当"人人都能贡献"
变成"机器人在刷屏"
2026年，GitHub上每月被合并的拉取请求（Pull Request）突破了9000万，是2023年初的3.6倍。
数字看起来繁荣，但开源维护者们感受到的却是另一种冲击——通知中心像一个炸了锅的群聊，几十条新PR堆在最上面，标题从"修复了一个拼写错误"到"重构了整个模块"，其中相当一批连提交者自己都解释不清改了什么。
这不是普通的"新手热情"。生成式AI把写代码的门槛砸到了近乎为零，但也把"制造一个看起来像模像样的PR"的成本降到了零。
有人用AI批量扫描热门仓库的老issue，自动生成补丁后广撒网式提交；有人纯粹为了简历上那行"给知名开源项目贡献过代码"，让Copilot或Agent代理替自己代劳；甚至出现了50%的PR来自AI机器人的实验证据——一位匿名维护者在CONTRIBUTING.md里埋了一段隐藏的prompt注入指令，结果半数提交者的行为模式立刻暴露。
curl项目的维护者Daniel Stenberg忍无可忍，关闭了运行多年的漏洞悬赏计划——因为收到的报告中高达70%是AI编造的，充斥着"robust""seamless""synergy"等大模型高频词，团队成员的个人工作负载被迫提升了60%以上。
Homebrew的Mike McQuaid则坦言，项目长期受困于"热情但重复"的PR洪流，而AI进一步放大了它。
问题的本质其实是一道经济学不等式：
代码生成成本 → 趋近于零，但代码审查成本 → 纹丝不动。
维护者的人数没有变，合并率却从40%跌到15%。开源赖以运转的"信任—声誉"隐性契约，正在被无理解、无测试、无责任感的自动化贡献冲刷出裂缝。
GitHub的反击
不是关门，而是装闸门
面对这场开源版的 "Eternal September"（永恒的九月），GitHub不再只做旁观者。作为Maintainer Month 2026的核心动作之一，平台推出了仓库级 Pull Request Limit——维护者可以为没有写权限的外部贡献者设定同时开放的PR数量上限。
触达上限后，该用户必须先关闭或合并已有PR，才能再开新的。关键点在于：由Copilot或其他AI Agent代开的PR同样计入这个配额，从机制层面堵住了"靠工具无限刷量"的漏洞。
配套措施还包括：
PR归档（Archiving）：将低质/垃圾PR从默认视图中隐藏，保留记录但不污染维护者视线；
PR创建控制：允许仓库直接限制"仅协作者可提PR"或完全禁用；
即将到来的 Issue Limits（对issue做同等限额）+ 智能豁免信号（依据已合并PR记录、账号年龄、组织归属等自动放行的分级信任机制）。
值得强调的是，这套设计追求的是一个微妙的中间地带——不开门，也不关门，而是装一道可调节的阀门。
可信贡献者可以进入bypass名单免限额，新人则被引导先以小规模提交证明自己。正如GitHub的表述："不再是'要么敞开大门，要么洪水滔天'的二选一。"
更深层的信号
开源治理正在重写规则
GitHub这一变化的意义，远超一个功能开关。它标志着开源生态第一次在平台架构层正式承认了一个事实：
未来的开源项目不只要管理人类贡献者，还要管理自动化代理。
传统的开源信任模型建立在"贡献本身有成本"这一隐性过滤器上——你至少要读懂代码、跑通测试、理解上下文，才会提PR。AI把这个过滤器拆了，于是社区被迫从道德劝说
（"请认真对待贡献"）转向工程约束（限额、准入、分级信任）。
但这也引出一连串需要整个行业回答的问题：
声誉体系怎么重构？ 当"PR数量"可以被AI刷出来，招聘方继续拿GitHub绿色方块当简历硬通货，就是在为噪音买单。
责任链怎么闭环？ Linux内核给出的思路是把责任嵌进流程——要求提交者手工验证AI输出、附带可复现的测试补丁，让"签名"重新变回"背书"而非摆设。
中小项目谁来保护？ 头部项目有能力制定强制规则，但90%以上的中小型开源仓库仍暴露在治理空白中，它们才是最容易被AI洪流压垮的那一层。
结·语
GitHub的PR限流机制不是反AI，也不是反开放——它是开源生态在AI冲击波下的一道应激性骨骼。开源的精神从来不是"来者不拒"，而是"只要提交够好，就能被接受"。当"好"的判断成本被机器海量的"看起来不错"淹没时，给维护者一把调节阀，就是对开源可持续性最基本的尊重。
下一步要看的，不是GitHub还会推出什么按钮，而是社区和招聘市场会不会同步进化：把评价标准从"你提了多少PR"转回"你理解了多少问题"。
毕竟，闸门只能拦洪水，真正的河床，还是人的判断力。
·【 END 】·
