让 AI 改代码不失控的六条工程约束

用 AI 写代码写久了会发现，让人头疼的从来不是”它写的代码有 bug”。有 bug 可以调。真正麻烦的是：你不知道它改了什么。

一次看似简单的”帮我修一下这个报错”，可能顺手重构了三个函数、改了两处配置、删掉了一段它认为没用的代码。等你发现的时候，已经很难回退了。

下面六条约束是针对这个问题的。

一、改动前必须有干净的版本控制状态

这是唯一一条没有商量余地的。

二、一次只改一件事

“顺便把那个也优化一下”是最贵的一句话。合并的改动会让 diff 变得不可读，而不可读的 diff 等于没有审查。

正确的做法是排队：修 bug 是一次，重构是另一次，加功能是第三次。每次改完提交一次。

三、给出明确的”不要动”清单

模型倾向于把它认为不好的东西顺手改掉。你需要在提示词里明确划界：

本次只修改 src/parser.js 中的 parseHeader 函数。

不要动：
- 其他任何文件
- 该文件中的其他函数
- 函数签名（调用方很多，改了会连锁）
- 现有的错误处理分支

如果你认为必须改动上述内容才能解决问题，
先说明原因并等我确认，不要直接改。

最后那一段是关键。没有这句，模型遇到障碍时会自作主张绕过去。

四、要求它先说方案，再动手

五、验证由你负责，不由它负责

模型会说”我已经测试过了”——它没有。它没有运行你的代码，也看不到你的运行环境。

每次改动之后，至少要过这三关：

六、保留可回退的路径

AI 改代码时最危险的操作是大范围替换——整文件重写、批量重命名、删除”无用”代码。这类操作一旦出错，靠肉眼是恢复不了的。

三条防线：

1. 频繁小提交。提交粒度越小，回退代价越低。
2. 在分支上做。不要直接在主干上让 AI 大改。
3. 删除操作单独一次。“删掉没用的代码”必须是独立的一次改动，且你要逐条确认每一处删除。模型对”没用”的判断依据是它看到的上下文，而它看到的往往不全。

七、把六条压成一张卡

八、最后说一句

这六条本质上都是同一件事：把改动的范围控制在你能审查的大小之内。AI 写代码的速度远超你审查的速度，如果不主动设限，产出很快就会超过你的理解能力——那时候代码库还是你的，但你已经不认识它了。