Codex计划模式怎么用？plan梳理范围、检查依据与实施前验收

需求说“优化登录”，Codex若直接开始改文件，可能把你只想讨论的方案扩成重构。CLI的/plan可将当前聊天切到计划模式，用于先调查和组织方案。本文以登录回跳练习为例，要求把目标、证据、未知项与验收分开，先检查计划是否可执行，再决定下一步，不把一张清单当成已经完成的开发。

第一步：在空闲聊天中进入plan

在当前Codex CLI等待输入时输入/plan并回车，也可直接附上计划问题。官方说明Codex正在工作时该命令暂不可用；先等当前操作结束，不把发送计划命令当作停止后台进程。网页或其他产品的同名入口也不能直接等同于这里的CLI行为。

/plan 只读调查练习项目登录后回跳异常。先解释实际调用路径与已知证据，再给最小修改计划。暂不改文件、不安装、不部署；找不到复现条件时列出缺口，不猜根因。

计划模式是工作方式，工具权限和执行边界仍由实际配置与组织策略控制。你要求只读时也应检查有没有意外文件变化，不把模式名称当完整安全隔离。开始前确认目录与分支，保存已有改动，便于区分本次调查和原先工作。

第二步：给计划提供可验证输入

描述触发条件、实际结果、期望结果与不能修改的范围。若有日志或截图，只提供必要且已脱敏的部分。比如回跳问题要说明从哪个页面登录、是否带return参数、成功后落在哪，不只说“登录不对”。输入含糊时，计划再详细也可能针对错误场景。

练习现象：从受保护页面进入登录，成功后回首页而非原页面。
目标：保留合法站内回跳。
边界：不改支付、账号权限和外部跳转策略。
验收：正常站内地址、缺少参数、无效或外站地址三类。
请区分我提供的现象、你读取代码得到的事实与待验证推测。

这是一份练习模板，不代表你的项目一定有这些参数。让Codex依据真实仓库找入口，计划中引用的文件、函数和命令必须确实存在。没有测试框架时应如实说明验证方法，不凭空列一个会成功的测试命令。

第三步：检查计划的范围与顺序

有用的计划应解释改哪几个位置、为什么改、影响什么以及如何验证，不必罗列几十个微步骤。先安排复现和现状确认，再修改与验证。若计划把一次回跳修复扩成认证框架重写，应要求收窄，避免无关改动增加评审负担。

请复核方案：每个拟改文件对应哪条证据？是否能用更小范围解决？哪些结论尚未验证？将“已读取事实”“拟执行动作”“验收标准”分开，删除与目标无关的重构，不把计划里的测试写成已经通过。

同一问题可能有多种做法，比较实际取舍即可，不让模型为显得全面而虚构多个方案。若必须作业务决定，例如无效回跳应该去哪里，由你确认后再更新计划，不能用程序员偏好替代产品要求。

第四步：确认实施边界再进入执行

读完计划后，按当前CLI界面支持的方式回到实施流程，并发出明确范围的请求。不要把“计划看起来不错”自动解释成发布、提交或变更线上权限的授权。需要的工具许可继续按现有设置处理，计划文本不能取消组织审批。

按已核对的最小方案处理练习项目，仅修改列出的登录相关文件。先检查当前状态是否与计划一致；若出现新证据导致范围扩大，先说明。完成后列出实际改动、已运行检查及结果、未验证项，不部署或对外提交。

第五步：把结果对照计划验收

检查真实差异和验证输出，确认解决原场景并保留原有边界。某一步没执行就标未执行，测试失败不能用“预计正常”替代。若当前代码已被其他人更改，先修订计划依据，不强行把旧方案套回新版本。

完成标准是计划有证据、实施有范围、结果可核对。只需要讨论时停在方案即可；准备实施时才明确推进。这样/plan解决的是先理解再决策的问题，不是把同一段模糊需求换成更多文字。

官方资料

资料核对日期：2026年11月8日。

• OpenAI：Developer commands
• OpenAI：Approvals and security