GitHub 宣布公开预览 Stacked Pull Requests：将大型软件变更拆成一组相互依赖的小型 PR，各自独立审查、独立合并。这不是一次普通的体验优化，而是对「AI 生成速度」与「人工审查容量」严重失衡的一次正面回应。
故事的开端很简单：AI 编码助手能在几分钟内生成大量代码，但代码审查仍然主要由人工完成。当单个 PR 动辄包含数百乃至数千行代码时，要求审查者一次性理解几十项互不相关的更改，几乎是在挑战人类认知的极限。
于是 GitHub 做了一个直接的选择——
数百到数千行的一次性合并，审查者需要同时理解全部改动，任何疏漏都可能引入缺陷。
一个大型功能按逻辑单元拆成多个小 PR，每个 PR 代表单一逻辑步骤，逐个审查、逐个合并。
怎么看这张卡：左右对照的是「一次看完」与「分步看完」两种审查心智负担。Stacked PR 没有改变审查者数量，改变的是每次审查需要理解的范围。
更关键的是，这套机制没有要求团队改变工作习惯：现有分支保护规则、审查工作流和合并策略全部保留。开发者不需要迁移到新平台，也不需要学习一套独立流程。
要理解这次发布的重量，得先看清开发速度的失衡现场。AI 编码助手的产出速度已经按「分钟」计算，而人类审查者的带宽是固定的。
AI 编码助手几分钟内即可生成大量可直接投入生产的代码。
审查者需要在数千行的单体 PR 中，同时理解几十项互不相关的更改。
审查仍由人工承担，速度与质量正在成为软件交付的主要瓶颈。
审查质量，正在决定 AI 是提升还是降低软件质量。
这并非猜测。近期针对智能编码工具早期采用情况的研究发现：AI 生成的拉取请求正变得越来越普遍，但成功的集成仍高度依赖人工监督——大多数项目在合并前，依然需要一位有经验的审查者验证 AI 生成的代码。另一项针对从业者的研究则直接指出，代码审查已成为决定 AI 价值能否落地的关键控制点。
注：以上结论来自对智能编码工具采用情况的多项调研，研究样本覆盖不同规模团队；核心信号一致——AI 写得越多，人工审得越吃力。
Stacked Pull Requests 思路非常朴素：既然审查速度追不上生成速度，那就让每次要审的东西变小。每个 PR 只代表一个逻辑步骤——引入新 API、更新数据库 schema、实现一个业务功能。范围越小，越容易理解，越容易验证。
一个典型的三层变更栈看起来是这样：
读图方式：越底层的 PR 越先被审查和合并；上层的 PR 依赖下层，但可以提前开发、排队合并。
一个诚实的注脚：分层开发并不是万能钥匙。它更适合可以被切分为逻辑独立步骤的增量变更；对于跨系统的大规模重构，「切分层级」本身可能变成另一种维护负担。GitHub 保留了原有保护规则与合并策略，也说明这是一种兼容性扩展，而非强推新范式。
「分层开发」在 GitHub 上是新事物，在行业里却早已有迹可循。Meta 通过内部开发工具长期推广 stacked diffs，Graphite 和 Sapling 等公司也围绕类似工作流构建了专用工具。此前 GitHub 团队若想采用这套模式，只能依赖第三方工具或手动管理分支。
内部工具推广「分层差异比较」（stacked diffs），是这套模式最早的规模化实践者。
以 stacked PR 为核心构建的代码审查平台，在开发者社区中已经形成稳定的用户群。
围绕分层工作流构建专用版本控制工具，覆盖提交、审查与合并全流程。
这些先行者证明了模式的可行性，但也暴露了共同的痛点——需要额外的工具链与工程配置。GitHub 这次直接把该能力集成进主平台，由母公司统一承担底层实现，团队不再需要引入额外的工程依赖。门槛，第一次被真正降了下来。
把目光拉远，这次发布与 GitHub 近期的动作——Copilot 编码助手、CodeQL 增强、构建签名认证、基于 MCP 的密钥扫描——指向同一个方向：软件工程的未来，不再是生成更多代码，而是创建让人类与 AI 安全、透明地大规模协作的工作流。
在代码生成日益自动化的时代，审查、理解并安全地集成 AI 产出的能力，正在成为高绩效工程团队最稀缺的竞争力。
该功能已进入公开预览，开发者可以在 GitHub 仓库设置中申请开通，并按依赖顺序创建 Stacked Pull Requests。