GitHub Spec Kit 工程化实践：从规范到代码的七步工作流
软件开发领域长期存在一个结构性矛盾：需求文档与最终实现之间的鸿沟。传统模式下，规格说明书往往在开发生命周期早期就被束之高阁，成为形式化的过场文档。GitHub 近期开源的 Spec Kit 工具包提出了一种范式转换 ——Spec-Driven Development（规范驱动开发），其核心主张是将规格从 "脚手架" 转变为 "可执行资产"，让规格本身直接生成工作实现而非仅作指导。
范式转变：从代码优先到规格优先
Spec-Driven Development 的根本性转变在于重新确立规格的中心地位。在传统开发流程中，开发者往往先写代码再补文档，或者规格与实现脱节。Spec Kit 所倡导的模式要求开发者在编写任何业务代码之前，先通过结构化流程建立完整的需求规格、技术规划和任务分解。
这种转变的底层逻辑是意图驱动开发（Intent-driven Development）：在确定 "如何做" 之前，必须清晰定义 "做什么" 以及 "为什么做"。规格不再是代码的附属品，而是成为驱动整个开发流程的核心工件。AI 编码代理的能力演进使得这一范式成为可能 —— 现代大语言模型具备理解复杂规格并生成对应实现的能力。
Specify CLI 工具链架构
Spec Kit 的核心是 Specify CLI，这是一个基于 Python 开发的命令行工具，通过 uv 或 pipx 进行分发安装。工具链采用分层架构设计：
核心层提供基础命令和工作流模板，包括constitution、specify、plan、tasks、implement等核心命令。这些命令通过斜杠指令（如/speckit.specify）的形式暴露给 AI 编码代理。
扩展层支持通过 Extensions 和 Presets 进行能力扩展。Extensions 用于添加全新的命令和工作流程，例如集成 Jira、添加代码审查流程或实现 V-Model 测试可追溯性；Presets 则用于自定义现有工作流的模板格式和术语体系，例如强制要求合规性规格格式或适配特定方法论（Agile、Kanban、DDD 等）。
集成层已支持 30 余种 AI 编码代理，包括 GitHub Copilot、Claude Code、Gemini CLI、Cursor CLI、Codex CLI 等主流工具。集成通过生成代理特定的配置文件（如.claude/commands/）实现。
七步工作流的工程化实践
Spec Kit 定义了一套严格的七步开发流程，每一步都有明确的输入输出和验收标准：
第一步：确立项目原则（Constitution）
使用/speckit.constitution命令创建项目宪法文件（.specify/memory/constitution.md）。这份文档定义项目的治理原则、代码质量标准、测试要求、用户体验一致性和性能基线。它作为后续所有开发决策的锚点，确保 AI 代理在实现过程中保持一致的决策逻辑。
第二步：创建功能规格（Specify）
通过/speckit.specify命令将高层需求转化为结构化规格。此阶段要求开发者聚焦于 "做什么" 和 "为什么"，明确排除技术栈细节。规格输出采用用户故事和验收标准的格式，存储于specs/{feature-id}/spec.md。
第三步：规格澄清（Clarify）
在制定技术规划前，必须使用/speckit.clarify对规格进行结构化澄清。该命令通过覆盖式提问识别规格中的模糊点和不完整处，将澄清结果记录在规格的 Clarifications 章节。这一步骤是减少下游返工的关键质量控制点。
第四步：技术规划（Plan）
使用/speckit.plan命令将功能规格映射到具体技术实现。在此阶段可以指定技术栈（如 ".NET Aspire + PostgreSQL + Blazor"），输出包括架构设计、数据模型、API 契约和依赖分析，存储于specs/{feature-id}/plan.md。
第五步：规划验证（Validate）
在生成任务列表前，应通过人工审查或/speckit.analyze命令验证规划的完整性和一致性。检查要点包括：任务序列是否清晰、依赖关系是否明确、是否存在过度设计、是否符合项目宪法。
第六步：任务分解（Tasks）
/speckit.tasks命令将技术规划分解为可执行的任务清单（tasks.md）。任务按用户故事组织，标注依赖关系和可并行执行的标记[P]，并指定每个任务的文件路径和验收标准。
第七步：执行实现（Implement）
最后通过/speckit.implement命令按任务清单执行实现。该命令会验证前置条件、按依赖顺序执行任务、遵循 TDD 流程，并在完成后提供进度报告。
扩展与预设系统的定制化能力
Spec Kit 的模板解析采用优先级栈机制，从高到低依次为：项目本地覆盖（.specify/templates/overrides/）→ Presets → Extensions → Core。这种设计允许团队在不修改核心代码的情况下深度定制工作流。
Extensions适用于需要添加全新能力的场景。例如，可以开发一个 Extension 来自动生成 OpenAPI 规范、集成 CI/CD 流水线或添加安全扫描步骤。Extensions 通过specify extension add命令安装，会在代理配置目录中注册新的斜杠命令。
Presets适用于需要调整输出格式和术语的场景。例如，金融行业的合规团队可以创建 Preset 强制要求所有规格包含审计追踪字段；国际化团队可以创建本地化 Preset 将整个工作流翻译成其他语言。
落地建议与适用场景
Spec Kit 最适合以下场景：
绿场项目（0-to-1）：从零构建新系统时，Spec Kit 的完整流程能确保需求被充分理解和记录，避免后期因需求理解偏差导致的重构。
多技术栈探索：当需要评估多种技术方案时，Spec Kit 支持基于同一规格生成不同技术栈的实现，便于横向对比。
遗留系统现代化：对于 Brownfield 项目，Spec Kit 的迭代增强模式支持在现有代码库上有序添加新功能。
高风险 / 高合规领域：在金融监管、医疗健康等对可追溯性要求严格的领域，Spec Kit 生成的规格文档链可作为审计证据。
需要注意的是，Spec Kit 对 AI 模型的规格理解能力有较高要求。在模型能力不足的简单场景下，严格遵循七步流程可能显得冗余。建议团队根据项目复杂度灵活调整 —— 对于原型验证可适当跳过澄清和验证步骤，对于生产系统则应严格执行完整流程。
资料来源
- GitHub Spec Kit 官方仓库：https://github.com/github/spec-kit
- Spec Kit 文档站点：https://github.github.io/spec-kit/
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。