Rust的LLM政策草案划出了正确边界

2026年4月17日，一个Rust Forge拉取请求提出了面向rust-lang/rust的LLM使用政策。截至2026年5月17日，该拉取请求仍处于开放状态，包含65条议题评论和284条审查评论，因此这项提案尚未成为已采纳的正式政策。¹

这份草案现在仍然重要，因为它点明了大多数AI编程指南回避的边界：LLM可以帮助人思考、学习、检查和实验，但在项目需要保留判断、品味、责任归属和共同理解的地方，它不应取代人的作者身份。²

这项提案也符合Rust现有的贡献规范。当前Rust Forge贡献指南已经要求贡献者建立信任、尊重审查者时间、提交自己完全理解的工作、在提交前仔细检查，并保持评论简洁。³编译器审查政策也说明，审查者需要对被审查代码有充分理解，而审查时间是有限的。⁴这份LLM草案把这些既有期望具体落实到AI辅助工作中。

摘要

Rust草案允许私下使用LLM进行学习、总结、私下审查、个人工具开发和实验。²它禁止由LLM生成的公开评论、议题正文、拉取请求描述、文档、编译器诊断信息，以及任何把LLM审查视为足以合并或拒绝代码的流程。²它为LLM创建的代码变更设置了一个狭窄实验空间：必须受邀、非关键、已披露、高质量、测试充分，并且作者和审查者都完全理解。²我的判断是：这项政策之所以成立，是因为它优化的是智识责任归属，而不是产出数量。

要点

• 对维护者而言：政策在谈生产力之前，应先保护审查能力、项目语气和责任归属。
• 对AI编程团队而言：私下使用可以广泛允许，但在公开作者身份、文档、诊断信息和合并权限上应划出更硬的边界。
• 对贡献者而言：披露只有在人类仍然承担作品责任时才有意义。“模型写的”不能成为借口。
• 对工具构建者而言：审查机器人需要独立身份、可屏蔽能力、较低的误报压力，以及建议性地位。
• 对代理团队而言：草案中最好的规则是文化性的，而不是技术性的：使用AI是为了写得更好，而不是更快。²

草案区分了思考与作者身份

大多数LLM政策把两件不同的事合并成一个类别：使用AI。Rust草案则把这一行为拆分为私下认知和公开作者身份。

私下认知获得了较宽的许可。贡献者可以向LLM询问代码库相关问题，可以为了自己的理解总结评论，可以私下审查自己的代码或文字，可以构建个人开发工具，也可以生成可能的解决方案，从中学习后再写出自己的方案。²

公开作者身份则被严格限制。草案禁止个人账户发布最初由LLM创建的评论。同一规则也适用于议题正文和拉取请求描述。²草案还禁止最初由LLM创建的文档，包括非平凡的源代码评论、文档注释、安全评论、多段评论和编译器诊断信息。²

这种区分是正确的，因为公开产物承载着项目语气。编译器诊断信息、安全评论和文档并不只是传递信息。它们还在教用户Rust如何思考。它们也会成为项目长期维护负担的一部分。

LLM生成的文字可能看起来流畅，却会削弱这种责任结构。审查者现在必须追问：是谁选择了这种表述？谁理解其中含义？谁负责这个边界情况？以后出现困惑时谁来修复？草案拒绝让贡献者一边外包这些责任，一边保留人类账户的可信度。

最强规则：AI审查不能拥有合并权限

草案禁止把LLM审查视为合并或拒绝变更的充分条件。²审查机器人可以存在，但草案要求它们保持建议性地位。审查者必须明确认可某条LLM评论后，才能据此阻塞拉取请求；作者也仍然负有自我审查义务。²

这条规则避开了一种很有诱惑力的失败模式。团队可以添加AI审查，然后宣称工作流更安全，即使新工具只是制造了第二条没人有时间评估的断言流。机器人可以发现真实缺陷。机器人也可能提出无关紧要的反对意见、过时的风格建议、幻觉出来的约束，或者对自己并未理解的代码发表自信评论。

Rust草案用结构化方式处理了这个问题：

重点并不是LLM审查毫无价值。重点是，审查权限属于人和项目流程。机器可以辅助审查者，但不能成为记录在案的审查者。

代码例外被刻意收窄

草案并未禁止所有LLM创建的代码。它为满足5项条件的代码变更设置了实验空间：受邀、非关键、高质量、测试充分、审查充分。²

每个词都承担了实际作用。

受邀意味着审查者事先同意审查由LLM创建的拉取请求。新贡献者不能直接通过这条路径使用LLM，除非他们先与分配给该拉取请求的同一位审查者沟通。²

非关键让AI创建的变更远离那些一旦出错就可能造成健全性回归的区域。草案认为内部工具更可能适合，而trait系统、MIR构建或查询系统等区域大概率不适合。²

高质量意味着代码至少必须达到其他变更的同等标准。草案明确拒绝会降低代码库质量的拉取请求。²

测试充分提高了门槛。由于LLM让编写测试变得更容易，由LLM创建的拉取请求面临更高的测试期望。如果没有现有测试套件覆盖相关代码，作者必须编写新的测试套件，或者关闭该拉取请求。²

审查充分意味着作者和审查者都承诺完全理解代码。项目成员的审查不能替代自我审查。²

这个实验设计很有价值。它没有假装AI创建的代码不可能有帮助。同时，它也拒绝了“AI辅助贡献”的懒惰版本：贡献者生成一个补丁，让维护者去筛选整理，而自己不投入任何人类理解成本。

更好，而不是更快

草案中最重要的一句话是：当人们用LLM来写得更好，而不是写得更快时，它们效果最佳。²

这句话应该成为AI编程的默认标准。

单纯追求更快，只会把工作从作者转移给审查者。贡献者花一小时生成补丁，维护者随后花三小时从有用代码、奇怪测试、臃肿评论、含糊诊断信息和无人负责的设计选择中抽丝剥茧。即使差异最终能够编译，项目也已经输了。

“更好”提出的是另一个问题：工具是否帮助人类形成了更清晰的理解？它是否发现了作者亲自验证过的边界情况？它是否帮助起草了作者理解的测试？最终贡献是否更易于审查、维护和信任？

Rust草案让这种区分可以执行。私下使用LLM可以提升作者理解。公开的LLM来源作者身份可能削弱项目的共同理解。实验性的AI创建代码只有在受邀、范围、质量、测试和审查都承担额外负担时才能推进。

这种组合比一概乐观和一概禁止都更好。它承认技术可能有帮助，但项目不会仅仅因为模型让产出变便宜，就吸收责任归属薄弱的产出。

治理章节避免了猎巫

草案在执行方面也处理得异常谨慎。它告诉贡献者，不需要像侦探一样调查他人是否使用LLM。如果违规看起来很明确，就指向政策；如果情况处于灰色地带，就报告给版主，然后继续推进。²

同一章节把关于LLM使用的不诚实行为视为行为准则问题，同时也说明，因他人使用LLM而骚扰贡献者是不可接受的。²这两点同样重要。会鼓励猜疑的政策，可能比它试图阻止的AI生成内容更快毒化社区。

好的AI政策需要两条边界：

草案把责任放在贡献者身上，却没有把每位审查者都变成调查员。这保护的不只是代码，也是审查文化。

其他项目应该借鉴什么

Rust提案值得关注，因为它定义的是角色，而不是氛围。

可以把LLM用作：

• 私人导师；
• 私人审查者；
• 帮助自己理解的总结工具；
• 在人类验证缺陷后使用的缺陷发现辅助；
• 当审查者选择加入且范围保持低风险时的实验来源。

不要把LLM用作：

• 您评论的公开作者；
• 项目文档的声音；
• 编译器诊断信息的作者；
• 人工审查的替代品；
• 没有编写测试的借口；
• 让维护者审查您并不理解的代码的方式。

这份清单给维护者提供了比道德论证更有用的东西：一套可操作的政策。

我的看法

这份草案对准了AI编程制造的质量问题。代码生产变得更便宜了。审查注意力、品味、连贯性、项目语气和社会信任并不会随之变便宜。稀缺性上移了。

优化产出数量的项目，会把维护者淹没在看似合理的差异里。优化责任归属的项目仍然可以使用AI，但只能以让人类作者更有能力、让审查者负担更轻的方式使用。

Rust草案保护了稀缺层。它把诊断信息、评论、文档和审查权限视为项目的一部分，而不是可互换的文本。它把测试和自我审查视为义务，而不是装饰。它给实验留了路径，但没有开空白支票。

这正是严肃软件项目应当走的方向。在Rust采纳任何政策之前，具体规则可能会变化。但底层形态不应改变：AI可以帮助人做出更好的工作，但贡献仍必须由人类承担责任。

FAQ

这项Rust政策已经采纳了吗？

没有。截至2026年5月17日，该政策仍是一个开放的Rust Forge拉取请求，标题为“Add an LLM policy for rust-lang/rust”。当前rust-lang/rust-forge main分支尚未包含src/policies/llm-usage.md。¹⁵

草案是否禁止所有AI使用？

不是。草案有条件地允许私下使用LLM进行学习、总结、审查、个人工具开发和想法生成。它还为已披露、受邀、非关键、高质量、测试充分、审查充分的LLM创建代码设置了一个狭窄实验空间。²

草案禁止什么？

草案禁止由LLM生成的公开评论、议题正文、拉取请求描述、文档、编译器诊断信息，以及把LLM审查视为足以合并或拒绝代码的做法。²

为什么草案如此严格地对待文档和诊断信息？

文档和诊断信息承载着项目语气、用户指导和长期维护义务。草案在某些情况下允许LLM辅助周边逻辑，但禁止LLM创建这些消息本身。²

AI编程团队应从这项提案中学到什么？

区分私下辅助和公开作者身份。凡AI会影响他人的地方，都要要求披露。审查权限必须保留在人类手中。当AI帮助创建代码时，提高测试和自我审查门槛。优化目标应是更好的工作，而不是更多产出。

参考资料