本文永久链接 – https://tonybai.com/2026/08/06/rust-lang-llm-policy-interpretation-2026

大家好，我是Tony Bai。

【导读】

2026年8月5日，Rust官方Inside Rust博客发布了一篇由核心贡献者Jynn Nelson执笔的文章，宣布rust-lang/rust仓库的编译器、标准库、类型系统、rustdoc、bootstrap五个团队，正式联合采纳了一份规范LLM使用方式的政策。这不是一份轻飘飘的倡议，而是一份写明「谁受影响、怎么执行、违反了怎么办」的可操作规则，背后是一场持续了一个多月、在Zulip上产生了三千多条消息的激烈内部辩论。这份政策没有宣布「封杀AI」，却也绝不是「AI友好」——它划出的那条线异常清晰：AI可以帮你思考，但不能替你创作。本文将逐层拆解这份政策出台的背景、核心条款，以及它对每一位Rust贡献者意味着什么。文末也会简单提一下Go、Zig、Linux Kernel等项目各自的立场，供横向参照。

【文章要点】

  • Rust官方明确强调，这份政策不是Rust项目对AI的整体官方立场，也不适用于rust-lang组织下的所有仓库，它只针对评审压力最大的rust-lang/rust核心仓库；
  • 政策诞生的直接动因是三类正在恶化的问题：打磨精致的PR不再等于作者真正理解代码、AI让写代码变容易但评审资源没有同步增加、把评审意见机械搬运给LLM再贴回来是在浪费所有人的时间；
  • 核心原则一句话概括：可以用LLM来提问、分析、提炼、精炼、检查、建议、评审，但不能用来「创造」；
  • 政策对LLM生成代码的要求，是比人类提交更高的门槛，而非更低——必须预先沟通、必须有完善测试、涉及健全性（soundness）的改动被强烈劝阻；
  • 披露是硬性义务：所有公开的LLM文本内容都必须标注，隐瞒AI参与是违反规则的行为，但骚扰使用AI的人同样被明确禁止；
  • Rust选择用政策而非禁令来应对分歧，是因为项目治理依赖共识而非「仁慈独裁者」，这也是这份政策留了大量「未来可修改」接口的原因；
  • Go、Zig、Linux Kernel等项目也各自划出了自己的AI红线，风格从「严格禁止」到「工具中立」不等，但底层关切高度相似。

一份「不代表官方立场」的官方政策

先厘清一个容易被误读的细节：Rust官方博客这篇文章的标题是「rust-lang/rust is adopting an LLM policy」，注意主语是rust-lang/rust这一个仓库，而不是整个Rust项目。作者Jynn Nelson在文章开头就特别强调，这份政策不是Rust对AI的官方整体立场，也不适用于rust-lang组织下的其他仓库——它是编译器（compiler）、标准库（libs）、类型系统（types）、rustdoc、bootstrap这五个团队，专门针对自己负责的这个核心仓库联合采纳的规则。

这份政策会影响四类人：

  • 在rust-lang/rust上评审或参与协调PR的人；
  • 提交含有LLM生成代码的PR的人；
  • 使用LLM发现问题并提交issue的人；
  • 在issue或评论中直接引用LLM输出内容的人。

如果你不属于这四类人中的任何一类，你的日常工作方式不需要做任何改变。

为什么非要立这份规矩不可

在政策成文之前，Rust团队其实早已用LLM做了不少「正面」的事——把邮件翻译成英文方便母语者用自己的语言起草、找出新手容易踩坑的糟糕报错提示、分析RFC是否遗漏了对语言其他部分设计的讨论。

这些用法都在尊重社区的运作方式。但同时，也有一些用法，哪怕并非有意为之，也在悄悄侵蚀社区的根基。文章总结了三类核心问题。

第一，打磨精致的技术产出，不再等于作者投入了真正的理解

过去，一个开源项目收到一份打磨完善、测试齐全的PR，本身就说明提交者在背后投入了大量时间与心力。

这个假设深深塑造了Rust的文化：团队通常不愿轻易关闭一个PR，因为那代表着别人的心血；评审流程强调渐进式讨论，允许设计在评审过程中根据新发现的事实调整；PR本身也被视为一个人想要加入社区、愿意被持续指导的信号。

但LLM让这些信号统统失效——打磨精致不再意味着作者理解自己提交的代码，甚至在自动化Agent的场景下，PR背后可能压根没有一个会持续跟进的人；而当写代码变得如此容易，一份漂亮的PR甚至不再能说明作者会长期留下来。

第二，写代码变容易，直接加剧了评审资源本就紧张的局面

文章提到一个具体数字：截稿时rust-lang/rust仓库有1281个开放中的PR，这代表着作者和评审员双方投入的巨量时间。

评审工作的大头从来不是「挑出Bug」，而是判断这个方向到底对不对、这件事到底值不值得做——文中引用了一个说法，评审本质上是由无数个决策组成的。

把大量PR「霰弹式」地砸向评审员，会带来极高的心理负担；作者往往真心相信自己在提供帮助，但从评审员的角度看，代码本身反而是改动里最不重要的部分，团队真正在意的是作者是否理解代码在做什么、是否规划了它未来会如何演变、是否决定了它应该长成什么样子——而这几件事，代码本身都无法替代。

第三，机械式的复制粘贴，是在浪费所有人的时间

团队经常遇到这样的场景：有人把评审意见复制给LLM，再把LLM的回复原样粘贴回GitHub。

文章用了相当直白的措辞——这是在浪费每个人的时间：如果团队想要一个LLM的意见，自己去问就是了，团队想听到的是你的想法，而不是一台机器的。

更深层的问题是，这种行为在破坏评审员与作者之间最基本的信任——评审的默认前提，是「我在跟一个想把事情做好的真人对话」，一旦怀疑对面根本没有认真投入，甚至怀疑「这里究竟还有没有一个人」，信任就会瓦解。

正因为这些问题在政策出台前只能靠临时搭建的私密频道和非正式的「潜规则」应对——而这些做法本身又违背了项目一贯追求的透明与友善，新贡献者完全不知道规则是什么，PR说关就关，却搞不清楚原因——团队才决定把规则公开、成文、可引用，让新人知道怎么加入社区而不会稀里糊涂地被关闭PR，也让评审员在执行规则时有明确依据可以指向。

政策到底写了什么

政策原文（forge.rust-lang.org/policies/llm-usage.html）用一句话总结了自己：可以用LLM来回答问题、分析、提炼、精炼、检查、建议、评审，但不能用来「创造」。

属于前一类的用途被允许，部分场景需要履行披露义务；属于后一类的用途则被严格限制。具体展开有几条关键规则：

  • 没有人被要求必须阅读LLM生成的输出，除非他们自己主动选择去读：未标注的LLM内容不允许出现在公开文档、PR描述或GitHub评论中；评审员没有义务查看被明确标注为AI生成的PR。
  • 没有人被要求必须使用LLM来参与贡献：政策文本必须先为人类而写，再总结出面向机器的版本；LLM评审不能替代人类的评审或自我评审。
  • 只要不公开发布，私下生成、只有自己看的LLM内容不需要披露。
  • 披露是硬性义务，适用于机器翻译、「琐碎」修改、通过LLM发现的Bug，以及使用LLM辅助评审他人代码等场景；同时政策也明确欢迎大家用自己的母语撰写内容，英文翻译从来不是参与贡献的必要条件。
  • 对于LLM生成的代码改动，政策设置了极其严格的准入条件：这类改动必须经过预先沟通、必须是非关键路径、必须质量过硬、有完善测试与评审记录，并且必须披露来源。文章特别强调，这份政策对LLM生成的代码，执行的是比人类提交更高、而非更低的标准——测试要求没有任何豁免；涉及健全性（soundness）的关键改动，即便作者本人已经是相关领域专家，也被强烈劝阻使用LLM生成，更不用说非专家。

在审核层面，政策也划了两条清晰的红线：

  • 必须披露LLM参与，你可以选择不发布LLM生成的内容，也可以选择发布但必须说明其来源，但不允许隐瞒AI的参与；
  • 骚扰行为不被允许，无论对方使用LLM的行为是否违反政策，都不允许因此对其进行骚扰，Rust行为准则在任何互动场景下都必须被遵守。

文章还特别提到，政策里有些条款其实很难被「抓现行」式地执行，但这不是一个漏洞，而是刻意的设计——政策的目标不是抓出每一次违规，而是画出一条清晰、明确的界线：除非政策特别豁免，所有公开发布的LLM文本都需要披露，这让评审员可以基于行为而非动机来判断是否违规，只有在决定如何回应时，才需要考虑动机。

这对不同角色意味着什么

如果你是issue报告者，通过LLM发现或撰写问题报告时必须披露，并清楚标出报告中哪些部分是LLM生成的内容——「禁止未标注的LLM评论」这条规则同样适用于你。

如果你是提交LLM生成代码的作者，牢记那句总纲就够了：可以用来问、分析、提炼、检查、建议、评审，但不能用来创造。更详细的清单在政策的「允许」章节和rustc-dev-guide里，感兴趣的读者可以进一步查阅。

如果你是评审员，你有权直接关闭不符合政策的PR，无需过多解释，只需要顺手把作者引导到专门的LLM辅助交流频道即可；判断一份PR是否为LLM生成，责任在作者本人而非评审员——项目后续会加入PR模板，直接询问作者代码是否由LLM生成，减少这类争议；文章特别提醒，风格本身不能作为证据，请不要仅凭代码「读起来像AI写的」就当面指控别人。如果你自愿参与LLM代码的专项评审，还需要额外承担一项责任：主动核实这份PR是否触碰了政策明确禁止AI介入的领域，比如文档、诊断信息或健全性相关的改动。

为什么是「政策」而不是「一刀切禁令」

文章花了不小的篇幅解释一个更深层的问题：Rust项目为什么没有像某些项目那样，直接一句话「禁止一切LLM生成内容」，也没有反过来说「AI就是工具，和其他工具没什么两样」。答案很简单：Rust没有一个可以拍板的「仁慈独裁者」。

政策原文中的一段话被直接引用：项目内部对于AI工具何时、如何、在何处可以被接受，目前没有共识，未来大概率也不会有——许多人认为AI很有价值，许多人认为它对社会与环境的负面影响严重到任何使用都不可接受，还有相当一部分人仍在形成自己的判断。

但即便存在这些分歧，项目上下依然共享着一些核心价值：致力于建设一个由深度专家组成的社区，也致力于建设一个所有人都感到被欢迎、被尊重的包容性社区。

也正因为如此，这份政策特意设计得比它被通过时更容易被修改，团队甚至在考虑成立一个专门负责LLM政策的子团队，避免未来每次调整都要凑齐三十人签字这种「噩梦级」流程。

作者本人也坦言，她并不认为政策里的每一条规则都完全正确，但把规则写下来，总比放任大家各自猜测要好，而一份「大家都有点不满意」的政策，恰恰能倒逼团队持续改进自己的治理结构。

横向一瞥：Go、Zig、Linux Kernel都怎么说

放在更大的背景里看，类似的辩论早已在其他项目里发生过，只是选择了不同的解法。

Go核心团队几个月前就因为一次「Co-Authored-By: Claude」的提交说明，在邮件列表上展开了一场关于版权归属与工程责任的激烈讨论，最终倾向于不接受AI作为共同作者、坚持代码必须有具体的人负全责。

Zig则走得更彻底，在其行为准则里直接写明严格禁止一切LLM/AI生成内容。

Linux Kernel社区的基调相对宽松，更接近于「AI只是众多工具之一，关键看怎么用」。

三者风格迥异，但内核关切与Rust这份政策高度一致：代码可以被工具加速产出，但理解与责任，终归要落在一个具体的人身上。

小结

这份政策不完美，Rust团队自己也不掩饰这一点。它只覆盖一个仓库，留下大量有待观察的灰色地带，也依赖大量「不完全可执行」的君子协定。但它做对了一件更重要的事：把长期只存在于少数人脑子里、靠临时频道和口头默契维持的规则，变成了所有人都能查阅、引用、争论的公开文本。

文章末尾提到，团队会持续跟踪一组数据——人们是不是真的在用AI做出有价值、有意思的贡献？他们是不是在学习、是不是会留下来做长期贡献？这些答案，将决定政策未来的走向。

这或许才是这份政策最值得借鉴的地方：不是急于给出一个永远正确的答案，而是先把边界画清楚，再用真实数据去检验和修正它。

参考资料：

  • Rust官方博客：《rust-lang/rust is adopting an LLM policy》，Jynn Nelson，2026年8月5日，blog.rust-lang.org/inside-rust
  • rust-lang/rust-forge LLM使用政策原文：forge.rust-lang.org/policies/llm-usage.html
  • rustc-dev-guide LLM相关指引：rustc-dev-guide.rust-lang.org/llm-guidance
  • Go核心团队邮件列表讨论：https://groups.google.com/g/golang-dev/c/4Li4Ovd_ehE/m/8L9s_jq4BAAJ
  • Zig行为准则AI政策条款：ziglang.org/code-of-conduct
  • Linux kernel ai assistants说明 ：https://docs.kernel.org/process/coding-assistants.html

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。