一句话看懂：Rust 项目五个核心团队采纳了统一的 LLM 编程准则，允许用大模型分析、审查、翻译代码，但禁止直接生成或创造；并设置熔断机制，防止 AI 生成的 PR 淹没人工评审。这是主流开源基础设施首次用成文规则给 AI 写代码划定清晰边界。
事件核心：发生了什么
2026 年 8 月 5 日，Rust 项目的 Jynn Nelson 在 Inside Rust 博客上宣布，编译器、标准库、类型系统、rustdoc 和 bootstrap 五个团队已正式批准一项 LLM 使用准则，适用于 rust-lang/rust 主代码库的贡献流程。核心原则可概括为：LLM 可以用于回答问题、分析、总结、完善、检查、提出建议和审查，但不能代替贡献者创造代码、评论或文档。
执行层面分三档：私人自查无需披露；机器翻译、微小修改、找 Bug、审查机器人必须披露；直接生成 PR 内容、依赖 LLM 运行的流程、仅凭 LLM 审查结论合并代码则被禁止。所有由 LLM 创建的 PR 需添加 ai-assisted 标签，并进入私有 Zulip 频道跟踪。最引入注目的是一条熔断机制：任意六周内合并的 LLM 创建 PR 若超过总数一半，将暂停合并直到占比回落至 50% 以下并冷却至少 10 天。六周周期与 Rust 发布节奏一致。
为什么重要
这份准则的深层意义，是开源项目面对 LLM 降低代码生成成本时，开始重新校准“信任信号”。过去一份结构完整、测试充分的 PR 通常意味着作者投入了时间、理解了细节；但当 LLM 能低成本产生同样漂亮的提交时，这个信号失效了。Rust 仓库当前积压着 1281 个未关闭 PR，真正稀缺的不是代码量，而是审阅者的判断力和时间。与此同时，Rust 项目内部对 AI 的态度也存在明显分歧——从日常重度使用到完全拒绝都有，因此准则被设计成兼顾弹性和透明度的折中方案。它承认许多规定无法靠技术强制，目标只是消除“可推脱空间”，让违规变成明确的故意行为，并与《行为准则》挂钩。对比之下，Zig 选择全面禁用 LLM 改写与生成，执行成本低但贡献者遵守成本高；Rust 则保留了工具自由度，但把判断责任压回了审阅者身上。
对用户/开发者/创作者的影响
对想参与 rust-lang/rust 的开发者来说，最直接的变化是：底层代码贡献和公开交流中存在一条明确的“披露线”，私下用 LLM 提问没问题，但公开发布前必须声明 AI 参与。新贡献者用 LLM 创建 PR 前，必须先找到愿意负责的审阅者；若修改区域没有现成测试，必须自己补上完整测试，否则只能关闭 PR。经常使用 AI 辅助开发的中级开发者会发现，类似“把审阅意见复制给 LLM、再把回答贴回 GitHub”的做法已被视为浪费审阅者时间的行为——审阅者期待的是你本人的理解和判断。如果你运营代码审查机器人或其他 AI 工具，需要用它专用的 GitHub 账号运行，方便他人屏蔽。值得注意的是，这项准则目前只覆盖 rust-lang/rust 仓库内部这五个团队，其他 Rust 团队、其他仓库及聊天论坛暂不受约束。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
第一，ai-assisted 标签启用后首个六周数据周期，是判断“有限放行 LLM 代码”是否会把合并队列进一步压垮的关键样本。第二，Rust 领导委员会正在讨论成立项目级 LLM 委员会，如落地，规则范围可能从单一仓库扩展到聊天频道、论坛和全部相关仓库，覆盖范围将显著扩大。第三，目前公开信息中尚未明确规则对商业机构维护者（例如自身有闭源模型的科技公司）的适用细节——他们是否需要在向 Rust 提交代码时披露使用了哪类模型，以及“人工深度修改”到什么程度可视为不再是 LLM 创建，这些操作边界会是后续实际执行中最容易产生争议的地方。
来源：InfoQ CN
