求你了，让 AI 少改点代码吧

不知道你有没有遇到过这种尴尬：你只是让 AI 修一个简单的空指针异常，结果它反手给你提交了一个涉及 20 个文件、1000 行变更的 Pull Request。

它不仅修了那个 Bug，还顺便重构了三个类，改了全局的命名风格，甚至因为它觉得“这里的代码写得不够优雅”，顺手删掉了一段它看不懂的历史兼容逻辑。

结果，Bug 确实修好了，但整个系统崩了。

这就是 AI 编程时代最荒诞的现状：我们不再缺“写代码”的产能，我们缺的是“不乱改代码”的克制。

---

1. 最大的风险，不是写不出来，而是“借题发挥”

过去我们担心 AI “不会写”，现在我们得担心 AI “太能写”。

人类工程师也会过度设计，但人是有物理极限的——改 20 行和改 2000 行，脑力和体力成本完全不同。人天生会为了省事而选择“最小化修改”。

但 AI 不一样。对它来说，改 1 行和改 2000 行的成本几乎没区别。

AI 把“生成代码”的成本打下来了，却没能把“判断哪些代码不该动”的难度打下来。

当修改成本变得极低，系统最容易出现的不是“做不动”，而是“改过头”：

• • 只是加个参数，它重构了整层配置；

• • 只是修个报错，它统一了所有返回格式；

• • 只是处理边界 Case，它动了沉睡五年的历史逻辑。

真正危险的不是 AI 没干活，而是它干了太多“不该干”的活，还混在你的 PR 里。

---

2. 旧架构不完美，不代表这次就该动它

所有的成熟系统在 AI 眼里都是“屎山”：命名不统一、抽象不彻底、历史包袱特别重。

AI 看到这些“不一致”，会有一种天然的冲动去“顺手统一”。但它不明白，很多看起来“不优雅”的代码，背后都是血淋淋的教训：

• • 那个奇怪的判断，是为了兼容某个已经不再维护的下游系统；

• • 那个冗余的字段，是为了保证灰度发布时的平滑过渡；

• • 那个看似累赘的封装，是某次重大事故后的防御性设计。

在 AI 编程时代，我们必须建立一个核心认知：先问“它为什么这样”，再问“要不要改”。

“不完美”不等于“应该在这次任务里修改”。

---

3. AI 时代的第一美德：克制

如果你觉得“只要方向正确，就应该立即改进”，那在 AI 协作中你可能会死得很惨。

即使一个重构方向再优雅、再先进，只要它：

1. 1. 不属于当前需求；

2. 2. 不构成当前阻塞；

3. 3. 会大幅扩大 Review 成本和回滚风险。

那么，它在这次提交里就是“有害”的。

AI 最擅长的，就是把“顺手清理”伪装成“必要修改”。

如果我们失去了对边界的控制，系统会很快从“提效”滑向“失控”。当“改代码”变得像呼吸一样简单，“知道哪些代码不该改”就成了最稀缺的顶级能力。

---

4. 救命的“AI 编程五问原则”

为了防止 AI 变成“拆房式装修”，在它动代码之前，请强迫它（或者你自己）回答这五个问题：

• • **第一问：这是不是当前需求的一部分？**如果不是，默认不改。

• • **第二问：如果不改它，当前需求会被阻塞吗？**如果不会，下次再说。

• • **第三问：如果必须改，能不能做最小范围的修改？**优先修补，而非重构。

• • **第四问：这次改动会影响已有契约吗？**检查 API、日志、下游依赖。

• • **第五问：这次改动能被清楚地审查和验证吗？**改动太杂，就该拆分提交。

这五问不是为了限制效率，而是为了把系统从“无限可优化”拉回“有限可交付”。

---

5. 最小必要改动：工程治理的生死线

如果 AI 编程只能保留一条军规，那一定是：最小必要改动原则（Minimal Necessary Change）。

任何代码修改，都应限定在完成当前需求所必需的最小范围内。非当前需求、非当前阻塞、非当前缺陷，禁止进入本次 diff。

它不反对重构，它反对的是“无边界重构”。

它不反对改善架构，它反对的是“在错误的时机改善架构”。

一旦这条原则立住，你的 PR 会变得更小，Review 会变得更快，责任边界会变得无比清晰。

---

6. 我们需要的不是“全自动工程师”

很多团队都在幻想招一个“全自动 AI 工程师”，让它自主搞定一切。

但更清醒的做法是：

• • AI： 作为一个高产、快速、执行力极强的实现者。

• • 人类： 作为一个守门人、架构师、风险责任人。

我们需要的不是一个“自由发挥”的艺术家，而是一个“在约束空间内爆发”的生产机器。

未来衡量一个团队 AI 编程的成熟度，不是看他们一天写了多少行代码，而是看他们有没有能力让 AI “只改该改的地方”。

大胆、聪明、高产，在 AI 编程时代都不是最值钱的。最值钱的是：克制。

---

转发给你的 AI 编程搭子，救救你的 PR 审查者。

---

参考资料

• • Google Engineering Practices: Small CLs

• • DORA Research: Working in Small Batches

• • Microsoft: Characteristics of Useful Code Reviews