先把话说在前面：7 步是简化模型，不是内部真相

网上许多文章把“Codex 的 7 步管线”当作 Codex 的内部原理来讲解，好像 Codex 代码里真有这七个固定的执行阶段。这是个典型的误解。

实际上，Codex 这类编程智能体（coding agent）的工作更像一个动态循环——读一点、判断一点、动手一点、看结果再调整。步骤可能合并、跳过、反复。OpenAI 也从未公开过“Codex 内部就是固定 7 步”的说法。

那为什么还要拆成 7 步？因为这是一套非常实用的心智模型。把一团模糊的过程切成 7 个关口，你就能做到两件以前做不了的事：

• 派活时知道该补充哪些信息（每个关口都需要你提供输入）。
• 卡住时能精准定位问题在哪个关口（而不是笼统地抱怨“Codex 不行”）。

所以，这 7 步的价值不在于“准确描述 Codex 内部”，而在于“给你一套能精准定位问题的坐标”。带着这个前提往下读，下面所有内容都围绕“如何把活派对”展开。

30 秒速查：派活前你最该确认的 6 件事

如果你只想快速了解“怎么给 Codex 派活才不跑偏”，先看这张表。每一行对应一个关口，后面的正文会逐个展开。

新手最容易犯的误区：把 Codex 当成“更会写代码的聊天机器人”，丢一句话过去，只看最后那段 diff（代码改动前后的差异对比）。结果它改对了你不知道为什么对，改错了你也不知道错在哪。这篇就是为了把这 7 个关口讲清楚，让你从“丢一句话”升级到“派一件能验收的活”。

一、Codex 不会读心，所以你得把活派清楚

新手第一次用 Codex 的挫败感，往往不是“它不会写代码”，而是“它没按我想的来”。

你输入“帮我修一下登录页报错”，它读文件、搜索、改代码、跑测试，最后说修好了。你看着 diff 心里没底：它到底改了什么？为什么要改这个函数？会不会顺手动了不该动的地方？

根子其实就一个：Codex 能读到的，只有你写的那句话。它没法知道你心里默认的那些前提——哪个文件是入口、哪些目录不能碰、什么样才算修好了。你不写出来，它就只能猜。猜得保守就只改一点，猜得激进就动一片。

所以说，“派活”这件事，决定了后面六步会不会顺。一句模糊的话，等于让它在第 1 步就开始赌；一份清楚的任务，等于把它需要的信息一次给齐。

二、一次任务的 7 步全景：用一个真实小任务走一遍

光看表还不够直观。拿一个具体任务走一遍，你就能看清这 7 步到底长什么样。

任务：“登录页邮箱为空时不应该提交。”

一次健康的过程是这样的：

这个过程不神秘，就是一个工程师正常做事的顺序。Codex 的强项，是能把读、改、测、复盘串起来自动跑；而你的责任，就是在每个关口给它设定足够清晰的边界。

这 7 步不是流水线那样一步一格往下走。小任务可能几步合在一起，复杂任务会在第 4、5、6 步之间反复——测试失败就回去读文件、再改、再测。这种“动手、看结果、再调整”的反复，就是业界常说的智能体循环（agentic loop）。它能自己纠错，靠的就是把测试这类真实反馈放回下一步判断里。

记不住 7 个名字没关系。真正要带走的是这一句：前三步（需求、上下文、计划）决定了方向，后三步（改代码、验证、汇报）决定了可信度，中间的工具调用把方向落成动作。出问题时，你就能指着其中一步问“是这里错了吗”。

三、第 1 步：把“优化一下”改写成能执行的任务

这是 7 步里你最该花力气的一步。需求写清楚了，后面六步大半能自己跑顺。

直接看一个改写例子。同一个需求，从模糊到能执行：

❌ 模糊版（它一定会乱猜）：

帮我修登录 bug。

✅ 能执行版（它不用猜）：

目标：修复登录页邮箱为空时仍然提交的问题。
范围：只改 src/app/login 和相关测试，不改认证后端。
先看：src/app/login/page.tsx、tests/login.test.ts。
验收：相关测试通过，并说明是否需要新增测试。

这四句话看起来普通，但它把 Codex 最需要的信息一次给齐了：要什么、不做什么、先看哪里、怎样算完成。它不用花时间猜入口、猜边界、猜测试，后面每一步你也更容易检查。

OpenAI 官方最佳实践里给的任务通常包含四件：Goal（目标）、Context（上下文）、Constraints（约束）、Done when（完成标准）；社区在此基础上常补一个 Inputs（输入数据/类型），凑成五件套。上面那四句正好对应这三核心——目标是 Goal，范围是 Constraints，先看是 Context，验收是 Done when。

3.1 为什么“优化一下”不是任务

“优化一下”“完善一下”“看看有没有问题”这类话，哪怕对人类同事也很难执行。它们是方向，不是任务。Codex 收到方向，会自己补一个任务定义——补得对你觉得它聪明，补得错你觉得它乱来。

把方向拆成动作，就成了任务。比如“优化这篇文章”，拆成：“删除重复段落，降低代码块比例，把 FAQ 改成真实搜索问题，保留 frontmatter 和内链。”每一条都是具体动作，Codex 没有自由发挥的空间。

这一步如果你自己都没想清楚要什么，别硬写，可以让 Codex 先反问你。怎么用反问把模糊需求逼成清楚规格，可以看看《OpenAI Codex 提示词怎么写？模糊需求转工程任务的新手完整指南》。

四、第 2 步：上下文给“最相关的两三个”，不是越多越好

Codex 接到任务后会去找上下文：AGENTS.md、你引用的文件、错误日志、目录结构，还有它自己刚跑出来的命令结果。

新手容易走两个极端，两个都会让它跑偏：

更稳妥的做法是“先给关键证据，再让它补查”：你知道报错来自某个页面，就先给页面文件和测试文件这 2 到 3 个；它要更多会自己搜索。这样你能看到它为什么打开新文件，也能及时判断它是不是跑偏了。

4.1 AGENTS.md 放长期规则，提示词放本次任务

这里有个新手常混淆的点：AGENTS.md 是 Codex 每次任务开始都会读的项目指令文件，放的是持久规则——测试命令是什么、哪些目录不能动、项目用什么框架。而今天这次任务的目标、范围、验收，属于一次性信息，应该放在提示词里。

两者千万别混。如果你把“今天不要跑全量测试”写进 AGENTS.md，下周 Codex 可能还记着这条临时规则，在你早就想跑全量测试的时候偏不跑。长期文件只放长期规则，这是上下文工程最基本的卫生习惯。

AGENTS.md 到底怎么写、放哪些内容，可以看看《AGENTS.md 怎么写？OpenAI Codex 智能体指令文件新手完整指南》；上下文到底该给哪些、哪些别塞，可以看看《OpenAI Codex 上下文工程新手指南》。

五、第 3 步：复杂任务先要计划，把计划当刹车

大任务直接让 Codex 开改，风险在于：你还没看懂它准备怎么做，它已经改了五个文件。方向对还好，方向错就得回滚。

所以跨多文件的任务，先让它出计划。Codex 自带规划模式，敲 /plan 或按 Shift+Tab 切换。OpenAI 团队自己的实践是：大改动先用 Ask 模式让 Codex 给实现计划，再切到 Code 模式执行，这个两步流能明显降低跑偏概率。

计划不用长，但必须回答三件事：

• 它准备先看哪些文件。
• 它准备改哪些地方。
• 它准备怎么验证。

一份合格的计划长这样：

计划：
1. 先读登录页和现有测试，确认空邮箱提交的当前行为。
2. 在表单提交前补客户端校验，不改后端认证逻辑。
3. 增加一个空邮箱测试。
4. 跑 login 相关测试；如果失败，只围绕登录页继续修。

这份计划的好处是边界清楚。它没说“顺便重构登录模块”，也没说“优化用户体验”，只处理这次 bug。新手最需要的就是这种窄计划。

5.1 三种不合格的计划，看到就让它重写

六、第 4 步：看工具调用有没有“证据链”

Codex 会用工具读文件、搜索文本、运行命令、应用补丁。你不用盯每个工具名，但要看这串调用有没有围着目标走。

正常的工具链每一步都接得上：

读登录页 → 发现 submit 逻辑 → 读测试 → 发现没有空邮箱用例 → 改页面 → 补测试 → 跑测试

不正常的工具链像在项目里乱逛：

读登录页 → 跳去改全局 auth → 又改样式 → 又改路由 → 没解释为什么

你不需要懂所有代码，也能看出前者围着目标推进、后者在发散。看到它发散，直接打断，让它复述：

先暂停。告诉我你现在定位到哪一步、已经确认了什么证据、下一步为什么要看这个文件。

能说清就放它继续，说不清就让它回到计划。

工具调用多不代表专业。它连读十个文件，可能是深入理解项目，也可能是没给入口在瞎找。判断标准只有一个：每个文件和任务有没有关系，而不是读了几个。读登录页、表单组件、登录测试很合理；突然开始读结算、订单、通知模块，就该问一句为什么。

七、第 5 步：改代码时，提前堵住“顺手”

Codex 改代码最容易出现一种情况：为了让问题看起来更完整，它顺手改了相关但不必要的文件。修一个登录 bug，顺手重构表单组件；改一个测试，顺手调整全局工具函数。

这不是它“坏”，而是任务边界没压住。编程智能体看到相关问题，会自然想一起处理。人类工程师也这样，只是人更容易意识到“这次 PR（pull request，一次提交评审的代码改动包）不该做太多”。

所以，在任务里提前写明边界：

不要顺手重构，不要修改无关文件。如果发现额外问题，只记录到“后续建议”，不要直接改。

这两句话很朴素，但非常管用。它能把 Codex 从“热心同事”拉回“本次任务负责人”。最后那句尤其关键——Codex 做任务时经常会发现相邻问题（比如修登录页时发现错误提示组件也不统一），这些发现有价值，但不该现在改。让它放进“后续建议”，既不丢信息，也不扩大本次改动。在真实工程里，这是控制 PR 质量的关键。

八、第 6 步：验证比修改更重要，要和改动匹配

Codex 说“已修复”不等于真的修复。你要看它怎么验证。验证分三层，按改动选，不是每次都跑全套：

（表里 lint 是代码风格与低级错误检查，build 是构建，看代码能不能编译打包通过。）

OpenAI 的 Codex 实践反复强调可靠测试环境的重要性，原因很直接：Codex 能不能自己纠错，取决于它能不能看到真实反馈，而测试输出就是最硬的反馈。

8.1 测试失败时，先定位“第一个真实失败”

测试失败不是坏事，Codex 会继续改。你要看它怎么读这个失败。

好的处理是先定位第一个真实失败：是断言错了、环境没起、依赖缺失，还是代码逻辑真错。差的处理是看到红色就开始乱改，越改越乱。你可以直接给它一条硬规则：

如果测试失败，先总结第一个真实失败原因，再决定是否修改代码。

这一句能防止它在失败循环里打转。

8.2 文档、配置类任务也要验证

不是只有代码需要验收。文章重写可以验证：H2 是否合理、有没有重复段落、FAQ 是否真实、内链是否存在、frontmatter 有没有坏。配置修改可以验证：能否解析、敏感信息有没有写进去、变更范围对不对。

“没测试”不等于“没验证”，验证方式跟着任务类型走就行。

九、第 7 步：好的汇报会告诉你“没做什么”

很多新手只看 Codex “完成了什么”。但更重要的是它有没有说清“没做什么”和“还不确定什么”。

一份合格的汇报包含四项：

• 改了哪些文件。
• 为什么这么改。
• 跑了哪些检查，结果怎样。
• 哪些事没做，或还有什么风险。

如果它只说“已完成”，这不是交接，是客套。直接要求它补：

请按“改动文件 / 验证结果 / 未处理风险 / 后续建议”四项重新汇报。

这份汇报是你决定要不要继续信任结果、要不要提交、要不要发布的依据。少一项，就让它补。Codex 的最终汇报不是收尾时的礼貌话，它就是一张交接单。

十、卡住了怎么救：7 步卡点排查表

Codex 出问题时，别先急着换模型，先定位它卡在哪一步。

10.1 一个完整的救场动作

假设 Codex 修完后测试失败，它又连续改了两次还没过。别让它继续循环，用下面这段把它从“继续尝试”拉回“重新定位”：

暂停继续修改。请按 4 点说明：
1. 当前任务的原始目标是什么？
2. 已经改了哪些文件？
3. 第一个真实测试失败是什么？
4. 你认为下一步应该改代码、改测试，还是补上下文？

很多时候 Codex 不是不能修，而是被连续失败带偏了。让它重新陈述目标和第一个真实失败，往往比它再自动试五轮更快收敛。

10.2 什么时候才轮到调推理深度

如果上面这些步骤都做了——任务写清了、上下文给对了、计划也窄了——它还是搞不定，这时才考虑调推理深度（reasoning effort）。用 /model 命令切换模型和推理深度档位。

OpenAI 官方对档位的建议是“根据任务难度选推理深度”：简单任务用低档省时间，复杂任务用高档让它想得更深。注意顺序：跑偏的常见原因是任务没写清、材料给错，不是推理不够深。先修前面这些，把调档位留给“任务确实写清楚了、纯粹因为问题难”的情况。把调档当第一反应，你会一边烧着高档算力一边继续踩同一个坑。

十一、一份可复用的派活模板

固定用这个模板给 Codex 派任务，六个字段对应 7 步里你能控制的关口：

目标：
范围：
先看：
不要做：
验收：
完成后汇报：

填好以后：

目标：修复登录页空邮箱仍然提交的问题。
范围：只改登录页和相关测试。
先看：src/app/login/page.tsx、tests/login.test.ts。
不要做：不要重构认证流程，不要改后端 API。
验收：新增空邮箱测试并通过相关测试。
完成后汇报：改动文件、验证结果、剩余风险。

字段和 7 步的对应关系：目标对应接需求，先看对应给上下文，范围和不要做对应计划边界，验收对应验证，汇报对应收尾。把这六行变成派活的肌肉记忆，你就不会漏掉关键信息。

十二、发任务前的自检清单

动手前对照过一遍，能挡掉大部分跑偏：

• [ ] 目标写成了“干完是什么样”，不是“优化一下”。
• [ ] 范围写清了改哪里、不改哪里。
• [ ] 给了 2 到 3 个最相关的文件作起点，没塞整个目录。
• [ ] 验收标准明确（哪些测试要过、什么行为算对）。
• [ ] 跨多文件或影响较大时，要求它先出计划（/plan 或 Shift+Tab）。
• [ ] 要求它最后按“改动文件 / 验证结果 / 未处理风险”汇报。
• [ ] 长期规则放进了 AGENTS.md，临时要求放进了本次提示词。

勾完这七条，你交出去的就不再是一句模糊的话，而是一份能被执行、可验证的工程任务。

十三、收尾：从“丢一句话”到“派一件活”

回到开头那句话——把任务拆成 7 步，不是因为 Codex 内部真有这七个阶段，而是因为这套坐标能让你把活派对、把问题定位准。

你不需要记住“7 步”这个说法，你要带走的是这套动作：派活前把目标、范围、材料、验收写清；过程中盯它读的材料对不对、改的范围是否越界；它说完后追问它没做什么、还有什么风险；卡住了先定位哪一步出问题，再决定是改任务、补材料还是重开。

把需求写清、把计划当刹车、把验证盯死——剩下的就交给它的智能体循环。你能说清它现在卡在第几步，就已经超过了大多数只丢一句话、只看 diff 的新手。

常见问题（FAQ）

把任务拆成“7 步”是 Codex 内部真实的工作流程吗？

不是。这 7 步是帮你理解和定位问题的简化模型，不是 Codex 内部代码的真实实现，OpenAI 也没公开过这种说法。真实的智能体执行更像一个不固定的循环：读一点、判断一点、动手一点、看结果再调整。用 7 步是因为它好记、好定位——出问题时你能指出“它卡在拉上下文还是出计划”。

Codex 的 Plan 模式具体怎么开？和直接让它改有什么区别？

敲 /plan 或按 Shift+Tab 切换。开启后 Codex 先收集上下文、问澄清问题、给一份计划，你同意后它才动手。OpenAI 团队的实践是大改动先用 Ask 模式给计划，再切 Code 模式执行。区别在于：直接改时你看不到路线，发现方向错它可能已经动了好几个文件；先要计划能在它动手前拦下错误方向。跨多文件、改错难回滚的任务建议先要计划。

Codex 一直在读文件不动手，是卡住了吗？

不一定，但值得打断确认。通常是两种情况：你没给入口、它在大项目里到处找；或者它读的文件和任务无关、在乱逛。两种都不该干等。打断它，让它复述现在定位到哪一步、确认了什么、下一步为什么看这个文件。能说清就放它继续，说不清就把相关文件路径直接喂给它。

推理深度怎么配？任务跑偏要不要调高？

用 /model 命令切换模型和推理深度档位。OpenAI 官方建议根据任务难度选档位——简单用低档、复杂用高档。但跑偏的常见原因是任务没写清、上下文给错，不是推理不够深。先修任务描述和材料，这两步修好了再考虑调高档位，别把调档当跑偏后的第一反应。

测试已经跑过了，为什么还要自己看 diff？

测试绿不等于改动符合预期。测试只覆盖被写进测试的情况，覆盖不到的地方 Codex 可能顺手改了——删注释、调无关函数、加多余依赖，这些不会让测试变红但可能不是你想要的。“跑过测试”验证功能没坏，“看 diff”确认范围没越界，是两件事。

Codex 改完只说“已完成”，我该追问它什么？

追问四项：改了哪些文件、为什么这么改、跑了哪些检查结果如何、有哪些没做或还有什么风险。直接要求它“按改动文件 / 验证结果 / 未处理风险 / 后续建议四项重新汇报”。最该盯后两项——它没做什么、还有什么不确定，这两项漏了你会误以为任务全清了。