在实际协作中，您可能会遇到 Codex 修改范围失控的情况：原本只需修复一个按钮的样式，结果它顺手重构了公共组件、调整了全局 CSS 变量，甚至修改了无关的后端接口文件。这被称为“修改范围失控”（Scope Creep），是 AI 协作中最高频的风险之一。
1. 识别失控信号
当 Codex 出现以下行为时，说明修改范围可能已经失控：
- 文件数量异常激增：预期只动 1-2 个文件，实际修改了 5 个以上。
- 触及公共/核心层：在未获授权的情况下修改了全局路由、公共工具类或数据库配置。
- 包含“顺手”优化：AI 解释为“为了保持代码风格一致”而进行的额外重构，但这并未在您的任务描述中提及。
2. 核心原则：立即停止
一旦在对话或 Diff 预览中发现改动超出预期范围，应立即停止写入或点击“取消”。不要尝试通过“顺便也处理了吧”来掩盖问题，这会导致后续测试难度激增，并可能引入难以排查的回归 Bug。
3. 处理步骤
第一步：只读核查范围
要求 Codex 列出所有已修改文件，并区分哪些是任务必需的，哪些属于额外扩大的范围。在未理清边界前，禁止继续修改。
建议提示词：
> “请先停止修改。请列出你目前准备修改的所有文件，并用中文解释每个文件的改动原因。请指出哪些改动是实现‘[任务目标]’必须的，哪些是额外的优化。”
第二步：拆解改动逻辑
让 Codex 将改动分类为“功能性改动”与“重构性改动”。明确哪些部分可以剔除而不影响当前任务目标的达成。
第三步：最小化回收
要求 Codex 仅回收超出范围的部分，保留真正必需的修改。重点在于“只收范围，不做二次优化”。
建议提示词：
> “你的修改范围超出了我的预期。请撤销对 /src/common 和 /config 目录下所有文件的改动。请仅保留对 [核心文件] 的修改，以实现‘[任务目标]’。”
4. 预防失控的策略
- 在 AGENTS.md 中定义禁区：显式规定 AI 禁止触碰的文件或目录（如
package-lock.json、dist/）。 - 任务描述中显式限速：在指令末尾加入“如果修改超过 3 个文件，请先向我确认原因”。
- 强制只读预览：对于复杂任务，先要求 Codex 输出修改计划（Plan），待人工确认后再执行。
5. 终极手段：Git 回退
当改动范围已大到无法通过对话简单回收，或 Codex 对目标的理解已发生严重偏差时，最佳实践是：
- 重置 Git 状态：使用
git checkout .或通过 IDE 的回退功能清空未提交的改动。
2. 重开任务：重新开启一个更小、更具体的任务 Thread，并附带更严格的范围限制指令。
---
下一篇推荐：Git 提交前审计 —— 学习如何利用 AI 守住代码库的最后一层质量防线，防止失控改动进入仓库。