Rust 给 AI 编程立新规：能帮你看，不能替你写，用多了还会“熔断”

作者 | Tina

本周, Rust项目里, 有五个团队, 已正式采纳了一项新准则, 这项准则关乎AI编程, 其目的在于规范贡献者, 规范的是当贡献者向rust - lang/rust提交代码时, 应怎样去使用大语言模型, 也就是LLM。

Rust项目的主要单体代码库是rust - lang/rust, 该准则的作者Jynn, 于2026年8月5日, 在Rust博客上宣布了这一消息。

简单来说，这份文件可以用一句话总结它的核心原则：

能用 LLM 回答问题, 能用它进行分析, 能用它提炼内容, 能用它完善细节，能用它检查情况, 能用它提出建议, 能用它审查要点, 然而却不能用它来创造。

此准则已获编译器团队批准, 已获标准库团队批准, 已获类型系统团队批准, 已获和团队批准, 它以一套公开且成文之规则, 取代了所说之昔日那种无公开规则且近似“蛮荒西部”之管理方式。

只是它当下仅仅适用于rust - lang/rust仓库, 并且仅仅约束已获批这项准则的团队。在这个范围里, 它划分出一条相当明晰的界线: 欢迎将LLM用作思考的工具, 然而不可让其取代你进行思考。

Rust 到底允许 AI 做什么？

Jynn 在 Rust 博客上介绍了这个新规定：

除了本人心甘情愿, 不然任何一个人都不存在必须去阅读LLM所生成内容的责任。在没有经过清晰标明的状况下, LLM所输出的内容不可以在公开的文档、PR描述或者评论里呈现；要是审阅的人不愿意去查看由LLM参与生成的PR, 那同样能够直接不去审阅。

对rust-lang/rust给出贡献, 并未要求任何人一定要去使用LLM。全部政策都得先撰写以供人阅读, 随后才可再整理成适宜机器读取的版本；LLM的审查结果也无法替代人工审查, 更不能替代作者自身的检查。

你能够在私下运用 LLM, 并且也不需要进行披露, 只要对于那一些生成的内容只是供自己去查看, 不会被发布到任何一处需要 Rust 项目成员去阅读或者审查的地方。

要是运用LLM去做机器翻译, 去作完“微小修改”, 去发觉Bug, 或是审察他人的工作, 那就都得披露LLM有参与。Rust也欢迎贡献者直接拿自己的母语来交流, 并不规定非得先译成英文才能参与贡献。

简单进行表述来看, 那便是“能够实施思考, 能够展开审查, 能够予以翻译, 仅仅唯独不可以进行创造”。将其落到实际中的操作范畴内, 大体上能够划分成三个不同的层级。

最先的那一类属于是全然被许可的情形: 任何一种仅仅是有着做出贡献的那个人自己才会看到语言大模型输出内容的私人化用途项目。就此举例来说, 朝着借助语言大模型去问询跟代码库有关联的问题、对其一讨论串做归纳总结, 或者是在私下里让其去审核自身所撰写的代码。

第二类是能够使用的, 不过必须要进行披露, 这其中涵盖了机器翻译, 再有就是修复拼写错误之类的微小修改, 还有借助语言模型发现漏洞, 以及运用语言模型代码审查机器人。针对审查机器人, 准则又规定它们得采用独立且有明确标记的账号来运行, 如此一来, 那些不想看到这类内容的用户便能够直接进行屏蔽。

第三类明确予以禁止 , 这之中涵盖了 , 由 LLM 直接生成评论 , 以及产生文档和编译器诊断信息, 还有任何必须依赖 LLM 才能够运行的流程 , 另外包括仅仅因为 LLM 给出了审查结论 , 便依据此决定合并或者拒绝某个改动。

这套准则真正有约束力的地方，在于它的执行方式。

倘若存在人员蓄意隐瞒, 或者虚假陈述自身运用LLM的情形, 那么此情况会被视作有违Rust项目 的《行为准则》, 并且同骚扰行为处于等效级别, 首次出现违规的现象或许会收到警告 , 要是反复出现违规的状况则有可能被封禁。

这里提出的文件, 同时明确作出了承认, 承认里面存在着许多规定, 而这些规定, 实际上并没有能够完全借助技术手段来进行强制执行这一情况, 并且表明这是一种有意而为的状况。准则里面是这样写的: “我们所设定的目标, 并非是要抓住每一次出现的违规行为……我们所设定的目标, 在于消除任何能够进行推脱的空间: 使得人们必须在遵守准则以及故意违反准则这两者之间作出选择。”。

Rust并非是那唯一一个着手给LLM划出边界的项目, 并且它同Zig之间所存在的对比是饶有趣味的。

Zig的针对LLM/AI的严酷禁用规则更为彻底, 不但禁止LLM生成的文字与代码, 而且禁止对LLM内容进行改写或者转述, 同时不准许运用AI进行编辑、翻译、头脑风暴或者查找Bug。Zig的方案执行成本低廉, 然而对于贡献者而言遵守成本高昂。Rust却恰恰相反, 它要求审阅者作出更多判断, 不过同时允许贡献者持续运用他们原本就会使用的LLM工具。

AI 写多了，就会触发“熔断”

并非 Rust 根本不许 LLM 编写代码, 而是其将此种贡献限定于边界划分得极为清晰的一个实验里。

最先, 任何经由 LLM 所创建的改动, 都得预先和一位明确指定的审阅者沟通妥当；这些改动不可涉及编译器健全性等关键部分；得有充分的测试, 还得接受充分的人类审查；并且不管处于何种情况, 都得披露 LLM 所参与。

尤其新的贡献者会被施加严格限制, 若你以前未曾参与过项目, 便不可以直接呈上一份由 LLM 创建的 Pull , 而得先寻觅到乐意负责审查的审阅者才行, 一旦你所修改的那部分代码原本并无现成的测试套件, 那么你就必须自行补充一套测试, 不然就只能将这个 PR 关闭, 不存在例外的情况。

这个实验甚至设置了自己的“熔断机制”。

六个星期的任意一个时间窗口当中, 要是已经合并的那些PR, 有超过一半是由LLM 创建的, 那么全部LLM 创建的PR, 都会暂停合并, 一直到其占比重新降低到 50% 之下, 并且至少得冷却 10 天。

这个六周的周期, 并非是随意挑选的, 它恰好与Rust有着的六周发布周期, 保持一致。

所有这类PR都会添加上一个全新的ai-标签, 且会被同步至一个私有的Zulip频道。此频道的目的并非用于设定新的审核门槛, 而是旨在收集数据, 比如通过 相关工具辅助协助的一些工作人员是不是真的处于实践中去学习, 之后还要不要展开一个积极地参与项目, 以及一些协助设计的人员最终能不能持续地打造创造并生成一份十分值得去完成的工作。

在公告里头, 提及了三个压力, 这三个压力最终使得那些团队, 从以往的非正式管理方式, 转变成把规则清晰地写下来。

首要的那个问题在于, 有一份呈现出极为美观样子的Pull, 它再也没办法表明作者切实投入了诸多精力, 并且也没法表明作者真切理解其中的代码。

曾经, 要是开源项目收到一份结构完整的PR, 同时收到一份测试充分的PR, 还收到一份说明详细的PR, 审阅者一般会默认, 背后之人耗费了诸多时间, 并且对自己所提交之物存有一定理解。然而在LLM时代, 这个信号正趋于失效, 而Rust项目的代码审查文化往昔颇为依赖这种信任。

第二个问题在于, 代码生成成本下降后, 原本就紧张的审查资源变得愈发紧张, 当前rust - lang/rust仓库存在1281个未关闭的PR, Rust项目长久以来真正稀缺的资源, 向来都不是代码, 而是审阅者的判断力以及时间, LLM能使一个人极为快速地生成更多代码, 然而却不会同步增加能够判断这些代码是否应当进入项目的人。

第三个问题, 是某些贡献者着手将审阅者的意见复制到 LLM 里, 紧接着又把 LLM 的回答复制回来。依照 的表述, 此类做法属于“浪费所有人的时间”。缘由在于倘若审阅者想晓得 LLM 的想法, 他们能够自行去询问。代码审查切实所需的是贡献者自身的判断与理解。

这种做法还会对代码审查里的一个基础假设造成破坏, 这个假设是, 审阅者会默认自己正与一个真实的人进行交流, 且这个人切实地在对问题予以认真理解, 并对反馈作出回应。

连 Rust 自己人，也没谈拢该不该用 AI

这项准则背后存在着另外一个相当重要的背景情形, 那就是, 在Rust项目内部, 对于AI的那种自身应有的态度, 实际上本就存有显著的分歧状况了。

它的动机部分清晰地写着, Rust内部之中, 关于何时、以何种方式去运用AI工具, 当下并没有达成共识, “并且极有可能永远都不会达成共识”。

项目成员立场跨度巨大, 有人 daily 使用 AI 工具, 有人觉得任何形式 AI 使用皆不被接受, 还有好多人尚处观望与思考阶段, 正因如此, 这份准则从起始便被设计为可修改的, 未来若要进行重大修订, 需每个已批准该准则的团队重新签字同意, 与此同时, 这些团队也能够选择完全废除这项准则。

此外, Rust的领导委员会于当下仍在对成立一个项目级的LLM委员会予以思忖。要是此委员会得以成立, 那么它于将来所制定的项目级规则, 能够直接将现在这份准则涵盖在内。

不过这项准则实际覆盖的范围，比标题看上去要窄很多。

它不适用于rust - lang组织当中别的代码仓库, 它也不适用于语言团队的某些工作, 像是Issue跟踪以及稳定性报告。

这份准则并不约束 Rust 的风格指南, 那些团队, 也就是尚未批准准则的团队, 同样不受其约束, 各个不同的团队依旧能够自行去制定规则。

rust - lang组织内部成员存在一个例外情况, 这个例外是, 他们在运用LLM创建代码的时候, 能够不受到“不得修改关键代码”这一限制的约束。然而, 准则清晰地表态, 极其不主张使用此种例外。

还有, 在准则正式开始生效以前就已经提交的PR, 同样是不会受到这项新规则的约束的。

存在另外一点是需要留意的: 哪怕某一个贡献者着实违背了LLM使用规则, 别的人对于他运用了LLM这件事儿也不可以去实施骚扰行为。骚扰这种行为本身同样是与Rust项目的行为准则相悖的。

六周之后，Rust 会决定要不要继续放行

等ai - 标签正式开端起用之后, Rust会着手经由私有Zulip频道去采集LLM创建PR的数据。

在第一个六周的进程里, 可以协助这些专班判定, 允准在一定范畴之内, 让LLM代码进行奉献, 到底会不会再一次把现有的结合队列沉重地压垮呢。

在此同一时候, Rust方面的进行领导工作的委员会, 还正处于讨论的进程之中, 打算成立专门的LLM这个委员会。要是这次这个委员会最终得以成立, 那么它所制定出来的规则, 将会拥有比当下正在实行的准则更高的那种优先级, 并且规则有较大机率会从rust-lang/rust 这个代码库, 扩展至全整个的Rust项目。

届时, 聊天频道, 目前尚无明确AI准则, 论坛, 还有其他代码仓库, 都有可能被纳入统一规范。

在文章里头切实支持的居然是这一方向, 依照她内心的想法, 当下这份准则仅仅是迈出的第一步, 并非那关于 Rust 究竟该怎么去面对 LLM 的最终答案。

参考链接：