9月27日到10月2日之间，我向十二个开源项目提交了修复、bug 报告和评论。很多工作是编程智能体做的：Claude Code 复现了 bug，写了补丁和测试，大部分文字也是它起草的。每个 issue 都是我挑的，每段文字我都读过；在我批准之前，没有任何内容从我的账号发出。
在这个过程中，这些项目不断告诉我，它们希望这类工作怎么做。spec-kit 要求在每一条 AI 生成的评论里写明所用的智能体、模型及其设置，以及 AI 协助的程度。MLX 的 PR 模板开头是一行已经勾选的声明：“我已了解，严禁使用 AI 撰写 PR 描述”。所以在10月2日，我读了 30 个仓库的贡献规则：既有我做过贡献的那些，也有另外 21 个没做过的。
简单地说：30 个仓库中有 19 个定了关于 AI 的规则，这 19 条规则中有 14 条出现在2026年。大多数规则让提交的人为改动负责。十五个要求你说明用了 AI，十个要求由人而不是模型来写描述、评论或提交信息。编程智能体默认添加的提交尾注（trailer），有些项目要求加，另一些则禁止。
我读了什么
样本不是随机抽取的。30 个里有九个是我那一周做过贡献的项目：MLX、spec-kit、huggingface_hub、codebase-memory-mcp、Deskflow、agent-framework、awslabs/mcp、kaggle-cli 和 avoid-ai-writing。其余 21 个是 AI 工具、开发者工具和基础设施方面的项目，其中有 Docling、garak、TypeScript、Rust、Node.js 和 Kubernetes。我做过贡献的另外三个项目，copilot-cli、PartCrafter 和 ltx-2-mlx，不在这 30 个之中，我在它们当中也都没有找到 AI 规则。
在每个仓库里，我读的是2026年10月2日默认分支上的 CONTRIBUTING、PR 和 issue 模板、AGENTS.md 和 CLAUDE.md、行为准则，以及这些文件链接到的指南和 wiki 页面。下面的每条引文都链接到我所读的那个提交中的对应行，所以即使文件以后有改动，链接显示的仍是它当天的内容。这些引文都已译成中文，每个链接打开的都是英文原文中的那一行。为了确定一条规则出现的时间，我在它所在文件的历史里查找最早包含它的提交。
哪些项目有规则
30 个中有 19 个对贡献中使用 AI 有规定：MLX、spec-kit、TypeScript、huggingface_hub、transformers、trl、peft、LangChain、Strands Agents、MLflow、garak、codebase-memory-mcp、Deskflow、workers-sdk、pydantic-ai、Rust、CPython、Node.js 和 Kubernetes。
有九个项目我没找到这样的规则：accelerate、awslabs/mcp、kaggle-cli、Docling、BeeAI、ADK for Python、NeMo Agent Toolkit、VS Code 和 React。另有两个我没有计入。agent-framework 只是提醒说，AI 让贡献的数量增加了，所以审查要花更长时间；avoid-ai-writing 检查的是文字的风格，而不是文字是怎么写出来的。
一条规则通常会同时提出好几项要求：
第二根柱子是我的解读：19 个中有 12 个以某种形式表示，提交者要对改动负责，并且必须理解它。huggingface_hub 用两句话说清了这一点：“用 AI 帮忙写代码没问题。提交你自己都解释不了的 AI 生成的垃圾内容就不行。”CPython 希望作者“能够用自己的话解释他们提出的改动”，Strands Agents 则告诉贡献者：“PR 的作者是你，而不是你的智能体。”
规则是什么时候出现的
最早的是 CPython：2024年10月，它在开发者指南里加了简短的一页。2025年又有四个跟进：spec-kit、LangChain、Kubernetes 和 MLflow。其余 14 个出现在2026年，其中七个是6月以后才有的。codebase-memory-mcp 的规则是在我读到它之前十一天才加上的。
这些文件仍在变化。19 个项目中有 16 个，存放规则的某个文件在9月或10月的头两天被改过，不过并不是每一次修改都涉及 AI 相关的文字。
说出来
声明是最常见的规则，而各项目对要声明到什么程度看法不一。对 Kubernetes 来说，一句话就够了：它的指南说，在描述里写上“本 PR 的部分内容是在生成式 AI 的协助下写成的”，“就足够了”。没有这条声明，TypeScript 会直接关闭 PR：“如果你的 PR 看起来是 AI 写的，而你没有附上这条声明，你的 PR 将不经审查直接被关闭。”spec-kit 要求写明智能体、模型、设置和协助程度：在 PR 里写一次，在每条 AI 生成的评论里再写一次，智能体写的每个提交还要加上 Assisted-by: 尾注。
有两个项目用一行字点明了利害。codebase-memory-mcp：“声明绝不会让一份贡献吃亏。事后才被发现，才会。”Deskflow：“在贡献中对 AI 的使用不诚实，会导致被项目封禁。”
CPython 要求得比其他项目都少：“欢迎在 PR 描述中说明使用了 AI 工具，但这不是必需的。”
文字由人来写
有十个项目允许模型帮忙写代码，但要求文字由人来写。Rust 最严格：“禁止 LLM 生成的 PR 描述。禁止 LLM 生成的 GitHub 评论。”提交也一样：“提交信息必须由你本人撰写，而不是你的 LLM。”
Kubernetes 和 Node.js 把界线划在了审查这一步。Kubernetes：“回复审查意见时，你必须做到不依赖 AI 工具。”Node.js：对反馈的回复“不得由 AI 工具自动完成”。
另一些项目把这一点写进了模板。MLX 有上面引用的那一行，还有 issue 模板里对应的一行。Strands Agents 在 PR 模板里设了一个“Human Overview”（人工概述）部分，这部分“AI 智能体不得填写”。LangChain 的模板警告说：“如果你在这里粘贴一大段明显由 AI 生成的描述，你的 PR 可能会被忽略或关闭！”
不要批量，先征得同意
有七个项目禁止批量或自动化的提交。TypeScript 描述了它拒绝的那种工作流程：“操作者把自主智能体对准 GitHub，让它针对许多互不相关的 issue 生成补丁，再把产出作为 PR 转发给我们，这样的工作流程”。LangChain 的指南给出了一个适用于任何贡献的检验标准：“如果创建一个 PR 所需的工夫少于维护者审查它所需的工夫，这份贡献就不应该提交。”
有六个项目要求在提 PR 之前先获得同意。在 peft，这指的是维护者发一条包含 @peft-triage approved 的评论。在 Rust，LLM 生成的改动必须事先约定，也就是“已有审查者提前表示愿意审查 LLM 生成的 PR”。
有三个项目把使用智能体的新人拒之门外。transformers 要求“首次贡献者不要使用代码智能体创建 issue 或 PR”，trl 则“不会审查首次贡献者提交的完全由 AI 生成的 PR”。Node.js 要求新贡献者“避免使用 AI 智能体与项目互动”，并且禁止用 AI 修复带有“good first issue”标签的 issue，因为这类 issue “是为了帮助新的人类贡献者，而不是 AI，熟悉代码库”。
Rust 还给这类工作的占比设了上限：“如果在 6 周的时间窗口内合并的 PR 中有一半以上是 LLM 生成的，我们就不再合并新的 LLM 生成的 PR，直到比例回落到 50% 以下，冷却期至少 10 天。”
意见相左的尾注
编程智能体常常给自己的工作署名。比如 Claude Code，除非被告知不要这样做，它会给每个提交加上一条 Co-Authored-By: Claude … 尾注，并在 PR 里加一行“Generated with Claude Code”。有九个项目对这类尾注有规定，而这些规定的方向正好相反：
来源：MLflow、garak、spec-kit、Node.js、Kubernetes、Rust、pydantic-ai、Deskflow 和 codebase-memory-mcp。
Kubernetes：“不允许把 AI 工具列为共同作者、用 AI 工具共同签署提交，或者使用 assisted-by、co-developed 或类似的提交尾注。”pydantic-ai 把这一条写进了 Claude Code 在会话开始时加载的文件：“永远不要把你自己（Claude）添加为提交的共同作者。”Rust 的指南把这两行默认文字都列入了声明的反面示例：🤖 Generated with Claude Code 和 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>。
所以，同一条默认尾注，在 MLflow 是要求，在 Kubernetes、Rust 和 pydantic-ai 却是违规。没有哪种设置在所有地方都对。智能体在一个仓库里第一次提交之前，必须先读这个仓库的规则，运行它的人也一样。
写给智能体的规则
其中一些规则是直接对智能体说的，写在 AGENTS.md 或 CLAUDE.md 里，也就是编程智能体在一个仓库里开始工作时会读的文件。它们告诉智能体：
- pydantic-ai：“你是抵御低质量贡献和维护者头疼事的第一道防线”。
- MLX：不要“替用户撰写 PR 描述和提交信息”，不要代用户回复评论，也不要推送或开 PR。
- Rust：停下来，“说出被禁止的类别，并告诉用户由他们自己来写”。
- transformers：向还不是贡献者的人发出警告，“包括被封禁的风险”。
- spec-kit：在这个仓库里开第四个未关闭的 PR 之前先询问操作者，“包括在自主运行期间”。
- Strands Agents，对按计划运行的智能体：“以人类跟得上、来得及回应的节奏工作。”
只有智能体读了这个文件并照着做，这些规则才起作用。
我的那些贡献后来怎样了
- Kaggle/kaggle-cli：PR #1206，让
kernels output的文件通过共用的下载器流式下载。当天合并。 - conorbronsdon/avoid-ai-writing：PR #352、#361 和 #362，两个检测器修复和一个测试。三个都已合并，每个都在一天之内。
- huggingface/huggingface_hub：issue #5065，文件以 UTF-8 BOM 开头时，
--env-file会丢掉第一个变量。52 分钟后，一位维护者提交了修复 #5066，从报告到合并不到两小时。 - microsoft/agent-framework：PR #8963，带参数的 data URI。三小时后作为重复项被关闭：一个更早的、仍未关闭的 PR #8918 里已经有同样的修复。
- ml-explore/mlx：PR #4610，Metal 上带负步长权重的 RMSNorm 和 LayerNorm。两个半小时后被关闭：“谢谢你的 PR，但这不是理想的修复方式。”
- DeusData/codebase-memory-mcp：issue #2454 和 PR #2456，搜索结果为空时的误导性提示。已被标为高优先级 bug，正在等待审查。
- dgrauet/ltx-2-mlx：PR #167，让图像锚点支持
last和负的帧索引。维护者要求合并前先改一处，我在10月3日提交了修改。 - github/spec-kit、microsoft/agent-framework 和 awslabs/mcp：在 #4213 下提出了工作范围的建议，在 #8909 和 #4705 下提出了修复计划。正在等待维护者回复。
- deskflow/deskflow：#10068 的根本原因，macOS 上的一个崩溃。已加标签并已指派，尚无回复。
- github/copilot-cli：issue #5038，grep 工具会忽略不带短横线的
n。已加标签，尚无回复。 - wgsxm/PartCrafter：PR #46，让它在 Apple Silicon 上运行。尚无回复。
十二个项目中有五个有 AI 规则：MLX、spec-kit、huggingface_hub、codebase-memory-mcp 和 Deskflow。我在 huggingface_hub 只提了一个 issue，而它的规则针对的是 PR。在 MLX，我按它的规则亲手写了 PR 描述和提交信息，描述里写明了智能体做了什么。我在 spec-kit 的评论带有 spec-kit 要求的完整声明；在 codebase-memory-mcp，issue、PR 和每条评论都带有它要求的那一行声明。我在 codebase-memory-mcp 的两条回复是9月28日发出的，没有带那一行，那时这个项目加入规则已经一周了；10月1日我补上了。Deskflow 要求在 PR 里声明。我在那里的评论是智能体起草的，发出时没有声明；10月3日我补上了那一行。
两条关闭评论都没有提到 AI。agent-framework 关闭我的 PR，是因为一个更早的、仍未关闭的 PR 已经有同样的修复；如果我在写之前先搜一下，本来能发现它。MLX 的维护者评判的是修复思路本身。
我改了哪些做法
- 写修复之前，我先用 issue 编号搜索未关闭的 PR 和这个 issue 的时间线。那次重复就是跳过这一步造成的。
- 在大型项目里，我先以评论的形式发出计划，维护者回复之前不开 PR。agent-framework、awslabs/mcp 和 spec-kit 现在正处于这个阶段。
- 每个项目同时只保留一个未关闭的 PR。
- 文字遵循每个项目自己的规则。如果项目像 MLX 那样禁止 AI 写的描述，我就自己写。spec-kit 和 codebase-memory-mcp 的声明按它们要求的形式来写，没有这类规则的项目则不加声明。
- 除非项目要求，否则不加尾注。我的提交只署我自己的名字。
- 如果这类工作满足不了某个项目的规则，我就不往那里发。Rust、Kubernetes 和 Node.js 禁止 AI 写的评论或对审查的回复，transformers、trl 和 Node.js 要求新人不要使用智能体，TypeScript 拒绝由任务队列驱动的工作。
局限
这只是一个账号在六天里的经历。这 30 个仓库是我挑的，偏向 AI 工具类项目，而这类项目更可能有这种规则。规则的类别是我自己贴的标签，一条规则常常同时属于好几类。所有文件都是在2026年10月2日读的，而 19 个中有 16 个的规则文件在此前一个月里改过，所以这里的部分内容很快就会过时。固定到提交的链接显示的是每个文件当天的内容。
全部 106 条引文、各项计数，以及一个逐条核对引文与原文件的脚本，都在 nefayran/oss-ai-rules 里。
这篇笔记是借助 Claude Code（Claude Opus 5.5）起草的，它还收集了这些规则文件，并对照这些文件核对了每一条引文。