GitHub官方Spec Kit：规范即代码
SpecKit是GitHub推出的规范驱动开发工具，核心理念是规范即代码，规范为主体，代码为编译结果。通过项目宪法设定质量与测试原则，五步工作流（定宪法、写需求、做计划、拆任务、实现）将传统12小时文档工作缩短至15分钟。支持30余种AI工具，适合企业级从零开始的大项目。
前面聊了两款规范驱动开发工具——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 分钟 vs 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）机制，社区可以贡献新的命令、钩子和能力。同时还有社区预设（Presets），可以自定义 Spec Kit 的行为模板和术语。
这和 OpenSpec 的第三方 Schema Bundle 类似，但 Spec Kit 背靠 GitHub 生态，社区规模和曝光度天然占优。
和 OpenSpec 的区别
两者理念相近，但风格截然不同：
OpenSpec 的 Delta Spec 只关注变化——加了什么、改了什么、删了什么。轻量、迭代、不搞瀑布流，非常适合“我在已有项目上改改东西”的场景。
Spec Kit 的规范是完整的——从宪法到需求到计划到任务，每一步都有严格的模板和验证。它更适合“我要从零开始建一个系统，每一步都要可追溯”的场景。
一句话总结：OpenSpec 更轻更灵活，Spec Kit 更重更严谨。
谁适合用？
适合：
- GitHub 生态用户（Copilot、Actions、Issues 都能联动）
- 企业团队，对过程追溯有严格要求
- 从零开始的大项目，需要完整规范体系支撑
- 团队成员使用不同 AI 工具、但需要统一流程的场景
可能不太适合：
- 个人开发者的小项目（略显笨重）
- 只想快速迭代、不愿写规范的人
- 不在 GitHub 生态里的团队
项目地址：github.com/github/spec-kit/
文档站：github.github.io/spec-kit/
下期预告：
《Superpowers vs OpenSpec vs Spec Kit：该选哪个？》——三个框架聊完了，最后一篇来个硬碰硬的对比。