之前我们探讨了两款规范驱动开发工具——Superpowers 注重纪律性，OpenSpec 强调灵活性。今天要介绍的是一个拥有“官方血统”的工具：Spec Kit，由GitHub官方出品。

其核心思想可以用一句话概括：规范并非代码的附加产物，规范本身才是主体，而代码不过是规范的编译结果。

这并非随意总结。Spec Kit 的官方文档明确指出：产品需求文档（PRD）不再是供开发者参考的辅助资料，而是直接驱动代码生成的源头。你所维护的是规范，代码仅仅是规范的“编译产物”。坦率地说，这一理念相当大胆。

核心概念：Constitution（项目宪法）

Spec Kit 拥有一个其他框架不具备的特性——项目宪法。

通过 /speckit.constitution 命令，你可以创建一份项目宪法，其中定义了项目的基本原则：代码质量标准、测试要求、用户体验一致性、性能要求等。所有后续开发工作都必须在宪法框架内执行。

这类似于国家的宪法。后续的每个功能规范、每个实施计划都必须与宪法兼容，不得冲突。

从工程实践角度看，这体现了高度的“企业级”设计。Superpowers 强调“先设计后实现”，OpenSpec 要求“先对齐规范”，而 Spec Kit 的纪律更为彻底：先确立原则，再依据原则执行一切。

五步工作流程

Spec Kit 的标准流程分为五步：

第一步：定宪法（constitution）

/speckit.constitution 创建以代码质量、测试标准、用户体验一致性为核心的项目原则。

第二步：写需求（specify）

/speckit.specify 开发一个照片相册应用，支持按日期分组、拖拽排序，照片以瓦片式预览展示

注意，该命令只关注“需求目标”和“理由”，绝不涉及“实现方式”。Spec Kit 的模板强制将“做什么”与“怎么做”分离。

第三步：做计划（plan）

/speckit.plan 使用Vite构建，尽量采用原生HTML/CSS/JavaScript，图片不上传至服务器，元数据存储在本地SQLite数据库

这一步才开始涉及技术选型。AI 将分析需求，生成实施方案、数据模型、API 合约、测试场景，并附带一份快速验证指南。

第四步：拆任务（tasks）

/speckit.tasks

AI 将计划拆解为可执行的任务列表。独立任务会自动标记为 [P]，表示可以并行推进。

第五步：实现（implement）

/speckit.implement

AI 按照任务列表逐项实现功能。

这五步流程看似与 OpenSpec 的 propose → apply → archive 类似？表面上看确实如此。但 Spec Kit 更为“厚重”——每一步都包含模板约束、一致性检查和宪法合规验证，层层把关。

15分钟对比12小时

Spec Kit 官方提供了一组对比数据：

传统开发流程：

• 撰写PRD：2-3小时
• 编写设计文档：2-3小时
• 手动搭建项目结构：30分钟
• 编写技术规范：3-4小时
• 编写测试计划：2小时
• 总计：约12小时的文档工作

Spec Kit 流程：

• /speckit.specify：5分钟
• /speckit.plan：5分钟
• /speckit.tasks：5分钟
• 总计：15分钟

15分钟内，你可以获得：完整的功能规范（包含用户故事和验收标准）、详细的实施计划（包括技术选型及理由）、API合约和数据模型、测试场景，以及所有在功能分支中版本化的文档。这个对比当然是理想场景，但方向是正确的——AI 将文档工作从“人工撰写”转变为“人工审核”。

支持哪些AI工具？

超过30种，是当前三个框架中支持数量最多的。

包括Claude Code、Cursor、GitHub Copilot、Codex CLI、Gemini CLI、Windsurf、Roo Code、Devin、JetBrains Junie、阿里通义灵码（Lingma）、Kimi Code、Trae等，基本上你能想到的主流工具都兼容。

更重要的是，它还支持多工具共存——在同一个项目中，你可以同时安装Claude Code和Cursor的集成，团队成员可以根据个人偏好使用各自擅长的工具。这在企业协作场景中实用性极强。

社区生态与扩展

Spec Kit 提供了社区扩展（Extensions）机制，允许社区贡献新的命令、钩子（hooks）和能力。此外，还有社区预设（Presets），可自定义 Spec Kit 的行为模板和术语。

这与 OpenSpec 的第三方 Schema Bundle 类似，但 Spec Kit 依托 GitHub 生态，社区规模和曝光度具有天然优势。

Spec Kit 与 OpenSpec 的区别

两者理念相近，但风格截然不同：

OpenSpec 的 Delta Spec 只关注变化——新增了什么、修改了什么、删除了什么。它轻量、迭代、不采用瀑布模型，非常适合“在现有项目上进行修改”的场景。

Spec Kit 的规范是完整的——从宪法到需求、计划、任务，每一步都有严格的模板和验证。它更适合“从零开始构建系统，每一步都需要可追溯”的场景。

一言以蔽之：OpenSpec 更轻量、更灵活，Spec Kit 更厚重、更严谨。

适用人群与场景

适合使用 Spec Kit 的情况：

• GitHub 生态用户（可与Copilot、Actions、Issues联动）
• 企业团队，对过程追溯有严格要求
• 从零起步的大型项目，需要完整规范体系支撑
• 团队成员使用不同AI工具，但需要统一流程的场景

不太适合 Spec Kit 的情况：

• 个人开发者的小型项目（略显繁重）
• 只希望快速迭代、不愿意编写规范的人
• 不在GitHub生态内的团队