Spec Kit 是什么？先从整体流程机制讲起

最近我在项目里开始尝试用 Spec Kit 管理 AI 协作开发。它不是让 AI 直接写代码，而是先把需求变成规格，再生成计划和任务，最后再进入编码。

这篇先不展开每个命令的细节，只简单聊一下 Spec Kit 的整体流程机制。后面我会一篇一篇拆开讲：specify、clarify、plan、tasks、implement 分别是怎么用的。

一、为什么需要 Spec Kit？

以前用 AI 写代码时，我经常会直接说：

帮我做一个忘记密码功能。

AI 通常会马上开始写代码。

但问题是，它可能还没完全理解项目背景，比如我的项目是一个 Monorepo 全栈博客项目：

claude/
├── apps/web/                 # 前端 H5 应用
├── services/auth-service/    # 认证服务
├── services/backend/         # 博客主业务服务
├── services/log-service/     # 日志服务
└── packages/shared-logging/  # 共享日志包

如果没有提前约束，AI 可能会出现这些问题：

  • 忘记密码代码写到了错误的服务里
  • 前端页面没有按项目结构拆分
  • 忽略了 HttpOnly Cookie、密码加密等安全规则
  • 需求边界没说清楚，写着写着范围变大
  • 最后只剩代码，看不出每一步是怎么来的

所以我需要的不是“AI 立刻写代码”，而是让 AI 先把事情想清楚。

Spec Kit 做的就是这件事。

二、Spec Kit 的核心思路

Spec Kit 的核心可以理解为：

先规格化，再计划化，再任务化，最后编码。

也就是把一句自然语言需求，逐步变成下面这些产物：

一句需求
  ↓
spec.md      # 需求规格书
  ↓
clarify      # 澄清不明确需求
  ↓
plan.md      # 实现计划
  ↓
tasks.md     # 任务清单
  ↓
代码实现

它更像是一套 AI 协作开发流程，而不是单纯的代码生成工具。

三、整体流程长什么样？

Spec Kit 常见流程大概是这样：

用户描述需求
  ↓
/speckit-specify
  ↓
生成 spec.md
  ↓
人工检查需求是否正确
  ↓
/speckit-clarify
  ↓
补充澄清不明确的问题
  ↓
/speckit-plan
  ↓
生成 plan.md
  ↓
人工检查技术方案是否合理
  ↓
/speckit-tasks
  ↓
生成 tasks.md
  ↓
/speckit-implement
  ↓
AI 按任务写代码

这里最关键的不是命令本身，而是中间多了几个“审核门”。

以前是：

需求 → 代码

现在变成：

需求 → 规格 → 计划 → 任务 → 代码

这会让 AI 开发过程更可控。

四、每个阶段大概负责什么？

1. specify：把需求说清楚

specify 阶段会生成 spec.md。

它主要回答：

  • 要做什么功能？
  • 谁会使用这个功能？
  • 用户在什么场景下使用？
  • 验收标准是什么？
  • 哪些内容不在本次范围内？

比如“忘记密码功能”，在这个阶段只需要先说清楚：用户通过手机号验证码重置密码，不需要一上来就讨论数据库表和 Controller。

2. clarify：把模糊问题问清楚

clarify 阶段一般发生在 specify 之后、plan 之前。

它主要用来发现需求里还没说清楚的地方，比如：

  • 验证码有效期是多久？
  • 忘记密码成功后是否自动登录？
  • 请求验证码是否需要图形验证码？
  • 同一个手机号多久可以重新发送一次？

这些问题如果不提前问清楚，后面生成 plan.md 时就只能靠 AI 猜。

所以 clarify 的作用就是在进入技术设计前，先把关键业务规则补齐。

3. plan：把实现方案说清楚

plan 阶段会生成 plan.md。

它主要回答：

  • 这个功能要改哪些系统？
  • 前端放哪里？后端放哪里？
  • 是否涉及数据库、接口、缓存、认证？
  • 是否符合项目已有技术规范？

以我的项目为例，忘记密码属于认证能力，后端应该放在：

services/auth-service/

前端页面则应该放在：

apps/web/

这一步可以避免 AI 把代码写错地方。

4. tasks：把计划拆成任务

tasks 阶段会生成 tasks.md。

它主要把实现计划拆成一条条可执行任务，比如：

- [ ] 确认 auth-service 中用户密码字段
- [ ] 新增请求验证码接口
- [ ] 新增重置密码接口
- [ ] 前端新增忘记密码页面
- [ ] 登录页增加忘记密码入口
- [ ] 执行 lint 和类型检查

这样 AI 后续执行时就不是“想到哪写到哪”，而是按任务推进。

5. implement：按任务写代码

implement 阶段才是真正进入编码。

它会根据前面生成的 tasks.md 一项项实现功能。

也就是说，Spec Kit 并不是不写代码，而是把写代码放在最后一步。

五、我觉得 Spec Kit 最大的价值

对我来说，Spec Kit 最大的价值不是“生成了几个 Markdown 文件”，而是它让 AI 协作过程变得可追踪。

以前 AI 写完代码后，我可能需要反过来问：

  • 你为什么这么设计？
  • 这个接口为什么放这里？
  • 这个需求有没有考虑边界？
  • 这个任务做到哪一步了？

用了 Spec Kit 后，这些问题会提前体现在文档里：

阶段产物作用
specifyspec.md初步整理需求规格
clarify更新 spec.md澄清不明确的业务规则
planplan.md确认技术方案是否合理
taskstasks.md确认任务是否可执行
implement代码按任务落地实现

尤其是像 Monorepo 这种多系统项目，Spec Kit 可以帮我提前确认修改范围，避免 AI 随意跨服务改代码。

六、什么时候适合用 Spec Kit？

我目前的感觉是：

适合用：

  • 新功能开发
  • 前后端联动功能
  • 涉及多个模块或服务
  • 涉及认证、安全、权限等关键逻辑
  • 希望保留需求和设计记录的功能

不一定需要用：

  • 改一个文案
  • 修一个很小的样式问题
  • 一两行代码能解决的小 bug

简单说，需求越复杂、影响范围越大，Spec Kit 越有价值。

七、总结

Spec Kit 的流程可以用一句话概括：

不要让 AI 一上来就写代码，先让它把需求、方案和任务讲清楚。

整体链路是：

/speckit-specify   →  spec.md
/speckit-clarify   →  澄清需求并更新 spec.md
/speckit-plan      →  plan.md
/speckit-tasks     →  tasks.md
/speckit-implement →  代码实现

这篇只是一个总览，先把整体机制讲清楚。

后面我会继续拆开写：

  • speckit-specify：如何把一句需求变成规格文档
  • speckit-clarify：如何补充澄清不明确的需求
  • speckit-plan：如何生成技术实现计划
  • speckit-tasks：如何拆出可执行任务
  • speckit-implement：如何按任务真正落地代码

如果你也经常用 AI 写项目代码，但遇到过“写得很快、改得很累”的情况，Spec Kit 这种流程化方式还是很值得试一下的。