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列表查看所属堆叠的详情。键盘快捷键Shift+J与Shift+K可在堆叠内切换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评审”这个瓶颈拆解成了可管理的小步骤。真正的收益取决于团队是否愿意调整评审习惯，把“一次评审一个逻辑变更”变成默认做法。