AI 编程似乎正陷入一个微妙的尴尬境地。一方面，Claude Code、Cursor、GitHub Copilot 等工具正重塑开发流程，越来越多程序员依赖 AI 编写函数、修复 Bug，甚至生成完整模块。但另一方面，开源社区却面临一个现实难题：如果代码主要由大模型生成，而提交者只是简单复制粘贴，那么这究竟算谁的贡献？又该由谁承担责任？
近日，GNU 编译器集合（GCC）社区就 AI 生成代码的问题展开热议，并倾向于采取更为谨慎的态度：今年将不再接受任何由 AI 或大语言模型 Agent 生成的“具有法律重要性”的代码贡献。换言之，GCC 将不再接纳那些由 AI 生成且可能影响版权归属、许可证合规性或法律责任的核心代码修改。
作为支撑 Linux 发行版、嵌入式系统及基础软件生态的重要项目，GCC 一直备受关注。此前，GCC AI 政策工作组提交了一份 AI 使用建议，经指导委员会批准后对外公布。新政策明确写道：“目前 GCC 的政策是：拒绝任何包含 LLM 生成内容，或基于 LLM 内容衍生而来的、具有法律重大意义的贡献。”“维护者可接受由 LLM 生成且法律意义不重大的贡献，前提是满足常规要求并明确标注 AI 使用情况。”“例外情况是，维护者可接受由 LLM 生成的、具有法律重大意义的测试用例。”这一政策基本延续了 GNU 对 AI/LLM 贡献的限制态度。
为何制定如此严格的规定？传统开源开发的核心原则在于：提交代码的人不仅是作者，更是责任承担者。过去，开发者提交 GCC 补丁意味着他们已阅读代码、理解修改逻辑，并愿意接受维护者的审查与追问。然而，AI 时代催生了一种新的提交模式：开发者仅用自然语言指令让 LLM 生成代码，经简单检查后便直接提交。一旦维护者质问：“为何这样设计？”“该优化是否影响其他架构？”“Bug 修复是否考虑了边界情况？”提交者若无法作答，开源协作体系便会断裂。AI 生成代码的隐患，不仅在于质量可能不佳，更在于代码背后可能缺乏真正的工程判断。
这并非 GCC 首次面临此类问题。过去一年，许多开源社区发现生成式 AI 正在制造一种低成本的新贡献模式：大量 Pull Request。对大型项目而言，最大的成本往往不是写代码，而是维护者的审核时间。Linux 内核社区对此感触尤深。Linux 之父 Linus Torvalds 对 AI 态度明确：他并不反对 AI 辅助开发，认为其有助于发现 Bug、提升效率，但他反感有人利用 AI 大规模生成无价值报告或提交未经验证的代码，以此增加维护者负担。他曾多次呼吁：“不要做那种‘随手丢一个没有理解的报告就走人’的人。”随后，Linux 内部制定了明确规则：AI 可辅助开发，但提交者必须理解代码并承担最终责任，不能替代 DCO（开发者原始证书）签署者。此外，若 AI 工具参与贡献，需通过 Assisted-by 标签注明工具和模型信息。
相比之下，Zig 编程语言社区则采取了更为严厉的“一刀切”策略，明确禁止 AI 生成代码贡献。Zig 维护者认为，大量 AI 生成的补丁会严重浪费核心维护者的时间，因为审核成本往往高于人工重写。他们担忧，对于维护者有限的小型项目，若每天面对海量 AI 提交，将无法继续维护真正重要的功能。
开源世界需要可信任的代码支撑。AI 的爆发式发展无疑正在加速软件开发方式的重构，但过去几十年开源能持续运转，依赖于一个简单而重要的共识：代码背后必须有一个真实的人。这个人可能来自企业，也可能是独立开发者，但他需要理解代码，能解释设计选择，回应社区审查，并承担相应责任。LLM 的出现，正在挑战这一基础假设。GCC 的选择表明，基础软件领域并不会简单拥抱所谓的“AI 编程革命”。对于编译器、操作系统、数据库等承载数字世界运行的核心基础设施而言，代码数量从来不是最重要的指标。真正重要的是代码背后的理解、责任与可信任性。AI 可以成为开发者的新工具，但在开源世界里，最终被接受的，仍然必须是有人愿意为它负责的代码。