Codex 修改范围失控怎么收回来

这类问题在真实使用里非常常见。

你本来的任务可能只是：

• 改一个按钮
• 修一个文案
• 调一个间距
• 修一个小 Bug

结果 Codex 顺手：

• 改了多个页面
• 动了公共组件
• 重构了无关代码
• 修了历史问题
• 连配置都一起动了

这就叫：

修改范围失控

这不是它“完全做错了”，而是任务边界没被及时拉住。

前置教程：怎样写一个合格的 Codex 任务
如果你还没有建立“目标、范围、禁止事项、验收标准”这套任务写法，先完成前置教程。

依据来源：OpenAI Codex 官方手册中关于 prompting、best practices、review、diff、approvals 和工作流收口的说明。

本篇目标

学完后，你应该能做到：

1. 识别 Codex 什么时候已经开始改多了。
2. 知道第一步应该停，而不是继续让它修。
3. 知道如何让它区分“本次必需改动”和“顺手改动”。
4. 知道如何把任务重新缩回最小范围。
5. 知道怎样避免第二次再失控。

最危险的错误动作是什么

最危险的不是“它改多了”本身。

最危险的是你在它已经跑偏之后，还继续说：

那你再修一下
那你顺便也处理了吧
那你把它一起优化了

这样会让失控范围越来越大。

所以第一原则是：

一旦怀疑改动超范围
先停

什么现象说明它已经开始失控

1. 改动文件数量明显超出预期

你本来只预期改 1 到 2 个文件，结果它动了 6 个、10 个，甚至更多。

2. 动到了公共层

例如：

• 全局样式
• 公共组件
• 通用工具
• 路由配置
• 构建配置

而你本来只是做局部任务。

3. 把历史问题也一起修了

它常常会觉得：

顺手一起修更完整

但对用户来说，这通常是扩大范围。

4. 它开始解释“为了让结果更一致，我额外做了……”

这句话往往是范围变大的信号。

第一步：立刻切到只读检查

一旦你觉得它改多了，不要继续让它写文件。

直接发这段：

先不要继续修改文件。

我怀疑你刚才的改动已经超出本次任务范围。

请先只读检查：
1. 你刚才一共修改了哪些文件。
2. 哪些文件是本次任务必需的。
3. 哪些文件属于顺手修改或扩大范围。
4. 你为什么会认为这些额外修改有必要。
5. 先不要继续修，只做范围说明。

这一步的目的不是立刻回滚，而是先把“超出范围的部分”说清楚。

第二步：让它区分“必需改动”和“顺手改动”

这是最关键的一步。

因为很多时候，问题不是它完全错，而是：

• 有 1 部分是本次任务必需的
• 有 1 部分是它自己扩出去的

你必须让它把这两部分拆开。

可以继续问：

请把你的改动分成两类：

## 本次任务必需改动
- 文件：
- 原因：

## 超出范围改动
- 文件：
- 原因：
- 是否可以不改：

第三步：先不要急着让它“自动收回来”

很多人这时会直接说：

那你自己收回来

这其实有风险。

因为如果它对边界理解还不清楚，它第二轮可能继续误收、误改。

更稳的做法是：

1. 先看它列出来的范围判断。
2. 你确认哪些确实不该动。
3. 再让它只处理这部分。

第四步：给它一个“最小回收任务”

当你已经看清哪些改动不该保留，再发这段：

现在请你只处理超出范围的改动。

要求：
1. 只回收和本次任务无关的修改。
2. 保留本次任务真正必需的改动。
3. 不要新增新的优化。
4. 不要顺手重构。
5. 完成后请重新列出最终保留的文件范围。

这段话的重点就是：

只收范围
不要顺手再干别的

第五步：看它为什么会失控

任务失控通常不是偶然。

最常见根因有 4 类：

1. 任务目标写得太大

例如：

把这个页面优化一下

这类目标天然容易扩。

2. 范围限制没写

如果你没写：

• 优先改哪个文件
• 不要动哪些层
• 不要顺手修历史问题

那它更容易自由发挥。

3. 验收标准不够具体

如果你只说“改好就行”，它就会自己定义什么叫“好”。

4. 第二轮反馈太模糊

当它开始跑偏时，如果你只说：

不太对，你再改改

它往往会继续猜。

一段可以长期复用的“收范围提示词”

先不要继续修改文件。

我怀疑你刚才的改动超出了本次任务范围。

请按下面顺序处理：
1. 列出你修改的所有文件。
2. 区分哪些是本次任务必需改动，哪些是顺手改动。
3. 解释你为什么会扩大范围。
4. 给出最小回收方案。
5. 在我确认前，不要继续修改。

怎么避免下一次再失控

以后你可以在任务开头直接加这段：

范围限制：
1. 优先只修改【这里填目标文件或目录】。
2. 如果需要修改超过 2 个文件，请先说明原因再继续。
3. 不要顺手修历史问题。
4. 不要重构无关代码。
5. 如果你发现任务必须扩大范围，请先停下来问我。

这一段非常值。

什么时候说明这次任务已经不适合继续修补

如果已经出现下面这些情况，说明不适合继续在同一个线程里“缝缝补补”：

• 改动范围已经很大
• 你和它对目标理解差很多
• 它已经连续两轮在错误方向上优化
• 你自己看 diff 都开始混乱

这时更好的做法通常是：

先收范围
再重新开一个更小、更清楚的新任务

完成标志

做到这里，如果你已经形成下面这些习惯，就说明本篇起作用了：

1. 一旦怀疑改动超范围，会先停。
2. 会先让 Codex 列出所有改动文件。
3. 会区分必需改动和顺手改动。
4. 会让它做最小回收，而不是继续乱优化。
5. 会在下一次任务开头提前写好范围限制。

下一步建议

这一波之后，排障手册已经开始有“稳定交付”味道了。下一波很适合继续补：

• Git 提交说明写得太空怎么办
• 让 Codex 先分析不要直接修改怎么写
• 一次任务太大了怎么拆