1,281 个待审 PR 之后：Rust 项目正式发布 LLM 使用政策

Rust 编译器仓库 rust-lang/rust 现在有 1,281 个待审 PR。这个数字本身已经令维护者不堪重负，而 LLM 的普及让情况更严峻：AI 让写代码变容易了，但审查每一份 PR 的人力并没有增加。2026 年 8 月 5 日，Rust 项目的编译器、标准库、类型系统、rustdoc、bootstrap 五个团队正式批准了一项 LLM 使用政策，对 AI 参与代码贡献划出明确红线。

为什么需要专门的政策

政策作者在官方博客中描述了 LLM 给 Rust 社区带来的三个核心问题。

第一个问题：技术产出不再等于人类投入。过去，一份经过精心测试、文档完善的 PR 意味着提交者投入了大量时间，也意味着他理解自己的代码、愿意长期维护。LLM 打破了这个信号。一份精致的 PR 背后可能没有任何人真正理解代码逻辑，甚至对于自主运行的 Agent 来说，另一端根本没有人在。

第二个问题：代码门槛降低导致审查负担激增。审查工作的大部分不在抓 bug，而在判断方向是否正确、PR 是否值得做。对审查者来说，被密集推送的 PR 消耗的是判断力，而 LLM 降低了批量提交的门槛。

第三个问题：机械复制 LLM 输出浪费所有人时间。有贡献者把审查评论粘贴到 LLM，再把回复粘贴回 GitHub。政策作者直言：如果审查者想要 LLM 的意见，他们自己会问。审查者需要的是提交者本人的思考。

政策的核心原则

整个政策可以用一句话概括：

可以用 LLM 回答问题、分析、提炼、检查、建议、审查。但不允许用它来创造。

具体分为三档。

允许的用法（无需披露）：

• 你自己看 LLM 输出，不公开张贴的任何场景。例如向 LLM 提问代码库相关问题、让它总结 issue 评论、让它私有审查你的代码
• 用 LLM 生成可能的解决方案，学习之后用自己的风格从头写

有条件允许（必须披露）：

• 机器翻译：用 Google Translate 等工具将母语翻译成英语发帖是允许的，但必须同时披露使用了机器翻译，建议附上原文
• 微量改动（trivial changes）：拼写修正、Markdown 链接、同义词替换、trait 实现的类型签名这类几乎只有一种写法的改动
• 用 LLM 发现 bug，前提是你本人验证了 bug 真实存在
• LLM 审查机器人：可以部署在 PR 上做辅助审查，但必须使用独立 GitHub 账号、明确标记为 LLM、可被用户屏蔽，且其评论不能作为阻止合并的条件

完全禁止：

• 用 LLM 生成评论、文档、编译器诊断信息。包括 issue 正文、PR 描述、源码注释（doc-comment、safety comment、多段非 doc 注释）
• 设计必须依赖 LLM 才能执行的流程或文档。例如不能只写 AGENTS.md 告诉 AI 测试在哪里，文档必须首先面向人类
• 把 LLM 审查当作合并或拒绝的充分条件。LLM 审查只能是建议性质，不能替代人类审查或自我审查

实验通道：LLM 生成的代码改动

政策没有一刀切禁止 LLM 写代码。它开辟了一个"实验通道"，允许在严格条件下提交 LLM 生成的代码 PR。

五项前提条件缺一不可：

1. 预先安排：提交者必须事先找到愿意审查 LLM PR 的审查者。新贡献者不能直接用 LLM 开 PR，必须先与将负责审查的人沟通
2. 非关键路径：PR 极不可能导致 soundness 回归。改内部工具（tidy、x setup、linkchecker）可能没问题，但触碰 trait 系统、MIR 构建、查询系统这类 soundness 敏感区域基本不行
3. 高质量：至少与人类提交的 PR 同等标准。政策明确表示不接受降低代码库质量的"vibe-coded" PR
4. 全面测试：覆盖你和审查者能想到的所有边界情况。LLM PR 的测试标准比人类 PR 更高，因为 LLM 让写测试也变容易了。如果目标代码段没有现成测试套件，你必须新写一个，否则关掉 PR
5. 充分审查：作者和审查者都承诺完全理解代码。作者必须在提交前和每次修改后自我审查

所有 LLM 生成的 PR 必须打上 ai-assisted 标签，并自动推送到一个（私有的）Zulip 频道。这个频道的作用在于收集实验数据：人们在用 LLM 做什么？是否在学东西？是否做了后续贡献？

断路器机制

政策引入了一个独特的熔断设计：如果任意 6 周窗口内合并的 PR 中超过一半是 LLM 生成的，就暂停合并新的 LLM PR，直到比例降回 50% 以下，且至少冷却 10 天。

6 周窗口对齐 Rust 的发布周期，10 天冷却对齐 FCP（final comment period）流程。冷却期旨在促使社区讨论：实验进展如何？是否在可持续地采用 AI？是否纳入了选择不用 LLM 的贡献者？

审查者的权利与义务

政策明确保护了审查者。任何人都没有义务阅读 LLM 输出，也没有义务使用 LLM 来贡献代码。审查者可以不附理由关闭不符合政策的 PR。

对于 LLM PR 的审查，政策要求审查者主动检查 PR 是否触碰了禁区（文档、诊断、soundness 关键代码）。如果审查者不确定某个 PR 是否由 LLM 生成，不能根据"写作风格"来指控别人。政策特别指出：英语非母语者、神经多样性人群、过度解释者是最容易被误判为"写得像 AI"的群体。

"originally created by an LLM" 的定义

政策对"由 LLM 创造"的定义很严格：指由 LLM 生成的文本（之后可能经过人工编辑）。无论之后人工编辑了多少，原始来源的性质不会改变。政策引用了一篇名为"What Colour are your bits?"的文章来解释这个逻辑：起源设定了初始风格，而风格一旦形成就很难改变。

这个定义不区分来自聊天界面的 LLM 输出和编辑器自动补全的输出。大多数自动补全属于"微量改动"范畴，但无论哪种情况，政策都不给予特殊对待。

故意保守的设计

政策作者在博客中坦承，并非每条规则都完美。但把规则写下来比不写好，有一个"每个人都不太满意"的政策能推动治理结构的改进。

Rust 社区内部对 LLM 没有共识，可能永远不会有。一部分人认为 AI 有价值，另一部分人认为其对环境和社会的负面影响大到不可接受。政策的目标在于分歧存在的情况下建立可操作的规则。

政策专门设计了便于未来修改的机制。小改动只需正常 PR 审批；大改动需要每个批准政策的团队完成 MCP（major change proposal，2 个批准且无反对意见）。领导委员会也在考虑组建专门的 LLM 委员会来处理项目层面的政策。

与其他开源项目的对比

不同项目对 LLM 的态度差异巨大。Zig 语言的行为准则直接写明"不允许任何 LLM 生成的内容，无论是代码还是文字"。Linux 内核的 Linus Torvalds 的态度则是"AI 是一种工具，就像我们使用的其他工具一样"。

Rust 选择了中间路线：不全面禁止，但设置高门槛。政策不适用于整个 Rust 项目，目前只覆盖 rust-lang/rust 单体仓库中批准了该政策的团队（编译器、标准库、类型系统、rustdoc、bootstrap 及其子团队）。其他仓库和子模块可以自行制定政策。

对开发者的实际影响

如果你向 rust-lang/rust 提交 PR，需要注意：

• 用 LLM 写的评论、文档、诊断信息直接禁止，没有例外
• 用 LLM 发现的 bug 需要你自己验证后才能报告，并披露 LLM 参与了发现过程
• 用 LLM 生成的代码改动必须事先与审查者沟通，打 ai-assisted 标签，通过五项前提条件审查
• 机械复制 LLM 回复到审查评论中会被视为浪费时间，可能被关闭 PR
• 不披露 LLM 使用是违反行为准则的行为，首次警告，多次违规可能被封禁

政策的执行不依赖侦探式的监控。引用政策作者的话："欺诈的最优数量不是零"。目标在于消除合理否认的空间：让贡献者在遵守规则和故意违规之间做出明确选择。

来源：

• rust-lang/rust is adopting an LLM policy - Rust 官方博客
• LLM Usage Policy - Rust Forge