---
source: ../../../core/spec-driven-development.md
source_version: 2.2.0
translation_version: 2.2.0
last_synced: 2026-03-30
status: current
---

# 规格驱动开发 (SDD) 标准

**版本**: 2.3.0
**最后更新**: 2026-06-08
**适用范围**: 所有采用规格驱动开发的项目
**范围**: universal

> **语言**: [English](../../../core/spec-driven-development.md) | [繁體中文](../../zh-TW/core/spec-driven-development.md)

---

## 目的

本标准定义规格驱动开发 (SDD) 的原则与工作流程，确保变更在实施前已经过规划、记录并透过规格核准。

**关键效益**:
- 减少利益相关者与开发者之间的沟通误解
- 为所有变更提供清晰的审计轨迹
- 新团队成员更容易上手

---

## SDD 作为独立方法论

SDD (Spec-Driven Development, 2025) 是 AI 时代的方法论，区别于传统的 TDD/BDD/ATDD 家族。它源于 AI 辅助开发工具的日益普及和现代软件工程对规格优先方法的需求。

### 历史背景

| 方法论家族 | 时代 | 核心文献 | 关系 |
|-----------|-----|---------|------|
| **TDD/BDD/ATDD** | 1999-2011 | GOOS (Freeman & Pryce), Dan North, Gojko Adzic | 传统测试驱动开发家族 |
| **SDD (2025)** | 2025+ | Thoughtworks, GitHub spec-kit, Martin Fowler | AI 时代新兴概念，独立于传统家族 |

### 与测试方法论的关系

SDD **不是** "ATDD → BDD → TDD" 序列的一部分。相反，它通过正向推导生成测试工件，但仍然是一个独立的方法论。

| 方法论 | 起源 | 关注点 | SDD 集成 |
|--------|------|-------|---------|
| **TDD** | 1999, Kent Beck | 代码级测试 | 可在 SDD 实施阶段使用 |
| **BDD** | 2006, Dan North | 行为场景 | 正向推导生成 .feature 文件 |
| **ATDD** | 2003-2006, GOOS | 协作验收 | 可选的 AC 定义输入方法 |

### 关键区别

```
┌─────────────────────────────────────────────────────────────────────────────┐
│                    两个独立方法论系统                                   │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌─────────────────────────────────────┐                                   │
│   │     SDD (AI 时代方法论)           │                                  │
│   │                                      │                                  │
│   │   需求 → SPEC.md → 正向推导 → 测试 │                                  │
│   │                                      │                                  │
│   │   • 规格是权威来源                 │                                  │
│   │   • AI 辅助代码生成                │                                  │
│   │   • 正向推导生成测试结构            │                                  │
│   └─────────────────────────────────────┘                                   │
│                                                                             │
│   ┌─────────────────────────────────────┐                                   │
│   │  双循环 TDD (传统)                 │                                  │
│   │                                      │                                  │
│   │   BDD (外层循环) → TDD (内层循环)  │                                  │
│   │                                      │                                  │
│   │   • 测试驱动设计                   │                                  │
│   │   • 手动开发                       │                                  │
│   │   • ATDD 是可选协作输入，不是顺序步骤 │                                  │
│   └─────────────────────────────────────┘                                   │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘
```

---

## SDD 成熟度级别

基于 Martin Fowler 对 SDD 工具的分析 (2025)，团队可以在不同的成熟度级别运作：

| 级别 | 名称 | 描述 | 人类角色 |
|-------|------|------|---------|
| 1 | **规格优先** | 编写规格，完成后丢弃 | 编辑规格和代码 |
| 2 | **规格锚定** | 在整个演进过程中维护规格 | 编辑规格，AI 协助代码 |
| 3 | **规格即源** | 规格是唯一来源，代码自动生成 | 只编辑规格，从不接触代码 |

### 级别特征

**级别 1: 规格优先**
- 在实施前编写规格
- 规格可能在功能完成后丢弃
- 代码仍然是权威来源
- 2025 年最常见

**级别 2: 规格锚定**
- 在整个生命周期中维护规格
- 规格用于演进和维护
- AI 基于规格更新协助代码变更
- 在企业环境中日益普及

**级别 3: 规格即源**
- 规格是唯一的事实来源
- 代码标记为"已生成 - 请勿编辑"
- 任何变更都需要先修改规格
- 2025 年仍处于实验阶段

### 参考资料

- [Thoughtworks: Spec-Driven Development](https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices)
- [Martin Fowler: SDD Tools (Kiro, spec-kit, Tessl)](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
- [GitHub spec-kit](https://github.com/github/spec-kit/blob/main/spec-driven.md)

---

## AC 格式

UDS 支持两种 AC 记法。**GWT 为预设与首选**（Forward Derivation／BDD 场景生成依赖它）。**EARS**（Easy Approach to Requirements Syntax，IBM Rational）为可选补充，对事件／状态／恒常／异常需求表达更精准（XSPEC-263）。

| EARS 型 | 模板 | 用于 |
|---------|------|------|
| 恒常 Ubiquitous | `THE SYSTEM SHALL <response>` | 恒常需求（无触发）|
| 事件驱动 Event-driven | `WHEN <trigger> THE SYSTEM SHALL <response>` | 事件触发 |
| 状态驱动 State-driven | `WHILE <state> THE SYSTEM SHALL <response>` | 状态持续期间 |
| 异常 Unwanted | `IF <condition>, THEN THE SYSTEM SHALL <response>` | 错误／异常处理 |
| 选配 Optional | `WHERE <feature included> THE SYSTEM SHALL <response>` | 选配功能 |

每个 AC 提供 **GWT 或 EARS** 之一（`.ac.yaml` 的 `given/when/then` 或 `ears`）。BDD 可推导行为优先 GWT；GWT 表达牵强时改用 EARS。不强制两者并存、不移除 GWT。

## 常见陷阱

采用 SDD 时避免这些常见陷阱：

| 陷阱 | 问题 | 缓解措施 |
|------|------|---------|
| **过度形式化** | 像瀑布开发一样减缓反馈 | 保持迭代，使用短周期 |
| **规格漂移** | 规格和代码变得不同步 | 持续验证，CI/CD 中的漂移检测 |
| **AI 幻觉** | AI 生成不匹配规格的代码 | 强健验证，合约测试 |
| **规模不匹配** | 为小错误使用重型工作流 | 基于复杂性选择适当流程 |
| **过早优化** | 跳到规格即源 (级别 3) | 从规格优先开始，逐步演进 |

### 何时不使用完整 SDD

| 场景 | 建议 |
|------|------|
| 关键热修复 | 先修复，后记录文档 |
| 错别字和格式 | 直接提交，无需规格 |
| 探索性原型 | 跳过正式规格，快速迭代 |
| 小错误修复 (< 30 分钟) | 仅轻量级跟踪 |

---

## 变更评估 (SDD 前评估)

在开始 SDD 工作流程之前，评估变更的性质和范围。这可以防止过度工程化并确保变更被适当路由。

### 评估决策树

```
新需求/变更
    │
    ▼
┌─────────────────────────────────────────────────────────┐
│ Q1: 这个变更的适用范围是什么？                         │
├─────────────────────────────────────────────────────────┤
│ A) 仅限项目特定内部使用                               │
│    → 添加到 CLAUDE.md 或项目配置                      │
│    → 无需核心标准                                    │
│                                                      │
│ B) 可重用于其他项目的规则                             │
│    → 创建核心标准                                    │
│    → 评估是否需要技能/命令                            │
└─────────────────────────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────────────────────────┐
│ Q2: 这个功能需要 AI 交互吗？                           │
├─────────────────────────────────────────────────────────┤
│ A) 需要交互式工作流                                 │
│    → 创建技能                                        │
│    → 评估是否需要斜线命令                            │
│                                                      │
│ B) 静态规则/背景知识                                 │
│    → 仅核心标准                                      │
│    → 在 CLAUDE.md 中引用                            │
└─────────────────────────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────────────────────────┐
│ Q3: 用户需要直接触发吗？                              │
├─────────────────────────────────────────────────────────┤
│ A) 需要 /command 触发                                │
│    → 创建斜线命令                                    │
│                                                      │
│ B) AI 自动应用                                       │
│    → 仅技能，无需命令                                │
└─────────────────────────────────────────────────────────┘
```

### 评估结果

| 评估结果 | 要创建的工件 |
|----------|-------------|
| 仅限项目特定 | 仅更新 CLAUDE.md |
| 通用静态规则 | 核心标准 + CLAUDE.md 引用 |
| 通用交互式 | 核心标准 + 技能 |
| 用户触发工作流 | 核心标准 + 技能 + 命令 |

### 范围分类标签

在规格文档中使用这些标签指示范围：

| 标签 | 含义 | 示例 |
|------|------|------|
| `[范围: 项目]` | 项目特定，不用于分发 | CI/CD 配置，团队约定 |
| `[范围: 通用]` | 其他项目可重用 | 编码标准，测试模式 |
| `[范围: 工具]` | 工具/生成器，无需核心标准 | docs-generator, code-formatter |

---

## SDD 工作流程

```
┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│     讨论     │───▶│     提案     │───▶│     审查     │───▶│     实作     │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
                                                                   │
                                                                   ▼
                                        ┌──────────────┐    ┌──────────────┐
                                        │     归档     │◀───│     验证     │
                                        └──────────────┘    └──────────────┘
```

### 工作流程阶段

| 阶段 | 说明 | 产出物 |
|------|------|--------|
| **讨论** | 厘清需求与探索方案 | 讨论记录 |
| **提案** | 定义变更内容与原因 | `proposal.md` |
| **审查** | 利害关系人核准 | 审查意见、核准纪录 |
| **实作** | 执行已核准的规格 | 程序码、测试、文件 |
| **验证** | 确认实作符合规格 | 测试结果、审查 |
| **归档** | 关闭并归档规格 | 已归档的规格与 commits/PRs 连结 |

---

## 核心原则

### 1. SDD 工具命令优先

**规则**: 当专案集成了 SDD 工具（如 OpenSpec, Spec Kit 等）且该工具提供特定命令（例如 `/openspec` 或 `/spec` 等斜线命令）时，AI 助手**必须优先使用这些命令**，而非直接手动编辑档案。

**理由**:
- **一致性**: 工具确保规格结构遵循严格的架构。
- **可追溯性**: 命令通常会自动处理日志、ID 和连结。
- **安全性**: 工具可能有内建验证以防止无效状态。

**范例**:
- ✅ 使用 `/openspec proposal "新增登入"` 取代手动建立 `changes/add-login/proposal.md`。

---

### 2. 方法论优于工具

**规则**: SDD 是一种方法论，不绑定於单一工具。虽然 OpenSpec 是常见的实作，但本标准适用于任何 SDD 工具（例如 Spec Kit）。

**指引**:
- **通用流程**: 讨论 -> 提案 -> 审查 -> 实作 -> 验证 -> 归档。
- **工具适应**: 适应工作区中启用之 SDD 工具的特定命令与模式。

---

### 3. 先规格，后程序码

**规则**: 在没有经核准的规格或变更提案的情况下，不得进行功能性的程序码变更。

**例外情况**:
- 关键热修复（立即恢复服务，随后补文件）。
- 琐碎变更（错字、注解、格式调整）。

---

## 规格文件范本

### 提案范本

```markdown
# [SPEC-ID] 功能标题

## 摘要
简述提议的变更。

## 动机
为何需要此变更？解决什么问题？

## 详细设计
技术方法、影响的元件、资料流程。

## 验收条件
- [ ] 条件 1
- [ ] 条件 2

## 相依性
列出对其他规格或外部系统的相依性。

## 风险
潜在风险及缓解策略。
```

---

## 与其他标准集成

### 与 Commit 讯息指南集成

实作已核准的规格时，在 commit 讯息中引用规格 ID：

```
feat(auth): implement login feature

Implements SPEC-001 login functionality with OAuth2 support.

Refs: SPEC-001
```

### 与签入标准集成

在为规格签入程序码前：

1. ✅ 规格已核准
2. ✅ 实作符合规格
3. ✅ 测试涵盖验收条件
4. ✅ PR 中引用规格 ID

### 与程序码审查清单集成

审查者应验证：

- [ ] 变更符合已核准的规格
- [ ] 无超出规格范围的变更
- [ ] 规格验收条件已达成

---

## 常见 SDD 工具

| 工具 | 说明 | 命令范例 |
|------|------|----------|
| **OpenSpec** | 规格管理 | `/openspec proposal`, `/openspec approve` |
| **Spec Kit** | 轻量级规格追踪 | `/spec create`, `/spec close` |
| **手动** | 无工具，基于档案 | 手动建立 `specs/SPEC-XXX.md` |

---

## 最佳实践

### 应该做的

- ✅ 保持规格专注且原子化（每个规格一个变更）
- ✅ 包含明确的验收条件
- ✅ 将规格连结到实作 PR
- ✅ 完成后归档规格

### 不应该做的

- ❌ 在规格核准前开始编码
- ❌ 实作期间修改范围而不更新规格
- ❌ 让规格处于悬而未决状态（始终关闭或归档）
- ❌ 跳过验证步骤

---

## 双向同步评估

在处理规格及其实现时，始终评估需要同步的内容。变更可以源自任何工件，并应传播到相关工件。

### 同步矩阵

| 变更来源 | 评估同步到 |
|----------|------------|
| 核心标准 | → 技能、命令、AI YAML、翻译 |
| 技能 | → 核心标准（如适用）、命令、翻译 |
| 命令 | → 技能、核心标准（如适用）、翻译 |

### 同步检查清单模板

在规格文档中包含此检查清单：

```markdown
## 同步检查清单

### 从核心标准开始
- [ ] 创建/更新相应技能？（如交互式）
- [ ] 创建/更新斜线命令？（如用户触发）
- [ ] 更新翻译？（zh-TW、zh-CN 等）
- [ ] 更新 AI YAML 版本？（如适用）

### 从技能开始
- [ ] 这个技能应该有核心标准吗？
- [ ] 如果是工具技能（例如 docs-generator），标记为"[范围: 工具]"
- [ ] 创建斜线命令？
- [ ] 更新翻译？

### 从命令开始
- [ ] 这个命令属于哪个技能？
- [ ] 更新技能文档？
- [ ] 更新翻译？
```

### 同步标记

在文档中使用这些标记指示同步状态：

| 标记 | 含义 |
|------|------|
| `[已同步: ✓]` | 所有相关工件已同步 |
| `[已同步: 待定]` | 需要同步但尚未完成 |
| `[已同步: 不适用]` | 无相关工件同步（例如独立工具） |

---

## 与反向工程集成

### 概述

对于没有规格的现有程序码库，使用[反向工程标准](reverse-engineering-standards.md)来生成与 SDD 兼容的提案草稿。

### 反向工程 → SDD 流水线

```
┌─────────────────────────────────────────────────────────────────────────┐
│                    反向工程 → SDD 流水线                                  │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   现有程序码                                                             │
│        │                                                                │
│        ▼                                                                │
│   ┌────────────────────────────────────────────────────────────┐       │
│   │ /reverse-spec                                               │       │
│   │   • 程序码扫描 → 技术清单 [已确认]                            │       │
│   │   • 测试分析 → 验收条件 [已确认/推论]                         │       │
│   │   • 缺口识别 → [未知] 项目                                   │       │
│   └────────────────────────────────────────────────────────────┘       │
│        │                                                                │
│        ▼                                                                │
│   草拟规格（反向工程）                                                   │
│        │                                                                │
│        ▼                                                                │
│   ┌────────────────────────────────────────────────────────────┐       │
│   │ SDD 审查流程                                                 │       │
│   │   • 人类填写 [未知] 区块（动机、风险）                         │       │
│   │   • 利害关系人验证 [推论] 项目                                │       │
│   │   • 正式核准                                                 │       │
│   └────────────────────────────────────────────────────────────┘       │
│        │                                                                │
│        ▼                                                                │
│   已核准规格 → 继续正常 SDD 工作流程                                     │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
```

### 反向工程规格的要求

当规格透过反向工程生成时：

1. **标记状态**：在元资料中包含 `状态: 草稿（反向工程）`
2. **填写未知**：所有 `[未知]` 区块必须由人类在核准前填写
3. **验证推论**：所有 `[推论]` 项目必须经过审查和确认
4. **标准审查**：在实作前遵循正常 SDD 审查流程
5. **来源引用**：维护 file:line 参考以确保可追溯性

### 何时使用反向工程

| 情境 | 做法 |
|------|------|
| 旧系统现代化 | 从反向工程开始 |
| 记录未文件化的程序码 | 从程序码生成规格 |
| 新成员入职 | 提取规格进行知识转移 |
| 重构前的文件化 | 在重大变更前建立规格 |

### 相关命令

| 命令 | 用途 |
|------|------|
| `/reverse-spec` | 从现有程序码生成 SDD 规格 |
| `/reverse-bdd` | 将验收条件转换为 Gherkin 情境 |
| `/reverse-tdd` | 分析 BDD 情境的测试覆盖 |

---

## 与正向推导集成

### 概述

规格批准后，使用[正向推导标准](../../../core/forward-derivation-standards.md)自动从验收标准生成 BDD 场景、TDD 测试骨架和 ATDD 验收测试。

### 正向推导 → SDD 流水线

```
┌─────────────────────────────────────────────────────────────────────────┐
│                  已批准规格 → 正向推导流水线                          │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   已批准的 SPEC-XXX.md                                                   │
│        │                                                                │
│        ▼                                                                │
│   ┌────────────────────────────────────────────────────────────┐       │
│   │ /derive-all specs/SPEC-XXX.md                               │       │
│   │   • 解析验收标准                                      │       │
│   │   • 转换 AC → Gherkin 场景 [已生成]                   │       │
│   │   • 生成 TDD 测试骨架 [已生成]                        │       │
│   │   • 创建 ATDD 验收表 [已生成]                         │       │
│   └────────────────────────────────────────────────────────────┘       │
│        │                                                                │
│        ▼                                                                │
│   输出文件                                                              │
│   ├── features/SPEC-XXX.feature (BDD)                                  │
│   ├── tests/SPEC-XXX.test.ts (TDD)                                     │
│   └── acceptance/SPEC-XXX-acceptance.md (ATDD)                         │
│        │                                                                │
│        ▼                                                                │
│   人工审查 → BDD/TDD 工作流程继续                                      │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
```

### 何时使用正向推导

| 场景 | 方法 |
|------|------|
| 规格已批准，开始实施 | 使用 `/derive-all` 生成测试结构 |
| 需要快速 BDD 场景 | 使用 `/derive-bdd` 生成 Gherkin |
| 开始 TDD 工作流 | 使用 `/derive-tdd` 生成测试骨架 |
| 手动验收测试 | 使用 `/derive-atdd` 生成测试表 |

### 相关命令

| 命令 | 输入 | 输出 | 用途 |
|------|------|------|------|
| `/derive-bdd` | SPEC-XXX.md | .feature | AC → Gherkin 场景 |
| `/derive-tdd` | SPEC-XXX.md | .test.ts | AC → 测试骨架 |
| `/derive-atdd` | SPEC-XXX.md | acceptance.md | AC → 测试表 |
| `/derive-all` | SPEC-XXX.md | 全部以上 | 完整推导流水线 |
| `/derive-contracts` | SPEC-XXX.md | contract.json, schema.json | AC → 合约验证 |

---

## 验证层

SDD 需要强大的验证机制，以确保生成的代码与规格保持一致。验证层在整个开发生命周期中提供持续验证。

### 理论基础

| 理论 | 来源 | 在 SDD 中的应用 |
|------|------|---------------|
| **设计合约** | Bertrand Meyer, 1986 | AC 作为前置/后置条件 |
| **形式化验证** | 计算机科学 | 规格 vs 实现 |
| **示例规格化** | Gojko Adzic, 2011 | 可执行规格 |
| **合约测试** | Pact, 2013+ | 服务合约验证 |

### 验证机制

| 机制 | 目的 | 工具 |
|------|------|------|
| **合约测试** | 验证实现遵守接口保证 | Pact, Spring Cloud Contract, Specmatic |
| **模式验证** | 拒绝违反结构要求的负载 | JSON Schema, OpenAPI 验证器 |
| **漂移检测** | 检测规格与行为之间的分歧 | CI/CD 集成, Specmatic |
| **向后兼容性** | 将变更分类为添加/破坏 | OpenAPI 差异工具 |

### SDD 验证流程

```
┌─────────────────────────────────────────────────────────────────────────────┐
│                         SDD 验证层                                    │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   SPEC-XXX.md (已批准)                                                    │
│        │                                                                    │
│        ├──→ 正向推导                                                        │
│        │         │                                                          │
│        │         ├──→ 合约测试 (已生成)                                    │
│        │         ├──→ 模式验证器 (已生成)                                   │
│        │         ├──→ BDD 场景 (已生成)                                    │
│        │         └──→ TDD 骨架 (已生成)                                    │
│        │                                                                    │
│        └──→ 实施 (AI 辅助)                                                 │
│                  │                                                          │
│                  ▼                                                          │
│        ┌─────────────────────────────────────────────────────┐             │
│        │              持续验证                              │             │
│        │  ┌─────────────────────────────────────────────────┐│             │
│        │  │ 合约测试              ✓/✗                   ││             │
│        │  │ 模式验证              ✓/✗                   ││             │
│        │  │ 漂移检测              ✓/✗                   ││             │
│        │  │ BDD 场景              ✓/✗                   ││             │
│        │  │ TDD 单元测试          ✓/✗                   ││             │
│        │  └─────────────────────────────────────────────────┘│             │
│        └─────────────────────────────────────────────────────┘             │
│                  │                                                          │
│                  ▼                                                          │
│        验证报告 → 归档或迭代                                                │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘
```

### 生成的验证工件

| 工件 | 目的 | 验证角色 |
|------|------|----------|
| `.feature` (BDD) | 行为场景 | 验收验证 |
| `.test.ts` (TDD) | 单元测试骨架 | 实现验证 |
| `acceptance.md` (ATDD) | 验收测试表 | 业务验证 |
| `contract.json` | 合约定义 | 接口验证 |
| `schema.json` | 模式定义 | 结构验证 |

### SDD 中的 V&V

- **验证** (正确构建): 合约测试通过，模式有效，代码匹配规格
- **确认** (构建正确的事物): AC 已满足，利益相关者批准，业务价值已交付

### 参考资料

- [InfoQ: Spec-Driven Development - Validation Layer](https://www.infoq.com/articles/spec-driven-development/)
- [Microsoft: Consumer-Driven Contract Testing](https://microsoft.github.io/code-with-engineering-playbook/automated-testing/cdc-testing/)
- [维基百科: Formal Verification](https://en.wikipedia.org/wiki/Formal_verification)
- [Specmatic: AI-powered API Contract Testing](https://specmatic.io/)

---

## SDD + 测试集成模型

### 理论基础

SDD 验证基于已建立的测试理论：

```
设计合约 (1986)        示例规格化 (2011)
        │                              │
        ▼                              ▼
┌───────────────────────────────────────────────────────────────┐
│               SDD 验证模型                                    │
│                                                               │
│   规格 (AC)  ←──→  合约测试  ←──→  实现                    │
│       ↑                 ↑                      ↓              │
│   前置/后置          验证机制            运行时            │
│   条件                                        行为           │
└───────────────────────────────────────────────────────────────┘
```

### 集成点

| SDD 阶段 | 测试集成 | 理论 |
|-----------|----------|------|
| **规格编写** | AC = 前置/后置条件 | 设计合约 |
| **正向推导** | 生成合约测试 | 可执行规格 |
| **实施** | TDD (可选) | 测试驱动开发 |
| **验证** | 合约测试 + 漂移检测 | 运行时验证 |
| **归档** | 测试结果作为证据 | 可追溯性 |

### 实用工作流程

```
┌─────────────────────────────────────────────────────────────────────────────┐
│                    实用 SDD 工作流程                                   │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   【输入来源】(任选其一)                                                   │
│   ├── 需求访谈 (最常见)                                                  │
│   ├── 利益相关者邮件/文档                                                 │
│   ├── 产品需求文档 (PRD)                                                   │
│   └── ATDD 工作坊 (可选协作)                                              │
│        ↓                                                                    │
│   【SDD 提案编写】                                                        │
│   SPEC-XXX.md 包括:                                                       │
│   - 摘要、动机                                                            │
│   - 详细设计                                                              │
│   - 验收标准 (Given-When-Then)                                            │
│   - 依赖关系、风险                                                        │
│        ↓                                                                    │
│   【审查与批准】                                                            │
│        ↓                                                                    │
│   【正向推导】                                                              │
│   /derive-all → .feature, .test.ts, acceptance.md, contract.json            │
│        ↓                                                                    │
│   【实施】(TDD 可选)                                                       │
│        ↓                                                                    │
│   【验证】→ 【归档】                                                        │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘
```

### 与传统方法的关键调整

1. **ATDD 工作坊是可选的**: 不是每个功能都需要正式工作坊
2. **规格是起点**: 无论输入来源如何，都转换为 SPEC-XXX.md
3. **Given-When-Then 嵌入**: AC 格式借鉴 BDD，但不需要正式 ATDD 流程
4. **正向推导填补空白**: 自动生成测试结构，弥补缺少工作坊的不足

---

## 与正向/反向工程集成

本标准与两个互补标准协同工作，形成完整的规格生态系统：

```
┌─────────────────────────────────────────────────────────────────────────┐
│                    SDD 生态系统集成                                  │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   遗留代码                    新功能                                 │
│       │                              │                                  │
│       ▼                              ▼                                  │
│   ┌─────────────────┐        ┌─────────────────┐                        │
│   │ 反向             │        │ SDD             │                        │
│   │ 工程             │        │ (本标准)         │                        │
│   │ 标准             │        │                 │                        │
│   └────────┬────────┘        └────────┬────────┘                        │
│            │                          │                                  │
│            │  代码 → 规格             │  规格优先                        │
│            │                          │                                  │
│            ▼                          ▼                                  │
│       ┌─────────────────────────────────────┐                           │
│       │          SPEC-XXX.md                │                           │
│       │    (已批准规格)                   │                           │
│       └──────────────────┬──────────────────┘                           │
│                          │                                               │
│                          ▼                                               │
│   ┌─────────────────────────────────────────────────────┐               │
│   │          正向推导标准                                 │               │
│   │                                                      │               │
│   │   规格 → BDD (.feature)                              │               │
│   │   规格 → TDD (.test.ts)                              │               │
│   │   规格 → ATDD (acceptance.md)                        │               │
│   └─────────────────────────────────────────────────────┘               │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
```

**何时使用每种方法**：

| 场景 | 起点 | 使用的标准 |
|------|------|-----------|
| 新功能开发 | 不存在任何东西 | SDD → 正向推导 |
| 记录现有代码 | 代码存在，无规格 | 反向工程 → SDD |
| 向现有代码添加测试 | 规格存在 | 正向推导 |
| 重大重构 | 代码存在，行为不明确 | 反向工程 → SDD → 正向推导 |

---

## 相关标准

- [反向工程标准](reverse-engineering-standards.md) - 程序码转规格转换
- [测试驱动开发](test-driven-development.md) - TDD 工作流程与 SDD 集成
- [行为驱动开发](../../../core/behavior-driven-development.md) - BDD 工作流程与 Given-When-Then 情境
- [验收测试驱动开发](../../../core/acceptance-test-driven-development.md) - ATDD 工作流程与商业验收
- [测试标准](testing-standards.md) - 测试框架与最佳实践（或使用 `/testing-guide` 技能）
- [测试完整性维度](test-completeness-dimensions.md) - 7 维度测试覆盖
- [Commit 讯息指南](../../../core/commit-message-guide.md) - Commit 讯息规范
- [程序码签入标准](../../../core/checkin-standards.md) - 程序码签入标准
- [程序码审查清单](../../../core/code-review-checklist.md) - 程序码审查清单
- [文件结构标准](../../../core/documentation-structure.md) - 文件结构标准

---

## 版本历史

| 版本 | 日期 | 变更内容 |
|------|------|----------|
| 2.2.0 | 2026-03-30 | 新增：AC YAML Sidecar、I/O 合约章节、假设与待厘清章节、AI Agent 行为章节 |
| 2.1.0 | 2026-01-26 | 新增：变更评估 (SDD 前评估) 章节，包含决策树、双向同步评估章节，包含同步矩阵和检查清单 |
| 2.0.0 | 2026-01-25 | **重大重构**: 新增 SDD 作为独立方法论章节（将 SDD 与 TDD/BDD/ATDD 家族分离）、成熟度级别（Martin Fowler 2025）、常见陷阱、包含理论基础的验证层、SDD + 测试集成模型、/derive-contracts 命令 |
| 1.4.0 | 2026-01-19 | 新增：与正向推导集成章节、推导命令 |
| 1.3.0 | 2026-01-19 | 新增：与反向工程集成章节、相关命令 |
| 1.2.0 | 2026-01-05 | 新增：IEEE 830-1998 和 SWEBOK v4.0 第 1 章（软件需求）至参考资料 |
| 1.1.0 | 2025-12-24 | 新增：工作流程图、规格范本、集成指南、最佳实践、相关标准、授权 |
| 1.0.0 | 2025-12-23 | 初始 SDD 标准定义 |

---

## 参考资料

- [OpenSpec Documentation](https://github.com/openspec)
- [Design Documents Best Practices](https://www.industrialempathy.com/posts/design-docs-at-google/)
- [ADR (Architecture Decision Records)](https://adr.github.io/)
- [IEEE 830-1998 - 软体需求规格](https://standards.ieee.org/ieee/830/1222/) - 需求文件标准
- [SWEBOK v4.0 - 第 1 章：软体需求](https://www.computer.org/education/bodies-of-knowledge/software-engineering) - IEEE Computer Society

### 验证理论

- [Design by Contract - Bertrand Meyer, 1986](https://en.wikipedia.org/wiki/Design_by_contract) - 前置/后置条件理论
- [维基百科: Formal Verification](https://en.wikipedia.org/wiki/Formal_verification) - 形式化验证理论
- [Microsoft: Consumer-Driven Contract Testing](https://microsoft.github.io/code-with-engineering-playbook/automated-testing/cdc-testing/) - 合约测试框架
- [Specmatic: AI-powered API Contract Testing](https://specmatic.io/) - 现代合约测试工具
- [Gojko Adzic: Specification by Example](https://gojko.net/books/specification-by-example/) - 可执行规格 (2011)

---

## 授权

本标准以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授权发布。
