Rust官方发文：AI 可以审代码，但不能写代码
内容提要
Rust官方于2026年8月5日采纳LLM使用政策，针对核心仓库，允许用LLM提问、分析、评审，但禁止生成代码。政策要求披露AI参与，对LLM代码设更高标准，强调人类理解与责任。此举因项目无独裁者，靠共识治理。Go、Zig、Linux各有立场，但核心关切一致：工具可加速，责任在人。
延伸解读
政策适用范围有限
这份政策并非Rust项目的整体AI立场，仅针对rust-lang/rust核心仓库，由编译器、标准库、类型系统、rustdoc和bootstrap五个团队联合采纳。其他仓库或项目不受影响。政策影响四类人：评审或协调PR者、提交LLM生成代码者、用LLM发现问题并提交issue者、在评论中引用LLM输出者。若不属于这些角色，日常工作无需改变。
核心原则：可用不可创
政策的核心原则是：可以用LLM来提问、分析、提炼、精炼、检查、建议、评审，但不能用来“创造”。这意味着LLM可以辅助思考，但不能直接生成代码或文档。对于LLM生成的代码，政策设置了比人类提交更高的门槛，要求预先沟通、非关键路径、完善测试和披露来源。涉及健全性的改动被强烈劝阻使用LLM。
披露与责任并重
政策强调披露是硬性义务，所有公开的LLM文本内容都必须标注，隐瞒AI参与是违规行为。同时，骚扰使用AI的人也被明确禁止。政策设计上允许私下使用LLM而不披露，但公开发布必须透明。评审员有权关闭不符合政策的PR，但判断责任在作者而非评审员。政策还提醒，不能仅凭风格判断代码是否由AI生成。
治理模式决定政策选择
Rust项目没有“仁慈独裁者”，治理依赖共识，因此选择政策而非禁令。政策设计为易于修改，并考虑成立专门子团队负责LLM政策。作者承认政策不完美，但认为公开规则比默认猜测好。横向对比，Go倾向不接受AI作为共同作者，Zig严格禁止LLM内容，Linux相对宽松，但核心关切一致：工具可加速，责任在人。
Q&A
Rust官方在2026年8月5日采纳的LLM使用政策主要针对哪些团队和仓库？
该政策由Rust的编译器、标准库、类型系统、rustdoc和bootstrap五个团队联合采纳，专门针对rust-lang/rust核心仓库，不适用于rust-lang组织下的其他仓库。
Rust的LLM政策核心原则是什么？
核心原则是：可以用LLM来提问、分析、提炼、精炼、检查、建议、评审，但不能用来“创造”代码。即AI可以辅助思考，但不能替代人类创作。
Rust团队为什么要制定LLM使用政策？
因为出现了三类问题：一是打磨精致的PR不再代表作者真正理解代码；二是AI让写代码变容易但评审资源没有同步增加；三是机械地把评审意见复制给LLM再贴回是在浪费所有人的时间。
Rust政策对LLM生成的代码有什么特殊要求？
对LLM生成的代码要求比人类提交更高：必须预先沟通、必须是非关键路径、必须有完善测试和评审记录，并且必须披露来源。涉及健全性（soundness）的关键改动被强烈劝阻使用LLM生成。
Rust政策中关于披露AI参与有哪些规定？
披露是硬性义务：所有公开的LLM文本内容（包括机器翻译、琐碎修改、通过LLM发现的Bug、辅助评审等）都必须标注来源。私下生成且不公开发布的内容无需披露。隐瞒AI参与是违规行为。
Rust为什么选择用政策而非一刀切禁令来应对AI？
因为Rust项目没有“仁慈独裁者”，治理依赖共识。项目内部对AI使用没有共识，因此需要一份可修改的政策来划清边界，同时保持开放，未来可根据数据调整。
Go、Zig和Linux Kernel对AI生成代码分别持什么立场？
Go核心团队倾向于不接受AI作为共同作者，坚持代码必须有具体的人负全责；Zig在其行为准则中严格禁止一切LLM/AI生成内容；Linux Kernel基调相对宽松，认为AI只是工具之一，关键看怎么用。
作为评审员，根据Rust政策，遇到不符合规定的PR应该如何处理？
评审员有权直接关闭不符合政策的PR，无需过多解释，只需将作者引导到专门的LLM辅助交流频道。判断PR是否为LLM生成的责任在作者本人，评审员不应仅凭风格猜测。
