#7 流程的阵痛——当瓶颈从「写代码」变成「Review 代码」

ec 为什么重要、怎么写、怎么用、以及它的边界在哪里。本篇离开 spec 本身，进入一个更大的问题：当 Agent 让代码产出速度暴增，你的流程接得住这个速度吗？

你的团队上个月全面接入了 AI 编码工具。结果立竿见影——每个开发者的代码产出翻了两倍。PR 数量从每天五六个涨到十五六个。站在产出指标看，这是一场胜利。

然后瓶颈出现了。

Review 队列从每天五六个 PR 涨到十五六个，但 review 的还是那几个人，用的时间还是那么多。CI 从偶尔红变成了天天红——不是因为代码质量下降了，而是因为每次 PR 的改动量更大了，测试覆盖面更广了，一个改动触发五个服务的集成测试。原来两天一次发布，现在一周都发不出去，因为 release candidate 的 review 积压了二十几个待合并的 PR。

团队 lead 看着看板发呆。产出翻了三倍，但交付速度反而慢了。这不对。

DORA 看到了同一件事

你的团队不是个例。DORA（DevOps Research and Assessment）在 2024 年发布了一份专门报告，研究生成式 AI 对软件开发的影响。数据来自大规模行业调查，结论直白得让人不舒服：

AI adoption 每提高 25%, delivery throughput 下降 1.5%, delivery stability 下降 7.2%。

这不是一两个团队的不幸巧合——这是行业层面的系统性信号。AI 让代码产出更快了，但交付速度反而下降了，稳定性也下降了。

DORA 的根因分析指向同一个机制：AI 让开发者生成代码的速度暴增，导致每次提交的 batch size 变大了。更大的 batch size 意味着 review 更慢——不是 reviewer 偷懒，是一个 PR 里塞了太多改动，理解成本指数级上升。更大的 batch size 也意味着测试覆盖更难跟上——一次改动触碰更多模块，集成测试更容易失败，CI 更容易红。结果就是：代码产出快了，但从「写完」到「交付」的链条反而更堵了。

DORA 把这个现象叫「真空假说」（vacuum hypothesis）。AI 成功加速了开发者喜欢的、有价值的任务——写代码、实现功能、解决 bug。但它没有减少那些开发者不喜欢的、枯燥的劳动——开会、走流程、等 review、处理 CI 故障。代码产出端被加速了，但流程消化端没有被加速。两端的速度差，就是瓶颈转移的空间。

这里有一个容易误读的地方。DORA 的数据不是说「AI 没用」——报告同时发现，重度使用 AI 的开发者报告了更高的心流体验、更高的工作满意度、更少的倦怠感。AI 在个体层面是有效的。但个体效率的提升，在没有配套流程调整的情况下，会在团队层面制造新的瓶颈。一个人的产出变成了三个人的量，但 review、测试、发布的基础设施还是为一个人的量设计的。

aros 分析了 10,000+ 开发者、1,255 个团队的遥测数据，发现了一个他们叫「AI 生产力悖论」的模式：AI 高采用团队完成的任务多 21%，合并的 PR 多 98%——但组织级交付指标纹丝不动。代码产出的洪水涌到了 review 门口，review 没有变快，所以交付没变快。

八个月后，2026 年 3 月，Faros 发布了第二份报告，样本扩大到 22,000 名开发者、4,000+ 个团队。需要说明的是，这份报告与 2025 年版是两个独立的行业横截面，并非同一组团队的纵向追踪——但两个截面都指向同一个方向，而且瓶颈不但没有缓解，还在加速恶化。他们把这个模式命名为「加速鞭笞」（Acceleration Whiplash）：

产出端确实在加速——每开发者完成的任务从 +21% 涨到 +33.7%，完成的 Epic 多了 66.2%。但消化端在崩塌：PR review 的中位等待时间从 +91% 飙升到 +441.5%——翻了将近五倍。每开发者的 bug 数从 +9% 加速到 +54%。每 PR 触发的生产事故涨了 242.7%——一次代码合并引发生产事故的概率翻了三倍多。代码 churn（写完不久就被删掉或重写的代码比例）涨了 861%。更令人不安的是，31% 更多的 PR 在没有任何 review 的情况下直接合并进了主干——不是 review 变快了，是 review 队列太长，有人开始跳过这一步。

Faros 2026 报告里最颠覆性的发现不是某个具体数字，而是一个结论：工程成熟度高的组织也没有被豁免。 无论团队的 DevOps 基线多好、DORA 指标多健康、交付流程多规范，Acceleration Whiplash 都会出现。这和 DORA 2025「AI 是放大器，好团队会更好」的乐观判断形成了张力——DORA 说的是相对表现（好团队相对获益更多），Faros 说的是绝对质量退化（所有人都没躲掉）。两者逻辑上可以共存，但 Faros 的数据让 DORA 的乐观显得不够完整——我们稍后会回到这个分歧。

企业基准：Opsera 和 CodeRabbit

第三条证据线来自企业级基准测试。Opsera 在 2026 年发布了覆盖 250,000+ 开发者、60+ 企业的 AI 编码影响基准报告。数据同样指向「产出快了、消化慢了」的分裂：AI 把 time-to-PR（从开始编码到提交 PR 的时间）缩短了最多 58%，但 AI 生成的 PR 在 review 队列里等待的时间是普通 PR 的 4.6 倍。同时，AI 生成代码引入的安全漏洞多了 15-18%。

CodeRabbit 2025 年的对比研究从另一个角度切入同一问题：AI 生成的代码暴露的问题数量是人类写的代码的 1.7 倍，近半数开发者报告调试 AI 输出比修人写的代码花更长时间。LogRocket 的一手对比实验更直观——同一个 REST API 端点，人手写 29 行，Claude Code 写了 186 行，6.4 倍的代码量。高级工程师 review AI 生成代码平均花 4.3 分钟，review 人类写的代码只花 1.2 分钟。而且 review 的性质变了：不再是「这段代码有没有 bug」，而是「这段代码有没有必要」——从验证正确性变成判断必要性，后者更耗心力，因为它需要 reviewer 对系统全局有更深的理解。

三条证据线——DORA 的问卷调查、Faros 的工程遥测、Opsera/CodeRabbit 的企业基准——方法不同、样本不同、时间窗口不同，但指向同一个结论：AI 让代码产出端加速了，但 review、测试、发布的消化端没有同步加速，瓶颈正在从「写代码」转移到「审代码」。

Batch size：被打破的隐藏假设

要理解瓶颈为什么会转移，需要理解一个被传统流程暗中假设的变量：batch size。

Batch size 是指一次代码提交、一次 review、一次部署中包含的改动量。在传统开发中，batch size 受限于人的编码速度。一个开发者一天能写几百行代码，所以一个 PR 通常包含几百行改动。review 者能在 20 分钟内看完。CI 能在 5 分钟内跑完测试。整个流程的吞吐量是按这个假设设计的——review 时间、CI 资源、发布频率，都暗中假设「一次改动不会超过几百行」。

AI Agent 打破了这个限制。一个开发者配上 Agent，一天可以产出几千行代码。Agent 不需要休息，不需要喝咖啡，不需要开会。于是 PR 从几百行变成了几千行，从改一个模块变成了改五个模块。但 review 还是人在做——一个几千行的 PR，review 者需要一小时甚至更久。CI 还是按原来的配置跑——但测试面扩大了十倍，跑完从 5 分钟变成了 40 分钟。

这就是瓶颈转移的本质：产出端的速度被 AI 放大了，但消化端的速度还是人的速度。 旧流程的管道直径是为人的编码速度设计的，Agent 往里灌了三倍的水量，管道就堵了。

DORA 数据里的 -1.5% throughput 和 -7.2% stability，就是这个管道堵塞在宏观层面的表现。throughput 下降因为 review 积压——代码写完了但过不了 review。stability 下降因为 batch size 大——一次部署包含更多改动，出问题的概率更高，回滚也更难。Faros 的遥测数据把这条因果链量化得更精确：2025 年截面显示 AI 高采用团队的 PR size 平均涨了 154%，2026 年截面中这一数字为 51.3%（需注意两份报告是独立横截面，非同一组团队的纵向追踪），但 review 时间却从 +91% 恶化到 +441.5%——管道不但没疏通，堵塞还在加速。Greptile 的跨行业研究同样观察到 PR 体积的膨胀：中位 PR 从 2025 年 3 月的 57 行涨到 2026 年 3 月的 110 行，一年涨了 93%。

Netguru 的行业分析印证了同一个逻辑。他们指出，AI 工具的采用速度远超治理框架的适应速度。Stack Overflow 2025 年调查的数据佐证了这一点——51% 的专业开发者每天都在用 AI 编码工具，42% 的代码提交有 AI 辅助。但多数团队的 review 流程、测试策略、CI 配置，还是为纯人工编码时代设计的。AI 生成的代码有一个特性让这个问题更尖锐：它在语法上是正确的，能通过 linter，能通过静态分析，但在语义上可能与系统其他部分的契约不兼容。review 者面对的不再是「这段代码有没有 bug」，而是「这段代码有没有违反我没写下来的隐式契约」——后者的认知负担远大于前者。Stack Overflow 2025 年对 49,000+ 开发者的调查还揭示了另一种焦虑：对 AI 工具的好感度从 70% 降到 60%，46% 的开发者表示不信任 AI 输出，66% 把「几乎对但不完全对」列为最大困扰。

每次 review 的东西更小。

这就是 spec 进入流程设计的地方。在前六篇文章里，spec 的角色是「告诉 Agent 做什么」。在这一篇里，spec 有第二个同样重要的角色：它是 batch size 的控制器。

一份好的 spec 天然把大功能切成小任务。第 5 篇讲过，spec 的五要素之一是验收标准——明确的验收标准会暴露出一个功能可以被拆成几个独立可验证的子任务。每个子任务对应一个小 PR。小 PR 意味着 review 者在 10 分钟内就能看完——不是因为他们更快了，而是因为要看的东西更少了。小 PR 意味着 CI 只跑受影响的测试子集——不是 CI 更快了，而是测试面更小了。小 PR 意味着合并更快、反馈更快、出问题定位更快。

这条链路是：spec → 任务拆分 → 小 batch → 小 PR → 快 review → 快合并 → 快 CI 反馈。

这不是新发明——精益生产和持续交付几十年前就在讲小批量。但 AI 时代赋予了它新的紧迫性。在人的编码速度下，大 batch 是不舒服但可以忍受的——反正代码产出也快不到哪里去，review 积压不会太严重。在 Agent 的速度下，大 batch 是致命的——Agent 一小时产出的代码量，review 者需要一天来消化。batch size 不控制，瓶颈就会指数级放大。

资本市场已经在用真金白银为这个判断投票。2025 年 12 月，Cursor 以超过 2.9 亿美元收购了代码 review 工具 Graphite。CEO Michael Truell 的逻辑很简单：写代码的时间在持续缩短，review 占开发者时间的比例在持续增长，review 是下一个要打破的约束。这不是一家公司的战略判断——据行业报道引用 GitHub Octoverse 2025 数据，使用 AI 辅助 review 的仓库已超过 130 万个，较 2024 年底翻约四倍，合并速度更快，合并后缺陷更少。行业赌的是：如果 AI 解决了代码生成，那下一个要解决的就是代码 review。

DORA 2025 报告确认了这条路径的可行性。报告发现，与 2024 年不同，AI adoption 与 delivery throughput 之间出现了正向关系——也就是说，有些组织已经开始学会如何在流程中消化 AI 的速度。DORA 把这个变化归因于组织学习：团队、工具和流程正在学会在什么场景、什么时候、以什么方式使用 AI 最有效。90% 的受访者已在工作中使用 AI，80% 以上认为 AI 提升了生产力，不信任比例从 39% 降到 30%。

但 DORA 2025 同时指出，stability 的负相关仍然存在。throughput 在恢复，stability 还在恶化。这意味着「消化速度」跟上了，但「消化质量」还没跟上——代码能更快地通过 review 和合并了，但出问题的概率还没降下来。流程重设计不是一次到位的工程，而是一个持续调优的过程。

DORA 2025 报告有一句话值得贴在墙上：「AI doesn't fix a team; it amplifies what's already there.」 AI 不会修复团队，它放大团队已有的东西。流程健康的团队用 AI 变得更好——小 batch、快反馈、松耦合架构让他们能接住 AI 的速度。流程混乱的团队用 AI 变得更乱——大 batch、慢反馈、紧耦合系统让 AI 的速度变成灾难。AI 是放大器，不是修复器。

治理层：不只是切小，还要验对

把 batch size 切小解决了「review 过来」的问题。但还有一个问题：review 什么？

Netguru 的分析识别出了 AI 生成代码的三种典型失败模式：语义漂移（代码能编译、测试能过，但违反了服务间的契约）、依赖幻觉（引用了不存在的库或 API 方法）、许可证污染（AI 建议的代码包含了不兼容的开源许可证）。这三种失败模式有一个共同点：它们不会被传统的 review 流程自动捕获。 Linter 不检查语义契约。静态分析不验证依赖是否真实存在。review 者用肉眼扫几千行 AI 生成的代码，漏掉一个幻觉的依赖是再正常不过的事。

这意味着流程重设计不只是「切小 PR」——还需要在 review 环节加入专门针对 AI 生成代码的治理层。Netguru 的实践数据给出了具体指引：加入契约测试（contract testing）作为 AI 辅助变更的强制门禁后，集成故障在两个 sprint 内下降了约三分之二。投入只需要几天的工具配置——Pact 是消费驱动契约测试的标准工具，能与大多数 CI 管道集成。

安全维度同样不容忽视。Opsera 2026 基准报告发现 AI 生成代码引入的安全漏洞比人工代码多 15-18%。Veracode 2025 年的测试更触目惊心：在覆盖 Java、Python、C#、JavaScript 的 80 个编码任务中，AI 生成的代码有 45% 引入了 OWASP Top 10 漏洞，Java 的比例高达 72%。Aikido Security 2026 年对 450 名开发者和安全领导者的调查显示，五分之一的组织已经经历过 AI 生成代码引发的安全事件，69% 在自己的系统中发现了 AI 引入的漏洞。这些数字让 LogRocket 实验中发现的 review 性质变化——从「验证正确性」到「判断必要性」——显得更加紧迫：当 reviewer 花四倍的时间判断 AI 代码「有没有必要」时，安全检查往往成为被挤掉的那一环。

DORA 2025 报告从另一个角度说了同一件事。报告指出，没有健壮的控制系统——强自动化测试、成熟的版本控制实践、快速反馈回路——变更量的增加就会导致不稳定。那些在松耦合架构和快速反馈回路中工作的团队能看到收益，而那些受紧耦合系统和慢流程约束的团队几乎看不到好处。

把这两条线索叠在一起，你得到的是一套完整的流程重设计清单：

在 spec 层，把大功能拆成小任务，每个任务有明确的验收标准和边界。spec 不只是给 Agent 的指令，也是给流程的切分器。

在 review 层，加入 AI 专项检查清单——幻觉依赖、错误处理模式、许可证兼容性——作为 definition of done 的一部分，不是可选项。

在测试层，把契约测试设为强制门禁。单元测试覆盖执行路径，契约测试覆盖服务间的行为合约。两者缺一不可。

在部署层，用金丝雀发布限制爆炸半径。当缺陷穿过管线时，5-10% 的流量灰度比全量发布的回滚成本低一个数量级。

这套清单不是理论推演——每一条都有 DORA 数据或 Netguru 实践经验支撑。也不是一劳永逸的方案——DORA 2025 的 stability 负相关提醒我们，流程适配是一个持续演化的过程。

流程是可以学的——但学得够快吗

如果这篇文章到此为止全是坏消息——AI 加速了产出但拖慢了交付、大 batch 堵塞了管道、稳定性还在恶化——那 DORA 2025 报告给了一个关键的正面信号。

2024 年，AI adoption 与 delivery throughput 是负相关的。2025 年，这个关系变成了正相关。这意味着什么？意味着行业正在学习。团队正在学会在什么场景、什么时候、以什么方式使用 AI。流程正在被重设计。管道正在被加宽。

DORA 2025 的核心发现是：最大的回报不来自 AI 工具本身，而来自对内部平台质量、工作流清晰度和团队对齐的战略性关注。 换句话说，决定 AI 能不能帮你变快的，不是你用了哪个 Agent，而是你的流程能不能接住它的速度。

但 Faros 2026 的遥测数据给这层乐观浇了一盆冷水。DORA 说「好团队会更好」，Faros 说「好团队也逃不掉」。在覆盖 22,000 名开发者、4,000+ 个团队的遥测数据中，Faros 发现高工程成熟度的组织与低成熟度的组织一样在经历 Acceleration Whiplash——review 时间暴涨、bug 数飙升、事故率翻倍。工程成熟度是必要条件，但不是充分条件。DORA 的问卷捕捉到的是开发者的感受——「我觉得流程在变好」。Faros 的遥测捕捉到的是流水线的现实——「管道还在堵，而且堵得更厉害了」。两个结论并不矛盾，但它们合在一起指向一个更微妙的判断：流程学习确实在发生，但学习的速度可能赶不上 AI 产出加速的速度。throughput 从负转正是真的，stability 持续恶化也是真的。管道在加宽，但水量增加得更快。

Netguru 的行业分析也指向同一个方向。他们观察到，一些工程团队正在从大型 Scrum 团队向更小的 AI 增强交付团队转型，以提高吞吐量并减少协调开销。这不是退回到个人英雄主义——而是承认 AI 时代的协作结构需要重新设计。当 Agent 能写代码，review 就成了新的瓶颈；当 review 成了瓶颈，团队结构就需要围绕 review 吞吐量来优化，而不是围绕编码吞吐量。

行业数据还揭示了一个容易被忽视的变量：信任。DORA 报告发现，信任 AI 的开发者接受更多建议、提交更多变更、花更少时间搜索信息。2024 年有 39% 的开发者对 AI 输出「只信任一点」或「完全不信任」，到 2025 年这个比例降到了 30%——在改善，但仍然意味着近三分之一的开发者对 AI 代码心存疑虑。Stack Overflow 2025 调查更细致地刻画了这种心理：46% 的开发者不信任 AI 输出，66% 把「几乎对但不完全对」列为最大困扰。这个信任缺口不只是一个心理学问题——它直接影响流程效率。不信任的 review 者会逐行检查 AI 生成的代码，把本该 10 分钟的 review 拉长到 30 分钟。信任不是盲目的——它建立在可靠的治理层之上。契约测试、AI 专项检查清单、自动化溯源追踪，这些机制不是为了约束 AI，而是为了让人有理由信任 AI。信任建起来了，review 速度才能跟上产出速度。

瓶颈还会继续转移

流程重设计解决了「review 不过来」的问题。但这只是当前这个时间点的瓶颈。

DORA 2025 报告里 stability 的持续负相关暗示了一件事：就算你把 batch size 切小了、review 加速了、契约测试加上了，还有一个更深的问题没解决——当 Agent 能写代码，人的角色到底是什么？review 速度跟上了，但 review 者的判断力跟上了吗？当 Agent 生成的代码量远超人工审查的极限，人类还能有效地判断「这段代码做对了吗」？

这是下一篇的问题。当 Agent 让代码产出速度暴增，工程师的定义必须重写。新角色不再是「写代码的人」，而是「设计约束、编写 spec、构建 harness、审阅产出」的编排者。从演员变成导演。

但在进入那个话题之前，先回答这一篇的问题：你的流程接得住 AI 的速度吗？Faros 2026 的数据里有一个数字值得警惕——31% 更多的 PR 在没有任何 review 的情况下直接合并进了主干。这不是流程重设计的成功，这是流程崩溃的前兆。当 review 队列长到让人选择跳过，瓶颈就不只是「慢」了，而是「断」了。如果答案是不确定——那就在下一次让 Agent 写代码之前，先花十分钟做一件事：把你要它做的功能拆成三个小任务，每个任务有独立的验收标准。三个小 PR 胜过一个大 PR。这不是 spec 的技巧，这是流程的纪律。

参考文献

DORA. (2024). Impact of Generative AI in Software Development [Special Report]. Google Cloud / DORA. 大规模行业调查：AI adoption 每提高 25%，delivery throughput 下降 1.5%，delivery stability 下降 7.2%。根因：更大 batch size → review 更慢 → 稳定性下降。「真空假说」：AI 加速有价值任务但省下的时间被低价值任务吸收。39% 开发者对 AI 输出「只信任一点」或「完全不信任」。https://dora.dev/ai/gen-ai-report/
DORA. (2025). State of AI-assisted Software Development: 2025 DORA Report. Google Cloud. 基于 100+ 小时定性数据和近 5,000 名技术从业者调查。AI adoption 与 delivery throughput 及 product performance 出现正向关系（组织学习效应），但 stability 负相关仍持续。90% 受访者使用 AI，80%+ 认为 AI 提升生产力，不信任比例降至 30%。七种团队原型聚类分析。「AI doesn‘t fix a team; it amplifies what’s already there.」https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
Faros AI. (2025). The AI Engineering Impact Report (AI Productivity Paradox). 基于 10,000+ 开发者、1,255 个团队的工程遥测数据（数据截至 2025 年 6 月）。AI 高采用团队完成任务多 21%，合并 PR 多 98%，但组织级交付指标持平。PR review 时间上涨 91%，PR size 上涨 154%，每开发者 bug 数上涨 9%。https://www.faros.ai/blog/ai-software-engineering
Faros AI. (2026). The AI Engineering Report 2026: The Acceleration Whiplash. 基于 22,000 名开发者、4,000+ 个团队的遥测数据（独立横截面，非纵向追踪）。完成任务 +33.7%，Epic 完成 +66.2%，但 PR review 中位时间 +441.5%，每开发者 bug +54%，每 PR 生产事故 +242.7%，代码 churn +861%，无 review 直接合并的 PR 多 31%。高工程成熟度组织同样无法豁免。https://www.faros.ai/research/ai-acceleration-whiplash
Opsera. (2026). AI Coding Impact 2026 Benchmark Report. 覆盖 250,000+ 开发者、60+ 企业。AI 缩短 time-to-PR 最多 58%，但 AI 生成 PR review 等待时间 4.6 倍，安全漏洞多 15-18%。高级工程师效率收益是初级工程师的 5 倍。https://opsera.ai/resources/report/ai-coding-impact-2026-benchmark-report/
CodeRabbit. (2025). State of AI vs Human Code Generation Report. AI 生成代码暴露的问题数量是人工代码的 1.7 倍；近半数开发者报告调试 AI 输出比修人工代码耗时更长。转引自 LogRocket Blog (2026)。https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
Stack Overflow. (2025). Developer Survey 2025. 49,000+ 开发者调查。84% 使用或计划使用 AI 工具，51% 专业开发者每天使用。对 AI 工具好感度从 70% 降至 60%，46% 不信任 AI 输出，66% 将「几乎对但不完全对」列为最大困扰。42% 代码提交有 AI 辅助。https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/
Netguru. (2026). Critical Software Development Industry Challenges to Watch in 2026. 行业分析。AI 工具采用速度超过治理框架适应速度。三种 AI 代码失败模式：语义漂移、依赖幻觉、许可证污染。契约测试将集成故障降低约三分之二。团队从大型 Scrum 向小型 AI 增强交付团队转型。https://www.netguru.com/blog/software-development-industry-challenges
Veracode. (2025). GenAI Code Security Report. 覆盖 80 个编码任务、100+ LLM（Java/Python/C#/JavaScript）。AI 生成代码 45% 引入 OWASP Top 10 漏洞，Java 高达 72%。Aikido Security 2026 年调查（450 名开发者和安全领导者）：20% 组织已遭 AI 代码安全事件，69% 发现 AI 引入漏洞。https://www.veracode.com/blog/genai-code-security-report/
Greptile. (2026). The State of AI Coding 2025/2026 (Q1 2026 Update). 跨行业研究。中位 PR 从 2025 年 3 月的 57 行涨到 2026 年 3 月的 110 行，涨幅 93%。GitHub Octoverse 2025 数据显示 AI 辅助 review 仓库超 130 万个（据行业报道引用）。Cursor 于 2025 年 12 月以超 2.9 亿美元收购 Graphite，押注 review 为下一约束。https://www.greptile.com/state-of-ai-coding