今年 4 月 9 日，OpenJDK 发布了一项临时 AI 政策：无论是部分还是全部由 AI 生成的内容，都不能进入 OpenJDK 仓库。代码不行，PR 描述不行，邮件不行，Wiki 也不行。近五个月过去，这项政策并没有被修改，仍然保持“临时”状态，但它的实际执行方式已经逐渐清晰：没有自动检测，没有强制审查，主要依赖提交者自行确认和自觉遵守。
从政策到工具链：OpenJDK 把“不用 AI”变成提交前声明
这项政策由 Oracle 以 OpenJDK Community 企业赞助商身份起草，并经 Governing Board 批准。政策名称为“Interim Policy”，即临时政策。其核心限制非常明确：只要内容包含 AI 生成痕迹，就不能提交到 OpenJDK 仓库。
FAQ 中对边界的解释同样严格。有开发者提问：如果 AI 生成了 100 行代码，自己再修改其中 10 行，是否可以提交？官方回答是否定的。这样的内容仍然被视为“包含 AI 生成的代码”。这意味着，OpenJDK 并没有给“AI 起草、人工修改”留下灰色空间。AI 可以作为学习工具，但不能充当代码代笔。
政策发布后，真正的变化出现在提交流程中。从今年 7 月底开始，OpenJDK 自研的 PR 管理系统 Skara 在每个新 PR 的正文中加入了一项确认框：
- I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy
提交者需要手动勾选，确认自己的贡献符合 OpenJDK 的临时 AI 政策。部分 reviewer 也会在评论区提醒提交者补充勾选。这种“先声明没有使用 AI，再进入审查”的流程，在半年前的开源社区中并不常见。
但这一机制并不能真正识别 AI 代码。OpenJDK FAQ 第 11 条明确写道：“可靠地区分人类生成的内容和 AI 生成的内容是不可能的。”换句话说，官方自己也承认，目前没有能力自动检测 AI 生成代码。
审查者只能看线索：异常工整、过度防御、甚至“过于乐观”
在缺乏检测工具的情况下，审查者只能依靠一些人工线索判断提交内容是否可能来自 AI。素材提到的线索包括：commit message 中出现 Co-Authored-By 字段、PR 评论区语气突然变得正式、代码注释异常工整并带有多级标题、过度防御性编程、到处添加 null check，甚至内容中出现 emoji。
其中一条描述颇具代表性：如果某段内容看起来异常乐观和细致，那么它可能正来自 AI 生成。这类判断并非技术检测，更接近经验性观察。对于有经验的开发者来说，这些痕迹并不难规避；而对于审查者来说，它们也只能作为提醒，并不能构成确定证据。
因此，OpenJDK 的 AI 禁令目前更像一种社区承诺机制。规则存在，确认框存在，但最终仍取决于提交者是否如实声明。它类似“禁止考试用手机”的规定：禁令本身表达了立场，却难以完成闭环执行。
Debian 选择允许“负责任使用”，却引发核心开发者离开
与 OpenJDK 的禁止路线不同，Debian 社区近期通过了一次关于 AI 生成内容的投票，允许“负责任地使用”生成式 AI 辅助贡献。这一结果在社区内部引发明显分裂。
素材提到，有开发者给 Debian 起了“debAIn”“debianslop”等带有讽刺意味的外号。核心开发者 Antoine Le Gonidec 宣布退出项目，并将 AI 生成内容类比为“法西斯主义”，称“面对法西斯主义假装中立，不是中立，是主动合作”。这一表述显示出部分开发者对 AI 内容进入 Debian 的强烈反感。
投票通过提案的作者也承认，自己“后悔失去了一些贡献者”，并建议两年后重新审视这个决定。这说明，即便提案获得通过，Debian 社区内部也没有形成稳定共识。允许 AI 参与并没有自动带来顺畅的治理，反而让社区付出了成员流失的代价。
OpenJDK 与 Debian 正好构成两个极端：一个选择全面禁止，但执行依赖自觉；一个选择有条件允许，却面临核心贡献者出走。两者都没有呈现出一种让社区普遍满意的方案。
同一个 Oracle，两种风险观：OpenJDK 禁止，GraalVM 允许
值得注意的是，Oracle 旗下的另一个重量级项目 GraalVM 采取了完全不同的政策。GraalVM 的贡献者政策明确允许 AI 辅助贡献，条件是提交者对内容负全责。提交者必须能够解释并维护自己提交的每一行代码。政策鼓励披露 AI 参与情况，但并不强制要求披露。
这意味着，GraalVM 并不把 AI 生成内容本身视为不可触碰的对象，而是把责任压到提交者身上。相比之下，OpenJDK 的判断是：AI 内容本身存在风险，因此直接禁止更为稳妥。
这种差异可以理解为不同项目对风险承受能力的不同。OpenJDK 承载着 Java 生态的基础运行环境，金融系统、政务系统等关键场景都可能依赖它，任何代码质量问题带来的代价都较高。GraalVM 的项目体量和迭代节奏不同，更容易接受“谁提交谁负责”的治理方式。
素材还提到，其他开源项目也在摸索各自边界：GCC 同样禁止 AI 生成代码，Linux 内核允许 AI 辅助但要求标注。不同社区正在根据项目性质、维护能力和风险偏好，形成不同的 AI 代码政策。
对开发者的现实影响：给 OpenJDK 提 PR，最稳办法是重写 AI 辅助部分
对于日常使用 Copilot、Cursor 等工具写代码的开发者来说，这些政策差异已经开始影响实际贡献行为。如果开发者习惯让 AI 补全一个工具方法，或者由 Copilot 生成大部分代码后只修改变量名，按照 OpenJDK 的标准，这类内容都可能被归入 AI 生成或部分 AI 生成内容。
在 OpenJDK 的语境下，最稳妥的做法并不是简单修改 AI 生成的几行代码，而是将 AI 辅助过的部分完全手动重写。更现实的建议是：在给开源项目贡献代码时，单独使用一个没有 AI 辅助的编辑器窗口，避免补全、生成和改写工具混入提交流程。
这看起来与当前 AI 编程工具的普及方向相悖，但它反映了开源社区治理的真实状态。AI 工具已经进入开发流程，开源项目却尚未建立可靠的识别、标注和责任机制。
OpenJDK FAQ 中的一句话点出了问题的核心：AI 可以帮助写代码，但不能替代提交者承担责任。当一段代码被提交到开源仓库时，审查者信任的是提交者本人，而不是背后的模型。至少在目前，OpenJDK 的 AI 禁令仍然只能依靠这种信任维持。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/openjdk-jin-zhi-ai-dai-ma-wu-ge-yue-hou-gui-ze-hai-zai-zhi
