AI写代码:越快越烂?
没人跟你说的生产力陷阱
咱们实话实说吧。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 之前,找个人先看看。