多轮协作技巧：引导 Codex 完成复杂任务
单轮不够用的场景
| 任务类型 | 单轮能搞定？ | 为什么需要多轮 |
|---|---|---|
| 改一行文案 | ✅ | — |
| 修一个有明确复现步骤的 Bug | ✅ | — |
| 新功能（含测试 + 文档） | 🔶 | 实现 → 补测试 → 补文档，每轮聚焦一件事更好 |
| 接手陌生代码库做分析 | 🔶 | 先全局扫描 → 再深入关键模块 → 最后输出报告 |
| 多文件重构 | ❌ | 先规划 → 分步执行 → 验证 → 收尾 |
| 技术方案设计 | ❌ | 调研 → 对比 → 写方案 → 评审 → 修改 |
复杂任务不是一条超长提示词，而是多轮有节奏的协作。每一轮有明确的目标，轮与轮之间有校准点。
多轮协作的三种模式
| 模式 | 适用场景 | 操作方式 | 优势 | 风险 |
|---|---|---|---|---|
| 渐进式 | 连续迭代，上轮输出是下轮输入 | 同一线程追加提示词 | 上下文连续，不需要重复 | 上下文膨胀，后期可能变慢 |
| 引导式 | Codex 正在执行，但你想介入调整方向 | 用引导提示（插队）打断当前执行 | 实时纠偏，避免浪费 | 打断可能丢失中间状态 |
| 委派式 | 耗时任务，你想并行做其他事 | 本地规划 → 云端执行 | 不阻塞你的工作 | 需要把规划写清楚，否则云端跑偏 |
渐进式——同一线程内追加
最常见的方式。每轮追加一条提示词，Codex 基于之前的上下文继续工作。
# 第 1 轮
分析 src/features/auth/ 模块的结构，列出核心文件和数据流。
# 第 2 轮（在同一个线程）
基于刚才的分析，重构 auth middleware，把 session 校验逻辑拆成独立的 middleware。
# 第 3 轮
补上重构引入的新逻辑的单元测试。
引导式——介入正在执行的任务
当 Codex 正在执行但你发现方向偏了，可以发一条引导提示：
# Codex 正在重构 auth 模块，但你发现它在改你不希望改的文件
等一下，不要改 src/features/auth/legacy/，那个文件保持不动。
只重构 src/features/auth/core/ 下的文件。
委派式——本地规划，云端执行
适合耗时较长的任务。先在本地用 /plan 让 Codex 产出计划，确认后将任务委派到云端。
# 本地：规划阶段
/plan 将 src/utils/date.ts 重构为独立的 @packages/date-utils 包。
列出所有步骤、涉及文件、潜在风险。
# 确认计划后：委派到云端
# 在 Codex App 中点击"发送到云端"，或在 CLI 中使用 cloud 命令
交叉引用：关于本地线程和云端线程的基础概念，参见 Codex 提示词 | 线程与上下文。
续线程 vs 开新线程 vs 委派的决策树
| 判断条件 | 结论 | 理由 |
|---|---|---|
| 下一轮依赖上一轮的上下文？ | 续线程 | 不需要重复背景信息 |
| 下一轮和上一轮改同一批文件？ | 续线程（但要确认无冲突） | 同线程能感知已有改动 |
| 下一轮和上一轮完全无关？ | 开新线程 | 避免无关上下文污染 |
| 当前线程已经很长（>20 轮）？ | 开新线程 | 上下文窗口可能快满了 |
| 任务耗时 >10 分钟？ | 委派到云端 | 不阻塞你的工作 |
| 任务需要并行执行多个独立子任务？ | 委派多个云端线程 | 并行效率更高 |
两条线程不要改同一批文件。 即使是云端线程，如果两个线程同时修改同一个文件，合并时可能冲突。委派前确认每个线程的文件边界不重叠。
多轮引导的三个阶段
第一阶段：锚定方向（30 秒）
用第一条提示词建立上下文和约束。这一轮的目标是"让 Codex 知道大方向"，不是"让 Codex 做完所有事"。
分析 src/features/checkout/ 的完整流程，包括：
1. 入口页面和路由
2. 核心组件和数据流
3. API 调用链
4. 当前存在的问题
输出一个结构化分析报告，不要改任何代码。
第二阶段：阶段性校准（每轮结束前）
每一轮结束前，花 30 秒检查 Codex 的输出，确认方向正确后再继续。
# 检查完 Codex 的分析报告后
分析到位。现在基于你的分析，设计一个重构方案：
1. 把 checkout 流程拆成 3 个独立步骤（购物车确认 → 收货地址 → 支付）
2. 每个步骤一个独立组件
3. 共享状态提升到 checkout context
先输出重构计划，确认后再写代码。
第三阶段：收尾与验证（最后 1 分钟）
最后一轮用来汇总和验证，对照验收标准检查。
重构代码已确认。现在：
1. 运行 `pnpm test -- --filter=checkout`，确保所有测试通过
2. 运行 `pnpm typecheck`，确保无类型错误
3. 列出所有改动的文件和改动摘要
4. 如果有改动不符合验收标准的地方，指出来
引导提示的时机与写法
| 时机 | 用什么 | 示例 |
|---|---|---|
| Codex 方向偏了，需要修正 | 引导提示（插队） | "等一下，不要改 X 文件，只改 Y" |
| Codex 完成了当前步骤，你要追加下一步 | 普通提示词 | "现在补上测试" |
| 你想补充约束，但不想打断执行 | 在下一轮开头说明 | "补充一个约束：不要用 any 类型" |
| 你想了解进展，但不想改变方向 | side chat（如果支持） | "目前改了哪些文件了？" |
三种引导提示模板：
方向修正：
等一下。[具体纠正内容]。
之前的方向继续有效，只需要调整 [具体调整点]。
补充约束：
补充一个约束：[约束内容]。
这个约束对当前任务和后续步骤都适用。
紧急中断：
暂停当前任务。[原因]。
[新的指令]。
反模式
| 反模式 | 问题 | 改进 |
|---|---|---|
| 无限续线程 | 上下文膨胀，Codex 开始"遗忘"早期约定 | 每 10-15 轮检查上下文余量，必要时开新线程 |
| 频繁开关线程 | 每次都重复背景信息，浪费时间 | 相关任务保持在同一线程 |
| 不审查就继续 | Codex 的错误累积到后面更难修 | 每轮结束前花 30 秒检查 |
| 方向漂移不修正 | Codex 越跑越远，最终产出不可用 | 用引导提示及时纠偏 |
验证清单
- 每轮任务有明确目标，不是"随便改改"
- 每轮结束前检查了 Codex 的输出
- 知道什么时候该续线程、什么时候该开新的
- 长任务用了阶段性校准，不是一口气跑到底
- 委派到云端的任务有清晰的规划（用 /plan 产出的）
FAQ
Q：一个线程最多跑多少轮合适？
没有硬限制，但建议在 15-20 轮左右开始关注上下文余量。Codex 会显示剩余上下文空间。如果发现 Codex 开始"遗忘"早期约定或重复之前的工作，就该开新线程了。
Q：委派到云端和本地继续跑有什么区别？
云端线程不占用你的本地资源，可以并行做其他事。但云端需要你提前把规划写清楚——它不会像本地线程那样和你频繁交互。简单的经验法则：如果你需要频繁校准方向，留在本地；如果方向明确、只需要执行，委派到云端。
Q：两个线程能不能改同一个项目的不同文件？
可以，但要确保文件边界不重叠。如果两个线程可能改到同一个文件（比如共享的配置文件、类型文件），就不要并行。参见 Codex 提示词 | 线程与上下文 中关于并发线程的说明。
平台能力、套餐限制以 OpenAI Codex 官方文档为准；本文写于 2026-06-24。
选读建议：多轮协作的底层挑战是上下文管理——→ 从提示词到上下文工程 会系统讲解上下文管理的思维框架。如果你想直接看多轮协作在真实场景中的完整用法——→ 提示词实战案例库。