rust-lang/rust is adopting an LLM policy

rust-lang/rust 正在采纳一项大语言模型（LLM）政策

Aug. 5, 2026 · Jynn Nelson 2026年8月5日 · Jynn Nelson

Recently, five teams in the Rust project adopted a policy that I originally authored, governing how Large Language Models can be used when contributing to the rust-lang/rust monorepo. Notably, the new policy is not an official stance on LLMs, and does not apply everywhere in the Rust project. I wrote it for a very specific purpose, described below. This post talks about why we created that policy, what it says, and how this will affect contributors. 最近，Rust 项目中的五个团队采纳了我最初起草的一项政策，旨在规范在向 rust-lang/rust 代码仓库贡献代码时如何使用大语言模型（LLM）。值得注意的是，这项新政策并非针对 LLM 的官方立场，也不适用于 Rust 项目的所有领域。我编写它是为了一个非常具体的目的，详见下文。本文将探讨我们为何制定该政策、其内容为何，以及它将如何影响贡献者。

The policy affects the following groups of people: People who review or moderate PRs on rust-lang/rust. People who author PRs with LLM-generated code on rust-lang/rust. People who discover issues using LLMs and post them on rust-lang/rust. People who write issues or comments that directly quote an LLM on rust-lang/rust. If you are not in one of those groups, you don’t have to change anything about how you work. 该政策影响以下群体：在 rust-lang/rust 上审查或管理 PR 的人；在 rust-lang/rust 上提交包含 LLM 生成代码的 PR 的人；使用 LLM 发现问题并将其发布在 rust-lang/rust 上的人；以及在 rust-lang/rust 上编写直接引用 LLM 内容的问题或评论的人。如果你不属于这些群体，则无需改变你的工作方式。

Why was this policy created? While the Rust project is a collection of technical artifacts, it is also a community of people who work together to build, maintain, and extend those artifacts. When we talk about “contributing to the Rust project”, we partly mean work on those artifacts, but we also mean joining that community and collaborating with the people already there. 为什么要制定这项政策？虽然 Rust 项目是一系列技术产物的集合，但它同时也是一个由共同构建、维护和扩展这些产物的人们组成的社区。当我们谈论“为 Rust 项目做贡献”时，部分是指对这些产物的工作，但同时也意味着加入这个社区并与现有成员协作。

Even before this policy was created, people were using LLMs to contribute to rust-lang/rust. Some of those uses respected our community: translating messages to English so people could draft them in their native language; finding poor diagnostics for code snippets that new contributors to Rust might write; analyzing RFCs to see if they were missing a discussion of other parts of the language that could affect the design. Some of those uses, sometimes unintentionally, did not. 甚至在政策制定之前，人们就已经在使用 LLM 为 rust-lang/rust 做贡献。其中一些用法尊重了我们的社区：例如将消息翻译成英语，以便人们可以用母语起草；为 Rust 新贡献者可能编写的代码片段寻找糟糕的诊断信息；分析 RFC 以查看它们是否遗漏了可能影响设计的其他语言部分的讨论。然而，有些用法（有时是无意的）则并非如此。

I’ve seen LLMs causing three main issues for our community: Polished technical products no longer indicate effort and understanding. Making code easier to write exacerbates our existing issues with review bandwidth. People mechanically copy-pasting to and from an LLM is a waste of our time. As time went on, these issues grew and grew, until we had to create dedicated channels and moderation policy for how to deal with them. However, those channels work against our goals of being transparent and welcoming, because new contributors have no idea what the rules are. The new policy formalizes those rules publicly, so that new contributors know how to join our community without getting their PRs closed for reasons they don’t understand, and so that existing reviewers can easily point to the rules as an actionable reason when closing PRs that don’t follow them. 我观察到 LLM 给我们的社区带来了三个主要问题：精美的技术产物不再代表努力和理解；代码编写变得容易，加剧了我们现有的审查带宽问题；人们机械地在 LLM 之间复制粘贴内容是在浪费我们的时间。随着时间的推移，这些问题愈演愈烈，直到我们不得不建立专门的渠道和管理政策来处理它们。然而，这些渠道违背了我们保持透明和欢迎的初衷，因为新贡献者根本不知道规则是什么。新政策将这些规则公开化，以便新贡献者知道如何加入我们的社区，而不会因为无法理解的原因被关闭 PR；同时也让现有的审查者在关闭不符合规则的 PR 时，可以轻松地引用这些规则作为可执行的理由。

Technical products no longer indicate effort 技术产物不再代表努力

It used to be that if an open source project got a polished, well-tested, detailed PR, that indicated that there was someone on the other end who had put time, effort, and understanding into the PR. That influenced Rust’s culture in several ways: We are generally reluctant to close PRs, since they represent someone else’s hard work. Our process emphasizes incremental discussions, where PRs are allowed to change existing design if we discover new facts during creation or review. We treat PRs as an indication that someone is interested in joining our community and being mentored to work on future PRs. 过去，如果一个开源项目收到一个精美、经过充分测试且详细的 PR，这表明另一端有人投入了时间、精力和理解。这在几个方面影响了 Rust 的文化：我们通常不愿关闭 PR，因为它们代表了他人的辛勤工作；我们的流程强调渐进式讨论，如果在创建或审查过程中发现新事实，允许 PR 更改现有设计；我们将 PR 视为某人有兴趣加入我们社区并接受指导以参与未来 PR 的信号。

With LLMs, none of these signals are reliable. Polished PRs no longer indicate effort; authors of polished PRs no longer necessarily understand their code—and in the case of autonomous agents, there is no longer someone on the other end at all; and because it’s become so much easier to write code, a polished PR no longer indicates that someone is likely to stick around for the long term. 有了 LLM，这些信号都不再可靠。精美的 PR 不再代表努力；精美 PR 的作者不一定理解他们的代码——而在自主代理的情况下，另一端甚至根本没有人；而且由于编写代码变得容易得多，一个精美的 PR 也不再意味着某人可能会长期留下来。

Making code easier to write causes review issues 代码编写变得容易导致了审查问题

At the time of writing, there are 1,281 open PRs to rust-lang/rust. This represents a staggering amount of time invested by both authors and reviewers. We have long had the problem that there are more people who want to write code than people willing to review it. With the advent of LLMs, this problem only gets worse. Most of the work of reviewing is not simply catching bugs. A great deal of it is deciding whether this direction is a good approach, whether the PR is a good idea at all. In other words, reviewing is made of decisions. “Shotgunning” PRs at reviewers incurs a high mental cost for them. I think most authors of LLM PRs believe that they are sincerely helping, but from our perspective, the code itself is the smallest and in some ways least important part of the change. We care much more about authors understanding what the code does, planning how it will change in the future, and deciding what it should look like. The code itself cannot help with any of those. 在撰写本文时，rust-lang/rust 有 1,281 个待处理的 PR。这代表了作者和审查者投入了惊人的时间。长期以来，我们一直面临着想写代码的人比愿意审查代码的人多的问题。随着 LLM 的出现，这个问题变得更加严重。审查的大部分工作不仅仅是捕捉 Bug。很大一部分工作是决定这个方向是否是一个好的方法，以及这个 PR 本身是否是一个好主意。换句话说，审查是由决策组成的。向审查者“狂轰滥炸”式地提交 PR 会给他们带来巨大的心理负担。我认为大多数 LLM PR 的作者相信他们是在真诚地提供帮助，但从我们的角度来看，代码本身是变更中最小的，在某些方面也是最不重要的部分。我们更关心作者是否理解代码的功能、规划其未来如何变更，以及决定它应该是什么样子。代码本身无法帮助解决这些问题。

Mechanically copy-pasting LLM output is a waste of time 机械地复制粘贴 LLM 输出是在浪费时间

We will often get people who respond to review comments by copy-pasting them into their LLM, then copy-pasting its response back onto 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. Moreover, this is a breach of trust between the reviewer and the author. Our assumption when we review is that we’re talking to a real person who wants to do their best work. Pasting LLM text creates suspicion: does the author actually care? Is there a person here at all? 我们经常遇到有人通过将审查意见复制粘贴到 LLM 中，然后将回复粘贴回 GitHub 来回应审查。坦率地说：这是在浪费大家的时间。如果我们想要 LLM 的意见，我们可以自己问它。我们想听到的是你的想法，而不是机器的想法。此外，这破坏了审查者和作者之间的信任。我们在审查时的假设是，我们正在与一个想要尽其所能工作的真实的人交谈。粘贴 LLM 的文本会产生怀疑：作者真的在乎吗？这里真的有人吗？

So why a policy? Before this policy, we had a “wild west” approach to moderation. We had dozens of LLM PRs; no disclosure rules; people trying to add risky MIR optimizations as their first PR; and people posting “Verification: git diff —check” in their PR description as if that did something. While we had something for moderators to point to in the form of “Empower reviewers to reject burdensome PRs”, our enforcement was inconsistent and our rules were not published anywhere. In practice, the rule was “anything goes, as long as it’s not obviously horrible”. Compared to the previous situation, the new policy is both much more strict and much more clear. Regardless of 那么为什么要制定政策呢？在制定该政策之前，我们的管理方式处于“蛮荒西部”状态。我们有几十个 LLM PR；没有披露规则；有人试图将有风险的 MIR 优化作为他们的第一个 PR；还有人在 PR 描述中发布“Verification: git diff —check”，好像这有什么用一样。虽然我们有“授权审查者拒绝繁重的 PR”这样的准则供管理员参考，但我们的执行并不一致，规则也没有发布在任何地方。实际上，规则就是“只要不是明显糟糕，什么都可以”。与之前的情况相比，新政策既严格得多，也清晰得多。无论如何……