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

此外，子系统维护者有权制定更严格的规则。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，这侵蚀了信任，绕过了人类的深思熟虑。

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

对开源治理更广泛的影响

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

这说明了什么

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