16-Spec-Kit详解：整体流程与机制解析

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.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 按任务写代码

这里最关键的并非那些命令本身，而是中间增加了多个“审核节点”。

原本可能是：

需求 → 代码

现在变成了：

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

这一微小的调整，却让整个开发流程的可控性大大提升。

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

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 写完代码后，常常忍不住反过来追问：

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

而使用 Spec Kit 后，这些问题的答案会提前体现到文档中：

尤其是像 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 这种流程化方式确实值得一试。