GitHub Spec Kit 详解：规范驱动开发（SDD）工具包
在 AI 编码工具爆发的今天，"一上来就让 AI 写代码"的 vibe coding（氛围编码）虽然爽，却常带来质量不可控、需求漂移、返工不断的隐患。GitHub 给出的答案是 Spec Kit——一个开源的规范驱动开发（Spec-Driven Development，SDD）工具包。它的口号很直接："Build high-quality software faster"，让你专注于产品场景与可预期的结果，而不是每次都从零 vibe coding。本文带你从理念、安装、工作流到定制体系，完整搞懂 Spec Kit。
项目地址：https://github.com/github/spec-kit；官方文档：https://github.github.com/spec-kit/。MIT 许可，受 John Lam 的 SDD 研究影响。
1、Spec Kit 概述
Spec Kit 是一个帮你"上手规范驱动开发"的命令行工具包。它不是一个 IDE，也不是一个模型，而是一套与你现有 AI 编码代理（Copilot、Claude Code、Gemini CLI 等）协作的脚手架：它通过一个叫 `specify` 的 CLI 初始化项目，注入一组 slash 命令（`/speckit.*`）和模板，把"先写规范、再让 AI 实现"这套方法论落地成可执行的流程。
- 开源免费（MIT），GitHub 官方维护，社区活跃
- 兼容 30+ AI 编码代理（CLI 与 IDE 双形态）
- 以"规范"为单一事实源，代码是其衍生产物
- 提供 Extensions / Presets / Bundles 三层定制能力
- 覆盖从 0 到 1 的绿地开发、并行探索、棕地迭代三类场景
2、核心理念：规范为王，代码是衍生物
Spec Kit 背后的 SDD 理念，是翻转传统软件开发"代码为王"的权力结构。过去几十年，代码是真理源泉，规范文档只是搭完就扔的脚手架。SDD 把规范提升为主要工件——specifications become executable（规范变得可执行），它直接生成可工作的实现，而不是仅仅"指导"实现。代码退化为"规范在特定技术栈中的表达"。
这套理念有四个支点：意图驱动（先定义"做什么/为什么"，再谈"怎么做"）；带护栏的富规范（结合组织原则与约束）；多步精炼（而非一次性从提示生成代码）；重度依赖 AI（让强模型去理解与执行规范）。落到工程上，规范成为贯穿始终的"单一事实源"——实现计划、任务、代码都围绕它持续演化。
3、安装与项目初始化
前置条件：Python 3.11+、包管理器 uv（推荐）或 pipx、Git、以及一个受支持的 AI 编码代理。装好 uv 后，用官方 CLI 安装 Specify CLI（把 `vX.Y.Z` 换成 Releases 里的最新 tag）：
// 安装 Specify CLI
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
// 初始化一个新项目并指定 AI 代理集成
specify init my-project --integration copilot
cd my-project
// 也可以在当前目录初始化（--here），或强制合入非空目录（--force）
specify init --here --integration claude
specify init . --force --integration gemini
// 升级：检查/预览/执行
specify self check // 是否有新版本（只读）
specify self upgrade --dry-run // 预览
specify self upgrade // 升级到最新稳定版
初始化时，CLI 会问你用哪个 AI 代理（非交互场景默认 Copilot，可用 `--integration` 显式指定）。它会把 `.specify/` 配置目录、模板、脚本以及对应的 slash 命令文件（如 `.claude/commands/`）注入项目。若本机没装目标代理工具，加 `--ignore-agent-tools` 跳过检测只取模板。
4、核心工作流：七步走
初始化完成后，在你的 AI 编码代理里会看到一组 `/speckit.*` 命令（Codex CLI 的 skills 模式是 `$speckit-*`，Copilot CLI 用 `/agents`）。一条标准的 SDD 流水线是七步：
// STEP 1 立项目原则（产出 .specify/memory/constitution.md）
/speckit.constitution 关注代码质量、测试标准、体验一致性、性能要求
// STEP 2 写规范：只讲 what/why，不讲技术栈（产出 specs/001-xxx/spec.md）
/speckit.specify 做一个按日期分组、可拖拽重排的相册管理应用
// STEP 3 澄清：planning 前推荐先跑，补全模糊需求
/speckit.clarify
// STEP 4 技术计划：这时才定技术栈（产出 plan.md / research.md / data-model.md / contracts/）
/speckit.plan 用 Vite + 原生 HTML/CSS/JS，元数据存本地 SQLite
// STEP 5 任务分解：把计划拆成可执行任务（产出 tasks.md，带依赖与并行标记[P]）
/speckit.tasks
// STEP 6 一致性分析（可选）：tasks 之后、implement 之前，做跨产物一致性检查
/speckit.analyze
// STEP 7 实现：按任务顺序执行，跑通 TDD 流程
/speckit.implement
每一步都会在 `specs/<feature>/` 下沉淀产物（规范、计划、研究、数据模型、API 契约、任务清单），形成一个可追溯的"规范-计划-任务-代码"证据链。一个关键纪律：specify 阶段不要谈技术栈（只讲业务意图），plan 阶段才定技术选型——把"做什么"和"怎么做"分层，避免过早绑定。
5、命令全景
Spec Kit 的命令分核心与可选两类，按需组合：
// 核心命令（SDD 主流程必备）
/speckit.constitution 立项目原则与开发准则
/speckit.specify 定义要构建什么（需求与用户故事）
/speckit.plan 结合技术栈产出实现计划
/speckit.tasks 生成可执行任务清单
/speckit.taskstoissues 把任务清单转成 GitHub issue 跟踪
/speckit.implement 按计划执行全部任务、构建功能
/speckit.converge 对照 spec/plan/tasks 评估代码库，补齐遗漏任务
// 可选命令（增强质量与校验）
/speckit.clarify 澄清规范中模糊处（plan 前推荐，原 /quizme）
/speckit.analyze 跨产物一致性与覆盖分析（tasks 后、implement 前）
/speckit.checklist 生成质量检查清单，号称"给英文写的单元测试"
其中 `/speckit.converge` 值得单独点名：它是棕地项目的"对账"命令——拿现有代码库去对照规范/计划/任务，把尚未完成的差距补成新任务，让规范与实现重新收敛。`/speckit.checklist` 则把"需求是否完整、清晰、一致"做成可勾选的检查项，相当于给需求文档加了"测试"。
6、定制体系：Extensions、Presets、Bundles
Spec Kit 不强求你照搬默认流程，它提供一套"积木式"定制体系，从单点到团队都能调：
// Extensions —— 加新能力（新命令/新阶段），扩展"能做什么"
specify extension search
specify extension add <name> // 如 Jira 集成、实现后代码评审、V-Model 测试追溯
// Presets —— 改现有工作流（覆盖模板与术语），定制"怎么做"
specify preset search
specify preset add <name> // 如合规化规范格式、本地化语言、强制安全评审门
// Bundles —— 角色化打包（一次装齐一组扩展+预设+流程）
specify bundle search
specify bundle install <bundle-id> // 如产品经理、业务分析师、安全研究员、开发
// 模板解析优先级（运行时自上而下取首个匹配）：
// 项目本地覆盖(.specify/templates/overrides/) > Presets > Extensions > Spec Kit 核心
三者的分工很清晰：要"加一个新命令或工作流"用 Extension；要"改规范/计划/任务的格式与术语"用 Preset；要"一键给某个角色（PM、安全、开发）配齐整套"用 Bundle。Bundle 用手写的 `bundle.yml` 描述，把各组件锁定版本打包，支持 `validate` / `build` 本地校验与发布，安装幂等且只作用于项目根目录。
7、AI 编码代理集成
Spec Kit 的定位是"与你现有 AI 编码代理协作"，而非自建代理。它已支持 30+ 主流代理，初始化时用 `--integration` 指定即可：
specify init . --integration copilot // GitHub Copilot
specify init . --integration claude // Claude Code
specify init . --integration gemini // Gemini CLI
specify init . --integration codex // OpenAI Codex
specify init . --integration cursor // Cursor CLI
// 还有 Qwen CLI、opencode、Kiro、Qoder、Tabnine、Goose、Mistral Vibe、ZCode 等
// 查看本机已装版本支持的全部集成
specify integration list
// skills 模式：装成"技能"而非 slash 命令文件（部分代理支持）
specify init . --integration codex --integration-options="--skills"
多数代理以 `/speckit.*` slash 命令暴露能力，Codex 的 skills 模式用 `$speckit-*`，GitHub Copilot CLI 用 `/agents` 选择代理。这意味着你不必换工具——在熟悉的代理里，Spec Kit 把规范、计划、任务的"指挥棒"递到 AI 手里。
8、三种开发阶段与适用场景
Spec Kit 把开发分成三类阶段，流程略有不同：
阶段 焦点 典型活动
-------------------------------------------------------------------
0-to-1 绿地开发 从零生成 高层需求 → 规范 → 计划 → 构建生产级应用
Creative Exploration 并行实现探索 多技术栈/架构方案并行试验，比较 UX
Iterative Enhancement 棕地现代化 增量加功能、改造遗留系统（用 /speckit.converge 对账）
绿地阶段走完整七步；棕地阶段则强调"工具更新与规范演进分离"——升级 Spec Kit 时刷新托管文件，行为变更时更新 `specs/`，并用 `/speckit.converge` 让代码与规范重新对齐。Creative Exploration 则支持你用同一份规范并行跑多套技术方案，比较后择优，特别适合原型与方案选型。
9、总结
GitHub Spec Kit 把"规范驱动开发"从一种理念，变成了一套可上手、可定制、与你现有 AI 代理协作的工程工具。它以规范为单一事实源，通过"原则→规范→澄清→计划→任务→分析→实现"的七步流水线，把 vibe coding 升级为"有结构、可追溯、可预期"的开发。
关键要点：
- 核心理念：specifications become executable，规范为王、代码是衍生物
- 用 `specify` CLI 初始化，注入 `/speckit.*` 命令与模板
- 七步工作流：constitution/specify/clarify/plan/tasks/analyze/implement
- 三层定制：Extensions（加能力）/ Presets（改流程）/ Bundles（角色打包）
- 兼容 30+ AI 代理；覆盖绿地、并行探索、棕地三类场景
对于想在 AI 编码时代"既要速度、又要质量"的团队而言，Spec Kit 提供了一条值得认真评估的路径：前期写规范的成本，会以"更少的返工、更可控的实现、可追溯的证据链"回馈回来。如果你已经被 vibe coding 的不可控性困扰，不妨挑一个绿地项目，按七步走一遍——亲身体验"规范变成可执行"之后，你大概率会对"AI 写代码"这件事有全新的认识。
