AI 垃圾代码围城,看 Linux 如何破局

当 AI 开始批量生产代码，全球最大的开源项目正在经历一场前所未有的信任危机。Linux 用一份只有 59 行 的文档，给出了自己的答案。

凌晨两点，某位开源维护者的 GitHub 邮箱里，又躺进了第 47 封 来自热心开发者的 PR（Pull Request）。邮件写得很满，几千行代码，附带详细的修复说明和性能优化分析。可当维护者真正开始审查时，问题很快就暴露了：一个简单的循环判断被改得面目全非，原本 10 行的函数膨胀到 89 行，所谓的优化在基准测试里反而让性能下降了 40%。

这不是孤例。到了 2024 年，这类场景已经在开源社区反复上演。各个社区公开披露的问题看起来细节不同，症状却高度一致：措辞模板化，代码结构臃肿，边界条件处理草率，对项目历史和设计哲学几乎没有理解。

cURL 项目的维护者 Daniel Stenberg 无奈关闭了运营多年的漏洞赏金计划，原因不是没人报漏洞，而是太多 AI 生成的漏洞报告涌了进来，维护者根本没有精力逐一甄别。Node.js 生态系统收到过一个包含数万行修复补丁的 PR，提交者声称这是 AI 协助开发的成果，结果审查下来几乎没有可以合并的内容。OCaml 核心项目也遭遇了类似的 AI 补丁轰炸。

而 Linux 内核，这个全球最重要的开源项目之一，同样没能置身事外。

2024 年 9 月，内核维护者 Sasha Levin 被发现曾在未做说明的情况下提交过多段由 AI 生成的代码。它们虽然能通过编译测试，但经过社区复核后，暴露出明显的性能问题：部分路径的执行效率远低于原有实现。更麻烦的是，一旦社区想追溯这些代码的真实来源，过程几乎无从下手。AI 生成了代码，署名却是一个人类维护者。

这场攻击没有病毒，也没有漏洞利用，但它正在用另一种方式拖垮开源社区：海量看似合理、实则质量堪忧的代码，正在淹没维护者有限的时间和精力。

AI 垃圾代码的泛滥，把开源社区推入了一个典型的三难处境。

传统代码审查依赖维护者对项目的深度理解。他们检查的从来不只是语法是否正确，还要判断代码是否符合项目风格，是否贴合既有架构，是否埋下潜在的性能或安全问题。AI 生成的代码最麻烦的地方，就在于它往往具有很强的迷惑性：能过基础检查，也可能过掉部分单元测试，但深层逻辑里埋着隐患。

一个很常见的特征是，AI 特别容易过度工程化。明明一个简单条件判断就能解决的问题，它偏要包成三层函数调用；明明标准库已经有现成方案，它却再手写一遍近似实现，边界条件还处理不完整。更糟的是，这类代码表面上往往很像样：术语正确，格式整齐，甚至注释充足，但就是不符合项目真正的工程需求。

开源社区的协作，本质上是建立在人与人之间的信任之上。当一位开发者提交代码并签署 DCO（Developer Certificate of Origin，开发者来源证书）时，他声明的不只是代码从哪里来，更是在承担这段代码未来可能带来的长期责任，包括 bug、安全漏洞和许可证问题。

但 AI 生成代码把这个边界冲淡了。当一段代码真正的生产者是一个无法被追责的模型时，Signed-off-by 这个签名到底还意味着什么？如果代码出了问题，最后该被问责的是签字的人类提交者，还是那个吐出代码的 AI 系统？

这种模糊性正在侵蚀开源协作最核心的基础。社区成员越来越难判断，收到的 PR 到底有多少是真正经过人类思考和审查的结果。当质量问题的根源都难以追溯时，整个代码审查机制也就难免被动摇。

更深的一层，是法律风险。AI 模型的训练数据来自互联网，其中天然混杂着大量开源代码。当用户要求 AI 生成一段实现某个功能的代码时，生成内容很可能与训练集中的某段实现高度相似，而那段实现背后，可能是 GPL、MIT、Apache 等完全不同的许可证体系。

对 Linux 内核来说，GPL-2.0-only 许可证本身就是护城河之一。即便 AI 吐出了 GPL 许可代码，只要最终进入 Linux，许可证链条通常还是自洽的。但对大量采用 BSD、MIT 等宽松许可证的项目来说，风险就复杂得多：如果 AI 无意中混入 GPL 代码，项目方可能直接踩进许可证雷区。

这也是 NetBSD 和 Gentoo 等项目直接禁止 AI 生成代码的重要原因。Gentoo 社区说得很直白：大模型生成的内容在法律层面可能构成污染，因为来源无法确认。与其承担不确定的风险，不如直接一刀切。

面对 AI 代码的渗透，Linux 内核社区内部并不是铁板一块。

2024 年，Linux 内核两位重要维护者之间的公开争论，把这场分歧摆到了台面上。

Dave Hansen（Intel 工程师，长期负责内核内存管理相关工作）主张对 AI 生成代码施加更严格的限制。他担心，如果社区不尽快设定边界，AI 代码会一点点稀释内核代码库的质量，最终伤害这个运行在全球数十亿设备上的操作系统。

而 Lorenzo Stoakes（活跃的内核开发者，以直言不讳著称）则走了另一条思路。他认为，与其费力去甄别每一行代码到底是不是 AI 写的，不如把重点放回到真正关键的问题上：无论用了什么工具，人类提交者都必须为结果负责。

两种观点其实各有逻辑。前者强调预防胜于治疗，后者强调结果导向的责任制。

最终，给这场争论定调的，还是 Linus Torvalds 本人。

在 Linux Plumbers Conference 上，面对社区关于 AI 代码治理的提问，Linus 直接给出了一句非常典型的回应：

There is zero point in talking about AI slop. That's just plain stupid.

他的意思很明确：纠结这是不是 AI 写的，本身就是一个偏题的问题。真正重要的只有两件事：代码质量过不过关，提交者愿不愿意承担责任。

Linus 的逻辑其实很朴素。AI 只是工具，就像编译器、静态分析器一样。问题从来不在工具本身，而在使用工具的人。如果代码有问题，无论它是人写的，还是 AI 辅助生成的，都应该被拒绝；如果代码质量过硬，那么背后具体用了什么工具，并不是首要问题。

这个表态，基本为 Linux 后续的治理路线定下了基调：不问出处，只问责任。

2024 年底，Linux 内核正式发布了关于编码助手（Coding Assistants）的官方指南。这份文档只有 59 行，却把 AI 代码参与贡献时最关键的责任链条说得非常清楚，也因此被很多人视作 Linux 对 AI 垃圾代码的正面回应。

文档开篇就给出了三条几乎不可退让的原则。

铁律一：AI 不得签署

规则写得非常直接：

DCO 是开源贡献最基础的法律承诺之一，它声明了代码来源，也声明了提交者有权以对应许可证提交代码。只有具备法律人格的人类才能签署这份承诺，AI 显然不具备这个资格。

铁律二：人类承担全部责任

Linux 文档明确规定，人类提交者才是代码质量的第一责任人。这件事具体落到行动上，至少包括四点：

说得更直白一点，不管你用了多少 AI，最后负责背锅的都只能是提交者自己。

铁律三：透明披露 AI 参与

如果你的提交有 AI 参与，必须通过 Assisted-by 标签进行披露。文档给出的标准格式是：

例如：

这条规则的关键，不是给提交者免责，而是把信息摊到台面上。审查者一旦知道这段代码有 AI 参与，就可以自然地提高审查强度。

很多人会觉得，Linux 没有直接封杀 AI 代码，是不是等于放行？恰恰相反。它给出的其实是一套更锋利的责任框架：用了 Assisted-by，就要承担更多解释义务；签了 DCO，法律责任也不会转移给模型；文档反复强调 thoroughly reviewed，说明质量门槛并没有降低。相比一刀切禁令，Linux 更务实，但底线很硬：工具可以进来，责任不能稀释。