一句话定义
Stacked Diff（堆叠式变更，也写作 stacked changes、stacked PRs）是一种版本控制工作流：把一个较大的代码改动拆成若干个互相依赖、必须按顺序叠加的小改动，每一层单独提交、单独评审、单独合并。
它长什么样
拿装修打比方。装修一整套房子，你不会等全部完工才请人验收，而是一间一间来：先改水电，验收通过；再刷墙，它建立在改好的水电之上；最后铺地板，又建立在刷好的墙之上。每一层都踩着下面一层往上垒，这就是"堆叠"。
代码里也一样。比如要给系统加一个"导出报表"的功能，可能要动三块东西：数据库加字段、后端加接口、前端加按钮。一次性写成一个几千行的 diff，评审人打开就头疼，评论散在各处，改一个地方要全部重看。堆叠式变更会拆成三层：第一层只加数据表和迁移脚本；第二层基于第一层，加接口；第三层基于第二层，加界面。评审人每次面对的只有几百行，思路清晰得多。
和相邻概念的区别
| 做法 | 评审粒度 | 依赖关系 | 主要代价 |
|---|---|---|---|
| 巨型 PR | 一个几千行的大 diff | 无 | 评审疲劳，一改全动 |
| Stacked Diff | 每层几百行 | 链式，严格按序合并 | 返工要层层重排，依赖工具支持 |
| Feature Flag | 代码直接进主干，靠开关隐藏 | 无 | 开关越积越多，清理成债 |
要注意它和"小 PR"不完全是一回事：小 PR 之间通常互相独立，谁先合都行；堆叠式变更是链条，抽掉中间一层，上面几层都得跟着调整。这个动作业内叫 restack（重排）。Google 的 Gerrit、Meta 的 Sapling 等内部工具链长期支持类似模式，不少代码托管平台也提供堆叠式 PR 的可视化支持。
为什么在智能体时代重新流行
过去几年，堆叠式变更更像是大厂内部的"高级玩法"，小团队嫌麻烦。但智能体（agent）改变了产出速度：一个任务交给模型，它可能一口气写出十几个文件、上千行改动。人审不过来，就会退化成"看一眼就点合并"，评审这道闸门形同虚设。
Anthropic 的工程团队曾公开提到，内部已经不再把 Git 当作源码管理的主力，而是围绕"智能体高频、大批量写代码"重建了一套流程——核心思路正是把一个大改动组织成一串可以逐个评审、逐个落地的变更。Git 那套"分支 + 大合并"的模型，是为人类低频提交设计的，在机器产出的量级下开始吃力。具体实现细节以其官方说明为准。
对从业者的实际意义有三点：一是把评审拉回人的认知负荷之内，每层都能真正读懂；二是反馈变快，不必等整个大 PR 通过才继续往下写；三是每层可以单独跑测试，出问题时定位到具体一层，而不是在几千行里大海捞针。
对普通职场人，这套思路同样能借用：写一份长方案、改一份大文档时，别憋到最后交一份"终稿"，而是一段一段确认，让协作者始终跟得上你的思路。