Codex 标准六步法工作流：从需求到交付的完整闭环

很多人用 Codex 效果一般，不是因为模型不够强，而是缺少一套可复用的工作流程。这篇文章把 Codex 的标准工作流总结为六步法：需求拆解 → 制定计划 → 小步实现 → 测试 → 代码审查 → 提交与复盘。每一步都有明确的检查点和提示词模板，直接复制可用。

核心理念：Codex 是工程执行者，不是聊天框

Codex 能进入你的项目目录，读取文件、理解上下文、制定计划、修改代码、运行命令、检查结果、整理 diff 与 PR。它的定位是「帮你交付任务」，而不是「帮你写代码片段」。

区别一句话：Copilot 帮你补代码，ChatGPT 帮你想代码，Cursor 陪你改项目，Codex 帮你交付任务。

第一步：需求拆解——给 Codex 画边界

动手前先回答七个问题，核心是给任务画边界：

1. 背景是什么？
2. 要解决什么具体问题？
3. 哪些文件可能相关？
4. 哪些功能不能动？
5. 什么结果算完成？
6. 需要哪些测试？
7. 有哪些风险？

示例提示词：

背景：我有一個 React + TypeScript 项目，用户反馈登录失败率高。
目标：定位登录失败原因并修复，不改动认证流程和 API 路径。
相关文件：src/auth.ts、src/pages/Login.tsx
不能动：api/login 接口、token 存储逻辑
完成标准：登录成功率达到 99% 以上，回归测试通过
风险：可能影响其他依赖 auth.ts 的页面
复制

第二步：制定计划——先不要写代码

提示词第一句就写「先不要写代码」，用 /plan 或计划模式先拿到方案再执行。

避免一上来就改、等你发现方向不对时已经改了一堆文件。

示例提示词：

先不要写代码。请分析 src/auth.ts 和 src/pages/Login.tsx，
列出可能的失败原因和修改方案，等我确认后再执行。
复制

第三步：小步实现——一次只改一个功能点

• 改完一小步，检查一小步
• 明确禁止：顺手重构无关代码、改命名目录结构、升级依赖、删除"没用"的代码
• 六种不确定情形必须停下来问人：
• 不确定改哪个文件
• 能否删旧代码
• 是否新增依赖
• 业务逻辑是否理解正确
• 测试失败原因
• 需要超出计划的修改

示例提示词：

按计划修改 src/auth.ts 第 23 行的验证逻辑。
只改这一个文件，不改其他。改完后运行单元测试验证。
复制

第四步：测试——按从快到慢覆盖

测试顺序：

老项目注意：历史 lint 问题不要让它顺手重构，回归测试最容易被忽略——改了首页按钮，可能影响了复用同一组件的其他页面。

第五步：代码审查——两轮制

第一轮：Codex 自审

请输出审查表格，检查：
- 是否改到计划外文件
- 是否新增依赖
- 是否误删旧逻辑
- 是否有硬编码
复制

第二轮：人工看 diff

高风险区四类：边界条件、安全问题、是否误删、业务逻辑。涉及登录、支付、权限、数据库时，建议用第二个模型交叉审查。

第六步：提交与复盘——交付不是结束

让 Codex 生成：

1. Conventional Commit：fix(auth): 修复登录验证逻辑，增加空值检查
2. PR 描述：做了什么、为什么、改了哪、怎么测、有什么风险、重点看哪
3. 复盘记录：现象 → 原因 → 解决，沉淀有效 Prompt

把稳定规则更新进 AGENTS.md，同步更新 README/.env.example/docs/CHANGELOG。

交付不是结束，复盘才是下一次效率提升的开始。

完整任务模板（可直接复制）

我要完成【任务名称】。

背景：【项目背景】
目标：【具体要解决什么问题】
边界：
- 可改：【文件/模块列表】
- 不可动：【严禁改动的部分】
- 完成标准：【验收条件】

请按六步法执行：
1. 先回答七个问题，帮我明确边界
2. 输出执行计划，先不要写代码
3. 小步实现，每步确认后继续
4. 按顺序跑测试：unit → typecheck → lint → build → manual → regression
5. 输出自审表格 + diff 供我 review
6. 生成 commit message、PR 描述、复盘记录

如果遇到六种不确定情形，停下来问我。
复制

来源：今日头条「代码萌新充电站」《把 Codex 当作需要交代清楚、需要划边界、需要验收、需要沉淀规则的工程执行者》（2026-09-13）

资料最后核对日期：2026-09-18 · 内容整理自 CodexGuide 社区公开教程