Codex 总是跑偏：先缩小任务边界，再补上下文
从目标、范围、现状证据和验收方式逐项排查，让 Codex 从‘大概对’回到可检查的任务轨道。
最常见的“跑偏”不是完全没做，而是做了很多，结果却不是你要的。比如只想改一个错误提示，却连组件结构一起重构；想修一个失败测试，却新增了与根因无关的兼容分支。
先看是哪一种跑偏
| 现象 | 先检查什么 |
|---|---|
| 改了不该改的文件 | 任务是否写明允许修改的目录和禁止范围 |
| 理解错现有行为 | 是否给了真实错误、复现步骤、请求或截图 |
| 只做了表面修复 | 是否要求先说明根因和影响路径 |
| 结果看起来对但不能用 | 是否在开始前定义验收命令或可见结果 |
| 一直反复修补上一轮 | 当前对话是否混入了已经作废的方案 |
用五分钟重置任务
- 停止继续修改，先让 Codex 只读检查现状。
- 用一句话写最终结果，不先写实现方案。
- 列出可以修改、不能修改的范围。
- 附上一份真实证据：错误日志、URL、截图、请求体或失败测试。
- 先定义验收方式，再让它实施。
可以直接使用的任务模板
目标：[用一句话写用户最终能看到的结果]
现状证据：
- [错误日志 / 请求 ID / URL / 截图 / 失败测试]
范围：
- 可以修改：[目录或模块]
- 不要修改：[公开 API、数据库、无关页面等]
执行方式：
1. 先只读定位实际运行路径和根因。
2. 说明最小修改方案后直接实施。
3. 运行 [验证命令]。
4. 总结根因、改动、验证结果和未验证风险。
上下文要精准，不要堆满
不需要一次性上传整个项目的所有文件。对多数排障任务，优先级更高的是：
- 能稳定复现问题的证据。
- 与这份证据对应的真实代码路径。
- 项目里已经存在的相似实现。
- 最后用来判断成功的命令或页面行为。
什么时候应该开新任务
如果目标已经改变、前面的方案已经作废，或当前对话里同时混着多个无关问题，开一个新任务通常更容易重新建立边界。新任务不要只写“继续修”，而要把上面的目标、证据、范围和验收方式重新写清。
完成检查
- 最终 diff 中没有无关文件。
- 实际改动与根因一致，不是只遮住表面现象。
- 开始时写下的验收方式已经执行。
- 无法验证的地方被明确记录，没有被当成“已完成”。