OpenJDK 和 GCC 拒收 AI 生成代码：开源社区担心的不是作弊，而是谁来承担审查成本
作者：林岚｜OC 开发者生态编辑
林岚
据 OpenJDK 临时政策 和 LWN 对 GCC 政策的报道，两个基础软件社区都开始限制 AI 生成贡献。OpenJDK 暂时禁止提交由大语言模型、扩散模型等生成的代码、文本和图像；GCC 则拒绝包含或衍生自 LLM 输出的“具有法律重要性”的贡献，同时为部分测试用例保留例外。
一句话结论：这些政策不是宣判 AI 编程无用，而是维护者在来源权利、补丁质量和审查容量都不确定时，把举证责任留给提交者；生成代码很便宜，验证代码依然昂贵。
OpenJDK 的规则覆盖范围很广，不只是源代码，还包括拉取请求、邮件、Wiki 和问题追踪器中的生成内容。开发者可以私下用 AI 理解、调试、研究和审查代码，只要不把模型输出直接作为贡献提交。项目还计划在 Skara 创建的拉取请求中加入确认框，让提交者声明符合政策。
GCC 的处理更接近版权贡献框架。政策使用 GNU 维护者指南中“具有法律重要性”的概念，通常约为 15 行代码或文本，但这不是普遍适用的版权法律门槛，也不是“14 行永远没问题”。它只是社区判断何时需要明确权利保证的操作口径。维护者可酌情接受 AI 生成的重要测试用例。
为什么基础项目格外谨慎？OpenJDK 和 GCC 位于大量生产系统底部，一处细微错误可能影响编译器、运行时和供应链。AI 很容易生成结构完整、解释充分、测试看似齐全的补丁，却可能误解未文档化约束。维护者需要花更多时间证明它错在哪里，而提交者只需几秒再生成一版。
知识产权也是现实问题。多数贡献协议要求提交者拥有足够权利并能授予项目许可。模型输出是否复现训练代码、用户能否对输出作完整权利保证，仍存在法律争议。社区无法可靠检测每一段 AI 代码，只能要求声明，并在出现明显迹象时要求移除。
规则也会面临执行难题。编辑器自动补全、重构、拼写检查与 LLM 生成之间的边界越来越模糊；人类大幅修改模型草稿后，怎样算“衍生”也不容易统一。临时政策的意义是先保护维护流程，再根据经验修订，而不是假装一次就能定义未来所有工具。
关键事实
- 来源：OpenJDK 官方临时政策、GCC 指导委员会政策及 LWN
- 涉及项目：OpenJDK、GCC
- 允许用途：私下理解、调试、研究和审查；GCC 可为部分测试用例设例外
- 主要风险：审查负担、安全与维护性、知识产权保证
OC 判断
问题不在开发者有没有用 AI，而在谁为最终补丁负责。成熟开源项目依靠有限的维护者时间运行，不能让无限生成能力把验证成本外包给社区。更可持续的规则应要求披露工具、提供可复现测试、缩小补丁范围，并让提交者能够解释每一处改动。
为什么重要
- 对开发者：向这些项目贡献前必须阅读项目级政策，不能把 Copilot 或 Agent 输出直接提交。
- 对维护者：声明机制只能降低风险，仍需要控制贡献规模和要求可复现证据。
- 对企业：内部 AI 编程规范也应明确代码权利、审查责任和高风险组件禁区。
评论
围绕这篇文章补充信息、提出问题或分享观察。