AI 写代码太猛怎么办？GitHub 堆叠 PR 把千行 diff 切成四层审查

GitHub 工程团队最近公开了一个针对 AI 编码智能体的代码审查工作流，核心思路是把一次动辄上千行的大 Pull Request，按照职责切成多层独立的“堆叠式 PR”（stacked PR）。过去 AI 写代码最大的尴尬，是智能体一口气把整块功能跑完，留下一坨谁也不敢轻易点的 diff；现在这套分层策略，是想把这坨代码重新变回人类能消化的形态。

过去一年里，Copilot 类编码助手已经升级为能跑多文件、跨模块改动的 Agent。任务越复杂，生成出来的代码量越大，一个 PR 里夹着数据迁移、接口变更、组件重写的情况越来越常见。一旦 diff 超过几百行，传统“一行行看”的审查方式就会崩溃，评审者要么敷衍通过，要么直接打回重写。

核心做法：分四层把巨型 PR 拆成可审查积木

GitHub 把一次典型的 AI 生成改动抽象成 L1 到 L4 四层：- L1 数据层：schema、迁移脚本、种子数据- L2 API 层：路由、请求校验、返回结构- L3 接线层：把 API 接到业务逻辑- L4 UI 层：组件、表单、交互每一层单独开 PR，单独配 CI，单独指派审查人。

这样做的好处是显而易见的：审查者的注意力从“读完一千行”变成“读懂一个分层”，认知负担被强行降下来。更重要的是，下层 PR 的接口一旦确定，上层 PR 的实现就被锁住，后面即使 AI 重新生成一版 UI 代码，也不影响底层审查记录。

为什么这次不一样

把一个大 PR 拆成多个串联的小 PR，本身在开源社区早就有过讨论。GitHub 这一版的差异在于，它专门为 AI 智能体的产出做了适配——每一层都假设上游和下游还在被修改，因此审查逻辑要更宽容，合并顺序也要更灵活。

对开发者来说，这套流程意味着：再也不能“一键合并 AI 写的代码”了。AI 输出的代码必须被拆分成可解释的步骤，每一步都要回答“它在做什么、改了哪些文件、为什么这么改”。这其实把审查责任重新压回了 AI 工具的设计者和使用者身上。

对企业和团队的影响

对中型以上团队而言，最直接的成本变化是 CI 时间和审查人力的增加——一个原来跑一遍的 PR，现在要跑四遍。GitHub 在文章里也承认，这种分层审查更像是把成本从“事后救火”前移到“事前预防”。它更适合对线上稳定性要求高的金融、SaaS 团队，而对快速迭代的初创团队可能是负担。

堆叠式 PR 想要真正落地，离不开工具支持。社区里已有 gh-stack、Graphite 这类命令行工具可以半自动拆分 PR，但和 AI 智能体深度集成的工作流还很少。GitHub 这次公开流程，更像是给整个行业画了一张路线图：未来 AI 编码工具不仅要会写代码，还要会“按层交付”。

中文用户该关注什么

即使你不用 Copilot，只要团队开始接入任何 AI 编码 Agent，这套分层思路都值得借鉴。中文开发者更常面对的是：AI 给出的注释是英文、改动跨越多个目录、合并冲突频发。提前在团队里约定“AI PR 拆分规范”，比事后争论“该不该合并”要省心得多。

当然，这套方法也有副作用。分层越多，PR 之间的依赖关系越复杂，一旦底层设计要返工，上层所有 PR 都会作废。另外，AI 智能体本身不一定知道怎么“按层”生成代码——这意味着工具链需要配套演进，否则分层审查只能靠人工维护。

后续值得观察三件事：第一，GitHub 是否会把堆叠式 PR 做成一键功能；第二，Cursor、Cline、Trae 等中文用户常用的 AI IDE 是否跟进类似拆分策略；第三，企业是否能围绕“AI 生成代码的可追溯性”形成新的合规要求。AI 写代码的速度已经不是瓶颈，能不能被安全地合并，才是下一阶段的真问题。