文章摘要
Rust项目中的五个团队通过了一项关于大语言模型使用的政策，规定了在rust-lang/rust仓库贡献时如何使用LLM。该政策针对特定群体，包括PR审核者、作者、问题发现者和评论者，但不代表官方立场，也不适用于整个Rust项目。
文章总结
近日，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 给我们的社区带来了三个主要问题： 1. 精良的技术产品不再代表投入和理解的标志。 2. 降低代码编写难度加剧了我们已有的审核带宽问题。 3. 人们机械地在 LLM 和平台之间复制粘贴，浪费了大家的时间。
随着时间的推移，这些问题日益严重，以至于我们不得不设立专门的频道和审核政策来应对。然而，这些频道与我们保持透明和欢迎新人的目标相悖，因为新贡献者根本不知道规则是什么。
新政策将这些规则公开化、正式化，以便新贡献者知道如何融入我们的社区，而不会因不明原因导致 PR 被关闭；同时，也让现有的审核者在关闭不符合规则的 PR 时，能轻松引用这些规则作为可操作的理由。
技术产品不再代表投入
过去，如果一个开源项目收到一个精良、经过充分测试、细节详尽的 PR，这通常意味着提交者投入了时间、精力和理解。这影响了 Rust 的几种文化： - 我们通常不愿关闭 PR，因为它们代表着别人的辛勤工作。 - 我们的流程强调渐进式讨论，允许在创建或审核过程中发现新事实时改变现有设计。 - 我们将 PR 视为有人有兴趣加入我们社区并愿意接受指导以完成未来 PR 的信号。
有了 LLM，这些信号都变得不可靠。精良的 PR 不再代表投入；精良 PR 的作者不一定理解他们的代码——在自主代理的情况下，甚至可能根本没有人在另一端；而且，由于编写代码变得如此容易，一个精良的 PR 也不再表明提交者有可能长期留下来。
降低代码编写难度导致审核问题
截至撰写本文时，rust-lang/rust 有 1,281 个开放的 PR。这代表了作者和审核者投入的惊人时间。我们长期以来一直面临一个问题：想写代码的人比愿意审核代码的人多。随着 LLM 的出现，这个问题只会变得更糟。
审核的大部分工作不仅仅是抓 bug。很大一部分工作是决定“这个方向是否是一个好的方法”，以及这个 PR 本身是否是个好主意。换句话说，审核是由决策构成的。
向审核者“散弹枪式”地提交 PR 会给他们带来高昂的脑力成本。我认为大多数 LLM PR 的作者都真诚地认为自己是在帮忙，但从我们的角度来看，代码本身是变更中最小、某种程度上也是最不重要的部分。我们更关心作者是否“理解”代码的作用、“规划”它未来将如何变化，以及“决定”它应该是什么样子。代码本身无法帮助解决这些问题。
机械复制粘贴 LLM 输出是浪费时间
我们经常看到有人将审核评论复制粘贴到 LLM 中，然后再将 LLM 的回复复制粘贴回 GitHub。直白地说：这是在浪费每个人的时间。如果我们想要 LLM 的意见，我们可以自己去问。我们想听到的是“你”的想法，而不是机器的。
此外，这破坏了审核者与作者之间的信任。我们审核时的假设是，我们正在与一个真实的人交谈，这个人想要尽最大努力做好工作。粘贴 LLM 文本会引发怀疑：作者真的在乎吗？这里到底有没有真人？
那么，为什么需要一项政策？
在这项政策之前，我们的审核方式是“狂野西部”式的。我们有几十个 LLM PR；没有披露规则；有人试图将风险较高的 MIR 优化作为他们的第一个 PR；还有人将“验证：git diff --check”这样的内容写在 PR 描述中，仿佛这能起到什么作用。虽然审核者可以引用“授权审核者拒绝负担过重的 PR”这一原则，但我们的执行并不一致，规则也没有在任何地方公布。实际上，规则就是“只要不是‘明显’糟糕的，什么都可以”。与之前的情况相比，新政策既严格得多，也清晰得多。
无论你对 LLM 的看法是正面、负面还是第三种，都不能再“忽视”它们了。我们的选择不是“没有政策”或“有政策”。我们的选择是，让政策成为一份非官方的审核笔记清单，还是成为我们公开坚持的东西。
为什么不彻底禁止 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 内容，无需披露，只要你不会将其发布到任何你期望我们阅读或审核的地方。
对于机器翻译、“琐碎”的更改、发现 bug 以及使用 LLM 审核他人的工作，需要披露。我们欢迎你用母语发布消息；贡献不要求必须翻译成英语。
对于 LLM 生成的代码更改，有非常严格的指导方针：
预先安排好的、非关键的、高质量的、经过充分测试和充分审核的、最初由 LLM 创建的代码更改是允许的，但“必须披露”。
该政策对 LLM 生成的更改设定了“更高”的标准，而不是更低：LLM PR 必须包含测试，无论这有多困难，此外还有其他各种限制；LLM 不得生成影响正确性的关键更改，除非作者已经是该领域的专家，即便如此也强烈不鼓励。
总的来说，该政策侧重于“理解”，帮助我们确保对代码有心理模型，而不仅仅是机械地做正确事情的产物。我们的动机受到阿西莫夫《职业》一文的启发。没有程序员磁带。
审核规则
你必须披露 LLM 生成的内容。 你可以选择不发布 LLM 内容，也可以选择发布并披露其来源。你不能隐藏 LLM 的参与。
不允许骚扰。 你不能因为某人使用了 LLM 而骚扰他们，无论他们的使用是否被政策禁止。在与 Rust 项目互动时，你必须始终遵守行为准则。
更多信息请参见政策本身。政策的某些部分是无法强制执行的。这不是一个 bug。目标“不是”抓住每一个违规行为，而是建立一个清晰明确的规则：所有公开的 LLM 文本都需要披露，除非政策特别豁免。这使得审核者能够基于“行为”而非意图来识别违规，并且只在决定如何回应时才考虑意图。
这对贡献者有何影响？
问题报告者
你必须披露在发现或报告问题过程中任何 LLM 的参与。你必须告诉我们你是否使用 LLM 发现了问题。你必须清楚地引用并指出报告的哪些部分是由 LLM 生成的；“禁止 LLM 生成的评论”这条规则同样适用于你。
发布 LLM 生成代码的作者
如果你向 rust-lang/rust 提交包含 LLM 生成代码的 PR，我编写了一份你应该遵循的指南清单。如果你遵循政策中的这条简单准则，就可以避免思考这些指南，甚至根本不用阅读它们：
使用 LLM 来回答问题、分析、提炼、完善、检查、建议、审核是可以的。但不要用于“创造”。
请参阅政策的“允许”部分，了解其完整含义。请参阅 rustc-dev-guide 获取完整的指南清单。
审核者
一般审核
你可以关闭不符合政策的 PR，无需任何解释。同时，请将作者引导至 #llm-mentoring。具体情形和建议措辞请参阅开发指南。
你没有责任判断一个 PR 是否由 LLM 生成；这个责任在于作者。我们将添加一个 PR 模板，询问作者的代码是否由 LLM 生成，这样这种情况就很少会出现。
如果作者声称他们的代码不是 LLM 生成的，但你仍然不确定，请“私下”向审核团队报告。风格不是证据；请不要指责他人使用了 LLM。报告的目的不是惩罚；审核团队也乐于看到非违规案例。
LLM 代码的审核
如果你自愿审核 LLM PR，以下部分适用于你。没有人被要求必须审核 LLM PR，除非他们自愿。
每个人都应遵守新政策，而不仅仅是作者。这意味着“你有责任”检查 LLM 创建的 PR 是否触及了政策禁止的领域，例如文档、诊断或影响正确性的关键更改。你可以要求作者在不使用 LLM 生成代码的情况下重做，在这种情况下，本节不适用。
开发指南中有你应执行的规则的更详细摘要。官方政策仍然是权威依据。
下一步是什么？
审核者、团队负责人、审核员、委员会代表以及项目内外的其他人员为此付出了大量工作。其中一些工作在政策本身撰写之前几个月就开始了。我要感谢所有直接或间接做出贡献的人。
这并非故事的终结。该政策的目标之一是帮助我们收集数据：人们是否在用 LLM 做有趣且有用的事情？他们是否在学习？他们是否在做出重复贡献？这些问题的答案将帮助我们决定未来如何调整政策。
这不是 Rust 项目团队发布的第一项 LLM 政策，希望也不会是最后一项。虽然当前政策仅适用于 rust-lang/rust 单一代码仓库，但我仍然相信，Rust 将受益于一项项目范围的政策，该政策将规定我们在聊天、论坛、公共沟通、没有明确政策的仓库以及其他跨项目领域中的期望。
评论总结
根据评论内容，总结如下：
主要观点与论据：
支持有限使用LLM（评分：None，作者：andsoitis）
- 核心观点：LLM可用于回答问题、分析、提炼、检查、建议和审查，但不应用于创作。
- 关键引用："It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create."
赞赏反骚扰政策（评分：None，作者：minimaxir、matheusmoreira）
- 核心观点：政策明确禁止因使用LLM而骚扰他人，并强调“不要试图当警察”，这有助于防止猎巫行为。
- 关键引用："Harassment is not allowed. You may not harass people for using an LLM..."（minimaxir）
- "Don’t try to be the police for whether someone has used an LLM."（matheusmoreira）
对政策可执行性的质疑（评分：None，作者：piokoch、weli）
- 核心观点：要求自我披露LLM生成内容难以执行，可能导致猎巫和精英主义，阻碍新人贡献。
- 关键引用："If someone is 'clever' enough to drop em-dashes... how one would know if something is AI generated?"（piokoch）
- "This quickly leads to witch hunting and easy persecution... communities slowly drift towards a group of elitists."（weli）
反对全面禁止LLM（评分：None，作者：lukasco）
- 核心观点：禁止LLM是自我挫败的，未来软件开发将不再手写代码，应聚焦如何让LLM贡献有效工作。
- 关键引用："LLM policies which ban usage are ultimately self-defeating... The era of hand coding is over."
- "I'd focus my policies much more on dealing with the issues that this new era presents."
平衡性说明：
评论呈现了支持有限使用、赞赏反骚扰、质疑可执行性、反对全面禁止等多元观点。支持者强调LLM的辅助角色和反骚扰的重要性；质疑者担忧政策漏洞和社区分化；反对者则认为应拥抱技术变革。整体上，评论对政策持谨慎乐观态度，但执行细节和未来方向存在分歧。