吞吐量倒挂：AI生成爆发与代码评审瘫痪
2026年7月30日，GitHub 官宣原生支持 Stacked PR 并开启公开预览，将大变更拆分成有序小 PR 的堆叠式工作流正式进入主流 Git 托管平台。这一功能的推出，直接回应了社区长期积累的代码评审效率焦虑。随着 GitHub CLI 扩展包 gh-stack 与 Copilot Agent skill 的同步发布，开发者可以在平台层面无缝构建与管理堆叠分支。
TED 技术团队在实践中发现，AI 工具的使用让开发者的产出速率实现了大幅提升，但随之而来的是 PR 体量的剧烈膨胀，评审人员难以应对动辄上千行的变更请求。TED 首席技术官 Andy Merryman 在官方公告里说得很直接：AI 让开发者的效率大幅提升，但制造了新瓶颈——PR 大到评审者难以招架。生成端提速之后，系统整体吞吐量容易被巨型 PR 卡死。
过去多年间，堆叠式 PR 主要作为 Meta、Google 等大厂的内部基础设施存在，或依赖 Graphite、Stacked.ai 等第三方 SaaS 工具实现。GitHub 将该能力转化为原生基础设施，标志着代码评审流从单纯的文件对比升级为结构化的依赖图谱管理。大 PR 没人愿意 review 的行业困局，由此迎来平台维度的官方解法。
堆叠式工作流：将单体大变更解构为线性依赖图
Stacked PR 的核心逻辑是将一个庞大的功能特性切分为若干依赖有序的独立小层，每个 PR 只承载聚焦的局域变更。在评审视角下，开发者打开 Stack 中任意一个 PR 时，只能看到该层本身的增量代码，而顶部渲染的 Stack Map 则提供全局上下文视图。这种设计降低了动辄数千行代码带来的认知超载，让跨层级的团队并行评审成为可能。
Next.js 团队负责人 Tim Neutkens 表示，团队在过去几个月中持续使用 GitHub Stacked PR 部署 Next.js 的重大更新。在引入大功能的同时交付小粒度变更，显著降低了团队成员的评审门槛。合并最顶层就绪的 PR 可以一次性完成所有未合并层落地，而优先合并下层时，上层分支也会自动触发 rebase 与 retarget 操作。
评审效率的卡点在于单次认知负荷而非绝对工作量。一个 PR 承载的变更越大，评审者需要同时跟踪的状态越多，出错的概率和拖延的倾向都随之上升。通过将线性变更包装为自顶向下的依赖栈，Stacked PR 把单次评审的复杂度锁定在可控范围之内。
图：GitHub Stacked PR 合并界面。来源：GitHub Changelog
无缝兼容既有治理：Branch Protection 与 Merge Queue 的缝合
在引入堆叠特性的同时，GitHub 保持了原有仓库治理体系的完整性。每一个 Stacked PR 仍需独立触发既有的 CI/CD 自动化检查，且严格受限于所在分支的 Branch Protection 规则。这一设计避免了因为引入新工作流而对企业级仓库的安全合规边界造成侵蚀。
jQuery 作者 John Resig 在体验后评价，将 5 个 Stacked PR 一次性直接投递到 Merge Queue 中落地极大地消除了研发流水线上的操作摩擦。合并队列能够按照依赖次序依次完成自动化测试与主干落地，消除了此前频繁手动 rebase 造成的流水线等待时间。借助 gh 命令行与 Agent 技能，开发者在终端即可完成复杂的堆叠管理。
企业级工程团队对新工具的接纳门槛，取决于其与现有基础设施的兼容代价。GitHub 选择在原生 PR 管道中嵌合 Merge Queue 和 Branch Protections，规避了第三方工具常见的数据同步时延与权限校验风险。基础设施的平滑演进，决定了堆叠工作流能否真正从小众极客群体走向大规模团队落地。
图：GitHub PR 页面上的 Stack Map 视图。来源：GitHub Changelog
生态吸收与争议：平台原生化对第三方生态的重构
发布当日，该议题在 Hacker News 上获得了 665 点赞与 231 条讨论，在 Lobsters 亦登上热门榜单。开发者社区对 GitHub 原生支持堆叠工作流展现出极高的关注度，许多工程师称赞这是 GitHub 近年来最具实操价值的管道级更新。长期依赖第三方 SaaS 交付的高阶 Git 工作流，由此完成了向公共基础设施的转化。
讨论中也出现了对第三方工具链生存空间的担忧。Graphite 等产品在堆叠可视化与高级操作逻辑上积累了多年深度体验，GitHub 原生功能的接入势必会对这些独立 SaaS 的商业壁垒带来直接冲击。与此同时，部分开发者指出原生 UI 减少了跨平台账号授权与上下文切换的沉没成本，有助于推动堆叠思想的普适化。
第三方生态通常承担着探索前沿工作流的先锋角色，而主干平台原生化则是工作流成熟的标志。当 GitHub 把 Stacked PR 变为内置标准功能，意味着堆叠式开发跨过了少数高成熟度团队的专有门槛。开发工具链的沉淀过程，展示了优秀范式下沉为基础平台默认能力的发展轨迹。
破除AI时代评审瓶颈：重新定义代码交付的最小单元
GitHub 将 Stacked PR 转化为平台原生能力，标志着软件交付管道正式迎来了针对 AI 产出特性的深度重构。在 Copilot 等智能体让代码生成成本大幅降低的当下，决定研发迭代速率的关键在于团队审核与消化变更的心理带宽。堆叠式 PR 给出了拆解大变更的标准化解法，将混乱的巨型提交还原为清晰可追溯的递进层级。
这一演进预示着代码交付最小单元的定义发生了深刻变化。过去团队在「频繁提交导致 CI 队列拥堵」与「积攒大 PR 导致评审瘫痪」之间艰难博弈，如今借助 Stacked PR 与 Merge Queue 的深度整合，研发流水线得以兼顾小粒度评审的精确性与批量合入的吞吐效率。
GitHub 原生支持 Stacked PR，正是对 AI 生成代码引发 PR 急剧膨胀这一趋势的直接回应。大 PR 没人愿意 review 的困局终于有了平台级解决路线。当变更被解构为有序依赖的小层，团队才能在 AI 辅助开发的高频产出中，稳固维持代码库的演进质量与评审安全。
参考链接：
