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：如何将自然语言需求转化成规范的需求规格文档
• speckit-clarify：系统性地挖掘并澄清模糊的业务细节
• speckit-plan：基于项目架构生成合理的技术实现方案
• speckit-tasks：把计划分解为原子级的可执行开发任务
• speckit-implement：严格按照任务清单驱动 AI 生成高质量代码

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