OpenJDK封杀AI生成贡献

甲骨文把AI挡在了OpenJDK提交入口之外

甲骨文近日再次向OpenJDK开发者明确：任何全部或部分由生成式AI产出的内容，都不得作为社区贡献提交。 禁令覆盖的范围不只是源代码，还包括GitHub Pull Request、PR描述、邮件沟通、Wiki页面、图片，以及Java Bug System（JBS）中的问题报告。

这不是一项只针对“AI写代码”的窄规则，而是一项针对AI生成内容来源的全面限制。 按照甲骨文给出的表述，只要内容由大语言模型、扩散模型或类似深度学习系统部分或全部生成，就不符合当前OpenJDK贡献要求。

截至2026年8月9日，这项规则仍被定位为临时政策，而不是最终版本。 OpenJDK在2026年4月初已经公布相关要求，近期甲骨文对项目组和开发者进一步通知后，再次引发关注。甲骨文表示，完整的AI贡献政策仍在制定中，将在“适当时候”提出。

禁止的是提交，不是私下使用

OpenJDK是Java平台标准实现的开源参考项目，其代码构成Oracle JDK以及多个主流JDK发行版的重要上游。 它并不是普通应用仓库：虚拟机、垃圾收集器、类库、加密实现和并发组件中的一个细小错误，都可能沿着下游发行版进入金融、云计算、电信和政企系统。

新规仍允许开发者私下使用AI理解、调试、评审和研究OpenJDK代码。 开发者可以让模型解释HotSpot实现、帮助定位崩溃原因，或者对一段补丁进行初步审查；真正的红线在于，模型输出不能进入正式贡献。

“AI辅助”与“AI生成”的边界，在这项政策下取决于最终提交物是否包含模型输出。 如果AI只是帮助开发者阅读代码，而补丁和说明由开发者独立完成，原则上不在禁令直接覆盖范围内；如果开发者复制、改写或拼接了模型给出的代码、文字或图片，这份贡献就存在AI生成内容。

OpenJDK的FAQ给出了一个非常严格的例子：100行AI生成代码中，即使人工修改了10行，剩余贡献仍然不得提交。 换句话说，人工润色不会自动“洗掉”生成来源，政策判断的是内容谱系，而不是人工编辑比例。

传统IDE功能并未被一并封禁，但工具底层是否使用深度学习非常关键。 拼写检查、语法检查、经典自动补全和确定性重构仍然可以使用，前提是这些功能不基于大语言模型或类似深度学习系统。现代IDE经常把规则补全、语义补全和生成式补全放在同一界面里，贡献者今后需要分清每项功能究竟由什么技术驱动。

三个理由：评审、安全和知识产权

甲骨文给出的第一个理由是，AI降低了生成补丁的成本，却没有同步降低维护者验证补丁的成本。 大语言模型最棘手的问题不是总会写出明显错误，而是能生成结构完整、命名合理、甚至附带测试，但在边界条件、并发语义或平台兼容性上存在缺陷的代码。

对于OpenJDK维护者而言，一份“看起来很对”的错误补丁往往比一份编译失败的补丁更昂贵。 前者需要评审者检查设计意图、运行测试、追踪平台差异，还要判断贡献者是否真正理解代码；后者通常在持续集成阶段就会暴露。AI可以在几分钟内批量生产补丁，但资深评审者的时间无法按同样速度扩张。

甲骨文给出的第二个理由是，JDK的基础设施属性决定了它不能接受普通应用项目的风险水平。 OpenJDK中的缺陷可能影响内存安全、沙箱边界、密码学实现、类加载机制和JIT编译行为。部分问题只会在特定CPU架构、垃圾收集器组合或极端并发条件下出现，单靠模型生成的单元测试很难覆盖。

甲骨文给出的第三个理由是，AI输出的知识产权归属仍存在法律不确定性。 Oracle Contributor Agreement（OCA）是Oracle用于接收外部贡献的贡献者协议，签署者需要确认自己有权向Oracle授予相关知识产权，并且这些权利不附带与项目分发冲突的限制。

生成式AI让OCA原本清晰的责任链变得模糊。 模型输出可能复现训练数据中的代码片段，也可能产生与现有实现高度相似的表达；与此同时，贡献者是否能够对纯AI生成内容主张完整权利，在不同司法辖区仍缺少统一结论。对甲骨文来说，先禁止、后制定细则，比接受一批来源无法证明的补丁再逐一处理风险更便宜。

代码、PR和邮件全部纳入，规则比多数项目更激进

OpenJDK新规最值得注意的地方，是它把协作过程本身也视为正式贡献。 很多团队只关心最终合并的代码是否由AI生成，但OpenJDK连PR描述、评审回复、邮件和Bug报告也纳入限制。这意味着让聊天机器人代写一封技术讨论邮件，理论上也可能违反当前政策。

这项规则本质上不是代码质量规范，而是内容来源规范。 一段AI生成代码即使完全正确、性能更好、测试齐全，也不能因此获得例外；一段人工编写但质量较差的代码，则仍可进入正常评审流程。甲骨文选择的不是“根据结果验收”，而是“先按生产方式设门槛”。

OpenJDK与同属Oracle生态的GraalVM采取了截然不同的路线。 GraalVM允许编码助手参与贡献，并将确保合法性、正确性和可维护性的责任放在贡献者身上；OpenJDK则认为现阶段仅靠贡献者担保不足以覆盖风险。

| 对比维度 | OpenJDK临时政策 | GraalVM编码助手政策 | |---|---|---| | AI生成代码 | 禁止提交，包括部分生成 | 允许，但贡献者承担责任 | | AI生成文本 | PR、邮件、Wiki、JBS报告等均禁止 | 原则上可以使用编码助手参与 | | 人工修改AI代码 | 修改部分内容后仍然禁止 | 重点审查最终贡献及责任归属 | | 私下理解、调试 | 允许 | 允许 | | 传统IDE功能 | 非LLM、非深度学习功能可用 | 通常允许 | | 知识产权处理 | 认为当前不确定性足以支持全面禁令 | 依赖贡献者承诺与现有协议 | | 政策状态 | 临时政策，最终规则尚未公布 | 已有相对开放的编码助手规则 |

同一家公司、同一份OCA，却出现两种政策，说明知识产权并不是唯一决定因素。 如果OCA本身必然要求全面禁止AI内容，GraalVM就很难采取开放路线。真正拉开差异的，更可能是两个项目对系统关键性、评审资源和社区风险承受能力的不同判断。

这项禁令有效，但执行难度不小

OpenJDK的保守选择有现实合理性，尤其适合一个维护周期以十年计的基础软件项目。 AI生成补丁的边际成本接近于零，而核心维护者数量有限；如果仓库被大量低成本尝试淹没，最先被消耗的不是算力，而是理解虚拟机和类库内部机制的专家时间。

不过，这项政策最明显的问题是可验证性不足。 从目前公开信息看，甲骨文没有同步公布AI内容检测器、相似度阈值或自动扫描机制。代码不像图片那样容易留下生成痕迹，而“这段循环是开发者自己写的，还是模型建议后重写的”通常无法仅凭结果判断。

AI检测也很难成为可靠执法工具。 不同模型、提示词和人工编辑会显著改变输出风格，误报可能把熟练开发者的规范代码判为AI生成，漏报则会让经过改写的内容顺利通过。对OpenJDK来说，这项规则短期内更像依赖贡献者诚信、评审质询和责任追溯的社区契约，而不是可以自动执行的技术防线。

规则对非英语贡献者和首次参与者也可能产生额外摩擦。 一些开发者会使用模型润色英文PR说明或整理Bug复现步骤，而这些场景并不直接降低代码质量，却同样被当前禁令覆盖。甲骨文选择了一条边界清晰但颗粒度较粗的路线，减少了维护者判断成本，也牺牲了部分低风险AI辅助场景。

对OpenJDK贡献者意味着什么

OpenJDK贡献者现在需要管理的不只是代码质量，还包括内容来源。 在最终政策出台前，最稳妥的做法是把生成式AI限定在私人分析环境中，不要直接复制模型输出到仓库、PR、邮件、Wiki或JBS。

开发者可以继续用AI做“旁听者”，但不应让它成为提交物的“代笔者”。 例如，让模型解释一段GC日志或列出可能的排查方向通常没有问题；让模型直接生成补丁、提交说明或Bug报告，再做少量修改后提交，则会撞上明确禁令。

贡献者还应检查IDE中默认开启的智能功能。 同一个“自动补全”按钮背后，可能是基于语法树的确定性建议，也可能是云端大模型生成。对于准备向OpenJDK提交内容的开发环境，关闭生成式补全并保留必要的工具配置记录，可以减少来源争议。

企业团队则需要把AI使用规则前移到开发流程，而不是等PR提交后再追问。 如果工程师在内部开发阶段混用了生成式代码，后续很难精确证明哪些行由人编写、哪些行来自模型。对于计划向上游回馈的补丁，独立分支、工具白名单和贡献记录会比事后清理更可靠。

甲骨文踩下的是刹车，不是倒车

OpenJDK的禁令不等于甲骨文否定AI编程，而是拒绝在责任链尚未清晰时让AI成为上游作者。 政策明确保留理解、调试、评审和研究用途，说明甲骨文接受AI作为辅助工具，只是不接受它直接进入贡献记录。

这项临时政策对其他基础软件项目具有示范意义。 Linux内核、编译器、数据库和密码学库都面临类似矛盾：生成式AI可以帮助新人理解复杂系统，也能以极低成本制造维护者必须认真核查的补丁。项目越关键、维护周期越长，就越可能优先保护评审带宽和责任可追溯性。

我们的判断是，OpenJDK的全面禁令短期内合理，但不适合作为永久方案。 一刀切可以在法律和评审机制尚未成熟时止损，却无法长期解决AI已深度嵌入IDE、搜索和代码审查工具的现实。更可持续的规则可能是强制披露、限定使用场景、要求贡献者解释补丁、提高测试门槛，并对安全敏感模块采用更严格限制。

真正决定政策能否持续的，不是能不能识别AI文风，而是能不能建立清晰的责任链。 当贡献者能够披露所用工具、证明代码来源、解释实现逻辑并对后果负责时，OpenJDK才有可能从全面禁止转向分级管理；在此之前，甲骨文选择把风险挡在仓库之外。

参考来源

• IT之家：甲骨文OpenJDK项目新规，不允许提交AI生成代码 —— 报道甲骨文对OpenJDK社区贡献的最新限制，以及允许与禁止的AI使用范围。
• OpenJDK GitHub组织主页 —— OpenJDK在GitHub上的官方项目集合，可用于查看各组件仓库、提交记录和Pull Request协作情况。