很多人使用 Codex 的方式，仍然是描述一个需求，然后等待它一次性生成大量代码。这个方法在小示例里很直观，进入真实仓库以后却容易出现三个问题：改动范围失控、结果无法验证、下一轮无法接着做。

我在桌面端语音输入、实时交互原型和内容工具这些项目中，逐渐把 Codex 的任务固定成一条工程流水线。核心不是更玄学的提示词，而是让每次任务都交付“修改、证据和可继续状态”。

第一步：先读取现场，不要直接修改

第一轮先让它确认仓库状态、入口文件、调用链、已有差异和项目约束。目标是区分已经确认的事实与仍需验证的假设。

可以直接这样描述任务：

先检查仓库当前状态，定位与问题相关的入口文件和执行路径，列出已确认事实、待核验事项和潜在风险；本轮暂时不要修改。

这一步尤其适合存在未提交改动、旧模块或多入口的项目。它能减少另起一套实现、覆盖已有修改和修错层级的概率。

第二步：把目标改写成可验证终态

“优化性能”“修好页面”“完善功能”都不是可验收目标。更好的写法应该说明：用户最终能做什么、允许改哪些范围、必须保留哪些行为，以及用什么证据证明完成。

例如，不要只说“优化接口性能”，而是要求定位慢在客户端、网关、数据库还是外部服务，只修改命中的层级，保留现有回退路径，并用分段计时和回归测试证明变化。

第三步：一次只解决一个可解释问题

复杂任务先形成假设，再做最小实验。修改一处以后立即构建、测试或复现；失败时保留完整错误，再决定下一步。

一次生成十几个文件看起来进展很快，出错以后却很难知道是哪一处改变引入了回归。小步修改的价值不在于保守，而在于每一步都能解释。

第四步：让不同问题使用合适的高层工具

仓库问题查看代码、差异和测试；界面问题进入真实预览；接口问题核对官方文档；数据问题读取真实表格或导出。不要让模型只凭记忆猜测正在变化的接口，也不要用低层脚本硬操控本来就有稳定入口的应用。

OpenAI 当前文档分别提供了生产系统、代码审查、Skills 与集成终端等工作流入口。这里借鉴的是“从真实状态出发、用验证证据收尾”的工程方法，不把任何具体能力或页面入口当作固定不变。工具数量不是重点，重点是每一步都能读取真实状态并产生可检查证据。

第五步：明确保护现场的约束

真实项目里，避免破坏往往比多写代码更重要。任务中应该明确要求：修改前检查现有差异，不清理无关文件，不覆盖用户改动，不执行未经授权的破坏性命令；小补丁能够解决时，不重写整个模块。

如果仓库已经有规范文件，还应该先读取其中的构建命令、目录边界、签名配置和安全要求。任务约束越靠近项目，越不容易在跨轮次协作时丢失。

第六步：把失败日志变成下一轮输入

“还是不行”几乎没有诊断价值。更有效的输入应包括执行命令、退出码、关键错误、已经排除的原因和最近一次改动。

如果连续重复同一种尝试，可以要求它暂停修改，列出三个互斥假设，并为每个假设写出最小证伪步骤。这样失败不会变成无休止重试，而会变成新的工程证据。

第七步：留下可接力的任务简报

长任务最怕下一轮重新理解现场。一份最小简报只需要记录六项：目标、已确认事实、已改文件、验证结果、剩余风险和下一步。

长期项目规范放进仓库说明，单次任务状态留在任务简报。这样换一轮对话或切换执行者时，可以从现有证据继续，而不是重新猜测。

可直接复用的任务模板

先读取当前状态和约束，定位相关执行路径；列出风险与待核验事实；提出最小修改方案并实施；运行与风险相匹配的验证；失败时保留证据并调整假设；完成后汇总修改文件、验证结果、剩余风险和下一步。保护已有改动，不处理任务范围外的文件。

交付前检查清单

一、是否说明修改了哪些文件以及为什么修改。

二、是否运行了与风险相匹配的构建、测试、预览或数据检查。

三、是否保留失败日志，而不是只给一句“已修复”。

四、是否区分已经验证的事实和仍未验证的判断。

五、是否留下下一轮能够直接继续的状态。

六、是否保护已有修改和任务范围外的文件。

如果只保留一个原则，那就是不要让 Codex 只交付代码。让它交付可审查的修改、可复现的验证证据，以及别人能够继续工作的现场，才是最稳定的效率来源。

参考资料

OpenAI Codex 文档：https://learn.chatgpt.com/docs

OpenAI ChatGPT/Codex 用例：https://learn.chatgpt.com/use-cases

作者：Julian Cooper

创作说明：本文由作者基于真实项目协作流程撰写，使用 AI 辅助整理，作者对事实和内容负责。