Rust项目采用LLM贡献政策：规范AI使用，维护社区质量

最近，Rust项目中的五个团队采纳了我最初起草的一项政策，该政策规定了在为 rust-lang/rust 单体仓库做贡献时如何使用大型语言模型（LLM）。值得注意的是，这项新政策并非官方对LLM的立场，也不适用于Rust项目的所有部分。

我写这份政策是为了一个非常具体的目的，下文将详细说明。这篇文章讨论了为什么我们制定这项政策、政策内容是什么，以及它将如何影响贡献者。该政策影响以下人群：- 在 rust-lang/rust 上审查或审核PR的人。

- 在 rust-lang/rust 上使用LLM生成代码编写PR的人。- 使用LLM发现问题并在 rust-lang/rust 上发布的人。- 在 rust-lang/rust 上撰写直接引用LLM内容的问题或评论的人。

如果你不属于这些群体，你不需要改变任何工作方式。为什么制定这项政策？虽然Rust项目是一系列技术成果的集合，但它也是一个由共同构建、维护和扩展这些成果的人们组成的社区。

当我们谈论“为Rust项目做贡献”时，部分意思是研究这些成果，但也意味着加入这个社区并与已经在那里的人们合作。甚至在这项政策制定之前，人们就已经在使用LLM为 rust-lang/rust 做贡献了。

其中一些用途尊重了我们的社区：将消息翻译成英语，以便人们可以用母语起草；为Rust新贡献者可能编写的代码片段找出糟糕的诊断信息；分析RFC，看看它们是否遗漏了对可能影响设计的语言其他部分的讨论。

但其中一些用途，有时是无意的，却没有做到这一点。我看到LLM给我们的社区带来了三个主要问题：- 经过打磨的技术产品不再表明努力和理解。- 让代码更容易编写加剧了我们现有的审查带宽问题。- 人们机械地复制粘贴LLM内容是在浪费我们的时间。

随着时间的推移，这些问题越来越严重，直到我们不得不创建专门的渠道和审核政策来处理它们。然而，这些渠道与我们透明和欢迎新人的目标背道而驰，因为新贡献者不知道规则是什么。

新政策将这些规则公开正式化，以便新贡献者知道如何加入我们的社区，而不会因为不理解的原因导致PR被关闭，同时现有的审查者可以轻松地指出这些规则作为关闭不遵循规则的PR时的可操作理由。

技术产品不再表明努力过去，如果一个开源项目收到一个精心设计、经过良好测试、详细的PR，那表明另一端有人投入了时间、精力和理解。这在几个方面影响了Rust的文化：- 我们通常不愿意关闭PR，因为它们代表着别人的辛勤工作。

- 我们的流程强调渐进式讨论，如果我们在创建或审查期间发现新事实，PR可以更改现有设计。- 我们将PR视为有人有兴趣加入我们的社区并接受指导以从事未来PR的迹象。有了LLM，这些信号都不再可靠。

打磨过的PR不再表明努力；打磨过的PR的作者不再一定理解他们的代码——在自主智能体的情况下，另一端甚至根本没有人；而且因为编写代码变得如此容易，一个打磨过的PR不再表明有人可能会长期留下来。

让代码更容易编写导致审查问题截至撰写本文时，rust-lang/rust 有1,281个开放的PR。这代表了作者和审查者投入的惊人时间。我们长期以来一直面临这样一个问题：想写代码的人比愿意审查的人多。

随着LLM的出现，这个问题只会变得更糟。审查工作的大部分不仅仅是捕捉错误。

很大一部分是决定这个方向是否是一个好方法，PR是否是一个好主意。换句话说，审查是由决策组成的。向审查者“散弹枪式”地发送PR会给他们带来高昂的精神成本。

我认为大多数LLM PR的作者都相信他们是在真诚地提供帮助，但从我们的角度来看，代码本身是变更中最小、在某些方面也是最不重要的部分。我们更关心的是作者理解代码的作用、规划它未来如何变化以及决定它应该是什么样子。

代码本身无法帮助解决其中任何问题。机械复制粘贴LLM输出是浪费时间我们经常会遇到有人通过将审查评论复制粘贴到他们的LLM中，然后将其回复复制粘贴回GitHub来回应审查评论。坦率地说：这是浪费每个人的时间。

如果我们想要LLM的意见，我们可以自己去问。我们想听到你的想法，而不是机器的。此外，这也违反了审查者和作者之间的信任。我们审查时的假设是，我们正在与一个想要尽最大努力的真实的人交谈。粘贴LLM文本会引起怀疑：作者真的在乎吗？

这里到底有没有人？那么为什么需要政策？在这项政策之前，我们采取了一种“狂野西部”式的审核方式。

我们有几十个LLM PR；没有披露规则；人们试图添加有风险的MIR优化作为他们的第一个PR；还有人在PR描述中发布“验证：git diff --check”，好像这能起到什么作用。

虽然我们有“授权审查者拒绝繁重PR”这样的东西供版主引用，但我们的执行不一致，规则也没有在任何地方公布。实际上，规则是“只要不明显糟糕，什么都可以”。与之前的情况相比，新政策既更严格也更清晰。

无论你对LLM是好是坏还是第三种看法，它们都不能再被忽视了。我们的选择不是“没有政策”或“有政策”。我们的选择是让政策成为非官方的审核笔记列表，还是成为我们公开支持的东西。为什么不彻底禁止LLM，或者允许我们认为是亲社会的任何LLM使用？

因为Rust的治理不是这样运作的。我们没有一位仁慈的独裁者可以说“不允许LLM生成的内容，无论是代码还是散文”或“AI是一种工具，就像我们使用的其他工具一样”。Rust是通过共识运作的。

正如政策所说：在Rust项目内部，对于何时/如何/在哪里可以接受使用基于AI的工具，没有共识——而且很可能永远不会达成。

Rust项目和社区的许多成员在AI中发现了价值；许多其他人则认为AI对社会和气候的负面影响足够严重，任何使用都是不可接受的。还有一些人正在形成自己的观点。尽管存在这些差异，但我们有许多共同的价值观：- 在我们的集体项目中建立一个深度专家社区。

- 建立一个包容性的社区，让所有人都感到受欢迎和尊重。我们希望未来能够改变政策。该政策有几项条款使其比最初采用时更容易更改。领导委员会还在考虑创建一个子团队来处理LLM政策，这样我们就可以减少“噩梦般的”30人审批要求。

我不认为这项政策中的每一条规则都是完全好的。我确实认为把规则写下来比不写下来要好，而且制定一项每个人都不太喜欢的政策会促使我们改进治理结构。政策说了什么？该政策这样总结自己：使用LLM来回答问题、分析、提炼、精炼、检查、建议、审查是可以的。

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