当 AI 编程智能体的改动远超任务范围时，正确的第一步不是把工作区强行恢复干净，而是停止新的写入并保留证据。重新确认原始目标，把每项改动分为必要、配套、附带和未知，再从可证明的部分重建最小补丁。
先冻结现场
记录当前 Git 状态、差异摘要、失败命令和最终生成物；如果智能体写过外部系统，也要记录外部状态。在证据还不断变化时，不要部署、全仓格式化或再启动一次宽泛任务。
这同样是权限边界。OpenAI 的编程智能体安全指南强调限制访问范围并审查高影响动作。恢复工作的起点，就是不再让授权范围继续扩张。
还原最初的任务契约
从原始需求中重新写出：
- 用户最终要得到什么；
- 哪些文件或系统确实需要变化；
- 哪些行为和数据必须保持不变；
- 哪些检查能够证明完成。
无法连接到以上任一项的改动，都应先提供证据再保留。“这样更整洁”不是证据。
先分类差异，再开始编辑
- 必要改动： 直接实现请求结果。
- 配套改动： 结果所需的测试、配置、文案或数据结构。
- 附带改动： 与验收无关的格式化、重命名、依赖升级或重构。
- 未知改动： 可能相关，但尚未被执行路径或测试解释。
遇到未知项先调查，并保护用户已有工作。尤其在工作区不干净时，不能用破坏性重置换取表面整洁。
找到最小可信执行路径
从用户动作追到真实状态变化。范围膨胀往往不是问题本身复杂，而是智能体围绕猜测出来的架构做了大量工作。先用一条窄测试复现目标行为，再只保留让该测试及相邻回归通过的改动。
可结合AI 生成代码上线前验证指南。若代码来自模板或生成器，必须直接验证最终生成物，而不只是验证源模板。
按影响面逐层验证
- 变更表面的语法或类型检查；
- 最窄回归测试；
- 受影响包的测试；
- 真实渲染或运行路径；
- 只有共享影响确实存在时，才扩到全仓检查。
后续检查失败时，不能因为窄测试通过就宣布完成。只有拿出基线证据，才能把某个失败判定为既有问题。
防止下一次范围膨胀
后续任务说明应明确保护边界、禁止动作、授权范围和完成证据，并把工作拆成可恢复的小检查点。OpenAI 的 harness engineering 实践说明了清晰仓库反馈的重要性；DORA 的 AI 辅助开发报告也提醒我们：局部活动更快，不等于交付稳定性自然提升。
SoloMap 可以把目标、当前证据和验收条件留在路线图步骤或 Solo 任务中，再把最终验证结果附回同一上下文。这样复盘范围时依据的是项目契约，而不是某次长对话的印象。微执行循环适合把反馈窗口缩小到可控范围。
常见问题
是否应该撤销全部 AI 改动重新开始？
不应默认如此。先保留证据和用户工作，再保留能连接到目标且通过验证的部分，隔离附带改动。
怎样判断一次重构是否必要？
要求它对应具体证据：失败测试、真实执行路径限制，或不重构就无法满足的验收条件。偏好本身不够。
大补丁一定是错的吗？
不一定。真实行为可能跨越多个层次。问题不在行数，而在于范围无法解释、结果无法追溯。