Spec Coding 使用

巧用 Spec-Kit，把AI训练成靠谱工程师！

Vibe Coding VS Spec Coding

1. Vibe Coding: 靠感觉、靠默契、反复试错，在跟AI的不断拉扯中勉强推进的开发模式，就是现在最火的—— “Vibe Coding”（感觉式编程）

在小项目里跑跑还行，项目复杂、团队一扩大，各种弊端就全暴露了：

• 需求理解全靠猜：AI常常“会错意”，做出来的东西跟想的完全是两码事。
• 技术选型像开盲盒：AI可能随手就选个你完全不熟的技术栈，后续维护火葬场。
• 代码质量堪忧：生成的代码能跑，但结构乱七八糟，别说交接了，自己看都费劲。
• 协作基本为零：除了你和AI，没人知道这功能是怎么“感觉”出来的，新同事来了只能干瞪眼。

结果呢？我们把大把时间都浪费在了跟AI的反复沟通和修改上，而不是真正地创造价值。

2. Spec Coding（规范式编程）: 既能用上AI的超能力，又能保证软件开发的工程质量和确定性，正在掀起一场AI编程的范式革命。

Spec-Kit是啥？从“代码为王”到“规范为王”，Spec-Kit不是一个新的AI编程工具，它是一套工作流和方法论。
它的作用，就是通过一套命令行工具和模板，把你那个有点“虎”的AI编程助手（无论是Claude Code, GitHub Copilot,还是Gemini），“调教”成一个既懂需求、又懂架构的“靠谱工程师”。

它的核心理念——规格驱动开发（Spec-Driven Development, SDD） ，直接把传统开发流程给颠覆了：

• 传统开发：规格 (爱看不看的文档) → 代码 (一顿瞎写) → 代码成为唯一真理
• Spec-Kit开发：规格 (可被执行的指令) → 计划 (AI自动生成) → 任务 (AI自动拆解) → 代码 (AI按图施工) → 规格成为唯一真理

在Spec-Kit的世界里，“规格”不再是写完就扔的静态文档，而是可以被执行、被验证、驱动整个开发流程的“源代码”。一句话：代码为规格服务，而不是规格为代码服务。

• Vibe Coding：没图纸，凭感觉边盖边想，盖出来的可能是个“歪歪扭扭的茅草屋”。
• Spec Coding：先有详细的建筑图纸（规格），再按图施工（实现），盖出来的才是“坚固可靠的摩天大楼”。

Spec-Kit 使用步骤

Spec-Kit把复杂的软件开发，变成了一套清晰、可控的“流水线”。下面，我就用开发一个简单的“待办事项（Todo List）”应用，带你走一遍完整流程。

Spec-Kit核心用途：

• 让“写什么/为什么”（Spec）先于“怎么做”（Plan/Tasks/Impl），减少返工；
• 给代理提供统一的“宪法”和护栏（安全、质量、SLO、禁行区等）；
• 产出一套可追溯的工件与目录结构（如 .specify/、任务清单、计划文档等）。

核心理念（SDD 四个关键词）

• Intent first：明确要做“什么/为什么”，再谈实现细节；
• Rich specs：用结构化的规格与检查清单约束 AI；
• Multi-step refinement：多阶段收敛替代一次性大Prompt；
• Model-agnostic control：与多种代理协同但不绑定技术栈。

第一步：安装

1
2
3
4

# 推荐用uv (一个快到飞起的Python包管理工具)
uv tool install specify-cli --from https://github.com/github/spec-kit.git

第二步： 初始化项目

1
2
3
4
5
6
7

# 创建一个tst-app 项目
specify init tst-app
cd tst-app

# 初始化的时候，它会让你选一个AI助手（我们使用的是：Claude Code+GLM4.7）和脚本类型（比如sh）。

搞定之后，你的项目里会多出.claude/和.specify/这些文件夹，这里面就藏着Spec-Kit的所有“魔法”。

第三步： 立规矩 ( /constitution ) - 给项目立个“宪法”

这是可选，但强烈推荐的步骤。项目开始前，先给它定好基本原则和约束。
在你的AI编程助手中输入（例子中使用Claude Code，注意工程路径中不要有中文！！）：

1
2
3

/speckit.constitution 这是一个基于React的待办事项应用，要注重简洁和用户体验。

AI会马上为你生成一份constitution.md文件，里面可能写着：

• 技术栈偏好：优先用React Hooks，别用Class Components。
• 代码风格：按Airbnb JavaScript Style Guide来。
• 测试要求：核心功能必须有单元测试。
• 用户体验原则：交互必须流畅，响应时间低于100ms。

这份“宪法”就是天条，后面所有的开发工作都得按这个来。

第四步： 提需求 ( /specify ) - 你只要说“要什么”

用大白话描述你的需求。记住，只谈功能，别谈技术。

1
2
3
4
5
6
7
8

/speckit.specify 我要做一个待-办事项应用。
核心功能：
- 用户可以添加新的待办事项。
- 用户可以标记待办事项为“已完成”。
- 用户可以删除待办事项。
- 完成任务时，要有一个好玩儿的庆祝动画。

Spec-Kit会立马开干：

• 在specs/目录下创建一个新版本，比如001-todo-app-core-features。
• 生成一份详细的spec.md（需求规格文档），里面有用户故事、验收标准、边界条件等等。
• 自动给你创建一个新的Git分支，比如feat/001-todo-app-core-features。

第五步： 清疑点 ( /clarify ) - 消除那些模棱两可的地方

这一步也是可选的。如果你的需求描述得比较模糊（比如“好玩儿的动画”），可以运行这个命令，让AI主动问你问题，把细节弄清楚。

1
2
3

/speckit.clarify

AI可能会反问你：

• Q1：“好玩儿的庆祝动画”具体是啥风格？是放烟花还是撒花？
• Q2：待办事项有字数限制吗？
• Q3：要不要支持任务优先级？
  你只要回答这些问题，AI就会自动更新spec.md，让需求变得嘎嘎清晰。

第六步： 出方案 ( /plan ) - AI变身架构师

需求明确后让AI来做技术方案。

1
2
3

/speckit.plan

AI会根据“宪法”和“需求”，生成一套完整的技术方案文档，可能会有：

• plan.md: 技术栈决策（比如用React 18, Zustand做状态管理, Framer Motion做动画）。
• data-model.md: 数据结构定义（比如Todo长啥样）。
• contracts/: API接口或组件接口定义。
• research.md: 为啥这么选型，做了哪些调研。

第七步： 拆解任务 ( /task ) - 拆解成可执行的任务

方案定了，接下来就是把它拆解成能干的活儿。

1
2
3

/speckit.task

AI会把plan.md拆成一份详细的tasks.md文件，就像一个靠谱的项目经理，把工作安排得明明白白：

1
2
3
4
5
6
7
8
9
10
11

Phase 1: 项目设置 (3个任务)
- [ ] T001: 初始化React + Vite项目。
- [ ] T002: 安装Zustand和Framer Motion依赖。
- [ ] T003: 配置ESLint和Prettier。

## Phase 2: 核心组件开发 (4个任务)
- [ ] T004: 开发`TodoItem`组件。
- [ ] T005: 开发`AddTodoForm`组件。
- ...

第八步： 写代码 ( /implement ) - AI开始干活

现在，让AI开始写代码吧！

1
2
3

/speckit.implement

AI会严格按照tasks.md的任务列表，一个一个地完成编码、写测试，每搞定一个，就会在任务清单上打个勾[x]。
你可以选YOLO模式让它一口气干完，也可以在每个任务后检查确认一下。
稍微等一会儿，一个结构清晰、文档齐全、完全符合你所有规范的“待办事项”应用就诞生了！

总结

Spec-Kit的核心价值是啥？

用了Spec-Kit，你拿到的可远不止是代码：

• 高质量、可预测的输出通过前置的规范和计划，AI的“自由发挥”被管住了，产出更符合你的预期。
• 自动化文档生成整个开发过程（需求、方案、任务）都被记了下来，形成了跟代码同步的“活文档”，再也不怕文档过期了。
• 团队协作效率飙升标准化的流程和文档，让团队沟通成本大大降低，项目维护和交接都变得超级简单。
• 沉淀团队的最佳实践可以把团队的架构约定、代码规范都写进/constitution，让宝贵的经验传承下去，变成可复用的资产。
• 真正的“AI工程师” 它让你和AI的关系，从“一个指令一个动作的打字员”，变成了能够理解意图、参与设计的“工程师”伙伴。

Vibe Coding 已死，Spec Coding 当立！

Spec-Kit的出现，标志着AI编程正在从“手工作坊”式的Vibe Coding，走向“工业化生产”式的Spec Coding。
它把软件工程“先想清楚再动手”这句古老智慧，跟AI的强大生产力完美地结合在了一起。
如果你也厌倦了跟AI的反复拉扯，渴望一种更从容、更具确定性的开发方式，那么，真的该试试Spec-Kit了。