Rust 采用正式的 LLM 政策用于其主仓库

五个 Rust 项目团队已采用了一项 正式政策，该政策规定了如何在为 rust-lang/rust 贡献时使用大型语言模型，Jynn Nelson ，该政策的作者，在 Inside Rust 博客 上宣布了这一消息。该政策（由编译器、libs、types、rustdoc 和 bootstrap 团队批准）取代了 Nelson 所描述的“狂野西部”式的无正式政策的管理方式，采用了一套公开的书面规则。

该政策并非对 AI 的项目范围内的立场，而是明确指出它仅适用于 rust-lang/rust 仓库和批准它的团队。在此范围内，它明确划出了一条界限：LLM 可以作为工具用于思考，而不是作为思考的替代品。

该政策实际上说了什么

该文件用一句话总结了自己：

> 使用 LLM 来回答问题、分析、提炼、改进、检查、建议、审查是可以的。但不能用于 创建。

在实践中，这产生了三个层次。被允许的：任何私人使用，其中贡献者是唯一看到输出的人 —— 询问关于代码库的问题、总结一个线程、审查自己的代码。需要强制披露的：机器翻译、更改琐碎的错误、LLM 辅助的 bug 发现和 LLM 审查机器人，这些必须从单独的、明确标记的 GitHub 账户运行，个人用户可以阻止这些账户。被禁止的：LLM 创建的评论、文档和编译器诊断；任何需要 LLM 执行的过程；以及将 LLM 审查视为合并或拒绝更改的充分条件。

最严厉的规定在于执行设计。故意歪曲 LLM 使用情况被视为违反项目的行为准则 —— 与骚扰同等级别 —— 会受到警告，并且对于反复违规者会被禁止。文件明确指出，其许多条款在实践中无法执行，这是故意的：“我们的目标不是捕捉每个违规行为……相反，我们的目标是去除合理的否认可能性：强迫选择在遵守政策和故意违反政策之间。”

LLM 编写代码的有界实验

LLM 编写的代码并未被完全禁止。它被限制在一个有严格入场条件的实验中：更改必须预先安排一个指定的审查员，非关键的编译器的健全性，经过良好的测试和审查，并且需要在每种情况下披露。新贡献者不能在没有预先安排审查员的情况下打开一个 LLM 创建的拉取请求。如果没有测试套件用于所触及的代码，作者必须编写一个或关闭 PR。没有例外。

该实验带有自己的电路断路器。如果在六周窗口内合并的 PR 中有超过一半是 LLM 创建的，则停止合并 LLM 创建的 PR，直到比例低于 50%，至少需要 10 天的冷却期。窗口与 Rust 的六周发布周期对齐。所有此类 PR 都带有一个新的 ai-assisted 标签，并发布到一个私有的 Zulip 频道，其目的是收集数据（是否 LLM 辅助的贡献者正在学习、返回并产生有用的工作），而不是守门人。

为什么现在

Nelson 的公告描述了三个推动团队从非正式管理到书面规则的压力。经过润色的拉取请求不再表明努力或理解，这会侵蚀项目审查文化所依赖的信任信号。代码生成的成本降低加剧了现有的审查带宽短缺：仓库目前有 1,281 个打开的 PR，而稀缺的资源一直是审查者的判断力，而不是代码。那些对审查评论做出回应的人通过将其粘贴到 LLM 中并将输出粘贴回去，正在浪费每个人的时间，并打破了审查者正在与一个人交谈的假设。

背景是项目内部的真正分歧。该政策的自身动机部分指出，Rust 内部没有共识，“可能永远不会有”，关于何时可以接受基于 AI 的工具，成员从每日用户到认为任何使用都是不可接受的人都有。因此，该文件的设计是可以更改的：需要每个批准团队的批准才能进行重大修订，该政策可以被这些团队或领导委员会目前正在考虑的项目范围内的 LLM 委员会完全废除。

细则

范围比标题所暗示的要窄。该政策不适用于 rust-lang 组织中的其他仓库、语言团队的工作（例如跟踪问题和稳定性报告）、风格指南或未批准该政策的团队。每个团队可以自行制定自己的规则。rust-lang 组织的成员免于遵守“非关键”LLM 代码的限制，尽管该政策表示它强烈反对使用这种豁免，且在政策生效之前编写的 PR 也是豁免的。骚扰贡献者使用 LLM 本身就是禁止的，无论使用是否违反了该政策。

接下来会发生什么

私人 Zulip 频道一旦 ai-assisted 标签可用，就开始收集有关 LLM 创建的 PR 的数据，而第一个六周的电路断路器窗口将告诉团队该实验是否会让合并队列不堪重负。领导委员会提出的关于专用 LLM 委员会的提议如果成立，将优先于该政策，并可能将规则扩展到项目范围内，涵盖目前没有政策的聊天、论坛和仓库。Nelson 的帖子认为这正是预期的结果，将该政策框定为第一步，而不是最终答案。