“凭感觉写代码”（vibe-coding）在原型、单文件、一次性脚本上很好用，但一旦碰到要服务真实用户、动辄牵扯四五个文件的真实应用，它就会撞墙。规格驱动开发（Spec-Driven Development）是另一条路：先把"要做什么"写清楚，再拆成可执行的任务，最后才动手写代码——而且每一步之间都留出人工审查的机会。
这篇文章讲清楚这套工作流是什么，并对比三套开源框架：Superpowers、GitHub Spec Kit、BMAD-METHOD，最后给出一个用三个问题就能定的选型方法。
什么是规格驱动开发
整套工作流由三份按顺序产出的文档驱动：
- Spec（规格）：写代码之前先用大白话写好，定义这次改动要达成什么目标。典型内容包括：支持哪些文件格式、有哪些交付模式、边界情况怎么处理、以及有意排除了哪些东西。
- Plan（计划）：把 spec 拆成编号、有先后顺序的任务，标明涉及的文件名和测试。
- Code（代码）：按计划逐项实现，每个任务之间插入人工审查。
它和 Claude Code 内置的 plan mode 不一样：规格驱动开发会把产物作为磁盘文件持久化，包含专门的审查阶段，并且能跨会话存活。
为什么 vibe-coding 会撞墙
模糊的 prompt 会逼模型去猜成千上万条没写出来的需求。举个例子：让不同团队实现同一份"通知偏好设置"需求，每个团队的理解都不一样——因为需求里没说清的部分，各人脑补的方向不同。
规格驱动开发的价值在于：每个审查阶段都能拦住一类特定的失败模式。
| 失败模式 | 在哪一步被拦住 |
|---|---|
| 任务做着做着范围蔓延 | Spec 审查 |
| 半成品式的实现 | Plan 审查 |
| 互相冲突的写法 | Plan 审查 |
| 修错了根因 | Spec 审查 |
| 计划一接触现实就崩 | Code 审查 |
三套框架对比
Superpowers
安装：
/plugin install superpowers@claude-plugins-official
这是一个 Claude Code 插件（obra/superpowers），打包了四个管理日常工作的 skill：
- brainstorming：通过引导式对话产出 spec
- writing-plans：把审查通过的 spec 转成编号任务列表
- subagent-driven-development：以测试优先的方式执行任务，每个任务完成后由 code-review 子代理审查
- requesting-code-review：合并前对完整 diff 做一次独立审查
工作流：头脑风暴 → Spec 审查 → 计划 → 计划审查 → 执行代码 → 完整 diff 审查
适合：个人开发、单仓库特性、无人值守的长跑任务
局限：处理多仓库特性、以及需要角色分工的工作时比较吃力
GitHub Spec Kit
安装：
uv tool install specify-cli \
--from git+https://github.com/github/spec-kit.git@vX.Y.Z
这是 GitHub 官方维护的 CLI（github/spec-kit），提供九个 slash 命令，支持多个 AI 编码代理（Claude Code、Cursor、Aider、Cline、Roo Code）。
核心命令（六个）：
/speckit.constitution/speckit.specify/speckit.plan/speckit.tasks/speckit.taskstoissues/speckit.implement
可选命令（三个）：
/speckit.clarify/speckit.analyze/speckit.checklist
它产出的文档与具体代理无关（agent-neutral），可以直接纳入 Git 跟踪。
适合：跨团队的 spec 审查、需要被非程序员阅读的 spec、跨代理协作、需要长期归档的产物
BMAD-METHOD
安装：
npx bmad-method install
这是一个模块化框架（bmad-code-org/BMAD-METHOD），它组织的不只是产物，而是人——用六个角色代理跨越四个阶段。
六个角色代理：
- Mary（分析师 / Analyst）
- Paige（技术文档 / Technical Writer）
- John（产品经理 / Product Manager）
- Sally（UX 设计师 / UX Designer）
- Winston（架构师 / Architect）
- Amelia（开发 / Developer）
四个阶段：
- 分析：产品简报（可选）
- 规划：PRD 和 UX 规格（必需）
- 方案设计：架构、epic、story、就绪度检查
- 实现：逐个 story 开发，并生成 QA
另有一条 “Quick Flow” 快速通道，对小型工作可以跳过第 1–3 阶段。
适合：服务真实用户的长周期项目、多人开发团队、有 PM 参与、需要角色分工交接的场景
选型决策树
三个问题就能决定用哪个：
- 这份 spec 需要被非 Claude Code 用户阅读吗？ → 用 Spec Kit
- 是否有多个人按不同角色分工协作？ → 用 BMAD-METHOD
- 以上都不是 → 用 Superpowers
混合用法：用 Spec Kit 产出持久化、跨团队的 spec，然后让 Superpowers 的 subagent-driven-development 指向 Spec Kit 生成的计划文件来执行。
几个实操要点
回本点：作者的经验是，扣掉前期投入后，规格驱动开发大约在第四、五个特性时开始变得划算。
spec 中途发现写错了怎么办：三套框架的处理方式不同：
- Superpowers：直接改 spec，重新生成受影响的任务
- Spec Kit：跑
/speckit.analyze找出矛盾点 - BMAD：第 3 阶段给出 “FAIL” 判定，回到第 2 阶段重写 PRD
小结
对大多数人来说，先选 Superpowers 上手，然后挑一个真实的端到端特性（涉及 3–5 个文件），完整跑一遍"头脑风暴 → spec → 计划 → 执行"的循环，把这套工作流真正内化下来。等到需要跨团队评审、或者多角色协作时，再考虑切到 Spec Kit 或 BMAD-METHOD。
本文翻译并改写自 DataCamp 教程 Spec-Driven Development with Claude Code。
关于
关注我获取更多资讯
