Spec Kit：让 AI 编程从 Vibe Coding 到 Spec First

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 ------ 定规矩

sql 复制代码

/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements

这一步创建项目的治理原则：代码质量标准、测试要求、UX 一致性规范、性能指标。

这些原则会指导后续所有的开发工作，相当于给 AI 定下了"宪法"。

2. Specify ------ 写规格

这是最重要的一步，也是 Spec Kit 和普通 AI 编程最大的区别。你只管说"做什么"，技术细节完全不用操心。 你会发现------当你只说"做什么"的时候，AI 反而能更好地理解你的意图，不会自己脑补一堆"你可能想要"的功能。这大概就是传说中的少即是多吧。

vbnet 复制代码

/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 ------ 给方案

csharp 复制代码

/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 ------ 拆任务

bash 复制代码

/speckit.tasks

AI 根据 Plan 自动拆解成可执行的任务清单。每个任务精确到文件路径、验收标准，完成一个打一个勾。

5. Implement ------ 执行

bash 复制代码

/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 文档校验和评分

这些扩展开箱即用，按需安装。

六、怎么装

csharp 复制代码

# 推荐：用 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 包管理器）。如果没装过，执行这一行就行：

arduino 复制代码

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 的轻量路线？欢迎评论区聊聊。

如果觉得有帮助，点个赞收藏一下，我会有更多动力继续写这个系列。

也欢迎关注我的公众号「清汤饺子」，获取更多技术干货！