一个AI编码智能体花三分钟喷出的变更请求，让你的团队花了整个下午都没审完——不是因为代码质量差，而是因为它把一切揉进了同一个diff。数据模型、API端点、业务逻辑、前端组件，2000行，一个PR，一个审查者。结果谁都没看全，点了“LGTM”就合并。这种事情正在吞噬工程团队的信心，而GitHub内部给出的解方，比大多数人的第一反应要聪明得多：别让AI生成的代码块骗过你的审查直觉，先把它拆开。
人脑不是为巨型diff设计的
上下文负载超过了工作记忆
心理学里有个老词叫“魔法数字七”，人的工作记忆一次能处理的独立信息块大概就五到九个。一个变动超过一千行的PR，往往交叉着三四层不同的抽象，审查者脑内的临时缓冲区早就溢出了。你看得见数据表结构的添加，却忽略了旁边service层悄悄改掉的错误处理分支；你盯着新接口的字段校验，已经没力气再看前端表单状态机是否同步。这不是态度问题，是认知资源耗竭。
AI编码智能体加剧了这个问题。它没有“每次只做一件事”的自觉，它只是忠实地把你口头提的一大段需求一股脑变成代码。人类开发者在一次提交里塞进太多东西时，至少还会感到一丝愧疚——智能体不会。于是我们拿到了更多、更大、更黏稠的diff，审查变成了过场。GitHub那篇工程博客上来就戳破这个疮疤：当你把AI当码农用的时候，你得到的是速度；当你不对它的输出做结构性拆分的时候，你丢掉的是安全。
LGTM成了逃避压力的快捷键
有一个隐蔽的信号：如果你发现团队里“Looks Good To Me”的出现频率与PR体积正相关，那说明审查已经失效了。不是大家不负责任，而是面对一大坨难以消化的变更，大脑会本能地寻求封闭。点一个approve是最小阻力路径。更糟的是，巨型PR常常只绑一个审查者，因为主动要求更多人来审会延长合并窗口，而所有人都急着交付。
这种做法在手工编码时代已经够呛，在智能体生成巨型补丁的时代，就是在埋地雷。你相当于把一个未经切分的、由概率模型编织的逻辑块直接放行到主分支。任何安全审计、架构review都会被绕过。GitHub的工程师们意识到了，问题的根源不在AI的代码生成能力，而在我们接收代码的流程。把唯一的审查者当成巨量输出的最终守门员，这是对人类注意力的不尊重。
拆成灌溉渠，而不是拦住洪水
L1：数据层先站稳
堆叠式PR（stacked PR）的哲学很简单：一个PR只干一层的事，层层依赖。GitHub在文章中拿一个典型场景做了示范：从数据库迁移、实体定义开始，这就是L1。只包含schema变更、新的migration文件、模型属性，不牵涉任何业务逻辑或HTTP层。审查者只需要问一个问题：这个数据模型对吗？命名合理吗？索引加对了吗？
这一步耗时最短，却奠定了后续所有层的骨架。因为是整个堆叠的地基，L1的reviewer往往需要由最熟悉领域模型的资深开发者来担任。无论AI生成了多么花哨的关联查询，如果这里的关系和约束定义有偏差，后面全是空中楼阁。文章里用一个很实的建议把这种感觉固定下来：L1合并之前，所有人不要写L2。
L2：把契约亮出来
数据模型就绪后，L2负责暴露API契约——GraphQL的schema、REST端点的路径和入参出参结构。只定义接口，不实现。这一层的价值在于让API的正确性在落进代码之前先被质疑一次。你可以把L2交给前端或App端的同事审查，他们会比对实际消费场景，而不是对着空空的接口实现拍脑袋。
这是堆叠式PR相比传统“feature分支里拆commit”高明的地方。每个堆叠节点（stacked diff）都是一个独立的审查靶点，可以分配最适合的审查者。L2的审查者不需要看懂数据库细节，他面对的只是一个干净的类型描述。GitHub的实践团队特别强调，API层必须“短小而稳定”，因为一旦L2合并，后续层的改动只会增加实现，不会轻易修改接口签名。
L3：接线与业务逻辑不再隐形
最难审的永远是业务逻辑。在巨型PR里它像沙子一样铺满所有文件，而在堆叠式PR里，L3精确地抓住“接线”——把L1的模型和L2的接口链接起来，加入校验、错误映射、权限检查。因为L1和L2已经固定了形状，L3的diff只含有核心业务逻辑的增量，体积一下子就下来了。
这时候可以拉上同时懂领域和代码的同事来审。注意力被聚焦在几百行上，而不是两千行。GitHub博客里给出了一种轻量级的心理技巧：把L3看成“实现意图与规范之间的翻译层”，审查者的任务就是看翻译有没有走样。这种命名本身就是减轻认知负荷的手段。
L4：皮相归皮相
最上一层L4是UI——组件、样式、交互状态。在传统大PR里，UI变更总是跟模型、接口混在一起，审查者一会儿看到一个div的class名，一会儿又撞上一个sql查询，两者的风险完全不一个量级。L4独立出来后，UI审查可以交给设计敏感度高或前端主导的工程师，他们只关注视觉还原、无障碍和交互逻辑，不会被后面的业务逻辑劝退。
四层走完，一个原先让人想装病的巨型PR变成了四个可审查的节点。GitHub的文章不止于画图，他们甚至给出了配合gh-stack CLI的具体操作：用gh stack管理依赖分支、提交顺序、以及当L1需要改时如何向下逐层rebase。这种工具化让堆叠式工作流从理论降落到日常命令行里。
gh-stack不是新玩具，是生存工具
依赖链的管理不再是手工地狱
老工程师们可能会说，拆成多个分支早就有人做过，但手动维护分支依赖树简直就是折磨。这正是GitHub推出gh-stack背景——一个第一方CLI插件，用于创建、更新、导航堆叠PR。它的核心能力是追踪“父分支→子分支”的关系，并在父PR被合并后自动将子PR的基分支改到主分支，而不是让子PR指向一个已经消失的旧分支。
文章演示了最常用的流程：gh stack create 通过标准输入依次创建L1到L4的分支；gh stack restack 在你修改L1后自动将变更逐层重放到L2、L3、L4，省去你手工cherry-pick或rebase的痛苦。在AI生成代码频繁改动的场景下，restack掉用率会非常高，因为智能体输出的代码经常需要你微调底层逻辑，而一个底层的微调必须向下广播。
审查指派的并行化才是真正提速
堆叠PR的价值不止于降低单次审查认知负荷，它还解锁了审查的并行性。你可以同时让数据库专家审L1、前端同事审L4，而不是让一个人被所有层绑架。GitHub的工程文化深谙这一点——审查不是码农的消遣，它是质量关隘，值得专门分配人力。
这里面有一个反直觉的点：很多人以为堆叠会让审查变慢，因为要等上一层合并。实际上，只要L1和L4的审查是独立进行的，而L2、L3有适当的重叠，总吞吐时间是下降的。文章提到一种“审查流水线”，每个堆叠节点进入“Ready for review”时就立即拉对应的人，不等所有层准备完毕。这种异步感，恰好是单纯在巨型PR上添加多个审查者所达不到的。
把堆叠思维写进AI对话里
别让智能体来决定你的PR结构
一个容易掉进去的陷阱是，开发者把自己当成了AI的“提示词发射器”，智能体返回啥就建一个PR提交。GitHub的建议很直接：你给AI的规划，就得带着堆叠的结构。当你向Copilot Workspace提出一个全栈需求时，先在心里过一遍L1到L4，再把需求分层喂给智能体，甚至要求它分阶段输出：先输出数据模型方案，等你确认再生成API契约，接着是接线，最后是UI。
这种“人定义结构，AI填充内容”的模式，比“AI生成一切，人挑错”的效率高得多。文章没有直说，但言下之意很明白：如果你不会拆解一个变更，那AI只会放大你的组织无能。
人机审查的新常态
有了堆叠式PR，你甚至可以把某些层的初步审查交给AI本身。比如用代码分析工具检查L1的schema变更是否引入了性能隐患，或者让另一个智能体审查L3的逻辑一致性。但如果底层还是那个巨型PR，这些都是空谈。堆叠式PR不仅是人类审查者的解药，也是机器审查生效的前提。
最终，GitHub这篇博客传递的不是一个教程，而是一种立场：AI编码越快，人越要变成拆解者和架构审查者。审查不是什么妨碍速度的官僚主义，它是工程面对不确定性的最后防线。用好堆叠，你才不会被自己的AI生成的代码拍死在代码库里。
