Rust 给 AI 编程立新规：能帮你看，不能替你写，用多了还会“熔断”

近期，Rust 项目中的五个团队已经正式采纳了一项关于AI编程的新准则，用来规范贡献者在向 rust-lang/rust 提交代码时，应该如何使用大语言模型（LLM）。 rust-lang/rust 是 Rust 项目的主要单体代码库。该准则的作者 Jynn Nelson 于 2026 年 8 月 5 日在 Inside Rust 博客上宣布了这一消息。 简单来说，这份文件可以用一句话总结它的核心原则： 可以用 LLM 回答问题、分析、提炼、完善、检查、提出建议和审查，但不能用它来创造。 这项准则已经获得编译器、标准库、类型系统、rustdoc 和 bootstrap 五个团队批准。它用一套公开、成文的规则，取代了 Nelson 所说的过去那种没有公开规则、近似“蛮荒西部”的管理方式。 不过它目前只适用于 rust-lang/rust 仓库，而且只约束已经批准这项准则的团队。在这个范围内，它划出了一条非常明确的界线：欢迎把 LLM 当作思考工具，但不能让它代替你思考。 Rust 到底允许 AI 做什么？ Jynn Nelson 在 Inside Rust 博客上介绍了这个新规定： 除非本人愿意，否则任何人都没有义务阅读 LLM 生成的内容。未经明确标注，LLM 输出不得出现在公开文档、PR 描述或 GitHub 评论中；如果审阅者不想看由 LLM 参与生成的 PR，也可以直接不审。为 rust-lang/rust 做贡献，并不要求任何人必须使用 LLM。所有政策都必须先写给人看，之后才能再整理成适合机器读取的版本；LLM 的审查结果也不能代替人工审查，更不能代替作者自己的检查。你可以私下使用 LLM，也无需披露，只要这些生成内容只供自己查看，不被发布到任何需要 Rust 项目成员阅读或审查的地方。如果使用 LLM 进行机器翻译、完成“微小修改”、发现 Bug，或者审查他人的工作，都必须披露 LLM 的参与。Rust 也欢迎贡献者直接使用自己的母语交流，并不要求必须先翻译成英文才能参与贡献。 简单来说，就是“可以思考，可以审查，可以翻译，唯独不能创造”。落实到实际操作中，大致可以分成三个层级。 第一类是完全允许的：任何只有贡献者本人会看到 LLM 输出的私人用途。例如，向 LLM 询问代码库相关问题、总结一个讨论串，或者私下让它审查自己写的代码。 第二类是可以使用，但必须披露：包括机器翻译、修复拼写错误等微小修改、借助 LLM 发现 Bug，以及使用 LLM 代码审查机器人。对于审查机器人，准则还要求它们必须使用独立且明确标记的 GitHub 账号运行，以便不想看到这类内容的用户可以直接屏蔽。 第三类则明确禁止：包括由 LLM 直接生成评论、文档和编译器诊断信息；任何必须依赖 LLM 才能运行的流程；以及仅仅因为 LLM 给出了审查结论，就据此决定合并或者拒绝某个改动。 这套准则真正有约束力的地方，在于它的执行方式。 如果有人故意隐瞒或者虚假陈述自己使用 LLM 的情况，将被视为违反 Rust 项目的《行为准则》，与骚扰行为处于同一级别。第一次违规可能收到警告，反复违规则可能被封禁。 文件同时明确承认，其中很多规定实际上并没有办法完全靠技术手段强制执行，而且这是有意为之。准则中写道：“我们的目标并不是抓住每一次违规行为……我们的目标，是消除任何可以推脱的空间：让人们必须在遵守准则和故意违反准则之间作出选择。” Rust 并不是唯一一个开始给 LLM 划边界的项目，而它和 Zig 之间的对比很有意思。 Zig 的严格禁用 LLM / AI 规则更加彻底：不仅禁止 LLM 生成的代码和文字，也禁止改写或转述 LLM 内容，同时不允许使用 AI 做编辑、翻译、头脑风暴或找 Bug。Zig 的方案执行成本低，但对贡献者来说遵守成本高。Rust 则刚好相反：它要求审阅者做更多判断，但也允许贡献者继续使用他们本来就会用到的 LLM 工具。 AI 写多了，就会触发“熔断” Rust 并没有彻底禁止 LLM 编写代码，而是把这类贡献限制在一个边界划得非常清楚的实验中。 首先，任何由 LLM 创建的改动，都必须提前和一名明确指定的审阅者沟通好；这些改动不能涉及编译器健全性等关键部分；必须有充分测试，也必须接受充分的人类审查；而且无论什么情况，都必须披露 LLM 的参与。 新贡献者尤其受到严格限制。如果你此前没有参与过项目，就不能直接提交一份由 LLM 创建的 Pull Request，必须先找到愿意负责审查的审阅者。如果你修改的那部分代码原本没有现成的测试套件，那么你必须自己补上一套测试，否则就只能关闭这个 PR。没有例外。 这个实验甚至设置了自己的“熔断机制”。 如果在任意一个六周时间窗口内，已经合并的 PR 中有超过一半是由 LLM 创建的，那么所有 LLM 创建的 PR 都将暂停合并，直到它们的占比重新下降到 50% 以下，而且至少要冷却 10 天。 六周这个周期并不是随便选的，它正好和 Rust 的六周发布周期一致。 所有此类 PR 都会加上一个新的 ai-assisted 标签，并被同步到一个私有的 Zulip 频道。这个频道的目的并不是设置新的审核门槛，而是收集数据：例如使用 LLM 辅助的贡献者是否真的在学习、之后是否还会继续参与项目，以及他们最终是否能够持续产出有价值的工作。 Nelson 在公告中提到了三个压力，它们最终促使这些团队从过去的非正式管理方式，转向把规则明确写下来。 第一个问题是，一份看起来非常漂亮的 Pull Request，已经不能再代表作者真的投入了大量精力，也不能代表作者真正理解里面的代码。 过去，如果一个开源项目收到一份结构完整、测试充分、说明详细的 PR，审阅者通常会默认，背后的人花了很多时间，也对自己提交的东西有一定理解。但在 LLM 时代，这个信号正在失效，而 Rust 项目的代码审查文化过去相当依赖这种信任。 第二个问题，是代码生成成本下降以后，原本就紧张的审查资源变得更加紧张。目前 rust-lang/rust 仓库还有 1281 个未关闭的 PR。Rust 项目长期以来真正稀缺的资源，从来都不是代码，而是审阅者的判断力和时间。LLM 可以让一个人非常快地生成更多代码，但并不会同步增加能够判断这些代码是否应该进入项目的人。 第三个问题，是一些贡献者开始把审阅者的意见复制进 LLM，再把 LLM 的回答复制回 GitHub。按照 Nelson 的说法，这种做法是在“浪费所有人的时间”。因为如果审阅者想知道 LLM 怎么想，他们完全可以自己去问。代码审查真正需要的是贡献者本人的判断和理解。 这种做法还会破坏代码审查中的一个基础假设：审阅者默认自己是在和一个真实的人交流，而这个人确实在认真理解问题、回应反馈。 连 Rust 自己人，也没谈拢该不该用 AI 这项准则背后还有一个重要背景：Rust 项目内部对于 AI 的态度，本身就存在明显分歧。 其动机部分明确写道，Rust 内部对于什么时候、以什么方式使用 AI 工具，目前并没有形成共识，“而且很可能永远也不会形成共识”。 项目成员的立场跨度非常大。有人每天都在使用 AI 工具，也有人认为任何形式的 AI 使用都不