什么是规格驱动开发 SDD？AI 时代的工程新范式

2026-06-17

规格驱动开发（Spec-Driven Development，简称 SDD）是一种”先把规格写清楚、再让 AI 按规格实现”的软件开发方法——把模糊的需求拆成明确的规范、计划、任务，让 AI 在有约束的前提下生成代码，而不是凭一句话即兴发挥。它正在成为 AI 时代工程化协作的新范式：当写代码的速度被 AI 拉满，瓶颈就从”敲键盘”转移到了”说清楚要什么”。

为什么需要 SDD

用 AI 写代码，很多人都踩过同一个坑：一句话丢给 AI，前两轮挺惊艳，越往后越失控。

改了 A 功能，B 功能莫名其妙坏了；
AI 自作主张换了技术栈、加了没要求的依赖；
同一个需求，今天生成的代码和昨天的逻辑对不上；
项目一大，AI 记不住前面的约定，到处”幻觉”。

根因只有一个：需求是模糊的，而 AI 会把模糊的地方自己脑补掉。 你以为说清楚了，其实只说了 30%，剩下 70% 全靠 AI 猜——猜错了就返工。

举个我踩过的例子：让 AI 给购物车加”满 99 减 10”的优惠逻辑，一句话丢过去，它很快写完了，跑起来也没报错。但上线前测试才发现，它默认把优惠券和满减做成互斥的（选一个就不能叠加另一个），而产品经理原本要的是”满减自动生效，优惠券可以叠加”。这个分歧我一开始压根没提，AI 也没问，它按自己对”电商促销”最常见的实现方式脑补了一版——逻辑没错，但不是我要的那版。返工的成本，比一开始花五分钟把”是否允许叠加”写进需求里贵得多。

SDD 的解法很朴素：把”猜”换成”读”。 先把要做什么、边界在哪、分几步做，写成一份 AI 能读懂的规格文档，再让它照着干。规格越清晰，AI 越像一个靠谱的工程师，而不是一个话痨实习生。

SDD 是怎么工作的

SDD 的核心是把”一句话需求”展开成一条清晰的流水线。典型流程分四步：

1. 规范（Specify）——说清楚做什么。 先写一份需求规格：要解决什么问题、给谁用、核心功能有哪些、明确的边界和不做什么。这一步只谈”要什么”，不谈”怎么实现”。这相当于给 AI 一份产品需求文档（PRD）。

2. 计划（Plan）——定怎么做。 基于规范,确定技术方案：用什么技术栈、怎么分层、关键模块怎么拆、有哪些约束（比如必须兼容旧接口）。这一步把抽象需求落到工程决策上。

3. 任务（Tasks）——拆成可执行的小步。 把计划切成一个个具体、可验证的任务，比如”实现登录接口""写登录页表单校验”。每个任务足够小，AI 能一次做对，你也能一眼看出做没做对。

4. 实现（Implement）——让 AI 按任务逐个落地。 AI 拿着规范+计划+任务上下文，逐个任务生成代码。因为约束充分，它不再乱发挥；你逐个 review，错了就回到对应任务修，而不是推倒重来。

打个比方：Vibe Coding 像口头跟装修队说”帮我装个温馨点的家”；SDD 像先出一套施工图纸再开工。 图纸画清楚了，工人（AI）只管照着干，返工自然就少了。

具体到一份规格文档长什么样，不用想得太玄乎。以刚才的购物车优惠为例，一份可用的 Specify 阶段文档大概是这样几行：

功能：购物车满减与优惠券叠加
背景：现有满 99 减 10 的满减规则，需新增优惠券功能
要求：
  1. 满减自动生效，无需用户操作
  2. 优惠券需用户手动选择使用
  3. 满减与优惠券可以同时叠加，互不排斥
  4. 叠加后总优惠不超过订单金额的 50%（防止负数订单）
不做：
  - 不做多张优惠券叠加（同一订单最多用一张）
  - 不做优惠券有效期的动态计算，沿用现有 coupon 表字段

四行”要求”加两行”不做”，比一句”帮我加个优惠券功能”信息量高出一个数量级，AI 也不需要再脑补”能不能叠加”这种关键分歧点。这就是 Specify 阶段真正该产出的东西——不是长篇大论，而是把容易分歧的地方点名说清楚。

SDD 和 Vibe Coding 怎么选

这是最多人纠结的对比。两者不是对立，而是光谱的两端。

维度	Vibe Coding（即兴）	规格驱动开发 SDD
出发点	一句话需求，边写边想	先写规格，再实现
速度	起步极快	起步慢，后期稳
适合规模	小脚本、原型、demo	中大型、要维护的项目
失控风险	项目一大就失控	约束足够，可控
协作	一个人爽	多人/人机协作清晰

给三条直接结论：

做一次性的小工具、验证一个想法、周末玩具项目——用 Vibe Coding，别上 SDD，那是杀鸡用牛刀。
做要长期维护、多人协作、要上线的真项目——用 SDD，前期多花的那点写规格时间，后面省下的返工时间是它的十倍。
最佳实践是两者结合：用 Vibe Coding 快速探明白要做什么，确定方向后，把它沉淀成规格，再用 SDD 严肃地实现。关于即兴开发如何过渡到工程化，可以读从 Vibe Coding 到工程化（规划中）。

为什么 SDD 能提升 AI 编程质量

很多人以为 SDD 只是”多写文档”，其实它提升质量的机制有三层：

1. 把上下文显式化。 AI 的输出质量高度依赖上下文。规格文档就是一份持久、可复用的上下文，每次生成代码都喂给它，AI 不用”记忆”也不会忘。

2. 把验收前置。 任务拆得足够细，每一步都”可验证”。错误在小颗粒度就被拦住，不会滚雪球到难以回滚。

3. 把决策和实现分离。 规范和计划阶段，人做高价值的判断（要什么、怎么架构）；实现阶段，AI 做体力活（写代码）。人管脑子，AI 管手。 分工对了，质量自然上去。

主流 AI 编程工具如 Claude Code、Cursor 都越来越鼓励这种做法——在项目里放 AGENTS.md 或规格文档，本质就是给 AI 一份”工程规范”。

如果你想直接上手一个现成流程，GitHub 官方开源的 Spec Kit 是目前最典型的落地方式：它给了四个斜杠命令，/specify 生成规范文档、/plan 生成技术方案、/tasks 拆任务清单、/implement 按任务逐个实现，每一步产出的文档都存在仓库里，可追溯、可复查。亚马逊的 Kiro 编辑器走的是同一条路，内置了”规格模式”，写完需求会自动生成 requirements、design、tasks 三份文档，逻辑和上面四步基本对应。就算不装任何专门工具，在 Cursor 里放一份 .cursor/rules、在 Claude Code 项目根目录放一份 CLAUDE.md，把项目的架构约束、代码规范、“不许做什么”写清楚，本质上也是在做同一件事——工具是外壳，把规格显式地写下来才是核心。 社区也出现了专门做 SDD 流程的开源框架，可以读 Spec Kit 上手教程（规划中）了解具体怎么落地。

怎么上手 SDD

不需要一上来就用复杂框架，先从最小可行版本练手：

下次写需求时，先用一段话写清”要什么、不做什么、边界在哪”，再丢给 AI。
让 AI 先输出实现计划，你确认无误再让它写代码——别一上来就让它写。
把需求拆成 3-5 个可验证的小任务，逐个让 AI 做、逐个 review。
项目稳定后，把这些规格沉淀进仓库（如 docs/ 或 AGENTS.md），形成可复用的工程资产。

熟练之后再考虑引入专门的 SDD 框架和工具，把流程自动化。

常见问题

SDD 是不是就是以前的瀑布开发？ 不是。瀑布是一次性写完所有文档再开发、改起来很贵；SDD 的规格是轻量、可迭代的，每个小任务做完即验证，跑通一轮再迭代下一轮，更像敏捷而非瀑布。

写规格不是更慢吗，AI 不就图个快？ 起步确实慢一点。但 AI 编程真正的成本不在第一版生成，而在反复返工和调试。规格把返工挡在了前面，总时间反而更短，项目越大越明显。

小项目也要用 SDD 吗？ 不用。一次性脚本、demo、验证想法，直接 Vibe Coding 更高效。SDD 的价值在”要维护的真项目”上才体现得出来。

SDD 需要专门的工具才能做吗？ 不需要。本质是一种工作方法，用任何 AI 编程工具加一份 Markdown 规格就能开始。专门的框架只是把流程标准化、自动化，是锦上添花，不是门槛。

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全把基本功打扎实。