OpenJDK治理委员会今年3月底一致通过了一项临时政策:禁止向这个Java官方开源实现的仓库、PR、邮件列表、wiki甚至JBS工单提交AI生成的代码、文本或图片,4月初正式对外公布。开发者仍可以私下用大模型调试和审查代码,但一旦要公开提交,AI生成的内容一律不收。理由写得很直白——知识产权归属不清、安全风险难判断。
这份禁令的尴尬之处在于,它的最大推手正是Oracle。就在差不多同一时间,联合创始人Larry Ellison公开说AI模型现在在写Oracle的代码,联合CEOMike Sicilia则强调AI让更小的工程团队也能交付得更快。一边是对外讲AI已经接管代码生产的故事,一边是在自己主导的开源治理机构里把AI代码堵在门外——这不是巧合,是同一家公司在两个场景里给出了两套答案。
禁令比想象中更严,也更诚实地承认了执行难题
外界第一反应容易停在"Oracle说一套做一套"上,但细看政策文本,更值得注意的是它的覆盖范围和自我坦白。这不只是禁AI写代码,连PR讨论、邮件列表发言、wiki页面里由大模型生成的文字和图片都在禁止之列。范围之广,超出多数人对"禁AI代码"的第一直觉。
更值得记下的一句话来自OpenJDK自己的官方FAQ:他们承认,技术上几乎不可能可靠区分人工编写和AI生成的内容,审查者只能"发现证据时采取行动",不是系统性检测。换句话说,这条规则本质上是一份责任声明,而不是一套真正能执行的技术审查机制——贡献者自证,审查者靠经验和运气抓漏网之鱼。
Apache宽松、Linux问责、OpenJDK排除:三条路线各自赌什么
如果只盯着Oracle的双重标准,会漏掉一个更大的背景:整个开源世界正在AI代码浪潮下分裂出至少三种治理哲学,OpenJDK选的是最保守的一条。
Apache基金会的逻辑最宽松:只要许可条款和素材来源可控,AI生成代码就能进仓库,建议标注"Generated-by"来源即可。Linux内核走中间路线,允许提交AI辅助写出的有意义代码,但要求在changelog里说明用了什么工具、什么提示词、哪部分受影响、怎么测试的——Linus Torvalds今年7月还专门表态,Linux不是"反AI项目",AI是工具不是意识形态问题。
OpenJDK直接跳过了披露和审查这两道中间选项,选了排除。这背后不是道德说教,而是Java作为银行、电信、政府系统底层基础设施的特殊属性——一旦出错,责任没法靠"标注来源"或"写清提示词"来兜底,唯一靠得住的还是人。
- 结论.三种路线对应三种风险偏好,OpenJDK赌的是"确定性优先于效率",这恰恰和Oracle对外讲的AI效率故事相反。
700亿的赌注和BBB-的评级,叙事和责任正在打架
Oracle今年计划投入700亿美元扩建数据中心,押注AI云基础设施的增长。这笔支出的规模让标普把Oracle的信用评级下调到BBB-,只比垃圾级高一档,理由是投资回报的不确定性。资本市场已经在替这场AI叙事打分,分数不算好看。
这就是为什么OpenJDK的禁令值得多看一眼:同一家公司,对外讲的是AI已经能替代工程师写代码、团队可以更小更快,对内主导的开源治理却退回到最谨慎的人力问责模式。企业愿意把AI效率故事讲给投资人和市场,但真正要为法律责任和安全事故兜底的场景里,本能地选择了最保守的选项。
对开发者来说,现实的动作很具体:提交给OpenJDK的代码,AI辅助调试可以,但别指望直接把大模型生成的补丁扔进PR。对其他关键基础设施类开源项目而言,OpenJDK这次选择可能变成一个参照——接下来值得盯的,是Eclipse、CNCF系列项目会不会跟进类似的排除性政策,还是继续观望Linux和Apache那两条更宽松的路。