规范驱动开发-SDD-SpecKit
SDD对比传统开发范式
在SDD之前，我们有以下几种经典的开发范式：
- TDD：测试驱动开发。先写失败测试，完成最小实现，最后进行代码重构。关注的是代码的正确性。
- BDD：行为驱动开发。用自然语言描述系统行为。Given/When/Then。核心价值在于消除需求的歧义。关注的是业务验收与共同理解。
- DDD：领域驱动开发。统一语言限界上下文。核心关注建模与系统的边界。使系统设计更贴合实际业务场景。
在AI大模型兴起后，Vibe Coding迅速在AI编程领域应用起来。这个时候，SDD-规范驱动开发。就特别适合现在这个AI编程时代。
一句话总结，SDD就是用精准技术规范作为唯一的真相源，驱动设计、编码、测试与文档。
SDD，先把需求、约束、边界条件、验收标准，写成结构化的Spec文档，再让AI Agent基于Spec，去规划、拆解、编码、测试、反复验证。
总之，AI的行为，取决于Spec文档中的精准描述。
人，多做设计决策，少写代码。
AI，负责“搬砖”、
让SDD和TDD、BDD、DDD，做一个本质区别的话，
前者强调的是，人，怎么把控AI，不要让AI写的代码偏离人的预期。
后者是让人怎么去更好的开发软件。
这四者，不是平行的替代关系，而是层级关系
1 | ┌─────────────────────┐ |
在过去，我们所有写的文档，都是起到一个辅助作用，不能“为准”，现在，AI就是照着文档来写的代码。
SDD对比Vibe Coding
| 对比维度 | Vibe Coding（氛围编程） | SDD（Specification‑Driven 规范驱动） |
|---|---|---|
| 核心定义 | 用自然语言跟 AI 聊天，边聊边改，“想到就做、能跑就行”，快速生成代码Vibe Coding。 | 先写规范、后写代码；用结构化 Spec 作为 “唯一真相源”，AI 严格按 Spec 生成 / 校验代码。 |
| 需求表达方式 | 模糊、口语化、不完整的自然语言描述；意图经常变。 | 结构化、可执行、可评审的规范文档：含目标、范围、输入输出、边界条件、异常、验收标准。 |
| AI 的角色与行为 | AI 自由发挥、结果不可预测；同一句话可能每次输出都不一样；人靠 “感觉” 验收。 | AI 是规范的执行者；严格按 Spec 生成代码、测试、文档；输出可重复、可验证、可审计。 |
| 开发流程 | 描述 → 生成 → 运行 → 不满意再描述；循环试错、无固定阶段Vibe Coding。 | Specify（定义规范）→ Plan（技术方案）→ Implement（实现）→ Verify（验证）；有明确阶段与评审关口。 |
| 质量与可维护性 | 低：无统一结构、无边界约束、无文档；改 A 坏 B、回归风险高；3 个月后债务爆炸。 | 高：规范即活文档；变更可追溯、回归风险低；架构清晰、长期可维护；代码与规范强绑定。 |
| 文档与知识沉淀 | 几乎无文档；知识全在对话历史里，人走知识丢。 | 规范就是活文档 + 团队知识库；持续积累、版本化、可检索。 |
| 团队协作能力 | 差：依赖个人聊天记录；无共同标准、评审困难、冲突多。 | 强：规范是团队契约；人人对齐、评审有依据、分工明确、可并行开发。 |
| 前期成本 / 上手门槛 | 极低：几乎无前置工作；会说话就能用Vibe Coding。 | 中等：需要花时间写规范；需要懂业务 + 结构化思维。 |
| 适用场景 | ✅ 原型 / POC、一次性脚本、小工具、个人项目、快速创意验证。 | ✅ 生产系统、中大型项目、长期维护系统、团队协作项目、核心业务系统。 |
| 风险与典型问题 | 架构漂移、质量不稳定、安全隐患、技术债务快速累积。 | 前期投入时间、规范可能过度设计、对能力有一定要求。 |
| 一句话总结 | 凭感觉、快而乱、短期爽、长期痛。 | 按规范、慢而稳、短期投入、长期稳健。 |
- Vibe Coding = 即兴发挥，适合 “快速试错、用完即弃”。
- SDD = 按图施工，适合 “要质量、要维护、要协作”。
SpecKit是什么？
SpecKit是Github上官方开源的SDD的标准化工具包
- 8个/speckit.* 命令，覆盖SDD完整流程。与Claude Code深度集成
- .specify目录结构。memory/存宪法，/specs/存规范计划任务，templates/定义文档模板格式
- 除了支持Claude Code外，也支持Gemini cli、Codex等主流AI编程Agent
SpecKit的安装
uv环境（Python包管理器）准备
1
2
3
4# 安装
curl -LsSf https://astral.sh/uv/install.sh | sh
# 验证
uv --version
安装SpecKit
1
2
3
4
5
6
7
8
9
10
11# 全局安装，一次安装，所有项目都能使用
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
# 升级
uv tool install specify-cli --force --from git+https://github.com/github/spec-kit.git
# 卸载
uv tool uninstall specify-cli
# 验证
specify --version
# 自动检测 Git、Python、AI Agent（Claude/Cursor 等）是否就绪
specify check
下面使用SpecKit实现SDD范式开发案例
案例需求说明
1 | # SpecKit SDD 开发实战案例：**简易任务待办清单（Todo List）** |
初始化项目
初始化项目：
specify init todo-spec-kit-test --ai claude，呸，用这个specify init todo-spec-kit-test --integration claude1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
➜ luan-qi-ba-zao git:(master) ✗ specify init todo-spec-kit-test --ai claude
███████╗██████╗ ███████╗ ██████╗██╗███████╗██╗ ██╗
██╔════╝██╔══██╗██╔════╝██╔════╝██║██╔════╝╚██╗ ██╔╝
███████╗██████╔╝█████╗ ██║ ██║█████╗ ╚████╔╝
╚════██║██╔═══╝ ██╔══╝ ██║ ██║██╔══╝ ╚██╔╝
███████║██║ ███████╗╚██████╗██║██║ ██║
╚══════╝╚═╝ ╚══════╝ ╚═════╝╚═╝╚═╝ ╚═╝
GitHub Spec Kit - Spec-Driven Development Toolkit
╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ │
│ Specify Project Setup │
│ │
│ Project todo-spec-kit-test │
│ Working Path /Users/sherry/code/tmp-tmp/luan-qi-ba-zao │
│ Target Path /Users/sherry/code/tmp-tmp/luan-qi-ba-zao/todo-spec-kit-test │
│ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
Selected coding agent integration: claude
Selected script type: sh
Initialize Specify Project
├── ● Check required tools (ok)
├── ● Select coding agent integration (claude)
├── ● Select script type (sh)
├── ● Install integration (Claude Code)
├── ● Install shared infrastructure (scripts (sh) + templates)
├── ● Ensure scripts executable (5 updated)
├── ● Constitution setup (copied from template)
├── ● Install git extension (existing repo detected; extension installed)
├── ● Install bundled workflow (speckit installed)
└── ● Finalize (project ready)
Project ready.
建议把 .claude/ 加到 .gitignore，避免密钥泄露
╭─────────────────────────────────────────────── Agent Folder Security ────────────────────────────────────────────────╮
│ │
│ Some agents may store credentials, auth tokens, or other identifying and private artifacts in the agent folder │
│ within your project. │
│ Consider adding .claude/ (or parts of it) to .gitignore to prevent accidental credential leakage. │
│ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
--ai is deprecated
请改用 --integration claude
╭──────────────────────────────────────────────── Deprecation Warning ─────────────────────────────────────────────────╮
│ │
│ --ai is deprecated and will no longer be available in version 0.10.0 or later. │
│ │
│ Use --integration claude instead. │
│ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
╭──────────────────────────────────────────── Notice: Git Default Changing ────────────────────────────────────────────╮
│ │
│ The git extension is currently enabled by default during specify init. │
│ Starting in v0.10.0, this will require explicit opt-in. │
│ Use specify extension add git after init when needed. │
│ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
下一步要做的事
╭───────────────────────────────────────────────────── Next Steps ─────────────────────────────────────────────────────╮
│ │
│ 1. Go to the project folder: cd todo-spec-kit-test │
│ 2. Start Claude in this project directory; spec-kit skills were installed to .claude/skills │
│ 3. Start using skills with your coding agent: │
│ 3.1 /speckit-constitution - Establish project principles →制定项目原则 │
│ 3.2 /speckit-specify - Create baseline specification →生成项目规范文档 │
│ 3.3 /speckit-plan - Create implementation plan → 生成实现计划 │
│ 3.4 /speckit-tasks - Generate actionable tasks → 生成可执行任务 |
│ 3.5 /speckit-implement - Execute implementation → 让 AI 直接写代码实现 │
│ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
增强技能
╭───────────────────────────────────────────────── Enhancement Skills ─────────────────────────────────────────────────╮
│ │
│ Optional skills that you can use for your specs (improve quality & confidence) │
│ │
│ ○ /speckit-clarify (optional) - 先澄清需求，减少歧义 │
│ ○ /speckit-analyze (optional) - 分析需求一致性 │
│ ○ /speckit-checklist (optional) - 生成质量检查清单 │
│ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
➜ luan-qi-ba-zao git:(master) ✗初始化项目，会创建一个项目文件夹，并初始化.claude、.specify等文件夹
进入项目目录，启动claude
我们能看到很多spec命令
制定宪法 /speckit-constitution
宪法，是整个项目的基本法。
它定义了不可违反的原则标准，后续所有阶段，AI都会拿它作为参考。
它是团队的编码规范，技术决策的标准，质量标准的总纲。
这个宪法，写到 .specift/memory/constitution.md 文件中去
这个宪法就是个md文件，可以自己写，可以参考其他项目，也可以让AI生成
1 | /speckit-constitution 我要作业待办清单程序，纯前端项目。使用React技术栈，pnpm作为包管理工具。使用中文，帮我完成SpecKit宪法的编写 |
宪法越具体，AI后续的行为就越可控
比如：要写出高质量的代码，这句话就不如：AI响应结构遵循统一的JSON格式 。这种表述更加具体。
编写规范 /speckit-specify
SpecKit规范的编写有三种方式
- 自然语言
1
2我要一个待办清单，可以添加任务、标记完成、删除任务。
使用React框架，本地运行 - 手写spec.yaml文件
- 命令生成
1
2
3/speckit-specify 我要一个可视化待办清单，有前端页面，能添加、标记完成、删除任务
# 这里因为只是个简单案例，所以手敲了需求。如何需求复杂的话，我们会在外面准备好详细的md格式的需求文档，复制进来。
# 这里，只专注于业务需求，不要写技术实现。
SpecKit会自动在项目根目录，创建 specs/001-XXX 文件夹，里面是符合SpecKit规范的各类文件。
规范的核心，是定义了 what（做什么），以及why（为什么做）。一定要避免涉及到how（怎么做）
对于生成出来的规范，一定要仔细检查。查看其是否包含了我们的全部需求，优先级、边界条件、验收标准。
澄清需求 /speckit-clarify
这一步是可选的，但还是推荐使用。
在这一步中，claude code会审视规范中模糊的地方，通过向用户提问的方式，来消除歧义。
1 | # 直接回车即可，不需要提示词 |
制定技术计划 /speckit-plan
在此计划中，告诉AI怎么做。提供高层的技术方向即可。
1 | /speckit-plan 使用React技术栈，不对接后端接口。数据存储在浏览器端。使用pnpm作为包管理工具 |
其实，如果我们在宪法中已经说明技术方向了，我们这里啥都不说也可以。输入完命令，直接回车
最终生成 001-XXX/plan.md 文件
重点检查目录结构、数据库表结构设计是否合理、组件拆分是否合理、技术方案是否如预期等等。
任务分解 /speckit-tasks
把技术计划，转化为AI可以逐个执行的原子化的工作项
1 | /speckit-tasks |
会基于 plan.md 文件生成task任务
task任务文件也会保存在 001 文件夹中。
任务分解的审核重点是
- 任务的依赖关系是否合理，前后关系是否准确
- 每个任务的粒度是否足够小，能否在单次AI交互中完成
- 任何的映射是否正确，每个任务能否追溯到具体的需求
- phase阶段划分是否合理
一致性分析 /speckit-analyze
本步骤可选，但也是推荐使用
本步骤会交叉验证宪法、规范、需求、计划、任务之间的一致性
- 使用命令
1
/speckit-analyze
最终会生成一份分析报告。我们根据这份报告，去调整前面的文档。
实现 /speckit-implement
1 | /speckit-implement |
具体做的事情包括
- 读取宪法、规范、计划、任务的文件
- 根据任务列表的顺序和依赖关系，逐个执行任务
- 为每个任务生成代码、测试和文档
- 在task.md文档中，把已经完成的任务标记为完成
- 在实现过程中，持续的参照宪法，确保合规
tips
对于一些复杂需求，一次/speckit-implement可能无法完成所有的任务，可能任务还没全部完成，会话就中断了。
没关系，继续执行 /speckit-implement 即可。或者也可以添加提示词，制定实现某个phase的任务
完美！
从测试情况来看，功能都是正常的。
但是页面的确是丑了点，不过这就是另一个话题了。
小技巧
- 宪法的编写
- 只写可执行的约束（做不到的废话，就别写了）
- 规范的编写
- 按照功能区拆分规范。避免AI上下文窗口的爆炸
- 让每个功能都独立的走一遍SpecKit流程。每个功能都可以独立验收
- 迭代开发
- SDD不是一次性的过程，不要想着把项目的需求一次性告诉AI，使用SpecKit进行完整的一次性生成
- 使用 /speckit-checklist 生成验收清单
- 推荐用claude code去修改各类规范文件，这样改出来的文件会更加规范，符合SpecKit的要求
- 如果代码有bug，不推荐去修改代码本身，而是回到规范或者计划层面去修正，重新执行implement。确保修改是系统性的而非补丁式的
SDD总结：人类掌舵，AI划桨
- SpecKit，每个阶段的产物都是md文件。可以被git版本控制，也可以被人为审查。更是被AI参考执行
- 规范，是一切的源头，代码，只是规范的产物
- SDD更加适合中大型的项目，对于小型的，临时的，只是为了个原型的项目，没必要
