Rust官方博客宣布采用LLM政策

最近，Rust 项目中有五个团队采用了一项我最初起草的政策，用于规范在 rust-lang/rust 单体仓库中贡献时如何使用大型语言模型。值得注意的是，新政策并非对 LLM 的官方立场，也不会在 Rust 项目各处通用。我为非常特定的目的编写了它，具体原因如下。

这篇文章会讨论我们为何创建这项政策、政策内容是什么，以及这将如何影响贡献者。

该政策影响以下几类人：

在 rust-lang/rust 上审核或 moderation PR 的人。 在 rust-lang/rust 上提交包含 LLM 生成代码的 PR 的人。 使用 LLM 发现问题并在 rust-lang/rust 上发帖的人。 在 rust-lang/rust 上撰写 issue 或评论并直接引用 LLM 输出的人。

如果你不在上述人群中，无需改变工作方式。

为什么要创建这项政策？

Rust 项目虽然是一个技术产物的集合，但同时也是一个社区，人们在其中共同努力构建、维护和扩展这些产物。当我们谈论"为 Rust 项目做贡献"时，部分指的是在这些产物上的工作，但也意味着加入这个社区、与已经在那里的人合作。

甚至在这项政策创建之前，人们就已经在使用 LLM 为 rust-lang/rust 做贡献了。有些用法尊重了我们的社区：将消息翻译成英语以便人们用自己的母语起草；为新手贡献者可能编写的代码片段查找糟糕的诊断信息；分析 RFC 看看是否遗漏了可能影响语言设计的其他部分的讨论。有些用法有时并非故意地，没有做到尊重社区。

我见过 LLM 给我们的社区带来三个主要问题：

精致的技术产品不再代表努力和理解。

让代码更容易编写加剧了我们现有的审核带宽问题。

人们机械地从 LLM 复制粘贴是对我们时间的浪费。

随着时间推移，这些问题越来越多，直到我们不得不创建专门渠道和 moderation 政策来处理它们。然而，这些渠道与我们的透明和欢迎原则相悖，因为新贡献者根本不知道规则是什么。

新政策将这些规则正式公开，这样新贡献者就知道如何加入我们的社区而不会因为不理解的原因被关闭 PR，现有的审核者也可以轻松指向规则作为关闭不符合规定的 PR 的可执行理由。

技术产品不再代表努力

过去，如果一个开源项目收到了一个精致、测试充分、详细的 PR，这表明另一端有人投入了时间、精力和理解到这个 PR 中。这在几个方面影响了 Rust 的文化：

我们通常不愿意关闭 PR，因为它们代表了他人的辛勤工作。

我们的流程强调增量讨论，如果在创建或审核过程中发现了新事实，允许 PR 改变现有设计。

我们将 PR 视为某人有意加入我们的社区并接受指导以处理未来 PR 的标志。

有了 LLM，这些信号都不再可靠。精致的 PR 不再代表努力；精致 PR 的作者不一定理解自己的代码——在自主代理的情况下，另一端根本没有人了；而且因为编写代码变得如此容易，精致 PR 不再表明某人可能会长期留下来。

让代码更容易编写导致审核问题

在撰写本文时，rust-lang/rust 有 1,281 个待合并的 PR。这代表了作者和审核者投入的大量时间。我们长期以来存在一个问题：想要写代码的人多于愿意审核代码的人。随着 LLM 的出现，这个问题只会变得更糟。

审核的大部分工作不仅仅是抓 bug。很大一部分是决定这个方向是否是一个好的方法，这个 PR 本身是否是一个好主意。换句话说，审核是由决策组成的。

向审核者" shotgunning" PR 会给他们带来很高的精神成本。我认为大多数 LLM PR 的作者真心相信自己在帮忙，但从我们的角度来看，代码本身是变更中最小的一部分，在某些方面也是最不重要的。我们更关心的是作者理解代码在做什么、规划它未来如何变化、以及决定它应该是什么样子。代码本身无法帮助任何这些。

机械复制粘贴 LLM 输出是浪费时间

我们经常会遇到这样的人：他们通过将审核评论复制粘贴到 LLM 中，然后将 LLM 的回复复制粘贴回 GitHub 来回应审核评论。直白地说：这是浪费每个人的时间。如果我们想要 LLM 的意见，我们可以自己问它。我们想听到的是你的想法，而不是机器的想法。

此外，这是对审核者和作者之间信任的破坏。当我们审核时，我们的假设是我们正在与一个想要尽力做好工作的真实的人交谈。粘贴 LLM 文本会产生怀疑：作者真的在乎吗？这里真的有一个人吗？

在这项政策之前，我们对 moderation 采取了"荒野西部"的方式。我们有数十个 LLM PR；没有披露规则；有人试图在他们的第一个 PR 中添加有风险的 MIR 优化；有人在 PR 描述中发布"Verification: git diff --check"，好像那能做什么一样。虽然我们有"授权审核者拒绝负担过重的 PR"作为 moderation 可以指向的内容，但我们的执法不一致，我们的规则也没有在任何地方公布。实际上，规则是"只要不是明显糟糕的，什么都可以"。与以前的情况相比，新政策既严格得多也清晰得多。

无论你对 LLM 是好是坏还是神秘的第三种东西的看法如何，它们不能再被忽视了。我们的选择不是"没有政策"或"有政策"。我们的选择是让政策成为一份非官方的 moderation 笔记还是我们公开支持的东西。

为什么不完全禁止 LLM，或者允许我们认为有利于社会的任何 LLM 使用？因为 Rust 治理不是这样运作的。我们没有一个仁慈的独裁者可以说"禁止 LLM 生成的内容，无论是代码还是文章"或"AI 是一个工具，就像我们使用的其他工具一样"。

Rust 通过共识运作。正如政策所述：

Rust 项目内部——而且可能永远不会——对于何时/如何/在哪里使用基于 AI 的工具是可接受的，没有共识。Rust 项目和社区的许多成员发现 AI 有价值；许多其他人认为其对社会和气候的负面影响严重到任何使用都是不可接受的。还有些人在形成自己的看法。

尽管存在这些差异，我们有许多共同的价值观：

在我们的集体项目中建立一个深度专家的社区。

建立一个包容的社区，让每个人都感到受欢迎和受尊重。

我们希望将来有可能改变政策。该政策有几项条款使其比最初通过时更容易改变。领导委员会也在考虑创建一个子团队来处理 LLM 政策，这样我们就会有更少的"噩梦"30 人批准要求。

我不认为这项政策中的每条规则都是完全好的。我确实认为把我们的规则写下来比不写更好，而且拥有一项每个人都有些不喜欢的政策会推动我们改进治理结构。

政策说了什么？

政策本身总结如下：

使用 LLM 回答问题、分析、提炼、完善、检查、建议、审核是可以的。但不能用于创造。

第一类用途是允许的，有时需要披露。第二类用途受到严格限制。

除作者外，任何人都无需阅读 LLM 输出，除非他们选择：LLM 输出不允许出现在公共文档、PR 描述或 GitHub 评论中，除非明确标注；审核者如果不想看，无需查看 LLM PR。

没有人必须使用 LLM 才能为 rust-lang/rust 做贡献：政策必须首先为人编写，然后才为机器总结；LLM 审核不能替代人工审核或自我审核。

你可以在不公开的地方生成只有你自己看到的 LLM 内容，无需披露，只要你不发布到你期望我们阅读或审核的地方。

机器翻译、"trivial"变更、使用 LLM 发现 bug、以及使用 LLM 审核他人的工作需要披露。我们欢迎用你的母语发布的消息；贡献不需要英语翻译。

关于 LLM 生成的代码变更有非常严格的指南：

预先安排的、非关键的、高质量的、经过充分测试和审核的、最初由 LLM 创建的代码变更是允许的，需要披露。

该政策对 LLM 生成变更的要求比人工编写的变更更高，而不是更低：LLM PR 必须有测试，仅此一点，无论这有多难，还有其他各种限制；LLM 不得生成影响正确性的关键变更，除非作者已经是该领域专家，即使如此也强烈不鼓励。

总体而言，该政策侧重于理解，帮助确保我们对代码有心智模型，而不仅仅是机械地做正确事情的产物。我们的动机受到了 Isaac Asimov 的《专业》一文的影响。没有程序员会只靠胶带。

你必须披露 LLM 生成的内容。你可以选择不发布 LLM 内容，或者你可以选择发布并披露其来源。你不能隐藏 LLM 的参与。

禁止骚扰。你不能因为别人使用 LLM 而骚扰他们，无论他们的使用是否被政策禁止。在与 Rust 项目互动时，你必须始终遵守行为守则。

更多信息请参阅政策本身。

政策的某些部分是无法执行的。这不是 bug。目标不是抓住每一个违规行为，而是创建一个清晰的亮线规则：所有公开的 LLM 文本都需要披露，除非政策明确豁免。这允许 moderators 根据行为而非意图识别违规行为，只在决定如何回应时才考虑意图。

这如何影响贡献者？

你必须披露在发现或报告问题中涉及的任何 LLM。你必须告诉我们你是否使用 LLM 发现了问题。你必须清楚引用并指出你报告中哪些部分是 LLM 生成的；"无 LLM 生成评论"规则也适用于你。

提交 LLM 生成代码的作者

如果你向 rust-lang/rust 提交带有 LLM 生成代码的 PR，我写了一份你应该遵循的指南清单。你可以不考虑它们，或者实际上根本不读这份清单，如果你遵循政策的这条简单指南：

使用 LLM 回答问题、分析、提炼、完善、检查、建议、审核是可以的。但不能用于创造。

请参阅政策的"允许"部分以了解这意味着什么的完整列表。请参阅 rustc-dev-guide 获取完整指南清单。

你可以关闭不符合政策的 PR，无需提问。请同时将作者指向 #llm-mentoring。参阅 dev guide 获取确切情况和建议措辞。

你无需负责确定 PR 是否是 LLM 生成的；该责任在于作者。我们将添加一个 PR 模板，询问作者他们的代码是否由 LLM 生成，这样这很少会成为问题。

如果作者声称他们的代码不是 LLM 生成的，但你仍然不确定，请私下向 moderation 报告 PR。风格不是证据；请不要因为怀疑而指责人们使用 LLM。报告不是为了惩罚；mod 团队有兴趣看到违规和非违规行为。

如果你自愿审核 LLM PR，以下部分适用于你。除非有人自愿，否则没有人有义务审核 LLM PR。

每个人都应该遵循新政策，而不仅仅是作者。这意味着你有责任检查 LLM 创建的 PR 是否触及了政策不允许的领域，如文档、诊断信息或正确性关键变更。你可以要求作者不使用 LLM 生成代码重新做，在这种情况下本节不适用。

在 dev guide 中有你被期望执行的规则的更详细摘要。官方政策始终是权威版本。

moderators、团队负责人、审核者、委员会代表以及项目内外各种人都为此付出了相当多的工作。有些工作早在政策本身编写之前几个月就开始了。我想感谢每一个做出贡献的人，无论直接或间接。

这不是故事的结束。政策的目标之一是帮助我们收集数据：人们是否在使用 LLM 做有趣和有用的事情？他们是否在学习？他们是否在重复贡献？这些问题的答案将帮助我们决定政策未来如何变化。

这不是 Rust 项目团队发布的第一项 LLM 政策，希望也不会是最后一项。虽然当前政策仅适用于 rust-lang/rust 单体仓库，我仍然相信 Rust 将受益于项目范围内的政策，指定我们对聊天、论坛、公共通信、没有明确政策的仓库和其他跨项目领域的期望。