GitHub 堆叠式 PR 把 1000+ 行 AI diff 拆成可独立审阅的链：瓶颈从「写」转到「读」的硬约束

GitHub 在 7 月 31 日把堆叠式 Pull Request（Stacked PR）推上公开预览，8 月 4 日的工程博客给出了一个完整的"AI 生成巨型 diff 怎么变可审查"工作流。这不是新功能，是 GitHub 第一次正面承认：当 agent 一次性生成 1000+ 行代码时，传统的"一个 PR 一段对话"模型已经失效。

技术形态并不复杂：堆叠 PR 是同一仓库内一组有序链接的 PR，每个 PR 面向下方 PR 的分支，形成自底向上合并的链。底层先合，上层自动 rebase 跟随。GitHub.com 提供原生 UI + 堆叠地图，CLI 通过 gh-stack 扩展（GitHub CLI 2.90.0+、Git 2.20+）管理生命周期，AI agent 侧通过 gh-stack skill 让 Copilot 等直接调用 gh stack 命令自动拆分。重要的是：分支保护和必需检查贯穿整条链，堆叠不绕过任何合并门禁——这是 GitHub 把"安全治理"和"工作流升级"绑在一起的关键动作。

GitHub 博客里的案例把痛点摆得很直白。一个 1000+ 行的 AI 生成 diff 被拆成 L1（数据模型）→ L2（API）→ L3（接线层）→ L4（UI）四层，每层分配不同审查者；底层先行 review 并合并，上层以它为基础继续 review。这跟 WHOOP 工程师 Mayank Saini 的实际体验对得上："过去一个大变更意味着一个没人想 review 的巨型 PR，现在变成一叠小 PR，reviewer 能真正跟上思路，而且整条链一次合并完成。"

值得追问的是为什么这件事现在发生。AI 编程压低了"生成代码"的成本，"审查代码"的成本却没变——一个工程师看 1000 行 PR 不会比看 200 行快多少，但 agent 几分钟就能产出 1000 行。瓶颈从写转移到读，整个开发流水线的吞吐被审查侧卡死。Stacked PR 不是"鼓励小 PR"的纪律话术，而是把"小步快跑"做成平台默认——agent 决定拆多少层、每层多大、谁 review，堆叠地图让 reviewer 在并行浏览各层时仍能看清依赖关系。

四个使用上的真问题：

• 拆层不是免费的——下层变更后上层必须 rebase 解决冲突，CI 不能跳；
• 测试必须跟到每一层，而不是整链做完再跑；
• 上层代码未合主干前不能当作"独立可发布"使用；
• gh-stack skill 的"自动拆层"取决于 prompt 质量，不是魔法——reviewer 仍然要看每层的实际改动。

判断：Stacked PR 跟 OpenAI Codex Sol/Luna 分层（8 月 3 日话题）、Cloudflare ADLC（8 月 4 日话题）构成同一波浪潮——当 AI 把"实现"环节压缩到接近零，工程管理的所有阶段都被迫重写。GitHub 选堆叠而不是别的形态，是因为它仍然长在"以 PR 为协作单位"的传统里，没有发明新的工作流术语；这是最小阻力路径，也是生态兼容性最好的路径。对已经在用 Graphite、Sapling、git-branchless 的团队来说，GitHub 原生堆叠未必能完全替代成熟三方工具，但 GitHub 的入场意味着"堆叠"从"高级玩法"变成了"默认动作"——等到 GA 时，原生堆叠极可能成为新仓库的默认工作流。

原文：https://github.blog/engineering/turn-one-giant-ai-generated-pull-request-to-a-reviewable-stack 文档：https://docs.github.com/pull-requests/get-started/stacked-prs-quickstart