用 AI 编程工具久了，几乎每个人都经历过这一幕：让 AI 改个小功能，它信心满满地交付，你一看很整洁就合并了，结果三天后线上出问题——某个它「顺手优化」的地方，悄悄改变了一个你以为不会变的行为。AI 没报错、没警告，它压根不知道自己改坏了。
AI 改坏项目不是能力问题——它能写出很多人写不出的漂亮代码。问题出在它的工作方式和真实软件工程的要求之间存在结构性错配。看清这些错配，才能对症下药。这篇文章拆解根本原因，给出可落地的降风险实践。
AI 改坏项目的原因是结构性的：没有全局视野、会自信幻觉、倾向过度改动——加上人的过度信任。
五个根本原因
1. 没有全局视野，只见树木
AI 看到的是你喂给它的那部分上下文，不是整个系统。它不知道你改的这个函数还被另外八处调用、不知道这个字段下游有个报表依赖、不知道这段“看起来没用”的代码其实是为了绕过某个历史 bug。人类资深工程师的价值很大程度在于知道“改这里会影响那里”，而这种全局关联恰恰是当前 AI 最缺的。于是它做出局部正确、全局错误的改动。
2. 自信的幻觉
AI 会用完全一样的笃定语气，写出对的代码和错的代码。它会调用不存在的 API、假设一个其实不成立的前提、“记得”一个早已废弃的用法——而且不会告诉你“这里我不确定”。人类工程师不确定时会停下来问、会留 TODO、会说“我猜是这样”,AI 把猜测和事实用同样的自信端上来。这让幻觉在代码里格外危险，因为代码要么对要么错，没有“大概对”。
3. 倾向过度改动
让 AI 修一行，它常常改一片：顺手“优化”了旁边的代码、“统一”了命名、“改进”了结构。每一处单看都像好意，合起来却是一个你没法安心 review 的大 diff，而且大大增加了引入意外行为变化的面积。AI 有种“多做点显得更负责”的倾向，但在成熟项目里，最小改动才是美德。
4. 静默的行为改变
最危险的一类。重构时把 >= 变成 >、把默认值从 true 改成 false、调整了排序顺序、改了缓存时长。功能“看起来”没变，行为已经变了。这类改动不会报错、测试可能碰巧还过，直到某个边界情况在生产环境引爆。
5. 人的过度信任
前四条是 AI 的，这一条是我们自己的——也是最致命的。AI 代码太整洁了，整洁会催眠 review 的人。“看起来这么规范，应该没问题吧”这个念头，让无数本该被拦下的问题溜进了主干。风险的放大器不是 AI，是放松警惕的人。
局部正确、全局错误——AI 缺的正是资深工程师“改这里会影响那里”的系统直觉。
降风险的六条实践
原因清楚了，对策就顺理成章。这六条按重要性排序：
1. 小步改，小步 review
对抗“过度改动”和“难以 review”的根本手段。把大任务拆成一系列小改动，每个小到你能完整读懂、能明确验收。宁可让 AI 分五次各改一点，也别让它一次改五百行。小 diff 才 review 得动，review 得动才拦得住问题。
2. 改动隔离，随时可回滚
用 Git Worktree 或独立分支让 AI 的改动和你的工作分开，git diff 一眼看清它改了什么，改坏了删掉即可。能一键还原，你才敢放手让它改。 这是心理上和工程上的双重安全网。
3. 给足上下文和红线
对抗“没有全局视野”：在 CLAUDE.md / AGENTS.md 里写清项目约定、目录职责、以及绝对不能碰的红线(migration、auth、支付、配置)。AI 看不见的全局，你用文档补给它一部分。
4. 带着怀疑 review，尤其是“看起来对”的地方
对抗“自信幻觉”和“过度信任”：按AI 代码 review 清单重点查幻觉 API、边界处理、被悄悄改掉的语义。核心心态是——越整洁越要验证，别被规范的外表安抚。
5. 必须实际运行验证
对抗“静默行为改变”：读代码发现不了行为变化，必须跑起来看真实结果。改动可预览的就在浏览器/测试里驱动一遍。“AI 说测过了”不算数，你自己跑过才算。
6. 用 CI 和自动化兜底
对抗人会疲劳、会漏：类型检查、lint、测试、安全扫描挂进 CI，让机器自动拦掉一批问题，把人的注意力留给机器发现不了的语义和设计。AI 生成的测试要额外警惕(它可能写假测试)，关键路径的测试自己把关。
六条对策各治一个病根：小步改、隔离、给红线、疑心 review、实跑验证、CI 兜底。
什么时候干脆别让 AI 改
不是所有代码都适合交给 AI。以下场景建议人主导、AI 最多打辅助：
- 安全和权限核心：鉴权、加密、访问控制，错一点就是大事故，AI 的幻觉在这里代价太高；
- 支付和资金逻辑：同上，不可逆的后果不容“大概对”;
- 你自己都没想清楚的需求：AI 会把你模糊的想法具体成一个看似合理其实跑偏的实现，让你误以为想清楚了。需求的判断永远是人的事，AI 负责实现不负责决定做什么。
- 牵一发动全身的核心抽象：改一处影响全局的底层设计，需要的正是 AI 最缺的系统视野。
适用人群与心态
适合所有把 AI 编程用于真实项目的人，尤其是那些已经尝到甜头、开始把越来越重的活交给 AI 的人——恰恰是这群人最容易在过度信任上栽跟头。
正确的心态不是“AI 不靠谱别用”，也不是“AI 很强放手交给它”，而是把它当成一个能力很强但不了解你项目、偶尔会自信地犯错、需要 review 的协作者。你对同事的代码会 review、会要求测试、会守住红线；对 AI 也一样，甚至要更警惕，因为它不会主动说“这里我不确定”。用好这层关系，AI 是实实在在的效率杠杆；用不好，它就是个高效的麻烦制造机。
常见问题
Q：模型越来越强，这些风险会消失吗？ A：会减轻，不会消失。幻觉频率会降、代码质量会升，但“缺全局视野”“需求判断”是结构性的——只要 AI 看不到你完整的系统和意图，局部正确全局错误的可能就一直在。降风险的工程实践不会过时。
Q：小步改会不会太慢，抵消了 AI 提效？ A：短期看多花点 review 时间，长期看远比“改坏了排查生产事故”快。AI 省下的是编码时间，别把它全花在善后上。留足 review 和验证预算，净收益依然可观。
Q：团队怎么落地这些实践？ A：写成明确的团队约定——哪些模块 AI 可主导、哪些必须人写、合并前必过哪些检查、改动大小上限。再用 CI 强制一部分(测试、扫描不过不许合)。把“疑心 review 和实跑验证”变成流程要求，而不是靠个人自觉。
小结
AI 改坏项目的病根有五个：没有全局视野、自信幻觉、过度改动、静默改变行为，以及人的过度信任。对策一一对应：小步改、隔离可回滚、给足红线、带疑心 review、必须实跑、CI 兜底。记住那句心态——越整洁越要验证。把 AI 当成需要 review 的强力协作者而非全知的自动驾驶，它就是你的效率杠杆。