「不要用机器来创造」
2026 年 8 月 5 日，Rust 核心团队在 Inside Rust Blog 正式发布 LLM 使用政策，由 Jynn Nelson 起草并获得五个团队一致通过。该文件明确规定：开发者可以使用 LLM 来回答问题、分析代码、提炼逻辑与检查错误，但禁止直接生成原创贡献内容。这是主流开源项目首次针对大语言模型划定明确治理红线，将 AI 工具的使用界限正式写入管理规范。
图：Rust 官方 Logo。来源：blog.rust-lang.org
新规目前仅适用于 rust-lang/rust 主仓库，并不代表整个生态或项目官方对 AI 的立场。虽然规范适用范围有限，但在社区引发了热烈讨论，Lobsters 平台相关议题迅速登上榜首并积累了大量讨论。社区关注的焦点集中在政策落地时的可操作性，以及规则对日常代码提交的深远影响。
信号失真：测试齐全不再证明理解
过去在开源协作体系中，包含完善测试与精细格式的代码变更，通常意味着贡献者投入了充沛的时间与深入的理解。LLM 的普及打破了这一既有经验，光鲜的代码提交可能源自大模型在数秒内的快速吐字，作者自身甚至未能完全消化变动细节。极端情况下，代码提交端背后甚至没有人类参与，完全由自动化代理独立发起。
这种变化直接摧毁了开源项目长期依赖的贡献者筛选机制。以往的高质量 PR 往往预示着作者愿意长期参与社区维护，现在它仅仅代表提示词工程的调用成果。当技术成品的产出成本被无限拉低，开源协作赖以建立信任的努力信号随之全面失效。
1281个积压PR背后的审查带宽危机
政策发布时，rust-lang/rust 仓库中积压了 1,281 个待处理的代码合并请求，展现出严峻的资源失衡。愿意生成代码的人数呈爆发式增长，然而具备审查资格与专业精力的维护者数量始终有限。代码审查的大部分精力集中在评估设计的方向性与架构契合度，而非单纯查找语法缺陷。
图：Ferris 吉祥物在 38c3 Rust 集会现场照片。来源：Wikimedia Commons
部分贡献者将审查意见直接复制给 LLM，再将机械生成的回复粘贴回 GitHub 讨论区，这种漫无目的的提交流程极大加重了审查者的认知负担。正如政策起草人在文中强调的，如果维护者需要机器的意见，他们大可自行询问大模型。社区更需要听到人类自身的工程思考，缺乏思考的交互正在迅速消耗维护者与贡献者之间的信任纽带。
明确划线与放弃全盘控制
新规实施后，所有在公开文档、代码描述或评论区出现的 LLM 内容均须进行明确标注，审查者拥有无理由关闭未合规提交的权利。针对涉及 soundness-critical（健全性关键）的编译器底座优化，政策严厉限制未经专家把关的 AI 原创变动。即便作者已是相关领域专家，官方依然明确表态不推荐在核心逻辑中引入大模型生成的代码。
Rust 项目依托共识治理，内部对 AI 工具的接受度存在明显分歧。部分成员看重大模型带来的效率提升，部分成员则对技术背后的资源开销与社会影响持谨慎态度。政策选择建立清晰的明线规则而非全盘禁绝，避免了陷入抽象的价值观争论，集中力量解决具体的协作秩序问题。
重新建立人类专家的筛选机制
政策起草团队承认规则在技术上难以百分之百精准执行，但其初衷在于树立行事标准并收集社区真实的使用数据。为避免治理流程沦为漫长的行政拉锯，官方考虑成立专门的子团队集中处理相关争议。通过记录开发者在披露前提下的使用习惯，项目组希望探索出可持续的辅助开发路径。
Rust 团队的治理尝试预示着开源社区管理模式的深刻转向。在自动化工具爆发的当下，真正稀缺的资产不再是代码本身的数量，而是维护者宝贵的注意力与专业研判力。开源项目的核心竞争力在于人类专家构筑的深度信任，这一根基绝非大模型的代码吞吐量所能替代。
参考链接：
- Inside Rust Blog 官方政策声明
- Rust Forge LLM 使用规范全文
- Lobsters 社区关于 Rust LLM 政策的讨论
