GitHub 首次给开源项目「限流」｜PR 月吞吐量四年涨 3.6 倍，AI 灌水把维护者逼到墙角
一句话总结
GitHub 上线 Pull Request Limits，仓库维护者首次可对无写权限用户设置 PR 上限。PR 月吞吐量 4 年涨 3.6 倍，AI 灌水是主因。
GitHub 于 6 月 18 日在官方博客宣布上线 Pull Request Limits，仓库维护者首次可以对「无写权限用户」设置同时开启的 PR 数量上限——这是 GitHub 自诞生以来，第一次在平台层面把「欢迎贡献」的默认姿态，反向改成「先排队」。
机制很直接：达到上限后，贡献者必须先关掉或合并一个 PR 才能再开新的。Draft PR 不计入额度，由 Copilot 或其他 AI agent 开的 PR 照样计入。维护者可以把信任的贡献者放进 bypass list，绕过限制但不发 write 权限。配置入口在 Moderation Options 下的 Interaction Limits。
数字解释了为什么要动这刀。2023 年 1 月 GitHub 上每月合并的 PR 约 2,500 万个；2026 年 6 月这个数字已破 9,000 万，四年涨 3.6 倍。涨幅大头不是新增开发者，而是 AI 自动生成的 PR——科技媒体 heise 直接点名这是「GitHub 没明说的 AI slop 治理」，The Register 早在 2 月就爆料 GitHub 在研究「PR kill switch」。
维护者端的反馈够直白。AutoGPT 的 Nicholas Tindle 在 GitHub 博客原话：「这让我们重新有了想去 review PR 的欲望。」Homebrew 的 Mike McQuaid 补了一句：「我们还是能接外部贡献，只是把节奏卡在维护者能消化的水平。」这两个都是被 AI PR 灌得最惨的明星项目。
下一步 GitHub 还在排：PR 归档即将上线、issue limits 在开发中、bypass list 之后会接入账号历史与组织成员身份做「智能放行」。
开源协作模型运转 17 年的默认规则——「PR 越多越好、来者不拒」——在 AI 把边际成本压到零的这一年，被官方亲手按下了暂停键。
via GitHub Blog / GitHub Changelog / InfoWorld / heise online
机制很直接：达到上限后，贡献者必须先关掉或合并一个 PR 才能再开新的。Draft PR 不计入额度，由 Copilot 或其他 AI agent 开的 PR 照样计入。维护者可以把信任的贡献者放进 bypass list，绕过限制但不发 write 权限。配置入口在 Moderation Options 下的 Interaction Limits。
数字解释了为什么要动这刀。2023 年 1 月 GitHub 上每月合并的 PR 约 2,500 万个；2026 年 6 月这个数字已破 9,000 万，四年涨 3.6 倍。涨幅大头不是新增开发者，而是 AI 自动生成的 PR——科技媒体 heise 直接点名这是「GitHub 没明说的 AI slop 治理」，The Register 早在 2 月就爆料 GitHub 在研究「PR kill switch」。
维护者端的反馈够直白。AutoGPT 的 Nicholas Tindle 在 GitHub 博客原话：「这让我们重新有了想去 review PR 的欲望。」Homebrew 的 Mike McQuaid 补了一句：「我们还是能接外部贡献，只是把节奏卡在维护者能消化的水平。」这两个都是被 AI PR 灌得最惨的明星项目。
下一步 GitHub 还在排：PR 归档即将上线、issue limits 在开发中、bypass list 之后会接入账号历史与组织成员身份做「智能放行」。
开源协作模型运转 17 年的默认规则——「PR 越多越好、来者不拒」——在 AI 把边际成本压到零的这一年，被官方亲手按下了暂停键。
via GitHub Blog / GitHub Changelog / InfoWorld / heise online
