Codex 工作流：Explore → Plan → Code → Verify → Review

这是 Codex 系列的第 7 篇。

前面几篇已经讲了几个基础件：

• 第 4 篇：先让 Codex 读懂项目，不要一上来就写 Prompt。
• 第 5 篇：用目标、上下文、约束、验收标准组织 Prompt。
• 第 6 篇：把反复出现的项目规则沉淀到 AGENTS.md。

到这里，一个新问题会出现：即使 Prompt 写清楚了，AGENTS.md 也写了，真实任务仍然可能失控。

原因很简单：真实项目里的任务不是“一问一答”，而是一段工程过程。Codex 会读文件、搜索、推断、编辑、跑命令、检查结果，再根据结果继续下一步。你如果只给一句“帮我实现”，它也会自己组织过程，但这个过程是否可靠、是否可复盘、是否容易验收，就很依赖运气。

我现在更愿意把一次 Codex 任务拆成五段：

Explore -> Plan -> Code -> Verify -> Review

这不是为了把使用方式变复杂，而是为了把不确定性分层处理。先确认现场，再决定方案；先做小改动，再验证；最后读 diff，而不是看到“完成了”就接受。

整理日期：2026-07-12。本文涉及 Codex 工作流、Plan mode、Goal mode、Prompting、验证、Review pane 和 Worktree，主要参考 OpenAI Codex 官方文档，并结合这个博客项目和前面几篇文章的实践整理。

产品说明：截至 2026-07-12，Codex 的桌面编码体验已经进入 ChatGPT 桌面应用。为避免每段都写很长，本文仍用“Codex app”简称桌面应用里的 Codex 项目与 Review pane。

这篇解决什么问题

读完这篇，你应该能带走四样东西：

这篇的重点不是让你每次都机械地走完五步。小任务当然可以合并步骤。但只要任务开始涉及多个文件、线上行为、数据迁移、权限、安全、发布、用户可见页面，我建议至少在心里过一遍这五个阶段。

一分钟速览

• Explore -> Plan -> Code -> Verify -> Review
  
   是本文整理的工程工作模型，不是 Codex 强制执行的五个内置状态。
• Explore 负责减少未知，Plan 负责收住范围，Code 负责产生最小 diff，Verify 负责给证据，Review 负责决定是否接受。
• 小任务可以合并阶段；一旦涉及多文件、用户数据、权限、远端写入或发布，阶段应该拆得更清楚。
• 内置 Plan mode 适合复杂或模糊任务；长期、多轮且需要持续迭代的任务，可以在当前界面支持时再考虑 Goal mode。
• 这篇最值得收藏的是开头的短模板、第 8 节的完整任务模板、第 9 节的真实案例，以及文末检查清单。

怎么使用这篇

这篇不需要顺序背诵。先根据你手里的任务，跳到最能解决当前问题的位置。

边界说明：五阶段的价值是让过程可检查，不是增加仪式。普通 Prompt 也能完成这套流程；Plan mode、Goal mode、/review 和 Worktree 是在合适场景下帮助执行的产品能力，不要把它们和五个阶段一一对应。

先收藏这版短模板

如果你现在没时间读完整篇，可以先把下面这段存起来。它适合大多数中等复杂度任务：

请按 Explore -> Plan -> Code -> Verify -> Review 完成这个任务。

Explore：先只读，不改文件；找相关文件、数据流、命令、Git 状态和风险。
Plan：给最小计划；明确改什么、不改什么、怎么验收。
Code：按计划小步修改；不做无关重构；遇到计划外风险先停。
Verify：运行最小相关检查；给命令、结果、失败原因和替代证据。
Review：自查 diff；列出风险、无关改动、人工重点检查点。

任务是：
[写清楚你要完成什么]

Done when：
[写清楚什么结果算完成]

这段模板不是为了显得正式，而是为了强制 Codex 留下中间证据。读者真正能带走的不是这五个英文词，而是一种节奏：先看清现场，再改；先验证，再接受。

1. 为什么不能只说“直接开始写”

很多失败的 Codex 任务，不是因为模型不会写代码，而是因为它太快进入了实现。

比如你说：

帮我修一下后台文章列表的分类下拉框，感觉有 bug。

这句话看起来很自然，但里面至少有几件事没说清楚：

Codex 的优势是它能主动探索。但探索本身也需要边界：先只读、先复现、先报告发现，再决定是否改。

所以我会把“直接开始写”改成：

先不要改文件。请只读检查后台文章列表的分类下拉框：
1. 找到相关页面、组件、API 和数据来源；
2. 判断问题可能出在前端状态、接口、数据库还是样式；
3. 给出最小修复计划和验证步骤；
4. 等我确认后再改。

这就是 Explore 和 Plan 的价值：让 Codex 在动手前，把它看到的世界先摆出来。你不一定每次都要手动确认，但至少要让它有机会把关键假设说出来。

OpenAI Codex 官方最佳实践里也有相同方向的建议：复杂或模糊任务先让 Codex 做计划；Prompt 里写清目标、上下文、约束和完成标准；不要停在“改完了”，还要让它测试、检查和 review。

示例说明：第 1-4 节用“后台分类下拉框”贯穿讲解，里面的文件路径、API 和测试命令是结构示例，不代表当前博客源码。真正使用时，应先让 Codex 从 package.json、README、CI 配置和现有测试里确认准确命令，不要照抄示例执行。

2. 五阶段工作流总览

我会这样理解这五段：

如果只记一句话，我会记这个：

Explore 降低未知，Plan 降低范围，Code 产生 diff，Verify 提供证据，Review 决定接受。

一份合格的中间输出应该长这样

只让 Codex “按流程做”还不够，你还要知道每一阶段的输出是否合格。否则它可能只是换一种方式说“我会努力完成”。

我会用下面这张表判断：

一个比较好的中间输出会长这样：

Explore 结果：
- 相关文件：app/admin/posts/page.tsx、components/admin/category-select.tsx、app/api/categories/route.ts
- 数据流：页面加载 -> 请求 categories API -> 下拉组件根据返回数组渲染选项
- 当前 Git 状态：components/admin/category-select.tsx 有用户未提交改动，暂不覆盖
- 最小验证：打开 /admin/posts，展开分类下拉；保存后刷新确认分类仍然存在
- 未知项：线上后台是否和本地代码同版本，需要后续确认

如果 Codex 的输出没有具体文件、具体命令、具体风险，就不要急着让它进入下一步。先让它补现场。

3. Explore：先让 Codex 读懂现场

Explore 阶段的目标不是让 Codex 写方案，而是让它建立项目地图。

我一般会要求它做这些事：

OpenAI 的版本控制建议是：能做到时，先在独立分支上工作，并让 git status 保持干净，这样 diff 更容易隔离和回滚。如果现实里已经有未提交改动，Explore 至少要明确列出这些文件，并把“保留用户改动”写进边界。

一个可复制的 Explore Prompt：

先进入 Explore 阶段，不要改文件。

目标：
我要解决：[一句话描述任务]

请你只读检查：
1. 当前 repo 的结构和相关目录；
2. 与这个任务最相关的文件、组件、API、测试；
3. 现有 Git 状态，哪些改动可能不是你做的；
4. 可以用来验证的最小命令；
5. 你目前还不确定的地方。

输出格式：
- 项目地图
- 相关文件列表
- 初步判断
- 风险和未知项
- 建议进入 Plan 阶段的下一步

这个 Prompt 的关键是“不要改文件”。它会把 Codex 从“马上解决”切到“先读懂”。

Explore 阶段的好输出

我会期待它输出类似这样：

项目地图：
- app/admin/posts/page.tsx：文章列表页面
- components/admin/post-category-select.tsx：分类下拉组件
- app/api/categories/route.ts：分类 API
- lib/db/posts.ts：文章和分类查询

初步判断：
- 下拉框显示“未分类”但没有选项，可能不是样式问题；
- 需要检查 API 返回值和前端状态初始化；
- 目前没有证据说明需要改数据库 schema。

验证入口：
- npm run test:run -- category
- npm run build
- 手动访问 /admin/posts，打开分类下拉，确认选项可见并可保存。

如果 Explore 阶段只输出“我会修复这个问题”，那还不够。它需要告诉你：它准备在哪里动手、为什么那里最可能相关、怎么证明不是乱猜。

4. Plan：计划不是作文，是控制范围

Plan 阶段最容易写成空话。

不好的计划长这样：

我会分析问题，修改代码，测试功能，确保正常。

这跟没计划差不多。

好的计划应该让你能判断三件事：

1. 改动范围是不是太大。
2. 验证方式是不是足够具体。
3. 一旦失败，是否知道怎么停下来。

我常用的计划表：

Plan Prompt 可以这样写：

基于刚才 Explore 的结果，请进入 Plan 阶段。

请给我一个最小修复计划：
1. 每一步要改哪些文件；
2. 明确哪些文件和行为不改；
3. 每一步怎么验证；
4. 如果验证失败，下一步如何定位；
5. 哪些地方需要我确认后才能继续。

计划要偏工程执行，不要写泛泛的“分析、修改、测试”。

OpenAI 文档里提到，对于复杂、模糊或难描述的任务，可以使用 Plan mode，让 Codex 先收集上下文、提出问题、形成更强的计划。当前可以通过 /plan 或 Shift+Tab 切换到 Plan mode。我的经验是：当任务涉及多个模块、数据库、登录态、部署或线上验证时，先 plan 一下往往比事后救火省时间。

5. Code：让 Codex 做最小可解释改动

进入 Code 阶段之后，要警惕一个现象：Codex 很容易“顺手变好”。

它可能在修一个 bug 的同时：

• 重命名一批变量；
• 顺手整理样式；
• 抽一个新 hook；
• 改掉无关函数；
• 重新格式化整个文件；
• 更新一堆依赖。

有时候这很好，但多数时候会增加 review 成本。你本来只想修一个分类下拉框，最后得到一个 800 行 diff，很难判断哪一行是真正必要的。

我会在 Code 阶段加这几条约束：

开始实现。

约束：
1. 只做计划里的最小改动；
2. 不做无关重构、样式重写、依赖升级；
3. 如果发现计划不成立，先停下来说明，不要扩大范围；
4. 保留已有用户改动，不要回滚你没有创建的改动；
5. 每完成一个小步骤，说明改了什么和为什么。

这里的重点不是限制 Codex 能力，而是把 diff 做成可理解的证据链。工程里真正让人放心的不是“它改得多”，而是“我知道它为什么只改这些”。

Code 阶段的暂停点

我希望 Codex 在这些情况下暂停，而不是硬做：

这也是为什么我不喜欢一开始就说“自动完成直到成功”。Agent 有自主性很好，但自主性需要停靠点。

6. Verify：验证不是跑一个命令截图

Verify 阶段的目标是回答一句话：

我们有什么证据说明这次改动真的完成了？

证据可以是不同层次的：

不是每个任务都需要全套验证。一个文案修正可能不需要跑完整测试；一个数据库迁移则不能只看页面能打开。

我会让 Codex 在 Verify 阶段输出这四类信息：

验证结果：
1. 已运行命令：
   - 命令、结果、关键输出
2. 手动验证：
   - 操作路径、观察结果、截图或日志
3. 未能验证的部分：
   - 原因是环境缺失、权限不足，还是任务本身不适合自动验证
4. 剩余风险：
   - 哪些情况还需要人工确认

一个可复制的 Verify Prompt：

进入 Verify 阶段。

请按最小充分原则验证刚才的改动：
1. 先运行与本次改动最相关的测试或检查；
2. 如果是 UI 或后台交互，启动本地页面并按复现步骤验证；
3. 如果某个验证不能跑，请说明原因，并给替代证据；
4. 最后用表格列出：验证项、命令/步骤、结果、是否通过。

不要只说“已测试”，要给出具体命令、结果和剩余风险。

这里有个小判断：如果 Codex 说“无法验证，因为环境不支持”，这不是失败，但也不是通过。它应该继续给你替代验证方案，比如读测试、跑更小范围命令、检查生成结果、给出人工验证路径。验证失败也不是坏事，坏的是把没有验证包装成已完成。

7. Review：接受之前要读 diff

Review 是很多人最容易省略的一步。

看到 Codex 说“完成了，测试通过”，人很容易直接合并。但在真实项目里，Review 至少要看四类东西：

ChatGPT 桌面应用里的 Codex Review pane 可以直接查看 Git 仓库改动。官方文档特别提醒：默认视图基于项目的 Git 状态，不只包含 Codex 自己改的内容，也可能包含你或其他工具留下的未提交改动。如果只想看最近一轮 Codex 产生的变化，可以切到 Last turn 视图。这一点在共用工作区时尤其重要。

我会在接受前让 Codex 做一次自 review：

进入 Review 阶段。

请站在代码审查者角度检查这次 diff：
1. 是否有无关改动；
2. 是否有潜在回归；
3. 是否有未处理的边界条件；
4. 测试是否覆盖了真正风险；
5. 哪些地方需要人工重点看。

请按严重程度列出 findings。没有问题也要明确说没有发现，并说明剩余风险。

在桌面应用或 CLI 中，也可以用 /review 触发专门的 review。当前桌面端可以选择对 base branch 做 review，或 review 未提交改动；在 CLI 里还可以在命令后追加关注点，例如 /review Focus on edge cases and security issues。我的建议是：写代码和找问题至少要分成两个明确阶段，让 Codex 真正切换到审查视角。

Review 不是把责任交给 AI

这一点要说清楚：Codex review 很有用，但它不是你不用看 diff 的理由。

我更愿意把它当成两件事：

1. 帮我先扫一遍明显 bug、边界和测试缺口。
2. 帮我把注意力集中到最值得人工看的地方。

最终是否接受、是否发布、是否提交，还是人的决定。尤其是涉及权限、支付、投资数据、用户隐私、数据库迁移、线上部署时，Agent 的“看起来合理”不能替代人工验收。

8. 一套完整任务模板

下面这段可以直接复制，用在中等复杂度任务上：

我想让你按 Explore -> Plan -> Code -> Verify -> Review 的工作流完成这个任务。

任务：
[一句话说明要完成什么]

背景：
[相关页面、功能、错误、截图、日志、用户反馈]

约束：
1. 不要做无关重构；
2. 不要覆盖已有用户改动；
3. 涉及危险命令、迁移、发布、远端写入时先停下来确认；
4. 保持现有项目风格和命名；
5. 如果发现任务描述不成立，先报告，不要硬改。

Done when：
1. [可观察结果 1]
2. [可观察结果 2]
3. [测试或检查通过]
4. 最后输出改动摘要、验证结果、剩余风险。

流程要求：
1. Explore：先只读检查项目地图、相关文件、验证入口，不改文件；
2. Plan：给出最小实现计划和风险，计划要具体到文件和验证；
3. Code：按计划做小步改动，发现计划不成立就暂停；
4. Verify：运行最小充分验证，说明命令、结果、失败原因或替代证据；
5. Review：自查 diff，列出问题、风险和人工重点检查点。

如果任务非常小，可以把 Explore 和 Plan 合并：

先快速确认相关文件和最小计划，再实现。不要做无关改动，完成后运行最小验证并 review diff。

如果任务非常大，反而应该拆成多轮：

这一轮只做 Explore 和 Plan，不实现。等计划确认后，再开下一轮实现第一阶段。

不要迷信一次 Prompt 走完全程。工程任务最稳的方式往往是分段推进。

9. 用第 6 篇的真实发布过程举例

这套流程不是只适合修代码。第 6 篇《AGENTS.md：Codex 项目说明书》的发布过程，就是一个刚发生在这个博客里的完整案例。

当时的任务看起来很简单：review 草稿，没问题就发布。如果直接把它理解成“把 draft 改成 false 再部署”，文章确实能上线，但几个真正影响读者的问题会一起漏过去：

• AGENTS.override.md
  
   的同目录替代语义没有说透；
• Rules 仍属实验能力，正文却没有提醒；
• SVG 底部的反馈文字被后绘制的卡片遮住；
• 桌面首屏标题只把最后一个“书”字挤到第二行；
• 文件检查通过，不代表页面在手机和桌面上都好读。

实际执行时，五个阶段留下了这样的证据：

如果要把这次任务写成一条可复制 Prompt，我会这样写：

请 review 系列第 6 篇草稿；只有达到发布标准后才发布。

Explore：
- 读取文章、配图、项目 AGENTS.md 和当前官方资料；
- 找出事实错误、过期信息、读者难以操作的段落和视觉风险。

Plan：
- 只修改文章和直属配图；
- 明确需要补的模板、边界说明和验证步骤。

Code：
- 保持技术笔记风；
- 不改其他文章，不做无关页面重构。

Verify：
- 运行内容检查与 lint；
- 用真实浏览器检查桌面和手机首屏、目录、表格与图片。

Review：
- 从读者角度判断是否值得收藏；
- 核对官方事实、链接、frontmatter 和剩余风险；
- 发布后回读文章页、首页、文章列表、RSS 和图片资源。

Done when：
- 读者能直接带走模板和检查清单；
- 页面没有文字孤行、图片遮挡或移动端溢出；
- 所有检查通过，线上关键资源返回 200。

这个案例让我更确定一件事：Verify 不能只等于“命令退出码是 0”。内容检查能发现 frontmatter 和资源引用问题，浏览器才能发现标题换行和图片布局问题，线上回读才能确认部署与缓存真的更新。不同证据解决的是不同层的问题。

10. 不同任务怎么调整五阶段

五阶段不是固定仪式。不同任务里，每一步的权重不同。

修 bug

修 bug 最重要的是 Explore 和 Verify。

你要让 Codex 先复现或解释为什么无法复现，再让它改。否则它可能只是根据症状猜一个补丁。

推荐 Prompt：

先复现或定位 bug，不要直接修。

请输出：
1. 复现路径；
2. 相关文件和数据流；
3. 最可能根因和排除掉的原因；
4. 最小修复计划；
5. 修复后如何证明这个 bug 不再出现。

加功能

加功能最重要的是 Plan 和 Review。

功能需求容易膨胀，Codex 也容易顺手设计一个更大的系统。你要把 MVP、非目标、验收标准写清楚。

推荐 Prompt：

这次只实现最小可用版本。

请先给计划：
- 新增哪些入口；
- 改哪些数据结构；
- 哪些边界暂不支持；
- 如何测试主路径；
- 哪些后续优化不放进本次 diff。

写技术文章

写文章也可以用这套工作流，只是 Code 阶段变成 Draft。

这也是这组 Codex 教程现在的写法：先调研，再写教程，再 review 是否值得收藏，最后发布。

比如我要写一篇新的 Codex 教程，可以这样发：

请按 Explore -> Plan -> Draft -> Verify -> Review 写一篇 Codex 教程草稿。

主题：
权限与安全：Sandbox、Approval、危险命令怎么管。

Explore：
- 先核对 OpenAI Codex 官方文档；
- 区分官方事实、社区经验和我的个人实践；
- 列出读者最容易踩坑的问题。

Plan：
- 给出文章大纲；
- 每一节说明解决什么读者问题；
- 确保至少有一个可带走产物，比如危险命令清单或权限决策表。

Draft：
- 写成技术笔记风；
- 不要营销式标题；
- 用真实项目例子说明。

Verify：
- 检查官方链接、术语、日期、图片引用和 frontmatter；
- 标注不确定或可能随版本变化的说法。

Review：
- 从读者角度判断：读完是否能在 30-60 分钟内完成一个安全配置练习；
- 如果不能，指出需要补的模板、表格或例子。

这个例子和写代码的差别不大：Explore 仍然是找事实，Plan 仍然是控制结构，Draft 仍然是产出，Verify 仍然是检查证据，Review 仍然是站在读者或维护者角度挑问题。

资料调研

资料调研最容易的问题是“看起来很完整，但证据不足”。所以 Explore 阶段要明确资料源，Verify 阶段要检查引用。

推荐 Prompt：

请先做 research note，不要直接写文章。

要求：
1. 区分官方资料、社区经验、个人判断；
2. 每条关键结论给来源链接；
3. 对不确定或过期风险高的说法标注日期；
4. 最后再给文章可用的大纲。

11. 什么时候用 Plan mode，什么时候用 Goal mode

先分清三件容易混在一起的东西：本文的 Plan 阶段是一种工作习惯，普通 Prompt 就能执行；内置 Plan mode 是让 Codex 在编辑前专门调查、提问和产出方案的产品能力；Goal mode 则用于需要多轮持续推进的目标。它们不是同一个概念。

不是每个任务都需要内置 Plan mode。

我会用这个判断：

官方文档把 Plan mode 放在“复杂任务先计划”的位置。我自己的理解是：Plan mode 最适合把“我要什么”还没说清楚的阶段变成对话，而不是让 Codex 边猜边改。

一个很实用的说法是：

先不要实现。请你采访我，直到你能把需求改写成有目标、上下文、约束和验收标准的任务单。

这句话对模糊需求很有用。很多时候，真正省时间的不是 Prompt 写得漂亮，而是先承认自己也没想清楚。

Goal mode 不是必经的第六阶段

在当前界面提供 Goal mode 时，可以先用 /plan 把方案谈清楚，再用 /goal 定义一个需要 Codex 持续推进的结果。普通的单轮改动不需要为了“高级”而启用它。

一个可靠 Goal 通常要写清六件事：

例如：

/goal 把这篇教程完善到可发布状态，以内容检查、桌面与手机渲染、线上回读作为证据；保持其他文章不变。每轮根据未通过的验证选择下一项修改。如果官方资料无法确认或部署不可用，停止并列出已确认事实、阻塞点和继续所需条件。

Plan 解决“准备怎么做”，Goal 解决“多轮之后怎样才算真正完成”。对大多数日常修复，五阶段 Prompt 已经够用；对长时间调试、性能优化、研究复现或需要自动续跑的任务，Goal 才更有价值。

12. 什么时候可以跳过某些阶段

五阶段不是宗教，不能为了流程而流程。

可以简化的情况：

但有些阶段不建议跳：

判断标准很简单：一旦失败成本变高，流程就要变细。

13. 常见反模式

反模式 1：把探索和实现混在一起

看一下这个问题并修掉。

更好的写法：

先只读定位问题，输出根因和最小修复计划；计划确认后再改。

反模式 2：计划没有验收标准

我会修改组件并测试。

更好的要求：

每一步都写清验证方式：命令、页面路径、预期结果、失败时怎么定位。

反模式 3：验证只说“通过”

测试通过。

更好的输出：

npm run test:run -- category
结果：通过，12 tests passed。

npm run build
结果：失败，原因是环境缺少 XXX；本次改动相关文件已通过类型检查，仍需在完整环境复测。

反模式 4：不读 diff

改好了，提交吧。

更好的流程：

先 review diff，列出无关改动、风险和人工重点检查点。确认后再 stage/commit。

反模式 5：让多个 Codex 任务改同一片文件

并行本身没有问题，问题是多个任务共用同一份可写工作区，还同时修改相同文件。你以为自己在提速，最后得到的往往是冲突、互相覆盖和难以归属的 diff。

如果要并行，最好按边界拆：

• 一个任务只做资料调研；
• 一个任务只做 UI 原型；
• 一个任务只做后端测试；
• 不要让两个任务同时改同一个组件。

在 ChatGPT 桌面应用里，Git 项目可以为并行任务使用独立 Worktree。每个 Worktree 有自己的文件副本，适合把后台任务和当前本地工作隔开；需要回到原环境验证时，再用 Handoff 移到 Local。

但 Worktree 不是“自动无冲突”。如果两个任务最终修改同一段代码，合并时仍要处理冲突。正确顺序是：先按模块或文件所有权拆任务，再用 Worktree 隔离执行环境。不是 Git 仓库的项目无法使用这套隔离，应避免同时写同一目录。

14. 把工作流写进 AGENTS.md

如果你发现自己经常要求 Codex “先 Explore，再 Plan，再 Verify”，就可以把它沉淀到 AGENTS.md。

AGENTS.md 里的规则可以用中文，也可以用英文。英文适合团队协作、工具命令和跨项目复用；中文适合个人博客、写作风格、内容边界和读者视角这种更细的偏好。关键不是语言，而是规则要具体、能执行、能验收。

比如：

## Default Task Workflow

For non-trivial tasks, use this workflow:

1. Explore: inspect relevant files, commands, current git status, and constraints before editing.
2. Plan: propose a small, verifiable implementation plan.
3. Code: keep diffs scoped and avoid unrelated refactors.
4. Verify: run the smallest relevant checks and report exact commands/results.
5. Review: summarize changes, risks, and what needs human attention.

Pause before destructive commands, database migrations, publishing, or remote writes.

对于这个博客项目，可以更具体一点：

## Blog Writing Workflow

For Codex tutorial posts:

1. Research current Codex facts against official OpenAI documentation.
2. Draft as a practical technical note, not marketing copy.
3. Include one take-away artifact: template, checklist, workflow, or example.
4. Review from the reader's perspective: can they finish a 30-60 minute exercise?
5. Before publishing, check frontmatter, category, tags, summary, links, images, and public page status.

AGENTS.md 里的流程不需要写太细。它只要提醒 Codex：这个项目默认不接受“改完就算完成”，需要可验证、可 review。

15. 30-60 分钟练习

找一个你自己的真实项目，选一个很小但不纯文本的任务，比如：

• 修一个表单校验问题；
• 给一个函数补测试；
• 优化一个后台列表交互；
• 给一个 API 增加错误处理；
• 整理一篇技术笔记的发布检查。

然后按下面流程跑一遍：

如果 60 分钟内做不完，不一定是失败。更可能说明任务太大，需要拆成两轮：第一轮只做 Explore + Plan，第二轮再实现。

第一步：只做 Explore

请先只读检查这个任务，不要改文件。
输出项目地图、相关文件、验证入口、未知项。

看 Codex 是否找对文件。如果它找错了，不要急着让它改，先纠正上下文。

第二步：让它给 Plan

请给最小实现计划。
每一步写清：改哪些文件、不改哪些范围、怎么验证、风险是什么。

删掉任何你觉得没必要的扩展。

第三步：让它 Code

按计划实现。保持 diff 最小。发现计划不成立就停下来说明。

第四步：让它 Verify

运行最小充分验证，输出命令、结果、失败原因或替代证据。

第五步：让它 Review

请 review 本次 diff，按严重程度列出潜在问题、无关改动和剩余风险。

最后你自己读 diff。这个练习的目标不是一次就让 Codex 完美，而是建立一个习惯：每次任务结束时，你知道它改了什么、为什么改、怎么验证、还有什么不确定。

收藏清单

可以把下面这段存成自己的快捷模板：

按 Explore -> Plan -> Code -> Verify -> Review 完成任务。

Explore：
- 先只读，不改文件；
- 找相关文件、数据流、命令、Git 状态和风险。

Plan：
- 给最小计划；
- 明确改什么、不改什么、怎么验收。

Code：
- 小步修改；
- 不做无关重构；
- 遇到计划外风险先停。

Verify：
- 运行最小相关检查；
- 给命令、结果、失败原因和替代证据。

Review：
- 自查 diff；
- 列出风险、无关改动、人工重点检查点。

我的经验是：这套流程真正有用的地方，不是把 Codex 管得很死，而是让它每一步都留下可检查的中间结果。这样你不是在“相信 AI”，而是在检查一段工程过程。

资料来源

• OpenAI Codex：Best practices，关于复杂任务先计划、测试、验证和接受前 review 的建议。
• OpenAI Codex：Prompting，关于 /plan、Goal mode、bug 复现、最小验证、UI 迭代与本地 review 工作流。
• OpenAI Codex：Code review，关于 Review pane、base branch、未提交改动和 /review。
• OpenAI Codex：Worktrees，关于在桌面应用中隔离并行任务与 Handoff。
• OpenAI Codex：Agent approvals & security，关于独立分支、干净 Git 状态、针对性验证和 diff review。
• OpenAI Cookbook：Using Goals in Codex，关于 Goal 的结果、验证面、约束、边界、迭代策略和阻塞停止条件。
• OpenAI：What’s new，关于 Codex 桌面编码体验进入 ChatGPT 桌面应用的当前说明。

下一篇我会继续写第 8 篇：权限与安全。前面几篇解决“怎么让 Codex 做事”，第 8 篇要反过来讲“哪些事情不能让它随便做”：Sandbox、Approval、危险命令、远端写入，以及发布前的人工确认。