chill_notes/AI工程/概念/规格驱动开发.md

规格驱动开发（SDD）

相关：AI编程演进阶段、Harness工程、Rule约束、BMAD、Spec_Kit、OpenSpec、Kiro

定义

规格驱动开发（Spec-Driven Development，SDD）是AI编程的第3阶段，以规格文档为核心的开发方法。

核心思想：Spec是单一事实来源（SSoT），所有开发活动围绕Spec展开。

核心特征

1. 规格中心化

• Spec是唯一的真相来源
• 所有代码从Spec生成
• Spec变更驱动代码变更

2. 结构化表达

• 需求以结构化形式表达
• 使用Markdown、YAML等格式
• 可机器解析和验证

3. 文件驱动

• 文件进，文件出
• 规格文件可版本化
• 规格文件可复用

SDD框架对比

维度	BMAD	Spec_Kit	OpenSpec	Kiro
定位	企业级SDD操作系统	工程化Spec工作流	轻量Spec层	IDE原生SDD
理念	Spec=治理体系+多Agent编排	Spec=开发入口+Git生命周期	Spec=变更单元（持续演化）	Spec=可执行源
生命周期	全生命周期	与分支绑定（短）	长期存在（持续）	持续驱动
粒度	大（系统/模块级）	中（Feature级）	小（变更/Patch级）	中（Feature+行为）
可执行	流程驱动	驱动开发流程	类Prompt	可生成代码+测试
自动验证	无	无	弱	强（内建）
适用场景	大型系统/多团队	新项目（0→1）	存量项目/快速迭代	小团队/高自动化

规格类型

1. 需求规格（Feature Spec）

# 用户注册功能

## 用户故事
作为一个新用户，我想要注册账号，以便使用系统功能。

## 验收标准
1. 用户可以输入邮箱和密码
2. 系统发送验证邮件
3. 用户点击链接完成验证
4. 验证成功后可以登录

## 字段定义
- email: string, required, unique
- password: string, required, min:8
- verified: boolean, default:false

2. 设计规格（Design Spec）

# 数据库设计

## users表
- id: bigint, primary key
- email: varchar(100), unique
- password: varchar(255)
- verified: tinyint(1), default:0
- created_at: timestamp
- updated_at: timestamp

3. API规格（API Spec）

openapi: 3.0.3
paths:
  /api/v1/users:
    post:
      summary: 创建用户
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/CreateUserRequest'

规格流转

过程方案（Plans）

• 每次创建新文件
• 记录实现过程
• 不修改旧文件
• 保留决策轨迹

事实方案（Designs）

• 覆盖更新最终态
• 作为下次Plan的起点
• 必须保持最新
• Source of Truth

适用场景

BMAD

• 企业级项目
• 多团队协作
• 强治理需求
• 合规要求高

Spec Kit

• 新项目（0→1）
• 需要Git集成
• 中等复杂度

OpenSpec

• 存量项目
• 快速迭代
• 轻量级需求

Kiro

• 小团队
• 高自动化需求
• AWS项目

优势

• 单一真相来源：避免信息不一致
• 可追溯：Spec变更有历史记录
• 可验证：Spec可以生成测试
• 可复用：Spec可以在项目间复用

挑战

• 初始成本：需要建立完整的Spec体系
• 维护成本：Spec需要持续更新
• 学习曲线：团队需要理解SDD理念

最佳实践

1. 从核心Spec开始：先定义最重要的规格
2. 逐步扩展：根据实践逐步添加规格
3. 定期Review：定期审查和优化规格
4. 自动化验证：尽可能自动化Spec验证

相关概念

• AI编程演进阶段：SDD是第3阶段
• Harness工程：SDD是Harness的组成部分
• 过程方案vs事实方案：SDD的规格管理方式
• BMAD、Spec_Kit、OpenSpec、Kiro：SDD框架