⚡

规范驱动开发工具包 speckit

规范驱动开发工具包是一个 AI 驱动的软件开发工具，基于规范驱动开发（SDD）方法论。它能够将自然语言描述转化为可执行的规格文档、详细的实现计划和有序的任务列表，支持特征规划、产品需求文档（PRD）创建和敏捷开发流程。主要功能包括规格生成、计划制定和任务管理，适用于提高软件开发效率。关键词：规范驱动开发、可执行规格、AI 生成、软件开发工具、任务自动化、架构设计、SDD、需求分析、项目管理。

架构设计 0 次安装 0 次浏览 更新于 3/7/2026

name: speckit description: 规范驱动开发 (SDD) 工具包。将想法转化为可执行规格、实现计划和任务列表。用于特征规划、PRD 创建，或当用户调用 /speckit.specify, /speckit.plan, /speckit.tasks 命令时。 license: MIT

规范驱动开发工具包：规范驱动开发

概述

规范驱动开发工具包实现 规范驱动开发 (SDD) —— 一种规格驱动代码的方法论，而不是相反。规格不是代码的文档，而是代码成为规格的表达。

权力反转

传统开发：代码是真理，规格是脚手架 SDD：规格是真理，代码是生成的输出

这通过 AI 使规格可执行，消除了意图和实现之间的差距。

命令

/speckit.specify <特征描述>

从自然语言描述创建综合特征规格。

用法： /speckit.specify 具有消息历史和在线状态的实时聊天

输出：

  • specs/{特征名称}/spec.md - 完整特征规格
  • specs/{特征名称}/checklists/requirements.md - 质量验证检查清单

过程：

  1. 解析用户描述，提取关键概念（角色、动作、数据、约束）
  2. 生成用户场景，带优先故事（P1, P2, P3）
  3. 定义功能需求（FR-001, FR-002 等）
  4. 创建可衡量的成功标准
  5. 识别关键实体
  6. 根据质量检查清单验证
  7. 如果存在关键歧义，提出澄清问题（最多 3 个）

指南：

  • 关注用户需要什么和为什么
  • 避免如何（无技术栈、API、代码结构）
  • 使用行业标准做出明智猜测
  • 限制 [需要澄清] 标记到最多 3 个
  • 每个需求必须可测试

详细模板：读取 references/spec-template.md 命令详情：读取 references/commands/specify.md

/speckit.plan [技术上下文]

从现有规格创建实现计划。

用法： /speckit.plan WebSocket, PostgreSQL, Redis 或 /speckit.plan（将从上下文确定技术）

先决条件： spec.md 必须在特征目录中存在

输出：

  • specs/{特征}/plan.md - 带技术决策的实现计划
  • specs/{特征}/research.md - 技术研究和决策
  • specs/{特征}/data-model.md - 实体定义
  • specs/{特征}/contracts/ - API 规范（OpenAPI/GraphQL）
  • specs/{特征}/quickstart.md - 验证场景

过程：

  1. 加载特征规格和项目章程
  2. 填充技术上下文部分
  3. 运行章程检查（评估架构门限）
  4. 阶段 0：研究未知，生成 research.md
  5. 阶段 1：设计数据模型，生成合同
  6. 设计后重新评估章程合规性

章程门限（如果使用章程）：

  • 简单性门限：使用 ≤3 个项目？无未来证明？
  • 反抽象门限：直接使用框架？
  • 集成优先门限：合同定义了吗？

详细模板：读取 references/plan-template.md 命令详情：读取 references/commands/plan.md

/speckit.tasks

从实现计划生成可执行任务列表。

用法： /speckit.tasks

先决条件： plan.md 和 spec.md 必须存在

输出：

  • specs/{特征}/tasks.md - 依赖顺序的任务列表

过程：

  1. 加载 plan.md（技术栈、结构）和 spec.md（用户故事）
  2. 可选加载：data-model.md、contracts/、research.md
  3. 按用户故事组织生成任务：
    • 阶段 1：设置（共享基础设施）
    • 阶段 2：基础（阻塞先决条件）
    • 阶段 3+：按优先顺序的用户故事（P1, P2, P3…）
    • 最后阶段：完善和跨领域
  4. 用 [P] 标记可并行任务
  5. 编号任务（T001, T002…）
  6. 生成依赖图和并行执行示例

任务格式： [ID] [P?] [Story] 描述

  • [P] = 可并行运行（不同文件，无依赖）
  • [Story] = 哪个用户故事（US1, US2, US3）

详细模板：读取 references/tasks-template.md 命令详情：读取 references/commands/tasks.md

工作流示例

# 1. 创建规格（5 分钟）
/speckit.specify 具有消息历史和用户在线状态的实时聊天

# 2. 生成实现计划（5 分钟）
/speckit.plan WebSocket 用于消息传递，PostgreSQL 用于历史，Redis 用于在线状态

# 3. 创建任务列表（5 分钟）
/speckit.tasks

结果（在 15 分钟内）：

  • 完整特征规格，带用户故事和接受标准
  • 详细实现计划，带技术原理
  • API 合同和数据模型
  • 可执行任务列表，按用户故事组织

项目章程

章程定义了项目的不可变架构原则。当存在 memory/constitution.md 时，/speckit.plan 命令将：

  1. 规划前验证章程门限
  2. 要求对任何违反进行理由说明
  3. 跟踪复杂性偏差

样本原则：

  • 库优先：特征作为独立库开始
  • 测试优先：TDD 强制（红-绿-重构）
  • 简单性：最多 3 个项目，YAGNI
  • 集成优先：真实数据库而非模拟

章程模板：读取 references/constitution-template.md

关键概念

用户故事组织

任务按用户故事分组以启用：

  • 独立实现
  • 独立测试
  • 增量交付（先交付 P1，然后 P2，然后 P3）

MVP 优先交付

  1. 完成设置 + 基础阶段
  2. 实现用户故事 1（P1） → 测试 → 部署
  3. 添加用户故事 2（P2） → 测试 → 部署
  4. 继续增量

模板驱动质量

模板约束 AI 行为以获得更好结果：

  • 防止过早实现细节
  • 强制显式不确定性标记
  • 强制测试优先思考
  • 防止推测性特征

文件位置

在项目中工作时：

  • 规格： specs/{特征名称}/
  • 章程： memory/constitution.md

参考文件

  • references/spec-template.md - 特征规格模板
  • references/plan-template.md - 实现计划模板
  • references/tasks-template.md - 任务列表模板
  • references/constitution-template.md - 项目章程模板
  • references/methodology.md - 完整 SDD 哲学文档
  • references/commands/ - 详细命令定义