前面几篇都在讲怎么让 AI 写得又快又多。这一篇泼冷水，也是整个专栏最不能省的一篇：它写出来的代码，凭什么信？
答案是：默认别全信，但可以用一套办法把风险管住。 一句话立场——
AI 写代码不是"要不要审查"的问题，而是"审查这道关永远不能撤"的问题。
它会怎么"骗"你
《大模型专栏》第 5 篇讲过幻觉：模型追求"像真的"，不担保"是真的"。放到代码上，幻觉有几副特别坑的面孔：
- 调用不存在的函数/参数：它会自信地写
array.shuffle()，可这门语言压根没这方法——因为"看起来该有"。 - 引用虚构的库：
import supertools，一个根本不存在的包。这还催生了一种新型攻击"依赖投毒"（slopsquatting）：坏人专门注册 AI 爱编的那些假包名，等你手一滑装上，就中招了。 - 代码能跑但是错的：语法没问题、测试也过了，逻辑却和你要的差一点——最难发现的一种。
- 看着对、边界全崩：正常输入没事，一遇空值、超大量、并发就出问题。
共同点是：它们都"长得很对"。 这正是危险所在——AI 的代码通常不会明目张胆地烂，而是似是而非，逼你必须真的看懂，而不是扫一眼觉得"挺像样"就合并。
守住质量的四道关
好消息是，管住这些风险，靠的还是软件工程本来就该有的那套纪律，只是现在更不能偷懒了。
第一关：自己读懂，再合并
铁律一条：
不理解的代码，不要合并。
AI 写的每一行，你都该能解释"它为什么这么写"。看不懂的地方，让它解释，或者干脆让它换个你能看懂的写法。"能跑"不等于"可以进主干"。 一旦你合并了看不懂的代码，你就在项目里埋了一颗自己都不知道在哪的雷。
第二关：让测试说话
第 4 篇讲过，测试是 AI 自我纠错的跑道；在审查这里，测试同样是你的第一道防线。
- 要求它为新代码配测试，尤其覆盖边界情况（空值、极端量、异常路径）——AI 恰恰最容易在这栽跟头。
- 但要留个心眼：别让写代码的和写测试的"串通"。AI 可能写出"刚好能让自己代码通过"的测试，绕开了真正的问题。关键逻辑的测试，自己过一遍，或者自己补几个刁钻用例。
第三关：自动化卡口全开
把机器能查的，都交给机器，别靠肉眼：
- 类型检查、Linter、编译：能挡掉很多"调用不存在的东西"这类幻觉。
- 依赖审查：装新包前核实它真实存在、来源可靠（专治虚构库和依赖投毒）。AI 说要装的包，先搜一下确认。
- CI 流水线：让所有变更都过一遍统一的自动检查，AI 的产出也不例外。
第四关：安全的红线自己守
这一关最不能松。凡是沾安全的代码，必须人工重点审：
- 用户输入有没有校验？会不会 SQL 注入、XSS？
- 密钥、密码、token 有没有被硬编码进代码？（AI 有时会为了"能跑"直接把示例密钥写死）
- 权限校验有没有漏？越权能不能访问？
- 危险操作（删数据、发钱、改权限）的逻辑，逐行看。
AI 不理解"这段代码上线会造成什么后果"，它只知道"这样写像是对的"。后果的判断，永远是人的责任。
一个健康的心态
怎么把握这个度？一个好用的类比：
把 AI 当成一个手很快、但需要盯着的初级工程师。 它能帮你省掉大量敲字和查资料的时间，产出也常常不错；但它交上来的东西，你一定会 review，不会闭眼合并。你对它的信任，是"信任它的效率"，不是"信任它的判断"。
抱着这个心态，你既能享受提速，又不会把项目交给一个不担责的黑箱。AI 负责快，你负责对。
小结
- AI 代码的核心风险是幻觉：调不存在的函数、引虚构的库（小心依赖投毒）、能跑但逻辑错、边界崩——共同点是"长得很对"。
- 守质量靠四道关：① 读懂再合并（不懂不合）、② 让测试说话（重点边界，防自证测试）、③ 自动化卡口全开（类型/Lint/依赖/CI）、④ 安全红线人工死守。
- 心态：把它当手快但需盯着的初级工程师——信任它的效率，不信任它的判断。
- 一句话：AI 负责快，你负责对。审查这道关永远不能撤。
守住了质量，最后一个现实问题：怎么把 AI 编程真正融进日常工作流？什么活该交给它、什么活别碰、怎么选工具、又怎么不让自己的能力"用废"？下一篇收尾。