AI编程工具让代码产出速度大幅提升随之而来的问题是一个PR动辄上千行改动评审者难以在合理时间内给出高质量反馈合并冲突也频繁出现。GitHub Stacked Pull Requests堆叠PR在2026年10月6日正式GA为这个问题提供了一条官方路径把大改动拆成多个小而聚焦的PR独立评审、链式合并。机制一条链上的多个PR堆叠PR的核心是把一个大型变更拆成若干相互依赖的小PR每个PR基于前一个PR的分支形成一条链。评审者可以逐个PR独立评审最终一起合并。GitHub官方数据显示使用堆叠的仓库相比同类仓库合并代码量增加9%排名前1%的仓库中超过三分之二已在使用堆叠PR合并时间改善5%。这些数字来自官方公告反映的是采用堆叠工作流的整体趋势而非单个团队的保证收益。GA版本的关键改进正式GA版本在合并与变基上做了多项增强这些细节直接决定堆叠工作流能否在企业仓库中稳定运行。审批在未变更代码上保留。当堆叠的基线分支如main前进后对未变更的堆叠执行Rebase stack会保留已有审批即使仓库配置了“新提交使旧审批失效”。这解决了一个长期痛点基线更新不应让评审者的工作白费。变基后的提交保持签名。Rebase stack会创建签名的替换提交保留原始作者信息。部分合并后的自动变基在分支规则要求签名或任一原始提交已签名时也会对替换提交签名。对启用签名校验的仓库这是能否采用堆叠的前提条件。绕过权限适用于堆叠。拥有绕过仓库规则权限的用户可以用该权限合并堆叠中最底部的未合并PR。合并行为更一致。堆叠现在作为一个合并组进入并通过合并队列。使用merge commit方式时GitHub为每个PR创建一个合并提交而不是为整个合并组创建一个。分支堆叠自动重定向。当堆叠的基线分支被删除时GitHub自动重定向堆叠而不是关闭其底部PR。这支持一个堆叠从另一个堆叠分出的工作流。自动合并逐步推出。堆叠可设置为在仓库合并要求满足后自动合并选中一组PR待全部就绪后一起合并。该能力将在未来几周内逐步推出。导航与自动化堆叠信息现在常驻PR页面头部也可从PR列表查看所属堆叠的详情。键盘快捷键ShiftJ与ShiftK可在堆叠内切换PR。时间线会记录PR加入或移出堆叠的事件pull_request webhook在PR加入堆叠时新增stacked动作。GitHub CLI的gh stack扩展现在支持Git worktrees并改进了初始化、检出和导航速度。对需要在多个分支间频繁切换的开发者worktrees支持意味着不必反复stash或重建工作区。与AI批量生成代码的配合AI编程工具如Copilot、各类Agent的典型输出是一个包含大量改动的补丁。直接把它塞进单个PR评审者面对的是混合了重构、功能、测试和格式化的整体很难逐项判断。堆叠PR提供了一种拆分思路按逻辑层次把AI产出切成若干小PR。例如第一层是接口与类型定义第二层是实现第三层是测试与文档。每层独立评审评审者可以在小范围内判断正确性而不是在千行diff中寻找关键改动。需要明确的是官方资料并未提供“AI生成代码应如何拆分堆叠”的具体规范。上述拆分方式属于工程实践建议团队应根据自身代码结构和评审习惯调整。企业落地建议先确认仓库规则兼容性。如果仓库启用了“新提交使旧审批失效”或强制签名GA版本的Rebase stack保留审批与签名提交能力是采用堆叠的关键。建议在试点仓库先验证这两项行为。把合并队列纳入流程。堆叠作为单个合并组进入合并队列意味着队列配置会直接影响堆叠的落地节奏。使用merge commit方式时每个PR生成一个合并提交提交历史与单PR合并更接近。用webhook和CLI做自动化。pull_request webhook的stacked动作可用于触发CI或通知gh stack对worktrees的支持适合在本地并行处理多个堆叠分支。控制堆叠深度。官方资料未给出推荐深度。从工程角度看过深的堆叠会增加变基和冲突处理的复杂度建议从2到4个PR的小堆叠开始根据团队反馈调整。关注自动合并的推出节奏。自动合并将在未来几周逐步推出团队可先规划好合并要求待能力可用后直接启用。可用范围堆叠PR在所有github.com计划上可用并将包含在即将发布的GitHub Enterprise Server版本中。官方文档提供了功能说明和入门指引。对于正在被AI生成代码淹没评审流程的团队堆叠PR不是银弹但它把“大PR评审”这个瓶颈拆解成了可管理的小步骤。真正的收益取决于团队是否愿意调整评审习惯把“一次评审一个逻辑变更”变成默认做法。