代码是 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。”
https://img2024.cnblogs.com/blog/757544/202605/757544-20260513093157321-1446731281.png
听起来没什么大不了的，对吧？各人都在开打趣。但作为技能人，这种风俗非常致命。
现在的 AI 厂商为了用户体验，把模子的语气微调得极其谦卑。动不动就对你说“歉仄，您说得对，我立刻改”。这种讨好型的输出，会在潜意识里给你一种错觉：你在和一个固然有点粗心，但性情极好、非常听话的低级步调员沟通。
这恰恰是最大的坑。
在人类社会的协作里，我们对同事是有“容错率”的。如果一个练习生态度很好，哪怕代码写得有瑕疵，你也会下意识地宽容他，乃至帮他把逻辑补齐。当你把大模子拟人化之后，你的大脑就会不自觉地套用这种“交际直觉”。你会放松鉴戒，以为“它都这么积极明确我了，大要方向应该没错”。
但实际是，大模子根本没有“明确”，没有“以为”，更没有“态度”。不管是 GPT 还是 Claude，它的底层本质就是一个没有魂魄、基于海量语料做统计学概率推测的“文本接龙呆板”。
资深开辟者在用 AI 时，内心应该有一堵非常冷漠的墙：不要对它说“请”和“谢谢”，不要把它当人看。
把它当成什么？当成一个高级的下令行工具（CLI），大概一个随时会抛出 NullPointerException 的第三方黑盒依靠。剥离掉拟人化的滤镜，你才不会对它天生的代码抱有任何不切实际的“信托感”，你的 Code Review 雷达才不会失效。
别被排版瞎搅了：没跑过验证的代码，满是定时炸弹
第二定律：拒绝盲从。 绝不能盲目信托 AI 的输出。没有颠末独立验证，绝不能将 AI 的效果视为权势巨子。
从前我们遇到搞不定的 Bug，风俗去搜 Stack Overflow。我们搜出来的谁人高赞答案，底下每每跟着一堆品评：“哥，稳了”、“注意，这个方法在多线程下会死锁”、“升级到 2.0 之后这个 API 废弃了”。
传统的社区代码，是带着“人类伤疤”的。它颠末了无数偕行的 Peer Review，乃至是用真实的线上故障试错出来的。
但是现在，你在代码助手里敲一句解释，它“唰”地一下给你天生了一大段代码。有高亮、有缩进、乃至另有看似细密的 Markdown 表明。它看起来太完满了，太权势巨子了。
但这才是最可怕的地方。这段代码没有任何人做过检察。 它只是模子在当下那一秒，“猜”出来的最连贯的字符组合而已。
https://img2024.cnblogs.com/blog/757544/202605/757544-20260513093235115-477447.png
实际中，绝大多数开辟一看到这种排版精致、逻辑“看起来”顺理成章的代码，大脑的思索机制就会自动关机，直接快捷键一敲，归并到业务代码里。我近来在查一个内存走漏的偶发 Bug 时，就发现是这种 AI 天生的“完满代码”里，漏写了一个很不显眼的资源开释逻辑。
大模子最可骇的本领，不是写代码，而是“一本端庄地颠三倒四，而且让你笃信不疑”。
以后在团队里，立下一个死规矩：信托在工程实践中非常名贵。不管 AI 输出的代码看起来多优雅，只要没有覆盖对应的单位测试，没有在本地环境真实地跑通走查过，那就是赛博垃圾。
谁归并代码谁背锅：“AI 写的”绝对不是免死金牌
第三定律：责任不可剥夺。 人类必须对结果负担全部责任。永久不能拿“AI 告诉我这么做的”来当捏词。
这大概是接下来一两年里，大部分技能团队在出线上变乱后，最容易上演的甩锅大戏。
想象一下：周五晚上十点，体系挂了，客服电话被打爆。周末全员拉群排查，终于定位到是由于一段 SQL 连表查询写成了死循环把数据库拖垮了。复盘会上，写这段代码的年轻开辟很委曲地说：“老大，那段复杂 SQL 是 Copilot 天生的，我看编辑器没报错就直接提交了，我也不知道它会把库打挂啊。”
如果在我的团队里听到这句话，我会当场发飙。
这就比如一个外科医生把手术做砸了，然后说“由于这把手术刀太锋利了，本身划偏了”一样谬妄。在工程师的职业素养里，用这句话来甩锅，恶劣程度等同于“由于编译器没报错，以是体系宕机不怪我”。
我们要搞清晰一个根本究竟：AI 只是个干活的工具。它不消背房贷，不消拿绩效，就算把整个付出宝大概微信的配景搞瓦解了，它也不会被开除，大不了就是重启一下进程。
工具不负担结果，人负担。
这就要求我们把权责切得显着白白：AI 可以帮你一秒钟写出 500 行代码，没标题，这是提效。但是，谁检察的这 500 行代码，谁按下的 Merge 按钮，谁把它发布到了生产环境，谁就老老实实为这 500 行代码负 100% 的责任。
你不能光占着 AI 帮你摸鱼的自制，却不想背它堕落的黑锅。一旦你内心有了“这反正是 AI 写的，堕落了也有捏词”的动机，你的技能生活根本也就到头了。
方向盘必须在本身手里
看完 Susam Pal 的这三条“反向定律”，我最大的感慨是：我们的重点是不是搞错了。
https://img2024.cnblogs.com/blog/757544/202605/757544-20260513093247581-1345914890.png
面临 AI 编程这波海潮，各人都在焦虑“我是不是要被镌汰了”、“我是不是该去学怎么写 Prompt”。但着实，AI 写代码的速率越快，对我们的根本功磨练反而越严苛。
在一个各人都能用 AI 刹时天生海量代码的年代，敲键盘的手速早就不是壁垒了。真正的壁垒是什么？
是你能在一眼望不到头的 AI 代码中，敏锐地嗅出架构腐化的味道；是你对峙无论代码谁写的，都必须卡死测试覆盖率的底线；是你时间清醒地知道，AI 只是工具，方向盘和刹车必须死死攥在本身手里。
不管大模子进化到第几代。打铁还需自身硬，在这个 AI 乱写的期间里，守住一个工程师的职业底线，比什么都强。
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金.
页:
[1]