文章作者： Tina

文章来源：InfoQ

吵了几个月之后，Linus Torvalds 和 Linux 内核维护者终于把 Linux 内核第一套 AI 辅助代码规则定下来了。这套新规很符合 Torvalds 一贯的务实风格：AI 工具可以用，但 Linux 内核对代码质量的高要求一点也不会放松。

新指南主要定了三件事。

第一，AI 代理不能添加 Signed-off-by 标签

只有人类才能合法签署 Linux 内核的开发者来源证明（Developer Certificate of Origin，DCO）。这是确保代码许可合规的法律机制。换句话说，即便你提交的补丁完全由 AI 编写，责任仍然只在你本人，而不是 AI 或其提供方。

第二，必须标注 Assisted-by（辅助来源）

如果在内核开发过程中用了 AI 工具，就要把来源写清楚，这样大家才能知道 AI 在这次提交里到底参与了多少。相关代码贡献需要按下面这个格式加上 Assisted-by 标签：

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

这里需要把你用了什么模型、什么 Agent、还有哪些辅助工具说清楚。比如 AGENT_NAME 是你用的 AI 工具或者框架名称；MODEL_VERSION 是具体用的模型版本；[TOOL1] [TOOL2] 是可选项，用来写这次还搭配用了哪些专门的分析工具，比如 coccinelle、sparse、smatch、clang-tidy。像 git、gcc、make、编辑器这些日常基础工具，就不用写进去了。

比如，如果你用的是 Claude 的 claude-3-opus，同时还配合 coccinelle 和 sparse 做分析，就可以这样写：

Assisted-by: Claude:claude-3-opus coccinelle sparse

第三，人类承担全部责任

把前面几条合起来看，意思其实很明确：AI 可以参与写代码，但责任不能转嫁给 AI。AI 生成的代码有没有经过完整审查，许可证是不是合规，后续如果出了 bug 或安全漏洞，最后都要由提交代码的人来负责。

不要试图把有问题的代码偷偷混进内核。2021 年明尼苏达大学的那起事件，就是一个典型的前车之鉴。否则，你基本可以告别 Linux 内核开发者身份，以及任何严肃开源项目的参与机会。

那次事件里，明尼苏达大学一组研究人员以安全研究的名义，故意向 Linux 内核提交带有缺陷、甚至可能引入漏洞的补丁，想借此测试社区能不能识别并拦下这些“有问题的修复”。问题不只在于补丁本身有问题，更在于他们事先没有告知社区，而是直接把维护者和开发者当成了实验对象。

事情曝光后，Greg Kroah-Hartman 公开批评这种做法浪费社区时间、破坏协作信任，相关提交被集中审查和回滚，明尼苏达大学的后续贡献也被 Linux 社区封禁，成为内核社区至今仍反复引用的反面案例。

1  Claude 已经够强了，但在内核里还只是工具 

Assisted-by 标签既是透明机制，也是一个“提醒标记”。它让维护者在不污名化 AI 使用的前提下，对 AI 辅助的补丁进行更严格的审查。

这个标签的出现，其实源自一场不小的争议。

争议的起点，是 Nvidia 工程师、知名 Linux 内核开发者 Sasha Levin。在 2025 年北美开源峰会上，他分享了自己用 LLM 改进内核的一些实践。

他认为 LLM 本质上就是一个参数规模巨大的模式匹配引擎，可以看作一个“超大的状态机”。不同的是，内核里常见的状态机是确定性的，而 LLM 的状态转移是概率性的。给定一段上下文，它会预测“下一个最可能的词”。比如输入“the Linux kernel is written in...”，它几乎一定会输出 “C”，但也存在较小概率输出 “Rust” 或 “Python”。

同时，LLM 依赖“上下文窗口”工作，也就是它在回答时能够“记住”的输入文本。像 Claude 这样的系统，上下文窗口大约在 20 万 token 左右，已经足够覆盖一个完整的内核子系统。

Levin 并不认为 LLM 会取代人类做内核开发。他更愿意把它看作“下一代编译器”。过去开发者写汇编，后来有了高级语言；当时也有人不认可，说“真正的开发者应该自己分配寄存器”。但最终大家还是接受了更高层的工具，生产力也随之提升。LLM 也是类似的演进——它不完美，但已经足够带来效率提升。

他举了一个例子：Linux 6.15 中合入的一个补丁，署名是他，但代码实际上是由 LLM 完整生成的，连 changelog 也是。Levin 对代码做了审查和测试，但并没有亲自编写。他认为，这类“小而明确”的任务正是 LLM 的强项，但还没到可以让它独立写出一个全新设备驱动的程度。

LLM 在写 commit message 上也很有帮助，而这件事往往比写代码本身更难，尤其对非英语母语的开发者来说。

他还展示了补丁中的一段修改。

这里从一个哈希 API 切换到另一个，需要把“大小”改为“2 的幂表示”。LLM 正确理解了这一点，并做了对应修改。它还在补丁后面意识到一个 mask 操作其实是多余的，于是直接删除。Levin 表示，这段代码既正确，也高效。

围绕这件事，社区也讨论了更多问题。比如，有人问：会不会因为过度信任 LLM 输出而引入错误？Levin 的回答是：LLM 会出错，人类也会，而且经常会。还有人问代码的许可证问题，他表示自己并没有深入考虑，直觉上认为模型生成的代码是可以使用的。

最后也有人问，这套方法能不能用于代码合入前的自动审查。Levin 表示技术上是可行的，但规模太大、成本太高，目前还不现实，不过未来有可能做到。

这场风波的一个直接结果是：Levin 本人开始支持建立 AI 使用的透明规则，他提交了第一版提案，也就是后来内核 AI 政策的雏形，最初建议用 Co-developed-by 来标记 AI 参与。

随后，无论是线下讨论还是 Linux Kernel Mailing List（LKML）上的交流，都在争论是引入新的 Generated-by 标签，还是复用现有的 Co-developed-by。最终，维护者选择了 Assisted-by，更准确地体现 AI 作为“工具”的角色，而不是“共同作者”。

最终选择 Assisted-by 而不是 Generated-by，主要基于三点考虑：

第一，更准确。内核开发中 AI 更多用于辅助（代码补全、重构建议、测试生成），而不是完整生成代码；

第二，格式一致。它与 Reviewed-by、Tested-by、Co-developed-by 等现有标签保持一致；

第三，中性表达。既说明了工具的参与，又不会暗示代码“不可信”或“低一等”。

这种务实路线，其实也和 Torvalds 的态度一致。他说：“我不希望内核开发文档变成某种 AI 立场声明。‘世界要完了’和‘AI 会彻底改变软件工程’这两种声音已经够多了。我不希望文档站队。对我来说，它就应该是——AI 只是一个工具。”

2  一夜之间世界就变了，规则也只能跟着改 

这一决策背后，一个很重要的现实变化是，AI 编程助手在内核开发里，突然开始变得“真的有用”了。

上个月，Linux 稳定内核维护者 Greg Kroah-Hartman 提到，几个月前，内核社区面对的还主要是所谓的“AI slop”，也就是那些明显不对、质量很低的 AI 生成安全报告。“当时甚至还有点好笑，也不太让人担心。”当然，Linux 内核有很多维护者，对他们来说，这类垃圾报告的压力远没有 cURL 那样大。cURL 的创始人兼主要开发者 Daniel Stenberg 就因为 AI 垃圾报告太多，一度暂停了漏洞赏金。

但情况已经变了。Kroah-Hartman 说，大概一个月前，也就是约在 2 月份，某个节点发生了变化，“整个世界都切换了。现在我们收到的，是‘真的’报告了。”

而且不只是 Linux。他提到，现在很多开源项目都在收到 AI 生成的报告，而且这些报告是好的、真实的。各大开源项目的安全团队之间一直有非正式的沟通，大家都观察到了同样的变化。换句话说，这已经不是 Linux 一家的问题，而是整个开源安全圈同时遇到的新情况。

至于到底发生了什么，没有人说得清。被问到变化的原因时，他说：“我们也不知道。没人知道为什么。可能是很多工具突然变好了，也可能是大家开始认真用这些工具了。看起来是很多不同的团队、不同的公司同时在做这件事。”

“这些工具确实挺好用的，我们没法忽视它们：它们已经来了，而且还在变得更强。”

北京时间周一，Linus Torvalds 发布了 Linux 内核 7.0。对他来说，这次升级到 7.0 并不意味着什么“重大版本转折”，更多只是版本号走到 x.19 之后，顺手进位到 x.0，避免继续往后编号显得太乱。

不过，这次发布说明里还是有一句话格外值得注意。Torvalds 写道，“我怀疑，接下来一段时间，大家大量使用 AI 工具，还会不断帮我们把各种边角问题翻出来，所以这可能会成为一段时间里的‘新常态’。至于会持续多久，还要再看。”

另外，虽然 Linux 内核已经引入了 AI 披露政策，但维护者并不会依赖所谓的 AI 检测工具来识别未披露的 AI 代码。他们依然得依靠老办法：深厚的技术经验、模式识别能力，以及最传统的代码评审。正如 Torvalds 在 2023 年说的：“评判他人的代码，需要一定的品味。”

问题就在这里。正如他所说：“讨论 AI 垃圾代码没有意义，因为写这些的人不会主动标注。”难的从来不是明显有问题的垃圾代码，而是那些表面看起来完全正常的补丁：它们符合当前需求，风格一致，可以顺利编译，但内部却埋着细微 bug，或长期维护成本的隐患。

因此，这套新政策的执行，并不依赖抓住每一个违规者，而是通过提高违规代价，来约束行为。问问那些曾因为提交劣质补丁而被 Torvalds 当面“教育”的人就知道了。虽然他现在已经比过去温和不少，但你依然不会想站在他的对立面。