代码是AI写的，生产事故谁背锅？

最近在做 Code Review 的时候我发现团队里越来越多的年轻工程师开始频繁提交一些看起来极其规整、甚至连注释都写得完美无缺但稍微往深了一看业务逻辑根本跑不通的代码。问他们怎么写的答案出奇地一致“这是 Copilot / ChatGPT / Claude Code 给出的代码我看它逻辑挺清晰的就直接拿来用了。”这两年整个行业都在拼命研究怎么给大模型“立规矩”搞 RAG检索增强、微调、写各种复杂的 System Prompt乃至搞出一整套 Harness Engineering。大家不断的折腾就是怕大模型在线上环境突然发疯。我们几乎把所有的工程资源都砸在了“如何防止 AI 犯错”上。但是最近有一个叫做 Susam Pal 安全研究员写了一篇叫《Inverse Laws of Robotics》的文章一巴掌拍醒很多人。他提出一个很犀利的观点阿西莫夫花了一辈子给机器人定法律但其实现在最危险的根本不是机器人而是屏幕前那个使用机器人的人类。代码是机器写的还是人写的这不重要。重要的是当一个开发者习惯了 AI 瞬间吐出几百行代码后他潜意识里的工程底线正在悄悄崩塌。Susam 提炼了三条给人类看的“反向定律”。结合我最近在团队里的观察我觉得这三条规矩应该直接写进每个技术团队的入职手册里。别给它加戏它不是你的同事只是一台 Token 机器第一定律拒绝拟人化。 不要赋予 AI 情感、意图或道德代理权。你在办公室里肯定听过同事这么议论大模型• “某某模型今天好像变笨了没听懂我的需求。”• “我指出了它的 Bug它认错的态度还挺诚恳的。”• “它以为我要写个 for 循环其实我想写个 map。”听起来没什么大不了的对吧大家都在开玩笑。但作为技术人这种习惯非常致命。现在的 AI 厂商为了用户体验把模型的语气微调得极其谦卑。动不动就对你说“抱歉您说得对我马上改”。这种讨好型的输出会在潜意识里给你一种错觉你在和一个虽然有点粗心但脾气极好、非常听话的初级程序员沟通。这恰恰是最大的坑。在人类社会的协作里我们对同事是有“容错率”的。如果一个实习生态度很好哪怕代码写得有瑕疵你也会下意识地宽容他甚至帮他把逻辑补齐。当你把大模型拟人化之后你的大脑就会不自觉地套用这种“社交直觉”。你会放松警惕觉得“它都这么努力理解我了大体方向应该没错”。但现实是大模型根本没有“理解”没有“以为”更没有“态度”。不管是 GPT 还是 Claude它的底层本质就是一个没有灵魂、基于海量语料做统计学概率预测的“文本接龙机器”。资深开发者在用 AI 时心里应该有一堵极度冷酷的墙不要对它说“请”和“谢谢”不要把它当人看。把它当成什么当成一个高级的命令行工具CLI或者一个随时会抛出 NullPointerException 的第三方黑盒依赖。剥离掉拟人化的滤镜你才不会对它生成的代码抱有任何不切实际的“信任感”你的 Code Review 雷达才不会失效。别被排版糊弄了没跑过验证的代码全是定时炸弹第二定律拒绝盲从。 绝不能盲目信任 AI 的输出。没有经过独立验证绝不能将 AI 的结果视为权威。以前我们遇到搞不定的 Bug习惯去搜 Stack Overflow。我们搜出来的那个高赞答案底下往往跟着一堆评论“哥稳了”、“注意这个方法在多线程下会死锁”、“升级到 2.0 之后这个 API 废弃了”。传统的社区代码是带着“人类伤疤”的。它经过了无数同行的 Peer Review甚至是用真实的线上故障试错出来的。但是现在你在代码助手里敲一句注释它“唰”地一下给你生成了一大段代码。有高亮、有缩进、甚至还有看似严密的 Markdown 解释。它看起来太完美了太权威了。但这才是最恐怖的地方。这段代码没有任何人做过审查。 它只是模型在当下那一秒“猜”出来的最连贯的字符组合而已。现实中绝大多数开发一看到这种排版精美、逻辑“看起来”顺理成章的代码大脑的思考机制就会自动关机直接快捷键一敲合并到业务代码里。我最近在查一个内存泄漏的偶发 Bug 时就发现是这种 AI 生成的“完美代码”里漏写了一个很不显眼的资源释放逻辑。大模型最可怕的能力不是写代码而是“一本正经地胡说八道并且让你深信不疑”。以后在团队里立下一个死规矩信任在工程实践中非常宝贵。不管 AI 输出的代码看起来多优雅只要没有覆盖对应的单元测试没有在本地环境真实地跑通走查过那就是赛博垃圾。谁合并代码谁背锅“AI 写的”绝对不是免死金牌第三定律责任不可剥夺。 人类必须对后果承担全部责任。永远不能拿“AI 告诉我这么做的”来当借口。这可能是接下来一两年里大部分技术团队在出线上事故后最容易上演的甩锅大戏。想象一下周五晚上十点系统挂了客服电话被打爆。周末全员拉群排查终于定位到是因为一段 SQL 连表查询写成了死循环把数据库拖垮了。复盘会上写这段代码的年轻开发很委屈地说“老大那段复杂 SQL 是 Copilot 生成的我看编辑器没报错就直接提交了我也不知道它会把库打挂啊。”如果在我的团队里听到这句话我会当场发飙。这就好比一个外科医生把手术做砸了然后说“因为这把手术刀太锋利了自己划偏了”一样荒谬。在工程师的职业素养里用这句话来甩锅恶劣程度等同于“因为编译器没报错所以系统宕机不怪我”。我们要搞清楚一个基本事实AI 只是个干活的工具。它不用背房贷不用拿绩效就算把整个支付宝或者微信的后台搞崩溃了它也不会被开除大不了就是重启一下进程。工具不承担后果人承担。这就要求我们把权责切得明明白白AI 可以帮你一秒钟写出 500 行代码没问题这是提效。但是谁审查的这 500 行代码谁按下的 Merge 按钮谁把它发布到了生产环境谁就老老实实为这 500 行代码负 100% 的责任。你不能光占着 AI 帮你摸鱼的便宜却不想背它出错的黑锅。一旦你心里有了“这反正是 AI 写的出错了也有借口”的念头你的技术生涯基本也就到头了。方向盘必须在自己手里看完 Susam Pal 的这三条“反向定律”我最大的感慨是我们的重点是不是搞错了。面对 AI 编程这波浪潮大家都在焦虑“我是不是要被淘汰了”、“我是不是该去学怎么写 Prompt”。但其实AI 写代码的速度越快对我们的基本功考验反而越严苛。在一个大家都能用 AI 瞬间生成海量代码的年代敲键盘的手速早就不是壁垒了。真正的壁垒是什么是你能在一眼望不到头的 AI 代码中敏锐地嗅出架构腐化的味道是你坚持无论代码谁写的都必须卡死测试覆盖率的底线是你时刻清醒地知道AI 只是工具方向盘和刹车必须死死攥在自己手里。不管大模型进化到第几代。打铁还需自身硬在这个 AI 乱写的时代里守住一个工程师的职业底线比什么都强。