AI 编程更快，但软件会更快崩坏吗？

随着大模型被广泛用于代码生成，一种乐观的论调正在蔓延：AI 已经比人类更会写代码。然而，一篇发表于 Hacker News 的技术评论提醒行业，"会写代码"并不等同于"会开发并维护软件"——若不调整工程实践，AI 编码的洪流可能把团队更快冲进难以收拾的遗留代码泥潭。

核心论点：缺陷率与速度的乘法

作者给出的第一个论据是一道简单的乘法题：

• 缺陷数 = 变更次数 × 单次变更缺陷率

根据 DX 等机构的调研，人类团队的变更缺陷率分布在 5% 到 30% 以上。假设 AI 在质量上追平甚至略胜人类，例如缺陷率仅 5%，但提交变更的速度是人类的 10 倍，那么单位时间内的缺陷数会从原来的 1 上升到 5。"速度提升 10 倍，缺陷数也涨了 5 倍"——而如果 AI 的单次缺陷率仍高于人类平均，情况会更糟。这意味着：

• 写一次性脚本或原型时，AI 的高产是优势；
• 但对于需要长期维护的生产代码，更高的吞吐量反而会拖累团队。

更棘手的是，AI 也能修 bug，但当它制造的 bug 是被修复 bug 的若干倍时，整体生产力的提升就会被吞噬。

模型坍塌：AI 写 AI 读的代码库

"模型坍塌"原本指机器学习模型在合成数据上反复训练后逐步退化的现象。作者认为，AI 生成的代码库内部也会出现类似问题：随着代码库中 AI 生成内容占比上升，token 模式越来越自指式，模型在尝试继续修改时越来越难以保持一致性。换言之，让 AI 反复编辑自己写出的代码，其输出的连贯性会随时间下降。

上下文限制：复杂度是所有人的敌人

第三个限制是上下文窗口。代码库越大、依赖越深，理解并安全修改它所需的上下文就越多，无论是人还是 AI 都会因此变慢、变笨。AI 编码的提速只是把这个"项目越复杂越难推进"的固有瓶颈更早触发，让软件更快滑向"满是 bug 的大泥球"。

该怎么办：质量优先于速度

作者并不否认 AI 编码的总体价值，但也强调，要真正用好它，必须把工程实践摆在模型能力之前：

• 短期：把质量放在速度前面。DevOps 与敏捷运动积累了几十年的经验，"慢即是稳，稳即是快"的判断同样适用于 AI 编程。
• 中期：保持任务离散且可验证。开放式的"让 AI 自己修 bug 循环"目前并不能稳定收敛；脱离监督的全自动修 bug 流程，最终往往把系统推向不可用甚至不安全。
• 长期：自愈式软件仍是值得追求的方向，但必须保留人在环中（human in/on the loop），否则非确定性的 AI 代理很容易把代码变成"回形针"。

在作者看来，AI 让"值得保留的代码"在总产出中的比例下降了，工程团队要做的不是追赶 AI 的速度，而是重新校准对质量、可维护性与变更节奏的期待。