生成式编程工具把写代码的成本快速压低之后，开源社区最先感到的往往不是效率提升，而是评审压力。2026 年 8 月 5 日，Rust 项目的五个团队在 Inside Rust 博客上宣布，正式采纳一套针对 rust-lang/rust 主仓库的大语言模型（LLM）使用政策。政策由长期维护者 Jynn Nelson（jyn514）起草，此前在 Zulip 上的讨论累计超过三千条消息，最终以 rust-forge 仓库第 #1040 号 PR 的形式落地。
需要先厘清的是范围。这套规则只适用于 rust-lang/rust 这一个仓库，且只约束已经批准它的团队——编译器、标准库、类型系统、rustdoc 和 bootstrap，及其子团队。它并不是整个 Rust 项目对 AI 的官方立场，语言团队、其他 rust-lang 仓库以及 crates.io 上的依赖都不在覆盖范围内。用政策作者的话说，它取代的是此前那种没有公开规则、近似「蛮荒西部」的管理方式。
政策的核心可以归结为一句话：可以用 LLM 来回答问题、分析、提炼、完善、检查、提出建议和审查，但不能用它来创造。落实到操作上，大致分成三个层级。第一类是完全允许的私人使用：只要模型输出只有贡献者本人看到，例如向 LLM 询问代码库结构、为自己总结一个讨论串，或者私下让它审查自己还没发布的工作。第二类是允许但必须披露的用法，包括机器翻译、修复拼写错误这类微小修改、借助 LLM 发现 Bug，以及运行 LLM 代码审查机器人。审查机器人还必须使用独立且明确标记的 GitHub 账号，让不想看到这类内容的用户可以一键屏蔽。第三类则是明确禁止的：由 LLM 直接生成的评论、文档和编译器诊断信息，任何必须依赖 LLM 才能运转的流程，以及仅仅因为 LLM 给出了审查结论就据此合并或拒绝某个改动。
这套规则的真正分量在于执行设计。故意隐瞒或虚假陈述 LLM 使用情况，会被视为违反 Rust 项目的《行为准则》，与骚扰行为处于同一等级，首次违规可能收到警告，反复违规则可能被封禁。同时政策也坦率地承认，其中许多条款无法靠技术手段强制执行，而这正是有意为之。它明确写道，目标并不是抓住每一次违规，而是要消除任何可以推脱的空间，迫使人们在遵守规则和故意违反之间做出选择。
值得注意的是，Rust 并没有彻底封杀 LLM 写代码，而是把它收进一个边界清晰的实验里。LLM 原始生成的代码变更只有在同时满足若干条件时才能进入评审：事先与一位明确愿意评审的成员约定好、不触及影响健全性（soundness）的关键区域、代码质量达标、测试充分、作者与评审者都能完整解释改动，并且必须披露模型参与。相关 PR 需要打上 ai-assisted 标签，并汇总到一个私有的 Zulip 频道，用于观察这项实验是否真的带来了有价值的贡献，而不是充当额外的守门人。对测试的要求也明显更严：如果所触及的代码没有现成测试体系，作者要么补上测试，要么关闭 PR，「测试很难写」不构成例外。涉及 trait system、MIR 构建、查询系统等健全性敏感区域，政策则强烈建议不要把工作交给模型。
这套实验还内置了一个量化「熔断」机制：如果在连续六周的滚动窗口里，被合并的 PR 中超过一半由 LLM 创建，就暂停合并新的 LLM PR，直到占比重新回落到 50% 以下，且至少要冷却十天。窗口与 Rust 六周的发布节奏对齐。这个设计直接瞄准了一个正在被 AI 改变的事实：代码生成变得越来越便宜，但人工评审并没有同步变便宜。
政策公告给出了推动规则落地的三个具体压力。第一，一个打磨完善的 PR 曾经暗示作者投入了时间、理解了上下文，甚至愿意长期留在社区，但 LLM 让这些信号集体失效——整洁的 PR 不再代表投入，作者未必理解自己的代码，而如果是自主代理在运作，对面可能根本没有一个真正思考的人。第二，生成代码的门槛下降，让本来就存在的「想写代码的人多、愿意评审的人少」进一步失衡；写公告时，rust-lang/rust 有 1,281 个未关闭的 PR，而评审的大部分工作不是挑 bug，而是判断方向对不对、这个改动值不值得做。第三，也是被反复点名的现象：有人把评审意见原封不动贴给 LLM，再把模型的回复贴回 GitHub。用 Nelson 的话说，这是在浪费所有人的时间——如果评审者想看模型的看法，完全可以自己去问，他们想听的是作者本人的判断。
这套政策在社区引发的讨论，恰好暴露了 AI 编程边界问题中真正难解的部分。Rust 项目内部对何时、以何种方式使用 AI 并没有共识，政策自己也承认这种共识「很可能永远不会有」：有人从中受益，有人认为它对环境和社会的负面影响大到任何使用都不可接受，还有人在观望。正因如此，Rust 无法像 Zig 那样采取一刀切的严格禁用——Zig 的规则连改写、转述、翻译、头脑风暴和找 Bug 都一并禁止，执行成本低，但对贡献者的约束成本高。Rust 选择了另一条路：允许贡献者继续使用他们本就会用的工具，但要求评审者做更多判断，并用披露、预约评审和熔断机制把责任留在人身上。
讨论中也不乏保留意见。Rust 的核心贡献者 Niko Matsakis 等人在政策形成阶段提出了关于范围和先例的担忧，有人认为「不创造」这条线在实操中会被绕开，也有人质疑熔断器统计的是「合并 PR 占比」而非真正被消耗的评审工时。不过，政策的整体设计意图是清楚的：它不试图回答「AI 写的代码算不算好代码」这种难以终结的争论，而是把问题转译成一套基于行为、可执行的规则，把注意力引向那个正在变贵的东西——愿意为代码负责、能够解释每一个决定的人。