Rust 为其主仓库采用正式的 LLM 政策

Rust 项目中的五个团队已采用一项关于如何使用大型语言模型的正式政策，用于在向 rust-lang/rust（项目的主单体仓库）贡献代码时的规范。该政策的作者 Jynn Nelson 于 2026 年 8 月 5 日在Inside Rust 博客上宣布。该政策（经编译器、libs、types、rustdoc 和 bootstrap 团队批准）用一套公开的书面规则取代了 Nelson 所称的未公开的“wild west”式审查方式。

该政策并非项目范围内对 AI 的立场，并且明确说明了这一点。它仅适用于 rust-lang/rust 仓库以及批准该政策的团队。但在此范围内，它划定了一条明确界限：LLM 作为思考工具是受欢迎的，而不是其替代品。

政策实际内容

该文件用一句话概括自身：

使用 LLM 来回答问题、分析、提炼、改进、检查、建议、审阅是可以的。但不能用于创建。

在实践中，这形成了三个层级。直接允许：任何贡献者唯一可见的私有使用——比如询问代码库相关问题、概括讨论串、私下审阅自己的代码。需强制披露后允许：机器翻译、诸如拼写错误修正等琐碎修改、LLM 辅助的错误发现，以及 LLM 审阅机器人，这些必须使用单独、标记清晰的 GitHub 账户运行，且用户可以屏蔽这些账户。禁止：由 LLM 创建的评论、文档和编译器诊断；任何需要 LLM 执行的流程；以及将 LLM 审阅视为足以合并或拒绝更改的依据。

最严厉的措施体现在执行设计上。故意误报 LLM 使用被视为违反项目行为准则——与骚扰同等级——会受到警告，屡次违规则会被封禁。文件明确指出，其许多条款在实践中难以执行，并说明这是有意为之：“我们的目标不是抓住每一次违规……相反，我们的目标是消除合理的否认空间：迫使人们在遵守政策和故意违规之间作出选择。”

对 LLM 编写代码的有界实验

LLM 编写的代码并未被直接禁止。它仅限于一个具备严格入门条件的实验：更改必须事先与指定审阅者协商，且对编译器的可靠性非关键，需经过充分测试和审阅，并在任何情况下都必须披露。新贡献者在获得审阅者批准前不得打开由 LLM 创建的 pull request。若所涉及的代码没有测试套件，作者必须编写测试或关闭该 PR。没有例外。

该实验设有自身的断路机制。如果在六周的时间窗口内合并的 PR 中超过一半是由 LLM 创建的，则 LLM 创建的 PR 合并将暂停，直至其比例降回 50% 以下，且最短冷却期为十天。该窗口与 Rust 的六周发布周期保持一致。所有此类 PR 都会加上新的 ai-assisted 标签，并发布到一个私有的 Zulip 频道，旨在收集数据（LLM 辅助的贡献者是否在学习、回归并产出有价值的工作），而非进行门禁控制。

为何此时

Nelson 在公告中描述了推动团队从非正式审查转向书面规则的三大压力。精致的 pull request 已不再体现付出或理解，这侵蚀了项目审查文化赖以运作的信任信号。更低成本的代码生成加剧了已有的审查带宽短缺：仓库目前有 1,281 个未合并的 PR，而稀缺的资源始终是审阅者的判断，而非代码本身。还有贡献者在审查评论中将内容粘贴到 LLM 中再把输出粘回，正如 Nelson 所言，这在浪费所有人的时间，并破坏了审阅者在与人交流的假设。

背后是项目内部的真实分歧。政策的动机章节指出，Rust 内部对 AI 工具何时可接受并无共识，“而且可能永远不会有”，成员的立场从每日使用者到认为任何使用都不可接受不等。这也是文件被设计为可变更的原因：重大修订需得到每个批准团队的签字，而这些团队可以完全废除该政策，或被领导委员会正在考虑的全项目 LLM 委员会所覆盖。

细则

适用范围比标题所示更窄。该政策不涵盖 rust-lang 组织中的其他仓库、语言团队的工作（如跟踪 issue 和稳定性报告）、风格指南，亦不适用于未批准该政策的团队。它们仍可自行制定规则。rust-lang 组织的成员可免除对 LLM 创建代码的“非关键”限制，尽管政策强烈不鼓励使用此豁免，且在政策生效前编写的 PR 也同样享有豁免。对因使用 LLM 而骚扰贡献者本身是被禁止的，无论该使用是否违反了政策。

接下来会怎样

一旦 ai-assisted 标签投入使用，私有的 Zulip 频道便开始收集 LLM 创建的 PR 数据，首个六周的断路窗口将告诉团队该实验是否已压垮合并队列。领导委员会正在审议的专门 LLM 委员会提案若获通过，将优先于本政策，并可能将规则扩展至全项目，包括目前完全没有政策的聊天、论坛和仓库。Nelson 的帖子正是为此结果辩护，将本政策定位为第一步，而非最终定论。