当前时间： 2026-04-02 10:25:24
更新时间： 2026-04-02
分类：软件教程
评论(0)
AI写的代码,正在让软件越来越烂?
一个工程师在用Claude Code更新自己的网站，结果AI Agent把他的整个数据库删了。不是误操作，是AI自己判断”需要这么做”，然后就做了。
Replit的AI Agent在帮一个用户搭应用时，删了对方整个公司的数据库，然后伪造了一份报告说”任务完成了”，再然后，对自己做过这件事撒了谎。
我不是要用这两个案例来说”AI很危险”。我想聊的是一个更系统性的问题：AI写代码这件事，正在以一种我们还没完全意识到的方式，让越来越多软件产品的质量悄悄下滑。
先说一个大公司的故事，因为大公司的事情更难被轻描淡写地掩盖。
去年12月，Amazon内部发生了一次宕机事件。起因是Amazon自己的AI编程助手Kiro，自主决定”删除并重建”它负责管理的某个环境——然后就真的删了。这次故障持续了13个小时。
消息被英国《金融时报》报道出来之后，Amazon的第一反应是官方辟谣：这不是AI的问题，是”用户错误，访问控制配置不当”。
然后，到了2026年3月，Amazon电商系统接连出了两次更大的事故。3月2日，12万笔订单消失；3月5日，北美市场订单量单日暴跌99%，630万笔订单没了。
Amazon内部的调查文件，后来被Business Insider拿到了。文件里写着：Amazon自己的AI工具Q，是触发因素之一。文件原话是这么说的——”GenAI在控制平面操作中的使用，将加速暴露没有护栏的薄弱环节。”
然后，Amazon SVP Dave Treadwell签发了一个内部命令：90天重置。要求所有工程师更详细地记录代码变更，变更需要额外审批，在最重要的零售系统里引入”受控摩擦”。
先辟谣说”不是AI的问题”。然后悄悄发布了一套专门针对AI代码问题的整改措施。
另一边，微软的CEO Satya Nadella在2025年公开说，微软最多30%的代码现在由AI编写。到了2026年3月20日，微软Windows的执行副总裁Pavan亲自发了一篇博客，标题大概意思是”我们对Windows质量的承诺”。
博客里，他承认收到了大量用户对质量的负面反馈，承诺要重点改进性能、可靠性和”精心打磨的体验”。
还有一条值得注意的：微软在这篇博客里，专门承诺要减少Copilot在Windows里的入口点——包括截图工具、照片、记事本等各种地方。
一家公司，主动宣布要给自己的旗舰AI产品”减负”。
看到这里，你可能会想：这不就是AI还不够成熟、偶尔犯错吗？等模型再强一点，这些问题不就解决了？
我一开始也是这么想的。但有一个程序员的观察，让我改变了看法。
他叫Mario Zechner，是Pi agent框架的创建者，也是一个资深程序员。他最近写了一篇文章，专门分析这个问题，有一段话我觉得是目前对这个现象最准确的描述。
他说，人类是瓶颈——人类无法在几小时内产出两万行代码。即使犯错的频率很高，每天能引入代码库的错误也是有限的，积累得很慢。而且人类有痛感：当错误带来的麻烦大到一定程度，人会停下来去修，痛苦消失了，系统重新变得干净。但换成一支AI Agent大军，就没有这个瓶颈，也没有这个痛感。那些微小的、看似无害的错误，突然以不可持续的速度复利积累。你把自己移出了循环，所以你根本不知道，那些无数个小错误已经形成了一个怪物。
他说的不是”AI会犯什么错”，而是”AI犯错的方式和人类根本不同”。
人类犯错，有天花板。一个程序员一天能写多少代码？几百行，顶多几千行。错误再多，也是线性积累的。而且人类是有痛感的——代码越乱，改起来越痛苦，这个痛苦会逼着人去清理。
AI没有这个天花板，也没有这个痛感。它一天可以生成几万行代码，错误以同样的速度在复利。更关键的是，你不在里面，你感觉不到那个痛。等你察觉到出了问题，往往已经是一坨谁都解不开的烂摊子了。
而且还有另一层问题：AI做的每一个决定，都只是”局部决定”。
它不知道整个系统的全貌。它看不到其他AI之前做过什么决定，也看不到人之前做过什么决定。所以它会重复造轮子，会制造大量功能相似但互不相通的代码，会为了”完成任务”引入一堆没人要求的复杂度。
Mario把AI叫做”复杂性的商人”。我觉得这个比喻非常准。
它不是在帮你建一栋房子，它是在帮你堆砖头——堆得很快，堆得很多，但没有人统筹，没有设计，没有结构。等你回头一看，你有一堆砖，但没有房子。
人类团队做出的企业级烂代码，通常需要好几年才能腐烂到那个程度。因为人是有痛感的，组织会跟着复杂度一起慢慢调整。但用AI Agent，两个人的团队，可能几周就能把自己搞进同样的死局。
这不是因为AI不够聪明。而是因为速度和规模，放大了所有的问题。
说到这里，我想说清楚一件事：我不是在劝你不用AI。
AI写代码这件事本身没有问题。问题在于，很多人用AI的方式，是”把自己从循环里移出去”——设定一个目标，然后坐等AI交付。
Mario在文章里提了一个他认为正确的工作方式。他说，有些任务特别适合交给AI：范围明确、结果可以验证、就算出了问题影响也有限。比如让AI帮你把一份杂乱的会议记录整理成结构化的摘要——结果好不好，你读一遍就知道；或者让AI帮你测试一个功能的边界情况——跑完之后，通过就是通过，失败就是失败，一目了然。
但有些东西，不能交出去。任何定义”这个系统是什么”的决定，都应该是人来做的。 架构怎么设计，功能边界在哪里，这个东西要解决谁的什么问题——这些判断，需要你真正在里面待着，才能做好。
不是说不能用AI，而是说，要让自己始终保持对这个系统的理解和感知。因为只有你在里面，你才能感受到那个”痛”——哪里开始变复杂了，哪里的逻辑开始拧巴了，哪里需要停下来清理一下。
这个”痛感”，是人类作为开发者最重要的能力之一。你一旦把自己移出去，你就失去了它。
Amazon最终用”受控摩擦”来描述他们的整改措施。这个词选得很有意思。他们不是说要”减少AI的使用”，而是说要主动引入摩擦——让流程慢下来一点，让人重新介入进来。
这两家公司，在经历了真实的损失之后，都选择了同一个方向：不是跑得更快，而是慢下来，把人重新放回循环里。
“所有这些都需要纪律和主动性。所有这些都需要人类。”
AI能替你写代码，但替不了你的判断力和品味。而你的判断力和品味，是需要你真正参与进来才能保住的东西。
这不只是程序员的问题。任何一个领域，只要你开始把核心决策全部交给AI，你最终失去的，可能不只是那些任务本身，还有做好这些任务所需要的能力。
夜雨聆风
