Rust 官方给 AI 编程立规矩：AI 写的 PR 必须带测试，合并占比超一半就熔断

先说结论：可以问 AI，不能让 AI 替你创造

用 AI 辅助写 Rust 的同学，这条消息值得花五分钟看完。

2026 年 8 月 5 日，Rust 官方 Inside Rust 博客发布了 Jynn Nelson 的文章《rust-lang/rust is adopting an LLM policy》：编译器、标准库、types、rustdoc、bootstrap 五个团队正式采纳了一套 LLM 使用政策，管所有向 rust-lang/rust 主仓库提 PR、提 issue、发评论的人。

整套政策可以压缩成一句话，原文是：

It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

翻译过来：用 AI 回答问题、分析、提炼、检查、提建议、做评审，都可以；用 AI 来"创造"，不行——创造类用途被严格限制在一个带五道门槛的"实验条款"里。

门槛有多硬？两条最直观的：

• AI 生成的 PR 必须带测试，没有例外。政策原文写的是：如果改动的那块代码没有现成测试套件，你要么补一套，要么关掉 PR，“writing the tests seems hard”（写测试好难）不是理由。
• 50% 熔断：任意 6 周窗口内，合入的 PR 里 AI 生成的占比超过一半，立即停收新的 AI PR，直到降回 50% 以下，外加至少 10 天冷静期。

这篇文章在 Hacker News 上拿到 120 多个赞、70 多条评论。下面把政策全文拆开讲，顺便看看社区在吵什么。

为什么现在立规矩：1281 个 open PR 的评审危机

Jynn Nelson 在博文里给了三组很坦率的动机，每一组都值得做开源维护的人细读。

第一，精美的 PR 不再代表任何东西。 以前一个打磨得很好的 PR，说明对面那个人花了时间、动了脑子、理解自己的代码——Rust 社区的评审文化建立在这个信号上：不轻易关 PR，因为那是别人的心血；把 PR 当作"作者想长期加入社区"的信号来培养。AI 把这些信号全部打碎了：精美的 PR 不代表努力，不代表理解，如果是自主 agent 提交的，对面甚至不一定有个人。

第二，评审带宽本来就不够，AI 让代码生产变得更廉价。 博文给出的数字是：政策发布时 rust-lang/rust 有 1281 个 open PR。评审的大头不是挑 bug，而是做判断——这个方向对不对、这个 PR 该不该存在。代码本身可以交给 AI 生成，但这些判断不能。作者原话：从维护者视角看，“代码本身是改动里最不重要的部分”。

第三，机械复制粘贴是在浪费所有人的时间。 有人把评审意见贴给 AI，再把 AI 的回复原样贴回 GitHub。博文的原话很不客气：

Bluntly: this is a waste of everyone’s time. If we wanted an LLM’s opinion, we could have asked it ourselves. We want to hear your thoughts, not a machine’s.

（说白了：这是在浪费所有人的时间。如果我们想要 AI 的意见，自己会去问。我们想听的是你的想法，不是机器的。）

在政策出台之前，rust-lang/rust 处于"狂野西部"状态：几十个 LLM 相关的 PR、没有披露规则、有人第一个 PR 就敢动高风险的 MIR 优化、有人在 PR 描述里写 “Verification: git diff –check” 假装验证过了。规则不是没有，而是散落在只有 moderators 知道的内部笔记里——新人根本不知道自己为什么被关 PR。所以按博文的说法，选择从来不是"有没有政策"，而是"潜规则还是明规则"。

规则全景：允许什么、禁止什么、什么必须披露

政策全文托管在 Rust Forge 的《LLM Usage Policy》页面，用 ✅ / ❌ / ⚠️ 三档分类。这里逐档拆给你看。

✅ 完全允许（只要输出只有你自己看到）：

• 问 AI 关于代码库的问题；让 AI 帮你总结 issue 和 PR 的评论（但总结不能公开发出去）
• 让 AI 私下评审你的代码或文字
• 用 AI 写你自己用的开发工具
• 让 AI 生成几种解决方案、学习思路之后用自己的风格从头重写
• 明显标记为实验性质的 PR（比如跑 crater、跑 perf 用的 S-experimental 标签、[PERF] 标题、r? ghost），建议披露但不强制；一旦摘掉实验标记，披露就变成必须

❌ 直接禁止：

• 个人账号发布 AI 原文生成的评论——包括 issue 正文、PR 描述，甚至音视频脚本。清晰引用并标注的 AI 内容可以出现，但评论必须"去掉 AI 部分也能独立成立"
• AI 原创的文档——包括 doc comment、safety comment、成段的非文档注释，以及编译器诊断信息（诊断的逻辑可以用 AI 辅助，但提示文案本身必须人写）
• 把流程设计成"必须用 LLM 才能执行"——比如文档只写在 AGENTS.md 里。政策要求文档首先为人类而写，给机器看的版本只能是摘要，不能有额外细节
• 把 LLM 评审当作合并或拒绝的充分条件——AI 评审只能是建议性质，也不能替代作者自审

⚠️ 有条件允许（全部要求披露 AI 参与）：

• 机器翻译：只发译文不发原文是"允许但不鼓励"——可能引入新的误解；原文+译文一起发 always OK，但要披露用了机器翻译
• “琐碎"修改：拼写、Markdown 链接、同义词替换、trait 实现的类型签名这类"没有第二种写法"的改动
• 用 AI 发现 bug：可以，但必须本人亲自验证，参照 fuzzer 报告准则
• 评审机器人：维护者一次性批准、必须用明确标识为 LLM 的独立 GitHub 账号、必须能被普通用户屏蔽、AI 评论不能直接卡 PR——评审人必须明确背书某条 AI 评论之后，才能拿它当合并门槛

AI 写的代码想合入？先过五道门

这是整个政策最核心的"实验条款”（Experiment: LLM-created code changes），五个条件缺一不可，而且全程披露：

1. Pre-arranged（预先沟通）：必须有评审人事先表示愿意评审这个 AI PR。新贡献者开 AI PR 之前，必须先和将来被指派的那位评审谈过。政策建议的做法是先推到自己的 fork，把链接发到 Zulip 上找评审，而不是直接开 PR。
2. Non-critical（非关键路径）：极不可能造成 soundness 回归。内部工具（tidy、x setup、linkchecker）大概率可以；trait 系统、MIR 构建、query 系统这类地方大概率不行。rust-lang 组织成员可以豁免这一条，但政策"强烈不鼓励"——原话是 AI 非常擅长生成看着合理的代码，而 soundness 很难测。
3. High-quality（高质量）：至少达到和人类代码相同的标准。原话点名：不接受降低代码库质量的 “vibe-coded” PR。
4. Well-tested（完整测试）：AI PR 的测试标准比人类 PR 更高，理由是 AI 写测试更容易。没有现成测试套件就补一套，否则关 PR，没有例外。
5. Well-reviewed（充分评审）：作者和评审双方都要承诺完全理解代码。别人评审不替代自审，作者每次改动后都要自己再过一遍。

流程上，这类 PR 必须打一个新的 ai-assisted 标签，并自动同步到一个 rust-lang 组织成员可见的私有 Zulip 频道——目的不是再加一道审批，而是收集数据：人们用 AI 做的是不是有意思的事？他们有没有在成长？会不会成为重复贡献者？这些数据将决定政策下一步往哪改。

注意这个条款的定位：它是"实验"，是用来给未来的正式政策探路的，不是常态。

50% 熔断：给 AI 贡献装的定量阀门

整套政策里最有设计感的一条，值得单独说。

规则是：任意 6 周窗口内（6 周正好对齐 Rust 的发布周期），如果合入的 PR 中 LLM 生成的占比超过一半，就禁止合入新的 LLM PR，直到占比降回 50% 以下——且最少冷却 10 天（10 天对齐的是 FCP 最终评论期流程，避免在"允许/禁止"之间来回翻转）。

冷却期的用途在政策里写得很明白，是用来回答四个问题的：实验进展如何？我们采纳 AI 的方式可持续吗？选择不用 LLM 的贡献者有没有被照顾好？政策要不要改？

政策还"强烈建议"把熔断自动化执行——人工执法不一致会滋生怨气。

我的看法（这是观点，不是政策内容）：这是目前主流开源项目里少见的、给 AI 贡献装"定量阀门"的尝试。大多数项目的 AI 政策停在定性层面（允许/禁止/披露），Rust 这套相当于承认了一个前提——评审带宽是稀缺资源，需要像限流一样管理。把上限写在明处，比依赖维护者的职业倦怠来兜底要诚实。

边界：这套政策不管什么地方

别被标题误导，这套政策的适用范围比看起来窄得多：

• 只适用于 rust-lang/rust 主仓库，且只有 compiler、libs、types、rustdoc、bootstrap 五个团队及其子团队批准了它
• lang、edition 等团队不在范围内，可以自己定政策
• rust-lang 组织下的其他仓库、submodule、crates.io 依赖都不适用

还有几个执法层面的关键细节：

• 按行为认定，不按意图。政策明确承认很多条款"无法强制执行"——目标不是抓住每个违规者，而是原文说的 “remove plausible deniability”（消除装傻空间）：你要么遵守，要么故意违反。隐瞒 AI 参与属于撒谎，直接算违反行为准则
• “代码风格不是证据”。评审觉得某段代码"看起来像 AI 写的"，不能据此指控作者；怀疑就私下报告 moderation 团队。同时，骚扰 AI 工具的使用者同样违反行为准则
• 它不是 Rust 项目对 AI 的官方立场。博文原话：项目内部对 AI 没有共识，“可能永远不会有”。这份政策被刻意设计成"修改它比通过它容易"，领导委员会还在考虑设立专门的 LLM 政策子团队

作为对照，隔壁 Zig 项目的做法严格得多：其官网行为准则里的 “Strict No LLM / No AI Policy” 直接禁止一切 LLM 生成内容——代码、文字、转述、润色、翻译全部不行。Rust 博文里那句被引用的话 “No LLM-generated content, whether it be code or prose”，正是 Zig 准则的原文——Rust 没有选择这条路，因为"Rust 的治理不靠仁慈的独裁者拍板，靠共识"。

社区在吵什么

Hacker News 的讨论串里，几派观点很有代表性。

政策原文的一句话总结被顶在最前面（HN 用户 andsoitis）：“It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create."——大部分人认可这个切分。用户 ares623 的解读是：你可以用工具帮自己干繁琐的部分，但不能用同一个工具把繁琐转嫁给评审。

反对声也不弱。用户 socalgal2 直接说 “Sounds like the beginning of the end of rust to me”（听起来像 Rust 终结的开始），理由是 “AI is a jet engine”——AI 是喷气引擎，限制创造类用途等于强制大家继续坐螺旋桨飞机。这个比喻的下方，用户 happyweasel 的反驳拿到了不少认同：Rust 只是想确保"你是个能真正掌舵的合格飞行员，再来占用所有人的注意力”。

还有一派担心"深度理解"被高估：没人能真正吃透大型代码库，包括原作者。反驳者举了 ffmpeg 和一批单人游戏的例子——争论没有结论，但这正是政策把自己定位成"实验"的原因。

对你有什么用：用 AI 提 PR 前的自查清单

这套政策虽然只管 rust-lang/rust，但它大概率会被更多项目参考。如果你日常用 Cursor、Codex、Copilot 这类工具给开源项目贡献代码，可以直接拿这张清单自查：

• ✅ 我真的理解自己提交的每一行代码吗？被评审追问时，答得上来的应该是我，不是我的 AI
• ✅ PR 描述、评论、issue 全是我自己写的吗？AI 帮我起草过没关系，发出去的必须是我改过、认账的话
• ✅ 披露了吗？越来越多的项目会学 Rust，在 PR 模板里直接问"代码是否由 LLM 生成"——撒谎的代价比披露大得多
• ✅ 测试齐了吗？Rust 把 AI PR 的测试门槛设得比人类 PR 更高，这个趋势会扩散
• ✅ 动核心路径之前，先和 maintainer 打过招呼吗？
• ❌ 永远别把评审意见贴给 AI 再把回复贴回去——这是整个政策里最被鄙视的行为，没有之一

FAQ

Rust 禁止用 AI 写代码了吗？

没有。政策只约束 rust-lang/rust 主仓库的五个团队（compiler、libs、types、rustdoc、bootstrap）。私下用 AI 学习、提问、总结、自查完全自由；AI 生成的代码想合入，需要满足预先沟通、非关键路径、高质量、完整测试、充分评审五个条件并披露。

什么是 Rust 的 50% 熔断机制？

在任意 6 周窗口（对齐 Rust 发布周期）内，如果合入的 PR 中 LLM 生成的占比超过一半，就暂停合入新的 LLM PR，直到占比降回 50% 以下，且至少有 10 天冷静期。政策建议把熔断做成自动化执行。

用 AI 给其他开源项目提 PR 也会被封吗？

每个项目政策不同。Rust 的政策只适用于 rust-lang/rust；Zig 项目在行为准则中严格禁止一切 LLM 生成内容。通用安全做法：披露 AI 参与、自己理解每一行代码、自己写 PR 描述和评论、不把 AI 回复原文贴进讨论区。

资料出处

本文政策条款全部以官方原文为准，建议对照阅读：

• Jynn Nelson 2026 年 8 月 5 日发表于 Rust 官方 Inside Rust 博客的《rust-lang/rust is adopting an LLM policy 外部链接 》，政策的来龙去脉、1281 个 open PR 的数字和"想听你的想法，不是机器的"均出自此文。
• Rust Forge 托管的《LLM Usage Policy 外部链接 》政策全文，✅/❌/⚠️ 三档分类、实验条款五道门槛、50% 熔断机制的条文以这份为准。
• 面向贡献者和评审的操作指引在 rustc-dev-guide 的 LLM 贡献指南 外部链接 和评审指引 外部链接 。
• 社区争论来自 Hacker News 讨论串《rust-lang/rust is adopting an LLM policy 外部链接 》，文中引用的评论均已对照原文核验。
• Zig 项目的《Strict No LLM / No AI Policy 外部链接 》收录在其行为准则中，作为严格禁止路线的对照。

相关阅读

如果你对 Rust 感兴趣，这几篇文章你可能也会喜欢：

• Rust 1.97.1 紧急修复：编译器误编译让程序悄悄段错误，从 1.87 就潜伏 - 编译器自己出 bug 的时候，谁在兜底
• 一个 if 拖慢 Rust 代码 4 倍：CPU 一直在替你"瞎猜" - 性能优化的前提是你真的理解代码在做什么
• 用 Rust 从零构建 AI Agent —— 工具调用循环详解 - AI 和 Rust 的另一种结合方式

关于「全栈之巅-梦兽编程」：专注 AI 编程与全栈技术深度内容，微信搜索「梦兽编程」关注公众号，获取更多 Rust 与 AI 编程实战教程。