背景:1,281 个 PR 的审稿压力,催生第一个旗舰开源项目的 LLM 边界规则

Rust 语言团队在 Inside Rust 博客正式宣布,rust-lang/rust 主仓库启用 LLM 政策,作者 Jynn Nelson,五个团队一致通过。这是头部系统级编程语言项目第一次把「LLM 能在贡献里做什么、不能做什么」写到官方规则里。政策在 https://forge.rust-lang.org/policies/llm-usage.html 公开,8 月 5 日上线。

政策的直接动因,是仓库目前的真实状态:截至发文时,rust-lang/rust 有 1,281 个 open PR。Nelson 在博文中把这个数字直接摆出来,并写道:长期以来,「想写代码的人」就远多于「愿意审稿的人」,LLM 让这件事进一步恶化。

政策核心:可以回答、提炼、校验,不能用来「创造」

Nelson 把政策浓缩成一句话:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

按此划分,政策对两类用法做了区分:

第一类,允许(部分需要披露):

  • 用 LLM 回答问题、分析代码、提炼思路、完善文稿、校验结果、提建议、做 review
  • 用 LLM 做机器翻译,把母语 issue 转成英文
  • 「trival」改动、发现 bug、协助审稿他人 PR —— 这些必须标注 LLM 参与

第二类,重限制(预约定 + 非关键路径 + 充分测试 + 必须披露):

  • LLM 原生产出的代码改动,必须在事前与维护者约定,且仅限「非关键」区域
  • LLM 产出的 PR 一律必须有测试,无论难度
  • 不允许 LLM 生成 soundness-critical 的改动,除非作者已经是该领域专家(且即使如此也「strongly discouraged」)
  • 在公开文档、PR 描述、GitHub 评论里出现的 LLM 文本必须明确标注

三条 Nelson 明确写出的「为什么」

Nelson 在 Inside Rust 博文中给了三条政策出台的直接理由:

  1. 「打磨过的技术产出,不再等于作者的投入和理解」:过去一个打磨充分的 PR 通常意味着作者花了大量时间,这影响 Rust 的协作文化——团队倾向于不直接关闭 PR、PR 过程中允许根据新事实调整设计、把 PR 视作新人进入社区的入口。LLM 让这些信号都失效了。
  2. 「代码变得好写,审稿压力反而更重」:大部分审稿工作不是抓 bug,而是在判断「这个方向是不是好方向、这件事值不值得做」。一旦 PR 可以用 LLM 短时间「撒」出来,reviewer 的判断成本反而被放大。
  3. 「机械复制 LLM 输出,浪费所有人的时间」:Nelson 直接写了一段比较尖锐的话——「如果我们想要 LLM 的意见,我们自己会问。我们想听到的是你,不是机器。」

治理细节:不抓每一条违规,只划清晰的红线

Nelson 也在博文中明确:政策的「goal is not to catch every violation」,政策本身有不可强制执行的部分,这是有意的设计——目标是建立一条清晰的披露红线,让 moderator 可以基于「行为」而不是「意图」识别违规,只有到了处分阶段才考虑意图。

具体到执行:

  • Reviewer 可以无解释地关闭违反政策的 PR,但需要把作者指向 #llm-mentoring 频道
  • Reviewer 不需要判断一段 PR 是不是 LLM 生成的——判断责任在作者。新加的 PR 模板会问作者代码是否由 LLM 生成
  • Reviewer 如果「不确定」某段 PR 是否 LLM 生成,可以私下向 moderator 报告,但「不能」基于行文风格直接指控别人用了 LLM

背景对比:头部项目的两种极端

Nelson 在博文中没有回避 Rust 的治理现实:Rust 不是 benevolent dictator 项目,不能在「全面禁止」和「鼓励使用」中二选一。所以政策没写「禁止 LLM 生成任何内容」,也没写「LLM 只是工具,和其他工具一样」——前者是 Zig 官方 code of conduct 的措辞,后者是 Linux 内核邮件列表上 Greg Kroah-Hartman 曾经给出的回应。

Rust 的选择是把规则写下来,把争议公开,把修改条款(便于日后根据数据调整)放在政策最后。

评论视角:为什么这条新闻对 LLM 圈是大事

这是头部开源基础设施项目第一次用「成文政策」的形式处理 LLM 贡献问题,与之前零散的「我们不收 LLM PR」或「AI just is a tool」式声明相比:

  • 它把 LLM 写进治理,而非靠 moderator 个体判断
  • 它要求「披露」而不是「禁止」,留下了 LLM 辅助贡献的合法空间
  • 它给了 LLM 写代码一个「更高」而不是「更低」的门槛(必须有测试),这对模型评测和开发者使用习惯会形成反向压力
  • 政策的「创造 vs 分析」二分,会变成后续其它项目(尤其是大型 monorepo)的可参考模板

更长远看,这是「LLM 写代码」从「个人生产力工具」走向「需要被项目治理的基础设施」的一个清晰信号。

来源