我用 Codex 和 Claude Code 把 Landing Page 制作压到了 30 分钟

为什么我把 Landing Page 从拖拽编辑器换成了 Agent CLI

以前我用 Elementor 做一个落地页，从设计到上线要花半天。现在用 Codex 和 Claude Code 这类 Agent CLI 工具，同一个流程被压缩到了 30 分钟以内，而且代码更干净、加载更快。这篇文章就是把这套流程完整拆开讲。

核心思路只有四步：AI 根据 Markdown 生成完整 HTML，把内联样式抽成独立 CSS，生成 SEO 元信息和 Schema，最后部署到 WordPress 并自动填入 AIOSEO。下面按顺序拆开讲。

第一步：从 Markdown 到可预览的 HTML

起点是一份 Markdown 文档，把页面结构写清楚：标题层级、段落、列表、FAQ 问答。然后交给 Agent CLI，提示词可以很短：

请根据以下 Markdown 内容，生成一个响应式 Landing Page HTML 文件。
要求：
1. 使用现代简洁的设计风格
2. 包含完整的 Hero 区域、功能展示区、FAQ 折叠面板、CTA 按钮
3. 所有样式内联在 style 标签中
4. 确保在移动端也能正常显示

AI 会输出一个本地双击就能打开的 HTML 文件，CSS 和 JS 全内联。先在浏览器里检查设计是否符合预期，不满意就直接让 AI 改，比在 Elementor 里手动调整快得多。

这个阶段不用追求像素级完美，确认信息层级和整体风格方向对就行。样式后面抽出来还能单独微调。

第二步：样式和内容分离

AI 生成的 HTML 能直接用，但样式全堆在 style 标签里，页面本身显得臃肿。混在一起还有两个实际问题：每次加载都要重新解析大量内联样式，浏览器缓存用不上；搜索引擎抓到的 HTML 被样式代码稀释，有效内容占比低。

所以关键一步是把内联样式抽成独立的 CSS 文件：

1. 让 AI 把 HTML 中所有 style 块提取出来，存成独立的 .css 文件
2. HTML 只保留干净的内容结构，语义化标签、合理层级、没有冗余样式
3. CSS 文件上传到 WordPress 子主题的 assets/css 目录
4. 发布时用 Classic Editor 的 Custom HTML 模块，只粘贴纯净的 HTML

分离之后 HTML 体积通常减少 60% 到 80%。CSS 独立文件的缓存收益要分两种情况看：如果是每个落地页各自一个 CSS，缓存帮到的是同一页面二次访问时不用重新下载样式；如果多个页面共用同一个 CSS（比如共享一套基础样式），那跨页面访问也能命中缓存。对 Core Web Vitals 里的 LCP 和 FCP 有直接改善的是前者——首屏不再等内联样式解析。

第三步：让 AI 一起输出 SEO 元信息和 Schema

这一步经常被跳过，但收益很大。生成页面的时候，让 AI 顺带输出完整的 SEO 配置，后面靠插件自动填入，不用手动复制粘贴。

Meta Title 和 Meta Description

在提示词里加一条：

请同时生成以下 SEO 信息：
1. Meta Title（50-60 字符，包含核心关键词）
2. Meta Description（120-160 字符，包含号召性用语）

Schema 结构化数据

Schema 是搜索引擎理解页面内容的说明书，我让 AI 为每个落地页生成三类：

让 AI 输出纯 JSON，稍后直接粘贴进 AIOSEO 的 Custom Schema 字段。FAQPage 只在页面确实有 FAQ 内容时才生成，没有就不要硬凑。

第四步：部署到 WordPress

素材准备好之后进入部署环节，以 Hello Elementor 子主题为例。

上传 CSS 文件

把分离出来的 CSS 放到子主题目录：

wp-content/themes/hello-elementor-child/assets/css/your-landing-page.css

在 functions.php 里注册

编辑子主题的 functions.php，用 wp_enqueue_style 把 CSS 挂到目标页面：

function bdwt_enqueue_landing_page_css() {
    if (is_page('your-landing-page-slug')) {
        wp_enqueue_style(
            'bdwt-landing-page',
            get_stylesheet_directory_uri() . '/assets/css/your-landing-page.css',
            array(),
            '1.0.0'
        );
    }
}
add_action('wp_enqueue_scripts', 'bdwt_enqueue_landing_page_css');

发布纯净 HTML

后台新建页面，切到 Classic Editor 的 Custom HTML 模块，粘贴分离后的纯净 HTML，不带任何 style 标签。

用 mu-plugin 自动填入 AIOSEO

Meta Title、Meta Description 和 Schema 靠 AIOSEO 插件管理。为了不每次手动填，我在 wp-content/mu-plugins/ 放了一个小型 mu-plugin，通过 WordPress REST API 暴露接口，Agent CLI 工具拿到 App Password 就能自动完成三件事：把 Meta Title 填入对应字段，把 Meta Description 填入对应字段，把完整 Schema JSON 写进 Custom Schema 模式。

填入 Custom Schema 之后，记得把 AIOSEO 默认生成的 WebPage Schema 删掉，否则页面会输出两份 Schema 标记，搜索引擎反而困惑。在 AIOSEO 的 Schema 设置里找到默认 WebPage 项移除即可。

App Password 在 WordPress 后台的用户 → 个人资料 → Application Passwords 里生成，和登录密码不同，可以随时撤销。只给 CLI 工具必要的权限就好。

人工和自动的取舍

理论上整个流程可以全自动，只要把服务器 SSH 密钥也交给 CLI。我保留了两个手动步骤：上传 CSS 和编辑 functions.php。

原因是安全边界。App Password 只能操作 REST API 范围内的内容，SSH 密钥意味着完整的文件系统权限。把服务器完全开放给 CLI，风险远大于手动花两分钟传一个文件，所以我在便利和安全之间画了一条明确的线。

如果网站有完善的备份和 staging 环境，全自动也走得通。直接在生产环境操作的话，手动这两步不会拖慢多少进度。

完整流程和效率对比

把整个流程串起来就是四步：AI 根据 Markdown 生成带内联样式的可预览 HTML，抽离样式为独立 CSS 保持 HTML 纯净，同步输出 Meta Title、Description 和 Schema，最后上传 CSS、注册 functions.php、发布 HTML、用 mu-plugin 自动填 AIOSEO。

和拖拽编辑器相比，差距主要在时间、代码质量和批量能力上：

用 Agent CLI 做 Landing Page，替代的不是设计师，而是拖拽编辑器。审美判断和内容策略还是得自己来，但执行层面确实快了十倍。