五个 Rust 团队采用 LLM 规则以保护人工代码审查

Why it matters

Rust is confronting the central constraint of AI-assisted software development: models can produce code faster than experienced maintainers can judge, explain and support it.

五个 Rust 团队采纳了由 Jynn Nelson 撰写的 LLM 贡献政策。Nelson 是 Ferrous Systems 的长期 Rust 维护者兼编译器团队负责人，该政策为审阅者在 rust-lang/rust monorepo 中处理 AI 生成的代码和文本提供了明确规则。

Nelson 在 Inside Rust 在 8 月 5 日发布的帖子 中写道，compiler、libraries、types、rustdoc 和 bootstrap 团队及其子团队最近已批准该规则。该政策并不约束整个 Rust 项目。包括 language 和 edition 在内的团队仍可自行制定实践，主 Rust monorepo 之外的仓库也不在其适用范围内。

Nelson 多年来一直在 Rust 中那些技术决策与贡献者治理交汇的领域工作。他们的简历表明他们领导过 rustdoc 和 docs.rs，创立了 Rust 的 bootstrap 团队，招募维护者，并将 rustdoc 的编译时间缩短了九倍。在 2025 年 9 月加入 Ferrous Systems 之前，Nelson 在 YottaDB、TCDI、Redjack 和 Cloudflare 从事编译器、数据库和网络基础设施方面的工作。

那段背景塑造出一个侧重于维护性而非对 AI 作出广泛判断的政策。Nelson 关切的是，生成的输出削弱了开源审阅者曾用来决定投入时间位置的信号。一个看起来很完美的 pull request 可能代表一位有抱负的维护者数天的细致工作，也可能是提交者在合并后无法解释、修改或支持的输出。

Nelson 的治理解决方案

公开公告于 8 月 5 日发布，但该政策是在数月内构建的。Rust Forge 提案 于 4 月 17 日在经过大量私下和公开讨论后开启。讨论记录称，此前在 Rust Zulip 的对话产生了超过 3,000 条消息，不包括随后在 GitHub 上的争论。

Nelson 将这项工作框定为对不一致执法的回应。Rust 的审阅者已经遇到数十个 LLM 辅助的 pull request，其中包括首次贡献者提出的有风险的编译器优化建议。版主们没有统一的披露规则，导致贡献者往往在审阅者关闭其工作后才发现对方的期望。

发布的 LLM 使用政策 为双方提供了书面标准。其工作总结简洁明了：“可以使用 LLM 来回答问题、分析、提炼、改进、检查、建议、审阅。但不能用来创作。”

私人 AI 协助通常被允许。贡献者可以向模型询问有关代码库的问题，为个人使用总结讨论，私下复查自己的工作，或在自己编写解决方案前生成可能的方案。规则还允许贡献者使用 LLM 寻找错误，前提是由人工核实结果并在报告时披露模型的参与。

公开输出则受到更严格的控制。贡献者不得将由 LLM 原创生成的评论、issue 正文、pull request 描述、文档、编译器诊断信息或大量源代码注释作为自己的文字提交。当周围的贡献本身已能成立时，清晰标注的引用是被允许的。机器翻译、琐碎编辑与 AI 辅助的审阅在披露的前提下有条件允许。

这种区分把责任放在贡献者身上。模型可以帮助某人思考、检查或翻译，但人仍需提出论点、理解变更并对审阅者负责。

AI 生成的代码获得一个试验通道

Rust 的规则并未直接禁止生成代码。它们为生成代码创建了一个受控实验，其准入门槛高于普通贡献流程。

LLM 创建的变更必须在打开 pull request 之前与一位愿意的审阅者达成安排。它必须避开对 soundness 至关重要的区域，符合代码库的质量标准，包含测试，并且作者和审阅者都必须理解该变更。新贡献者不能先提交生成的代码再去寻找审阅者。

被接受的提交将获得 ai-assisted 标签，并发布到一个 Rust 组织成员可访问的私人 Zulip 频道。该频道旨在收集证据以判断贡献者是否在学习、是否会带着进一步工作回归，以及是否产生值得维护的变更。审阅者可以拒绝 AI 辅助的 pull request，并且 LLM 的审阅不能替代人工批准或作者本人的审查。

该政策还包含一个数值断路器。如果在滚动六周期间，LLM 创建的更改占所有合并的 pull request 的比例超过 50%，Rust 将暂停进一步的 AI 生成合并，直到该比例降到阈值以下。冷却期至少持续 10 天。

这一限制是刻意保守的，可能在很大程度上只是理论性的。它明确了 Rust 背后的优先事项：不能允许生成的提交占据代码库或使 AI 工具成为参与的实际必要条件。

稀缺资源是审阅者的判断力

Nelson 报告称在公告时 rust-lang/rust 中有 1,281 个打开的 pull request。该数字只是一个快照，但它反映了推动该政策的不对称性。AI 系统可以比开源项目招募有经验人员来评估架构选择、长期维护成本和安全影响的速度更快地增加代码供给。

在编译器中的审阅工作很少仅仅止于定位有缺陷的代码行。维护者必须决定某个提议的方向是否适合进入 Rust、它如何与其他编译器组件交互，以及谁会在几个月后理解这一变更。生成的代码降低了呈现看似可行实现的成本，但并未降低做出那些决策的成本。

该政策还应对了协作中的一个更直接的崩溃：贡献者将审阅意见输入 LLM，然后把模型的回复粘回 GitHub。Nelson 认为审阅者是在要求作者说明其推理。机器生成的回复让维护者无法判断他们是在与真正理解补丁的人合作，还是仅仅在审阅者与模型之间转述信息。

Rust 的回答是将贡献权与人类理解挂钩。该政策并不要求审阅者通过风格来检测 AI 编写的代码，并且警告他们不要基于怀疑作出公开指控。作者必须披露其使用情况。对涉嫌不诚实的处理将通过版主处理，而不是在 pull request 内部争论。

目前的本地折衷

这一狭窄的适用范围反映了 Rust 的决策方式。该项目通过在职责和对 AI 看法各异的团队之间达成共识来运作。Nelson 写道，一些贡献者认为这些工具有实际价值，而另一些人则反对其在技术、社会或环境方面的成本。被采纳的政策基于对专业知识、包容性和审阅者能力的共同关切。

项目范围内的答案仍未确定。7 月 14 日的项目管理更新 表示 Rust 的 Leadership Council 正在讨论一个可以编写和修订更广泛规则的 LLM 委员会。该提案建议由四到五名成员组成，代表项目内不同的意见。

在治理工作推进之前，Nelson 的政策为 Rust 中最繁忙的中央仓库部分提供了一个实用的运行模式。它在为实验保留空间的同时，让提交者承担证明生成工作值得稀缺审阅者关注的成本。随着代码生成变得更便宜而维护工作依然难以自动化，这种权衡很可能在开源界变得越来越常见。