☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
两个同由 Oracle 支持、存在技术关联的开源项目，在对待生成式 AI 所产出的开源贡献方面，采取了截然不同的立场：OpenJDK 管理委员会通过了一项临时性限制政策，明确禁止此类内容；而 GraalVM 则在其《Coding Assistants 政策》中明确允许使用生成式 AI 辅助开发并提交贡献。值得注意的是，这两个项目均要求贡献者签署同一份《Oracle Contributor Agreement》（OCA），以统一处理知识产权相关事宜。
2026 年 4 月上旬，OpenJDK 正式公布了一项全面限制生成式 AI 内容参与的政策：
任何贡献均不得包含由大语言模型、扩散模型或其他类似深度学习系统部分或全部生成的内容。此处所指“内容”涵盖范围广泛，包括但不限于 OpenJDK Git 仓库中的源码、GitHub 上的 pull request、邮件列表讨论、Wiki 页面以及 JBS issue 中出现的源代码、文本及图像。
该政策列出了三项核心依据。其一为评审资源压力：大量表面合理但实则存在逻辑错误、难以长期维护的代码将严重挤占本就稀缺的社区评审人力。其二为安全与可靠性要求：作为支撑关键基础设施的核心平台，JDK 必须维持极高的质量与可信标准。其三则是知识产权不确定性：OCA 明确要求贡献者对其提交内容拥有完整且无附加限制的知识产权，并有权将其无偿授予 Oracle；然而当前法律实践中，个人是否对 AI 生成内容享有可主张的著作权，尚处于多起未决诉讼之中，尚未形成定论。
该政策并未一刀切地禁绝所有 AI 使用场景，而是为开发者保留了私人用途空间：贡献者仍可借助生成式 AI 工具进行代码理解、调试、性能分析与代码审查等工作，亦可用于学术研究目的——唯一不可逾越的红线是，不得将 AI 直接生成的内容作为正式贡献提交。政策 FAQ 特别强调，即便仅对一段由 AI 生成的 100 行代码做了 10 行修改，整段提交仍被视为含 AI 生成成分，因而不被接受。与此同时，政策明确豁免常规开发辅助工具，例如编辑器或 IDE 中的拼写检查、语法校验、基础自动补全及重构功能，前提是这些功能未基于大语言模型或同类深度学习架构。
自即日起，OpenJDK 贡献者在 Skara 这一自动化 pull request 审核系统中提交代码时，必须勾选一项确认框，声明其贡献符合上述生成式 AI 使用规范。OpenJDK 官方也坦承，现实中人工编写与 AI 生成的代码往往难以准确区分，因此建议评审人员重点关注可能暴露 AI 特征的典型痕迹，如过度模板化表达、异常一致的命名风格、缺乏上下文适配的注释等。
而在 2026 年 4 月中旬，隶属 Oracle Labs、独立于 OpenJDK 管理委员会之外的 GraalVM 项目，则正式发布了其《AI 编码助手使用政策》与配套贡献指南，明确接纳生成式 AI 的参与：
GraalVM 贡献者在准备代码提交过程中，可自由使用 AI 编码助手及相关工具。……本文档所定义的“编码助手”，泛指一切能够协助起草、转换、解释、评审或归纳代码、测试用例、文档及提交说明文本的 AI 驱动工具。本政策适用于所有经此类工具辅助完成的贡献行为，以及由此产生的项目互动，包括但不限于 pull request 和 issue 提交。
此外，GraalVM 于 2026 年 6 月 3 日进一步补充发布了专为 AI 编码助手定制的《术语与写作风格指南》，旨在提升 AI 辅助内容的专业性与一致性。
GraalVM 的政策参考了 Linux 内核已有的 AI CodingAssistants 指南，但在执行细节上进行了本地化调整。例如，Linux 内核要求所有 AI 辅助提交必须标注 Assisted-by 标签；而 GraalVM 对此未作强制要求——它允许贡献者自主决定是否披露所用模型或工具的具体名称；但若该信息有助于评审者理解变更背后的实现逻辑与设计思路，项目仍积极鼓励主动说明。
“贡献者责任”构成了 GraalVM 政策体系的基石：每位提交代码的人类贡献者，须对其整个提交内容承担完全责任，无论其中是否存在 AI 协助成分。这意味着他们必须亲自审阅、充分理解全部改动，验证其功能正确性，并能在不依赖工具的前提下，独立回应评审者的各类质询。政策明确指出：“若贡献者无法清晰解释、合理辩护或持续维护某项 AI 辅助完成的变更，该提交将面临被拒绝的风险。”
同样地，维护者端的评审标准并未因 AI 参与而降低。GraalVM 强调，AI 辅助既不等于代码正确，也不代表变更已达可评审状态，更不能替代常规审查流程。维护者在评审过程中，依然有权深入追问变更来源、设计动机、许可证合规性、测试覆盖情况，以及贡献者本人对该改动的真实掌握程度。
尽管两者均依托同一份 OCA 实现知识产权归属，OpenJDK 将 AI 生成内容所引发的权属模糊性视为全面禁止的正当理由，而 GraalVM 则选择以强化“人类责任闭环”作为风险控制机制，从而为 AI 辅助贡献留出制度性通道。
目前，Oracle 正在为 OpenJDK 全面制定一套更系统化的 AI 贡献治理框架，预计将在“合适时机”对外发布。至于 GraalVM 方面，暂无关于其现行 AI 政策后续演进路径的官方披露。
原文链接：
https://www.php.cn/link/5ecf438e3ba6480cc3a438114d08f6c5
本文来自微信公众号“InfoQ”（ID：infoqchina），作者：Karsten Silz，编辑：田橙z，36氪经授权发布。
