今年编译器圈最戏剧性的对照，在半年之内完成了闭环。
2 月，Anthropic 让 Claude 用纯 Rust 写了一个零依赖的 C 编译器，开源在 claudes-c-compiler 仓库，README 直接写明它能把 Linux 内核编译到可启动。7 月，编译器世界里最老资格的项目 GCC 则在官网挂出 AI 贡献政策页，指导委员会正式接受了 AI 政策工作组的建议。The GCC steering committee has announced that it has accepted an AI contributions policy recommended by the GCC AI policy working group。LWN 一边是 AI 开始写编译器，一边是编译器开始拒 AI。我一开始也觉得 GCC 太保守，但把官方政策页、LWN 报道和上百条评论区争论、知乎和微博的讨论全部读完之后，我发现中文讨论里“GCC 全面封杀 AI”的转述，把这件事最重要的细节都转丢了。
先说前情：AI 写的那个编译器，经不经得起细看
想理解 GCC 的选择，得先看看“AI 写的编译器代码”在显微镜下长什么样。知乎那个 CCC 编译器问题下，最高赞回答做了一次拆机式体检：编译产物 8,622KB，而手写 C 编译器通常只有三四百 K；开源后第一个 issue 就是 HelloWorld 跑不起来。毕竟手写的 c 编译器一般也就三四百 K。然后第一个 issue 里 HelloWorld 确实跑不了：原因我分析了下，是硬编码了 gcc 目录。知乎
问题清单还不止这些：DATE、TIME 被锁死，_Float128 在 x86-64 上被定义成 long double，__builtin_cpu_supports 永远返回 0，一部分 fortify 函数直接转发给 glibc 运行时去执行，类型检查甚至放行 int x = “fucking yes” 这种语句。而最致命的是覆盖率报告：ARM 后端整整一页文件，函数、行、分支覆盖率清一色 0.00%，也就是说这整套后端的代码几乎从未真正被执行过，“支持 ARM/RISC-V” 停留在“我跑的测试过了”的层面。
把这份体检报告放在这里，不是为了嘲笑 CCC。它真正回答的是一个更深的问题：当一份编译器代码没有任何一个人真正为之负责时，它能“跑通”到什么程度，又敢被用到什么程度。
GCC 政策被误读最多的部分：拒的不是“用 AI”
先看 GCC 官网政策页（最后更新 2026-07-29）的核心条款，第一段第一句就是：For the time being, the GNU Compiler Collection (GCC) policy is to decline any legally significant contributions which include LLM-generated content or are derived from LLM-generated content。GCC官网 “法律意义显著”借用了 GNU 维护者指南的标准，即大约 15 行代码或文本。GCC 指导委员会正式宣布 AI 贡献政策：拒绝任何“法律意义显著”（约 15 行以上）的 LLM 生成代码，但允许 AI 辅助找 Bug 或生成测试用例。微博
但被转述时经常消失的，是政策里“不拒”的那一半：15 行以下的法律意义不重大的小修改，只要明确标注就可以接受；LLM 生成的测试用例即使超过 15 行，维护者也可以接受；从其他项目导入的代码（比如 libsanitizer）不受此政策约束；用 AI 做研究、分析、找 bug、报 bug、辅助补丁审查、调试，只要输出不进入贡献，统统不管；翻译、拼写校正、读屏这类个人用途同样不受限。
所以知乎上“基于 AI 代码人改的都不行”这个标题，对超过 15 行的部分是对的——“derived from” 意味着你把 AI 初稿实质性重写一遍，依然算派生，依然拒。但把它概括成“GCC 全面封杀 AI”就错了：它拒的是“把 AI 的输出放进代码库”，不是“你用 AI”。红线画在输出的去向上，不是工具上。政策还留了个口子：预计会随社区和 GNU 整体立场演化，最迟 2027 年初复审，它不是一块刻死的碑。
GCC 为什么这么刚，社区又为什么吵到现在
第一层逻辑是法律。GPL 的效力完全建立在版权之上，而 AI 生成内容是否受版权保护，在多国法律趋势里尚无定论。如果一批版权状态不明的代码混进代码库，GCC 对商业软件的 copyleft 约束力可能被从内部掏空。这不是技术保守，是在法律未定区主动选最保守路线。
第二层是问责。政策页里比拒绝条款更关键的是这句：All contributions must be submitted by a human who understands the changes and is prepared to answer questions about them。GCC官网 提交者必须理解改动并准备好回答问题，合并决定必须由人做出，Signed-off-by 只能由人签署，LLM 不允许直接向仓库提交。GCC 要保的不是“手写纯度”，而是一条问责链：三年后某段代码出了问题，得有人站出来说“这是我写的，我来修”。
第三层是现实。AI agent 流行之后，老牌项目被大量自动刷的 PR 淹没，操作者甚至不看代码，只为刷简历。haproxy 维护者 wtarreau 在 LWN 评论区说，他不在乎贡献者用 AI、用书还是用计算器，他在乎的是代码出问题那天，这个人还在不在。What matters to me as a maintainer is that the day a problem is reported with that piece of code, that person is available to help。LWN
反对阵营的理由同样不弱。评论区的 quotemstr 认为，不可执行又只惩罚诚实人的规则，只会催生隐蔽使用和规则蔑视。systemd 的 Luca Boccassi 更直接：在 Opus 4.8、GPT 5.5 这个级别的模型手里，AI 辅助产出已经无法区分，所以 systemd 大约一个月前废除了提交标注“Co-developed-by”的要求，因为标注已完全失去意义。in systemd we simply scrapped the requirement to annotate commits with "Co-developed-by" a month ago or so, as it became completely pointless。LWN 还有人担心政策制造猎巫气氛、吓退新贡献者，主张“按贡献质量判断，而不是按工具判断”。
有意思的是，两派在一件事上完全一致：没人想要 slop 进仓库。分歧在于“流程标注”在 2026 年到底还可不可执行、成本由谁扛。GCC 收紧标注，systemd 放弃标注，这两条路线的后续结果，是未来一两年开源世界最值得观察的自然实验。
这件事和你有什么关系
如果你准备给 GCC 提补丁：别把 AI 输出写进贡献，包括“AI 出初稿、我实质性重写”（派生也算）；15 行以下的小修改老实标注 Assisted-by；测试用例是目前对 AI 最友好的入口；提交前先问自己“这个补丁任何一行被追问，我答得上吗”，这个问题的答案比任何规则都好使。
如果你还给别的项目贡献代码：先翻它的 AI 政策页再动手。这波从 GCC 开始，但大概率不会在 GCC 结束；DCO、Assisted-by 这类问责标记会不会扩散，每个项目都在做自己的选择，守规矩的成本永远比 reputation 翻车低。
如果你只是想看风向：记住三个观察信号。一是会不会出现“AI 友好”fork（LWN 评论区已有人押注）；二是 GCC 最迟 2027 年初的政策复审怎么改；三是 GNU 整体是跟进还是各项目各自划线。这三个问题的答案，会比一百场线上吵架都有说服力。
结尾
回到开头那个对照。那个 8,622KB 的 ccc.exe 证明 AI 已经能“写出”一个编译器；GCC 的政策页提醒所有人，在开源世界里，“写出代码”从来不是最难的部分，最难的是三年后这段代码出了问题，还有人站出来说一句“这是我写的，我来修”。
AI 现在最缺的，恰恰是说这句话的资格。
