2026年1月，Linux内核社区正式发布了第三版AI代码辅助指南。

这份文档存放在内核代码库的Documentation/process/coding-assistants.rst中，全文59行、约1.82KB。

文档的核心内容并不复杂：AI生成的代码可以提交，但必须满足三条硬性规则——人类必须签名、必须标注来源、代码必须兼容GPL-2.0-only。

这三条规则看似简单，背后却是一场持续数月、甚至数年的争论。

三条规则

第一条：签名。

AI工具不能添加 Signed-off-by 标签。这个标签是 Linux 内核贡献流程的核心，用来认证开发者_certificate origin（DCO，开发者来源证书）。文档原文写得很直接："只有人类才能在法律上认证DCO。"

这意味着什么？即使你用AI写了一段代码，最终提交时必须由你来签名。你要对这段代码负责——负责它的正确性、负责它的许可合规、负责它可能带来的任何问题。AI只是工具，签字的那个人才是责任方。

第二条：归因。

AI生成的代码需要标注来源，格式是：Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]。

官方给出的例子是：Assisted-by: Claude:claude-3-opus coccinelle sparse。这行注释会永久保留在代码历史中，谁用了什么工具、什么版本，清清楚楚。

第三条：许可。

所有代码必须与GPL-2.0-only兼容。这条规定并没有因为AI的出现而改变——它一直是内核代码库的基本要求。

争论从何而来

这份规范的诞生并不是一帆风顺的。

2026年1月，内核邮件列表上爆发了一场激烈争论。英特尔工程师Dave Hansen和甲骨文员工Lorenzo Stoakes就"是否应该严格限制AI工具"针锋相对。Dave Hansen是x86架构维护者，最终也成为这份规范的主导者。

争论的导火索是NVIDIA工程师Sasha Levin的一次提交。他没有披露就提交了AI生成的Linux补丁，代码能跑，但性能很差。这个案例被反复引用，成为"AI工具需要规范管理"的标志性事件。

类似的问题不只发生在Linux社区。cURL项目被大量AI幻觉代码淹没，被迫关闭了漏洞奖赏计划。Node.js和OCaml收到了上万行由AI生成的补丁，给维护者造成了沉重负担。

这些事件说明一个问题：AI工具正在以前所未有的速度向开源社区渗透，而社区的规则还没有准备好。

Linus怎么说

关于AI，Linus Torvalds的态度一直很鲜明。

他说过："全面禁止AI只是毫无意义的作秀。AI只是工具。提交垃圾代码的人本来就不会遵守规则，与其限制开发者用什么工具，不如直接追究'提交者'的责任。"

这个立场很实际。禁止AI不会让烂代码消失，只会让用AI的人隐瞒自己用了AI。与其这样，不如把规则定清楚：可以用，但你签字、你负责。

Linux这份规范正是这种思路的体现。它没有禁止AI，而是把责任框定清楚——工具可以换，签字的人不能换。

其他开源社区怎么做

不是所有项目都和Linux持相同立场。

NetBSD和Gentoo直接禁止了AI生成的代码。Gentoo的担忧尤为特殊：他们认为大模型生成的内容在法律上属于"污染"，因为训练数据的版权来源不明确。开发者无法保证AI输出的代码不会侵犯他人的版权许可。

这是Linux没有正面回应的问题。Linux选择用"人类签字"来解决责任归属，但没有回答一个更根本的问题：如果AI训练时用了GPL代码，而AI生成的代码恰好与这些GPL代码相似，法律责任该如何界定？

DCO要求开发者确保自己对代码拥有"贡献权"，但AI模型的训练过程并不透明。这个问题目前没有答案。Linux规范选择搁置它，但问题不会因为搁置而消失。

规范能解决问题吗

效果可能有限。

对于本来就守规矩的开发者，这份规范提供了清晰的指引——他们会照着做。对于不守规矩的人，规范的作用就更复杂：他们可能不会遵守，也可能不会披露自己用了AI。

真正能约束行为的，不是文档，而是流程和文化。Linux内核社区有着几十年的贡献文化，提交者习惯了对自己的代码负责。这种文化背景让规范更容易落地。对于一个刚刚开始接收AI贡献的新项目，情况可能会完全不同。

从另一个角度看，这份规范的价值或许不在于它写了什么，而在于它承认了什么。它承认AI工具已经成为现实，承认社区必须面对这个问题，承认在这个问题上有共识、也有分歧。

开源社区一直信奉"粗略共识、代码为王"——如果有分歧，就让代码说话。现在，在AI这个问题上，Linux内核社区选择先把话说清楚，再让代码继续说话。