AI代码垃圾不是模型不行，是成本塌了

7月8日，Linus Torvalds 在孟买开源峰会上说了句话。他说自己"已经不是程序员了"。

这话被当成标题传了一周。真正重要的不在这里。

他说了另一句："大模型生成的垃圾远多于有用代码。"

媒体抓到了。读者确认了偏见。然后呢？然后所有人停在了"AI 产垃圾"这个结论上，没有人追问一句：为什么会这样？

不是模型不够强。不是因为 AI 写不好代码。

是因为写代码这件事，成本塌了。

我手写代码的时候，"要不要写"是先于"怎么写"的问题。每个函数进来之前脑子里要过一遍：这个东西真需要吗？怎么和现有模块衔接？写完谁维护？这些问题的答案决定了写不写、写多少。

但 AI 改了游戏规则。

现在"能不能写"取代了"要不要写"。打字变成回车。不用再在动手之前先想清楚，直接让 AI 生成一版看看效果就行。

试错成本从"几个小时想清楚→写代码"变成"一句话→看结果"。这种成本塌缩是好东西——快速原型、探索性编程、自己不熟悉的语言——Linus 自己的 AudioNoise 项目就这么干的。Python 他不太熟，让 AI 写，他在 C 那边手写 DSP 核心。

但成本塌缩有另一面。

当"写一段代码"的成本趋近于零，"要不要写这段代码"的判断就被跳过了。 你不需要先想清楚——试一下嘛，反正不要钱。

从手写时代到 AI 成本塌缩的连锁反应

Linus 在这次演讲里用了一个特别的说法。他说 AI 补丁是"无意义的创可贴"——或许能解决当前问题，但类似的 bug 仍然留在那里，"随时可能在其他地方再次出现"。

这话仔细想想——它不是 AI 代码质量低。是 AI 在修一个它不理解的东西。

AI 看到 bug → 找到触发位置 → 修掉。但它不知道这个 bug 是什么时候引入的，为什么那时候没被发现，当时的代码还想做什么，修完会不会在隔壁炸。这些东西不在代码文件里。它们在维护者脑子里，在多次合入冲突中积累的模式识别里，在"上次这个模块出过类似问题"的记忆里。

Linus 说"我读解释多于读 diff"，这句话是整个演讲的钥匙。

解释是理解的测试。代码是理解的产物。AI 可以跳过理解直接产代码。产物看起来是对的——直到走廊里的 bug 来敲你的门。

这事还有一个维度，Linus 5月份就说过了。

Linux 内核的安全邮件列表被 AI 漏洞报告淹了。不同安全研究员用相同工具扫出相同漏洞，各自独立提交。维护者大量时间花在转发重复报告、解释"这已经修过了"。

生产漏洞报告的成本变成了零。审查成本不变。

生产在一端，成本在另一端。没有定价机制。

Linus 的方案很直接：AI 能扫出来的漏洞大概率别人也扫出来了，所以不用走私密安全通道。把门打开，让所有人看到重复提交。

到 7月15日，他更进一步——在 LKML 上直接回怼："Linux 不是反 AI 项目。反对 AI 你就 fork。"

不禁止 AI。不能禁止——成本塌缩不可逆。但必须透明。1月份写进内核文档的三条铁律很简单：AI 不能签 DCO，用了 AI 必须标注 Assisted-by，出 Bug 你扛。

这些政策在回应同一件事：成本塌缩之后，门槛要重新建。

以前的门槛是能力——你会不会写。这个门槛被 AI 抹掉了。现在要建的门槛是判断——你知不知道该不该写，你理没理解你改的东西。

Linus 怎么测这个？他读解释。

"解释告诉我发送变更的人是否真的理解他在做什么。"

代码可以骗人。解释比代码难骗。你能写出一段看起来对的代码，但很难写出一段听起来对的解释——除非你真的理解了。

有个事特别能说明问题。

今年1月，Linus 用 AI 给自己的 AudioNoise 项目写了个 608 行的 Python 波形可视化器。同时手写了 C 的 DSP 核心。C 那边有全套验证测试，Python 那边——零测试、零类型提示、一个 try/except。

6个月后，有人用 git log 查了这个仓库。

同一个方法被定义了两次。一次是截断的 stub，一次是完整版。Python 默默覆盖了第一版，代码能跑，不报错。

这个死函数存活了 6 个月。4400 个 star，207 个 fork，20 个后续 commit，没人发现。

不是没人看——那个方法调了 matplotlib 的 save，正常运行。是没人读。所有人引用 README，没人读 diff。dead code 不 crash，它只是等。

Linus 自己说的："在自己最强的领域手写、最弱的领域用 AI"——这个建议有一个从来没人引用的推论：你在最弱的地方也最弱于审查。

成本塌缩不是坏事。编译器把汇编成本打下来的时候，也没人想回去。

问题不在工具。在使用工具的人有没有把"判断力"当成需要重新训练的能力。

Linus 把话说得很平："希望 AI 创造的生产力能超过它造成的损失。"这不是唱衰。这是诚实。

如果你用 AI 写代码，你应该不需要我这篇文章。

但如果你在用 AI 决定要不要写代码——你可能需要的是 Linus 那句："我读解释多于读 diff。"然后你试一次。下次交 PR 之前，先写下这个改动要解决什么问题、为什么这样解决、改了会影响什么。写完之后再跑 AI。

你会发现有些代码根本不需要存在。