AI生成代码进入开源核心？Linux与Rust项目2026年相继立规：人类责任不可推卸

2026年，地球上最具影响力的两个开源项目——Linux内核和Rust项目——相继通过了针对AI生成代码贡献的正式政策。尽管两者的严格程度和范围有所不同，但都指向同一个核心原则：任何提交者都必须为自己名下提交的每一行代码承担全部责任。

以下是两项政策的详细解读、背后的动机，以及对开源软件开发未来的启示。

Linux内核：全局政策 + 子系统级别的强化防御

Linux内核在2026年4月通过其首个全局AI政策，并随 Linux 7.0 正式生效，官方文档为 Documentation/process/coding-assistants.rst 。该政策确立了四项核心规则：

• 仅限人类认证：AI代理不得添加 Signed-off-by 标签。只有人类才能认证开发者原创证书（DCO）。
• 完全的人类责任：提交者对所有AI生成的代码承担全部法律和技术责任，包括其中的漏洞和安全缺陷 。
• 强制披露：贡献必须包含 Assisted-by: 标签，注明所用AI工具名称、模型版本及使用的任何辅助分析工具 。
• 标准流程不变：AI辅助的补丁仍需遵循内核编码规范、提交流程和许可要求 。

此外，子系统维护者有权制定更严格的规则。2026年8月，内核无线网络子系统（802.11、mac80211、WWAN、rfkill）的维护者 Johannes Berg 宣布了对AI/LLM生成补丁的强硬立场 ：

• “三秒审查”规则：任何补丁如果在三秒内不能明显看出其正确性，将被直接忽略 。
• 拒绝迭代修改：他拒绝参与旨在修复AI生成补丁的来回审查过程 。
• 拒绝低质量“垃圾”：不能一眼看出正确性的补丁将被直接拒绝，不做进一步讨论 。

在此之前，Greg Kroah-Hartman 已规定 drivers/staging/ 子系统拒绝所有由LLM生成的补丁，真正的安全修复除外 。

Linux内核为何采取此策略

内核社区发现三个核心问题推动了政策的制定：

1. 审查带宽危机：维护者被大量AI生成的补丁淹没，其中许多补丁表面光鲜，但语义错误或存在危险性 。
2. 信号退化：过去，质量高的补丁通常意味着贡献者的努力和理解，但LLM打破了这一信任信号 。
3. 责任的不可替代性：社区一致认为，人类责任是不可妥协的底线——机器无法认证代码的法律来源，也无法为bug承担责任 。

Rust项目：五个团队的LLM政策（2026年8月5日）

2026年8月5日，Rust项目五个核心团队在 rust-lang/rust 核心仓库通过了正式的LLM政策 。该政策明确不是整个项目的官方立场，仅适用于核心仓库和采纳该政策的团队 。

允许的行为（需披露）

• 使用LLM回答问题、分析代码或学习代码库以提升自身理解 。
• 贡献者私下进行代码或文本审查 。
• 贡献者自行验证的bug发现 。
• 内容的机器翻译 。

禁止的行为

• 提交由LLM生成的文档，包括文档注释和安全注释 。
• 发布由LLM生成的GitHub评论、issue正文、PR描述、编译器诊断信息或大量源代码注释 。
• 发布由LLM编写的代码，除非事先获得审查者同意，并明确披露使用了LLM 。
• 提交未经理解或审查的AI生成内容 。

该政策的核心总结是：“使用LLM来提问、分析、提炼、优化、检查、建议、审查是可以的。但不能用于创作。”

Rust为何采取此策略

政策作者 Jynn Nelson 在官方公告博客中列出了三个核心问题 ：

1. 精美的技术产物不再体现努力和理解：LLM可以产出看起来很干净的补丁，但提交者自己并不理解其中的内容，这破坏了精心编写的PR代表真实人力投入的社会信号。
2. 审查带宽已不堪重负：rust-lang/rust 已有 1,281 个开放的PR。让写代码变得更容易，但不增加审查者人手，只会加剧已有的瓶颈。
3. 机械的复制粘贴浪费所有人的时间：贡献者将审查意见粘贴给LLM，再将LLM的回答粘贴回GitHub，这侵蚀了信任，绕过了人类的深思熟虑。

该政策还旨在将非正式、不一致的管理方式转变为清晰、公开的规则，方便审查者引用，也让新贡献者容易找到 。

对开源治理更广泛的影响

这两项政策揭示了一个共同模式和一系列共享的治理挑战：

维度	Linux内核	Rust项目
范围	全局政策 + 子系统级别强化	五个团队，仅限核心仓库
人类责任	绝对：提交者承担所有法律/技术责任	绝对：未经披露和理解，不得有AI生成内容
AI生成代码	允许，但需注明来源和人类签名	原则上禁止，除非事先获得审查者批准
AI生成文档/评论	不是政策重点	严格禁止
子系统自主权	维护者可自行加严（如“三秒规则”）	范围限于采纳政策的团队

这说明了什么

• “审查危机”是核心矛盾。两个项目都认识到，LLM大幅增加了提交量，但合格的审查者人数并未增加。这是最大的治理压力来源 。
• 信号崩塌是真实存在的。两个社区都指出，精心制作的PR曾经代表着努力和理解，但LLM已经打破了这一信号 。
• 正式化规则正在取代临时管控。两个项目都是从非正式规则转向成文政策，正是因为执行标准不统一让贡献者困惑，也让维护者精疲力竭 。
• 子系统自主权很重要。Linux内核允许单个维护者制定更严格的规则，如 Johannes Berg 对无线子系统的做法；Rust的方法则是逐团队采纳 。
• 关于AI本身并没有共识。Rust的政策明确承认，项目范围内不可能就AI达成一致，因此政策只关注贡献机制，而不对LLM本身做出道德评判 。