一边是 vibe coding 的教程在全网刷屏，连"爸爸用 AI 给妈妈做个小程序"都能上热搜；另一边，编程世界里工程要求最严的社区之一，已经悄悄把"AI 到底能怎么用"写成了白纸黑字的规则。
8 月 5 日，Rust 项目的编译器、标准库、类型系统、rustdoc、bootstrap 五个团队正式采纳了一份 LLM 贡献准则，rust-lang/rust 成为第一个把"AI 辅助编程"写成明文规则的主流基础设施项目。InfoQ知乎这不是又一条"AI 要取代程序员"的噪音，而是一份难得把边界画清楚的规则文本——每一个每天在用 AI 写代码的人，都值得拿它对照一下自己的用法。
一句话原则：AI 可以帮你思考，不能替你思考
这份准则的核心只有一句话：你可以用 LLM 回答问题、分析、提炼、检查、提建议、做审查，但不能用它来"创造"。Rust Forge
具体落到操作层面，分成了三档。
第一档是完全允许的私人用途。只要输出只有你自己看，随便用：向 AI 问代码库的问题、让它总结一段冗长的讨论串、私下让它审查你自己写的代码，都不需要向任何人交代。
第二档是可以用、但必须披露。包括用 AI 做机器翻译、修拼写错误这类"微小修改"、借助 AI 发现 Bug、以及跑 AI 代码审查机器人——审查机器人必须使用独立且明确标记的账号，不想看的人可以直接屏蔽。
第三档是明确禁止。AI 直接生成的评论、文档、编译器诊断信息，不能出现在项目里；任何"离开 AI 就跑不下去"的流程不被接受；更不能仅仅因为 AI 给出了审查结论，就据此决定合并或拒绝一个改动。Rust Forge
准则还给了审阅者一项很硬的权利：任何人没有义务阅读 AI 生成的内容，未经明确标注，AI 输出不得出现在公开文档、PR 描述或 GitHub 评论里；如果审阅者不想碰有 AI 深度参与的 PR，可以直接不审。InfoQ
两条最狠的条款：50% 熔断线，隐瞒等于骚扰级违规
这份准则真正出圈的地方，是它的执行机制。
第一条是"熔断"。如果在任意一个六周窗口内，已合并的 PR 中超过一半是由 AI 创建的，那么所有 AI 创建的 PR 全部暂停合并，直到占比降回 50% 以下，而且至少要冷却 10 天。Rust Forge六周这个周期不是随便选的，正好和 Rust 的发布周期对齐。InfoQ所有这类 PR 都会打上 ai-assisted 标签，数据同步到一个专门的 Zulip 频道——目的不是设新门槛，而是收集数据：用 AI 辅助的贡献者到底有没有在学、之后还会不会留下来。
第二条是处罚。如果有人故意隐瞒或虚假陈述自己使用 AI 的情况，会被视为违反 Rust 项目《行为准则》——和骚扰行为同一个级别。初犯可能收到警告，反复违规可能被封禁。Rust Forge有意思的是，准则同时写明：反过来，别人也不能因为你用了 AI 就对你进行骚扰，那同样违规。InfoQ
准则自己也承认，很多条款在技术上没法完全强制执行，而且这是有意为之。原文写得很直白：目标不是抓住每一次违规，而是消除任何可以推脱的空间，让每个人必须在"遵守规则"和"明知故犯"之间做出选择。Rust Forge
为什么是现在：三个压力，把 Rust 逼到了必须立规矩
准则作者 Jynn Nelson 在 Inside Rust 官方博客里说了三个直接原因，每一个都戳在当下 AI 编程的痛点上。Rust官方博客
第一个，“漂亮的 PR"不再等于"用心的作者”。过去，一份结构完整、测试充分、说明详细的 PR，审阅者会默认背后的人花了时间、理解了代码。现在 AI 几分钟就能生成一份卖相极好的 PR，这个信任信号正在失效。
第二个，代码生成成本趋近于零，但审查资源没有增加。目前 rust-lang/rust 仓库还积压着 1200 多个未关闭的 PR。InfoQRust 真正稀缺的从来不是代码，而是审阅者的判断力和时间。AI 能让一个人飞快地生成更多代码，但不会同步多出一个能判断这些代码该不该进项目的人。开源社区遇到了一个很现实的新问题：代码越来越便宜，人的判断越来越贵。机器之心
第三个最生动：有贡献者开始把审阅者的意见复制给 AI，再把 AI 的回答原样贴回 GitHub。Nelson 的评价毫不客气——这是"浪费所有人的时间"，因为审阅者想知道 AI 怎么想，完全可以自己去问。Rust官方博客代码审查的前提是你在和一个真实的人交流，而这个人确实在认真理解问题。
顺带一提，Rust 内部对 AI 的态度本身就没谈拢。准则的动机部分明确写道：项目内部对什么时候、怎么用 AI"没有共识，而且很可能永远也不会形成共识"——有人天天用，有人认为任何形式的使用都不可接受。Rust Forge这份规则背后是一场持续一个多月的内部辩论，光 Zulip 上就留下了三千多条消息。Tony Bai所以它从一开始就被设计成可修改、甚至可以整体废除。
不只是 Rust：同一道题，开源世界已经交出一整排答案
把视野拉远一点，会发现这不是孤立事件。短短一两个月内，多个主流开源项目对"AI 代码能不能进仓库"交出了截然不同的答案，正好构成一条从严到宽的光谱。
最严的是 Zig：不仅禁止 AI 生成的代码和文字，连改写、转述 AI 内容都不行，甚至不允许用 AI 做编辑、翻译、头脑风暴和找 Bug。InfoQ执行成本最低，但贡献者遵守成本最高。
Godot 基金会 7 月初宣布，禁止贡献者提交 AI 编写的代码和 AI 代理发起的 PR，继续提交会被 GitHub 自动封禁；AI 只被允许做代码补全、正则表达式、查找替换这类"琐碎事务"。原因很直白：维护者每天被迫在海量 AI 提交里猜哪些是真知灼见、哪些是"赛博垃圾"，审核从质量把关变成了机械的垃圾过滤。网易网
GCC 指导委员会 7 月底采纳的政策走法律路线：一律拒收具有"法律意义"的 AI 生成或派生代码，只有测试用例例外，"法律意义不显著"的小改动在明确标注后可以接受。这是暂行安排，2027 年初会重新审视。cnBeta
光谱中段同样热闹。Go 团队几个月前因为一条"Co-Authored-By: Claude"的提交说明，在邮件列表里吵了一轮版权归属，最终的倾向是不接受 AI 当共同作者——代码必须有具体的人负全责。Tony BaiLinux 内核的规矩带着林纳斯·托瓦兹的个人风格：维护者必须完全理解并能为自己提交的每一行代码辩护，解释不清 AI 补丁背后逻辑的，直接拒收。InfoQ
Kubernetes 则走"披露换共存"的路线：PR 描述里必须披露 AI 的使用情况，禁止 AI 生成的提交信息，AI 审查工具只当建议性的质量门，拍板的还是人。InfoQ
Rust 则选了最"重"的一条路：允许你用，但高披露、高门槛、可追溯，把判断负担交给审阅者。这条规则也收获了跨阵营的认可——有 OpenAI 研发人员以自己开源维护者的身份公开表态，认为它"非常周到且合理"。机器之心
这些路线谁对谁错，现在没人能下结论。但它们指向同一个事实：AI 代码"匿名裸奔"的时代正在结束。商业世界的动作同样印证了这一点。据 Wiz 与 Snowflake 近日披露，Snowflake 一个公开仓库的 GitHub Actions 工作流存在脚本注入漏洞，AI 编码助手 Copilot Autofix 曾以共同作者身份参与相关检查，却没有拦住问题；漏洞上线五天后，被 Wiz 的红队 Agent 发现并验证了完整利用链路。知乎需要说明的是，公开证据并未证明那次问题改动由 AI 写成——但"AI 参与审查也没能兜底"这件事本身已经足够提醒人。同样是这两天，Cursor 发布了限量测试的 AI 原生代码库 Origin，其中一个核心卖点就是"代码溯源"：每一行 AI 注入的代码都留下结构化元数据，记录模型、提示逻辑和上下文窗口，方便审计。知乎
开源用规则划边界，商业把溯源做成产品。方向是一致的：AI 写的每一行代码，都得有人站出来负责。
对每天用 AI 写代码的你，这意味着什么
你可能会想：我又不去给 Rust 提 PR，这份规则关我什么事？
关系在于，Rust 只是第一个把大家心照不宣的东西写出来的项目。知乎上有个问题——“大家Vibe Coding路上遇到最大的问题是什么”，一个回答说得直白：启动任务替代了处理问题，完成数量替代了工程质量。知乎生成可以并行、理解只能串行，机器的带宽上去了、人的带宽没跟上——这些几乎是每个每天开着多个 Agent 写代码的人的日常。Rust 的三档分类，正好可以拿来给自己的使用习惯做个自查。
落在安全区的三个习惯：把 AI 当搜索引擎和总结工具，问问题、读代码、梳理讨论；写完代码先让 AI 帮你审一遍，但改动的决定权留在自己手里；用 AI 做翻译、修小错这类小事时，在团队协作里大大方方说出来。
踩在危险区的三个习惯，值得逐条对照。第一，把 AI 一口气生成的整个功能直接交出去，自己说不清实现逻辑。在 Rust，这类 PR 必须提前找到愿意负责的审阅者。InfoQ新贡献者甚至没有直接提交的资格。Rust Forge第二，改动的模块本来没有测试，也不补测试就提交。第三，拿 AI 的回复去正面回怼审查意见，把"人机传话"当成沟通。
更深一层的信号是：当生成代码的成本趋近于零，真正被定价的就不再是代码产出速度，而是理解、测试和担责的能力。AI 能替你打字，但替不了你在代码出问题时回答"为什么这么写"。
接下来值得盯的两个信号
这份准则不是终局，它自己就写着"只是第一步"。有两个后续值得持续关注。一是第一个六周周期结束后的熔断数据——AI 辅助 PR 的占比、这些贡献者有没有留下来，会直接决定规则是收紧还是放宽。Rust官方博客二是 Rust 领导委员会正在讨论成立项目级的 LLM 委员会，一旦成立，它的规则优先级会高于现在这份准则，覆盖范围也可能从 rust-lang/rust 扩展到整个 Rust 项目。InfoQ
最后留个讨论：50% 的熔断线，你觉得是太松还是太严？如果你们团队的代码库也立这么一份规矩，你希望熔断线画在哪？
