怎么给 OpenAI Codex 派活它才不跑偏？一次任务的 7 步拆解

⏱️ 预计阅读 16 分钟 ｜ 🎯 目标：学会怎么给 OpenAI Codex 派一件活，让它不乱猜、不越界、能验证，以及它跑偏时你能定位是哪一步出了问题。

先说清楚这篇讲什么、不讲什么。它不是讲 Codex 内部源码怎么实现的逆向工程文章。它讲的是一件更实用的事：把一次任务拆成 7 个你能看见、能干预的关口，让你知道任务该怎么写、过程中该盯哪里、卡住了该怎么救。

先把话说在前面：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 步就开始赌；一份清楚的任务，等于把它需要的信息一次给齐。

🔥 翔宇判断

在派活上多花的两三分钟，是 AI 编程里回报最高的两三分钟。一句「优化一下」省下的时间，往往要用一次返工十几分钟补回来。把任务写清楚不是麻烦事，它本身就是你对这件活想清楚的过程——你自己都说不明白要什么，Codex 不可能替你想明白。

二、一次任务的 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 写任务是同一个逻辑——具体到它不需要猜的程度。

这一步如果你自己都没想清楚要什么，别硬写，可以让 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 三种不合格的计划，看到就让它重写

⚠️ 常见踩坑

很多新手对看着不大的任务习惯让 Codex「直接改」。问题不在它一定改错，而在改错以后你无法回溯它为什么走到那一步。更稳的做法是：只要任务跨多个文件，先让它说计划——计划不对当场改，计划对了再放行。这个习惯比频繁换模型更能提升稳定性。

六、第 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 改完只说「已完成」，我该追问它什么？

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

相关阅读

• OpenAI Codex 完整学习指南 —— Codex 所有知识点的中枢页，看清学习顺序。
• OpenAI Codex 提示词怎么写？模糊需求转工程任务的新手完整指南 —— 第 1 步派活的进阶：用五件套和反向访谈把模糊需求逼成精确任务。
• AGENTS.md 怎么写？OpenAI Codex 智能体指令文件新手完整指南 —— 第 2 步最依赖它，把项目长期规则写清楚。
• OpenAI Codex 上下文工程新手指南 —— 第 2 步深入：该给哪些材料、哪些材料别塞。
• OpenAI Codex 沙箱与审批怎么配？让 AI 安全动手的双层防线新手指南 —— 当你开始让 Codex 真动手，下一步学清楚权限边界。

外部参考（实践建议与命令以官方当前文档为准，本文 2026 年 6 月核对）：

• OpenAI Codex Best Practices 最佳实践 —— Ask / Code 两步流、任务四件套、按任务难度选推理深度的官方来源。