代码是 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 乱写的时代里，守住一个工程师的职业底线，比什么都强。