AI写代码:越快越烂?

AI写代码:越快越烂?

八月 31, 2026 ai coding software quality developer productivity vibe coding technical debt

没人跟你说的生产力陷阱

咱们实话实说吧。AI 写代码确实厉害,那速度能让通宵加班的高级工程师都自愧不如。想要个 REST API?搞定。写个登录验证层?小意思。一个微服务架构?给我三十秒。

但有个让人不舒服的事实,没人把它印在大会演讲的 PPT 上:我们现在的代码产出速度,可能正在以软件史上最高的效率制造技术债务。

速度悖论

有个公式一直让我睡不着觉:

代码量 × 缺陷率 = 总 Bug 数

写出来看着很简单,但背后的含义挺吓人的。如果你的代码产量翻十倍,缺陷率保持不变,那你不仅仅是效率提高了十倍——你是以十倍的速度往系统里塞问题。

DX 的研究显示,人类团队的平均变更失败率在 5% 到 30% 之间。AI 写代码可能确实比平均水平干净一些,假设 AI 的缺陷率是人类的一半——这已经很厉害了。但如果同一个 sprint 里它产出了十倍的代码量,那你引入的 Bug 反而增加了五倍。

速度的提升不是免费的,是透支你未来的精力换来的。

没人注意到的模型坍缩

有个事儿我看到讨论得还不够:代码库里也会发生模型坍缩。

当 AI 生成的代码又成为训练下一代 AI 的素材时(因为你用 AI 去调试 AI 写的代码,调试结果又被 AI 分析……),你就会陷入一个"封闭语义循环"。代码模式越来越自说自话,越来越像是一个只看别人代码、而那个别人也只看这段代码的人写出来的。

这不是理论。用 AI 写代码很激进的团队已经在反映:他们的代码库越来越让新来的开发者看不懂了。不是因为业务领域本身复杂,而是 AI 生成的那些模式越来越偏离人类习惯的软件工程规范。

上下文窗口:隐形的天花板

人和 AI 在系统变得复杂的时候都会遇到瓶颈。区别在于,AI 工具往往不会告诉你它遇到瓶颈了。它会很自信地生成看起来没问题的代码,但实际上是误判了更宏观的系统上下文。

代码库越大,任何一段 AI 生成的代码引入隐蔽但致命 Bug 的概率就越高。人类程序员以前也有这个问题,但好歹人类会对系统的危险边界产生直觉。

AI 没有这种直觉。它有上下文窗口,而上下文窗口是有极限的。

真正管用的做法

我不是来批判 AI 写代码工具的。我自己用,我们团队也在用。这些工具确实香:

  • 快速生成样板代码
  • 解释不熟悉的代码逻辑
  • 写测试用例(真的可以)
  • 重构边界清晰的组件

不管用的做法:放出 autonomous AI 代理让它"把功能做出来",然后指望它能无缝融入一个活着的系统。

我观察下来,AI 用得好的团队都有这些共同习惯:

他们把 AI 的输出当成一个热情但没经验的新人写的初稿。 得有人带着上下文去 review。不是光检查对不对,还要看符不符合系统架构、命名规范,以及隐含的业务逻辑。

他们衡量结果,不衡量产出。 代码行数是虚荣指标。功能真正在生产环境跑起来花了多少时间?这才是真正的数字。而 AI 辅助的情况下,这个数字往往包含了大量返工的时间。

他们保持人始终在环里。 Human-in-the-loop 不是可选的,不是"有的话更好"。它决定了你半年后代码库是体面地老化还是变成谁都不敢碰的噩梦。

回形针最大化问题

Nick Bostrom 的思想实验讲的是:一个只想着造回形针的 AI,最后会把整个世界都变成回形针工厂。这个寓言现在看越来越应景了。看 AI 写代码工具的实际表现,你会发现:它们优化的是 token,是最可能出现的输出。它们不会为你的系统长期健康去优化,因为它们做不到——它们没有人类意义上的目标。

当你让 AI "随便改改"又没给清楚边界条件的时候,你实际上开启了一个不确定的优化循环。这种循环不会可靠地收敛到"能跑、安全、可维护"这个结果。

理想和现实

大家都说 AI 会搞定那些繁琐的活儿,让我们专注架构、创意和策略。这话没错。但过渡期很难熬。现在的情况是:

  • 代码生成的速度比 code review 的速度还快
  • 技术债务累积的速度,以前的老程序员看了都得吓一跳
  • "能用"和"可维护"越来越不是一回事

以前管用的那些实践——code review、测试、架构审查——现在不是没那么重要了,而是更重要了。恰恰因为代码生成那边已经快到飞起,我们更要在质量这边下功夫。

NameOcean 的看法

在 NameOcean,我们经常聊 vibe coding 和 AI 辅助开发,因为我们真心觉得这些工具能改变游戏规则。但变革不意味着变革没有代价。最快搞崩生产环境的路,就是觉得"AI 写的肯定没问题"。

我们正在做一些功能帮团队应对这个现实——更好的监控、更清晰的部署流程,还有能帮你在问题变成用户投诉之前就发现它的工具。

未来是 AI 辅助的。但未来还是需要工程师——真正懂什么是质量、并且愿意为质量较真的工程师。

慢就是稳,稳就是快。质量——那个无聊的、不酷的、花时间的质量——依然是软件开发里唯一可持续的竞争优势。

去造点厉害的东西吧。但合并 PR 之前,找个人先看看。

Read in other languages:

NL HU RO PL RU BG CS EL TR UZ SV FI PT NB IT FR ES DA DE EN