GitHub把PR拆成流水线，治的是审查跟不上代码的病

GitHub把「堆叠式Pull Request」(Stacked Pull Requests)做进了公开预览。以前一个大改动往往要塞进一个几千行的巨型PR，等一个人慢慢审完才能合。现在可以拆成一串有依赖顺序的小PR，一层接一层，分头审、并行审，审完再一键合并整条链路。

这套玩法在圈内不新鲜。Graphite、Sapling这类第三方工具做「堆叠式开发」已经好几年，一直游离在GitHub原生流程之外，得单独装CLI、走额外平台。GitHub现在把它收进自己的审查、检查、合并规则里——真正推动这件事的，不是分支管理有多难用，而是AI把「写代码」这一步的速度拉起来之后，「审查」这个环节开始跟不上。

怎么拆、怎么合

三条路径摆在一起看更清楚：

GitHub这次干的事，是把第二条路径的能力搬进第三条——不用再为了堆叠开发单独维护一套工具链。

机制不复杂：先开一个基础分支和PR，再在它上面接下一个分支、开下一个PR，一层压一层。打开栈里任意一个PR，只看到当前这一层的diff，顶部有张「栈地图」标出它在整条链路里的位置——团队成员可以分头认领不同层，互不干扰，不用排队等一个人审完整个大PR。

合并同样灵活。点最上面已经就绪的PR合并，会把它和下面所有未合并的层一次性合入；只想先落地底下几层也行。合并之后，上面还开着的PR会自动rebase、自动重新指向新的目标分支，不用手动改基准分支。

分支保护、必需检查、合并规则照常生效，走栈流程不会绕开审批——这点GitHub说得很明白，也是它敢把这套东西放进原生流程、不留给第三方工具的底气。

谁该用，谁先别急

这次更新对两类团队最直接。

负责大型功能交付、日常要审大改动的团队，可以把功能拆成栈，按层分工审查——一个人扛几千行diff的场景会少很多。但前提是团队先商量清楚「怎么拆」，拆分逻辑不统一，栈本身会变成新的协调负担，只是从「大PR没人敢审」挪到了「小PR谁先谁后」。

正在大量用AI编码工具的工程负责人，更该盯着这个功能。GitHub官方通稿里提到一个说法：TED的CTO Andy Merryman说，AI让开发者的产出暴涨，反而把审查者堵住了。这是厂商给出的案例，不算独立验证的普遍结论，但方向站得住——审查跟不上产出，是这轮AI提效最先撞到的墙。

堆叠PR能把AI吐出来的大改动切成可审的小块。但AI生成代码往往缺清晰的层次边界，拆分逻辑还得靠人设计，不能指望模型自己把改动拆成整齐的栈。

功能目前分批灰度所有仓库，还是公开预览，不是全量GA；Merge Queue对堆叠PR的支持要再等几周才跟上。想现在用，可以走github.com网页、GitHub移动端、gh-stackCLI扩展或GitHub Copilot里的对应skill建栈管栈；重度依赖Merge Queue的团队，这几周最好先观望。

补的是摩擦，不是复杂度

老子讲「合抱之木，生于毫末」，堆叠式PR做的是反过来的事：把已经长成合抱之木的大改动，拆回一根根毫末，方便一根根查。方向没错，但这次改的是维护一条栈的手工成本——自动rebase、一键合并，省的是体力活。

栈该建几层、每层怎么切、依赖顺序怎么排，还是人的活。拆得好是清晰的分层审查，拆得烂就是一串互相拽着的小PR，谁改了底层谁负责通知上层，这种协调成本GitHub目前还接不住。

接下来两件事最值得盯：一是Merge Queue什么时候补上对堆叠PR的支持，二是等所有仓库都亮灯之后，每层PR大概率都要触发一次独立CI，团队的CI成本会不会跟着涨——公开预览阶段还看不出这笔账。

GitHub把传送带修好了，分不分层、分几层、分得对不对，决定权还在写代码的人手里。