Hi～大家好呀，我是清汤饺子。
先说个我踩过不止一次的坑。
我要加个功能，跟 AI 说"加个用户登录"。AI 热情开干，半小时后给我整了个完整的 Auth0 集成方案——OAuth 2.0、JWT、refresh token，应有尽有。
我只想要一个最简单的本地账号密码登录。
AI 很委屈：你不就说"加个用户登录"吗？我以为……
我：我也以为你能读懂我的心思。
问题出在哪？不是 AI 不够努力，是我们在起点就没有对齐"做什么"。
然后我发现了 Spec Kit——GitHub 官方的 Spec-Driven Development 工具包。
GitHub 说：为什么不反过来试试？让规格说明书变成可执行的，代码来服务规格，而不是规格服务代码。 听起来很简单对吧？但背后的思路很根本。
一、Spec-Driven Development：规格说明书才是老大
传统开发里，代码是老大，规格说明书是跟班。 我们写 PRD、设计文档、技术方案，这些是"脚手架"——搭完就扔。代码往前走，文档跟不上，最后代码就是规格，规格就是代码。 这句话听起来很熟悉对吧？每个团队都经历过"代码改了三版，文档还停在 v0.1"的痛苦。
我们写 PRD、设计文档、技术方案，这些是" scaffolding "——搭完就扔。代码往前走，文档跟不上，最后代码就是规格，规格就是代码。
这是 GitHub 想翻过来的。
Spec-Driven Development（ SDD ） 的核心主张是：规格说明书变成可执行的，代码是规格的输出，而不是规格的指导。
翻译成人话：以前是"我想清楚，然后写代码"；现在是"我想清楚，写规格，AI 从规格生成代码"。
这不是在改进写代码的方式，这是在重新定义谁来当老大。
二、Spec Kit 是什么
GitHub 官方出的，听起来就很靠谱对吧？ 实际上也确实靠谱——GitHub 的工程团队自己就在用这套方法论来开发产品，所以 Spec Kit 不是纸上谈兵，是从自己的真实工作里提炼出来的。
定位：让你聚焦在"产品场景和可预期结果"上，而不是从零开始 vibe coding 每一个细节。
它提供一套结构化的工作流，让 AI 从"你说什么我做什么"变成"你说什么——我来确保做对"。
支持 Claude Code、Codex、Cursor 等主流 AI 编程工具。
三、六步工作流（核心）
整个工作流的设计思路很清晰：先定规矩 → 说清楚做什么 → 给技术方案 → 拆成小任务 → 执行 → 随时检查。每一步都有 slash command 对应，不用记复杂参数，AI 帮你串联全程。
1. Constitution —— 定规矩
/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements
这一步创建项目的治理原则：代码质量标准、测试要求、UX 一致性规范、性能指标。
这些原则会指导后续所有的开发工作，相当于给 AI 定下了"宪法"。
2. Specify —— 写规格
这是最重要的一步，也是 Spec Kit 和普通 AI 编程最大的区别。你只管说"做什么"，技术细节完全不用操心。 你会发现——当你只说"做什么"的时候，AI 反而能更好地理解你的意图，不会自己脑补一堆"你可能想要"的功能。这大概就是传说中的少即是多吧。
/speckit.specify Build an application that can help me organize my photos in separate photo albums. Albums are grouped by date and can be re-organized by dragging and dropping on the main page. Albums are never in other nested albums. Within each album, photos are previewed in a tile-like interface.
这一步描述你要做什么。聚焦在"做什么"和"为什么"，不要管技术栈。
你会发现——当你只说"做什么"的时候，AI 反而能更好地理解你的意图，不会自己脑补一堆"你可能想要"的功能。
3. Plan —— 给方案
/speckit.plan The application uses Vite with minimal number of libraries. Use vanilla HTML, CSS, and JavaScript as much as possible. Images are not uploaded anywhere and metadata is stored in a local SQLite database.
规格确认后，这一步给出技术方案：选什么框架、用什么数据库、依赖怎么管理。
Plan 是规格和技术决策之间的桥梁——规格说"要一个照片应用"，Plan 说"用 Vite + SQLite + 原生 JS 来实现"。
4. Tasks —— 拆任务
/speckit.tasks
AI 根据 Plan 自动拆解成可执行的任务清单。每个任务精确到文件路径、验收标准，完成一个打一个勾。
5. Implement —— 执行
/speckit.implement
AI 按照任务清单一个个执行。和 OpenSpec 一样，严格按照 Plan 来，不会自己跑偏。
6. Review & Iterate —— 检查和迭代
实现过程中可以随时回到前面的步骤调整。规格改了，Plan 自动更新，Tasks 自动重新生成。
四、和 OpenSpec 的区别
这是大家最常问的问题。
| OpenSpec | Spec Kit | |
|---|---|---|
| 出品方 | Fission-AI | GitHub 官方 |
| 工作流 | propose → apply → archive | constitution → specify → plan → tasks → implement |
| 风格 | 轻量、迭代友好 | 正式、有"宪法"概念 |
| 团队协作 | 支持 | 更好（支持 branch + merge 规格版本管理） |
| 社区扩展 | 较少 | 丰富（Jira、Azure DevOps 等集成） |
简单说：OpenSpec 更轻量，适合个人开发者快速上手；Spec Kit 更完整，适合团队协作和有正式流程要求的项目。
五、社区扩展生态（这是亮点）
这是我觉得 Spec Kit 最值得期待的地方——生态正在生长，而且很有意思。 截止目前社区已经贡献了十几种扩展，挑几个我，觉得特别有想法的说说：
集成类：
- Jira Integration：把 spec 规格自动同步到 Jira Epics 和 Stories
- Azure DevOps Integration：同步到 Azure DevOps Work Items
代码质量类：
- Checkpoint Extension：实现中途提交，不至于最后只有一个巨大的 commit
- Cleanup Extension：实现完成后自动 review 改动，修小问题，标记中等问题，生成大问题报告
流程类：
- Fleet Orchestrator：全生命周期编排，带 human-in-the-loop 关卡
- Cognitive Squad：多智能体认知系统，理解→内化→应用
文档类：
- Archive Extension：合并后归档到项目记忆
- DocGuard：Canonical-Driven Development 文档校验和评分
这些扩展开箱即用，按需安装。
六、怎么装
# 推荐：用 uv 持久安装（稳定版）
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
# 或者一次性运行（不需要安装）
uvx --from git+https://github.com/github/spec-kit.git@vX.Y.Z specify init <PROJECT_NAME>
⚠️ 前提：需要先安装 uv（一个极快的 Python 包管理器）。如果没装过，执行这一行就行：
curl -LsSf https://astral.sh/uv/install.sh | sh
装好后，在项目目录运行 specify init . --ai claude，AI 助手会自动识别并加载 Spec Kit。
七、技术原理
如果你对"它怎么做到的"感兴趣，这节简单说说。不感兴趣可以跳过，不影响你用它。
Spec Kit 的核心架构分四层，理解起来很简单：
-
Specify CLI：命令行工具，负责初始化项目、管理扩展、调度 AI Agent。是整个工具的入口。
-
Slash Commands（
/speckit.*）：用户和 AI 交互的主要方式。每个 command 对应一个工作流阶段，AI 根据当前阶段决定下一步。 -
Spec Artifacts：规格说明书的输出格式。包含：
SPEC.md——产品需求文档PLAN.md——技术实现方案TASKS.md——任务清单CONSTITUTION.md——项目治理原则
-
Extension System：社区扩展的插拔机制。扩展分为五类：
docs——读写/校验/生成规格文档code——review/校验/修改代码process——跨阶段工作流编排integration——同步外部平台visibility——项目健康度报告
八、和 Superpowers + ECC 的关系
这是 Claude skills 第四篇了，终于可以凑齐一桌麻将：
| 工具 | 出品 | 解决的问题 |
|---|---|---|
| Spec Kit | GitHub 官方 | 规格说明书 → 可执行，需求对齐 |
| OpenSpec | Fission-AI | 轻量规格流程，迭代友好 |
| Superpowers | @obra | 工程纪律，TDD + task 分解 |
| ECC | @affaan-m | AI 性能和记忆，Token 优化 |
Spec Kit 和 OpenSpec 解决的是同一类问题（需求对齐），但 Spec Kit 更适合团队、更正式；OpenSpec 更轻量、更迭代。
Superpowers 在下游执行层——规格确认后，怎么按工程规范来做。
ECC 在底层——让 AI 跑得更稳、更快、更聪明。
四者组合，才是完整的 AI 编程工作流。
写在最后
用了 Spec Kit 之后，我最大的感受是： Spec Kit 把"我以为 AI 能读懂我"变成了"我明明白白告诉 AI 我要什么"。
这种感觉就像是——以前是让 AI 猜你的心思，现在是跟一个聪明但需要你说清楚的同事合作。累吗？稍微累一点，但返工少多了，信心也多了。
Spec Kit 解决的就是这个问题——在 AI 动笔之前，先把"要什么"定义清楚。
GitHub 官方的背书也意味着它的长期维护有保障，扩展生态会更丰富。
如果你在团队里推动 AI 编程，用 GitHub 官方出品的工具，说服成本会低很多——不用解释这个工具靠不靠谱，直接说"这是 GitHub 官方做的"就够了。
当然，它也有学习成本。六个 command、constitution 怎么写、plan 怎么给，都需要摸索。但这个成本是一次性的，投入产出比很高。
你试过 Spec Kit 吗？或者你更偏向 OpenSpec 的轻量路线？欢迎评论区聊聊。
如果觉得有帮助，点个赞收藏一下，我会有更多动力继续写这个系列。
也欢迎关注我的公众号「清汤饺子」，获取更多技术干货！
