30 秒快速回答
规格驱动开发（SDD）就是：先写规格，再写代码——只不过这份「规格」是写给 AI 看的、可执行的结构化文档，而不是写完就锁进抽屉的需求书。
它的核心价值一句话：把「AI 猜你想做什么」变成「AI 按你已确认的规则做」，让 AI 生成的代码从「看起来能跑」变成「可验收、可维护、可追溯」。 代表实践是 AWS 的 Kiro（requirements.md / design.md / tasks.md 三件套）和 GitHub 的 Spec Kit（/specify → /plan → /tasks → /implement 四步命令流）。
一、为什么「一句话让 AI 写整个项目」会翻车
Vibe Coding 的问题不在模型不够强，而在于意图没有被显式化。你只说「做一个带登录的待办应用」，模型就必须自己填补几十个隐含决策：用哪个数据库？密码怎么存？会话过期多久？删除要不要软删？每个决策都是一次猜测，猜错一次，后面全链条返工。
规格驱动的思路是把这些隐含决策提前固化成文档，让 AI 在写第一行代码之前先和你对齐。
| 维度 | Vibe Coding | 规格驱动开发（SDD） |
|---|---|---|
| 输入 | 一句话自然语言 | 结构化需求 + 设计 + 任务清单 |
| 决策由谁做 | AI 替你猜 | 人确认，AI 执行 |
| 返工时机 | 代码跑起来之后 | 写代码之前 |
| 可追溯性 | 无 | 每条任务可回指需求条目 |
| 适合场景 | Demo、脚本、一次性工具 | 多人协作、长期维护、生产系统 |
一句话结论：玩具项目随便 vibe，要活过三个月的项目必须上规格。
二、SDD 的三段式：需求 → 设计 → 任务
成熟工具链基本都收敛到同样三段结构，以 Kiro 为例，一个 spec 目录长这样：
.kiro/specs/user-login/
├── requirements.md # 要什么（用户故事 + 验收标准）
├── design.md # 怎么做（架构、数据模型、接口、错误处理）
└── tasks.md # 分几步做（可勾选的任务清单）
关键在 requirements.md：它不写散文，而写可验收的验收标准。业界常用 EARS（Easy Approach to Requirements Syntax）句式约束表达：
当 用户提交登录表单 时，系统 应当在 500ms 内返回鉴权结果
如果 连续 5 次密码错误，则 系统 应当 锁定账号 15 分钟并发送提醒邮件
如果 账号已锁定，则 系统 应当 返回 423 状态码而不是 401
这种「触发条件 + 系统响应」的句式，机器能解析、人也能验收，比「登录要安全一点」有用一百倍。
tasks.md 则是执行层：每条任务都应当能回指到某条需求，AI 打勾推进，人看进度也看边界。
三、落地实操：用 Spec Kit 跑一遍完整流程
GitHub 的 Spec Kit 把 SDD 固化成几个斜杠命令，在 Claude Code、Cursor、Copilot 等支持自定义命令的 Agent 里都能用：
# 1. 安装并初始化（在项目根目录）
uvx --from git+https://github.com/github/spec-kit.git specify init .
# 2. 固化的四步命令流
/specify 构建一个待办应用，支持多用户登录与任务分类
/plan 技术栈用 Next.js + Postgres，给出数据模型与接口设计
/tasks 按依赖顺序拆成可执行任务清单
/implement 逐条执行任务并生成代码
其中 /constitution 用来定义项目铁律（比如「所有接口必须有错误处理」「禁止引入未审计的第三方包」），它会作为约束注入后续每一步，避免 AI 在实现阶段自作主张。
实操上记住三条顺序纪律：
- 规格没确认，不进
/plan——先花十分钟读一遍 AI 写的验收标准，改错一句比改错一百行代码便宜。 - 设计没定接口，不进
/tasks——design.md里数据模型是错的，后面任务是批量错的。 - 任务粒度要一天以内——单条任务超过半天工作量，就该继续拆，否则 AI 一旦跑偏你无法定位。
四、三个容易踩的坑
| 坑 | 表现 | 解法 |
|---|---|---|
| 规格写成小说 | 需求文档两千字，AI 读完抓不住重点 | 每条需求一行，只写触发条件和可验证结果 |
| 规格与代码脱节 | 改完代码忘了改 spec，下一轮 AI 按旧规格返工 | 把 spec 纳入仓库版本管理，改代码同 commit 改 spec |
| 过度规格化 | 给一次性脚本写三份文档 | 按项目寿命分级：一次性脚本跳过 SDD |
还有一条隐性风险：规格文件本身也是提示词注入面。如果 spec 里混进了从外部抓来的内容（比如网页复制的需求），务必人工过一遍，别让 AI 把恶意指令当需求实现。
总结
- SDD 的本质不是「多写文档」，而是把人的决策权从实现阶段提前到规格阶段。
- 三段式结构：
requirements.md（EARS 句式，可验收）→design.md（架构与接口）→tasks.md（可回指的需求任务）。 - 工具选型：轻量用 GitHub Spec Kit 四命令流，全流程 IDE 体验用 Kiro。
- 纪律：规格确认后才进入计划，设计接口定稿后才进入任务拆解。
延伸阅读建议：先读本博客《什么是 Vibe Coding？AI 主导编程的新范式与实践全解析》理解对照面，再看《什么是 AGENTS.md？让 AI 编程 Agent 秒懂你项目的标准文件全解析》把项目级约束固化下来——三者组合，就是一套完整的 AI 工程化底座。