universal-dev-standards 5.17.0 → 6.1.0

package/bundled/locales/zh-CN/methodologies/guides/sdd-guide.md

@@ -0,0 +1,836 @@
+---
+source: ../../../../methodologies/guides/sdd-guide.md
+source_version: 2.1.0
+translation_version: 2.1.0
+last_synced: 2026-06-10
+source_hash: 972eba45ce66
+status: current
+---
+
+# 规格驱动开发 (SDD) 标准
+
+**版本**: 2.1.0
+**最后更新**: 2026-01-26
+**适用范围**: 所有采用规格驱动开发的项目
+**范围**: universal
+
+> **语言**: [English](../../../../methodologies/guides/sdd-guide.md) | [简体中文](../../methodologies/guides/sdd-guide.md)
+
+---
+
+## 目的
+
+本标准定义规格驱动开发 (SDD) 的原则与工作流程，确保变更在实现前已经过规划、记录并通过规格审批。
+
+**主要效益**:
+- 减少利益相关方与开发者之间的沟通误解
+- 为所有变更提供清晰的审计轨迹
+- 新成员更容易上手
+
+---
+
+## SDD 作为独立方法论
+
+SDD（规格驱动开发，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：规格即来源**
+- 规格是唯一的真实来源
+- 代码标注 "GENERATED - DO NOT EDIT"
+- 任何变更都需先修改规格
+- 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)
+
+---
+
+## 常见陷阱
+
+采用 SDD 时应避免以下常见陷阱：
+
+| 陷阱 | 问题 | 缓解措施 |
+|------|------|---------|
+| **过度形式化** | 像瀑布开发一样拖慢反馈速度 | 保持迭代，使用短周期 |
+| **规格漂移** | 规格与代码不同步 | 持续验证，在 CI/CD 中做漂移检测 |
+| **AI 幻觉** | AI 生成的代码与规格不符 | 健壮的验证、契约测试 |
+| **尺寸不符** | 对小 bug 使用重量级流程 | 根据复杂度选择合适流程 |
+| **过早优化** | 跳跃至规格即来源（等级 3） | 从规格优先开始，逐步演进 |
+
+### 何时不使用完整 SDD
+
+| 情境 | 建议 |
+|------|------|
+| 关键热修复 | 先修复，后补文档 |
+| 错字与格式 | 直接 commit，不需规格 |
+| 探索性原型 | 跳过正式规格，快速迭代 |
+| 琐碎 bug 修复（错字级别、无共用代码） | 仅轻量跟踪 |
+| 易回归 bug 修复（共用代码 / 迁移 / 曾破坏路径） | 使用下方的 Bugfix 规格模板 |
+
+---
+
+## 变更评估（SDD 前置评估）
+
+开始 SDD 工作流程前，先评估变更的性质与范围。这能防止过度工程化，确保变更被正确路由。
+
+### 评估决策树
+
+```
+新需求/变更
+    │
+    ▼
+┌─────────────────────────────────────────────────────────┐
+│ Q1: 这个变更的适用范围是什么？                              │
+│     What is the scope of this change?                    │
+├─────────────────────────────────────────────────────────┤
+│ A) 仅限项目内部使用                                        │
+│    → 加入 CLAUDE.md 或项目配置                             │
+│    → 不需要核心标准                                        │
+│                                                          │
+│ B) 可被其他项目复用的规则                                   │
+│    → 创建核心标准                                          │
+│    → 评估是否需要 Skill/Command                            │
+└─────────────────────────────────────────────────────────┘
+    │
+    ▼
+┌─────────────────────────────────────────────────────────┐
+│ Q2: 这个功能需要 AI 交互吗？                               │
+│     Does this feature require AI interaction?            │
+├─────────────────────────────────────────────────────────┤
+│ A) 需要交互式工作流程                                      │
+│    → 创建 Skill                                          │
+│    → 评估是否需要 Slash Command                            │
+│                                                          │
+│ B) 静态规则 / 背景知识                                     │
+│    → 仅建核心标准                                          │
+│    → 在 CLAUDE.md 中引用                                  │
+└─────────────────────────────────────────────────────────┘
+    │
+    ▼
+┌─────────────────────────────────────────────────────────┐
+│ Q3: 用户需要直接触发吗？                                   │
+│     Does the user need to trigger this directly?         │
+├─────────────────────────────────────────────────────────┤
+│ A) 需要 /command 触发                                     │
+│    → 创建 Slash Command                                  │
+│                                                          │
+│ B) AI 自动应用                                            │
+│    → 仅建 Skill，不需要 Command                            │
+└─────────────────────────────────────────────────────────┘
+```
+
+### 评估结果
+
+| 评估结果 | 需创建的产出物 |
+|---------|-------------|
+| 仅限项目 | 仅更新 CLAUDE.md |
+| 通用静态规则 | 核心标准 + CLAUDE.md 引用 |
+| 通用交互式 | 核心标准 + Skill |
+| 用户触发工作流程 | 核心标准 + Skill + Command |
+
+### 范围分类标签
+
+在规格文档中使用以下标签标示范围：
+
+| 标签 | 含义 | 示例 |
+|------|------|------|
+| `[Scope: Project]` | 项目专用，不对外发布 | CI/CD 配置、团队惯例 |
+| `[Scope: Universal]` | 可被其他项目复用 | 编码标准、测试模式 |
+| `[Scope: Utility]` | 工具/生成器，不需核心标准 | docs-generator、code-formatter |
+
+---
+
+## Bugfix 规格模板（易回归修复）
+
+> XSPEC-264。不是每个 bug 都需要规格——**琐碎** bug 保持轻量即可。但**易回归**的修复
+>（触及共用代码、迁移或曾被修复又破坏的路径）值得一份轻量的
+> `<BUG-ID>.bugfix.md`——比功能规格便宜得多，比盲目修补安全得多。
+
+```markdown
+# <BUG-ID>: <简短标题>
+
+## Current behavior（当前行为）
+现在发生的事（缺陷） + 重现步骤。
+
+## Expected behavior（预期行为）
+应该发生的事。
+
+## Unchanged behavior（不变行为）
+明确列出**不应改变**的内容——回归防护范围。
+
+## Root cause（根本原因）
+链接系统性调试分析（5 个为什么 / 二分法）。
+
+## Regression test（回归测试）
+修复前失败、修复后通过的测试——并且断言"不变行为"仍然成立。
+将此测试视为 AC（acceptance-criteria-traceability: `@AC <BUG-ID>`）。
+```
+
+**使用时机**（参见上方变更评估表）：琐碎 → 轻量；易回归 → 使用此模板。`Unchanged behavior`（不变行为）+ `Regression test`（回归测试）两节，正是 UDS 自身的迁移/重构回归（XSPEC-199/200/201）屡屡缺少的。设计上保持轻量；不要把琐碎 bug 升级。
+
+---
+
+## SDD 工作流程
+
+```
+┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
+│     讨论     │───▶│     提案     │───▶│     审查     │───▶│     实现     │
+└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
+                                                                   │
+                                                                   ▼
+                                        ┌──────────────┐    ┌──────────────┐
+                                        │     归档     │◀───│     验证     │
+                                        └──────────────┘    └──────────────┘
+```
+
+### 工作流程阶段
+
+| 阶段 | 说明 | 产出物 |
+|------|------|--------|
+| **讨论** | 厘清灰色地带、锁定范围、建立 read_first 清单 | 范围定义、规范参考 |
+| **提案** | 定义变更内容与原因 | `proposal.md` |
+| **审查** | 利益相关方审批 | 审查意见、审批记录 |
+| **实现** | 执行已审批的规格 | 代码、测试、文档 |
+| **验证** | 确认实现符合规格（最多 3 次迭代） | 测试结果、追溯矩阵 |
+| **归档** | 关闭并归档规格 | 已归档规格及 commits/PRs 链接 |
+
+---
+
+## 双向同步评估
+
+处理规格及其实现时，始终评估哪些内容需要同步。变更可能来自任何产出物，并应传播至相关产出物。
+
+### 同步矩阵
+
+| 变更来源 | 需评估同步至 |
+|---------|------------|
+| 核心标准 | → Skills、Commands、AI YAML、翻译 |
+| Skill | → 核心标准（如适用）、Commands、翻译 |
+| Command | → Skill、核心标准（如适用）、翻译 |
+
+### 同步检查清单模板
+
+在规格文档中加入此检查清单：
+
+```markdown
+## Sync Checklist（同步检查清单）
+
+### 从核心标准出发
+- [ ] 创建/更新对应的 Skill？（若需交互）
+- [ ] 创建/更新 Slash Command？（若需用户触发）
+- [ ] 更新翻译？（zh-TW、zh-CN 等）
+- [ ] 更新 AI YAML 版本？（如适用）
+
+### 从 Skill 出发
+- [ ] 此 Skill 应有核心标准吗？
+- [ ] 若为工具 Skill（如 docs-generator），标记为 "[Scope: Utility]"？
+- [ ] 创建 Slash Command？
+- [ ] 更新翻译？
+
+### 从 Command 出发
+- [ ] 此 Command 属于哪个 Skill？
+- [ ] 更新 Skill 文档？
+- [ ] 更新翻译？
+```
+
+### 同步标记
+
+在文档中使用以下标记表示同步状态：
+
+| 标记 | 含义 |
+|------|------|
+| `[Synced: ✓]` | 所有相关产出物已同步 |
+| `[Synced: Pending]` | 需要同步但尚未完成 |
+| `[Synced: N/A]` | 没有需要同步的相关产出物（如独立工具） |
+
+---
+
+## 核心原则
+
+### 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
+- ✅ 完成后归档规格
+
+### 不应该做的
+
+- ❌ 在规格审批前开始编码
+- ❌ 实现期间修改范围而不更新规格
+- ❌ 让规格处于悬而未决状态（始终关闭或归档）
+- ❌ 跳过验证步骤
+
+---
+
+## 与逆向工程集成
+
+### 概述
+
+对于没有规格的现有代码库，使用[逆向工程标准](../../core/reverse-engineering-standards.md)来生成与 SDD 兼容的提案草稿。
+
+### 逆向工程 → SDD 流水线
+
+```
+┌─────────────────────────────────────────────────────────────────────────┐
+│                    逆向工程 → SDD 流水线                                  │
+├─────────────────────────────────────────────────────────────────────────┤
+│                                                                         │
+│   现有代码                                                               │
+│        │                                                                │
+│        ▼                                                                │
+│   ┌────────────────────────────────────────────────────────────┐       │
+│   │ /reverse-spec                                               │       │
+│   │   • 代码扫描 → 技术清单 [已确认]                              │       │
+│   │   • 测试分析 → 验收条件 [已确认/推断]                          │       │
+│   │   • 缺口识别 → [未知] 项目                                   │       │
+│   └────────────────────────────────────────────────────────────┘       │
+│        │                                                                │
+│        ▼                                                                │
+│   草拟规格（逆向工程）                                                    │
+│        │                                                                │
+│        ▼                                                                │
+│   ┌────────────────────────────────────────────────────────────┐       │
+│   │ SDD 审查流程                                                 │       │
+│   │   • 人类填写 [未知] 区块（动机、风险）                          │       │
+│   │   • 利益相关方验证 [推断] 项目                                 │       │
+│   │   • 正式审批                                                 │       │
+│   └────────────────────────────────────────────────────────────┘       │
+│        │                                                                │
+│        ▼                                                                │
+│   已审批规格 → 继续正常 SDD 工作流程                                      │
+│                                                                         │
+└─────────────────────────────────────────────────────────────────────────┘
+```
+
+### 逆向工程规格的要求
+
+当规格通过逆向工程生成时：
+
+1. **标记状态**: 在元数据中包含 `Status: Draft (Reverse-Engineered)`
+2. **填写未知**: 所有 `[Unknown]` 区块必须由人类在审批前填写
+3. **验证推断**: 所有 `[Inferred]` 项目必须经过审查和确认
+4. **标准审查**: 在实现前遵循正常 SDD 审查流程
+5. **来源引用**: 维护 file:line 参考以确保可追溯性
+
+### 何时使用逆向工程
+
+| 情境 | 做法 |
+|------|------|
+| 遗留系统现代化 | 从逆向工程开始 |
+| 记录未文档化的代码 | 从代码生成规格 |
+| 新成员入职 | 提取规格进行知识转移 |
+| 重构前的文档化 | 在重大变更前建立规格 |
+
+### 相关命令
+
+| 命令 | 用途 |
+|------|------|
+| `/reverse-spec` | 从现有代码生成 SDD 规格 |
+| `/reverse-bdd` | 将验收条件转换为 Gherkin 场景 |
+| `/reverse-tdd` | 分析 BDD 场景的测试覆盖 |
+
+---
+
+## 与正向推导集成
+
+### 概述
+
+规格审批后，使用[正向推导标准](../../core/forward-derivation-standards.md)从验收条件自动生成 BDD 场景、TDD 测试骨架和 ATDD 验收测试。
+
+### 正向推导 → SDD 流水线
+
+```
+┌─────────────────────────────────────────────────────────────────────────┐
+│                  已审批规格 → 正向推导流水线                              │
+├─────────────────────────────────────────────────────────────────────────┤
+│                                                                         │
+│   APPROVED 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 |
+| **Schema 验证** | 拒绝违反结构要求的 payload | JSON Schema、OpenAPI 验证器 |
+| **漂移检测** | 检测规格与行为的偏离 | CI/CD 集成、Specmatic |
+| **向后兼容性** | 将变更分类为新增/破坏性 | OpenAPI diff 工具 |
+
+### SDD 验证流程
+
+```
+┌─────────────────────────────────────────────────────────────────────────────┐
+│                         SDD 验证层                                            │
+├─────────────────────────────────────────────────────────────────────────────┤
+│                                                                             │
+│   SPEC-XXX.md（已审批）                                                     │
+│        │                                                                    │
+│        ├──→ 正向推导                                                        │
+│        │         │                                                          │
+│        │         ├──→ 契约测试（已生成）                                     │
+│        │         ├──→ Schema 验证器（已生成）                               │
+│        │         ├──→ BDD 场景（已生成）                                    │
+│        │         └──→ TDD 骨架（已生成）                                    │
+│        │                                                                    │
+│        └──→ 实现（AI 辅助）                                                 │
+│                  │                                                          │
+│                  ▼                                                          │
+│        ┌─────────────────────────────────────────────────────┐             │
+│        │              持续验证                                │             │
+│        │  ┌─────────────────────────────────────────────────┐│             │
+│        │  │ 契约测试               ✓/✗                      ││             │
+│        │  │ Schema 验证            ✓/✗                      ││             │
+│        │  │ 漂移检测               ✓/✗                      ││             │
+│        │  │ BDD 场景               ✓/✗                      ││             │
+│        │  │ TDD 单元测试           ✓/✗                      ││             │
+│        │  └─────────────────────────────────────────────────┘│             │
+│        └─────────────────────────────────────────────────────┘             │
+│                  │                                                          │
+│                  ▼                                                          │
+│        验证报告 → 归档或迭代                                                │
+│                                                                             │
+└─────────────────────────────────────────────────────────────────────────────┘
+```
+
+### 生成的验证产出物
+
+| 产出物 | 用途 | 验证角色 |
+|--------|------|---------|
+| `.feature`（BDD） | 行为场景 | 验收验证 |
+| `.test.ts`（TDD） | 单元测试骨架 | 实现验证 |
+| `acceptance.md`（ATDD） | 验收测试表格 | 业务验证 |
+| `contract.json` | 契约定义 | 接口验证 |
+| `schema.json` | Schema 定义 | 结构验证 |
+
+### SDD 中的 V&V
+
+- **验证（Verification）**（正确地构建）：契约测试通过、schema 有效、代码符合规格
+- **确认（Validation）**（构建正确的东西）：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/)
+- [Wikipedia: 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 → 正向推导 |
+
+---
+
+## 相关标准
+
+- [正向推导标准](../../core/forward-derivation-standards.md) — 规格转测试转换（规格 → BDD/TDD/ATDD）
+- [逆向工程标准](../../core/reverse-engineering-standards.md) — 代码转规格转换（代码 → 规格）
+- [测试驱动开发](../../core/test-driven-development.md) — TDD 工作流程与 SDD 集成
+- [行为驱动开发](../../core/behavior-driven-development.md) — BDD 工作流程与 Given-When-Then 场景
+- [验收测试驱动开发](../../core/acceptance-test-driven-development.md) — ATDD 工作流程与业务验收
+- [测试标准](../../core/testing-standards.md) — 测试框架与最佳实践（或使用 `/testing-guide` 技能）
+- [测试完整性维度](../../core/test-completeness-dimensions.md) — 8 维度测试覆盖
+- [Commit 消息指南](../../core/commit-message-guide.md) — Commit 消息规范
+- [代码签入标准](../../core/checkin-standards.md) — 代码签入标准
+- [代码审查清单](../../core/code-review-checklist.md) — 代码审查清单
+- [文档结构标准](../../core/documentation-structure.md) — 文档结构标准
+
+---
+
+## 版本历史
+
+| 版本 | 日期 | 变更内容 |
+|------|------|----------|
+| 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 | 新增：与正向推导集成章节、derive 命令 |
+| 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 标准定义 |
+
+---
+
+## 参考资料
+
+### SDD（2025 AI 时代）
+
+- [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)
+- [InfoQ: Spec-Driven Development](https://www.infoq.com/articles/spec-driven-development/)
+
+### 传统需求工程
+
+- [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) — 前后置条件理论
+- [Wikipedia: 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/) 授权发布。