一句话总结：AI 编码 Agent 把代码生成的成本降到接近零，但代码审查的成本是人类时间，无法被 AI 等比例降低。这个不对称，正在把开源维护变成一场不公平的消耗战。
数字说话
2026 年 6 月，GitHub 工程博客发布了一组数字，让很多维护者从个人感受变成了集体共识：
在某些热门开源项目中，一周内新增 PR 的数量同比增长超过 200%。其中，被系统标记为「可能由 AI 生成」的 PR（基于提交信息格式、代码结构特征等信号）占到新增 PR 总量的 40-60%。
这些 PR 的合并率：个位数百分比。
等待维护者审查的 PR 排队时间：从数周延长到数月。
GitHub 的 PM 在博客中用了一个词来描述这种状态：asymmetry（不对称性）。
“AI coding agents have made code generation dramatically cheaper and faster. But the review, validation, and integration of that code have not gotten any faster.”
— The New Stack, 2026-06-18
这场危机是怎么形成的
生成成本的暴跌
2024 年，让 AI 辅助写一个 PR 需要：一个懂代码的人类、花费数小时理解上下文、手动运行测试、组织提交信息。
2026 年，让 AI Agent 自动提交一个 PR 需要：把仓库 URL 喂给一个 Agent，等几分钟。
Claude Code、GitHub Copilot Workspace、各种基于开源框架搭建的编码 Agent，让这个过程完全自动化。Agent 扫描 Issue 列表，识别「看起来可以修复」的条目，clone 仓库，生成修复代码，提交 PR，甚至自动回复评论。
对 Agent 的操作者（通常是想积累 GitHub 贡献记录的个人，或者研究 Agent 能力的团队）而言，边际成本接近于零。对维护者而言，审查每个 PR 的成本没有变化。
质量分布的恶化
低成本生成的 PR 的质量分布，和高成本生成的 PR 非常不同。
人类开发者提交 PR 之前，通常会：
- 实际使用过这个项目
- 理解这个 Bug 的根本原因
- 确认修复不会破坏其他功能
- 考虑维护者的审查负担，保持 PR 精简
AI Agent 提交的 PR 往往：
- 基于 Issue 的文字描述生成，不一定理解底层逻辑
- 可能修复了表面症状但引入了新问题
- 可能和其他进行中的 PR 形成冲突
- 提交信息格式化但缺乏上下文
更重要的是，AI Agent 可以同时提交几十个 PR 到不同仓库，而一个维护者在同一时间只能审查一个 PR。
「开源税」的转移
这场危机的本质，是谁来支付 AI 生产力的社会成本。
AI 编码工具的使用者（个人开发者、企业、研究团队）从中获益。成本被转移到了开源维护者身上：他们需要花费更多时间处理低质量的 PR，这些时间原本可以用于真正改进项目。
这种成本转移在开源社区之外也在发生（出版商正在起诉 OpenAI 和微软爬取内容），但开源维护者的处境尤其脆弱：他们通常是志愿者，没有法律手段抵御，唯一的选项是关闭贡献通道（这会同时关掉好的贡献）或者忍受。
GitHub 的响应：技术手段能解决结构性问题吗
2026 年 6 月的措施
GitHub 在 2026-06-18 宣布了一批新功能，核心是给维护者更细粒度的控制权：
PR 数量上限：维护者可以在仓库设置中配置「每个作者最多 N 个未关闭 PR」。超出上限的用户无法新建 PR，直到他们关闭现有的 PR。
PR 权限分级：可以将 PR 权限限制为「仅合作者」（Collaborators only）或「仅维护者」，相当于关闭了陌生人的 PR 入口。
PR 完全禁用：针对镜像仓库等特殊场景，可以完全禁用 PR 功能。
AI 生成内容标记：GitHub 正在测试自动检测并标记疑似 AI 生成 PR 的功能，让维护者可以优先处理人类贡献。
这些措施的局限
PR 上限是个钝器。它会阻止 AI Agent 的高频轰炸，但也会伤害那些有多个合理 PR 在等待审查的活跃贡献者。
「仅合作者」模式实际上关闭了开源项目最重要的价值之一：陌生人的无摩擦贡献。Linux kernel 的某些最重要的贡献来自于项目之外、事先没有任何关系的开发者。把 PR 权限限制为已知合作者，会把开源项目变成半闭源项目。
AI 内容检测存在误报。写得好的 AI 辅助 PR（贡献者使用 AI 但经过认真人工审查）可能被误标，而精心伪装的 AI 自动生成 PR 可能逃过检测。
技术手段在解决的是症状，不是病因。病因是：生成成本和审查成本之间的巨大不对称，短期内没有技术手段能消除这个不对称。
社区层面的自我调节
有维护者在尝试的方法
明确的 AI 贡献政策：在 CONTRIBUTING.md 中写清楚「我们接受 AI 辅助的贡献，但要求提交者对代码内容完全理解并负责」或「我们不接受纯 AI 自动生成的 PR」。虽然没有技术手段强制执行，但降低了沟通成本。
PR 模板门槛：在 PR 模板中增加「请解释为什么这个修改是对的，而不仅仅是描述做了什么」等问题，迫使提交者展示理解，让纯自动化的 PR 更难通过。
自动标签 + 低优先级队列：CI 检测到某些特征（如提交信息格式、diff 规模、测试覆盖率变化）时自动打 needs-human-review 标签，放入低优先级队列，维护者优先处理没有这个标签的 PR。
正在出现的社区规范讨论
这场危机触发了开源社区内部一场关于「什么是可接受的贡献」的重新讨论。
一方认为：贡献的价值来自结果（代码是否有用），来源（AI 还是人类生成）不重要。这个立场的逻辑类似于「不管黑猫白猫，能抓老鼠就是好猫」。
另一方认为：开源贡献是一种社区行为，不只是代码传输。一个贡献者理解自己提交的代码、准备好在 review 阶段答疑和改进，是这个社区运转的基础。AI Agent 自动提交不需要人类参与的 PR，破坏的是这个信任基础，而不只是增加了工作量。
目前没有共识，但讨论本身很有价值。
更深层的问题：AI Agent 时代的开源协作模式
「贡献者」的含义正在改变
在 2020 年之前，GitHub 上的「贡献者」列表基本等于「真实参与了这个项目的人类开发者」。现在，这个等式正在崩溃。
一个运行了 AI Agent 并按计划提交了 100 个 PR（哪怕其中 5 个被合并）的用户，在 GitHub 的统计上是一个「活跃贡献者」。他的贡献记录看起来和一个真正在这个生态系统中深度参与的开发者差不多，但两者的实质差异是巨大的。
这对开源软件的信任机制是一个隐性威胁：当「贡献记录」的信号价值下降，评估一个开发者的能力和参与度会变得更困难。
维护者倦怠的加速器
开源维护者倦怠（burnout）不是新问题。数十亿人依赖的基础设施，往往由几个志愿者在业余时间维护。这种结构性不可持续性在多个知名项目的危机（OpenSSL、Log4j、XZ Utils 等）中反复暴露。
AI 生成 PR 的泛滥，是这个问题的加速器。当一个维护者的一半工作变成关闭 AI 生成的无效 PR，他能花在实际改进项目上的时间更少了，而倦怠的速度更快了。
可能的结构性出路
AI 贡献的责任归属：让部署 AI Agent 进行自动化贡献的组织承担一定责任。例如要求在 PR 中声明 AI 生成比例，明确人类审查者是谁。这在技术上可实现（PR 元数据 + GitHub Apps 签名验证），但需要平台层面的政策支持。
维护者经济补偿：开源基金会（如 Apache、CNCF）和企业赞助商开始将维护者补偿与「处理贡献的审查负担」挂钩，而不仅仅是与项目重要性挂钩。这不能从根本上解决不对称，但至少承认了维护者正在承担额外成本。
工具层面的质量门控：在 PR 到达维护者之前，由 AI 系统自动完成初步质量评估（测试是否通过、代码逻辑是否自洽、是否与已有 PR 重复）。这相当于用 AI 来过滤 AI，但至少可以阻止最明显的垃圾。
结语
GitHub AI PR 危机是一个更大故事的局部章节：当 AI 把某类工作的边际成本降到接近零，相关的社会成本会重新分配，通常是分配给那些没有预期到这个变化的人。
对开源维护者来说，这个变化来得很快，快到社区规范、平台工具、法律框架都没有做好准备。GitHub 的 PR 上限机制是第一步，但只是第一步。
接下来需要的是更困难的工作：开源社区重新定义「贡献」的含义，平台重新设计协作规则，AI 工具的使用者接受一定的责任约束。
这些不是技术问题，是治理问题。而治理问题通常比技术问题难解决得多，也重要得多。