凌晨两点，一位开源项目维护者的 GitHub 邮箱中，又静静躺进了第 47 封来自“热心开发者”的 Pull Request（PR）。邮件内容相当详实，包含数千行代码，附带了详细的“修复说明”和“性能优化分析”。然而，当维护者真正开始审查时，问题立刻暴露：一个简单的循环判断被改得面目全非，原本仅 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（开发者来源证书）时，他声明的不仅是代码从哪里来，更是在承担这段代码未来可能带来的长期责任，包括 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 社区说得很直白：大模型生成的内容在法律层面可能构成污染，因为来源无法确认。与其承担不确定的风险，不如直接一刀切。
交锋：Linux 内核的内部战争
面对 AI 代码的渗透，Linux 内核社区内部并非铁板一块。
两种声音
2024 年，Linux 内核两位重要维护者之间的公开争论，把这场分歧摆到了台面上。
Dave Hansen（Intel 工程师，长期负责内核内存管理相关工作）主张对 AI 生成代码施加更严格的限制。他担心，如果社区不尽快设定边界，AI 代码会一点点稀释内核代码库的质量，最终伤害这个运行在全球数十亿设备上的操作系统。
而 Lorenzo Stoakes（活跃的内核开发者，以直言不讳著称）则走了另一条思路。他认为，与其费力去甄别每一行代码到底是不是 AI 写的，不如把重点放回到真正关键的问题上：无论用了什么工具，人类提交者都必须为结果负责。
两种观点其实各有逻辑。前者强调预防胜于治疗，后者强调结果导向的责任制。
Linus 出场
最终，给这场争论定调的，还是 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 后续的治理路线定下了基调：不问出处，只问责任。
破局：59 行文档的重拳
2024 年底，Linux 内核正式发布了关于编码助手（Coding Assistants）的官方指南。这份文档只有 59 行，却把 AI 代码参与贡献时最关键的责任链条说得非常清楚，也因此被很多人视作 Linux 对 AI 垃圾代码的正面回应。
三条铁律
文档开篇就给出了三条几乎不可退让的原则。
铁律一：AI 不得签署
规则写得非常直接：
AI agents MUST NOT add Signed-off-by tagsDCO 是开源贡献最基础的法律承诺之一，它声明了代码来源，也声明了提交者有权以对应许可证提交代码。只有具备法律人格的人类才能签署这份承诺，AI 显然不具备这个资格。
铁律二：人类承担全部责任
Linux 文档明确规定，人类提交者才是代码质量的第一责任人。这件事具体落到行动上，至少包括四点：
- 彻底审查 AI 生成的每一行代码
- 确保代码符合许可证要求
- 添加 Signed-off-by 声明
- 对未来可能出现的任何问题承担全部责任
说得更直白一点，不管你用了多少 AI，最后负责背锅的都只能是提交者自己。
铁律三：透明披露 AI 参与
如果你的提交有 AI 参与，必须通过 Assisted-by 标签进行披露。文档给出的标准格式是：
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]例如：
Assisted-by: Claude:claude-3-opus coccinelle sparse这条规则的关键，不是给提交者免责，而是把信息摊到台面上。审查者一旦知道这段代码有 AI 参与，就可以自然地提高审查强度。
解读
很多人会觉得，Linux 没有直接封杀 AI 代码，是不是等于放行？恰恰相反。它给出的其实是一套更锋利的责任框架：用了 Assisted-by，就要承担更多解释义务；签了 DCO，法律责任也不会转移给模型；文档反复强调 thoroughly reviewed，说明质量门槛并没有降低。相比一刀切禁令，Linux 更务实，但底线很硬：工具可以进来，责任不能稀释。
