Rust 给 AI 代码装了个熔断器：50%、六周、十天
先说结论
8 月 5 日，Rust 的五个团队给 rust-lang/rust 这一个仓库定了条规矩：如果连续六周里，合并的 PR 中超过一半由 LLM 生成，就暂停接受 LLM 生成的 PR，至少停十天。
带数字的熔断器，我在别的项目里没见过。别人还在吵"AI 写的代码能不能要"，Rust 跳过了这道道德题，转去给一种资源装配额——评审带宽，不可扩容，也从没被计价过。
值得长期跟的是背后那个判断：生成变便宜了，评审没有。瓶颈换了位置，治理就得换靶子。
事情是怎么发生的
政策由 Jynn Nelson（jyn514）起草，走 rust-forge PR #1040，8 月 5 日合并并在 Inside Rust 博客公告。此前 Zulip 上吵了三千多条消息。
范围先说清，别放大：只覆盖 rust-lang/rust 这一个仓库、五个团队采纳，文件里明确声明这不是 Rust 项目的官方全局立场；subtree、submodule、crates.io 依赖、其他 rust-lang 仓库都不在内。
总纲一句话：“It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create."（可以拿 LLM 回答、分析、提炼、打磨、检查、建议、评审，但不能用来创作。）
配套机制：LLM 生成的代码，提交之前得先找到一个明确答应评审它的人，新贡献者必须先和指定 reviewer 谈过；用了必须披露，合并后打 ai-assisted 标签并汇总到一个 Zulip 频道，用来看这个实验到底有没有用；编译器诊断信息和文档这类面向用户的文字，不允许由 LLM 原创；涉及 soundness 的核心区域（trait system、MIR building、query system），哪怕作者本人是专家也不建议交给模型。
博客给的三条理由更值得看：PR 的打磨程度不再能说明作者是否真的理解、是否想留下来；生成变容易，本来就堵的评审更堵；把评审意见丢给模型、再把回复机械粘回来，协作变成空转。
为什么重要
第一条理由才是核心，也最容易被读漏。
开源社区二十年来靠一个不成文的信号运转：一个 PR 打磨得越干净，说明作者投入越多，也就越值得评审花时间。 没人写进文档，但所有维护者都拿它做分诊。LLM 一来，打磨成本塌到接近零，信号和它指示的东西脱钩。丢掉的不是代码质量，是那把"判断谁值得投入"的尺子。
尺子坏了有两种修法。一种是去查作者——查不准，也确实查不出来。Rust 走了另一种：不判断代码谁写的，转而给被消耗的那个资源装计数、装配额、装熔断。政策自己承认大量条款无法执行，写明目标是 “remove plausible deniability”——不是抓住每一次违规，是让人没法再假装不知道规矩。
这句坦白比政策本身诚实得多。
站得住与站不住的地方
正面：它把"AI 代码算不算数"这种永远吵不完的题，换成了"评审工时够不够用"这种可以计量的运营题。事前预约 reviewer 尤其漂亮——把评审从"默认无限供给的公共品"改成"要先取得同意的稀缺品”，这是开源协作多年没动过的默认值。
反面有四条，都不轻。
一是 “not to create” 这条线在实践里会化掉。LWN 的讨论里已经有人给出走法：让模型用英文讲清楚该怎么改，自己照着敲——代码不是模型生成的，仍算 from scratch。这条线约束的是形式，不是实质。
二是熔断器量错了东西。它数的是合并 PR 的占比，可政策自陈要保护的是评审工时。一个耗掉三十小时评审、最后没合并的 AI PR，在这个计数器里等于不存在。用错的表，计对的资源。
三是范围太窄，洪水会绕路。只管一个仓库，压力平移到别处而已。
四是带宽措施包装成了质量措施。soundness 区不让碰、诊断文案不让生成，是质量条款；熔断器、事前预约，是流量条款。混在一份文件里，将来失效了难判断坏的是哪一半。
这对行业意味着什么
一、投稿审稿是同一个结构。 投稿量在涨，审稿人不涨，而 AI 写作恰好击穿了"稿子打磨得好 = 作者投入多"这个我们同样用了二十年、同样没写进任何规范的信号。Rust 的第一条诊断，一字不改可以搬到期刊和会议。真要治，方向是给审稿工时装配额，而不是去检测 AI 写作——后者和查代码作者一样，注定测不准。
二、给学生的代码和论文，多了一道前置判断。 以前看到一份干净的稿子可以直接进内容讨论，现在得先弄清哪部分是本人做的判断。这一步省不得，因为成长发生在做判断的地方，不发生在敲字的地方。可以借 Rust 的做法：不禁用，但要求声明，并且划出哪些区域（标定流程、评价指标的实现）必须自己写。
三、影像系统里的 review 从来不是抓编译错误。 ISP 代码评审真正在评方向：这个白平衡策略在低照度下会不会崩、这条 CCM 的约束是不是把肤色让给了饱和度、这个指标是不是在测我们真正关心的东西。这些是决策，不是缺陷检查。Nelson 在博客里的说法大意是，评审的本体就是做决策——这恰好是模型最卸不掉的那部分，也解释了为什么"生成变快"不会自动变成"交付变快"。