AI 编写的代码不行吗？Java 的核心 OpenJDK 为何发布“AI 禁令”

한국어 English 日本語 简体中文 繁體中文
By Gi Pyeong Lee
OpenJDK Java AI 编程 开源
OpenJDK 标志与人工智能图形形成对比，象征开源项目 AI 政策的变革
AI Summary

出于代码稳定性和版权问题的考虑，OpenJDK 社区引入了一项政策，暂时禁止贡献 AI 生成的代码。

想象一下，你是一名正在建造一座巨大桥梁的工程师。但在设计大桥时，如果不经人手，直接使用“AI”自动计算出来的数值，会怎样？虽然计算速度很快，但你可能会感到不安：AI 为什么得出这个数值？会不会存在肉眼看不见的结构性缺陷？

最近，Java 语言的核心项目 OpenJDK 社区发布了一项带有类似考量的政策。这就是所谓的“AI 生成代码贡献禁令”，即禁止将 AI 编写的代码引入项目。究竟为什么会做出这样的决定？这又与我们的日常生活有何关联？让我们一起来了解一下。

为什么这很重要？

Java 是全球无数金融系统、企业软件和云基础设施的骨架。我们早上醒来通过 App 查看银行余额，在整理会议资料时使用的众多系统，都是基于 Java 运行的。

如果这些核心基础（OpenJDK）中混入了未经检验的 AI 代码，会发生什么？这可能会超越单纯的错误，引发数据泄露或系统瘫痪等严重的安全性事故。这项政策并非单纯意味着“讨厌 AI”，而是为了捍卫基础设施的可靠性（Trustworthiness，即对系统将按预期安全运行的信任）而采取的措施 Source 10。虽然开发者将 AI 作为便利工具来使用无可厚非，但 OpenJDK 的意愿是维持一种由人类负责到底的结构，特别是针对我们每天都在使用的基础设施。

AD

浅显易懂：代码的“原产地”问题

简单来说，这项政策类似于“原产地标记制度”。

打个比方，AI 编写代码的方式就像是一个“聪明的摘要机器人”，它阅读全球无数书籍，并将其内容混合在一起写出新的句子。但问题在于，这个机器人在编写句子时，往往无法完全说明信息的来源。

  1. 知识产权的模糊性：如果有人用 AI 编写了代码，但后来发现该代码侵犯了他人的版权，该怎么办？由于 OpenJDK 是全球都在使用的开源项目，因此无法承担这种法律纠纷风险 Source 10。
  2. 评审者的痛苦：以前，评审者只需看人类编写的代码并纠正“这里有问题”，但 AI 瞬间生成的成千上万行代码，对于人类评审者来说负担太大了 Source 8, Source 10。
  3. 安全稳定性：AI 有时会写出“看起来没错但实际错误”的代码。如果 AI 代码中潜藏着针对系统极小漏洞的 Bug，那么查找它比大海捞针还要困难 Source 5, Source 10。

换句话说，AI 就像帮你做作业的“天才学弟”。因为学弟写的报告太出色了，你直接提交给了老师，结果发现内容是来源不明的拼凑，或者关键数据有误。那么，责任将全部由提交报告的你来承担。OpenJDK 现在决定不直接接收那位学弟的报告。

现状：“个人用” vs “项目用”

那么，开发者现在写代码时就不能使用 AI 了吗？幸运的是，并非如此。

OpenJDK 社区允许“个人使用 AI”。开发者为了提高生产力，向 AI 提问或获取灵感，并在此基础上“由人类亲自”编写并提交代码，这是没有任何问题的 Source 6。只是严格禁止将 AI 直接生成的代码复制并贡献给 OpenJDK 项目 Source 5, Source 6。

有趣的是，尽管都是甲骨文（Oracle）支持的项目，但像 GraalVM 这样的其他项目却允许贡献 AI 生成的代码 Source 3, Source 11。这是一个非常有趣的例子，展示了根据项目性质的不同，对待 AI 的视角也会有所差异 Source 10, Source 12。

未来将会怎样？

这项措施是 2026 年 4 月发布的“临时政策（Interim Policy）” Source 1, Source 8。也就是说，OpenJDK 计划在密切观察 AI 给软件生态系统带来的机遇与风险的同时，从长远角度制定完善的政策 Source 8。

未来，我们将会在更多的开源项目中目睹这样的考量。因为越是核心的基础设施项目，就越倾向于优先考虑“安全”和“责任”，而非“速度”。各位读者将来会在新闻中频繁看到“AI 辅助编程”的华丽消息背后，伴随着“但谁来负责？”的拷问。这是技术进步的同时，我们对待技术的责任感也在共同进化的证明。

MindTickleBytes AI 记者的观点

随着技术的发展，“人类的判断”将变得愈发珍贵。即便迎来 AI 可以编写所有代码的时代，代码是否安全到足以支撑公共系统的最终审批权，始终会掌握在人类手中。OpenJDK 的这一决定，将成为警惕技术工具化、捍卫系统信任的一个重要里程碑。

参考资料

  1. OpenJDK Interim Policy on Generative AI
  2. OpenJDK Interim Policy on Generative AI - announce - openjdk.org
  3. Oracle’s OpenJDK Bans Generative AI Contributions While Oracle’s GraalVM Allows Them - InfoQ
  4. What’s coming in JDK 27… and why OpenJDK just said no to your Copilot - JVM Weekly vol. 171
  5. Agentic AI Workflows for OpenJDK Development
  6. OpenJDK Legal Documents
  7. April 2026 - announce - openjdk.org
  8. OpenJDK Interim Policy on Generative AI Usage - LinkedIn
  9. Oracle’s OpenJDK Bans Generative AI Contributions While…
  10. Oracle’s OpenJDK Bans Generative AI Contributions While …
  11. Oracle’s OpenJDK Bans Generative AI Contributions While …
AD
测试你的理解
Q1. 以下哪项不是 OpenJDK 禁止 AI 生成代码贡献的主要原因？
  • 代码稳定性和安全隐患
  • 知识产权所有权问题
  • AI 工具的订阅费太贵
主要原因是代码安全性、版权以及评审者的压力，并未提及订阅费问题。
Q2. 想要为 OpenJDK 做出贡献的开发者完全不能使用 AI 工具吗？
  • 是的，编写代码时完全不能使用 AI。
  • 不是，个人作业中可以使用，只要不提交到项目中即可。
  • 只有提交到项目的代码才需要禁用 AI。
可以使用 AI 工具辅助个人工作，但禁止将该成果直接贡献给 OpenJDK。
Q3. 甲骨文支持的 GraalVM 项目是否采取了与 OpenJDK 相同的政策？
  • 是的，完全相同。
  • 不是，GraalVM 持有相反的政策，允许贡献 AI 生成的代码。
  • 没有确定的政策。
与 OpenJDK 相反，GraalVM 实行的是允许贡献 AI 生成代码的政策。