Spec驱动开发SDD实测：返工率从40%降到10%，5人7天干完20人数周的活

AI写代码的速度早就够快，真正的瓶颈在返工。

一句话需求丢给Cursor，30秒吐出500行代码。看起来很爽，三天后问题浮出水面：分页漏了边界条件，权限校验没做，前端状态管理一团乱。重新生成的成本，比手写还高。

2026年，越来越多团队换了一套打法：让AI动手写代码之前，先逼它把需求写清楚。这套方法论叫Spec-Driven Development，规格驱动开发，简称SDD。

三个实战数据

先看账本。

某团队用OpenSpec配合AI IDE推行SDD，代码一次通过，返工率从40%压到10%。一篇arXiv论文记录了金融领域的SDD实践：API变更周期缩短75%。QoderWork的Quest模式跑出更夸张的数字：5人团队7天干完传统20人团队数周的工作量，Spec写好后直接委派Quest执行，AI自动写代码、提PR、跑测试。

数据背后有个共同点：AI生成的代码恰好符合预期，因为预期已经被写成AI能读懂的Spec。

SDD的核心流程

这套方法最早由AWS在AI IDE产品Kiro中正式提出。Kiro于2025年7月上线，此后一路迭代到2026年，目前已GA并支持CLI。它的流程分三步。

第一步，需求结构化。 Kiro把自然语言提示翻译成EARS语法（Easy Approach to Requirements Syntax）的条目，英文句式为”When [trigger], the system shall [response]”。每条需求都是可验证的行为声明，验收标准直接写进需求里。

第二步，设计文档。 AI基于需求生成design文档，涵盖系统架构、模块划分、API定义、数据模型。开发者在这一步介入评审——改设计的成本远低于改代码。

第三步，任务分解。 design确认后生成tasks列表，每条任务可独立验收、独立提交。AI按任务逐条实现，自动提PR。

Kiro凭EARS语法产出可审计的输出，每条行为需求都要通过三文档关卡才能进入代码生成，对医疗、金融等合规敏感团队是硬需求。

工具格局：四个流派

GitHub Spec Kit：2025年9月开源，模型无关的CLI，支持30多个Agent——Claude Code、Copilot、Cursor、Codex CLI、Gemini CLI、Qwen Code都能接。命令行五阶段：`/speckit.constitution` → `/specify` → `/plan` → `/tasks` → `/implement`。

AWS Kiro：规格原生的IDE，基于VS Code构建，EARS语法加三文档关卡，适合合规审计要求高的团队。

Google Antigravity 2.0：押注并行Agent吞吐，多个Agent同时写代码，速度优先，适合审计要求低的场景。

轻量方案：Cursor Plan Mode、Claude Code Skills、OpenSpec、BMAD-METHOD，都能以较低成本试水。

为什么有效

SDD把传统软件工程的精华——需求分析、系统设计、任务分解——压缩成AI生成代码的强制前置步骤。

传统需求文档的痛点人人皆知：写完没人看，看的人理解不一致。Spec换了个定位，做可验证的行为声明，人读得懂，机器也读得懂。衡量标准在于省了多少次理解不一致造成的沟通和修复，字数多少无关紧要。

Spec同时砍掉三类返工：需求传递失真导致的开发返工，缺乏统一约束导致的代码审查返工，文档缺失导致的交接维护返工。

Spec稳定之后还能复用。接口契约、错误码、数据格式定义完整，AI直接生成符合Spec的代码，金融领域API变更周期缩短75%的案例就是这么来的。

上手三步走

• 初始化项目：`uvx –from git+https://github.com/github/spec-kit specify init myproject`
• 依次执行`/speckit.constitution`定项目宪法，`/specify`生成需求草稿，用`/clarify`补齐歧义
• `/plan`出设计，`/tasks`分解任务，`/implement`让AI按任务实现

全程人工介入三个点：审需求、审设计、审PR。中间所有体力活交给AI。

什么团队该用，什么团队别用

多人协作、前后端协同、需要长期维护的项目，SDD收益明显。一次性脚本、周末原型、验证想法的Demo，直接Vibe Coding更快，套SDD纯属浪费时间。

适应成本也要算进去。规格化表达与写需求文档的思路差异不小，团队前两周会明显变慢。从整个交付周期看，这笔投入换回的是返工成本的断崖式下降。

写清楚你要什么，AI才能写清楚代码。这句话概括了SDD的全部逻辑。