Rust 给 LLM 贡献划出边界：可以辅助，但不能替你负责

Rust 的新规则看起来像一句口号：LLM 可以回答、分析、提炼、检查和建议，但不要让它替你“创造”贡献。 真正值得注意的不是它对 AI 说了“不”，而是它把一个长期被忽略的成本摆到了台面上——代码生成越来越便宜，人工审核却没有一起变便宜。

8 月 5 日，Inside Rust Blog 说明，rust-lang/rust 单仓库内已有五个团队采纳一套 LLM 使用政策。政策覆盖用 LLM 生成代码的 PR 作者、问题报告者、审核者，以及把模型输出直接放进 issue、PR 描述或 GitHub 评论的人。它不是整个 Rust 项目对 LLM 的统一立场，也不适用于所有仓库；范围只限于已批准该政策的相关团队和子团队。原文与完整政策可见：Inside Rust Blog 与 Rust Forge。

政策针对的不是工具，而是“审核负债”

作者 Jynn Nelson 给出的背景很具体。写作时，rust-lang/rust 有 1,281 个未关闭 PR。项目本来就长期面临“想写代码的人多、愿意审核的人少”的问题；LLM 又把生成一份表面完整、测试齐全、措辞专业的 PR 变得更容易，却没有解决方向判断、长期维护和作者是否真正理解代码的问题。

政策因此区分了私人辅助和公开贡献。只给自己看的模型输出通常可以使用，例如询问代码库、总结讨论、私下审查代码，或先从模型提出的方案中学习，再用自己的方式完成工作。但公开提交的 LLM 文本必须披露；由模型起草的 PR 描述、GitHub 评论、公共文档、诊断信息，以及让 LLM 审核代替人工判断，都被禁止。机器翻译、简单改动、缺陷发现和审核机器人可以在附带条件下使用，但需要披露。

这套规则最锋利的一点是：作者不能把阅读模型输出的成本强加给其他人。 审核者可以拒绝查看 LLM 生成的 PR；模型审核只能提供建议，不能成为合并或拒绝的充分条件；作者仍然必须自审，并对提交承担责任。

生成代码没有被一刀切，但门槛更高

Rust 保留了一条实验通道。LLM 原始生成的代码变更可以进入评审，但需要同时满足几项条件：事先找到愿意审核的项目成员、变更不涉及高风险关键区域、代码质量合格、测试充分、作者与审核者都能解释和理解变更，并明确披露模型参与。相关 PR 还要添加 ai-assisted 标签。

对测试的要求也比普通贡献更严。政策写明，如果相关代码没有现成测试体系，作者需要补测试，否则应关闭 PR；“测试很难写”不是例外。涉及健全性、公共文档、诊断文本等区域，则要求人类自己编写。Rust 编译器开发指南还要求作者自己写 PR 描述、评论、提交信息和 LLM 使用说明，并在发起 PR 前重新阅读完整 diff，而不是只看与 Agent 的对话记录。

政策还设置了一个流量阀：如果六周窗口内，合并的 PR 中超过一半由 LLM 创建，就暂停合并新的 LLM PR，直到比例重新低于 50%，且至少冷却十天。这不是对模型能力的 benchmark，而是对社区审核容量的保护。

我的判断：AI 编程的瓶颈正在从“能不能写”转向“谁来负责”

Rust 没有把 LLM 当成单纯的生产力插件，也没有采取全面禁用。它把问题拆成三件更可执行的事：谁看到了模型输出、谁做了关键判断、出了问题由谁解释。这个框架比争论“AI 写的代码算不算代码”更接近真实协作。

对大型开源项目来说，代码只是贡献的一部分。方向选择、证据、测试、解释和后续维护，才是审核者真正付出的时间。模型可以让提交数量上升，却也可能把理解成本转移给少数维护者。Rust 的回答是：允许工具提高质量，但不允许工具稀释责任。

当生成速度不再稀缺，真正稀缺的就不是代码，而是愿意为代码签字的人。