代码越来越便宜，人的判断越来越贵：Rust 社区被 AI 写的 PR「堆成山」，1300个未关闭的 PR 治不了

Updated 08/08/2026 1 min read

AI飞行客

Rust 社区最近干了件值得整个软件工程行业记笔记的事——它不是发布了新版本，也不是吵了哪个语法糖，而是给 rust-lang/rust 主仓库定了一份 LLM 使用政策。

别小看这么个文档。它碰上的问题，是所有重度使用 AI 编程的团队早晚要撞的墙：AI 写代码太容易了，但 AI 写的代码该不该合，这件事没变容易。

数据显示，rust-lang/rust 仓库里积压了 1300 个尚未关闭的 PR。这不是因为 Rust 维护者懒。遍地跑路的 AI Coding Agent 正在把开源项目变成代码的垃圾场——什么垃圾呢？格式工整、测试齐全、看着很专业的垃圾。

在过去，看到一份结构完整、测试充分、描述详细的 PR，维护者可以合理推断：这个作者花了不少时间，对代码有理解，可能愿意长期参与。这些信号直接决定了开源社区的协作方式——维护者通常不愿意轻易关闭一个别人花很多时间做的 PR。

LLM 普及后，这套判断标准全废了。

一个人可以同时提交多个看起来相当完整的 PR，几分钟或几十分钟生成一段「完美」的代码。如果背后跑的是自主 Coding Agent，甚至可能连一个真正参与思考的人都不存在。

Rust 团队尤其担心一种让他们头大的场景：开发者收到 review 意见后，直接把审核者的话复制给 LLM，再把 LLM 的回复原封不动贴回 GitHub。政策起草者说得很直接——维护者如果想知道 LLM 怎么回答，完全可以自己去问。

代码审查真正需要的是贡献者自己的判断：你为什么这么改？有没有考虑其他实现？未来代码结构发生变化怎么办？

这正是 AI 编程最讽刺的反转——代码越来越便宜了，人的判断却越来越贵。

搞清一点：Rust 这次没搞非黑即白。政策远比「Rust 禁止 AI 写代码」复杂。

你可以让 LLM 回答问题、分析 RFC、检查代码、参与 review。个人私下使用 LLM，只要生成内容没有直接提交给社区审核，通常也不需要披露。一些实际用途也被保留下来——比如用 LLM 辅助翻译，让非英语母语贡献者用自己的语言起草内容。

真正严格的是直接提交给项目的生成内容。

公开提交 LLM 生成的内容，必须明确披露来源。涉及 AI 直接生成代码的限制更加严格——只有在事先安排、非关键、高质量、测试充分并经过充分审查的情况下，才能在披露 LLM 使用的前提下被允许。

最值得注意的一条：AI 生成的代码，需要达到比普通人类代码更高的门槛。

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

Review 端也获得了更多主动权：维护者没有义务审核 AI 生成的 PR。如果一个提交违反政策，Reviewer 可以直接关闭，并要求作者按照规则重新处理。

同时 Rust 也防了一手反向歧视——不能因为代码「看起来很像 AI」就公开指责作者。代码风格本身不能构成使用 LLM 的证据。如果 Reviewer 怀疑作者隐瞒 AI 使用情况，可以私下交给 Moderation 团队处理。

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

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

但同时，一个新的工程约束正在浮出水面：AI 可以扩大代码产能，却没有同步扩大人类的审核产能。

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

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

政策原文有一句点题的话：Review 本质上由一连串决策组成。

这句话戳中了 AI 编程接下来真正的产业瓶颈。代码生成模型已经能够显著压缩实现的成本，软件工程里那些更难规模化的部分随之暴露出来：需求判断、架构选择、代码审查、责任确认、长期维护。

AI Agent 越强，治理这一层的重要性反而越高。

现在看一个 Coding Agent，大家问的还是「一天能生成多少代码」或者「能完成多少个 Issue」。

未来，一个更现实的问题应该是：它最终给人类增加了多少审核负担？

假设 Agent 一天生成 20 个 PR，而资深工程师需要更长时间逐一确认设计与实现，代码生成速度的提升就未必能够等比例转化为整个项目的研发吞吐量。更糟糕的情况是，审核瓶颈反过来会削弱 Agent 自身的效率——产品经理的 PR 排着队，你生得再多也没用。

所以下一阶段 Coding Agent 真正重要的能力，可能不再是「写得更快」，而是：自动测试、提供修改依据、解释关键设计决策、控制任务范围、主动降低 Reviewer 的认知负担。

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

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

OpenAI 的一位研发人员在看到 Rust 的这份政策后，以自己作为维护者的身份评论说「非常周到且合理」。连造 LLM 的人都觉得合理，这块铁板有多硬，应该不用再解释了吧。

别被 AI 写代码的效率迷了眼。代码写再多，没人审、没人理解、没人负责，它就是技术债务的另一种形态。 Rust 社区已经把这面旗插下了——你可以跑，但想合进来？先过人的那一关。