一条几乎没有回旋余地的禁令

Oracle 是开源 Java 项目 OpenJDK 的企业赞助方。近期，OpenJDK 管理委员会批准了一份关于生成式 AI 的临时政策，措辞相当直接：

OpenJDK 社区的贡献不得包含由大语言模型、扩散模型或类似深度学习系统部分或全部生成的内容。这里的内容包括但不限于 OpenJDK 代码仓库、GitHub 拉取请求、电子邮件、维基页面以及 Java 缺陷系统条目中的源代码、文本和图片。

政策同时留了一道口子：贡献者仍可以私下使用这类工具来理解、调试和评审 OpenJDK 的代码及其他内容，也可以用于相关研究，前提是不把工具生成的内容提交上去。

配套的问答部分把边界划得更细。如果用生成式 AI 写了 100 行代码，自己再改掉其中 10 行，这份贡献依然不能提交，因为它仍然“部分包含”AI 生成内容。编辑器和集成开发环境里的拼写检查、语法检查、自动补全和重构功能可以继续使用，条件是它们不基于大语言模型或类似的深度学习系统。为了让规则落地，OpenJDK 计划改造自动化评审系统 Skara，在每个拉取请求正文中加入一个复选框，提交者必须勾选确认自己的贡献符合该政策。

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

官方给出的顾虑有三层。

第一是评审负担。生成式 AI 天然擅长批量产出看似合理的代码和看似合理的测试，但这些代码可能本身就是错的，即便正确，也常常设计糟糕、难以维护。评审这类提交会迅速消耗本就紧张的人力。

第二是安全。OpenJDK 维护的 JDK 是 Java 平台的主要实现，支撑着全球企业、政府机构的关键业务系统。官方表述是：“安全性和安全保障至关重要。看似合理但实际错误的代码会让这些关键属性面临风险。”

第三是知识产权。Oracle 贡献者协议要求贡献者对每一份贡献拥有知识产权，并能无限制地把这些权利授予 Oracle。但多数生成式 AI 工具是在受版权和许可证保护的内容上训练出来的，输出可能包含侵权内容；至于使用者本人是否对 AI 生成的输出拥有知识产权，目前仍是多起诉讼正在争论的问题。

对内的说法完全相反

这套谨慎姿态，与 Oracle 对外宣传自家 AI 编码能力时的口径形成了鲜明落差。

联合创始人兼首席技术官 Larry Ellison 在 Oracle AI World 2025 上说过一段被广泛引用的话：

Oracle 写的那些代码，不是 Oracle 在写。是我们的 AI 模型在写。我们只需要告诉模型希望这个程序做什么，AI 就会拿出一套分步流程去实现。流程不是我们写的，我们只声明意图，由模型写出那套分步流程，也就是通常所说的计算机程序。

今年早些时候，联席首席执行官 Mike Sicilia 也表示，如果不采用 AI 编码工具，这些工具将构成威胁，但公司正在快速采用，“在 Oracle 内部使用 AI 编码工具，让更小的工程团队能更快地为客户交付更完整的方案”。今年 6 月裁减 21000 个岗位时，公司在声明中同样提到，AI 技术在各项业务中的部署已经并可能继续导致人员规模缩减。

科技媒体 The Register 直言不解：既然 AI 生成的代码适合放进 Oracle 自家产品，为什么不适合作为 OpenJDK 的贡献？该媒体已就此向 Oracle 提出询问。

值得一提的是，同属 Oracle 体系的 GraalVM 走了另一条路。这个由 Oracle Labs 主导、不受 OpenJDK 管理委员会管辖的项目，明确允许贡献者使用 AI 编码助手，只是要求提交者对整份贡献负责——必须能够解释、辩护并维护相关改动，否则贡献可能被拒。两个项目签署的是同一份贡献者协议，结论却完全相反。

时间点也不算轻松

这场争议出现的时机对 Oracle 而言并不舒服。公司表示未来一年将投入 700 亿美元扩建数据中心，高于 2026 财年（截至 5 月）的 557 亿美元。评级机构标普随后将其信用评级下调至 BBB-，仅比垃圾级高出一档，理由是这些投资的盈利路径尚不明朗。Oracle 正在大举借债支撑建设计划，并接受负向现金流；近期其信用违约互换利差走阔，意味着为其债务违约投保的成本正在上升。

在这样的背景下，公开表达对 AI 可靠性的疑虑，与对外持续强调 AI 已能代写代码的叙事之间，确实存在难以自洽的张力。

来源：The Register、OpenJDK 官方政策页、InfoQ