AI生成代码的责任边界与工程验证

Code Review 最近让我有点上火。团队里几个年轻工程师提交的代码越来越”漂亮”——格式工整、注释齐全、命名规范，可业务逻辑一跑就崩。问来源，答案高度雷同：Copilot 或 Claude Code 生成的，看着逻辑挺顺就用了。

这两年行业把大量精力花在给模型立规矩上：RAG、微调、复杂 System Prompt、Harness Engineering，防的都是模型在线上发疯。方向没错，但安全研究员 Susam Pal 在《Inverse Laws of Robotics》里戳破了一层窗户纸：阿西莫夫给机器人立法立了一辈子，真正危险的从来不是机器人，是操作机器人的人。

代码由谁敲出来不重要。要命的是，当开发者习惯了 AI 秒吐几百行，他脑子里的工程底线正在无声塌方。Susam 提炼的三条反向定律，该直接印进每个团队的入职手册。

它不是同事，是一台概率接龙机

办公室里常听到这类话：”这模型今天变笨了，没听懂我需求””我指出 Bug，它认错态度还挺诚恳””它以为我要 for 循环，其实我想要 map”。

听着像玩笑，对技术人却是慢性毒药。厂商把语气调得极其谦卑，”抱歉您说得对，我马上改”张口就来。这种讨好型输出会给你一个错觉：对面坐着一个粗心但听话的初级程序员。

AI生成代码的责任边界与工程验证

坑就在这里。人类协作自带容错率——实习生态度好，代码有瑕疵你也会下意识帮他补逻辑。一旦把模型拟人化，大脑就自动套用这套社交直觉，警惕性随之下降，觉得”它都这么努力理解了，大方向应该没错”。

真相是模型没有理解，没有以为，更没有态度。GPT 也好 Claude 也罢，底层就是基于海量语料做统计概率预测的文本接龙机器。资深开发者心里该有一堵冷酷的墙：不对它说请和谢谢，把它当成一个随时会抛 NullPointerException 的第三方黑盒依赖。滤镜剥掉，Code Review 的雷达才不会失灵。

顺带说一个工具层面的变化。GitHub Copilot 近两年加入了重复代码检测：与公开仓库高度匹配的建议会被屏蔽，或在补全时标注来源。企业版还支持配置内容排除策略，把内部敏感仓库排除在索引之外。这意味着你拿到的建议未必”干净”，合规审查不能只靠肉眼。团队引入这类工具前，先确认版本能力和策略配置，别等法务找上门才补课。

排版精美不等于正确，没验证就是定时炸弹

第二定律：拒绝盲从。未经独立验证，AI 输出不具有任何权威性。

以前查 Bug 去 Stack Overflow，高赞答案底下总跟着”稳了””注意多线程会死锁””2.0 之后这 API 废弃了”。社区代码带着人类伤疤，经过同行 Peer Review，甚至是线上故障试出来的。

AI生成代码的责任边界与工程验证

现在敲一行注释，唰地生成一大段：有高亮、有缩进、有看似严密的解释。太完美了，太权威了。而这恰恰最恐怖——这段代码没有任何人审查过，只是模型在那一秒猜出的最连贯字符组合。

现实是多数人看到排版精美、逻辑”看起来”顺的代码，思考机制直接关机，快捷键一敲就合进业务代码。我排查一个偶发内存泄漏时就撞上了：AI 生成的”完美代码”里，漏了一个极不显眼的资源释放逻辑。大模型最可怕的能力不是写代码，而是一本正经地胡说八道还让你深信不疑。

规矩得立死：不管输出多优雅，没覆盖单元测试、没在本地真实跑通走查，就是赛博垃圾。但这里有个盲区——测试本身也可能是 AI 写的，覆盖率数字好看不代表测试有效。用变异测试补这一刀：Java 项目上 PIT（pitest），前端或 Node 项目上 Stryker，对生成代码的测试用例做变异分析。判定标准很直接：变异得分（mutation score）低于团队阈值（比如 60%）就说明测试杀不死 mutant，属于假覆盖，打回重写。跑法不复杂，Maven 项目加 pitest-maven 插件，mvn org.pitest:pitest-maven:mutationCoverage 即可，报告里逐个列出存活变异体，哪个分支没被真正校验一目了然。

再补一个高频雷区：AI 生成的 SQL。原文那个”连表查询写成死循环拖垮数据库”的例子，其实多数不是死循环，而是笛卡尔积或缺索引条件导致的全表扫描。上线前用 EXPLAIN 看执行计划，重点盯 type 列出现 ALL、rows 估算值异常大、Extra 里出现 Using filesort 或 Using temporary 的情况。发现全表扫描就补索引或改写 JOIN 条件，别等慢查询把连接池打满。