- 同一家公司、同一份贡献者协议、完全相反的政策
- OpenJDK 禁止了什么，又允许了什么
- 只改十行也不行的原因在知识产权条款上
- 政策自己承认了检测是不可能的
- GraalVM 把同样的风险挪到了责任上
- Linux 内核给出了第三个答案
- 真正把三份政策分开的那根轴
- 写自家仓库的政策时需要拍板的四件事
- 参考资料
同一家公司、同一份贡献者协议、完全相反的政策
你打算给一个开源项目发一个补丁。干活时你一直开着编码助手。为了确认这个补丁能不能发，你打开项目文档，结果发现每个项目的答案都不一样 —— 而且在同一家公司赞助的两个项目之间，答案是完全相反的。
OpenJDK 的临时政策日期为 2026 年 4 月 9 日，明确规定生成式 AI 产出的内容不得包含在贡献中。GraalVM 的政策文件则写明贡献者可以使用 AI 编码助手。两者用的都是甲骨文贡献者协议。
把这个差异概括成「一个保守、一个开明」，什么也得不到。真把这三份文档读一遍，会看到另一幅图景。
OpenJDK 禁止了什么，又允许了什么
原文把范围划得非常宽。禁止的对象不限于源代码，还包括仓库里的文本与图片、GitHub 上的 pull request、邮件、wiki 文档，以及 issue 追踪系统。提交信息、PR 描述、邮件列表的回复，统统算在内。
与此同时，允许的范围也很清楚。贡献者可以私下使用生成式 AI 工具去理解代码、调试、评审，以及做与项目相关的调研。只要不把这样产出的内容作为贡献提交就行。
FAQ 把这个区分推得更远：把草稿状态的 JEP 或文档交给 AI 帮忙评审是可以的 —— 因为文本全是本人写的，评审显然落在允许的范围里。编辑器里的拼写检查和自动补全也可以继续用，只要它们不是基于大语言模型的。
只改十行也不行的原因在知识产权条款上
被引用得最多的 FAQ 条目是这个：用 AI 生成了 100 行、其中 10 行是自己改的，能不能贡献？答案是不能。因为它依然包含部分由 AI 生成的代码。
如果你觉得这个答案严得过分，只要看到原因不在代码质量而在合同上，就容易理解了。甲骨文贡献者协议要求贡献者持有每一份贡献的知识产权，并且能够不受限制地把这些权利转让给甲骨文。而原文写道：生成式 AI 工具的使用者是否对其产出拥有知识产权，是一个目前仍在诉讼中的问题。
只要掺进哪怕 1% 权利归属不确定的部分，「不受限制地转让」这个确认就不成立。所以不可能出现按比例划线的标准，它只能是二分法。
理解了这一点，一个常见的反驳就失去了力量。那个反驳是「那 IDE 的自动补全怎么办」，而原文划这条界线靠的不是工具种类，而是技术：文档里写着，不基于大语言模型或类似深度学习系统的拼写检查与自动补全可以继续使用。判据不是便利性，而是「训练方式是否属于权利归属存在争议的那一类」。
政策自己承认了检测是不可能的
政策里最坦率的一段是关于评审者责任的部分。原文明确写道：可靠地区分人写的内容和 AI 写的内容，通常是做不到的。
即便如此，它仍规定：一旦看到迹象，评审者有责任告知贡献者，并且把这些迹象的例子也列了出来 —— 提交 trailer 里留着某个特定工具作为共同作者、和平时文风不同的啰嗦冗长、带着好几个标题的过度结构化注释、不必要的注解、比需要更防御的代码、使用表情符号等等。原文自己又补了一句：这些线索今天有效，明天未必。
于是执行落在申报而不是检测上。Skara 会在 pull request 正文里加一个复选框，让贡献者自己确认已遵守该政策。实质上，这是一套诚实声明体系。
GraalVM 把同样的风险挪到了责任上
GraalVM 的文档用另一种方式处理同一份风险清单：允许使用，但规定提交者要对包括 AI 产出部分在内的整份贡献负责。
期待的行为也很具体：读懂并理解自己提交的代码、测试、文档和提交信息；验证变更是正确的、必要的，并且符合项目标准；回答评审者的问题时不拿工具当借口；以及在评审与维护期间对这份贡献负责。文档写道：如果贡献者无法解释、无法辩护、也无法维护一项 AI 辅助的变更，那么这份贡献可能被拒绝。
来源标注是推荐而非强制，也不需要写明具体的模型名称。对维护者一侧，文档明确指出：是否为 AI 辅助，并不构成推定其正确性的依据。
Linux 内核给出了第三个答案
GraalVM 文档表示参考过的 Linux 内核的 AI 编码助手文档用的是又一根轴：允许，但要求留下痕迹。
其中一条核心规则很有意思：AI 代理不得添加 Signed-off-by 标签。因为能在法律意义上确认开发者原创声明的只有人。取而代之的是另一个标签。
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
例：Assisted-by: Claude:claude-3-opus coccinelle sparse
找 bug 并修复的流程，也被文档以步骤的形式钉死了。对于并不琐碎的 bug：要写出复现代码确认它真实存在；要一直做到修好为止；不得引入新的编译警告并且要通过 checkpatch 检查；以及明确说明你没能做到的事。写不出复现代码、或者没能测试，就照实写出来。理由也原样写在文档里：维护者花在分析未经验证的报告上的时间实在太多了。
真正把三份政策分开的那根轴
把三份文档并排放着看，那根轴就浮出来了。它不是「对 AI 有多信任」，而是把评审负担记到谁头上。
| 项目 | 承担负担的一方 | 执行手段 |
|---|---|---|
| OpenJDK | 对全体贡献者的事前禁止 | PR 复选框声明、评审者上报 |
| GraalVM | 单个贡献者的事后责任 | 解释不了就拒绝 |
| Linux 内核 | 对贡献者与工具双方都施加流程 | 强制标签、要求复现与验证 |
OpenJDK 最严格，是因为它的评审者池又窄又难以替代，而且产出会铺在关键任务系统的最底层。原文以安全与保安为理由的位置正在这里。反过来，GraalVM 判断在同一份协议之下，靠个体责任也扛得住。同一家公司给出不同答案不是自相矛盾，而是因为每个项目的瓶颈不一样。
写自家仓库的政策时需要拍板的四件事
知道了这根轴，公司内部仓库的政策也可以写得很短。不必去抄别人的政策，只要定四件事。
AI 辅助贡献政策 —— 示例骨架
1. 范围：只管代码，还是连 PR 描述和 issue 评论一起管
2. 责任：提交者解释不了的变更是否会被拒绝
3. 记录：标注是强制还是推荐，用哪个标签留痕
4. 执行：依赖检测，还是依赖声明加评审
默认建议：范围为代码与 PR 描述，责任全部由提交者承担，
记录以提交 trailer 的形式推荐，执行采用声明加常规评审。
只把第三条展开说一下：把标注变成强制，得到的不是监控，而是数据。半年之后你就能单独看 AI 辅助变更的事后缺陷率，然后就能用数字而不是靠感觉去调整政策。眼下这场争论之所以基本都在靠感觉进行，正是因为几乎没有组织手里有这个数字。
最后还有一点。OpenJDK 那份文档从标题上就写着「临时」，正文里也写明甲骨文计划向治理委员会提交一份正式政策。眼下的禁止不是最终结论，而是一项争取时间的措施。引用时漏掉这一点，就等于让原文说了它没说过的话。
参考资料
- OpenJDK Interim Policy on Generative AI — openjdk.org, 2026-04-09 —— 禁止范围、私下使用的许可、三类风险、100 行里改 10 行的 FAQ、Skara 复选框、评审者责任与线索清单，全部出自这份文档。
- GraalVM Coding Assistants — oracle/graal 仓库 —— 允许范围、贡献者责任、可选标注、维护者评审原则。
- AI Coding Assistants — Linux 内核文档 —— 禁止签名、Assisted-by 标签格式、bug 修复流程。
- 上面的对比表与政策骨架，是我读完三份原文后整理出来的，任何一份文档里都不会原样出现。
현재 단락 (1/42)
你打算给一个开源项目发一个补丁。干活时你一直开着编码助手。为了确认这个补丁能不能发，你打开项目文档，结果发现每个项目的答案都不一样 —— 而且在同一家公司赞助的两个项目之间，答案是完全相反的。