AI 写得越快,越没人敢 merge?规格驱动开发才是解药

一个人用 AI，一天能提交的 PR 比过去多出一大截。可评审的速度没跟上，代码堆在那儿，谁也不敢按下 merge。

问题不在 AI 写得不好，而在没人有把握说「这段能上」。

代码越攒越多，Reviewer 越看越慢，瓶颈早就从「写」挪到了「验」。光靠一句「帮我实现这个功能」，AI 写得再快，也只是把没人敢用的代码生产得更快。

规格驱动开发（Spec-Driven Development，下称 SDD）就是冲着这个来的：先把「要什么」写成一份说得清、能对照的规格，再让 AI 照着规格生成代码。早期受控研究显示，人工精修过的规格能让 LLM 生成代码的错误率最高下降约 50%（这一方向的研究仍处于早期阶段）。

下面按「为什么、是什么、怎么做」讲清楚，第四节是可以直接照抄的工作流。

一、AI 编程的新病：写得飞快，没人敢 merge

先看一个反直觉的现象。DORA 2025 年的报告有个核心判断：AI 是放大器——它提升了软件交付的吞吐，却没同步带来稳定性，反而容易把下游的问题一起放大。

具体到 PR 上就是：AI 让你写得飞快，合入的 PR 大幅增加，可评审这一环并没有跟着提速。一个人能同时开几个 Agent 猛产代码，Reviewer 的人数和时间却没变。结果不是上线变快，而是 PR 越堆越高。

瓶颈从「写代码」迁到了「读别人写的代码」，而这个「别人」，现在是 AI。

问题的根子在于：你给的是一句模糊指令，AI 只能靠猜补全意图。它猜得越多，Reviewer 要核对的隐含假设就越多，评审自然越慢、越不敢放行。

二、什么是规格驱动开发

一句话：规格是唯一的权威定义，代码由规格推导出来，而不是反过来。

传统写法里，代码是事实，文档是事后补的注脚。SDD 把这层关系倒过来——先写规格，代码只是规格的一种实现。

你的角色也跟着变：从「写代码的人」变成「定义逻辑的人」。你负责把需求想清楚、写成契约；AI 负责按契约生成结构一致、符合架构约束的实现。

对比项	随手写（Vibe Coding）	规格驱动（Spec-Driven）
起点	一句话指令	一份明确的规格
权威	代码写成什么算什么	规格说了算，代码照做
你的角色	盯着 AI 一行行改	定义契约、审规格
Reviewer	从第一行猜到最后一行	对照规格逐条核
出错时	重新描述、再猜一遍	改规格，重新生成

差别不在「用不用 AI」，而在有没有一份大家（人和 AI）都能对照的契约。

三、为什么它能压低错误率

规格不是多写的文档，它在动手前就约束了解空间。

前面提到的早期受控研究给出过一个方向性的信号：人工精修过的规格，能让 LLM 生成代码的错误率明显下降（部分研究中最高约 50%）。原理不玄乎——规格在 AI 动笔前就框定了「什么算对」，把大量本该在评审阶段才暴露的分歧，提前挡在了生成之前。

这正好接上第一节的验证瓶颈：

没有规格：AI 猜意图 → 生成 → Reviewer 逐行核对隐含假设 → 发现不对 → 返工。验证负担全压在后面。
有规格：人审规格（短、集中） → AI 照做 → Reviewer 对照规格核（有基准、快） → 一致即过。验证负担被前置到了更便宜的阶段。

一句话：审一份规格，比审一坨代码便宜得多。

四、实战：一套可复现的规格驱动工作流

这是本文的核心。下面这套流程，用 Claude Code、Cursor 或任何支持多步骤的 Agent 工具都能落地。

Step 1：把需求写成规格

别再对 AI 说「帮我做个用户登录」。规格至少要说清四件事：

✅ 要做什么：输入、输出、边界条件。
✅ 不能做什么：哪些情况必须报错、哪些数据不能碰。
✅ 怎么算做完：要过哪些测试、构建和检查必须绿。
✅ 风险线：哪些安全问题零容忍、失败重试几次、还不行交给谁。

这份规格就是你和 AI、以及 Reviewer 之间的契约。它值得你花十分钟，因为它能省下后面几小时的返工和扯皮。

实战案例：让 Agent 做一次依赖升级。规格里写明「受影响模块清单、目标版本、必须跑通的固定测试集、改动说明格式、测试失败即停并带日志」。Reviewer 不用从头猜 AI 做了什么，只需对照规格判断这次升级要不要合。

Step 2：orchestrator + worker，一份规格拆给多个 Agent

规格写清后，别用一个 Agent 从头干到尾。业界验证过的生产架构是一个协调者 + 若干专职 worker：

Orchestrator（协调 Agent）：读规格，决定谁在什么时候干什么，负责派活和串联。
DB Agent：探查库表结构、生成 SQL。
架构 Agent：设计分层和接口。
Code Agent：按已批准的设计生成代码。
Reviewer Agent：做对抗式审查，专挑毛病。

每个 worker 只干一件事，职责清晰、好测试、好替换。规格就是它们之间对齐的那份共同契约。

orchestrator + worker 架构：一份规格拆给一个协调者和多个专职 Agent

Step 3：规格级拆分，多 Agent 并行不打架

规格的另一个红利：可以在规格层面把活拆开。把互不重叠的任务分给多个 Agent 同时干，有依赖的地方交给 orchestrator 排序。

因为每块活都有明确的规格边界，多个 Agent 并行时不会互相踩脚——这是「一句话指令」永远做不到的，模糊指令下的并行只会制造更多需要人工消解的冲突。

五、上生产的 3 条铁律

工作流跑通只是第一步，要真正放进生产，记住三条：

1. 幂等、检查点、高风险处留人工门。 可靠性会在 Agent 链条上层层累积或层层衰减，从一开始就要设计好：操作可重试（幂等）、关键步骤留检查点、风险高的地方设 human gate（人工审批）。

2. 先建 worker，再建 orchestrator。 推荐的搭建顺序是先把每个 worker Agent 单独做好、隔离测试通过，再上协调者把它们串起来。反过来先搭编排，底层不稳，问题会被放大。

3. 可观测性不是可选项。 如果你看不到 Agent 实时在干什么，就没法调试、没法改进。每一步的 prompt、工具调用、决策点都要能追溯。

结语

7 月我写过一篇《AI 写代码已经很快了，团队为什么还是慢？》，讲的是症状——写得快、上线不快，瓶颈卡在验证和发布。

规格驱动开发就是那篇的处方：与其让 AI 猜你要什么、再让人费劲验证它猜得对不对，不如先把契约写清楚，让验证变便宜。

AI 提速的下半场，拼的不是谁写得更快，而是谁能让写出来的东西有人敢 merge。规格，就是那份让人敢按下 merge 的底气。