学习资料

主题

⏱ 13 分钟阅读✍️ 3,895 字👁 ...AI开发者工具# Rust# LLM 政策# 开源治理# AI 辅助编程# Claude Code# GitHub Copilot# 开发者工具

Rust 编译器项目立规矩：LLM 能"问答分析"，不能"创造"——一份写给所有开源贡献者的 AI 使用说明书 ​

2026 年 8 月 5 日，Rust 编译器核心仓库 rust-lang/rust 的五个团队通过 Inside Rust Blog 正式公告：项目已经采纳了一份专门针对大语言模型（LLM）使用的政策文档。这份文档不是心血来潮的产物——在此之前，围绕"该不该、能不能在给 Rust 编译器提交代码时用 AI"这个问题，项目内部在 Zulip 上吵了一个多月，攒下了三千多条讨论消息，最后才收敛成一份公开征求意见的 GitHub PR，并在四个团队的联合终审期后落地。

对每天在用 Claude Code、GitHub Copilot、Cursor 之类工具写代码的开发者来说，这不是一条可以划过去的"某开源项目内部行政新闻"。Rust 是全球最活跃、审核最严格的系统级语言项目之一，它这次给出的答案，很可能成为其他大型开源项目制定类似规则时参考的模板。更现实的是：如果你本来就打算或者已经在用 AI 工具给开源项目提交 PR，这份政策里明确写出的"什么能做、什么不能做、怎么披露"，此刻就该被当成一份可以直接抄作业的操作手册来读。

一、背景：审核负担、信号失效，和一次被曝光的"复制粘贴" ​

政策起草者 Jynn Nelson（Rust 编译器团队成员，社区里更熟悉的 ID 是 jyn514）在文档里把制定这份政策的动机归纳为三个越来越难以忽视的现实问题：

第一，"PR 质量高"这个信号正在失效。 过去，一个结构清晰、测试完备、描述详尽的 PR，本身就是贡献者认真投入的证明。但 LLM 现在可以在几分钟内产出同样"看起来"完备的代码和文字，审核者没法再用"写得好不好"来判断"这个人到底有没有理解自己在做什么"。

第二，审核队列本来就已经不堪重负。 rust-lang/rust 仓库长期维持着一千两百多个（1,281 个，文档撰写时的数字）处于打开状态的 PR，而 LLM 显著降低了"写出一个能过 CI 的改动"的门槛，这意味着提交速度可能进一步甩开审核速度，队列只会更长。

第三，一次真实发生、破坏信任的事件成为了导火索。 有贡献者被指出，直接把审核者的评论原文粘贴给 LLM，再把 LLM 生成的回复原样粘贴回 PR 讨论区，整个过程贡献者本人既没有理解评论内容，也没有真正修改代码逻辑，只是充当了一个"人肉 API 转发器"。这种做法被认为直接破坏了代码评审赖以运作的基本信任：评审者投入时间给出反馈，默认对方会认真消化，而不是把反馈原样转手给另一个模型。此外还出现过完全没有 Rust 经验的新人，第一个 PR 就试图给 MIR（Rust 编译器的中间表示层）动手做优化这种高风险改动的情况——这类改动即便出自人类专家之手也要格外谨慎，更不用说由不理解后果的人在 LLM 辅助下提出。

政策文档开篇引用了一句立场鲜明的话："写成文字的规则，胜过不成文的规则。"("A written rule is better than an unwritten one.") 与其让审核者凭个人直觉、一事一议地判断某个 PR 该不该因为"看起来像 AI 写的"而被拒，不如把标准明确写下来，让所有人在同一套规则下工作。

二、政策解析：一句话原则，和它背后的具体条款 ​

整份政策可以浓缩成起草者自己给出的一句话总结：

LLM 可以用来"回答（answer）、分析（analyze）、精炼（distill）、检查（check）、建议（suggest）、审查（review）"，但不能用来"创造（create）"。

围绕这条主线，政策把具体场景拆成了三类：明确允许、有条件允许、明确禁止。

明确允许、无需披露的场景（因为产物只有你自己看得到）：

  • 就代码库内容向 LLM 提问、请它帮你理解一段陌生代码；
  • 让 LLM 总结一个冗长的 issue 或 PR 讨论，方便自己跟进；
  • 在把自己写的代码发布出去之前，先用 LLM 做一轮私下自查；
  • 用 LLM 辅助翻译——文档特别欢迎非英语母语贡献者提交的翻译内容；
  • 在发现安全漏洞、准备披露报告时借助 LLM 整理措辞；
  • 用 LLM 辅助审查别人提交的代码（作为审核者自己的参考，而非替代自己的判断）。

这一类的共同点是：LLM 的输出只是你个人工作流里的一个中间产物，从未以"LLM 生成"的面目被发布到公开可见的地方，因此不需要对外声明。

明确禁止的场景：

  • 由 LLM 撰写、且未经改写就发布的 PR 描述、代码评论；
  • 由 LLM 原创、直接产出的文档内容和编译器诊断信息（compiler diagnostics）文案；
  • 任何把"这段代码/评论已经过 LLM 审查"当作合并或拒绝一个改动的充分理由的工作流——换句话说，AI 说"看起来没问题"不能替代人类真正的判断。

有条件允许的实验性例外——ai-assisted 标签机制： 政策为"由 LLM 直接生成代码"这件事留了一道很窄的口子,但附加了近乎苛刻的前提条件，必须同时满足：

  1. 这次尝试必须由审核者事先主动邀请，而不是贡献者单方面决定要不要用 AI；
  2. 改动不能触及 trait 系统、MIR 构建这类"健全性关键"（soundness-critical）的核心模块；
  3. 代码质量必须过硬，经过充分测试和充分评审，测试用例是硬性要求，没有例外；
  4. 作者和审核者都必须能够完整解释这段代码——"我不懂但它能跑"不是一个可接受的状态。

满足条件的 PR 会被打上 ai-assisted 标签，并同步推送到一个所有 rust-lang 组织成员可见的私密 Zulip 频道，目的是让整个项目能持续观察："这个实验到底有没有真的产出有价值的贡献。"这本质上是一次带着数据收集意图的谨慎试点，而不是一次性拍板的定论。

贯穿全文的硬性要求是披露义务。 政策原话大意是："你可以选择不发布 LLM 生成的内容，也可以选择发布但披露其来源；唯独不能既发布，又隐瞒它是 LLM 生成的。"任何打算被别人看到、审查的产出——PR 描述、评论、文档——一旦掺杂了未经改写的 LLM 输出，就必须明确标注。

需要特别说明适用范围：这份政策只约束 rust-lang/rust 这一个 monorepo，并不代表整个 Rust 项目、更不代表 Rust 基金会的官方立场——生态里其他数以万计的 crate 仓库不受其约束。文档还提到，Leadership Council（Rust 项目的治理委员会）正在考虑成立一个专门负责 LLM 政策的子团队，未来可能推动更大范围、更统一的规则。项目同时开了一个 #llm-mentoring 的 Zulip 频道，给想按规矩使用 LLM 但拿不准边界的贡献者提供咨询渠道。

三、放在行业坐标系里看：Rust 选择了中间地带 ​

这份政策发布后，社区讨论里很自然地把它和其他知名开源项目的既有立场做了对比，这个坐标系本身就很有参考价值：

项目立场
Zig、Servo完全禁止 LLM 生成代码提交
QEMU禁止 LLM 生成代码，但允许非生成类用途（问答、审查等）
Linux 内核、LLVM、Firefox允许使用，但要求披露 + 人类监督兜底
NixOS仍在草案讨论阶段，尚未形成社区共识
rust-lang/rust默认"能分析不能创造"，附加极窄的 ai-assisted 实验通道

值得一提的是，Zig 项目在阐述自己"绝对禁止"立场时，援引了阿西莫夫 1957 年的一篇科幻短篇小说来论证"原创思考不可被机械替代"这个价值判断——足见这场关于 LLM 在开源协作中该扮演什么角色的讨论，本质上早已超出了纯技术范畴，进入到了项目文化与身份认同的层面。Rust 选择的"中间路线"——不一刀切禁止，而是用清单+实验田+强制披露的方式管理——某种程度上也反映了它作为一个体量庞大、贡献者背景极其多元的项目，在治理上必须寻找共识而非强推立场的现实约束。

政策落地后在 Hacker News 上引发了不小的讨论（帖子拿到 69 分、26 条评论），争议焦点主要集中在"这到底代表谁的意见"上。Rust 核心团队成员 JoshTriplett 提醒大家，这份文档目前更像是"一份引用了其他人各种立场、但并不代表任何官方统一意见的内部草稿"；另一位评论者 mtndew4brkfst 则直言，文档的措辞在描述"符合"与"不符合"起草者本人观点的立场时，明显带有倾向性。更尖锐的批评来自 Rust 项目的资深贡献者 Niko Matsakis——他认为这份政策"比完全没有政策还要糟糕"，理由是规则过于复杂、限制过严，反而会劝退那些本可以为项目做出贡献的潜在新人。另一位贡献者 Diggory Blake 则提出了一个更根本的重新框定：与其纠结代码到底是不是 LLM 写的，不如干脆把评审标准聚焦在"代码质量本身"，把更多裁量权交还给维护者的专业判断——这其实呼应了不少人对"来源审查"这条路径本身有效性的怀疑。

四、实践指南：给正在用 AI 工具做开源贡献的开发者 ​

无论你是不是 Rust 生态的贡献者，这份政策里"能做什么、怎么披露"的框架都值得直接搬到自己参与的任何项目里。这里给出一套可以照抄的实践清单：

1. 提交前，先问自己一个问题：这段内容会不会被别人评审？

  • 只在本地终端里用 Claude Code / Copilot 帮你理解代码、生成草稿、做自查——不需要任何披露；
  • 一旦这段内容（代码注释、PR 描述、issue 回复）会被别人看到并纳入评审，就进入下一步。

2. PR 描述里显式标注 LLM 参与的部分。 一个符合"Rust 式"披露标准的 PR 描述可以这样写：

markdown
## 变更说明
修复 #12345：解析器在遇到嵌套泛型时的越界 panic。

## AI 使用披露
- 本 PR 的实现逻辑与测试用例由我本人编写和验证。
- PR 描述的英文措辞部分经 Claude 辅助润色（原始技术内容为我本人撰写）。
- 未使用 LLM 生成任何未经我逐行阅读和理解的代码。

3. 给自己的 commit 加一个可追溯的规范标记。 参考 Linux 内核、许多大厂内部规范的做法，可以在 commit message 末尾加一行标准化 trailer，方便审核者和未来的代码考古一目了然：

Fix off-by-one in nested generic parsing

Co-Authored-By: Claude <noreply@anthropic.com>
Assisted-By: Claude Code (draft generation, human-reviewed)

4. 永远不要把"AI 说没问题"当成合并的理由。 无论是给自己的 PR 找"AI 审查通过"背书，还是作为审核者用 AI 摘要代替自己读 diff，这条路径在 Rust、Linux 等几乎所有成文政策里都是明确踩线的——审核责任不能外包给模型。

5. 触碰"高风险区域"前，先跟维护者打招呼。 如果你打算用 LLM 辅助写涉及安全边界、并发逻辑、类型系统这类"改错了会很难排查"的核心模块，最稳妥的做法是照抄 Rust 的 ai-assisted 思路：先在 issue 或社区频道里知会维护者"我打算怎么用 AI 参与这部分"，拿到默许之后再动手，而不是先斩后奏。

6. 检查目标项目自己的政策文件。 越来越多知名项目（Rust、Zig、QEMU、Linux、Servo）都已经或正在制定专属的 LLM 使用政策，贡献前花两分钟搜一下仓库根目录或 CONTRIBUTING.md 里有没有类似文档，是目前性价比最高的合规动作。

五、总结与展望 ​

Rust 这份政策释放的信号，比它具体的条款更值得记住：围绕"AI 该在开源协作里扮演什么角色"这个问题，行业正在从"要不要用"的表态阶段，转向"怎么用、怎么披露、谁来担责"的流程设计阶段。 一刀切的全面禁止（Zig、Servo）和完全放任的模糊地带都不再是主流大项目愿意长期停留的位置，取而代之的是像 Rust 这样"分场景列清单 + 开一个可观测的实验通道 + 强制披露"的治理模式——本质上是把一个价值判断问题，转化成了一套可执行、可审计的工程流程。

对独立开发者和普通团队而言，即便你从不打算给 Rust 编译器提交代码，这套框架本身也提供了一份现成的模板：区分"仅供个人使用"和"会被他人评审"两类场景、对后者强制披露、划出不能触碰的高风险区域、明确"AI 审查"不能替代"人类担责"。随着越来越多头部开源项目把这类规则明文化，能不能读懂并遵守这些规则，会逐渐变成开源贡献者的一项基本素养——就像多年前大家逐渐习惯了 DCO 签署、Contributor License Agreement 一样。与其等自己提交的 PR 因为"看起来像 AI 写的"被打回来，不如现在就把披露习惯建立起来。

参考来源 ​

📚 相关文章

💬 评论