⚡

规范驱动开发Skill spec-driven-development

规范驱动开发（SDD）是一种基于GitHub SpecKit的结构化AI辅助软件开发方法论。它通过宪法治理、七阶段工作流（从初始化到实施）和多智能体协调，将书面规范直接转化为可执行代码。核心是确保开发质量、团队协作效率，并支持复杂项目的并行执行与治理。关键词：AI辅助开发、规范驱动、宪法治理、多智能体协调、分阶段工作流、软件开发方法论、GitHub SpecKit、质量门、并行执行、结构化开发。

架构设计 2 次安装 70 次浏览 更新于 2/28/2026

name: spec-driven-development description: 基于GitHub SpecKit的规范驱动开发（SDD）方法论。用于结构化AI辅助开发，包含宪法治理、分阶段工作流和多智能体协调。实现从宪法到实施的7阶段流程。 author: Joseph OBrien status: unpublished updated: ‘2025-12-23’ version: 1.0.1 tag: skill type: skill

规范驱动开发（SDD）

本技能实现了GitHub的SpecKit方法论，用于结构化、AI辅助的软件开发。SpecKit通过系统化的、基于阶段的方法，将规范转化为可执行工件，内置质量门和多智能体协调。

核心理念

“规范变为可执行，直接生成工作实现，而不仅仅是指导它们。”

何时使用此技能

  • 启动需要结构化开发的新项目
  • 在复杂功能上协调多个AI智能体或开发者
  • 通过宪法治理确保一致的质量
  • 将复杂功能分解为可管理的、并行的工作
  • 在明确规范之前防止过早实施
  • 具有严格治理要求的企业项目
  • 需要跨多个功能实时可见性的团队

7阶段工作流

阶段0：项目初始化

目的： 创建项目结构并配置开发环境

工件：

  • .specify/ 目录结构
  • Git仓库
  • 自动化脚本
  • 模板

关键操作：

  • 设置目录结构
  • 初始化版本控制
  • 配置AI智能体偏好
  • 生成脚本变体（bash/powershell）

阶段1：宪法

目的： 建立项目治理和开发原则

工件： memory/constitution.md

核心原则：

  1. 库优先原则： 每个功能都作为独立的库开始
  2. CLI接口强制要求： 所有库必须具有基于文本的接口
  3. 测试优先要求： 测试必须先于实现
  4. 简单性和反抽象： 最小化复杂性
  5. 集成优先测试： 优先考虑真实的测试环境

版本控制： 语义化版本控制（主版本.次版本.修订号）

  • 主版本：向后不兼容的治理变更
  • 次版本：新原则或实质性扩展
  • 修订号：小的澄清或改进

编排： 交互式原则定义，对所有工件进行验证

阶段2：规范

目的： 创建详细的功能规范，专注于“是什么”和“为什么”，而不是“如何做”

工件： specs/[功能]/spec.md

必需部分：

  • 功能分支名称（2-4个单词）
  • 用户场景（P1、P2、P3优先级排序）
  • 验收场景（Given/When/Then格式）
  • 边界情况
  • 功能需求（FR-XXX）
  • 关键实体
  • 成功标准（可衡量、与技术无关）

关键约束：

  • 关注业务价值，而非实现
  • 为利益相关者编写，而非开发者
  • 最多3个澄清标记用于关键未知项
  • 每个用户故事必须可独立测试

质量门：

  • 内容质量验证
  • 需求完整性检查
  • 功能就绪度评估
  • 成功标准可衡量性

阶段3：澄清

目的： 系统性地识别和解决规范中的模糊之处

工件： 更新 specs/[功能]/spec.md

澄清维度：

  • 功能范围
  • 数据模型
  • 用户体验（UX）
  • 非功能属性（性能、安全性等）
  • 集成点

关键约束：

  • 每次会话最多5个问题
  • 多项选择或简答格式
  • 关注高影响、实施关键的不确定性
  • 一次一个问题，进行迭代改进

编排： 交互式提问工作流，每次回答后增量更新规范

阶段4：规划

目的： 创建技术实施策略并解决技术未知项

子阶段：

阶段0 - 研究：

  • 识别和研究技术未知项
  • 输出：research.md，所有不确定性已解决
  • 门： 未解决的澄清项导致ERROR

阶段1 - 设计：

  • 创建数据模型和API契约
  • 输出：data-model.md、契约模式、智能体特定上下文

工件：

  • specs/[功能]/plan.md
  • specs/[功能]/research.md
  • specs/[功能]/data-model.md
  • specs/[功能]/contracts/

计划部分：

  • 功能摘要
  • 技术上下文（语言、依赖项、平台）
  • 项目结构
  • 仓库布局
  • 非标准方法的复杂性跟踪

阶段5：分析

目的： 在实施前验证跨工件的一致性

分析的工件：

  • specs/[功能]/spec.md
  • specs/[功能]/plan.md
  • specs/[功能]/tasks.md

检测过程：

  1. 重复项
  2. 模糊性
  3. 未充分指定的项
  4. 宪法冲突

输出： 分析报告，包含按严重性排序的发现（最多50个高信号问题）

关键约束：

  • 只读操作（无法修改文件）
  • 必须在任务分解后运行
  • 优先考虑宪法原则

阶段6：任务分解

目的： 从计划生成可操作的、依赖关系排序的任务列表

工件： specs/[功能]/tasks.md

任务结构：

  • 用于完成跟踪的复选框
  • 顺序任务ID
  • 可选并行化标记（||）
  • 故事标签（适用时标注P1、P2、P3）
  • 精确的文件路径
  • 清晰的描述

阶段结构：

  1. 阶段1： 项目设置
  2. 阶段2： 基础先决条件（阻塞性 - 必须在用户故事之前完成）
  3. 阶段3+： 用户故事实施（优先级顺序：P1 → P2 → P3）
  4. 最终阶段： 优化和跨领域关注点

关键原则：

  • 任务按用户故事分组，以便独立实施
  • 每个故事可独立测试和交付
  • 清晰的依赖关系跟踪
  • 明确的并行化标记
  • 基础阶段完成前不开始用户故事工作

阶段7：实施

目的： 分阶段执行实施，内置验证

8阶段流程：

  1. 先决条件检查： 验证项目就绪度
  2. 清单验证： 计算已完成/未完成项，如果未完成则要求确认
  3. 上下文分析： 读取必需的工件（tasks.md、plan.md）和可选的工件
  4. 项目设置： 为检测到的技术创建/验证忽略文件
  5. 任务处理： 解析任务，提取阶段、依赖关系、执行流程
  6. 分阶段实施： 遵循TDD分阶段执行任务
  7. 错误处理： 报告进度，处理失败，提供调试上下文
  8. 最终验证： 确认完成，验证实施，检查测试覆盖率

编排： 系统化的多阶段执行，内置检查和平衡

编排与并行执行

核心编排理念

顺序阶段推进，在依赖关系允许的情况下，阶段内并行执行。

协调机制

1. 基于阶段的门

  • 每个阶段必须完成并验证后才能开始下一阶段
  • 门在错误或未解决的问题上阻塞
  • 实施：模板验证、清单要求、宪法一致性检查

2. 依赖关系跟踪

  • 任务标记有必须在执行前解决的依赖关系
  • 基础阶段阻塞所有用户故事工作
  • 任务明确引用先决条件

3. 并行化标记

  • 当不存在依赖关系时，任务明确标记为并行执行
  • 任务格式中的可选 || 标记
  • 表示任务可以并发运行

4. 用户故事分组

  • 任务按用户故事分组，以便独立、并行实施
  • 每个用户故事可独立测试和交付
  • 允许多个智能体/开发者同时工作

5. 宪法一致性

  • 所有阶段都引用宪法以保持一致的实践
  • 在所有命令中加载和验证宪法
  • 确保并行工作流之间的一致性

并行执行模式

模式1：用户故事并行化

基础阶段完成后，用户故事（P1、P2、P3）可以由不同的智能体并行实施

好处：

  • 独立可测试性
  • 增量交付
  • 减少阻塞
  • 可扩展的团队协调

示例：

基础：✓ 项目设置、数据库模式、认证框架

并行工作：
├─ 智能体1：P1故事 - 用户注册流程
├─ 智能体2：P1故事 - 用户登录流程
└─ 智能体3：P2故事 - 个人资料管理

模式2：任务级并行化

在一个阶段内，没有依赖关系的任务可以并发执行

示例：

阶段3：P1 用户注册
├─ [ ] T3.1 || 创建用户模型（tests/models/test_user.py）
├─ [ ] T3.2 || 创建注册端点（tests/api/test_register.py）
└─ [ ] T3.3 || 创建验证服务（tests/services/test_validation.py）

模式3：多智能体协调

不同的AI智能体可以使用共享的工件格式处理不同的方面

示例：

功能“用户认证”：
├─ Claude：生成 spec.md 和 plan.md（推理优势）
├─ Copilot：实施认证端点（代码生成）
└─ Gemini：编写集成测试（测试覆盖）

同步点

并行工作必须同步的关键点：

  1. 宪法之后： 所有后续工作必须与原则保持一致
  2. 规范之后： 澄清必须在规划前解决
  3. 规划研究之后： 所有未知项必须在设计前解决
  4. 任务之后： 分析必须在实施前验证
  5. 基础任务之后： 用户故事工作可以开始
  6. 实施过程中： 清单验证会阻塞执行

智能体协调模式

模式1：模板驱动的交接

结构化的Markdown模板确保不同AI智能体之间一致的工件格式

好处： 智能体互操作性、一致的文档、减少模糊性

模式2：宪法一致性

宪法作为所有智能体和阶段之间的共享上下文

好处： 一致的质量标准、可预测的行为、跨团队/智能体的一致性

模式3：分阶段推进

线性阶段推进，在智能体之间有明确的交接点

好处： 明确的职责、减少混淆、质量门

模式4：增量改进

在阶段内进行迭代改进，然后再向前推进

好处： 更高质量的工件、减少返工、早期错误检测

模式5：工件驱动的上下文

上下文通过工件引用传递，而非对话

好处： 无状态执行、上下文恢复、长期运行的项目

目录结构

.specify/
├── memory/
│   └── constitution.md          # 项目治理和原则
├── scripts/
│   ├── *.sh                     # Bash自动化脚本
│   └── *.ps1                    # PowerShell自动化脚本
├── specs/
│   └── [功能名称]/
│       ├── spec.md              # 功能规范
│       ├── plan.md              # 技术实施计划
│       ├── tasks.md             # 可操作的任务分解
│       ├── research.md          # 研究发现（可选）
│       ├── data-model.md        # 数据结构设计（可选）
│       ├── quickstart.md        # 快速入门（可选）
│       └── contracts/           # API/接口定义（可选）
└── templates/                   # 命令和工件模板

最佳实践

  1. 尽早建立宪法 以指导所有后续决策
  2. 使用澄清命令 在规划前解决模糊性
  3. 在实施前运行分析命令 以尽早发现问题
  4. 构建用户故事 以实现独立可测试性
  5. 用 || 明确标记可并行任务
  6. 完全完成基础阶段 后再开始用户故事工作
  7. 在所有阶段保持宪法一致性
  8. 在规范中使用具体、可衡量的成功标准
  9. 在规范阶段避免实施细节
  10. 利用多个AI智能体 发挥不同优势

需要避免的陷阱

  1. 跳过澄清阶段会导致模糊的规范
  2. 规范中过早的实施细节会降低灵活性
  3. 忽略宪法会导致不一致的实践
  4. 没有适当依赖关系跟踪的并行工作会导致冲突
  5. 不完整的基础阶段会阻塞所有用户故事工作
  6. 实施前不运行分析会浪费精力在错误的计划上
  7. 早期阶段过度规范会限制AI智能体的创造力
  8. 不充分的成功标准会使验证变得主观
  9. 不使用用户故事分组会限制并行化潜力

实施场景

场景1：启动新项目

使用完整的7阶段工作流和宪法治理。专注于尽早建立原则。

场景2：拥有多个开发者/智能体的团队

强调用户故事并行化和工作树隔离。使用仪表板实现实时可见性。

场景3：具有治理要求的企业

包含企业约束的全面宪法。强制要求在实施前进行分析阶段。

场景4：快速原型制作

详细的规范以对齐愿景，但规划较轻。小的用户故事以快速验证。

参考文献

基于GitHub SpecKit（spec-kit）方法论 - 一个用于规范驱动开发的开源工具包，支持15+个AI编码智能体，包括Claude Code、GitHub Copilot、Gemini和Cursor。