GCC禁止AI生成关键代码贡献

AI 编程似乎正在进入一个略显尴尬的节点。一面是 Claude Code、Cursor、GitHub Copilot 这些工具不断刷新着开发者的想象空间，越来越多的程序员开始习惯让 AI 去写函数、修 Bug、甚至生成完整的模块。另一面，开源社区却不得不面对一个现实层面的拷问：如果一段代码主要是由大模型生成的，提交者只是复制粘贴，那这算谁的贡献？出了事，又该谁来负责？

最近，GNU 编译器集合（GCC）社区就因为这个话题引发了一场不小的讨论，最终的倾向，是采取更加谨慎的态度——

换言之，GCC 以后不会再接受那些由 AI 生成，且可能影响版权归属、许可证合规或法律责任的核心代码修改。简单直接，但背后是深思熟虑的判断。

GCC 的忧思：AI 代码最大的风险不是错误，而是责任链条的断裂

GCC 不是一个小项目，它是全球最重要的开源编译器之一，支撑着大量 Linux 发行版、嵌入式系统和基础软件生态。它的任何一个决策，都可能牵动整个开源基础设施的神经。

不久前，GCC AI 政策工作组提交了一份 AI 使用政策建议，获得了 GCC 指导委员会的认可，并最终对外公布。这份政策的核心内容，通过一份原始 HTML 提交写入了项目文档，其中几个关键点值得关注：

这一政策基本延续了 GNU 现有对 AI/LLM 贡献的限制态度。那么，为什么这么规定？

因为传统开源开发依赖一个很朴素的逻辑：提交代码的人，不只是代码的作者，更是责任的承担者。过去，一个开发者提交一个 GCC Patch，意味着他读过代码，理解修改的逻辑，并愿意接受维护者的审查和追问。

但 AI 时代出现了一种新的提交模式：开发者用自然语言指令让 LLM 生成代码，自己简单检查一下，就提交了 Patch。问题随之而来：如果维护者追问“为什么这里这样设计？”“这个优化是否会影响其他架构？”“这个 Bug 修复是否考虑了边界情况？”——提交者答不上来。那么，整个开源协作的信任链条，就出现了断裂。

AI 生成代码的问题，不只是“代码质量可能不好”这么简单——更深层的隐患，是代码背后的工程判断可能压根不存在。

其他开源社区的做法：Linux 定规则，Zig 全面禁止

GCC 不是第一个遇到这个问题的项目。过去一年里，大量开源社区都发现，生成式 AI 正在制造一种新的贡献模式：大量低成本、低质量的 Pull Request。对大型项目来说，最大的成本从来不是写代码，而是维护者审核代码。

Linux 内核社区对此感受尤其深刻。Linus Torvalds 本人对 AI 的态度其实很明确——他不反对 AI，甚至还认为它可以帮助发现 Bug、提高效率。但他反感的是：有人拿 AI 大规模生成无价值的问题报告，或者提交未经充分验证的代码，白白增加维护者负担。他说过不止一次——不要做那种“随手丢一个没有理解的报告就走人”的人。

经过内部讨论，Linux 内核制定了一套清晰的规则：AI 可以辅助开发，但提交者必须理解代码，并承担最终责任；AI 不能替代 Developer Certificate of Origin（DCO）的签署者。如果 AI 工具参与了贡献，可以通过 Assisted-by 标签注明工具和模型信息。

不过，比起 GCC 和 Linux 的谨慎开放，有些项目选择了更严格的路线。例如 Zig 编程语言社区，就明确禁止了 AI 生成代码的贡献。Zig 维护者的理由很直接：大量 AI 生成的 Patch 会浪费核心维护者的时间，因为审核这些代码的成本，往往比他们自己重新实现还高。对于一个小型开源项目来说，维护者数量有限，如果每天面对大量的 AI 生成提交，最终可能连真正重要的功能都无暇顾及。

开源需要可信任的代码支撑

AI 的爆发式发展，毫无疑问在加速重构软件开发的方式。但过去几十年，开源世界能够持续运转，依赖的是一个简单而重要的共识：代码背后必须有一个真实的人。

这个人可能来自企业，也可能是一名独立开发者，但他需要理解自己提交的代码，能够解释设计选择，回应社区 Review，并承担由此带来的责任。

LLM 的出现，正在挑战这个基础假设。GCC 的选择说明，基础软件领域并不会简单拥抱所谓的“AI 编程革命”。对于编译器、操作系统、数据库这些承载着整个数字世界运行的核心基础设施而言，代码数量从来不是最重要的指标。

真正重要的，是代码背后的理解、责任，以及可信任性。AI 可以成为开发者的新工具，但在开源的世界里，最终能被接受的，仍然必须是有人愿意为它负责的代码。