AI 编程最尴尬的场景，已经不是代码写不出来。
而是 Agent 一口气改了十几个文件，测试也全绿，最后生成了一个几百行的巨型 PR。作者觉得任务完成了，Reviewer 打开页面却不知道从哪里开始。
代码生成变快以后，真正变慢的是审查。
GitHub 最近把 Stacked Pull Requests 推进公测。它允许一个功能拆成一组有依赖关系的 PR，每一层单独审查、单独跑检查，最后再整体合并。GitHub 官方也承认，AI 提高开发效率后，PR 变大已经开始成为审查瓶颈。
巨型 PR 隐藏了修改顺序
一个完整功能通常不是一次改动。
它可能先增加数据结构，再修改服务接口，然后接入前端，最后补测试和文档。把这些内容全部压进一个 PR，Reviewer 看到的只是最终结果，中间的因果关系被抹平了。
Stacked PR 的价值，是把这条关系保留下来：
第一层修改数据库结构；第二层接入服务逻辑；第三层调整界面；第四层补齐测试。
后面的 PR 建立在前面的 PR 之上。每一层都足够小，可以单独理解，也可以单独讨论。前一层合并后，后面的分支会自动重新定位，减少手工 rebase 的负担。
这不是把一个大 PR 切成四个标题，而是把修改之间的依赖关系显式写出来。
AI 生成速度越快，审查粒度越要变小
过去，一个工程师一天写一个 PR，PR 大一点还能忍。
现在 Agent 可以同时推进多个任务。如果仍然要求它把所有修改揉成一个最终 PR，团队得到的不是更高效率，而是一座更难检查的代码山。
更合适的做法，是让任务边界和 PR 边界对齐：一个 Agent 负责数据结构，一个 Agent 负责服务实现，另一个 Agent 负责测试和回归。
每个 PR 都要有明确目标、独立检查和清晰的失败条件。Reviewer 不需要一次理解整个功能，只需先判断当前这一层是否成立。
当然，Stacked PR 解决的是组织修改和审查的问题，不会自动让 AI 写出正确代码。每一层仍然需要测试、分支保护和人工判断。GitHub 只是把工具放进了平台，真正的收益取决于团队是否愿意改变 PR 的拆分方式。
AI 让代码产生得更快，Stacked PR 让人重新有机会把代码看懂。
