拉取请求限制正在减少噪音

# 拉取请求限制如何降低干扰 来源：https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/ 如今，参与开源贡献的人比以往任何时候都多，绝大多数人都是真心想帮忙。挑战在于如何跟上贡献的体量。创建拉取请求从未如此简单。而审查一个拉取请求仍然需要人类花费几乎和以往一样长的时间。当优秀的贡献和低质量的干扰同时进入同一个队列时，那些值得关注的贡献就更难被发现。 正因如此，我们引入了拉取请求限制。它直接解决了我们听到最多的一个问题：涌入的拉取请求太多，低质量的干扰太多，而管理流程的方式又太少。 ## 工作原理 拉取请求限制会设置一个上限，规定没有写入权限的用户在你的仓库中最多可以同时打开多少个拉取请求。达到上限后，必须先关闭或合并一个拉取请求，才能再打开新的。由 Copilot 或其他 AI 代理打开的拉取请求会计入上限。受信任的贡献者可以被加入白名单，从而不受限制，但又不会获得全面的贡献者权限。草稿状态的拉取请求不计入上限。 一个显示"审核选项菜单"打开到"互动限制"子菜单的截图，顶部显示"拉取请求限制"。复选框"限制没有写入权限的用户打开的拉取请求"已勾选。 GitHub 已经有互动限制，但那是临时的冷却措施。这些新的拉取请求限制是持久且可配置的——让维护者获得了他们曾反馈缺失的控制力。 上限也会改变贡献者的行为。当任何人都能在几秒钟内打开一个拉取请求时，一个精心打磨的改动和一个粗糙的草稿在队列中看起来一模一样。但当一次只能打开少量拉取请求时，贡献者就必须有所选择，并优先考虑哪些贡献希望被审查。这个最初的价值判断在拉取请求到达你之前就已做出，而更小的池子也让优秀的工作更容易被发现。 > 这个功能让我们又有了查看拉取请求的意愿。知道某人没有一次性打开 5-10 个粗制滥造的拉取请求，会让我们更愿意去查看。展望未来，我们期望它能帮助我们管理积压任务，确保大家在做的事情正是我们所需要的。—— Nicholas Tindle，AutoGPT > 这个功能太棒了。长期以来，Homebrew 一直有个问题：热心的用户会提交大量需要近乎相同审查的拉取请求。AI 进一步加速了这一趋势。现在，我们既能保持外部贡献，又能让维护者贡献更多内容，同时将用户打开的拉取请求数量限制在我们能处理的水平。—— Mike McQuaid，Homebrew > 在 OpenClaw，我们会收到来自社区的大量拉取请求，不得不自己构建机器人来对抗垃圾信息。我们非常高兴 GitHub 现在能为维护者开发出开箱即用的解决方案来管理这种体量。—— Vincent Koc，OpenClaw ## 创建的成本已超过审查的成本 这些限制在当前显得尤为关键，因为生态系统发生了变化。2023 年 1 月，开发者在 GitHub 上月均合并约 2500 万个拉取请求。如今这个数字超过了 9000 万——增长了约 3.6 倍。现在在公开平台构建的人比 GitHub 历史上任何时候都多。 大多数贡献是出于善意，但即使是善意的贡献，其堆积速度也可能超过一个志愿者能够回复的速度。今年二月，我们曾撰文提到开源正在进入它自己的 [永恒九月](https://github.blog/open-source/maintainers/welcome-to-the-eternal-september-of-open-source-heres-what-we-plan-to-do-for-maintainers/)。拉取请求限制让维护者能够收回部分注意力，同时又不关闭下一个贡献者的门。 ## 下一步：更多管理贡献的控制手段 拉取请求限制只是第一步。同样的反馈直接指向了接下来的方向：更灵活、更精细地控制贡献如何流入。 **归档拉取请求（即将发布）**：仓库管理员将能够归档拉取请求，将低质量或垃圾拉取请求隐藏出主拉取请求视图。归档的拉取请求对管理员仍然可访问，但可以从默认列表中过滤掉。我们特意选择了归档而不是删除：有些组织出于法律或合规原因不能永久删除拉取请求，而许多维护者希望保留它们以备查证。 **议题限制（开发中）**：你现在对拉取请求的控制功能将应用到议题上：每个仓库对没有写入权限的用户同时打开的议题数量设定上限，附带白名单，以及限制只有协作者才能创建议题的选项。 **更智能的白名单信号（下一步开发）**：目标是减少手动信任管理。不再需要手动维护白名单，你可以让贡献者根据真实信号自动解除限制：例如之前在仓库中合并过拉取请求、账号年龄、或组织成员身份。这样维护者就能从手动维护列表中解放出来，有更多时间专注于工作本身。 **跨仓库控制（探索中）**：每个仓库的上限有助于应对单个项目中的反复活动，但当有人同时在数百个仓库中打开拉取请求时，它就无能为力了。我们正在探索通过信任信号、速率限制或其他跨仓库控制手段来捕捉那些跨多个仓库散布拉取请求的贡献者的方法。 ## 感谢 开源运行在每一个日复一日付出的人身上。致每一位深夜审查拉取请求的人、指导初次贡献者的人、整理积压任务的人、提交议题的人、或者告诉我们工具哪里不够好的人：谢谢你们。你们塑造了这个功能，你们的反馈对于我们决定下一步方向至关重要。我们将继续与你们一起构建。 在你的仓库设置中尝试拉取请求限制，并[告诉我们它在哪里有帮助、在哪里还不够](https://github.com/orgs/community/discussions/198851)。 让我们在拉取请求队列中见。🧡 ## 作者 Camilla Moraes 产品经理 Ashley Wolf GitHub 开源项目总监 我负责开源战略和项目，支持 GitHub 内部及整个生态系统中的维护者。同时我也是 TODO Group 指导委员会的成员，帮助组织负责任地使用和维持开源。 ## 相关文章 ## 从 GitHub 探索更多 文档 ### 文档 掌握 GitHub 所需的一切，尽在一处。 前往文档 (https://docs.github.com/) GitHub ### GitHub 在 GitHub 上构建未来，这里是任何人从任何地方构建任何事物的平台。 开始构建 (https://github.com/) 客户案例 ### 客户案例 了解使用 GitHub 构建的公司和工程团队。 了解更多 (https://github.com/customer-stories) GitHub Universe 2026 ### GitHub Universe 2026 10 月 28-29 日，在旧金山或线上加入我们，参加 GitHub Universe——我们的旗舰开发者活动，将人、代理和世界代码汇聚一堂。 立即注册 (https://githubuniverse.com/?utm_source=Blog&utm_medium=GitHub&utm_campaign=module_uni_26)