Spec-Driven Development (SDD) 是一套基于 GitHub SpecKit 方法论的结构化、AI 辅助软件开发技能。SpecKit 通过系统化、分阶段的方法，将规格说明转化为可执行产物，并内置质量门禁与多智能体协作机制。
核心哲学
“规格说明变为可执行，直接生成可工作的实现，而不仅仅是指导实现。”
何时使用本技能
- 启动需要结构化开发的新项目
- 在复杂功能上协调多个 AI 智能体或开发者
- 通过宪法式治理确保一致的质量
- 将复杂功能拆解为可管理、可并行的工作
- 防止在规格明确前过早实现
- 有严格治理要求的企业项目
- 需要跨多个功能实时可见性的团队
7 阶段工作流
阶段 0：项目初始化 目的：创建项目结构并配置开发环境。 产物：.specify/ 目录结构、Git 仓库、自动化脚本、模板。 关键操作：设置目录结构、初始化版本控制、配置 AI 智能体偏好、生成脚本变体（bash/powershell）。
阶段 1：宪法 目的：建立项目治理与开发原则。 产物：memory/constitution.md。 核心原则：库优先原则（每个功能从独立库开始）、CLI 接口强制（所有库必须有基于文本的接口）、测试优先（测试必须先于实现）、简洁与反抽象（最小化复杂度）、集成优先测试（优先真实测试环境）。 版本管理：语义化版本（MAJOR.MINOR.PATCH）。MAJOR：向后不兼容的治理变更；MINOR：新增原则或实质性扩展；PATCH：细微澄清或改进。 编排：交互式原则定义，并在所有产物间进行验证。
阶段 2：规格说明 目的：创建详细的功能规格，聚焦 WHAT 和 WHY，而非 HOW。 产物：specs/[feature]/spec.md。 必需章节：功能分支名（2-4 个词）、用户场景（P1、P2、P3 优先级）、验收场景（Given/When/Then 格式）、边界情况、功能需求（FR-XXX）、关键实体、成功标准（可度量、技术无关）。 关键约束：聚焦业务价值而非实现；为利益相关者而非开发者编写；关键未知项最多 3 个澄清标记；每个用户故事必须可独立测试。 质量门禁：内容质量验证、需求完整性检查、功能就绪评估、成功标准可度量性。
阶段 3：澄清 目的：系统性地识别并解决规格中的歧义。 产物：更新 specs/[feature]/spec.md。 澄清维度：功能范围、数据模型、用户体验（UX）、非功能属性（性能、安全等）、集成点。 关键约束：每次会话最多 5 个问题；多选或简答格式；聚焦高影响、实现关键的不确定性；一次一个问题以迭代细化。 编排：交互式提问工作流，每次回答后增量更新规格。
阶段 4：规划 目的：创建技术实现策略并解决技术未知项。 子阶段：
- 阶段 0 - 研究：识别并研究技术未知项。输出：research.md，所有不确定性已解决。门禁：未解决的澄清会报 ERROR。
- 阶段 1 - 设计：创建数据模型和 API 契约。输出：data-model.md、契约模式、智能体特定上下文。 产物：specs/[feature]/plan.md、specs/[feature]/research.md、specs/[feature]/data-model.md、specs/[feature]/contracts/。 计划章节：功能摘要、技术上下文（语言、依赖、平台）、项目结构、仓库布局、非标准方法的复杂度跟踪。
阶段 5：分析 目的：在实现前验证跨产物一致性。 分析的产物：specs/[feature]/spec.md、specs/[feature]/plan.md、specs/[feature]/tasks.md。 检测项：重复、歧义、未充分说明项、宪法冲突。 输出：分析报告，按严重程度排序的发现（最多 50 个高信号问题）。 关键约束：只读操作（不能修改文件）；必须在任务拆解后运行；优先考虑宪法原则。
阶段 6：任务拆解 目的：从计划生成可操作、按依赖排序的任务列表。 产物：specs/[feature]/tasks.md。 任务结构：用于完成跟踪的复选框、顺序任务 ID、可选并行标记（||）、故事标签（适用时 P1、P2、P3）、精确文件路径、清晰描述。 阶段结构：阶段 1：项目设置；阶段 2：基础先决条件（阻塞——必须在用户故事前完成）；阶段 3+：用户故事实现（优先级顺序：P1 → P2 → P3）；最终阶段：打磨与横切关注点。 关键原则：任务按用户故事分组以实现独立实现；每个故事可独立测试和交付；清晰的依赖跟踪；显式并行标记；基础阶段完成前不做任何用户故事工作。
阶段 7：实现 目的：逐阶段执行实现，内置验证。 8 阶段流程：先决条件检查、清单验证、上下文分析、项目设置、任务处理、分阶段实现（遵循 TDD）、错误处理、最终验证。 编排：系统化多阶段执行，内置检查与平衡。
编排与并行执行
核心编排哲学：顺序阶段推进，在依赖允许的范围内阶段内并行执行。
协调机制
- 基于阶段的门禁：每个阶段必须完成并验证后才能进入下一阶段；门禁在错误或未解决问题时阻塞。
- 依赖跟踪：任务标记依赖，必须先解决才能执行；基础阶段阻塞所有用户故事工作。
- 并行标记：无依赖时任务显式标记为并行执行；任务格式中可选 || 标记。
- 用户故事分组：任务按用户故事分组以实现独立、并行实现；每个用户故事可独立测试和交付。
- 宪法一致性：所有阶段引用宪法以保持一致实践。
并行执行模式 模式 1：用户故事并行化。基础阶段完成后，用户故事（P1、P2、P3）可由不同智能体并行实现。 模式 2：任务级并行化。阶段内无依赖的任务可并发执行。 模式 3：多智能体协调。不同 AI 智能体可使用共享产物格式处理不同方面。
同步点
- 宪法之后：所有后续工作必须与原则对齐
- 规格说明之后：澄清必须在规划前解决
- 规划研究之后：所有未知项必须在设计前解决
- 任务之后：分析必须在实现前验证
- 基础任务之后：用户故事工作可以开始
- 实现期间：清单验证阻塞执行
智能体协调模式 模式 1：模板驱动交接 模式 2：宪法对齐 模式 3：分阶段推进 模式 4：增量细化 模式 5：产物驱动上下文
目录结构 .specify/ ├── memory/ │ └── constitution.md # 项目治理与原则 ├── scripts/ │ ├── *.sh # Bash 自动化脚本 │ └── *.ps1 # PowerShell 自动化脚本 ├── specs/ │ └── [feature-name]/ │ ├── spec.md # 功能规格 │ ├── plan.md # 技术实现计划 │ ├── tasks.md # 可操作任务拆解 │ ├── research.md # 研究发现（可选） │ ├── data-model.md # 数据结构设计（可选） │ ├── quickstart.md # 快速开始（可选） │ └── contracts/ # API/接口定义（可选） └── templates/ # 命令与产物模板
最佳实践
- 尽早建立宪法以指导所有后续决策
- 使用 clarify 命令在规划前解决歧义
- 在实现前运行 analyze 命令以尽早发现问题
- 为用户故事结构设计独立可测试性
- 用 || 显式标记可并行任务
- 在用户故事工作前完全完成基础阶段
- 在所有阶段保持宪法对齐
- 在规格中使用具体、可度量的成功标准
- 避免在规格阶段涉及实现细节
- 利用多个 AI 智能体的不同优势
应避免的陷阱
- 跳过澄清阶段导致规格歧义
- 规格中过早的实现细节降低灵活性
- 忽视宪法导致实践不一致
- 无适当依赖跟踪的并行工作导致冲突
- 基础阶段不完整阻塞所有用户故事工作
- 实现前不运行 analyze 会在有缺陷的计划上浪费精力
- 早期阶段过度规格化限制 AI 智能体创造力
- 成功标准不足使验证主观化
- 不使用用户故事分组限制并行化潜力
实现场景 场景 1：启动新项目。使用完整 7 阶段工作流与宪法治理，重点尽早建立原则。 场景 2：多开发者/智能体团队。强调用户故事并行化与工作树隔离，使用仪表板实现实时可见性。 场景 3：有治理要求的企业。全面的宪法与企业约束，强制实现前进行分析阶段。 场景 4：快速原型。详细规格以对齐愿景，但较轻的规划，小用户故事以快速验证。
参考 基于 GitHub SpecKit（spec-kit）方法论——一个支持 15+ AI 编码智能体（包括 Claude Code、GitHub Copilot、Gemini 和 Cursor）的开源 Spec-Driven Development 工具包。