Rust LLM 贡献政策是什么 只绑主仓库

2026 年 8 月，Rust 项目里五个团队在主仓库 rust-lang/rust 采纳了一份 LLM 使用政策。若你问 rust llm 贡献政策是什么，先记住两点：它管的是主仓库里审 PR、发 PR、用 LLM 找 issue、在评论里贴 LLM 原文的那几类人；它不是整个 Rust 项目的官方立场，别的仓库可以没有这套规则。

作者：CodePass 技术编辑

谁必须改习惯，谁可以照旧

Jynn Nelson 在 Inside Rust 的说明 把适用范围写得很窄。必须遵守的是四类人：在主仓库审查或 moderation PR 的人；用 LLM 生成代码再提 PR 的人；用 LLM 发现问题并到主仓库报 issue 的人；在 issue 或评论里直接引用 LLM 输出的人。不在这四类里，工作流程不用为这份政策单独调整。

政策作者强调，这是为解决主仓库社区摩擦写的成文规则，不是 Rust 全生态对 LLM 的统一态度。其他子项目可以有自己的政策，也可以没有；当前文本只覆盖 rust-lang/rust monorepo。写进 CONTRIBUTING 之前，moderation 靠非公开渠道和口头惯例，新人常因「不知道规矩」被关 PR。

成文前社区里的三类摩擦

博文把 LLM 带来的压力归纳成三个方向，也是政策动机，而不是泛泛的「反对 AI」。

第一类是信号失真：过去一份打磨好、带测试的 PR 往往代表作者投入时间和理解；主仓库文化因此 reluctant 关 PR、鼓励增量讨论、把 PR 当作「有人想加入社区」的信号。LLM 让「表面完成度」和真实理解脱钩，自主 agent 场景下甚至不一定有持续维护者在场。

第二类是评审带宽：博文写到当时主仓库约有 1281 个 open PR，本来就「想写代码的人多于愿意 review 的人」。LLM 降低写代码成本后，向 reviewer「散弹式」丢 PR 的边际成本更低，而 review 里大量工作是方向与取舍判断，不是找 bug；代码本身反而是变更里较小的一部分。

第三类是机械往返：有人把 review 意见复制进 LLM，再把模型回复贴回 GitHub。博文直说这是在浪费双方时间，也破坏「对话对象是真人」的信任假设。政策要把这些此前靠 moderation 私下处理的情况，改成可公开引用的条款。

政策总则：分析可以，创造受限

政策自述的核心句在官方博文里被逐字引用：

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

中文读者可以把它理解成两档：第一档（问答、分析、提炼、润色、检查、建议、review）允许，部分场景要披露；第二档（用 LLM「创造」你要提交的内容）受到严格限制。Rust 治理靠共识，博文解释为何不能简单「全面禁止 LLM」或「全面放开」：项目内对 AI 的价值与风险没有共识，政策要在共享价值观（培养深度专家、包容社区）下找可操作中间路线。

披露、翻译与公开可见的 LLM 文本

「总则」之外，博文概括的通用规则包括：

• 除作者本人外，没人必须阅读 LLM 输出；除非明确标注，LLM 输出不应出现在公开文档、PR 描述或 GitHub 评论里；reviewer 若不愿审 LLM PR，可以不审。
• 贡献者不被要求使用 LLM；政策文档必须先为人写，再为机器摘要；LLM 做的 review 不能替代人类 review 或作者自检。
• 仅自己可见、且不发布到需要社区阅读或 review 之处的 LLM 内容，可以不披露。
• 机器翻译、「trivial」改动、用 LLM 发现 bug、用 LLM review 他人工作：需要披露。博文写明欢迎用母语发帖，不强制先译成英文再贡献。

Issue 报告者同样适用「公开评论里的 LLM 文本」规则：若用 LLM 发现问题或写报告，必须披露 LLM 参与，并清楚标出哪些段落来自模型。这和 coding agent 在 GitHub 上「代笔回复」的风险类似，只是 Rust 把边界写进了仓库政策；工具侧权限与身份边界可对照 AI agent 工具权限边界失效怎么办 里「提示词不是安全边界」那套核验顺序。

LLM 生成代码：更高门槛，不是更低

对要合入主仓库的 LLM 生成代码，博文引用的政策口径是：事先安排好的、非关键路径、高质量、有充分测试且经充分 review、最初由 LLM 产出的改动，在披露前提下可以允许。同时 LLM 改动 bar 高于人类作者，而不是更低：LLM PR 必须有测试，「无论多难」；一般不得让 LLM 生成 soundness-critical 改动，除非作者已是领域专家，且仍强烈不推荐。

动机是维护集体对代码的心智模型，博文引用 Isaac Asimov《Profession》里的「No programmer tapes」意象：社区要的是理解与设计能力，不是可机械粘贴的成品。若你习惯用 agent 一次生成大 diff，再指望 reviewer 帮你「认领理解」，这和 Rust 主仓库当前方向是冲突的；把计划与阶段写进仓库、让人能接续 review 的做法，见 用文件做 Agent 规划，它解决的是协作可读性，不能替代披露义务。

审 PR 的人能关 PR、不必当侦探

Review 侧规则在博文里同样具体：不符合政策可以无额外解释关 PR，并指向 #llm-mentoring；是否 LLM 生成由作者负责，计划增加 PR 模板询问作者。Reviewer 不应凭「风格像 AI」指控他人；若作者否认但仍有疑虑，应私下报 moderation，而非公开羞辱。自愿审 LLM PR 的人还要检查改动是否触及政策禁止区域（如文档、诊断、soundness-critical）；可要求作者不用 LLM 重做。

Moderation 层：必须披露 LLM 生成内容，不得隐瞒；不得因他人使用 LLM（即便违规）而骚扰；始终遵守 Code of Conduct。博文承认部分条款无法逐条执法，目标是亮线规则——公开 LLM 文本默认要披露，除非政策明确豁免——便于按行为而非意图处理。

政策正文以仓库内 canonical 文本为准；博文与 Inside Rust 全文 是 2026-08-05 的解读入口，后续 council 还可能设专门小组调整治理流程。

参考资料

• rust-lang/rust is adopting an LLM policy（Jynn Nelson，2026-08-05）
• rust-lang/rust 仓库（政策 canonical 文本以仓库内当前文件为准）