Codex 实战：从需求到可运行页面

用 Codex 做页面开发，关键不是让它“随便设计一下”，而是把需求拆成目标、上下文、约束和验收标准。企业团队可以把 Codex 当成一个能读代码、改文件、跑命令、解释结果的执行助手，但仍要保留人工审核和上线验证。

这篇教程用“新增一个企业服务介绍页面”的场景，说明从需求到可运行页面的基本流程。

第一步：把需求写成可执行任务

不要只说：

帮我做一个好看的页面。

更好的写法是：

请在现有 Next.js 网站里新增一个企业服务介绍页面。
目标：让访客理解我们的企业 AI 诊断、培训、工作流部署和项目陪跑。
上下文：沿用首页视觉风格，使用现有 Tailwind 组件，不引入新 UI 框架。
约束：不要改导航结构，不要影响现有 /services 页面。
验收：本地 /enterprise-services 可以打开，移动端不重叠，npm run build 通过。

Codex 需要的是可执行信息，而不是抽象评价。

第二步：让 Codex 先读项目

在成熟项目里，第一步不是写代码，而是让 Codex 了解项目结构：

先阅读首页、服务页、Header、Footer 和现有页面组件，告诉我这个项目的页面风格和可复用组件在哪里。

Codex 通常会检查：

• 路由目录。
• 组件目录。
• 样式系统。
• 国际化文件。
• 现有 metadata 和 sitemap。
• 复用的数据结构。

这一步可以减少“写出一个和项目风格完全不同的页面”的风险。

第三步：锁定页面结构

页面结构要先确定，再写代码。一个企业服务页面可以拆成：

1. Hero：一句话说明服务定位。
2. 服务对象：老板、管理层、业务负责人、运营团队。
3. 核心服务：AI 诊断、企业 AI 培训、工作流自动化、知识库、智能体。
4. 交付流程：诊断、训练、试点、部署、复盘。
5. 典型场景：销售、客服、外贸、内容、知识管理。
6. FAQ：回答客户会问的问题。
7. CTA：预约 AI 诊断。

如果项目已经有统一组件，优先复用；如果没有，再让 Codex 新增小组件。

第四步：给出内容边界

企业页面最容易出现两个问题：内容太空，或者写成内部方案说明。

给 Codex 的约束可以这样写：

文案必须面向企业客户访客，不要出现“根据 SEO 长尾词写”“内部提示词”“页面要埋关键词”等后台语言。
可以自然覆盖企业 AI 培训、AI 落地实施、AI 工作流自动化、企业知识库等关键词。

这能避免把内部工作说明直接写到公开页面上。

第五步：让 Codex 实现并自检

实现阶段可以要求 Codex：

• 只修改相关页面和组件。
• 不做无关重构。
• 保持现有 Tailwind 风格。
• 添加 metadata、canonical、Open Graph。
• 如有 FAQ，补 FAQPage JSON-LD。
• 跑 npm run build。

对于页面任务，最好再让它检查移动端和桌面端是否有文字重叠、按钮挤压、图片变形。

第六步：检查 diff，而不是只看页面

Codex 完成后，企业团队至少要看三件事：

1. 页面是否符合业务表达。
2. 代码是否只改了相关文件。
3. 构建、路由、SEO metadata 是否正常。

如果要上线，还要确认：

• 是否需要更新导航。
• 是否需要加入 sitemap。
• 是否需要部署服务器。
• 是否需要触发内容 revalidate。

第七步：把成功流程沉淀下来

如果这个流程以后会重复使用，可以把提示模板沉淀到团队文档或 AGENTS.md：

页面开发默认流程：
1. 先读现有页面和组件。
2. 先给页面结构，再实现。
3. 文案面向访客，不写内部说明。
4. 保持 Tailwind 和现有视觉风格。
5. 实现后跑 build，并说明修改文件。

这会让企业团队使用 Codex 的质量越来越稳定。

FAQ

Codex 能完全替代前端工程师吗？

不能。Codex 可以加速实现、排查和整理，但需求判断、品牌表达、交互质量和最终审核仍需要人负责。

不懂代码的人能用 Codex 做页面吗？

可以做低风险页面和文档型页面，但要给清楚验收标准，并让懂项目的人做上线前审核。

Codex 做页面最常见的失败原因是什么？

需求太模糊、没有让它先读项目、没有约束视觉风格、没有检查移动端和构建结果。

资料来源

• OpenAI Codex Manual: Quickstart
• OpenAI Codex Manual: Best practices
• CRAZYAIGC 企业 AI 编程与内部工具项目经验