作者：林岚｜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 编程规范也应明确代码权利、审查责任和高风险组件禁区。

参考来源

• OpenJDK Generative AI Interim Policy
• GCC steering committee announces AI policy
• GCC AI policy working group
• GNU maintainer guidelines