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 是放大器，不是修复器。
