一、什么是 Spec-Driven Development？
Spec-Driven Development（SDD，规范驱动开发） 是一种以"规范（Specification）"为核心驱动力的软件开发方法。其核心思想是：
在编写任何代码之前，先编写一份结构化的规范文档（Spec），规范成为人类开发者与 AI 共同的"唯一事实来源（Single Source of Truth）"，代码是规范的最终实现产物。
传统开发模式中，代码是核心，需求文档往往只是临时的"脚手架"，编码完成后即被抛弃。SDD 颠覆了这一模式------规范不再只是指导编码的文档，而是直接驱动生成可运行的实现代码。
1.1 SDD 的背景与兴起
随着 AI 编程助手（如 GitHub Copilot、Claude Code、Cursor 等）的普及，"Vibe Coding"（氛围编程） 成为热门，开发者通过与 AI 即兴对话快速生成代码。但实践中暴露出诸多问题：
- 上下文丢失：AI 在长对话中"忘记"之前的约定
- 意图模糊：相同提示词产出不同代码
- 需求不可追溯：需求隐含在聊天记录中
- AI 幻觉：模糊需求触发逻辑偏差
SDD 正是为解决这些问题而生------在 AI 动手之前，人类与 AI 先达成一套关于架构、边界与逻辑的共识文档。
二、规范（Spec）到底是什么？
目前"规范"还没有通用严格定义，但可理解为：
规范是一组结构化、面向行为的自然语言文档，用以准确表达软件功能、为 AI 代码生成提供指令基础。
2.1 规范 vs 其他文档
| 文档类型 | 关注点 | 生命周期 | 用途 |
|---|---|---|---|
| Spec（规范） | 具体功能实现的细化要求 | 任务驱动型 | AI 代码生成指令 |
| Memory Bank | 全局性知识与原则 | 长期有效 | 项目所有 AI 交互 |
| PRD（产品需求文档） | 业务需求与用户场景 | 项目阶段性 | 产品设计指导 |
| AGENTS.md / 架构描述 | 项目"背景知识" | 长期维护 | 上下文感知 |
2.2 规范的典型内容
一份完整的 Spec 通常包含：
- 功能描述：做什么、为什么
- 技术栈约束：编程语言、框架、数据库等
- 接口规范：API 路径、参数、返回值、错误码
- 数据结构：领域模型、DTO 定义
- 业务规则：边界条件、验收标准
- 代码风格：命名规则、缩进风格
三、SDD 的三个实践层级
根据学术论文及行业实践，SDD 在实践中分为三个层级：
Level 1: 规范优先
Spec-First
Level 2: 规范锚定
Spec-Anchored
Level 3: 规范即源码
Spec-as-Source
Level 1：规范优先（Spec-First）
- 优先撰写规范文档，贯穿 AI 辅助开发流程
- 规范仅为暂时性产物，任务完成后可删除
- 绝大多数 SDD 实践停留在此层级
Level 2：规范锚定（Spec-Anchored）
- 规范文档成为长期资产
- 持续与功能进化同步更新维护
- 规范可追溯、可审计
Level 3：规范即源码（Spec-as-Source）
- 规范作为唯一编辑对象
- 开发者只维护规范，代码完全由 AI 自动生成
- 目前仍处于理想化阶段
四、SDD 的核心工作流
是
否
需求输入
撰写规范
Spec
生成计划
Plan
任务分解
Tasks
AI 代码生成
Implement
验证与测试
Verify
通过?
归档规范
Archive
4.1 典型五步工作流
| 步骤 | 动作 | 产出 |
|---|---|---|
| 1. 初始化 | 安装 CLI 工具，初始化项目 | 项目配置文件 |
| 2. 规范创建 | 编写功能描述与约束 | spec.md |
| 3. 计划生成 | AI 生成技术方案 | plan.md |
| 4. 任务分解 | 拆解为可执行的离散任务 | tasks.md |
| 5. 实现与验证 | AI 按任务逐步生成代码 | 可运行代码 |
五、主流 SDD 工具对比
5.1 工具全景
SDD 工具生态
GitHub spec-kit
Amazon Kiro
Tessl Framework
OpenSpec
BMAD-METHOD
5.2 详细对比
| 维度 | GitHub spec-kit | Amazon Kiro | Tessl | OpenSpec |
|---|---|---|---|---|
| 定位 | 企业级 SDD 框架 | AI-native IDE | SDD 平台 | 轻量级开源框架 |
| 核心理念 | "宪法"模式 Constitution | 用户故事 + EARS 标记 | 规范即源码 | 提案-规范-归档闭环 |
| 规范结构 | spec.md + plan.md + tasks/ + constitution.md | requirements.md + design.md + tasks.md | 结构化规范语言 | proposal.md + spec.md + design.md + tasks.md |
| 工作流 | Specify → Plan → Task → Implement | Spec → Design → Tasks | 规范 → 生成 → 验证 | /opsx:new → /opsx:ff → /opsx:apply → /opsx:archive |
| AI 兼容性 | Copilot / Claude Code / Gemini CLI | 仅 Claude（内置） | 自有 Agent | Cursor / Claude Code / Copilot 等 |
| 适合场景 | 大型团队、企业级项目 | 新项目快速原型 | 代码完全自动生成 | 存量项目增量改动 |
| 开源 | 是 | 否 | 否 | 是 |
| 学习成本 | 中等 | 低 | 中等 | 低 |
5.3 选型建议
| 场景 | 推荐工具 |
|---|---|
| 新启动项目（0 → 1） | Kiro / spec-kit |
| 存量项目改造（1 → n） | OpenSpec / Tessl |
| 企业级治理需求 | spec-kit |
| 个人/小团队轻量使用 | OpenSpec |
| 锁定 AWS 生态 | Kiro |
六、大厂实践动态
2025-2026 年，SDD 已被多个头部厂商采纳：
| 厂商 | 工具/产品 | SDD 实践 |
|---|---|---|
| GitHub | spec-kit | 开源 SDD 框架，四阶段工作流 |
| Amazon/AWS | Kiro | 内置 Spec 工作流的 AI IDE |
| 阿里巴巴 | Qoder Quest Mode | Spec 驱动的 AI 自主编程 |
| 腾讯云 | CloudBase AI Toolkit | 集成 Spec 工作流 |
| Gemini CLI | 支持 spec-kit 协同 |
七、SDD 的优势与挑战
7.1 核心优势
锁定意图
高质量代码输出
可追溯性
团队协作对齐
降低重构风险
具体优势：
- 锁定意图：编码前与 AI 达成共识，避免偏离
- 减少 AI 幻觉：AI 依据明确 Spec 而非模糊对话
- 可追溯性：规范版本化、可审计，便于维护
- 团队协作对齐：统一"规范语言"，减少多方误解
- 降低重构风险：提前明确边界，减少后期返工
- 开发者角色升级：从"写代码"转向"设计系统"
7.2 面临的挑战
- 上下文盲点：AI 对存量项目的隐式知识理解有限
- 规范膨胀：小功能也可能产生大量 Markdown 文件
- 维护成本：规范需随代码同步更新，否则成为负债
- 定义模糊：SDD 术语尚无统一标准
- 敏捷性争议：编码前大量文档可能回归"瀑布模型"
- 工具锁定：部分工具绑定特定 IDE/模型
八、SDD 与相关方法论对比
开发方法论演进
瀑布模型
Waterfall
敏捷开发
Agile
TDD
测试驱动开发
BDD
行为驱动开发
SDD
规范驱动开发
MDD
模型驱动开发
| 方法论 | 核心驱动 | 主要产物 | AI 适配性 |
|---|---|---|---|
| TDD | 测试用例 | 测试代码 → 实现代码 | 中 |
| BDD | 行为描述 | Given-When-Then 场景 | 中 |
| MDD | 模型定义 | UML/DSL → 代码 | 低 |
| SDD | 规范文档 | Spec → AI 生成代码 | 高 |
| SpecDD | 规范点(Spec) | 需求-开发-测试全链路 | 中 |
SDD 与 MDD 的历史关系
SDD 在理念上与 MDD（模型驱动开发）有相似之处------都希望从更高层的抽象驱动代码生成。但 SDD 在以下方面有所不同：
- 使用自然语言而非形式化建模语言
- 依托AI 大语言模型而非代码生成器
- 更灵活轻量，不需要复杂的建模工具
九、SDD 实践指南
9.1 何时适合使用 SDD？
适合使用：
- 有明确边界的功能变更或新需求
- 需要与产品/测试团队对齐的场景
- 实现需拆多步、多人协作的复杂功能
- 需要留存决策记录和设计审计
可以不用：
- 小修小补（改文案、调样式）
- 探路试错、快速原型验证
- 个人一次性修改
- 不需要留存规范记录的场景
9.2 快速上手 OpenSpec
bash
# 安装 CLI
npm install -g @fission-ai/openspec@latest
# 在项目中初始化
cd your-project
openspec init
# 创建新变更
/opsx:new <功能描述>
# AI 执行实现
/opsx:apply
# 归档变更
/opsx:archive9.3 快速上手 GitHub spec-kit
bash
# 安装 Specify CLI
npm install -g @github/specify
# 初始化项目
specify init
# 创建规范
/specify
# 生成计划
/plan
# 分解任务
/task
# 实现代码
/implement十、SDD 的典型工作流时序
代码库 AI Agent 规范文档 开发者 代码库 AI Agent 规范文档 开发者 loop [逐个任务] 1. 编写功能规范 2. 审查和细化 3. 提交规范给AI 4. 生成技术计划 5. 审查计划 6. 分解任务列表 7. 确认任务 8. 按任务生成代码 9. 审查代码 10. 归档规范
十一、总结与展望
当前状态
SDD 正处于快速发展期，2025-2026 年间已从概念走向工具化、产品化：
- GitHub、AWS、阿里、腾讯等大厂集体押注
- 开源工具生态逐步成熟
- 学术论文（如 arXiv:2602.00180）开始系统化总结
未来趋势
- 规范标准化：SDD 术语和规范格式将逐步统一
- 工具融合：SDD 工具将深度集成到 IDE 和 CI/CD 流水线
- 双向同步：代码变更自动反映到规范（Spec-as-Source）
- 企业级治理：合规性、审计、权限管理将成为标配
- 多 Agent 协同：不同 AI Agent 分别负责规范、设计、编码、测试
核心观点
SDD 不是对"先写文档再写代码"的简单回归，而是在 AI 时代将"意图管理"提升为软件工程的首要任务。规范是给 AI 的"合约"------越精确的合约，越可靠的代码。