Spec Coding（规约驱动开发）· 个人总结
看了 spec-kit 介绍 + 规约驱动相关讨论，对照自己工作流后的理解 · 2026-07-03
为什么跟 AI 越聊越乱
典型场景：「帮我加登录」→「密码要加密」→「失败要有提示」→ 改到第三轮注册接口被动了。
直觉怪模型不够聪明。真相是输入就是碎的——AI 每次只看到这一句话 + 眼前上下文，做第五步时可能忘了第一步为什么那么设计。你和 AI 之间缺一份双方都认可的对齐物。
Vibe Coding 爽在不用写文档，适合小玩具、一次性脚本、周末 demo。正经项目、要长期维护的，口头一句句喂，就像跟外包说需求——双方都没有完整图。
Spec Coding 是什么
先把要做成什么样讲清楚，再让 AI 动手。
不是写一份死合同，而是分台阶、每阶停一下对一次。任何一步发现前面想岔了，随时回去改——规约是活的共识，不是瀑布式签字定死。
1 | 需求（做什么、为什么，不谈技术） |
| Vibe Coding | Spec Coding | |
|---|---|---|
| 步骤 | 四步糊在一起 | 四步分开，每步有产物 |
| 纠错 | 代码写完才发现方向错 | 第一步就能发现理解偏差 |
| 产物 | 碎片对话 | 可检查、可修改的文档 |
spec-kit：把流程做成斜杠命令
GitHub 官方的 spec-kit 把上面四步封装成 Skill，装在 .claude/skills/ 下：
| 命令 | 干什么 |
|---|---|
/speckit-constitution | 项目铁律（如「所有接口写测试」） |
/speckit-specify | 只写需求，不提技术 |
/speckit-plan | 基于需求定技术方案 |
/speckit-tasks | 拆任务清单 |
/speckit-implement | 按任务实现 |
兜底：
| 命令 | 什么时候用 |
|---|---|
/speckit-clarify | specify 后、plan 前——把模糊点问清 |
/speckit-analyze | tasks 后、implement 前——需求/方案/任务交叉比对 |
关键细节：Skill 是 Claude Code 启动时扫描的，必须 cd 进项目目录再开 claude，斜杠命令才会出现。
安装：uv tool install specify-cli --from git+https://github.com/github/spec-kit.git，然后 specify init <项目名> --integration claude。
和标准瀑布的区别
| 瀑布 | 规约驱动 | |
|---|---|---|
| 文档 | 签字定死，改要走变更 | 随时改，AI 几秒重生 |
| 节奏 | 一次定死扛着走 | 边走边对齐 |
表面都是分阶段，内核完全不同——规约是橡皮泥，不是石头。
选型标准：这东西打不打算长期维护、持续加功能？是 → Spec；几十行跑一次就扔 → Vibe 一把梭。
和我自己的工作流：本质一样，工具不同
我没直接用 spec-kit，但大需求走的是同一套逻辑：
1 | /grill-with-docs ≈ constitution + specify + clarify（压力测试 + 对齐边界） |
区别是我用自定义 Skills 而不是 spec-kit 默认模板，Grill 阶段会读代码库、写 ADR，比纯 spec-kit 更重「领域建模」。
spec-kit 的 /speckit-specify 强调需求阶段零技术词——这点我认同，也是性价比最高的一次检查：花 2 分钟读 spec，省 2 小时返工。
实操教训
- specify 只谈需求——「React + SQLite」留到 plan
- 每步产物亲自过——不对当场改，别攒到 implement
- 大项目分阶段 implement——别一条命令从头撸到尾；上下文太长会顾此失彼
- implement 前一行代码都没有是正常的——到 tasks 步还在规划，说明做对了
有人用 spec-kit 做看板 demo，10 分钟跑通——我信小 demo 可以，但生产级项目别指望一次 /speckit-implement 搞定。
和 MewCode Agent 项目的关联
MewCode Agent 虽没用 spec-kit，但文档结构也是：
1 | spec.md → plan.md → task.md → checklist.md → 代码 |
让 AI 写代码前先把规划做满——这和 spec-kit 哲学一致，只是文件命名不同。
我的判断
AI 时代瓶颈从「会不会写代码」转向能不能把事情讲清楚。Spec Coding 的价值不是文档本身，是把「先想清楚再写」从废话变成绕不过去的工序。
| 场景 | 我选 |
|---|---|
| 改 Bug、小接口、脚本 | Vibe 或单会话 /implement |
| 跨模块、要维护、有架构决策 | Grill → PRD → Issues → Implement |
规约驱动真正值钱的是对齐成本前置——第一步发现理解偏差，比 implement 完返工便宜一个数量级。
待办
- 挑一个 repo 用 spec-kit 完整跑一遍，和我的 Skills 流程对比差异
- constitution 级铁律（测试、安全）是否该单独文件化
- 大需求 implement 继续一 Issue 一会话，别合并成 mega-session
