OpenAI Codex任务7步拆解，精准派活不跑偏

基于工程实践构建的7步模型，并非Codex内部真实流程 许多技术文章将Codex的7步管线描述为其内部工作机制，这是一种常见的误解。实际上，Codex这类编程智能体的执行更接近一个动态循环：读取、判断、操作、观察结果并调整。步骤会合并、跳过或重复。OpenAI从未官方确认过“Codex内部存在固定的7个阶段”。 那么，为何还要拆解为7步？因为它是一个极其有效的心智模型。将模糊不清的过程切分为7个检查点，你就能做到两件原本无法实现的事： * 分配任务时，明确每个检查点需要提供哪些信息。 * 遇到卡点时，精准定位问题出在哪个环节，而不是笼统地归咎于“Codex不行”。 因此，这7步的价值不在于“精确描述Codex内部逻辑”，而在于“为你提供一套能准确定位问题的坐标系统”。带着这个理解阅读下文，所有内容都将围绕“如何高效分派任务”展开。 快速参考：任务分派前必须核实的6个关键点 如果你只想快速掌握“如何避免Codex偏离任务方向”，可以直接查阅这张表格。每一行对应一个检查点，后续正文将逐一展开。 | 检查点 | 需确认事项 | 错误示例（会跑偏） | | :--- | :--- | :--- | | 1. 需求定义 | 目标具体到可交付的成果形态 | “优化一下” | | 2. 材料提供 | 提供2到3个最相关的文件作为起点 | 一句话不提供入口，或塞入整个目录 | | 3. 计划制定 | 涉及多文件的任务，先要求计划再执行 | 直接让它在大型改动上开始修改 | | 4. 工具审视 | 检查它读取的文件是否与任务相关 | 它开始翻阅无关模块且未解释原因 | | 5. 边界遵守 | 明确指令“不要顺手改动无关文件” | 修复一个bug时顺手重构了其他模块 | | 6. 验证跟踪 | 要求它执行相应的测试或检查 | 它说“应该可以”就结束任务 | | 7. 结果交接 | 要求按文件改动、验证结果、风险项汇报 | 只汇报“已完成” | 新手最常见的误区：将Codex视为“一个更会写代码的聊天机器人”，丢给它一句话，然后只看最终的代码差异（diff）。结果，代码改对了不知道为什么对，改错了也不知道错在哪里。本文的目的就是讲透这7个检查点，让你从“丢一句话”升级到“分派一个可验收的工程任务”。 一、Codex无法读取意图，任务描述必须清晰 新手首次使用Codex时的挫败感，往往源于“它没按我的想法执行”，而非“它不会写代码”。 当你输入“帮我修一下登录页报错”，它会读取文件、搜索、修改代码、运行测试，然后报告修复完成。但你看着代码差异（diff）会感到不安：它到底改了什么？为什么修改那个函数？会不会顺手动了不该动的地方？ 问题的根源只有一个：Codex能接收到的信息，仅限于你输入的那句话。它无法知晓你心中默认的前提条件——哪个是入口文件、哪些目录不能碰、怎样才算修复成功。你不明确写出来，它只能猜测。猜测保守，它就只改一点点；猜测激进，它就可能改动一大片。 因此，“分派任务”这一动作，决定了后续六个步骤是否顺畅。一句模糊的指令，等于让它在第一步就开始猜测；一份清晰的任务说明，则相当于一次性提供了它所需的所有信息。 二、任务全景示例：用真实场景走完7步 附注：图片展示了一次任务的7步拆解，详细说明了在每个阶段Codex做什么、用户需要关注什么。 只看表格可能不够直观。我们用一个具体任务来演示，你就能看清这7步的实际运作。 任务：“登录页当邮箱为空时，不应允许提交。” 一个健康顺畅的执行过程如下： | 步骤 | Codex的动作为例 | 你需要关注的点 | | :--- | :--- | :--- | | 1. 接收需求 | 确认目标：空邮箱时阻止提交行为 | 目标是否足够具体 | | 2. 获取上下文 | 读取`AGENTS.md`、登录页面文件、相关测试文件 | 它读取的材料是否准确 | | 3. 制定计划 | 决定只修改前端校验逻辑，不动后端认证 | 计划范围是否过大、是否遗漏了验证环节 | | 4. 调用工具 | 读取文件、搜索文本、运行命令、生成补丁 | 工具调用是否与任务目标相关 | | 5. 修改代码 | 修改登录页面，补充一条空邮箱验证的测试用例 | 修改是否越界，触及了无关文件 | | 6. 自我验证 | 运行与登录相关的测试用例 | 验证命令是否正确、结果是否可信 | | 7. 结果汇报 | 总结修改了哪些文件、测试结果如何、遗留风险是什么 | 是否清晰说明了“做了什么”和“没做什么” | 这个过程并不神秘，本质上是工程师处理问题的常规流程。Codex的优势在于，它能将读取、修改、测试、复盘串联起来自动执行；而你的责任，是在每个环节为其设定足够清晰的边界。 这7步并非流水线般严格按序执行。小型任务可能合并几步，复杂任务则会在第4、5、6步之间循环——测试失败后返回去读取文件、再次修改、再次测试。这种“执行、观察、再调整”的循环，正是业内常说的“智能体循环”。它能自我纠错，依靠的是将测试这类真实反馈纳入下一步决策。 记不住7个步骤的具体名称没关系。关键在于记住：前三步（需求、上下文、计划）决定了方向，后三步（改代码、验证、汇报）决定了可信度，而中间的工具调用则将方向转化为具体行动。当问题出现时，你就能指着其中一步追问：“是这里出错了吗？” 三、第一步：将“优化一下”转化为可执行的任务 附注：图片展示了如何将模糊的需求改写为可执行的任务描述。 这是7步中最值得你投入精力的一步。需求写清楚了，后续六步大多能自动顺畅运行。 直接看一个改写示例。同一个需求，从模糊到可执行： ❌ 模糊版本（Codex一定会猜测）： `帮我修登录 bug。` ✅ 可执行版本（Codex无需猜测）： `目标：修复登录页邮箱为空时仍然提交的问题。` `范围：只修改 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提示词怎么写？模糊需求转工程任务的新手完整指南》。 四、第二步：上下文提供“最相关的两三个”，而非越多越好 Codex接到任务后，会主动寻找上下文：`AGENTS.md`、你引用的文件、错误日志、目录结构，以及它自己刚运行命令的输出。 新手容易走两个极端，两者都可能导致任务偏离： | 极端 | 表现 | 后果 | | :--- | :--- | :--- | | 提供太少 | 只说一句目标，不给出入口文件 | 它在大型项目中四处搜索，浪费时间寻找路径 | | 提供太多 | 塞入整个目录、几千行日志 | 重点信息被噪音淹没，它可能抓错重点 | 更稳妥的做法是“先提供关键证据，再让它补充查询”：你知道报错来自某个页面，就先提供页面文件和测试文件这2到3个；它如果需要更多信息，会自行搜索。这样你就能看到它为何打开新文件，也能及时判断它是否偏离了方向。 4.1 `AGENTS.md`存放长期规则，提示词存放本次任务 这里有一个新手容易混淆的概念：`AGENTS.md`是Codex每次任务开始时都会读取的项目指令文件，存放的是持久性规则——测试命令是什么、哪些目录不能动、项目使用什么框架。而本次任务的目标、范围、验收标准，属于一次性信息，应该放在提示词中。 两者切勿混淆。如果你将“今天不要运行全量测试”写入`AGENTS.md`，下周Codex可能还会记得这条临时规则，在你希望运行全量测试时依然不执行。长期文件只存放长期规则，这是上下文工程最基本的规范。 关于`AGENTS.md`如何编写、存放哪些内容，可以参考《AGENTS.md怎么写？OpenAI Codex智能体指令文件新手完整指南》；关于上下文具体该提供哪些、哪些不应提供，可以查阅《OpenAI Codex上下文工程新手指南》。 五、第三步：复杂任务先要计划，将计划视为刹车 附注：图片展示了在复杂任务中先要求计划，作为方向纠正的“刹车”机制。 对于大型任务，直接让Codex开始修改的风险在于：你还没理解它打算如何操作，它可能已经修改了五个文件。方向正确还好，方向错误则需要进行回滚。 因此，对于跨越多文件的任务，先要求它输出计划。Codex内置了规划模式，输入`/plan`或按`Shift+Tab`即可切换。OpenAI团队的实践是：对于大型改动，先用Ask模式让Codex提供实现计划，再切换到Code模式执行，这个两步流程能显著降低偏离方向的概率。 计划无需冗长，但必须回答三个问题： * 它计划先读取哪些文件。 * 它计划修改哪些代码区域。 * 它计划如何验证修改效果。 一份合格的计划示例如下： `计划：` `1. 先读取登录页代码和现有测试，确认空邮箱提交的当前行为。` `2. 在表单提交前补充客户端校验，不修改后端认证逻辑。` `3. 增加一个空邮箱验证的测试用例。` `4. 运行login相关的测试；如果失败，仅在登录页范围内继续修复。` 这份计划的优势在于边界明确。它没有说“顺便重构登录模块”，也没有说“优化用户体验”，只处理本次的bug。新手最需要的就是这种范围窄、目标明确的计划。 5.1 三种不合格的计划，看到就要求重写 | 问题类型 | 表现形式 | 为何不合格 | | :--- | :--- | :--- | | 动作描述太虚 | “分析代码、优化逻辑、提升质量” | 听起来合理，但你无法判断它具体要修改哪里 | | 范围太大 | 一个登录页bug，计划却是“重构认证模块、统一错误处理” | 这些改动或许都值得做，但不是本次任务的目标 | | 缺少验证环节 | 只有“修改”步骤，没有“如何证明修改正确” | 没有验证的计划不是工程计划，只是一份行动清单 | 六、第四步：检查工具调用是否具备“证据链” Codex会使用工具来读取文件、搜索文本、运行命令、应用补丁。你无需关注每个工具的具体名称，但要观察这些调用是否围绕目标任务展开。 一个正常的工具链，每一步都前后衔接： `读取登录页 → 发现submit逻辑 → 读取测试 → 发现缺少空邮箱用例 → 修改页面 → 补充测试 → 运行测试` 一个不正常的工具链，像是在项目中漫无目的地浏览： `读取登录页 → 跳转到修改全局auth → 又去修改样式 → 又去修改路由 → 没有解释为什么这么做` 你不需要理解所有代码，也能看出前者围绕目标推进，后者在发散。当你发现它发散时，立即打断，要求它复述： `先暂停。告诉我你现在定位到了哪一步、已经确认了什么证据、下一步为什么要查看这个文件。` 如果它能清晰说明，就允许它继续；说不清，就让它回到计划轨道上。 工具调用次数多不代表专业。它连续读取十个文件，可能是深入理解项目，也可能是没有入口文件而在瞎找。判断标准只有一个：每个文件是否与任务相关，而不是它到底读了多少个。读取登录页、表单组件、登录测试文件是合理的；但突然开始读取结算、订单、通知模块，你就应该追问一句为什么。 七、第五步：修改代码时，提前堵住“顺手改动” Codex修改代码时最容易出现一种情况：为了让问题看起来解决得更彻底，它顺手修改了相关但不必要的文件。修复一个登录bug，顺手重构了表单组件；修改一个测试，顺手调整了全局工具函数。 这不是它“恶意”，而是任务边界没有约束住。编程智能体看到相关问题时，会本能地想一起处理。人类工程师也常有这个倾向，只是人更容易意识到“这次PR（代码合并请求）不应该改动太多”。 因此，在任务描述中，要提前明确边界： `不要顺手重构，不要修改无关文件。如果发现额外问题，只记录到“后续建议”中，不要直接修改。` 这两句话虽然朴素，但非常有效。它能把Codex从“热心的同事”拉回到“本次任务的负责人”。最后一句尤其关键——Codex在执行任务时经常发现相邻问题（例如修复登录页时发现错误提示组件也不统一），这些发现有价值，但不应该在本次任务中修改。让它放入“后续建议”，既不丢失信息，也避免了扩大本次改动的范围。在实际工程中，这是控制PR质量的关键技巧。 八、第六步：验证比修改更重要，需与改动范围匹配 Codex说“已修复”并不等于真的修复。你需要查看它是如何验证的。验证分为三个层级，根据改动范围选择，并非每次都要跑全套： | 验证层级 | 适用场景 | 新手判断标准 | | :--- | :--- | :--- | | 相关测试 | 有测试文件、改动范围明确 | 至少需要运行这一层 | | 全量测试 / lint / build | 改动影响了公共模块 | 发布前运行更稳妥 | | 手工检查 | 文档、文章、UI、配置类任务 | 需要明确列出检查项 | （表中lint指代码风格与低级错误检查，build指构建，看代码能否成功编译打包。） OpenAI的Codex实践反复强调可靠测试环境的重要性，原因很简单：Codex能否自主纠错，取决于它能否看到真实的反馈，而测试输出就是最硬性的反馈。 8.1 测试失败时，先定位“第一个真实失败原因” 测试失败不是坏事，Codex会继续修改。你要观察它如何解读这个失败。 正确的处理方式是先定位第一个真实失败原因：是断言写错了、环境没启动、依赖缺失，还是代码逻辑真错。错误的处理方式是看到红色就开始胡乱修改，越改越乱。你可以直接给它一条硬性规则： `如果测试失败，先总结第一个真实失败原因，再决定是否需要修改代码。` 这一句话能防止它在失败的循环中打转。 8.2 文档、配置类任务也需要验证 并非只有代码需要验收。文章重写可以验证：H2结构是否合理、是否出现重复段落、FAQ是否基于真实问题、内链是否存在、frontmatter是否损坏。配置文件修改可以验证：能否正确解析、敏感信息是否被写入、变更范围是否符合预期。 “没有测试”不等于“不需要验证”，验证方式应跟着任务类型走。 九、第七步：一份好的汇报会告诉你“没做什么” 许多新手只关注Codex“完成了什么”。但更重要的是，它是否说清了“没做什么”和“还不确定什么”。 一份合格的汇报应包含四项内容： * 修改了哪些文件。 * 为何这样修改。 * 运行了哪些检查，结果如何。 * 哪些事没有做，或还存在什么风险。 如果它只说“已完成”，这不是交接，只是客套话。直接要求它补充： `请按“改动文件 / 验证结果 / 未处理风险 / 后续建议”四项重新汇报。` 这份汇报是你决定是否要继续信任其输出、是否提交、是否发布的依据。缺少一项，就要求它补充。Codex的最终汇报不是收尾时的礼貌性话语，它就是一张任务交接单。 十、卡住了怎么办：7步卡点排查表 附注：图片展示了一个7步卡点排查表，用于快速定位Codex卡在何处。 当Codex出现问题时，不要急着更换模型，先定位它卡在哪一步。 | 卡点表现 | 多半卡在的步骤 | 你应该如何提问 | | :--- | :--- | :--- | | 它修改了不相关的文件 | 第1步需求 / 第3步计划 | “本次任务的边界是什么？哪些文件不该动？” | | 它一直读文件但不动手修改 | 第2步上下文 | “你还缺少哪份证据？读完后准备修改哪里？” | | 它制定的计划范围很大 | 第3步计划 | “把计划压缩成只解决当前问题的3个步骤。” | | 它运行了错误的命令 | 第2步上下文 / 第6步验证 | “`AGENTS.md`里写的测试命令是什么？” | | 它反复修改一个失败的测试 | 第6步验证循环 | “总结第一个真实失败原因，不要继续盲目修改。” | | 它只报告完成，不报告风险 | 第7步汇报 | “列出没做的事和剩余风险。” | 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改完只说“已完成”，我该追问它什么？** 追问四项：改了哪些文件、为什么这么改、跑了哪些检查结果如何、有哪些没做或还有什么风险。直接要求它“按改动文件 / 验证结果 / 未处理风险 / 后续建议四项重新汇报”。最应关注后两项——它没做什么、还有什么不确定，这两项遗漏了，你会误以为任务全部清除了。

来源：互联网