rust-lang/rust 正在采用 LLM 政策

# rust-lang/rust 正在采用一项 LLM 政策 | Inside Rust Blog 最近，Rust 项目中的五个团队（[链接](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust-forge/pull/1040#issuecomment-4438128685)）采纳了一项[政策](https://forge.rust-lang.org/policies/llm-usage.html)，这项政策由我最初撰写，用于规定在向 `rust-lang/rust` 单体仓库贡献时如何[使用大型语言模型（LLM）](https://en.wikipedia.org/wiki/Large_language_model)。值得注意的是，这项新政策*并非*官方对 LLM 的立场，也*不*适用于 Rust 项目的所有地方。我是为了一个非常具体的目的而撰写它的，下文会说明。 这篇文章将讨论我们为什么创建这项政策、政策的内容，以及它将如何影响贡献者。 该政策影响以下人群： - 在 `rust-lang/rust` 上审阅或审核 PR 的人。 - 在 `rust-lang/rust` 上使用 LLM 生成的代码提交 PR 的人。 - 使用 LLM 发现问题并在 `rust-lang/rust` 上发布 issue 的人。 - 在 `rust-lang/rust` 上撰写直接引用 LLM 的 issue 或评论的人。 如果你不属于上述任何人群，你不必改变你的工作方式。 ## 为什么创建这项政策？ 虽然 Rust 项目是一系列技术产物的集合，但它也是一个由共同构建、维护和扩展这些产物的人们组成的*社区*。当我们说“为 Rust 项目做贡献”时，我们部分指的是在这些产物上的工作，但也包括加入这个社区，并与已经在那里的人协作。 即使在这项政策创建之前，人们已经在使用 LLM 为 `rust-lang/rust` 做贡献。其中一些使用方式尊重了我们的社区：将消息翻译成英语，以便人们可以用母语起草内容；为 Rust 新手可能编写的代码片段查找糟糕的诊断信息；分析 RFC，看它们是否遗漏了对语言中其他可能影响设计的部分的讨论。还有一些使用方式——有时是无意的——则没有。 我目睹了 LLM 给我们的社区带来了三个主要问题： 1. 精致的技术产物不再代表投入的努力和理解。 2. 让写代码变得更容易加剧了我们现有的审阅带宽问题。 3. 人们机械地在 LLM 之间复制粘贴是在浪费我们的时间。 随着时间的推移，这些问题越来越大，直到我们不得不为如何处理它们建立专门的渠道和审核政策。然而，这些渠道与我们保持透明和欢迎新人的目标相悖，因为新贡献者根本不知道规则是什么。 新政策公开地正式确立了这些规则，以便新贡献者知道如何加入我们的社区，而不会因为无法理解的原因被关闭 PR，也便于现有审阅者在关闭不符合规则的 PR 时，可以轻松地将规则作为可操作的理由。 ### 技术产物不再代表努力 过去，如果一个开源项目收到一个精致、测试充分、细节详尽的 PR，那意味着另一端有一个为之投入了时间、努力和理解的人。这影响了 Rust 的文化，体现在几个方面： - 我们通常不愿意关闭 PR，因为它们代表了他人的辛勤工作。 - 我们的流程强调增量讨论，如果在创建或审阅过程中发现了新事实，PR 可以改变现有设计。 - 我们将 PR 视为某人有意加入我们的社区并希望接受指导、参与未来 PR 的信号。 有了 LLM，这些信号都不再可靠。精致的 PR 不再代表努力；精致 PR 的作者不一定理解他们的代码——而在自主代理的情况下，另一端甚至不再有人；而且因为写代码变得如此容易，一个精致的 PR 不再代表某人有可能长期留下。 ### 让写代码更容易导致审阅问题 在撰写本文时，`rust-lang/rust` 有 **1,281 个开放 PR**。这代表了作者和审阅者投入的惊人时间。我们长期以来一直面临这样的问题：想写代码的人比愿意审阅的人多。随着 LLM 的出现，这个问题只会更严重。 审阅的大部分工作不仅仅是抓 bug。很大一部分工作在于决定*这个方向是否是好的方法*、这个 PR 是否根本是个好主意。换句话说，审阅是由[决策](https://web.archive.org/web/20260213080731/https://siderea.dreamwidth.org/1219758.html)组成的。 向审阅者“滥发”PR 会给他们带来很高的心智成本。我认为大多数 LLM PR 的作者都相信自己是在真诚地帮忙，但从我们的角度来看，代码本身是变更中最小、在某些方面最不重要的部分。我们更关心作者*理解*代码的作用，*规划*它未来将如何变化，以及*决定*它应该是什么样子。代码本身无法帮助我们做到其中任何一点。 ### 机械地复制粘贴 LLM 的输出是浪费时间 我们经常遇到一些人，他们把审阅意见复制粘贴到 LLM 中，然后把 LLM 的回复再复制粘贴回 GitHub。坦率地说：**这是在浪费所有人的时间**。如果我们想要一个 LLM 的意见，我们可以自己去问它。我们想听到的是*你*的想法，而不是机器的。 此外，这还破坏了审阅者和作者之间的信任。我们审阅时的假设是，我们正在与一个想要做到最好的真实的人对话。粘贴 LLM 文本会引发怀疑：作者真的在乎吗？这里到底有没有人？ ### 那么为什么需要政策？ 在这项政策之前，我们的审核是“蛮荒西部”式的。我们有几十个 LLM PR；没有披露规则；有人试图添加有风险的 [MIR 优化](https://rustc-dev-guide.rust-lang.org/mir/optimizations.html)作为他们的第一个 PR；还有人把“验证：`git diff --check`”（[链接](https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---check)）写在 PR 描述里，好像这能有什么用。虽然我们确实有“赋予审阅者拒绝繁重 PR 的权力”这样的[东西](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/compiler-team/issues/893)可供审核者引用，但我们的执行并不一致，规则也没有发布在任何地方。实际上，规则就是“只要不是*明显*很糟糕，什么都可以”。与之前的情况相比，新政策既严格得多，也清晰得多。 无论你对 LLM 是好是坏，还是某种隐秘的第三种东西持什么看法，它们都不能再被*忽视*了。我们的选择不是“没有政策”或“有政策”。我们的选择是，让这项政策成为一份非官方的审核笔记清单，还是成为我们公开坚持的东西。 为什么不完全禁止 LLM，或者允许任何我们认为对社会有益的 LLM 使用？因为 Rust 的治理不是这样运作的。我们没有一位仁慈的独裁者，可以说“禁止任何 LLM 生成的内容，无论是代码还是文字”（[链接](https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-policy)），或者说“AI 是一种工具，就像我们使用的其他工具一样”（[链接](https://lore.kernel.org/linux-media/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/)）。 Rust 靠共识运作。正如政策中所述： > Rust 项目内部对于何时/如何/在哪里使用基于 AI 的工具是可接受的，并无共识——很可能永远也不会有。Rust 项目和社区中的许多成员认为 AI 有其价值；另有许多人认为 AI 对社会的负面影响以及气候危害已经严重到任何使用都无法接受。还有一些人仍在形成自己的观点。尽管存在这些分歧，我们仍共享许多价值观： > - 在我们共同的项目中建立一个由深度专家组成的社区。 > - 建立一个让所有人都感到受欢迎和被尊重的包容性社区。 我们希望未来有可能修改这项政策。该政策有[若干条款](https://forge.rust-lang.org/policies/llm-usage.html#conditions-for-modification-or-dissolution)，使它的修改比最初采纳时更容易。领导委员会也正在[考虑设立一个子团队](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/leadership-council/issues/308)来处理 LLM 政策，这样我们就不再需要那些需要 30 人批准的“噩梦”式流程。 我并不认为这项政策中的每一条规则都是完全好的。但我*确实*认为，把我们的规则写下来比不写要好，而且有一项大家都不太喜欢的政策会推动我们改进治理架构。 ## 政策说了什么？ 政策这样总结自己： > 可以使用 LLM 来回答问题、分析、提炼、优化、检查、建议、审阅。但不能用它来**创造**。 第一类用途是允许的，有时需要披露。第二类用途则受到严格限制。 ### 一般规则 除作者本人外，没有人必须阅读 LLM 输出，除非他们自愿：LLM 输出不允许出现在公开文档、PR 描述或 GitHub 评论中，除非明确标记；审阅者如果不想看 LLM PR，则没有义务去看。 没有人被要求必须使用 LLM 来为 `rust-lang/rust` 做贡献：政策必须首先为人类书写，然后才能为机器做简要总结；LLM 审阅不能替代人工审阅或自我审阅。 你可以生成只供自己查看的 LLM 内容，无需披露，只要你没有将其发布到任何期望我们阅读或审阅的地方。 对于机器翻译、“琐碎”改动、发现 bug 以及使用 LLM 审阅他人的工作，都需要披露。我们欢迎你用母语发布信息；贡献时并不要求提供英文翻译。 对于 LLM 生成的代码改动，有非常严格的指导原则： > 事先安排好的、非关键性的、高质量的、测试充分的、经过充分审阅的、由 LLM 最初创建的代码改动是允许的，**但必须披露**。 该政策对 LLM 生成的改动设置了比人类作者改动*更高*的标准，而不是更低：LLM PR 必须要有测试，无论这有多难，此外还有其他各种限制；LLM 不得生成涉及健全性（soundness）的关键改动，除非作者已经是该领域的专家，即使如此也强烈不推荐。 总的来说，这项政策侧重于*理解*，帮助确保我们对自己代码的心智模型不仅仅是机械地做正确事情的人工产物。我们的动机受到了艾萨克·阿西莫夫的[《职业》](https://web.archive.org/web/20201109034130/https://www.abelard.org/asimov.php)的影响。没有程序员磁带。 ### 审核规则 **你必须披露 LLM 生成的内容。**你可以选择不发布 LLM 内容，或者选择发布并披露其来源。你不能隐藏 LLM 的参与。 **不允许骚扰。**你不能因为他人使用 LLM 而骚扰他们，无论其使用是否被政策禁止。在与 Rust 项目互动时，你必须始终遵守[行为准则](https://rust-lang.org/policies/code-of-conduct/)。 更多信息请参阅[政策本身](https://forge.rust-lang.org/policies/llm-usage.html)。 政策中的某些部分无法强制执行。这不是 bug。目标*不是*抓住每一次违规，而是建立一条清晰、明确红线规则：所有公开的 LLM 文本都必须披露，除非政策明确豁免。这使审核者能够基于*行为*而非意图来识别违规，并且只在决定如何回应时才考虑意图。 ## 这对贡献者有什么影响？ ### Issue 报告者 你必须在发现或报告 issue 时披露任何 LLM 的参与。如果你使用 LLM 发现了问题，必须告诉我们。你必须清楚地引用并指明报告的哪些部分是 LLM 生成的；“禁止 LLM 生成评论”的规则同样适用于你。 ### 发布 LLM 生成代码的作者 我已经撰写了一份指南清单，如果你要向 `rust-lang/rust` 提交包含 LLM 生成代码的 PR，应该遵循它。如果你遵循政策中的这条简单准则，就可以不去考虑它们，甚至根本不用读清单： > 可以使用 LLM 来回答问题、分析、提炼、优化、检查、建议、审阅。但不能用它来**创造**。 有关其含义的完整列表，请参阅政策中的[“允许”部分](https://forge.rust-lang.org/policies/llm-usage.html#-allowed)。完整指南清单请参阅 [rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.html)。 ### 审阅者 #### 一般审阅 你可以关闭不遵循政策的 PR，无需多问。请在关闭的同时将作者指向 [#llm-mentoring](https://rust-lang.zulipchat.com/join/rlfvpemsaacs3pfi6kwqnqjb/)。具体情形和建议措辞请参阅[开发指南](https://rustc-dev-guide.rust-lang.org/llm-guidance/reviewing.html)。 你不需要负责判断某个 PR 是否是 LLM 生成的；这个责任在作者一方。我们将添加一个 PR 模板，询问作者的代码是否由 LLM 生成，这样这类问题就很少会出现了。 如果作者声称他们的代码不是 LLM 生成的，但你仍然不确定，请*私下*向审核团队报告该 PR。风格不是证据；请不要指责他人使用 LLM。报告并不是为了惩罚；审核团队既对违规情况感兴趣，也对非违规情况感兴趣。 #### 审阅 LLM 代码 如果你自愿审阅 LLM PR，以下部分适用于你。除非自愿，没有人被要求审阅 LLM PR。 每个人都需要遵循新政策，不仅仅是作者。这意味着**你有责任**检查 LLM 创建的 PR 是否触及政策禁止的领域，例如文档、诊断或健全性关键改动。你可以要求作者不使用 LLM 生成的代码重做，在这种情况下，本部分不适用。 你应执行的规则有更详细的摘要，见[开发指南](https://rustc-dev-guide.rust-lang.org/llm-guidance/reviewing.html)。[官方政策](https://forge.rust-lang.org/policies/llm-usage.html)仍是最权威的版本。 ## 接下来呢？ 审核者、团队负责人、审阅者、委员会代表以及项目内外的其他许多人已经为此投入了大量工作。其中一些工作在政策本身撰写前几个月就开始了。我想感谢每一位直接或间接为此作出贡献的人。 这并不是故事的终点。这项政策的目标之一是帮助我们在实践中收集数据：人们是否在用 LLM 做有趣且有用的事情？他们是否在学习？他们是否在持续贡献？这些问题的答案将帮助我们决定政策未来如何变化。 这不是 Rust 项目内团队发布的第一份 LLM 政策，希望也不会是最后一份。虽然当前政策仅适用于 `rust-lang/rust` 单体仓库，但我仍然认为，Rust 会受益于一份项目范围的政策，明确规定我们在聊天群组、论坛、公开交流、没有明确政策的仓库以及其他跨项目领域的期望。