AI写的PR堆成山，Rust已忍无可忍

机器之心编辑部

AI 编程正在把软件开发里最昂贵的一件事迅速变便宜：写代码。然而，Rust 社区却发现，麻烦恰恰由此开始。

数据显示，rust-lang/rust 仓库里积压了 1300 个尚未关闭的 PR。过去，一个结构完整、测试充分、说明详细的 Pull Request，往往意味着背后有人花了不少时间研究代码、理解设计，再认真完成修改。

LLM 普及之后，这套判断标准开始失效。一个人可以很快生成几百行代码，甚至同时提交多个看起来相当完整的 PR。代码产量大幅提高，负责审核这些代码的维护者却没有变多。

开源社区遇到了一个很现实的新问题：代码越来越便宜，人的判断越来越贵。

最近，Rust 项目中的五个团队采纳了一套针对 rust-lang/rust 主仓库的 LLM 使用政策，专门规定大语言模型可以怎样参与 rust-lang/rust 主仓库的贡献。

它没有覆盖整个 Rust 项目，也没有给 AI 编程下一个简单的「允许」或「禁止」结论。政策给出的核心原则很有意思：可以用 LLM 回答问题、分析、提炼、润色、检查、建议和审查；涉及到直接创造内容，则会受到严格限制。

OpenAI 的一位研发人员以自己作为维护者的身份，认同 Rust 的这份新政策，表示「非常周到且合理。」

图源：https://x.com/charliermarsh/status/2085065098616275359

一份漂亮的 PR

已经证明不了你懂代码

Rust 这次专门为 LLM 制定规则，首先碰到的是一个很反直觉的问题：AI 正在让「认真工作留下的痕迹」失去可信度。

维护者看到一份完成度很高的 PR，通常可以推断出几件事：作者投入了时间，对相关代码有一定理解，也可能愿意长期参与这个项目。这些信号会直接影响开源社区的协作方式。此外，维护者通常不愿意轻易关闭一个别人花很多时间完成的 PR。代码审查过程中发现新的问题，双方还可以继续讨论和修改。

LLM 普及后，这些判断越来越难成立。

格式工整、测试齐全、描述详细的 PR，几分钟或者几十分钟就可以生成。代码看起来专业，作者未必理解其中的设计。如果背后运行的是自主 Coding Agent，甚至可能连一个真正参与思考的人都不存在。

Rust 团队尤其担心一种情况：开发者收到 Review 意见后，直接把审核者的话复制给 LLM，再把 LLM 的回复原封不动贴回 GitHub。

政策起草者对此说得很直接。

维护者如果想知道 LLM 怎么回答，完全可以自己去问。代码审查真正需要的是贡献者自己的判断：你为什么这么改？有没有考虑其他实现？未来代码结构发生变化怎么办？

这些问题很难靠一段「看起来正确」的生成文本解决。这也解释了 Rust 为什么一直强调一个词：理解。

一段代码能够运行，只说明它目前完成了某项功能。大型基础软件还需要考虑 API 设计、兼容性、安全边界、后续维护以及它与其他模块的长期关系。

Rust 没有封禁 AI

但 AI 代码要过更高的门槛

这份政策比「Rust 禁止 AI 写代码」复杂得多。

LLM 仍然可以大量参与开发。你可以让它回答技术问题，可以用它分析 RFC，可以检查代码，可以帮助总结信息，也可以让它参与 Review。个人私下使用 LLM，只要生成内容没有直接提交给社区审核，通常也无需披露。

一些过去已经存在的实际用途也被保留下来。例如开发者可以用 LLM 辅助翻译，让非英语母语贡献者用自己的语言起草内容；可以借助模型寻找编译器诊断不合理的地方；也可以分析 RFC，检查设计讨论有没有漏掉语言系统中的其他影响因素。

Rust 对 AI 的态度并不排斥。真正严格的是直接进入项目的生成内容。

公开提交 LLM 生成的内容，需要明确披露来源。利用模型发现 Bug、完成机器翻译、进行部分简单修改，或者借助 LLM Review 他人的工作，都有对应的披露要求。

涉及 AI 直接生成代码，限制更加严格。

Rust 给出的条件包括：AI 生成代码只有在事先安排、非关键、高质量、测试充分并经过充分审查的情况下，才能在披露 LLM 使用的前提下被允许。

尤其值得注意的一条是：

AI 生成的代码，需要达到比普通人类代码更高的门槛。

对涉及 Rust soundness（健全性）的关键改动，限制更加严格：除非作者本人已经是相关领域专家，否则不能由 LLM 生成；即使作者具备专业能力，政策仍然强烈不建议这么做。

Review 端同样获得了更多主动权。

维护者没有义务审核 AI 生成的 PR。如果一个提交违反政策，Reviewer 可以直接关闭，并要求作者按照规则重新处理。

与此同时，Rust 也专门防止另一种问题出现：不能因为代码「看起来很像 AI」就公开指责作者。

政策明确提出，代码风格本身不能构成使用 LLM 的证据。如果 Reviewer 怀疑作者隐瞒 AI 使用情况，可以私下交给 Moderation 团队处理。

这套机制实际上把责任划得很清楚：作者负责披露，维护者负责判断代码是否值得进入项目。

Rust 并不试图检测每一次偷偷使用 AI 的行为。它更看重一条容易执行的边界：只要公开提交了 LLM 生成内容，就应该明确说明。

AI 编程的下一个瓶颈

可能已经不是生成代码

这套政策真正值得关注的地方，其实已经超出了 Rust。

过去两年，AI 编程产品竞争的重点几乎都放在「写得更快」上。模型一次生成完整功能，Agent 连续工作几个小时，跨越大型代码库修改几十个文件，自主运行测试、修复错误再重新提交结果。这些能力还在快速提高。

但同时，一个新的工程约束正在浮出水面：

AI 可以扩大代码产能，却没有同步扩大人类的审核产能。

一个 Coding Agent 可以同时启动十个任务，一个资深 Maintainer 很难同时认真审十个复杂 PR。生成成本越低，这个问题越明显。

尤其对于 Rust 这样的基础软件项目，一次修改影响的可能是编译器、标准库、诊断系统、安全边界以及未来多年的兼容性。真正耗费时间的环节，经常不是把代码敲出来，而是决定这项修改值不值得做、设计是否合理、会不会给未来留下技术债。

Rust 政策原文里有一句很关键的话：Review 本质上由一连串决策组成。

这句话点中了 AI 编程接下来很可能面对的产业问题。

代码生成模型已经能够显著压缩实现的成本，软件工程里那些更难规模化的部分随之暴露出来：需求判断、架构选择、代码审查、责任确认以及长期维护。AI Agent 越强，治理这一层的重要性反而越高。

未来衡量一套 Coding Agent 系统，也不能只看它一天生成多少代码、完成多少 Issue。一个更现实的问题会变成：它最终给人类增加了多少审核负担？

假设 Agent 一天能够生成 20 个 PR，而资深工程师需要更长时间逐一确认设计与实现，代码生成速度的提升就未必能够等比例转化为整个项目的研发吞吐量。

能够自动测试、提供修改依据、解释关键设计决策、控制任务范围、主动降低 Reviewer 的认知负担，可能会成为下一阶段 Coding Agent 更重要的能力。

这也是 Rust 这份政策最有意思的地方。

它没有试图阻止 AI 进入软件开发。相反，它提前碰到了 AI 编程规模化之后必然出现的一道题：机器开始无限生产代码之后，人类究竟还需要负责什么？

Rust 给出的答案很明确。代码可以让模型帮忙写，理解、判断和责任，暂时还不能外包。

原文链接：https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/