半个月前，你把一份用 AI 反复打磨过的补丁提交给 GCC，大概率会被直接拒收，没得商量；同一份代码提交给 Rust，对方会先问你一句"哪部分是 AI 写的"；提交给 Zig，答案更干脆——只要 AI 参与过，连门都进不去。
从 7 月底到 8 月中旬，基础软件圈像是约好了一样，密集对 AI 代码表态。但仔细看会发现，大家画的线根本不在同一个位置。我把这波事件和各项目的规则手册梳理了一遍，如果你平时爱折腾编译器、也打算给开源项目提交第一份 AI 辅助的 PR，建议先看完再动手。
半个月里发生了什么
先把时间线捋清楚，信息量有点大：
7 月底，GCC 指导委员会正式公布 AI 贡献政策：拒绝一切"法律意义显著"的 LLM 生成代码，外界转述的门槛大约是 15 行以上。微博用 AI 帮忙找 Bug、写测试用例没问题，但 AI 生成的代码本身不收，甚至"AI 写完人再改"的也不收。知乎上那个"怎么看 GCC 正式拒绝所有 AI 代码"的问题，两周多攒了 23 万+浏览。
8 月 5 日，Rust 官宣：编译器、标准库、类型系统、rustdoc、bootstrap 五个团队联合为 rust-lang/rust 主仓库采纳了一份 LLM 政策。这份政策不是拍脑袋出来的，背后是一场持续了一个多月、在 Zulip 上留下三千多条消息的内部辩论。
8 月上旬，甲骨文被曝对 OpenJDK 项目禁止 AI 生成代码，动机分析见下文，带有推测成分。
Debian 社区同期就"是否禁止 AI 代码"发起正式投票，三个提案摆上台面，结果当时还没出来。这是第一个以正式投票机制面对这一问题的重量级项目。
再往前倒：今年 1 月，一个约 1.9 万行、由 Claude 生成的 PR 冲击 Node.js 核心库，社区吵翻天；6 月，游戏引擎 Godot 更新贡献政策，明确要求所有代码必须由人类完成。知乎Linux 内核则在 7 月中旬由 Linus 本人亲自下场定了规矩：AI 和编译器一样是工具，不爽就 fork 走开。
同一件事，半年内逼出了至少三种解法。这才是最有意思的地方。
同一份 AI 补丁，三种命运
各家规则差异极大，我整理成一张对照表：
项目 | 立场 | 核心规则 | 背后的逻辑 |
|---|---|---|---|
GCC | 禁止 | “法律意义显著”（约 15 行+）的 LLM 代码一律不收，人改的也不收；AI 找 Bug、写测试可以 | 版权：GPL 的效力依赖版权 |
Zig | 全面禁止 | AI 生成、编辑甚至参与构思的代码都不收 | 质量与审查成本 |
OpenJDK | 禁止 | 甲骨文禁止 AI 生成代码进入项目 | 版权结构复杂（据分析） |
Rust | 限制+披露 | AI 可以问、分析、检查、评审，但不能"创造"；生成内容必须披露，且门槛比人类代码更高 | 治理协商：把潜规则写成明文 |
Go | 不承认 AI 作者 | 倾向不接受 AI 作为共同作者，代码必须有具体的人负全责 | 版权归属与工程责任 |
Linux 内核 | 宽松+标注 | AI 是工具，但 Signed-off-by 只能人签，用 Assisted-by 标注 AI 参与 | 责任到人 |
Debian | 投票中 | 全面禁止 / 责任共担 / 尽可能拒绝，三选一 | 社区治理实验 |
注意一个反直觉的事实：站得最硬的 GCC，理由恰恰不是"AI 写得烂"。这不关乎技术优劣，而是版权的"生死存亡"。微博
第一笔账：版权账
GCC 是 GNU 的旗舰项目，整个许可证体系建立在 GPL 之上，而 GPL 的法律效力完全依赖版权——你得先拥有版权，才能用 GPL 去约束别人。
问题来了：美国版权局在 2023 年已明确裁定，AI 生成的内容不受版权保护。知乎也就是说，一段 LLM 生成的代码进了 GCC，就是一段"无主代码"：项目方没法对它主张版权，GPL 在这段代码上等于失效。对靠版权立命的 GCC 来说，这不是代码质量好不好的一般问题，而是许可证体系的生死问题。
OpenJDK 的情况类似但更复杂。甲骨文对 OpenJDK 项目禁止 AI 生成代码。知乎它的代码库混着 GPLv2+CE、甲骨文的商业授权和 IBM、Red Hat 等公司的贡献，AI 代码的权属在这种结构里就是一颗雷。当然，"甲骨文的动机"目前只是分析文章的推测，官方没有公开完整解释，这一点要打个问号。
第二笔账：审查产能账
剩下的大项目，算的是另一笔账。Linus 在 7 月中旬的邮件列表里说了一句话，堪称这波争论的题眼。知乎
AI 降低了发现可疑代码、撰写报告、生成补丁的成本，却没有以同样的比例降低维护者验证、沟通、承担风险的成本。
翻译成人话：代码生成变便宜了，但把关变贵了。
数据都在印证这件事：
rust-lang/rust 仓库积压着约 1300 个未关闭的 PR。知乎过去一份打磨精致、测试齐全的 PR，能证明作者投入了时间、理解了代码；现在这些几分钟就能生成，"认真工作的痕迹"彻底贬值了。
curl 作者 Daniel Stenberg 2025 年就统计过：AI 生成的低质量安全报告约占提交量的两成，当年提交里最终被确认为真实漏洞的只有约 5%。知乎到了 2026 年，他观察到新变化——一眼假的垃圾报告少了，但"看起来更可信、必须认真验证"的报告在变多，单个报告消耗的时间反而更长。
Godot 维护者直言，大量"看起来像贡献"的内容涌入，消耗的是维护者判断"这个改动值不值得做"的时间。
所以 Rust 政策原文里有一句很关键的话：评审本质上是由一连串决策组成的。知乎AI 压缩的是写代码的成本，压缩不了"判断这件事该不该做、设计对不对、会不会留债"的成本。
顺带一提，治理结构也决定了规则长什么样：有"仁慈独裁者"的内核可以 Linus 一句话定规矩；甲骨文控制 OpenJDK，可以直接一刀切；Rust 没有拍板人，只能靠三千多条 Zulip 消息吵出一份"大家都有点不满意"的成文政策。知乎这份政策还特意被设计得比通过时更容易修改。规则的形状，其实是组织结构的投影。
给贡献者的行动手册
说点实际的。如果你打算给这些项目提交 AI 辅助的代码：
给 GCC 提交：AI 生成的代码别交，改过也别交。社区里有个 53 赞的回答说得很透——只要人还对自己的产出负责，就有审核校对的义务。知乎如果能被人看出是"基于 AI 的人为修改"，说明这段代码本身就带着低质代码的味道。用 AI 帮忙写测试、找 Bug 倒是被明确允许的。
给 rust-lang/rust 提交：记住那句总纲——可以问、分析、提炼、检查、建议、评审，但不能"创造"。公开提交的 LLM 内容必须披露；AI 生成的代码要通过，门槛比普通人类代码更高，还得满足"事先安排、非关键、测试充分"等条件；涉及 soundness（健全性）的改动基本是禁区，除非你本人就是该领域专家。另外千万别把评审意见复制给 LLM 再把回复粘回来——政策原文明说这是在浪费所有人的时间。
给 Linux 内核提交：AI 可以用，但三条铁律——AI 不能签 Signed-off-by（法律责任只能人背）；提交者必须真正审过每一行；用 Assisted-by 标签写清楚用了哪个模型。
给 Zig 提交：省省吧，连"参与构思"都算违规。
如果是自己的项目或公司内部仓库：内核这套"人签字、标来源、审到位"的三件套，是目前被验证过最稳的模板，可以直接抄。
争议的另一面：不是所有人都拍手
规则立起来了，社区却不是铁板一块。知乎相关问题的评论区里，有人直接留言"看不惯就 fork 一份搞全 AI 写"。知乎也有人把 GCC 称作"计算机系的最后一道城墙"，觉得这刀切得没毛病。维护者一侧的态度则更直接：以 ruff 等开源工具闻名的 Charlie Marsh（@charliermarsh）公开表态，“戴上维护者的帽子"看，rust-lang/rust 的 LLM 政策"非常周到且合理”——毕竟熬夜审 PR 的是他们，而被上千个 open PR 淹没的焦虑，只有维护者自己知道。知乎
三个值得持续关注的信号
Debian 的投票结果：这是第一个用正式投票机制处理 AI 代码的重量级项目。知乎三个提案分别代表"禁止派"“责任共担派”“尽可能拒绝派”，结果会直接影响其他社区跟进的方向。
LLVM 社区会不会表态：这波 GCC、Rust、Zig、内核都出牌了，但我检索到的公开讨论里，LLVM 还没有统一政策落地。作为编译器基础设施的"最大公约数"，它的动向值得盯。
Rust 承诺的后续数据：Rust 团队明说要跟踪——人们是不是真的在用 AI 做出有价值的贡献、会不会留下来。这份数据出来之前，所有关于"AI 代码到底是洪水还是红利"的判断都只是立场。
最后说个社区里流传的说法，我觉得挺妙：过去大家调侃 Rust 编译器是"折磨人类的严师"，现在 AI 写代码的时代来了，这台严格的编译器反而成了"监督 AI 的严格教练"——编译器开发者头一回和自己的作品站到了同一边。
这波规则重排，画掉的从来不是"用 AI"，而是"不用负责"。
