AI 编码导致脆弱的代码库
原文：AI usage generates a fragile codebase 作者：Evan X. Merz 日期：2026-11-07 标签：
编程、AI、LLM、Web 开发译注：文中的「我」均指原作者 Evan X. Merz。
我只能猜测自己五月份被 Meta 裁掉的原因，但我怀疑其中之一是：和同事相比，我对把 AI/LLM 当作编码工具这件事多了一点抵触。别误会，在最后几个月里，我至少有 90% 的代码是用 AI 生成的，这是拿到一个还算过得去的绩效评级的最低门槛。但 AI 并没有让我写出十倍的代码，甚至连两倍都没有。
我在意的是代码质量。我看到一些重度依赖 AI 的同事在推代码，也看到那些代码有多脆弱。里面有很多微妙的问题，长期来看会堆积成技术债，而一些明显的问题也被非常优秀的程序员忽略了。举个例子：我见过我们组最好的程序员之一，试图合入一段用 JavaScript 事件来实现鼠标悬停 CSS 效果的代码，而不是用 :hover 选择器，这种写法完全不具备可扩展性。
现在我在另一家大型科技公司工作，已经完全转向了 100% 用 AI 生成代码，因为这就是今天的期望。然而我依然能看到，越来越多的人开始意识到，对于大规模 SaaS 产品的持续开发而言，这条路走不通。AI 非常擅长解决那些能装进上下文窗口（context window）的问题，但它对那些无法在这个有限视野里被理解的长期问题完全视而不见。
在这篇文章中，我要列出 AI 编码导致代码库脆弱的四种方式，这种脆弱让代码库无法应对高可用、高可扩展 SaaS 应用的要求。
顺便说一句，这篇文章的每一个字都是人写的。虽然下面的题图是 AI 生成的，但文章本身不是 AI 泔水。
AI 让代码库脆弱的四种方式
以下是我观察到的 AI 导致代码库脆弱的四种最常见方式。
1. AI 写的测试很浅
现代 LLM 最明显的缺陷之一，是它们倾向于写简单的自动化测试用例，覆盖不到真正对人类有意义的地方。我经常看到 AI 智能体写了一堆测试 getter/setter 方法的用例，这些方法本身就微不足道，通常不需要太多测试。当 AI 写端到端测试（e2e test）的时候，它们往往只覆盖代码库中已经被覆盖过的场景。换句话说，AI 写的测试只针对一种类型的用户，或者只停留在表面的交互上。这会在测试覆盖率中留下巨大的缺口，而开发者看不到这些缺口，因为行级覆盖率指标反映不出来。
2. AI 写的代码过于复杂
AI 还倾向于写过度复杂的代码。它经常在一个辅助方法就够用的时候用上两三个。它试图严格遵守 DRY（Don't Repeat Yourself）等编码规范，但矫枉过正了，没有意识到这种死板带来的额外复杂度反而让代码更难被人类开发者调试和理解。
3. 依赖 AI 会降低人类的理解力
这就是 AI 代码库的第三个问题：人类不理解它们。一家公司越长时间依赖 AI 智能体来生成代码，能理解代码库的开发者就越少。这意味着开发者做不了那些构建健壮代码库所必需的事情。他们对数据结构和算法的理解不够深入，看不出一个 PR 里新引入的抽象是否与已有的架构相矛盾。
4. AI 速度太快，质量标准跟不上
AI 太快了，快到人类开发者无法维持一个高质量标准。每个 PR 来得比上一个更快，留给审查的时间更少。这导致开发者只能走马观花地看代码，遗漏那些会变成长期技术债的关键细节。测试缺口、命名不当的变量，这些小的质量问题在代码库里不断累积，直到整个代码库变成一团意大利面条式的烂泥。
代码库已经脆弱的四个信号
如果你不确定编码智能体是否正在伤害你的代码库，可以留意以下这些脆弱的 AI 生成代码库的症状。
1. AI 生成的代码库事故更多
当你把部门切换到智能体编码之后，事故数量是不是慢慢开始上升了？一开始我们都在用智能体大量生成代码的时候，看起来和传统编码没什么两样。PR 来了，合入了，一切似乎都好好的。但月底出了一个 P0 事故，下个月又出了两个 SEV，然后更多。现在，经过一两年的智能体编码，好像每个周末都有事故。AI 编码智能体正是影响客户的事故越来越多的原因。
2. AI 代码库的事故恢复时间更长
不仅事故更多了，恢复时间也更长了。事实是，你团队的人类开发者现在对代码库的理解更浅了。如果你的编码智能体找不到客户遇到的问题，人类就得在一个高度复杂、测试不足的代码库里翻找。他们本质上是在进入一片陌生的领域，所以需要更长时间才能搞清楚到底出了什么问题。于是，公司在那些恢复时间越来越长的事故上损失越来越多的钱。
3. AI 生成的代码库会产生只有用户才能看到的错误
当人类不花时间待在代码里的时候，他们就看不到所有的使用场景。他们无法理解真实用户是如何使用代码的，因为他们没有确保 AI 正确地埋入了分析埋点、正确地捕获了所有错误。于是，隐形的错误开始在代码库中出现。这些错误没有被捕获，只对真实用户可见，而不是自动化测试或开发者手动测试中所覆盖的那类用户。
4. AI 导致糟糕的用户体验
这就引出了 AI 代码库的终极问题：它们不是为人类做的。AI 代码库是 AI 为 AI 写的软件。它们没有为人类用户的使用方式做优化，也没有为人类开发者的维护方式做优化。用户端和开发者端的体验同时退化，形成一个恶性循环，持续的「劣质化」（enshittification）。
为人类做的产品需要人的参与
事实就是：一款产品要让人类客户满意，就必须有人类视角的注入。没有人喜欢在餐厅对着机器点餐。在网站上买衣服永远比不上去店里试穿合身。SaaS 产品也是同样的道理。任何时候你把 SaaS 产品交给机器，你都在失去那种对用户和开发者都有价值的人情味。对于那些只拼价格的最廉价产品，这或许行得通；但高质量的软件产品将继续保留人的参与。最好的、最贵的产品，将由人类开发者为人类用户量身定制。它们会让人觉得有魅力、用起来愉快。它们不会脆弱，因为它们不是主要由 AI 开发的。
