⚡

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

规范驱动开发（SDD）是一种基于GitHub SpecKit的结构化AI辅助软件开发方法论。它通过7个阶段（宪章、规范、澄清、规划、分析、任务分解、实施）将书面规范转化为可执行代码，强调宪章治理、分阶段工作流和多智能体协调。核心关键词包括：AI辅助开发、规范驱动、多智能体协调、结构化开发、GitHub SpecKit、分阶段工作流、宪章治理、并行执行、软件工程方法论。

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

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

规范驱动开发（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）的开源工具包，用于规范驱动开发。