OpenJDK禁AI代码半年了,现在执行得怎么样?答案是:全靠自觉

刷掘金的时候看到有人又在讨论OpenJDK禁止AI代码的事,评论区一片"早该禁了"和"禁了也没用"吵成一团。 我回头看了一下,这条政策是今年4月9号发的,到现在快5个月了。当时刚出来的时候热度很高,但后来就没什么声响了。最近Debian社区关于AI贡献的投票结果出来,又把这事儿带出来了------两个社区,两个极端,结局也都不太好看。 今天不聊政策原文了,聊聊这半年到底发生了什么,以及现在实际执行是个什么状态。

政策本身没什么新花样

先快速过一下。OpenJDK的临时AI政策核心就一句话:不管部分还是全部,只要沾了AI生成的边,都不能提交进OpenJDK仓库。代码不行,PR描述不行,邮件不行,Wiki不行。 FAQ里最狠的一条是第8条------有人问"AI生成100行我自己改了10行行不行",官方说不行,仍然算"包含AI生成的代码"。 这个定义在当时就已经把灰色地带全堵了。不是说"大部分是AI写的"不行------是哪怕你改了一部分,只要还有AI的痕迹,都不行。 说白了,AI可以当你的学习工具,但不能当你的代码代笔。 这条政策到现在没有修改过,还是临时状态。Oracle以OpenJDK Community企业赞助商身份起草,Governing Board批准的,名义上叫"Interim Policy"------临时的。但"临时"这个词在开源社区是什么意思,大家都懂。

5个月后,执行层面多了个checkbox

政策发了之后,最大的变化不在政策本身,而在工具链。 从7月底开始,OpenJDK的Skara(自研PR管理系统)里,每个新PR的body里都多了一行:

css 复制代码
- [ ] I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy

每个提交者都得手动勾选。我看到好几个PR的reviewer在评论区直接写:"请确认你已勾选AI政策确认框。"这种场景半年前在开源社区根本不存在------你得先声明"我没用AI",才能开始被review。 但说实话,这就是个君子协定。FAQ第11条自己说了:"可靠地区分人类生成的内容和AI生成的内容是不可能的。"

他们没有能力自动检测AI代码。审查者能靠的只是一些线索------commit message里有Co-Authored-By字段、PR评论区的语气突然变正式了、代码注释异常工整带多级标题、过度防御性编程到处加null check、甚至用了emoji。最后一条挺逗的,原话是"如果某段内容看起来异常地乐观和细致,你可能正在看AI生成的东西。" 这些线索有用,但太弱了。任何一个有点经验的开发者都知道怎么规避。 所以现在的状态就是:规则在那儿,checkbox在那儿,执行靠自觉。跟"禁止考试用手机"一个道理。

Debian投票才是真的炸了

如果说OpenJDK是"我禁了但管不了",那Debian社区最近做的事就是"我允许了但社区炸了"。 几乎就在同一时间,Debian完成了一次关于AI生成内容的社区投票。结果------允许"负责任地使用"生成式AI来辅助贡献。

消息出来之后社区直接裂了。有人给Debian起了外号叫"debAIn",有人叫它"debianslop"。一位叫Antoine Le Gonidec的核心开发者直接宣布退出项目,理由是"面对法西斯主义假装中立,不是中立,是主动合作"------他把AI生成内容直接类比成了法西斯主义,可见愤怒程度。 投票通过提案的作者自己都说"后悔失去了一些贡献者",建议"两年后再 revisit 这个决定"。这话翻译过来就是:现在谁也不知道对不对,先这样吧。 你看,OpenJDK选"禁",执行靠自觉;Debian选"放",代价是核心成员出走。两条路都走不通完美。

同一个公司,两套做法

还有个有意思的事。Oracle旗下的GraalVM走了完全相反的路线。 GraalVM的贡献者政策明确允许AI辅助贡献,条件是:代码提交者对内容负全责,你必须能解释和维护你提交的每一行代码,鼓励披露AI参与情况但不强制。 谁提交谁负责。 同一个母公司,两个重量级开源项目,政策截然相反。OpenJDK说"东西本身有风险,禁了省心";GraalVM说"风险存在,但只要有人兜住就行"。 这不是矛盾,是两种风险观。OpenJDK承载着整个Java生态的安全基线------金融系统、政务系统全跑在它上面,出事的代价太高。GraalVM相对体量更小迭代更快,能接受"贡献者自负其责"。兜不起就禁,兜得起就放。

跟日常开发的关系

如果你只给公司内部项目写代码,上面这些都跟你没关系。但如果你也给开源项目贡献,就得认真对待了。 我自己用Cursor写代码,默认开着Copilot补全。很多时候写个工具方法tab一按就补全了------这算AI生成的吗?改了两个变量名其余都是Copilot写的------算"部分AI生成"吗?按OpenJDK的标准:算。

所以如果你要给OpenJDK提PR,最稳的做法是:提交之前,把AI辅助的部分全部手动重写。不是改几行,是完全从头来。更实际的做法:给开源项目贡献代码时单独开一个没有AI辅助的编辑器窗口。我知道这听起来很蠢------2026年了还要故意关掉AI才能写代码。但这就是现实。

GCC也禁了。Linux内核允许AI辅助但要求标注。各项目都在摸索自己的边界。 说到底,OpenJDK的FAQ里有句话说得到位:AI可以帮你写代码,但不能替你担责。你提交一段代码的时候,审查者信任的是你这个人,不是背后的模型。 半年了,谁也没找到比"靠人自觉"更好的方案。

相关推荐
冬奇Lab21 分钟前
开源项目第204期:LoopX — 长周期 Agent 控制平面,跑在 Codex/Claude Code 之上的状态管理层
人工智能·开源
stormzhangV3 小时前
AI 视频迎来了奇点时刻
开源·ai编程
孟健3 小时前
Uber:70% 的 PR 来自 Agent,AI 账单却没涨
ai编程
ovO4 小时前
DeepSeek Harness 源码解读(五):工具明明并发执行,结果为什么还按顺序写入
开源·agent·deepseek
杨杨杨大侠4 小时前
Harness 怎么适配不同模型:上下文、Token 计算与缓存
aigc·openai·ai编程
爱丶不疚4 小时前
Eval: Agent 说的 Eval 是什么?从单测、TDD 到 Sentry 聊起
前端·ai编程·vibecoding
dong_junshuai4 小时前
每天一个开源项目#86 ECC:245K星的 Agent 工程操作层
开源·github·agent
杨杨杨大侠5 小时前
Agent 是怎么被组织起来的:六种编排方式与选择
aigc·openai·ai编程
jimidou5 小时前
少点几次“允许”,Claude Code 为什么反而更安全?
ai编程