把 AI 生成的大型 PR 拆成可审查的堆叠 PR：GitHub 官方实践
2026/08/05 00:47阅读量 2
GitHub 官方博客指出，AI 编码代理在提升效率的同时，也容易默认生成数千行的大型 PR，增加审查与合并难度。文章提出用 GitHub 堆叠 PR（stacked pull requests）将功能按逻辑分层拆解为有序 PR 链，并结合商品搜索功能示例说明具体做法。
事件概述
AI 编码代理能快速生成完整功能实现，但其默认输出往往是一个包含数据模型、API、客户端 UI、空状态等全部改动的大型 PR，可能超过 1000 行 diff。这种 PR 难以审查，也容易被拖延合并。
Gartner 预测，到 2028 年，编码代理将在软件开发生命周期的每个阶段带来 50% 的生产力提升。但代理并未消除“如何组织 PR”的问题，反而放大了这一选择的重要性。
核心信息
- 单一大 PR 的常见组成：新数据模型及种子数据、API 路由与校验、客户端接线、UI 及空/回退/错误状态等，全部挤在一个巨型 diff 中。
- 大型 PR 的问题：审查者失去上下文，反馈质量下降，合并变慢，手动处理冲突耗时，最终功能可能在低质量审查下合入。
- GitHub 堆叠 PR 的核心思路是“分解”：不试图用一个 PR 解决整个 issue，而是把功能拆成多个逻辑层，并识别它们之间的依赖链，形成一组有序、可单独审查的 PR。
示例：为购物助手添加商品搜索
文章以“给购物助手添加商品搜索”为例。初始状态是：
- 一个模拟 AI 助手，响应来自随机行生成器；
- 商品数据硬编码且散落在各组件中；
- 没有目录模块、没有 API、没有数据层。
典型流程是：创建功能分支，分配给编码代理，获得完整实现代码和更新的测试，然后推送并打开一个 PR。但这类 AI 生成的 PR 描述往往“长而浅”，无法帮助审查者理解改动。
文中模拟审查者面对的情况是：1,721 行变更，描述信息不足，只能暂时搁置审查。
采用堆叠 PR 后，代理可以按照逻辑依赖链，将原本落入单个巨型 PR 的工作拆分为一组更小的 PR，让每一步都更容易审查、验证和合并。