同属 Oracle，OpenJDK 与 GraalVM 对 AI 代码贡献态度相反

OpenJDK紧急亮红灯：全面封杀AI生成代码

2026年4月初，OpenJDK管理委员会批准了一项临时政策，明确禁止任何由大语言模型、扩散模型或类似深度学习系统生成或部分生成的内容贡献。该政策覆盖范围极广，包括但不限于Git仓库中的源代码、文本、图片，以及GitHub Pull Request、电子邮件、Wiki页面和JBS Issue中的所有内容。

• 评审负担：大量看似合理但实际错误或难以维护的AI生成代码会耗尽有限的评审资源。
• 安全性与可靠性：JDK支撑着关键任务系统，必须维持极高的代码门槛。
• 知识产权不确定性：OCA要求贡献者拥有授予Oracle的知识产权，且不得附带限制，但目前关于个人是否拥有AI生成输出知识产权的诉讼仍未尘埃落定。

政策为私人使用留出了空间：贡献者仍可使用AI来理解、调试、评审代码或进行研究，只是不能提交AI生成的内容。FAQ特别强调，即使只修改了100行AI生成代码中的10行，整份贡献依然被视为包含AI生成内容，不可提交。此外，编辑器或IDE中的拼写检查、语法检查、自动补全和重构功能仍可使用，前提是这些功能不基于大语言模型或类似深度学习系统。未来，贡献者需在Skara自动化PR评审系统中勾选一个复选框，确认贡献符合政策。

GraalVM大开绿灯：允许AI编码助手，强调贡献者责任

与OpenJDK的严防死守相反，2026年4月中旬，Oracle Labs旗下的GraalVM项目发布了明确的AI辅助贡献政策，允许使用生成式AI工具。项目将“编码助手”定义为有助于起草、转换、解释、评审或总结代码、测试、文档或提交文本的AI工具，并特别在2026年6月3日新增了一份“文档术语和风格指南”以规范AI辅助写作。

• 贡献者责任是核心：提交贡献的人类贡献者必须对整份贡献负责，包括任何由AI辅助完成的部分。他们必须评审并理解该贡献，验证其正确性，并在不把问题推给工具的情况下回答评审者的问题。如果贡献者无法解释、辩护或维护某项AI辅助变更，该贡献可能被拒绝。
• 宽松的披露要求：参考Linux内核的AI Coding Assistants政策，但进行了调整。Linux要求贡献包含“Assisted-by”标签，而GraalVM只鼓励（而非强制）贡献者说明具体使用了哪个模型或工具，前提是披露有助于评审者理解变更过程。
• 维护者评审规则不变：使用AI辅助并不意味着变更自动正确、达到可评审状态或可跳过正常审查。维护者仍可追问变更来源、设计意图、许可、测试情况以及贡献者是否真正理解改动。

共同OCA，不同解读：知识产权风险的“分岔路”

两个项目都要求贡献者签署同一份Oracle Contributor Agreement（OCA），以授予Oracle不受限制的知识产权。然而，同一份协议在AI时代引出了截然不同的解读：

• OpenJDK将AI生成内容所带来的知识产权诉讼风险作为全面禁止的关键理由，认为贡献者无法明确证明拥有AI输出的所有权。
• GraalVM则通过强化贡献者责任来绕过知识产权问题，认为只要人类贡献者愿意为整个贡献（包括AI生成部分）承担法律责任，且有能力解释代码，就足以允许这类贡献。

这种“一个合同，两套执行”的局面，折射出Oracle内部对AI代码合规性的深层分歧。

未来走向：临时禁令与演进路线

OpenJDk承认，人类生成内容和AI生成内容很难被区分，但仍建议评审者留意AI生成内容的典型痕迹。目前，OpenJDK的AI贡献政策是临时性的，Oracle正在为OpenJDK制定一项完整的AI贡献政策，并将在“适当时候”提出。而GraalVM方面，暂无关于其AI贡献政策进一步演进的公开公告。两个项目虽同属Oracle，但一个由OpenJDK管理委员会治理，另一个由Oracle Labs管辖，这种组织架构的差异或许是政策分歧的根源之一。