标题：把AI生成的大型Pull Request拆成可审查的提交栈
标题：把一份 AI 生成的巨型 PR 拆成可审阅的 PR 栈
回想一下你最近上线的那个大功能。说实话，你是把它硬塞进一个巨型 PR，还是拆成了一串小范围 PR？多年来，你一直默默面临两难选择：要么看着一个 PR 越滚越大，大到审阅变成噩梦；要么拆成一连串小 PR，然后你得像个保姆一样维护它们——手动同步、每次底层一改就处理冲突。两种选择都有代价。一个难审，一个难维护。你当时的选择，不过是偏向痛苦更少的那一边。
现在把 AI 编码代理（coding agent）加进来。它们生产力极高，根据 Gartner 的预测，到 2028 年将在软件开发生命周期的每个阶段带来 50% 的效率提升。但它们并不能替你决定如何组织 PR。恰恰相反，它们把这个决定变得更重要了。
下面用一个例子，看看怎么用“堆叠式 PR”（stacked pull requests）来简化代码审阅。
具体场景：给购物助手加上商品搜索
假设你发了一条提示词，要求给购物助手加上商品搜索功能，然后走开几分钟——真的就几分钟——回来之后开始审阅、引导、批准。但仔细看看，这一个 PR 里通常都塞了些什么：
- 一个新的数据模型及其种子数据
- 一条 API 路由及其校验逻辑
- 客户端的接线、UI、空状态/兜底状态/错误状态
……所有这些，甚至更多，全挤在了一份 1000 多行的巨型 diff 里。由于 AI 代理在很大程度上是依据多年来人类编写代码的方式训练的，这种“一锅烩”的方式就是它们默认的交付模式。
我们来推演一下这个过程。你想给一个已有的 Web 应用加上商品搜索，初始状态是这样的：
- 一个模拟 AI 助手，回答来自随机行生成器
- 不一致的商品数据，硬编码散落在各个组件里
- 没有目录模块，没有 API，没有数据层——什么都没有
为了开发这个功能，开了一个 issue。一个典型的流程是：创建功能分支，把它分配给一个编码代理（或者多个自定义代理），拿到整个实现代码和更新后测试的第一版草稿……
然后你开始读代码（好吧，你也许真的读了代码）。