130 秒速览

1The 30-second version

一句话:2026 年 8 月第一周,两个重量级开源项目给出了截然不同的答案——OpenJDK 临时禁止任何“部分或全部由大模型生成”的贡献;Rust(rust-lang/rust 仓库)则允许有限使用,但必须披露、必须带测试、关键代码不许生成。两者都在保护同一样稀缺资源:维护者的审阅注意力。

In one sentence: in the first week of August 2026 two heavyweight open-source projects gave opposite answers. OpenJDK temporarily bans any contribution “generated, in part or in full, by large language models”; Rust (the rust-lang/rust repository) allows limited use but requires disclosure, tests, and no generated soundness-critical code. Both protect the same scarce resource: maintainers’ review attention.

先说名词:贡献(contribution)是外部开发者向开源项目提交的代码、文档或问题报告;PR(拉取请求)是提交改动、请维护者审阅合并的方式;披露就是在提交里写明“这里用了 AI”。

Quick vocabulary: a contribution is code, docs or an issue report that an outside developer submits to an open-source project; a PR (pull request) is how you propose a change for maintainers to review and merge; disclosure means stating in the submission that AI was used.

2背景:为什么是现在

2Background: why now

各项目给出的理由高度一致,可以归成三类:

The reasons projects give are strikingly similar and fall into three groups:

还有一个常被忽略的理由来自 Godot:代码审阅历来是培养下一代维护者的途径,而对 AI 给出的反馈不会让模型下次改进,这部分“导师价值”就被机器吸收掉了。

A less obvious reason comes from Godot: code review has long been how projects mentor future maintainers, and feedback given to an AI does not change how the model behaves next time, so that mentoring value is “absorbed by a machine.”

数据来源:Developers Digest 08-08 简报(HN 数据)、Rust Inside 博客、it-connect(Debian)、WebProNews(QEMU)。

Data: Developers Digest brief of Aug 8 (HN figures), Rust Inside blog, it-connect (Debian), WebProNews (QEMU).

3核心概念

3Core concepts

4光谱:主要项目怎么规定

4The spectrum: what major projects require

下表按“从严到宽”排列。日期为政策发布或报道日期;状态以各来源描述为准。

The table runs from strictest to loosest. Dates are when each policy was published or reported; status is as each source describes it.

5两种思路的细节:OpenJDK 对 Rust

5Two approaches in detail: OpenJDK vs Rust

OpenJDK:按“内容来源”一刀切。据 Developers Digest 对其 FAQ 的整理:100 行 AI 代码里手工改了 10 行,结果“仍然部分包含 AI 生成的代码”,照样不收;IDE 里的拼写/语法检查、自动补全、重构工具可以用,但前提是它们不基于 LLM——也就是说,基于模型的自动补全在写贡献代码时要关掉。执行上计划在 Skara 的每个 PR 里加一个确认勾选。FAQ 也承认“可靠地区分人写与 AI 写是不可能的”,列出的线索全是行为特征:提交里有给工具记功的 Co-Authored-By、与作者以往风格不符的啰嗦、过度结构化的注释、防御式代码、表情符号。

OpenJDK: a blanket rule based on where the content came from. Per Developers Digest’s reading of its FAQ, if you hand-edit 10 of 100 AI-generated lines the result “would still include, in part, AI-generated code” and is still barred. Spell-checking, grammar checking, auto-completion and refactoring in the IDE are allowed only if they are not based on LLMs, so model-powered autocomplete must be off when writing contributed code. A compliance checkbox on every PR is planned via Skara tooling. The FAQ concedes that “reliably distinguishing human-generated content from AI-generated content is impossible”; its listed signals are all behavioural: a Co-Authored-By trailer crediting a tool, verbosity unlike the author’s past work, over-structured comments, defensive code, emoji.

Rust:按“用途 + 风险”分层。可以用 LLM 帮你理解、检查、审阅,但不应让它“创作”;例外是事先约定、非关键、高质量、测试充分、审阅充分的改动。机器翻译、“小改动”、用 LLM 发现的 bug、用 LLM 做的审阅,同样都要披露。审阅者可以“不问理由”关闭不合规 PR,并引导作者去 Zulip 的 #llm-mentoring 频道;审阅者不负责判断代码是否由 LLM 生成,拿不准就私下报告给管理团队,而不是公开指责——“风格不是证据”。

Rust: layered by use and risk. You may use LLMs to understand, check and review, but not to “create”; the exception is pre-arranged, non-critical, high-quality, well-tested, well-reviewed changes. Machine translation, “trivial” changes, bugs found with an LLM and reviews done with an LLM must all be disclosed. Reviewers may close non-compliant PRs “no questions asked” and point authors to the #llm-mentoring Zulip channel; reviewers are not responsible for deciding whether code is LLM-generated, and if unsure they report privately to moderation rather than accuse anyone — “style is not evidence.”

6怎么做:给编码 agent 用户的实操清单

6What to do: a checklist for coding-agent users

以下为作者据上述政策给出的做法建议,不代表任何项目的官方要求:

The following are the author’s recommendations derived from these policies, not any project’s official requirements:

示例:按项目调整 Claude Code 的提交署名。据 Classmethod(2026-09-22,v2.1.267 实测)对官方设置文档的整理,attribution.commit / attribution.pr 接受字符串,可改成项目要求的尾注;放在该项目的 .claude/settings.local.json 里只影响这个仓库。注意:该写法来自晚于本文日期的文档,请以你所用版本的设置参考为准。

Example: adjust Claude Code’s commit attribution per project. According to Classmethod’s write-up of the official settings docs (2026-09-22, tested on v2.1.267), attribution.commit / attribution.pr take strings, so you can switch to the trailer a project wants; putting it in that project’s .claude/settings.local.json affects only that repository. Note this comes from documentation later than this article’s date, so check the settings reference for your version.

// 内核类项目:<repo>/.claude/settings.local.json
{
  "attribution": {
    "commit": "Assisted-by: LLM sparse",
    "pr": ""
  }
}

# 提交时由你本人签名(DCO)
git commit -s -m "fix: ..."

// Kernel-style project: <repo>/.claude/settings.local.json
{
  "attribution": {
    "commit": "Assisted-by: LLM sparse",
    "pr": ""
  }
}

# Sign the DCO yourself when committing
git commit -s -m "fix: ..."

Linux 内核文档给出的格式是 Assisted-by: LLM [TOOL1] [TOOL2],方括号里只写 coccinelle、sparse、smatch、clang-tidy 这类专门分析工具,不写 git、gcc、编辑器等常规工具(以检索时的现行文档为准)。

The Linux kernel docs give the format Assisted-by: LLM [TOOL1] [TOOL2], where the brackets list only specialised analysis tools such as coccinelle, sparse, smatch or clang-tidy, not routine tools like git, gcc or editors (per the current docs at research time).

7坑与争议

7Pitfalls and controversies

8资源与来源

8Resources and sources