规范驱动开发（Spec-Driven Development）深度解析

在AI编码工具爆发式增长的2025-2026年，一种"古老而崭新"的开发范式正在重新定义软件工程的游戏规则。本文从定义出发，横跨工具链、企业案例、方法论对比与未来趋势，带你全面理解规范驱动开发（SDD）。

什么是规范驱动开发？
SDD的历史渊源与2025年的复兴
[SDD vs Vibe Coding：给AI立规矩](#SDD vs Vibe Coding：给AI立规矩)
[SDD vs TDD/BDD/DDD：方法论全景对比](#SDD vs TDD/BDD/DDD：方法论全景对比)
规范格式与工具链全景
代码生成与契约测试
[三大SDD工具深度对比：Kiro、Spec Kit、Tessl](#三大SDD工具深度对比：Kiro、Spec Kit、Tessl)
实战案例与落地路径
优势、挑战与争议
未来趋势：从开发到工程
行动建议与总结

1. 什么是规范驱动开发？

1.1 多源定义搜集与分析

规范驱动开发（Spec-Driven Development, SDD） 是一种以结构化规范为先导的软件开发方法。其核心思想是：在编写代码之前，先编写一份描述系统行为的规范（Spec），然后以该规范作为人和AI的"单一事实源"来驱动后续的设计、实现与验证。

以下是来自不同权威来源的定义对比：

来源	定义	发表时间
Martin Fowler / Birgitta Böckeler (Thoughtworks)	"Spec-driven development means writing a 'spec' before writing code with AI ('documentation first'). The spec becomes the source of truth for the human and the AI."	2025年10月
GitHub (Spec Kit)	"In this new world, maintaining software means evolving specifications. The lingua franca of development moves to a higher level, and code is the last-mile approach."	2025年9月
Tessl	"A development approach where specs --- not code --- are the primary artifact. Specs describe intent in structured, testable language, and agents generate code to match them."	2025年
GitHub Blog	"Instead of coding first and writing docs later, in spec-driven development, you start with a spec. This is a contract for how your code should behave and becomes the source of truth your tools and AI agents use to generate, test, and validate code."	2025年9月
Thoughtworks 技术雷达 Vol.34	"Spec-driven development is an emerging approach to AI-assisted coding workflows... workflows that begin with a structured functional specification, then proceed through multiple steps to break it down into smaller pieces, solutions and tasks."	2025年11月

定义差异分析：

共同点：所有定义都强调"先写规范，后写代码"，规范成为"事实源"
分歧点一：是否必须依赖AI？ Martin Fowler的文章明确将SDD定位为"AI辅助编码工作流"的一部分；而传统的"contract-first"方法（如OpenAPI先行）并不依赖AI
分歧点二：规范是否必须机器可读？ Tessl强调规范用"结构化、可测试的语言"编写；而Kiro和Spec Kit允许用自然语言+Markdown
分歧点三：规范的生命周期？ 有的工具认为规范是一次性的（用完即弃），有的认为规范应该长期维护

1.2 SDD的三个层级

根据Birgitta Böckeler的分析，SDD存在三个递进的实现层级：

复制代码

┌─────────────────────────────────────────────────────┐
│ Level 3: Spec-as-Source（规范即源码）               │
│   ↑ 人只编辑规范，代码完全自动生成                  │
│   │ 代码标注 "GENERATED FROM SPEC - DO NOT EDIT"    │
├─────────────────────────────────────────────────────┤
│ Level 2: Spec-anchored（规范锚定）                  │
│   ↑ 规范在功能完成后继续保留，随功能演进更新        │
├─────────────────────────────────────────────────────┤
│ Level 1: Spec-first（规范优先）                     │
│     为当前任务编写规范，任务完成后规范可能被弃用     │
└─────────────────────────────────────────────────────┘

来源: Birgitta Böckeler, "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl", martinfowler.com, 2025年10月15日

1.3 什么是"规范（Spec）"？

"A spec is a structured, behavior-oriented artifact --- or a set of related artifacts --- written in natural language that expresses software functionality and serves as guidance to AI coding agents."

--- Birgitta Böckeler

规范与以下概念的区别：

与提示词（Prompt）的区别：规范是结构化的、持久的；提示词是即时的、一次性的
与Memory Bank的区别：Memory Bank（如AGENTS.md、architecture.md）是跨所有会话的上下文；规范只与特定功能的任务相关
与PRD的关系：规范最接近"产品需求文档（PRD）"的概念，但更面向AI消费

2. SDD的历史渊源与2025年的复兴

2.1 概念起源

SDD并非2025年的全新发明。其根源可追溯至：

Contract-First API Design（合约优先设计）：自Swagger/OpenAPI出现以来（2011年），"先写API规范，再写实现"的实践就已存在
Model-Driven Development（模型驱动开发, MDD）：2000年代流行的MDD使用UML或自定义DSL作为"规范"，通过代码生成器产出代码
Executable Specifications（可执行规范）：BDD（行为驱动开发）中Cucumber等工具让规范可以直接运行
Design-by-Contract（契约式设计）：Bertrand Meyer在1986年提出的概念

2.2 为什么AI让SDD重新火热？

2025年SDD复兴的核心驱动力：

驱动因素	说明
LLM上下文窗口扩大	从8K到200K+ tokens，AI可以"读完"完整规范
AI编码能力提升	从补全到全文件/全项目生成
Vibe Coding的痛点暴露	无约束的AI生成导致质量问题和维护噩梦
非确定性问题	相同提示词每次生成不同代码，规范提供"锚定"机制

Thoughtworks技术雷达原文（2025年11月，Assess级别） ：

"Spec-driven development is an emerging approach to AI-assisted coding workflows. While the term's definition is still evolving, it generally refers to workflows that begin with a structured functional specification, then proceed through multiple steps to break it down into smaller pieces, solutions and tasks."

2.3 关键里程碑

2025年2月：Andrej Karpathy提出"Vibe Coding"概念
2025年7月：Amazon推出Kiro IDE，内置SDD工作流
2025年9月：GitHub发布Spec Kit开源工具包
2025年10月：Tessl Framework进入私有测试
2025年11月：Thoughtworks技术雷达将SDD列入"Assess"象限
2026年：SDD工具生态继续快速演化

3. SDD vs Vibe Coding：给AI立规矩

3.1 什么是Vibe Coding？

Vibe Coding 是AI研究者Andrej Karpathy于2025年2月在X（Twitter）上提出的概念：

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists... I 'Accept All' always, I don't read the diffs anymore."

核心特征：

用自然语言描述需求，AI直接生成代码
开发者不阅读、不理解生成的代码
通过结果反馈（能跑就行）迭代修复
2025年被Collins词典评为"年度词汇"

来源: Wikipedia "Vibe coding" 条目; Karpathy X post, 2025年2月2日

3.2 Vibe Coding的主要问题

问题类别	具体表现	来源
安全漏洞	Lovable平台170/1645个应用存在信息泄露	Semafor, 2025年5月
代码质量	AI共创代码"重大问题"率是人类代码的1.7倍	CodeRabbit, 2025年12月
技术债务	代码重构量从25%降至10%，代码重复4倍增长	GitClear, 2025年
生产力悖论	经验开发者使用AI工具实际慢19%（尽管自认为快20%）	METR, 2025年7月
维护噩梦	"Vibe coding hangover" --- 接手AI代码如同噩梦	Fast Company, 2025年9月
删库事件	Replit AI agent删除用户生产数据库	The Register, 2025年7月

3.3 SDD作为Vibe Coding的"解毒剂"

GitHub Blog的表述最为直接：

"As coding agents have grown more powerful, a pattern has emerged: you describe your goal, get a block of code back, and often... it looks right, but doesn't quite work. This 'vibe-coding' approach can be great for quick prototypes, but less reliable when building serious, mission-critical applications."

"The issue isn't the coding agent's coding ability, but our approach. We treat coding agents like search engines when we should be treating them more like literal-minded pair programmers."

SDD与Vibe Coding的核心对比：

维度	Vibe Coding	SDD
输入	模糊的自然语言提示	结构化的功能规范
控制程度	低------"Accept All"	高------每个阶段检查点验证
适用场景	原型、个人项目、周末项目	生产级应用、团队协作
AI角色	自由发挥	按规范执行
可维护性	低	高（规范即文档）
安全性	堪忧	规范中可嵌入安全约束

3.4 某些场景下Vibe Coding可能更合适

公平地说，并非所有场景都需要SDD：

一次性脚本：数据清洗、格式转换等用完即弃的工具
快速原型验证：验证技术可行性，不关心长期维护
个人学习项目：探索新技术栈，不进生产环境
创意探索：快速迭代UI设计，寻找灵感

Simon Willison的界定标准："If an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding in my book --- that's using an LLM as a typing assistant."

4. SDD vs TDD/BDD/DDD：方法论全景对比

4.1 对比矩阵

维度	SDD	TDD	BDD	DDD	Code-first
核心思想	先写规范，规范驱动AI生成代码	先写测试，测试驱动实现	用业务语言描述行为，行为驱动开发	以领域模型为中心组织代码	先写代码，后补文档
最先编写	功能规范文档	失败的单元测试	Given-When-Then场景	统一语言+领域模型	业务逻辑代码
主要工件	Spec文档（Markdown/结构化文本）	测试套件	特性文件（.feature）	领域模型+限界上下文	源代码
目标受众	开发者+AI Agent	开发者	开发者+产品+QA	架构师+开发者+领域专家	开发者
AI时代适用性	⭐⭐⭐⭐⭐ 专为AI设计	⭐⭐⭐ AI可生成测试	⭐⭐⭐ AI可理解场景	⭐⭐⭐⭐ 领域知识对AI有指导意义	⭐⭐ 无结构化约束
最适合场景	AI辅助的中大型功能开发	复杂业务逻辑的精确实现	跨角色协作的需求澄清	复杂业务领域的系统设计	快速迭代的小型项目
反馈速度	中（需等规范→代码生成）	快（秒级测试反馈）	中（需运行场景）	慢（设计层面反馈）	快（直接运行代码）

4.2 SDD是TDD的替代还是扩展？

结论：SDD是TDD之上的扩展，而非替代。

理由：

层级不同：TDD在代码层面工作（微观），SDD在需求/设计层面工作（宏观）
互补关系：Spec Kit的任务分解中明确包含"test-driven development structure"
SDD + TDD的组合：先用SDD确定"做什么"，再用TDD确保"做对了"

GitHub Spec Kit文档中明确提到："If tests are requested, test tasks are included and ordered to be written before implementation"------SDD流程内嵌了TDD。

4.3 推荐的方法论组合（2025-2026）

在当前技术环境下，推荐组合使用：

SDD + TDD：SDD负责宏观的功能规范和任务分解，TDD负责微观的实现正确性
SDD + DDD：DDD提供领域模型和统一语言，SDD将其转化为AI可消费的规范
SDD + BDD：BDD的Given-When-Then格式可直接作为SDD规范的一部分

5. 规范格式与工具链全景

5.1 六大规范格式对比

格式	主要用途	机器可读？	支持代码生成？	常见工具生态	最适合场景
OpenAPI	REST API描述	✅ YAML/JSON	✅ 50+语言	Swagger UI, Postman, OpenAPI Generator	同步REST API
AsyncAPI	事件驱动API描述	✅ YAML/JSON	✅	AsyncAPI Generator, Specmatic	消息队列/事件流
Protocol Buffers	RPC接口+数据序列化	✅ .proto	✅ 多语言	protoc, gRPC, buf	高性能微服务通信
GraphQL Schema	查询语言类型定义	✅ SDL	✅	Apollo, GraphQL Codegen	灵活前端数据获取
JSON Schema	数据结构验证	✅ JSON	✅ 部分	AJV, json-schema-to-typescript	数据验证/配置
TypeSpec	多协议API设计	✅ .tsp	✅ OpenAPI/JSON Schema/Protobuf	TypeSpec compiler, VS Code扩展	大规模API设计

5.2 分类

API描述语言：OpenAPI、AsyncAPI、GraphQL Schema、TypeSpec

理由：定义服务的接口契约，包含端点、操作、请求响应格式

数据描述语言：Protocol Buffers、JSON Schema

理由：主要定义数据结构和序列化格式，不直接描述API行为

跨类别：TypeSpec可同时生成API描述（OpenAPI）和数据格式（JSON Schema、Protobuf）

5.3 TypeSpec与OpenAPI的关系

TypeSpec是微软推出的API设计语言，它解决了OpenAPI的以下痛点：

typespec 复制代码

// TypeSpec --- 简洁、可复用、有类型系统
import "@typespec/http";
using Http;

model Store {
  name: string;
  address: Address;
}

@route("/stores")
interface Stores {
  list(@query filter: string): Store[];
  read(@path id: Store): Store;
}

TypeSpec → 自动生成 → OpenAPI YAML（通常数百行）

问题	OpenAPI 手写	TypeSpec
冗长重复	数千行YAML	几十行TypeSpec
跨协议	需要维护多份规范	一份TypeSpec生成多格式
复用性	需$ref引用，容易出错	原生model继承和组合
IDE支持	有限的schema验证	完整的语言服务器支持

来源: https://typespec.io/ --- "Design your data up front and generate schemas, API specifications, client/server code, docs, and more."

6. 代码生成与契约测试

6.1 OpenAPI Generator深度调研

支持规模：

50+ 客户端生成器
40+ 服务端生成器
支持文档、配置、Schema生成

可生成的产物类型：

客户端SDK：Java, Python, TypeScript, Go, Ruby, C#, Swift, Kotlin等
服务端骨架：Spring Boot, Flask, Express, ASP.NET, Go Gin等
文档：HTML, Cwiki
配置：Apache2, Nginx配置
Schema：MySQL表定义, GraphQL Schema

CLI命令示例：

bash 复制代码

openapi-generator generate \
  -i petstore.yaml \       # 输入：OpenAPI规范文件
  -g python \              # 生成器：目标语言/框架
  -o ./generated-client \  # 输出目录
  --additional-properties=packageName=petstore_client  # 额外配置

避免覆盖手写逻辑的设计模式：

Inversion of Control (IoC)：服务端骨架只生成接口定义，业务逻辑写在单独文件
.openapi-generator-ignore：类似.gitignore，标记不应被覆盖的文件
模板覆盖：自定义Mustache模板，控制生成内容

"再次运行生成器"的设计模式 ：叫做 Regeneration Pattern 或 Template-based Generation，通过IoC确保每次重新生成不会破坏业务代码。

6.2 代码生成工具对比

工具	优势领域	输入格式	输出类型
OpenAPI Generator	全能型REST API生态	OpenAPI 2.0/3.x	客户端/服务端/文档
protoc	高性能跨语言RPC	.proto	gRPC客户端/服务端
GraphQL Codegen	前端类型安全	GraphQL Schema + Operations	TypeScript类型/Hooks
AsyncAPI Generator	事件驱动架构	AsyncAPI	消息处理器骨架

6.3 代码生成的常见问题

搜集自多篇讨论"openapi generator limitations"的文章：

模板质量参差不齐：社区维护的生成器质量不一，有些生成的代码不够idiomatic
过度生成：为简单API生成过多样板代码，增加维护负担
规范与实现的漂移：规范更新后忘记重新生成，或生成后手动修改导致不一致
复杂业务逻辑无法表达：规范只能描述接口，无法描述内部逻辑
学习曲线：配置选项过多，新手容易迷失

6.4 契约测试与SDD的关系

Specmatic 是将契约测试与SDD结合的代表性工具：

"Specmatic supercharges your API Specifications by leveraging them as 'Executable Contracts'."

工作原理：

OpenAPI/AsyncAPI/GraphQL规范 → 自动转化为可执行的契约测试
无需手写测试代码（No-Code）
自动生成正向测试（功能验证）和负向测试（边界条件）

契约测试 vs 传统集成测试：

维度	契约测试	传统集成测试
依赖	不需要真实服务运行	需要所有服务可用
速度	毫秒级	秒~分钟级
稳定性	高（隔离测试）	低（环境依赖多）
覆盖	接口契约级别	端到端流程

订单服务契约测试示例流程：

复制代码

┌─────────────────────────────────────────────────────────────┐
│                     中央契约仓库                             │
│              orders-api-spec.yaml (OpenAPI)                  │
└─────────────┬───────────────────────────┬───────────────────┘
              │                           │
     ┌────────▼────────┐        ┌────────▼────────┐
     │  Provider（订单服务）│    │  Consumer（前端）   │
     │                  │        │                  │
     │ Specmatic自动生成 │        │ Specmatic自动生成 │
     │ 请求→验证响应    │        │ Mock服务          │
     │ 符合规范         │        │ （智能虚拟化）     │
     └──────────────────┘        └──────────────────┘
              │                           │
              ▼                           ▼
     规范变更时CI自动           消费方无需等待
     触发契约测试               提供方就绪即可开发

来源: specmatic.io; 信任企业包括British Airways, Commonwealth Bank of Australia, Prudential, Telstra等

7. 三大SDD工具深度对比：Kiro、Spec Kit、Tessl

7.1 工具概览

维度	Kiro (Amazon)	Spec Kit (GitHub)	Tessl Framework
发布时间	2025年7月	2025年9月	2025年（私有Beta）
分发方式	独立IDE（基于VS Code） + CLI	CLI + 工作区配置	CLI + MCP服务器
SDD层级	Spec-first	Spec-first（探索Spec-anchored）	Spec-anchored / Spec-as-source
工作流	Requirements → Design → Tasks	Constitution → Specify → Plan → Tasks → Implement	Spec ↔ Code（双向同步）
支持的AI工具	内置Claude	30+ AI编码工具	多种编码助手
核心理念	轻量简洁	可定制+社区驱动	规范即主工件

7.2 GitHub Spec Kit详解

核心命令：

命令	作用
`/speckit.constitution`	创建项目治理原则（不可变的架构约束）
`/speckit.specify`	定义要构建什么（功能需求+用户故事）
`/speckit.plan`	创建技术实现计划（指定技术栈和约束）
`/speckit.tasks`	生成可操作的任务列表
`/speckit.implement`	按计划执行所有任务

设计理念：

Intent-driven development：规范定义"什么"而非"怎么做"
Multi-step refinement：多步精化而非一次性代码生成
Constitution（宪法）：不可变的项目原则，每次生成都必须遵守

与GitHub Copilot协同 ：Spec Kit通过.github/prompts/目录注入slash命令，Copilot在生成代码时参考规范文件。

来源: https://github.com/github/spec-kit; GitHub Blog "Spec-driven development with AI", 2025年9月2日

7.3 Amazon Kiro详解

Kiro的口号："Bring engineering rigor to agentic development"（为Agent开发带来工程严谨性）

工作流：

Requirements：自然语言 → 结构化需求（EARS Notation）+ 验收标准（Given-When-Then）
Design：分析代码库 → 架构设计、系统设计、技术栈选择
Tasks：离散任务列表，按依赖排序，含可选的测试

"Go from vibe coding to viable code" 是Kiro的市场定位核心表述。

来源: https://kiro.dev/

7.4 观察与批判

Birgitta Böckeler（Thoughtworks）在试用三个工具后提出的核心质疑：

"用大锤砸核桃"问题：小任务用SDD流程过于笨重------一个小bug变成4个用户故事16个验收标准
Markdown审查疲劳：Spec Kit生成大量Markdown文件，审查这些比审查代码更累
虚假的控制感：即使有详尽的规范，AI Agent仍然经常无视指令
MDD的幽灵：Spec-as-source让人想起已经失败的模型驱动开发

"I'd rather review code than all these markdown files. An effective SDD tool would have to provide a very good spec review experience."

--- Birgitta Böckeler, Thoughtworks

8. 实战案例与落地路径

8.1 企业案例汇总

公司/项目	使用的规范格式	采用SDD的初衷	取得的效果
Specmatic客户群（British Airways, CBA, Telstra等）	OpenAPI, AsyncAPI, GraphQL	消除API集成问题，加速交付	API开发周期减少75%，流效率提升40%
Kiro早期用户	自然语言Spec（Kiro格式）	AI编码的工程化	"从概念到原型仅一个周末"，"功能开发时间从周缩短至天"
GitHub Spec Kit社区	Markdown Spec	结构化AI编码流程	支持30+AI工具集成，2700+ GitHub Stars

8.2 Specmatic深度案例

背景：Specmatic是将"API规范即可执行契约"理念落地的先驱工具

技术栈：支持OpenAPI, AsyncAPI, GraphQL, gRPC(Protobuf), WSDL, Arazzo

实施过程：

团队将现有API规范存入"中央契约仓库"（Git）
Specmatic自动从规范生成契约测试（零代码）
Provider方CI流水线自动验证实现是否符合规范
Consumer方获得智能Mock服务，可并行开发
规范变更时自动触发向后兼容性检查

量化效果（来自Specmatic官方数据）：

消除约25%的合约不匹配缺陷
开发周期缩短达75%
流效率提升40%

来源: specmatic.io; "Trusted By" 列出 British Airways, CBA, Macquarie, Prudential, Telstra, Tietoevry, TM Forum

8.3 从零到一的实践步骤

以OpenAPI + Spec Kit为例：

第1步：编写最小OpenAPI规范

yaml 复制代码

openapi: 3.0.0
info:
  title: Todo API
  version: 1.0.0
paths:
  /todos:
    get:
      summary: List all todos
      responses:
        '200':
          description: A list of todos
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Todo'
components:
  schemas:
    Todo:
      type: object
      required: [id, title]
      properties:
        id:
          type: integer
        title:
          type: string
        completed:
          type: boolean

第2步：生成客户端代码

bash 复制代码

openapi-generator generate -i todo-api.yaml -g typescript-axios -o ./client

第3步：生成服务端骨架

bash 复制代码

openapi-generator generate -i todo-api.yaml -g python-flask -o ./server

第4步：可修改 vs 会重新生成的代码

类别	文件	说明
✅ 可修改	`controllers/todo_controller.py`	业务逻辑实现
⚠️ 会重新生成	`models/todo.py`	数据模型定义
⚠️ 会重新生成	`openapi/openapi.yaml`	规范副本
✅ 可修改	`.openapi-generator-ignore`	保护列表

第5步：测试

bash 复制代码

# 用Specmatic进行契约测试（零代码）
specmatic test --contract todo-api.yaml --host localhost --port 5000

8.4 常见坑点与解决方案

坑点	原因	解决方案
生成的代码风格不符合项目规范	默认模板不够定制化	自定义Mustache模板
规范更新后忘记重新生成	手动流程容易遗忘	CI/CD中加入生成和验证步骤
复杂继承关系生成错误	OpenAPI的allOf/oneOf处理复杂	简化规范结构或使用TypeSpec

9. 优势、挑战与争议

9.1 十大优势（按维度分类）

对个人开发者

减少认知负载：先想清楚做什么，再交给AI执行 $GitHub Blog$
提高AI输出质量：明确的规范减少AI的"猜测"，降低错误率 $GitHub Blog$
强制思考：写规范的过程迫使你理清需求，避免"动手写代码才发现没想清楚" $Martin Fowler$

对团队协作

统一的沟通语言：规范成为团队的"单一事实源"，消除信息不对称 $Specmatic$
并行开发：前后端/多服务团队可基于规范同时开发，无需等待 $Specmatic$
降低新人上手门槛：阅读规范比阅读数万行代码快得多 $GitHub Spec Kit$

对AI辅助

可重复生成：相同规范多次生成，结果更一致 $Tessl$
技术栈独立：同一规范可生成Python、Go、Java等不同实现 $Spec Kit$
规范即提示词的超集：比临时写的prompt更完整、更结构化 $GitHub Blog$

对长期维护

活文档：规范与代码同步演进，永远是最新的"设计文档" $Specmatic$

9.2 十大挑战与批评

流程开销

前期投入大：对小任务来说，写规范可能比直接写代码更慢 $Birgitta Böckeler, Thoughtworks$
Markdown审查疲劳：SDD工具生成大量需要审阅的文档 $Birgitta Böckeler$
过度工程风险：为简单问题创建复杂的规范结构 $Thoughtworks技术雷达$

AI相关

虚假的控制感：即使有详尽规范，AI仍可能忽视部分指令 $Birgitta Böckeler$
非确定性：相同规范多次生成可能得到不同代码 $Martin Fowler$

方法论争议

"瀑布模型借尸还魂"：批评者认为大量前期规范设计违反敏捷原则
功能/技术分离困难：何时保持纯功能描述，何时加入技术细节？边界模糊 $Birgitta Böckeler$
"Bitter Lesson"风险：为AI手工制定详细规则最终可能不如让AI自行学习 $Thoughtworks技术雷达$

实际落地

工具不成熟：SDD工具仍在快速演化，API频繁变更 $Martin Fowler$
棕地项目困难：在已有大型代码库中引入SDD比绿地项目难得多 $Birgitta Böckeler$

9.3 "SDD是瀑布模型"的争议

反对者观点：

SDD要求先写完整规范再开始编码，这是"Big Design Upfront"
在需求快速变化的环境中，维护规范成为负担
规范可能成为"形式主义"，团队为了满足流程要求而写规范

支持者观点：

SDD的规范可以迭代修改，不是一锤定音
规范的粒度可以很小（一个user story级别）
在AI时代，规范→代码的转化速度极快，不像传统瀑布那样有巨大时间成本
Spec Kit明确支持"iterative enhancement"模式

我的判断 ：SDD与敏捷并不矛盾，关键在于规范的粒度控制。在Scrum团队中：

Sprint级别：每个Story可以有一个轻量级Spec
不需要在Sprint开始前写完所有规范
规范可以在Refinement会议中逐步补充

Thoughtworks技术雷达的态度较为审慎："We may be relearning a bitter lesson --- that handcrafting detailed rules for AI ultimately doesn't scale."

9.4 SDD与DDD的关系

SDD和DDD是互补而非竞争关系：

DDD提供"统一语言"和"限界上下文"------这正是SDD规范的理想输入
SDD的规范可以使用DDD的术语体系，确保AI生成的代码符合领域模型
两者都强调"在编码之前先建立共识"

10. 未来趋势：从开发到工程

10.1 专家预测（2026-2027）

规范自动生成：从自然语言需求自动生成OpenAPI/AsyncAPI规范（Specmatic的"Genie"功能已实现：描述需求→自动生成完整API规范）
Spec即Code：Tessl的方向------规范成为唯一需要人类维护的工件，代码完全自动生成
多Agent协作：不同的AI Agent负责规范的不同部分（需求Agent、设计Agent、实现Agent）
规范验证自动化：AI自动检查规范的完整性、一致性和可实现性

10.2 "规范"与"提示词"的边界模糊化

"I've even recently heard people use 'spec' basically as a synonym for 'detailed prompt'."

--- Birgitta Böckeler

当前趋势显示：

规范正在变得越来越像"高质量的提示词"
提示词工程正在变得越来越像"规范设计"
未来可能融合为"意图工程（Intent Engineering）"

10.3 从"Spec-Driven Development"到"Spec-Driven Engineering"

GitHub在Spec Kit中探索的方向暗示了一个更大的愿景：

"We're moving from 'code is the source of truth' to 'intent is the source of truth.' With AI the specification becomes the source of truth and determines what gets built."

--- GitHub Blog

Development vs Engineering的区别：

Development：单个项目/功能的开发流程
Engineering：整个组织的工程实践体系，包括治理、合规、可扩展性

10.4 个人反思

如果我只有一个周末尝试SDD：

选择 OpenAPI + Spec Kit + GitHub Copilot
构建一个简单的REST API（如Todo应用）
原因：OpenAPI生态最成熟，Spec Kit免费开源，Copilot集成最顺滑

SDD不值得用的场景：

探索性原型：当你还不确定要做什么时，写规范是浪费时间
极小的修改：修复一个CSS样式、改一行配置------用SDD是"大炮打蚊子"

SDD会是长期范式还是一阵风口？

我认为SDD的核心理念 （先明确意图再编码）将是长期存在的范式，但当前的具体工具和流程可能会大幅演变。理由：

历史证据：Contract-first API设计已经存活了15年以上
AI驱动力：只要AI生成代码需要约束和指导，SDD就有价值
但工具形态可能变化：从显式的Markdown文件→可能内嵌到IDE中不可见

最大的"顿悟时刻"来自Birgitta Böckeler的这段话："LLMs take some of the overhead and constraints of MDD away, so there is a new hope that we can now finally focus on writing specs and just generate code from them. With LLMs, we are not constrained by a predefined and parseable spec language anymore."

这让我意识到：SDD之所以在2025年重新成为可能，不是因为"规范"变了，而是因为"从规范到代码"的成本趋近于零了。

11. 行动建议与总结

11.1 不同读者的下一步

类型A（新手开发者）：

从写一份简单的OpenAPI规范开始（20行即可）
用OpenAPI Generator体验"规范→代码"的魔力
在个人项目中尝试Kiro或Spec Kit

类型B（团队Leader）：

评估团队的API开发流程是否存在规范漂移问题
在一个新微服务上试点Contract-first + Specmatic
制定规范模板和审查标准

类型C（架构师/决策者）：

评估SDD在组织级别的ROI（减少集成缺陷、加速并行开发）
考虑建立"中央契约仓库"
关注TypeSpec作为统一多协议规范的可能性

11.2 三个常见误区

误区	真相
"SDD就是写更多文档"	SDD的规范是可执行的、AI可消费的，不是传统的Word文档
"SDD只适用于新项目"	存量系统可以逐步引入，例如先给新API编写规范
"SDD会让开发变慢"	前期规范投入换来后期减少返工、加速AI生成和团队协作

11.3 容易混淆的术语澄清

Contract-first ≠ Spec-driven
- Contract-first专注于API接口约定（机器可读的OpenAPI等）
- Spec-driven范围更广，包含功能需求、用户故事、行为描述（可以是自然语言）
- 混淆来源：两者都强调"先写规范"
Executable Specification ≠ SDD
- 可执行规范是一种技术手段（如BDD的.feature文件、Specmatic的契约测试）
- SDD是一种开发流程/方法论
- 混淆来源：SDD经常使用可执行规范作为其落地形式
Design-first ≠ Spec-driven
- Design-first通常指先设计API，再实现（传统API设计方法）
- Spec-driven在AI时代强调规范作为AI的输入和锚定
- 混淆来源：两者在"先设计/规范"这一点上重叠

引用来源汇总

#	来源	标题	日期	URL
1	Martin Fowler / Birgitta Böckeler	Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl	2025-10-15	https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
2	Thoughtworks Technology Radar	Spec-driven development (Assess)	2025-11	https://www.thoughtworks.com/radar/techniques/spec-driven-development
3	GitHub Blog / Den Delimarsky	Spec-driven development with AI: Get started with a new open source toolkit	2025-09-02	https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
4	GitHub	Spec Kit README	2025-2026	https://github.com/github/spec-kit
5	Wikipedia	Vibe coding	持续更新	https://en.wikipedia.org/wiki/Vibe_coding
6	Specmatic	Official Website	2025-2026	https://specmatic.io/
7	Amazon / Kiro	Official Website	2025-2026	https://kiro.dev/
8	Microsoft	TypeSpec	2025-2026	https://typespec.io/
9	OpenAPI Tools	OpenAPI Generator	持续更新	https://openapi-generator.tech/
10	Andrej Karpathy	X (Twitter) post on vibe coding	2025-02-02	https://x.com/karpathy/status/1886192184808149383
11	Ars Technica	Will the future of software development run on vibes?	2025-03-05	---
12	Fast Company	The vibe coding hangover is upon us	2025-09-09	---
13	METR	Measuring the Impact of Early-2025 AI on Experienced OS Dev Productivity	2025-07-10	https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
14	CodeRabbit	State of AI vs Human Code Generation Report	2025-12-17	---
15	GitClear	How AI generated code compounds technical debt	2025-02-19	---

本文写作时间：2026年5月。SDD领域正在快速演变，建议读者关注上述工具的最新版本和Thoughtworks技术雷达的后续更新。