Linux 内核源码都接受 Vibe Coding 了

4 月 10 日，有人把 Linux 内核源码树里一个文档文件贴到了 Hacker News 上。文件路径是 Documentation/process/coding-assistants.rst，标题是「AI Coding Assistants」。

这不是什么提案或讨论帖。这是一份已经合入 Linux 内核主线代码库的正式文档，规定了 AI 工具在参与 Linux 内核开发时应该怎么做。它和 coding-style.rst（编码规范）、submitting-patches.rst（提交补丁指南）并列，是内核开发流程文档的一部分。

这篇帖子拿到了 264 个赞和 140 多条评论。讨论的核心不是「要不要用 AI」，而是「全球最重要的开源项目，选择了什么样的方式与 AI 共处」。

文档说了什么

核心内容四点。

AI 必须遵守现有规则。 文档第一段就说得很清楚：AI 工具参与 Linux 内核开发，应该遵循标准的内核开发流程。没有什么「因为是 AI 所以可以例外」。

AI 不能签 DCO。 Linux 内核的每个补丁都需要一个 Signed-off-by 标签，表示开发者签署了 Developer Certificate of Origin（开发者来源证书，DCO），在法律上确认自己有权提交这段代码。文档明确规定：AI 代理不得添加 Signed-off-by 标签。只有人类才能在法律上认证 DCO。

人类提交者负责：审查所有 AI 生成的代码、确保符合许可证要求、添加自己的 Signed-off-by 标签、对贡献承担全部责任。

必须标注 AI 参与。 当 AI 工具参与了内核开发时，贡献中应该包含一个 Assisted-by 标签。格式是：

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

比如：Assisted-by: Claude:claude-3-opus coccinelle sparse

其中 AGENT_NAME 是 AI 工具名，MODEL_VERSION 是具体模型版本，方括号里是可选的专项分析工具（coccinelle、sparse、smatch、clang-tidy 等）。基本的开发工具（git、gcc、make、编辑器）不需要列出来。

许可证不变。 所有贡献必须兼容 GPL-2.0-only，使用适当的 SPDX 许可证标识。

背后的人：Sasha Levin

这份文档的作者是 Sasha Levin。他在 NVIDIA 工作，是 Linux LTS（长期支持）内核的联合维护者，之前在 Google 和 Microsoft 也工作过。他在内核社区不是新手——他是一个有长期贡献记录的核心开发者。

2025 年 7 月 25 日，Levin 提交了一份 RFC（据 Phoronix 报道）。RFC 中提议了两件事：为各种 AI 编码助手添加统一的配置文件，以及添加规则和文档。

配置文件的覆盖面很广：Claude（CLAUDE.md）、GitHub Copilot（.github/copilot-instructions.md）、Cursor（.cursorrules）、Codeium（.codeium/instructions.md）、Continue（.continue/context.md）、Windsurf（.windsurfrules）、Aider（.aider.conf.yml）。所有配置文件都符号链接到同一个中心文档，确保跨工具的一致性。

不过，最终 2025 年 12 月合入主线内核时，只保留了文档本身（coding-assistants.rst），配置文件并未一起进入。2026 年 4 月，有人把这份文档贴到了 HN 上，才引发了广泛讨论。

Levin 在 RFC 中解释了他的动机：「随着 AI 工具在软件开发中变得越来越普遍，为它们在内核开发中的使用建立明确的指导原则很重要。」

从「Co-developed-by」到「Assisted-by」

一个值得注意的细节：Levin 最初的 RFC 用的是 Co-developed-by 标签来标注 AI 参与。但最终合入的版本改成了 Assisted-by。

这不是随便改的。Co-developed-by 在 Linux 内核中有特定的法律含义——它暗示另一个人或实体共同开发了这段代码，并且也可能需要签署 DCO。用这个标签来标注 AI 工具会模糊法律责任的边界。

Assisted-by 是一个全新的标签，专门为 AI 创建。它的含义更精确：AI 协助了开发，但不是法律意义上的「共同开发者」。责任的归属仍然完全在人类提交者身上。

这个标签选择反映了一种务实的法律思维：不是简单禁止 AI，也不是假装 AI 不存在，而是创造一个专门的法律框架来准确描述 AI 的角色。

Levin 的现场演示

Levin 在 RFC 邮件中附上了一个实际演示。他用 Claude 修复了一个内核文档中的拼写错误（dont → don’t），全程没有手动编辑：

$ claude -p "Fix the dont -> don't typo in Documentation/power/opp.rst. Commit the result"Done! The typo has been fixed and committed.

生成的补丁中，Claude 正确地添加了 Co-developed-by: Claude claude-opus-4-20250514（这是 RFC 时的格式），没有添加 Signed-off-by（它知道自己不能签），提交者是 Levin 本人。

Levin 还演示了 Claude 对规则的自觉遵守。他问 Claude「你需要标注你的提交吗？」，Claude 回答：「是的，根据这个 Linux 内核仓库中的 CLAUDE.md 文件，我必须在提交中通过包含 Co-developed-by 标签来标识自己是 AI 助手。我不应该添加 Signed-off-by 标签——只有你（人类开发者）应该添加那个，因为它代表法律认证。」

为什么这不是「禁止 AI」

这份文档的态度很明确：AI 可以用，但有规矩。

这与一些其他开源项目的态度形成了对比。有些项目选择全面拥抱 AI，几乎没有限制；有些项目（比如一些小型项目）选择全面禁止 AI 贡献。Linux 内核选择了一条中间路线。

这条路线的核心逻辑是：区分「能力」和「责任」。 AI 有能力写代码，但 AI 不能承担法律责任。所以代码可以由 AI 生成，但法律认证必须由人类完成。AI 的参与必须透明标注，但不需要被禁止。

Linus Torvalds 本人到目前为止没有公开对这份文档发表评论——至少没有像他评论某些补丁时那样用他标志性的直率风格。沉默在内核社区通常意味着「没有强烈反对」，这本身就是一种态度。

HN 评论区的讨论

140 多条评论覆盖了几个方向。

规范化的意义：很多人认为这是一件好事。「与其假装 AI 不存在，不如建立明确的规则。这样维护者知道怎么处理 AI 生成的补丁，贡献者知道怎么正确标注。」

Assisted-by 标签的设计：有人指出这个标签的设计很聪明——它创造了可追溯性。未来可以统计 AI 在内核开发中的参与程度、哪些子系统使用 AI 更多、不同 AI 工具的效果差异。这些数据对理解 AI 在复杂软件工程中的实际价值非常有用。

担忧的声音：有人担心这会降低补丁质量。「如果维护者知道一个补丁是 AI 生成的，他们会不会审查得更严格或者直接拒绝？」另一些人反驳：「如果你标注了 AI 参与，你承诺了你审查过这段代码并愿意为之负责。标注反而应该提高信任度。」

对其他项目的示范效应：Linux 内核是全球最大、最老牌的开源项目之一。它对 AI 的态度会影响其他项目。「如果 Linux 内核都能接纳 AI 并建立规范，其他项目没有理由不这么做。」

对中国开源社区的意义

Linux 内核的这份文档对中国开源社区有几层参考价值。

AI 参与开源贡献的规范模板。 中国的开源项目正在快速增长，越来越多的开发者使用 AI 辅助编码。Linux 内核的 Assisted-by 标签机制和 DCO 责任划分，提供了一个经过深思熟虑的法律框架。中国开源项目可以直接借鉴或适配这个模型。

内核贡献的中国开发者。 中国是 Linux 内核贡献的重要力量。如果中国开发者使用 AI 辅助内核开发，这份文档直接适用于他们——必须正确标注 AI 参与，自己签署 DCO，对代码负全责。

AI 工具的本地化适配。 虽然 RFC 中提议的配置文件最终没有随文档一起合入主线，但 Claude、Copilot、Cursor 等工具确实在 Levin 的考量范围内。中国的 AI 编码工具（如通义灵码、Trae 等）如果要被内核社区接受，也需要遵循同样的标注规范。

最后

Linux 内核从 1991 年到现在，经历了无数次技术变革。从 CVS 到 Git，从 32 位到 64 位，从单核到多核，从裸机到云。每一次变革都伴随着争论和适应。

AI 是最新的一个。Linux 内核的回应不是恐惧，不是盲目拥抱，而是一份不到 60 行的文档——说清楚规则，划清责任边界，然后继续工作。

Assisted-by 标签可能会成为开源世界的一个新标准。当你在一个开源项目的 commit 历史里看到 Assisted-by: Claude:claude-4-opus 或者 Assisted-by: GPT:o3，你会知道：这里有人用了 AI，他自己审过了，他为此负责。

这可能比任何关于「AI 会不会取代程序员」的讨论都更有建设性。

参考来源

• Linux 内核文档: AI Coding Assistants（内核主线）
• Phoronix: Linux Kernel Proposal Documents Rules For Using AI Coding Assistants（2025-07-25）
• LWN: Add AI coding assistant configuration to Linux kernel（RFC 邮件，2025-07-25）
• Hacker News 讨论（264 points, 140+ comments）