甲骨文OpenJDK新规：禁止提交AI生成代码

2026年8月9日至10日，IT之家、IT时代网等媒体先后报道：甲骨文（Oracle）已通知OpenJDK开发者，项目组不再接受AI生成的代码。甲骨文的表述相当直接——OpenJDK社区贡献内容不得包含由大语言模型、扩散模型或深度学习系统生成的内容。在AI编程助手几乎成为开发者标配的2026年，全球最重要的Java开源项目之一选择明确说「不」，这件事的信号意义远大于规则本身。

新规到底禁了什么

先把原话摆出来。甲骨文的表述是：「OpenJDK 社区贡献内容不得包含由大语言模型、扩散模型或深度学习系统生成的内容。此处的『内容』包括但不限于代码、文本、PR、电子邮件沟通、维基和 Bug 报告。」

「内容」的范围铺得很开

注意，代码只是其中一项。文本、Pull Request 描述、电子邮件沟通、维基页面、Bug 报告，统统算在内。也就是说，你不能用大模型帮你润色一段 PR 说明，也不能让它替你写一封提交给邮件列表的说明信。这个覆盖面比大多数人预想的要宽。

分界线画在「输出物」而不是「工作方式」

这是整份新规最值得注意的一点。甲骨文明确说明：开发者仍然可以私下使用AI工具审查代码、调试问题，或者做OpenJDK项目相关的研究。禁的不是你怎么干活，而是你交出来的东西。换句话说，AI可以当你的私人顾问，但不能当共同署名的作者。

甲骨文给出的三个理由

官方解释中，新规主要出于三方面考虑。

第三条其实最现实。开源项目最稀缺的资源从来不是代码，而是有能力做深度评审的人。当生成侧的成本趋近于零、审核侧的成本却纹丝不动，供需就会崩掉。

这不是突然出现的政策

回溯时间线会发现，这条规则早有铺垫。2026年4月初，OpenJDK管理委员会就批准了一项临时政策，广泛禁止生成式AI内容。当时的政策FAQ给出了一个非常硬的判定标准：即使一份100行的AI生成代码你只修改了其中10行，也不能提交，因为这份贡献仍然包含AI生成内容。

同时，政策也留了口子——允许使用「编辑器或IDE中的拼写检查、语法检查、自动补全和重构功能」，前提是这些工具不是基于大语言模型或类似深度学习系统。传统的静态分析和重构工具，依然可以放心用。

同属Oracle，GraalVM态度却相反

有意思的是，两个由Oracle支持、彼此相关的项目，对生成式AI贡献发布了相反的政策：OpenJDK禁止，而GraalVM的Coding Assistants政策则允许这类贡献。两个项目的贡献者签署的还是同一份 Oracle Contributor Agreement（OCA），用于处理知识产权相关事项。

同一家公司、同一份贡献者协议、两条相反的路线。这说明什么？说明连Oracle内部对「AI生成代码能不能进开源仓库」这个问题，也还没有形成统一答案。它取决于项目的性质：JDK是数以亿计设备的底层基座，容错空间极小；GraalVM相对年轻，实验色彩更浓。

对开发者和企业意味着什么

• 贡献开源要看清项目政策。同一家公司旗下项目规则都可能相反，提交前先读CONTRIBUTING，别凭习惯办事。
• 「AI辅助」和「AI生成」要分清。用AI理解代码、定位Bug、做背景研究，多数项目并不禁止；把模型输出直接粘进补丁，性质完全不同。
• 企业内部要建立可追溯机制。如果团队既用AI提效又要向上游回馈代码，就需要留存来源记录，否则合规声明无从签起。
• 评审能力正在变成核心资产。写代码的门槛在降，判断代码好坏的门槛在升，这个剪刀差会持续拉大。

一点判断

把这件事放在更长的时间轴上看，它其实不是「反AI」，而是开源世界在给AI补上一道责任边界。开源协作的底层逻辑是信任：贡献者对自己交出的每一行代码负责，维护者据此建立审查预期。当代码可以由模型批量生成，而模型不承担任何法律与道德责任时，这条信任链就出现了断点。OpenJDK的做法是先把断点堵上，等治理工具成熟再谈松绑。保守，但对基础设施而言，保守往往是对的。

FAQ

Q1：这条规则从什么时候开始执行？

甲骨文于2026年8月9日前后正式通知OpenJDK开发者。更早的铺垫是2026年4月初OpenJDK管理委员会批准的临时政策，本次通知是该方向的进一步明确和落实。

Q2：我用Copilot类工具帮我看代码、查Bug，还能给OpenJDK提交贡献吗？

可以。甲骨文明确说明，开发者仍可私下使用AI工具审查、调试代码以及进行OpenJDK项目相关研究，只是一切AI生成内容不得提交至仓库。分界线在于最终交付物是否包含模型生成的内容。

Q3：如果只是改了AI生成代码的一小部分，算不算违规？

算。政策FAQ明确指出，即使100行AI生成代码中只修改了10行，也不能提交，因为该贡献仍然包含AI生成内容。这是一条不看比例的判定标准。

Q4：为什么GraalVM可以，OpenJDK不行？

两个项目都由Oracle支持、都使用同一份Oracle Contributor Agreement，但发布了相反政策：OpenJDK管理委员会禁止生成式AI贡献，GraalVM的Coding Assistants政策则允许。差异主要来自项目定位与风险承受度的不同，也反映出行业对该议题尚无统一共识。