本文内容根据 Victoria Mossi 于 2026 年 5 月 15 日发布的报道《Rust Project Draws Line on AI Assistance in Core Contributions》整理。

开源项目如何应对 ChatGPT 等 AI 工具带来的代码生成浪潮？Rust 最近的一份提案给出了明确答案：禁止在核心贡献中直接使用 LLM 生成的内容，但私下使用不受影响。

长期以来，Rust 语言以其严谨的代码审查和人类判断为核心价值。

然而，随着大语言模型（LLM）能够在数秒内生成代码和文本，这种文化正面临新的考验。

2026 年 4 月中旬，一份编号为 #1040 的 PR  提交到了 rust-lang/rust-forge 仓库，由 Mara Bos（账号 jyn514）起草。该提案的目标很明确：

• 遏制低质量贡献
• 保留个人借助 AI 提升生产力的空间

截至 5 月中旬，该提案仍在热烈讨论中。

 

 提案核心：公私分明

  私用领域（基本不受限制）

• 向模型咨询现有代码库
• 请求私密总结 Issue 线程
• 个人代码审查与开发工具创建
• 发现 Bug（前提：本人核实、本人撰写报告、披露模型角色）

   公域领域（严格限制）

• 禁止 LLM 撰写的评论、问题描述、PR 文本或代码
• 无法通过 “原创性测试” 的细微修改，将被拒收
• 任何生成内容必须附有清晰的文档并经过严格审查
• 只有经审核者明确同意的高质量贡献才能被接受
• 模型生成的文档必须标记并审核

 

为何此时提出？

提案背后是 Rust 领导委员会年初以来感受到的三重压力：

• “灌水” 提交激增：大量明显由 AI 生成的低质量 PR 涌入，消耗维护者的宝贵精力。
• 能力快速提升：过去模型容易产出明显错误，现在往往生成 “看似合理但存在隐蔽缺陷” 的补丁，筛选成本更高。
• 效率与质量的冲突：资深开发者同样借助 AI 提速，如何既保护审核者精力又不放弃有效辅助是需要思考的问题。

因此，Rust 领导委员会 3 月份就已经出台了一项针对低质量贡献的临时措施并在 RFC 中讨论贡献标准（Inside Rust Blog，2026 年 4 月）。

 

不偏离主线，先聚焦核心库

但 Forge 提案范围较窄：

• 仅覆盖 rust-lang/rust 主仓库
• 其他子模块、外部依赖（crates.io） 暂不涉及
• 语言设计层面的变更不受影响

这种范围划定有利于快速达成共识，也承认了不同区域面临的压力不同。

 

讨论焦点与分歧

在 PR 的讨论区，多位核心成员提出了深思熟虑的意见：

• Niko Matsakis：早期版本难读，建议以 “强制披露” 为更简单的基准。
• Travis Cross：私用条款会不会意外限制跨团队协作？
• Alice Ryhl：允许使用模型辅助生成已标记的安全报告。

部分评论者希望更严 —— 比如 “未征询同意的 LLM 生成代码直接拒绝”；

也有人希望更松 —— 允许某些团队内部采用更宽松流程。

这些意见预计会影响正式版本的出台。

 

Rust 生态中的类似思考与实践

类似的思考与实践早已存在于 Rust 生态中：

• Rust 审核团队已有针对机器生成内容的反垃圾贡献政策。
• This Week in Rust 接受辅助写作，但要求在模型发挥重要作用时必须披露。
• Zig、Servo、postmarketOS 等项目已有相关实践（forge 文档的参考来源）。

Rust 基金会 2025 年回顾报告强调支持维护者，但未直接触及生成式 AI。当前提案正是对这一空白的填补。

 

 后续步骤与意义

如果获得批准，该政策将通过以下方式落地：

• 在 CONTRIBUTING.md 中添加链接和说明
• 更新 rustc 和标准库开发者指南
• 作为动态文档持续迭代

决策路径：

• 最终决定权在 Rust 领导委员会；
• 各相关团队需完成 “最终评议期” 并达成共识；
• 委员会未来若发现明显危害，也有权撤销该政策。

 

结语

Rust 社区没有简单地选择 “全面拥抱” 或 “全面禁止” AI。

这份提案的态度更为务实：

不评判模型好坏，而是回答一个实际问题 —— 如何在保护审核者精力的同时，保留有用的辅助？

草案倾向于：信息公开、人工把关、拒绝低质输出。

随着生成式 AI 越来越深地渗透到开发流程中，Rust 的做法为其他开源项目提供了一个值得参考的治理样本：

立场清晰、保持问责、尊重那些真正撑起项目声誉的开发者。