Ask / Plan / Execute：让 Codex 先想清楚再动手
TL;DR
Codex 不应该永远直接执行。更可靠的团队策略，是在 Ask、Plan、Execute 三种授权节奏之间切换。Ask 用来只读理解和澄清事实；Plan 用来设计路径、暴露风险、列验证方式；Execute 用来在明确边界内修改文件、运行命令并交付可 review 的结果。
Ask / Plan / Execute 不是 OpenAI 官方文档中的固定产品模式，而是一套工程协作约定。它和 Codex 的沙箱、审批、AGENTS.md、任务 brief、CLI / App / Cloud 入口配合使用。任务越模糊、影响越大、权限越敏感，就越应该先 Ask 或 Plan。只有目标、范围、权限和验收都清楚时，才适合直接 Execute。
这个策略的核心是渐进授权：先让 Codex 花便宜的只读成本建立事实，再让它给出可审查计划，最后才给写权限和命令权限。它不能保证没有错误，但能显著减少过早动手带来的无效 diff。
读者定位
本文面向已经把 Codex 用于真实工程任务的开发者、Tech Lead、项目维护者和工程平台负责人。你可能遇到过这些问题：Codex 在还没理解需求时改文件；计划写得漂亮但漏掉验证；执行中发现新风险却继续扩大范围；多轮追加需求导致 diff 无法 review。
如果你正在设计团队 Codex 使用规范，Ask / Plan / Execute 可以作为默认授权语言。它比“谨慎使用 AI”更具体，也比“一律先计划”更灵活。
问题：过早 Execute 是多数失控任务的起点
很多人使用 Codex 的默认方式是：发一句任务，等待修改完成。小任务可以这样做，比如修文档链接、改 typo、补一个明显测试。但复杂任务不行。
复杂任务通常有这些特征：
- 目标描述不完整。
- 相关文件不明确。
- 可能影响公共 API、权限、账单、迁移或 CI。
- 需要跑命令、访问网络、安装依赖或改配置。
- 验证方式不清楚。
- 仓库里已有用户或其他 worker 的改动。
在这些条件下直接 Execute，Codex 会一边理解一边改。人类工程师也很少这样工作。你不会让同事不读需求、不确认风险、不看测试就改认证核心逻辑。Codex 具备执行能力，所以更应该先建立事实和计划。
过早 Execute 的成本通常不是一次失败，而是一组难审查的 diff：有些修改解决问题，有些修改是猜测，有些修改是顺手清理，有些测试没跑，有些风险没说明。后续 review 需要先拆解它做了什么，再判断哪些能保留。
心智模型：三种授权，不是三种语气
Ask、Plan、Execute 的区别不是礼貌程度，而是授权范围。
Ask：授权读取和分析，不授权修改
Ask 适合信息不足、目标不清、需要建立事实的任务。它的产物是解释、文件列表、调用链、风险清单、问题列表。Ask 阶段默认不改文件，也不运行有副作用命令。
典型 Ask：
先不要修改文件。请阅读 src/auth 下的登录流程，回答：
1. 登录入口在哪里？
2. session 在哪里创建和刷新？
3. 哪些分支可能导致刷新后登出？
4. 现有测试覆盖了哪些路径？
最后列出你建议下一步调查的文件。
Ask 不是让 Codex闲聊，而是让它建立可核对事实。
Plan：授权设计路径，不授权执行
Plan 适合目标明确但路径复杂的任务。它的产物是将读取和修改的文件、步骤、验证命令、风险、停靠点、可能需要审批的动作。Plan 阶段可以读文件，但不改文件，除非你明确允许。
典型 Plan：
目标是把订单导出的空结果从 500 修成空 CSV。
请先给修改计划：会读哪些文件、预计改哪些文件、需要补哪些测试、
运行什么命令验证、哪些风险需要我确认。
不要修改代码，等我确认。
好的计划不是“先分析，再修改，再测试”。它应该点名文件、命令、风险和停靠点。
Execute：授权按边界交付
Execute 适合目标、上下文、约束、验收都清楚的任务。它允许 Codex 编辑文件、运行命令、根据失败做小范围修复，并最终汇报结果。Execute 不是无限授权；它必须遵守任务 brief、AGENTS.md、沙箱和审批。
典型 Execute：
按刚才确认的计划执行。只修改 src/orders/export.ts 和 tests/orders/export.test.ts。
不要改变 CSV 字段顺序，不引入新依赖。
运行 pnpm test -- tests/orders/export.test.ts。
最后汇报 diff 摘要、测试结果、未运行检查和剩余风险。
Execute 中如果发现计划外风险，应该停下说明，而不是自行扩大范围。
详细机制：渐进授权怎样和 Codex 配合
Codex 的官方机制提供了执行和安全基础，Ask / Plan / Execute 提供任务节奏。
沙箱控制技术权限。比如 read-only + on-request 很适合 Ask；workspace-write + on-request 适合执行受控本地修改；read-only + never 适合非交互只读检查。渐进授权不应只写在 prompt 里，也要匹配实际沙箱。
审批控制越界动作。Plan 阶段如果需要联网、安装依赖、写出工作区，应列为待审批动作。Execute 阶段遇到审批请求时，人要检查它是否在计划内。计划之外的审批请求通常应先拒绝并要求解释。
AGENTS.md 提供长期规则。Ask / Plan / Execute 不需要每次重复团队通用安全边界；但本次任务的特殊边界要写清。例如 AGENTS.md 已写“不运行 deploy”，本次 prompt 还可以补充“不要修改 GitHub Actions”。
入口影响节奏。CLI 适合实时 Ask 和 Plan；App 适合多线程 Ask；Cloud 适合计划清楚后的异步 Execute；IDE 适合局部 Ask 和小范围 Execute。入口选择不改变策略，只改变反馈回路。
Done-when 决定停点。Ask 的 Done-when 是输出事实和问题；Plan 的 Done-when 是输出可批准计划；Execute 的 Done-when 是 diff、命令、结果、风险。不同阶段不要混用完成标准。
决策表：什么时候用哪种模式
| 场景 | 推荐节奏 | 原因 |
|---|---|---|
| 不知道问题在哪里 | Ask | 先建立事实，避免改错方向 |
| 知道目标但影响范围不清 | Plan | 先暴露文件、风险和验证方式 |
| 小范围 bug，有测试，有明确路径 | Execute | 直接交付更省时间 |
| 涉及 auth、billing、permissions | Ask -> Plan -> Execute | 风险高，需要停靠点 |
| 数据库迁移、CI、部署、secrets | Ask 或 Plan 起步 | 需要审批和回滚策略 |
| 文档 typo、链接修复 | Execute | 低风险，验收简单 |
| 性能优化 | Ask -> Plan -> Execute | 必须先找基准和热点 |
| 大规模重构 | Ask -> Plan，分批 Execute | 降低不可 review diff |
这张表不是硬规则。关键是把任务风险和授权阶段对齐。
真实工作流案例：认证问题的渐进处理
假设线上出现“用户刷新页面后偶尔登出”。不要直接要求修复。先 Ask：
先不要修改文件。请阅读 src/auth、src/session 和 tests/auth。
输出登录入口、session 创建和刷新路径、cookie 写入点、登出路径、现有测试覆盖。
列出最可能导致刷新后登出的三个原因和对应证据。
你读完结果后，让 Codex Plan：
基于刚才的分析，请给修复计划。
计划要包含预计改动文件、测试场景、验证命令、不会触碰的边界。
不要修改代码。若需要改公开 API 或权限逻辑，请标为需要人工确认。
计划通过后 Execute：
按确认计划执行。
只修改 src/auth/session.ts 和 tests/auth/session.test.ts。
不改公开 API，不改权限逻辑，不引入依赖。
运行 pnpm test -- tests/auth/session.test.ts。
最后汇报 diff、测试结果、未运行检查和剩余浏览器手动验证点。
如果执行中 Codex 发现根因在权限中间件，不在 session 文件，就应该停下：
我发现需要修改 src/auth/permissions.ts，超出当前授权范围。
原因是 session 修复无法覆盖权限中间件清空 cookie 的分支。
建议先扩展计划或由人工确认。
这就是渐进授权的价值：发现新事实时回到 Plan，而不是继续扩大 Execute。
操作清单：把策略写进团队规范
- 在任务模板里加入模式字段：Ask、Plan 或 Execute。
- Ask 任务必须写“不要修改文件”，必要时写“不要运行命令”。
- Plan 任务必须输出预计文件、步骤、验证命令、风险和审批点。
- Execute 任务必须包含 Goal、Context、Constraints、Done-when。
- 高风险模块默认从 Ask 或 Plan 开始。
- 执行中发现越界需求时，要求 Codex 停下说明，不自行扩大范围。
- 审批请求要和计划对照，不在计划内的动作先拒绝。
- 最终摘要必须包含修改文件、命令结果、未运行检查和剩余风险。
- 多轮追加需求时，优先完成当前任务，再开新任务，避免 diff 混杂。
权衡与风险
Ask / Plan / Execute 会增加前置时间。对低风险任务，这可能不划算。团队不应把所有任务都强制三段式，否则会降低使用意愿。
但对高风险任务，前置时间通常能减少返工。尤其是权限、账单、迁移、CI、性能、跨模块重构，先让 Codex 说明事实和计划，可以避免它在错误方向上改很多文件。
这套策略依赖人类判断计划质量。Codex 可能给出看似完整但漏掉关键约束的计划。技术负责人要看计划是否包含验证、边界、回滚或停靠点，而不是只看步骤数量。
还有一个风险是“计划确认疲劳”。如果每个小任务都要人工确认计划，团队会开始机械批准。更好的做法是按风险分级：低风险直接 Execute，中风险 Plan 后执行，高风险 Ask 起步。
常见误区
误区一：Ask 写得像 Execute。“看看有没有问题”容易被理解为可以顺手修。要明确“不要修改文件，只输出分析”。
误区二：Plan 太抽象。“先分析、再修改、再测试”没有审查价值。计划要点名文件、测试命令、风险和停靠点。
误区三：Execute 中不断加需求。执行阶段追加无关目标，会让 diff 难审。完成当前任务后开新任务。
误区四：计划通过后不看结果。Plan 降低风险，不替代测试和 review。执行结束仍要读 diff、看命令结果。
误区五：只靠 prompt 控制权限。Ask / Plan / Execute 是任务约定，沙箱和审批才是硬边界。两者要一起用。
团队落地：渐进授权的制度化
Ask / Plan / Execute 要想稳定生效，不能只靠开发者临时提醒 Codex。团队可以把它制度化成任务状态和审批语言。每个 Codex 任务在开始时标明当前阶段，阶段变化需要明确授权。这样人类、Codex、CI 和 review 流程都能看懂当前任务允许做什么。
第一种做法是在任务标题或首行标记阶段。例如 [Ask] 分析登录刷新后登出原因、[Plan] 订单导出空结果修复方案、[Execute] 按确认计划修复 CSV 空结果。这个小标记能减少误解。Codex 看到 Ask 时默认只读，人类看到 Execute 时知道要重点审查 diff 和命令结果。
第二种做法是把阶段和沙箱匹配。Ask 使用 read-only，Plan 可以 read-only 或 workspace-write 但不编辑，Execute 使用 workspace-write 加 on-request。不要在 Ask 阶段给高权限，再靠一句“不要修改”维持边界。Prompt 约束和工具权限一致，才是真正的渐进授权。
第三种做法是阶段转换需要产物。Ask 结束应有事实清单和问题；Plan 结束应有预计改动文件、验证命令和风险；Execute 结束应有 diff、命令结果和剩余风险。没有合格产物，不进入下一阶段。例如 Ask 没找清入口，就不应让它 Plan；Plan 没写验证命令，就不应 Execute。
第四种做法是审批请求要绑定阶段。在 Ask 阶段，任何写文件请求都应被视为异常；在 Plan 阶段，写文件请求应被拒绝，但可以允许只读命令；在 Execute 阶段，计划内命令可以批准，计划外命令要回到 Plan。审批不再是孤立弹窗，而是对照当前阶段的授权检查。
第五种做法是把“发现新风险”定义为回退条件。Codex 执行中如果发现需要改计划外文件、触碰高风险模块、访问网络、安装依赖、修改公共接口、更新迁移，就应该停下，输出新事实和建议计划。团队要奖励这种停下，而不是要求它“自己搞定”。可靠代理不是永远不停，而是知道什么时候不能继续。
第六种做法是处理多轮追加需求。开发者经常在 Execute 过程中想到新要求。规范应要求：如果新要求和当前 Goal 强相关，可以补充 Constraints；如果是新目标，结束当前任务后另开任务。这样能避免一个线程从修 bug 滑到重构、再滑到补文档、最后生成难以 review 的混合 diff。
第七种做法是用复盘强化阶段感。任务失败后，记录失败发生在哪个阶段：Ask 没读到关键文件，Plan 漏验证，Execute 越界，审批误批。不同阶段的修复方式不同。Ask 失败要补 Context，Plan 失败要改计划模板，Execute 失败要收紧 Constraints 或权限，审批失败要训练人类审查请求。
最后，渐进授权要和速度平衡。不是所有任务都要三阶段完整走完。团队可以定义默认路径：低风险任务 Execute；中风险任务 Plan -> Execute；高风险任务 Ask -> Plan -> Execute。真正的成熟不是流程最多，而是授权恰好匹配风险。
反例分析：阶段混乱时会发生什么
Ask / Plan / Execute 的失败，常常不是因为概念难，而是因为阶段边界被混用。看几个反例，就能知道为什么要把授权说清。
第一种反例是 Ask 阶段偷偷执行。任务写“看看登录问题”，Codex 读着读着开始改 session 文件。开发者本来只是想了解现状，却得到一个未经授权的 diff。避免方法很明确：Ask 任务第一句写“不要修改文件”，并使用只读权限。
第二种反例是 Plan 阶段计划空洞。Codex 输出“先分析代码，再修改问题，再运行测试”。这不是计划，只是流程口号。有效计划必须列出预计文件、修改点、测试命令、风险和停靠点。没有这些信息，就不应该进入 Execute。
第三种反例是 Execute 阶段重新探索。Codex 已经被授权修改两个文件，但执行中发现另一个模块可能相关，于是继续扫描并改动更多文件。探索本身没错，但阶段错了。发现新范围时应停下，回到 Plan，让人确认是否扩权。
第四种反例是人工审批破坏阶段。Ask 阶段 Codex 请求写文件，人类随手批准；Plan 阶段请求安装依赖，人类也批准。这样阶段标记失去意义。审批要对照当前阶段，而不是对照“这个命令看起来能不能跑”。
第五种反例是 Execute 中追加新目标。原本修导出空结果，中途又要求顺便整理导出字段命名，再补文档，再调性能。最后 diff 混杂，reviewer 很难判断每个改动是否必要。正确做法是完成当前 Goal，再开新任务。
第六种反例是阶段产物不可审查。Ask 结束没有文件列表，Plan 结束没有验证命令，Execute 结束没有测试结果。看似走了三阶段，实际每阶段都没有可用证据。阶段不是仪式，每个阶段都要有产物。
第七种反例是低风险任务过度流程。修一个拼写错误也要求 Ask、Plan、Execute，开发者会觉得流程碍事，最终绕开规范。渐进授权要按风险使用。低风险任务可以直接 Execute，只要 Done-when 清楚即可。
第八种反例是把 Plan 当承诺。Codex 给出计划后，执行仍可能遇到新事实。计划是降低风险，不是保证成功。团队要允许执行中回退到 Plan，也要要求 Codex说明为什么计划变化。
这些反例说明，Ask / Plan / Execute 的核心不是多几轮对话，而是把授权边界放到正确时刻。只读事实、可审查计划、受控执行，三者分开后，Codex 的错误更早暴露，人的介入也更有针对性。
阶段产物模板
团队可以把每个阶段的产物格式固定下来，减少沟通成本。
Ask 阶段的产物应包含：已阅读文件、关键事实、调用链、现有测试、风险点、不确定问题、建议下一步。不要包含未授权 diff。若 Codex 认为必须修改才能确认问题，应说明理由，而不是自行修改。
Plan 阶段的产物应包含：目标复述、预计修改文件、不会修改的边界、步骤、验证命令、审批请求、回滚或停靠点、需要人工确认的问题。计划要足够具体，能让 reviewer 判断是否批准执行。
Execute 阶段的产物应包含：修改文件、核心改动、验证命令和结果、未运行检查、失败处理、剩余风险、人工验证建议。若执行过程中偏离计划，应单独说明偏离原因。
阶段转换也可以模板化。Ask 到 Plan 的条件是事实足够清楚，至少知道入口和主要风险。Plan 到 Execute 的条件是修改范围、验证方式和审批点清楚。Execute 到完成的条件是 Done-when 达成，或者未达成项有明确说明。
当任务卡住时，也要按阶段处理。Ask 卡住，多半是 Context 不足；Plan 卡住，多半是目标或边界冲突；Execute 卡住，多半是环境、权限或测试失败。不同卡点用不同解决方式，不能一律要求 Codex“继续试”。
这种产物模板能让团队快速扫描任务状态。看到 Ask 摘要就知道是否进入计划，看到 Plan 就知道是否授权，看到 Execute 摘要就知道是否 review。Codex 不再是一个黑盒对话，而是一条有状态的工程流水线。
实际落地时，模板不必很长。关键是每阶段都留下证据。没有证据的 Ask 是闲聊，没有文件和命令的 Plan 是愿望清单，没有验证的 Execute 是未完成 diff。把证据作为阶段出口，渐进授权才有意义。
阶段策略也适合多 worker 场景。多个 Codex 同时工作时，Ask 线程可以并行调查不同方向，但 Execute 线程必须隔离分支或目录。Plan 阶段要说明和其他任务是否可能冲突。执行前确认当前工作区里哪些改动属于自己，哪些属于别人。这样能避免一个代理覆盖另一个代理的半成品。
渐进授权还适合教学。新成员第一次用 Codex，不要让他从高权限执行开始。先让他做 Ask，学会判断 Codex 是否读对文件；再让他做 Plan，学会审查步骤和风险；最后做小范围 Execute，学会看 diff 和测试结果。这个训练路径能让开发者理解代理协作，而不是只学会发命令。
在长期项目中，阶段策略会逐渐沉淀为默认语言。开发者说“先 Ask 一轮”，团队就知道不改文件；说“给 Plan”，就知道要等确认；说“按计划 Execute”，就知道需要 diff 和验证结果。这种共同语言比复杂流程图更有用。
如果阶段执行得好，最终会减少会议和反复解释。Ask 产物让事实对齐，Plan 产物让方案对齐，Execute 产物让结果对齐。三次对齐都留下文本证据，后续 review、复盘和交接都会更轻。
这套语言也能帮助管理预期。人类看到任务仍在 Ask，就不会期待当天合并；看到进入 Execute，就知道要准备审查真实改动。
阶段清楚，协作节奏才清楚。
这种节奏还会降低心理负担。开发者不必一次决定是否完全信任 Codex，只要决定下一阶段授权什么、验证什么、在哪里停下。
延伸阅读
GitHub 原文：07-ask-plan-progressive-strategy.md