最近，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 做贡献。一些使用方式尊重了我们的社区：将信息翻译成英语，以便人们能用本地语言撰写；查找新贡献者可能撰写的代码片段的较差诊断；分析 RFC，以查看是否缺少对可能影响设计的语言其他部分的讨论。有些用法有时不小心地没有做到这一点。我看到 LLM 为我们社区带来了三个主要问题：精致的技术产品不再表示努力和理解。简化代码编写加剧了我们现有的审查带宽问题。人们机械地从 LLM 复制粘贴代码浪费了我们的时间。随着时间的推移，这些问题不断扩大，直到我们不得不创建专门的渠道和管理政策来处理这些问题。然而，这些渠道与我们透明和欢迎的目标相悖，因为新的贡献者不知道规则是什么。新政策公开地规范了这些规则，以便新贡献者知道如何加入我们的社区，而不必因为不理解的原因关闭他们的 PR，以便现有的审查者可以轻松地将规则作为关闭不遵循这些规则的 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 的意见，我们本可以自己询问。我们想要听到的是...