GitHub 草稿 PR 也可计入限制：先设计代理工作的入口

代理生成代码越快，评审队列也可能越长。草稿 PR 表示尚未准备好，并不会让工作从仓库负担中消失。GitHub 的变化是重新审视入口的机会。

10月8日的变化

GitHub 于2026年10月8日宣布，可配置 PR 限制将草稿也计算在内。过去草稿不计入用户上限。这不代表所有仓库设置已自动改变。

公告旨在減少低质量贡献及垃圾提交带来的杂乱、通知和 CI 运行。没有通用推荐数值。先查看真实配置及适用范围。

草稿表达准备程度，上限控制进入的工作量。未完成的工作也需要维护。但不能说所有草稿都运行昂贵 CI，应查看触发条件与实际历史。

为同一 issue 的三个方案各开草稿，便于比较，却留下三个分支和 diff。它们是实验，不是三次发布承诺。可行时在 issue 中比较方案，再打开目的明确且可评审的 PR。

记录草稿和普通 PR 数量、负责人及目标、最后有意义的更新，再查看 CI、等待时间与重复 issue。凭通知太多的感觉设置上限，可能挡住有效贡献。

代理流程应关联仓库、issue 和已有 PR。创建失败时不要立刻换名字再开一个。先确认已有工作并更新。这是团队运营建议，不是 GitHub 新增自动行为。

指引应包括如何继续已有工作、评审准备标准及联系人。不要把转为普通 PR 当作绕过策略的方法。关闭或归档前查看负责人和有用内容。

依赖的多个 PR 不能只按数量判为低质量。小 diff 堆叠与重复提交不同。上限保护入口，不替代评审、测试或部署判断。

在一个仓库记录策略及例外，确认实际设置。同周期比较草稿增长、已有 PR 复用、等待时间与有效贡献受阻。条目減少不等于质量提高。

先让同一任务回到同一 PR，再提高代理频率。GitHub 提供设置反馈渠道。本文没有编造未经验证的反应或改进数据。

2026年10月9日核验。区分产品变化与运营建议。