探索 AI 前沿：Rust 编译器的 LLM 政策

将大语言模型 (LLMs) 集成到软件开发生命周期中，为关键开源基础设施的维护者们带来了一个悖论。虽然 AI 可以加速编码，但它往往将验证的负担从作者转移到了审查者身上。Rust 编译器团队正在通过提议的 LLM 政策正面应对这一问题，这在开发者社区内引发了关于速度与正确性之间平衡的重要辩论。

Rust LLM 政策的核心

该提议的政策托管在 Rust Forge 中，被设计为一个动态文档而非静态的 RFC。其核心在于，该政策建立了一个明确的界限：LLM 的使用者应对其提交的输出内容负全部责任。

这些指南基本上可以归纳为几个关键原则：

  • 问责制： 如果使用 LLM 生成代码或注释，人类提交者应对其正确性和质量负责。
  • 披露： 要求贡献者在创建 PR 或错误报告时，披露是否使用了 LLM。
  • 质量控制： 低质量的 PR——通常以“AI slop”（幻觉逻辑或通用、非上下文相关的注释）为特征——将被拒绝。

一些贡献者认为这只是“常规标准”，并指出这仅仅是将“作者在提交到具有高稳定性要求的项目之前必须审核自己的工作”这一预期正式化。

维护者的负担：为何政策是必要的

社区讨论中一个反复出现的主题是“验证责任”。传统上，维护者可以依赖一种社会契约：如果一个受信任的贡献者提交了 PR，审查过程可以侧重于架构契合度及边缘情况，而不是基础的正确性。

随着 LLM 使得提交包含微妙幻觉的复杂、功能丰富的 PR 成为可能，这种信任正在被侵蚀。一位评论者指出维护者负担的增加：

"在现在的 PR 中，仓库维护者必须做更多的工作，因为他们无法再依赖‘OptionOfT 写了这些……所以我们可以从那个角度来看待 PR’这种社会契约。…… 这现在增加了 PR 作者的工作量，如上所述。我们需要进行验证，而不能依赖社会契约。"

对于像 Rust 编译器这样“承载着全球经济”的项目来说，错误的代价是天文数字。保持代码库的严密性比追求快速、由 AI 驱动的功能扩张更重要。

社区摩擦与批评

尽管该文档经过了深思熟虑，但该政策并非没有批评者。一些人认为指南过于指令化，甚至带有“保姆式”色彩，特别是在关于是否允许使用 LLM 来总结注释或询问有关代码库的问题方面。

批评者认为这些权限在实践中是无法验证的。正如一位用户指出的：

"如果有人稍后承认他们是用 LLM 发现的 bug，他们会回过头去拒绝这个 bug 吗？"

其他人持有更激进的观点，暗示 Rust 团队是在出于一种“卢德分子”式的恐惧，担心被取代。一些人推测，如果主仓库保持过于严格的限制，可能会出现“支持 LLM 的 fork”，利用 AI agent 来审查 PR，并可能在开发速度上超越主项目的规模。

AI 治理的替代方案

讨论强调了项目处理 AI 生成内容涌入的几种替代方式：

  1. 担保系统： 一些人建议实施类似 vouch 的系统，即贡献者在与项目的敏感部分进行交互之前，必须由受信任的成员担保。
  2. 严格的“AI slop”过滤器： 一些项目已经在采用激进的政策，立即关闭并封禁提交明显 AI 生成噪声的用户。
  3. 基于规范的演进： 一部分社区成员认为项目应该忽略这种情况，让社会规范有机地发展，而不是试图将其编纂成政策。

结论：追求更好，而非更快

Rust 编译器的做法反映了“追求更好，而非更快”的哲学。通过坚持人类问责制和披露要求，该项目旨在保护其维护者免受 AI 生成贡献的噪声干扰，同时确保语言能够继续安全地演进。该政策是否会达成完全共识——或者它是否会成为项目成员之间的争论点——尚待观察，但它为关键基础设施项目如何管理向 AI 时代的转型设定了一个至关重要的先例。

Sources