Oracle 禁止 OpenJDK 中的 AI 生成代码

政策范围

• 适用于 OpenJDK 社区贡献，并不明确适用于所有 Oracle 内部代码。
• 禁止由 LLM 或类似深度学习工具“部分或全部”生成的代码及其他内容。
• 允许传统 IDE 功能（拼写检查、重构、非 LLM 自动补全）。
• 标注为“临时”；最终政策仍待法律审查。

明示与推测的动机

• 法律/IP 风险被视为首要因素：
  • AI 输出的版权状态不明确；担心 AI 代码可能不受版权保护，或包含侵权片段。
  • Oracle 更广泛的商业模式高度依赖强力 IP 执法，因此他们希望来源清晰、可追溯。
• 质量与风险方面的担忧：
  • AI PR 可能冗长、防御性强、不一致，或充满幻觉内容。
  • 维护者不想把有限的审查时间花在替贡献者梳理他们自己都未必理解的“垃圾代码”上。
  • 对于一个成熟、广泛部署的平台来说，来自未审查 AI 代码的额外风险被视为只有坏处没有好处。

执行与可行性

• 明确承认可靠检测 AI 生成代码很困难，甚至可能不可能。
• 预计该政策在很大程度上会依赖自我约束：
  • 尊重项目的贡献者会避免使用 AI 代码。
  • 社会性筛选：如果某人无法解释自己的改动，或者代码有“AI 痕迹”，审查者可以拒绝。
• 有些人推测，这也可能作为一种酌情工具，用来拒绝有问题的提交。

社区反应

• 支持观点：
  • 对关键基础设施来说，这是合理的风险管理。
  • 有助于保护维护者，避免低质量 PR 的洪水。
  • 与严肃 OSS 项目长期以来依靠社会机制把关贡献的规范一致。
• 批评观点：
  • 考虑到 Oracle 在 AI 宣传和基础设施投资上的重仓，此举显得虚伪（“对我们可以，对你不行”）。
  • 该政策过于粗暴、难以执行，而且可能只会鼓励撒谎或“洗白” AI 代码。
  • 一些人认为这主要是法律上的姿态，以保留 Oracle 的诉讼空间。

关于开发中 AI 的更广泛争论

• 许多人同意，当专家仍然掌控全局并且完全理解结果时，AI 可以成为有用的生产力工具（+10–15% 的效率提升）。
• 也有人报告了严重的现实问题：难以阅读的代码库、凭证泄露、测试失败、以及不可维护的“凭感觉写出来”的系统。
• 关于长期影响仍存在争议：
  • 有些人设想 AI 让个人分支和高度定制的软件成为可能。
  • 另一些人则认为，维护、边界情况以及缺乏实战检验使这种设想不现实。