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

先看OpenJDK这边。2026年4月初，管理委员会直接拍板：禁止任何生成式AI内容混进来。政策写得非常坚决——不管是大语言模型、扩散模型，还是其他深度学习系统，只要它们参与了贡献内容的生成，哪怕只是一部分，都不行。这个“内容”范围也拉得很宽：OpenJDK的Git仓库、GitHub上的pull request、邮件、Wiki页面、JBS issue里的源代码、文本、图片，全都算在内。

为什么要这么决绝？原因有三。

第一，评审负担。这可能是最现实的问题。AI生成的代码乍看之下有模有样，但里面可能藏着各种逻辑错误、性能陷阱，甚至根本就没法维护。这些“伪优雅”的代码大量涌入，会把本就紧张的评审时间直接拖垮。

第二，安全性与安全保障。JDK是什么级别的项目？它支撑着无数关键任务系统，必须是小数点级都经得起推敲的东西。在这个层面，容不得半点含糊。

第三，知识产权。这可是个烫手的山芋。OCA要求贡献者对授予Oracle的知识产权拥有完整的所有权，且不能附带任何限制。问题是，个人对AI生成的内容到底有没有知识产权？这场官司还没打完呢，谁敢冒这个险？

不过，OpenJDK这政策也不是一棒子全打死。私人使用完全没问题——你还是可以用AI来帮助理解代码、调试程序、做评审，甚至用它做研究。只是，贡献的内容不能出自AI之手。

FAQ里有个例子值得细品：如果你从AI生成了100行代码，自己只改了10行，对不起，这也不行。因为这份贡献的主体仍然是AI生成的内容。而像IDE里的拼写检查、语法检查、自动补全、重构这些传统功能，只要不依赖大模型或深度学习系统，仍然可以用。

未来，OpenJDK的贡献者需要在Skara（那个自动化的pull request评审系统）里勾个框，确认自己的贡献符合AI政策。OpenJDK自己也清楚，人类写的和AI写的内容有时候真的很难分清，但评审者还是被建议要留意那些典型的AI痕迹。

另一边的GraalVM就不一样了。作为Oracle Labs旗下的项目，它不受OpenJDK管理委员会管辖。今年4月中旬，GraalVM明确了自己的AI政策：不仅允许使用AI编码助手，还专门为此更新了贡献者指南。

政策里把“编码助手”定义得很宽泛，包括起草、转换、解释、评审、总结代码、测试、文档、提交文本的AI工具。说白了，只要你是用AI帮忙准备的贡献，都在政策涵盖范围内。6月3日，GraalVM还专门给AI编码助手加了一份“文档术语和风格指南”。

GraalVM的这个政策，参考了Linux内核的做法，但做了更宽松的调整。比如Linux要求贡献里必须加个“Assisted-by”标签，GraalVM说不用强制，你愿意用哪个模型、哪个工具就写上，不是强制的。但如果披露AI辅助过程能帮评审者更好地理解变更，那就鼓励你说明。

核心还是落在“贡献者责任”上。提交贡献的人类，要对整个贡献全权负责，AI只是辅助工具。贡献者必须自己评审、理解、验证，面对评审者的追问，不能甩锅给工具。如果贡献者解释不了、辩护不了、甚至维护不了某个AI辅助的变更，那么拒绝，没商量。

评审规则也不会因为AI辅助而下调标准。维护者照样可以追问：你这个变更到底是从哪来的？设计意图是什么？许可是否合规？测试做了吗？你，真的理解了这次的改动吗？

两个项目都要求贡献者签署同一份OCA，授予Oracle不受限制的知识产权。但面对这一纸协议，它们选择了截然不同的路：OpenJDK认为AI带来的知识产权风险不可控，索性全面禁止；GraalVM则认为，只要强化贡献者责任，控制风险足矣。

话说回来，Oracle正在为OpenJDK制定一项更完整的AI贡献政策，预计会在“适当时候”推出。至于GraalVM这边的政策会不会继续演变，目前还没有公开消息。