GCC 拒绝 AI 生成代码贡献，开源社区划定责任红线

GCC 编译器集合（GCC）近日明确了一项社区政策：今年将拒绝任何由大语言模型 Agent 生成、且具有「法律意义」的代码贡献。这一决定在开源社区引发广泛讨论，也折射出生成式 AI 浪潮下传统软件协作模式正在面临的根本挑战。

政策核心：明确区分「法律意义」代码与一般贡献

GCC AI 政策工作组提交的方案近日获得指导委员会认可，并已写入项目文档。文档中的关键条款包括：

• 拒绝任何包含 LLM 生成内容，或基于其衍生而来的、具有法律重大意义的贡献；
• 维护者可以接受法律意义不重大的 LLM 贡献，但必须满足常规代码贡献要求，并明确标注使用了 LLM；
• 测试用例作为例外，全部或部分由 LLM 生成、具有法律意义的测试贡献可被接受。

这一政策延续了 GNU 项目对 AI 贡献的既有审慎态度。所谓「具有法律意义的代码」，主要指可能影响版权归属、许可证合规或法律责任的核心代码修改。

担忧背后：AI 代码真正的风险是责任消失

GCC 是支撑 Linux 发行版、嵌入式系统以及大量基础软件的核心开源项目。社区认为，传统开源开发依赖一个核心原则：提交者不仅是代码作者，也是责任承担者。一个开发者提交 Patch，意味着他阅读过代码、理解逻辑，并愿意接受维护者的审查与追问。

但 AI 时代出现的新模式是：开发者用自然语言让 LLM 生成代码，简单检查后便提交。如果维护者追问「为什么这样设计」「是否考虑边界情况」而提交者无法回答，整个开源协作链条就会断裂。换言之，AI 生成代码的问题不只是质量可能不好，更在于代码背后的工程判断可能根本不存在。

其他社区路径：Linux 立规、Zig 全面禁止

GCC 并非唯一面临这一抉择的项目。Linux 之父 Linus Torvalds 并不反对 AI 本身，他认可 AI 在发现 Bug、提升效率方面的作用，但反感大量未经理解的报告与代码涌入，并多次呼吁「不要做那种随手丢一个没有理解的报告就走人的人」。经过内部讨论，Linux 内核社区确立了明确规则：

• AI 可以辅助开发，但提交者必须理解代码并承担最终责任；
• AI 不能替代 Developer Certificate of Origin（DCO）的签署者；
• 如使用 AI 工具，可通过 Assisted-by 标签注明工具与模型信息。

Zig 编程语言社区则走向更严格的路线——明确禁止 AI 生成代码贡献。维护者认为，审核 AI 生成 Patch 的成本往往高于自行实现；对小型项目而言，维护者精力一旦被低质量提交占用，将难以为继真正重要的功能开发。

开源的底线：可信任的代码

过去数十年，开源世界运转依赖一个简单共识：代码背后必须有一个真实的人——无论他来自企业还是独立开发者——他需要理解自己提交的代码，能解释设计选择、回应社区 Review，并承担相应责任。LLM 的出现正在挑战这一基础假设。

GCC 的选择表明，对于编译器、操作系统、数据库等承载数字世界运行的核心基础设施，代码数量从来不是最重要的指标。真正重要的，是代码背后的理解、责任与可信任性。AI 可以成为开发者的新工具，但在开源世界里，最终被接受的，仍然必须是有人愿意为它负责的代码。