一、Vibe Coding 的甜蜜与苦涩
2025 年初，Andrej Karpathy 提出了“Vibe Coding”这个概念——你只需要用自然语言描述想法，AI 就能生成代码。这种方式极大地降低了编程门槛，让更多人能够通过 AI 实现自己的想法。对于快速原型验证和个人项目，Vibe Coding 的效率提升是真实的、惊人的。
但当项目变得复杂——涉及多个模块、前后端协同、多人协作、需要长期维护时，纯粹的 Vibe Coding 就会暴露出一系列结构性问题：
上下文丢失：长对话链中，AI 容易遗忘早期的设计决策。每开一个新的聊天窗口，之前的上下文就完全丢失了。
需求漂移：模糊的意图描述导致 AI“自由发挥”。你让它加个登录功能，它可能给你整出一套 OAuth2 + JWT + 微服务架构。
质量不可控：生成的代码风格不一，缺乏统一的质量标准。核心原因是它没有规格——AI 不知道“做对了”是什么样子，人类也没有明确的验收标准。
协作困难：多人各自和 AI 对话，导致对“要做什么”的理解不一致，代码合并时冲突频发。
这些问题的根源不在于 Vibe Coding 本身，而在于当项目复杂度上升后，它需要一层结构来约束和引导。
二、SDD：让规范成为可执行的契约
Spec-Driven Development（规格驱动开发，SDD）正是对这一问题的回应。GitHub 在 2025 年 9 月的博客中给出了明确定义：开发始于规范（Spec），而非代码。规范是代码应该如何行为的契约，它成为工具和 AI 智能体用于生成、测试和验证代码的“单一事实来源”。
SDD 的核心思想可以用一句话概括：规格是唯一的真相来源，代码只是规格的可执行投影。在传统开发中，代码是真相，规格文档可能过时；在 SDD 中，这个关系反转了——当规格变化时，代码需要重新生成或修改以匹配规格。
这并非什么全新发明，TDD 也是“先定义后实现”的思路。但 SDD 的革命性在于：规格不再只是人类之间的沟通工具，而是人机协作的接口协议。
SDD 通常将开发流程拆解为四个阶段：
- Specify（规范）：定义“做什么”和“为什么做”，包括业务规则、约束条件、验收标准
- Plan（规划）：确定技术方案，包括架构设计、数据模型、API 设计
- Tasks（任务）：将技术方案拆解为可执行的原子任务，按依赖关系排序
- Implement（实现）：AI 按照任务清单逐个进行代码实现
每个阶段的产出物必须经人工确认后，才进入下一阶段。这确保 AI 始终在正确轨道上运行。
目前主流的开源 SDD 工具有三种：OpenSpec、GitHub Spec-Kit 和 BMAD。它们的设计哲学和适用场景各有不同，下面逐一介绍。
三、OpenSpec：轻量级规范先行
核心定位
OpenSpec 由 Fission-AI 开发，是目前最轻量的 SDD 工具之一，在 GitHub 上已获得超过 5.5 万 star。它的核心理念极其简洁：写代码前，先让人类和 AI 对“要做什么”达成一致。
与其他工具相比，OpenSpec 最大的特点是棕地优先——它不要求从零开始，而是与存量项目完美兼容。它采用“变更提案”的模式，将每次修改定义为一个可追溯的变更单元，而非要求你为整个项目重写规范。
OpenSpec 支持集成到 22 种以上的 AI 编程工具中，包括 Claude Code、Cursor、Windsurf、OpenCode 等，这意味着你不需要绑定某一个特定的 IDE 或助手。
安装与初始化
OpenSpec 基于 Node.js（要求 20.19.0 或更高版本），全局安装即可使用：
npm install -g @fission-ai/openspec@latest进入你的项目目录后执行初始化：
cd your-project openspec init初始化会创建openspec/目录结构，并根据你选择的 AI 工具配置对应的斜杠命令。目录结构如下：
openspec/ ├── specs/ # 已实现的功能（真相之源） └── changes/ # 待实现的提案 └── [变更名]/ ├── proposal.md # 为什么要做、做什么 ├── design.md # 技术方案 ├── tasks.md # 实施清单 └── specs/ # 规范增量（补丁）你还可以通过--tools参数指定支持的 AI 工具，例如openspec init --tools claude或openspec init --tools all配置所有支持的工具。
三阶段工作流
OpenSpec 的核心工作流围绕三个命令展开：
1. Propose（提案）：创建变更提案
以“添加深色模式”为例，在 AI 对话中执行：
/opsx:new add-dark-mode这会创建openspec/changes/add-dark-mode/目录，并生成首个工件模板。你也可以使用/opsx:ff（快进）一次性生成所有规划文档，包括 proposal、specs、design 和 tasks。
2. Apply（实施）：按任务清单实现代码
/opsx:applyAI 会按照tasks.md中的任务清单逐步完成代码实现。由于计划存在于文件中而非聊天记录中，你可以清除上下文、启动全新的 AI 会话，然后用/opsx:apply继续——上下文不会丢失。
3. Archive（归档）：归档变更，更新主规范
/opsx:archive已完成变更会移至changes/archive/，同时更新specs/中的主规范。这确保了规范文档始终反映项目的当前状态。
OpenSpec 还提供了/opsx:verify命令用于验证实现与规范的一致性，以及/opsx:explore用于只读的探索和调研。CLI 层面则提供了openspec list（列出进行中的变更）、openspec validate（验证格式）等命令。
实践建议
根据社区反馈，大多数日常变更使用 OpenSpec 的 Lite 模式即可——几行需求加几个场景就够。只有涉及跨团队、跨仓库、API 契约变更的复杂场景，才需要写更详细的规范。
四、GitHub Spec-Kit：官方出品，规范即代码
核心定位
Spec Kit 由 GitHub 官方推出，核心主张只有一句话：让规格成为可执行的东西，直接生成可工作的实现。与 OpenSpec 的轻量灵活不同，Spec Kit 提供了一套更加完整和结构化的流程，适合新项目（Greenfield）和需要严格规范管理的团队。
Spec Kit 支持 GitHub Copilot、Claude Code、Cursor、Windsurf、Amazon Q Developer 等主流 AI 编程助手。
安装与初始化
Spec Kit 是一个 Python CLI 工具，需要通过uv包管理器安装。首先确保环境满足：Python 3.11+、Git、uv 工具。
# 安装 uv（如果尚未安装） curl -LsSf https://astral.sh/uv/install.sh | sh # 安装 Spec Kit CLI uv tool install specify-cli --from git+https://github.com/github/spec-kit.git # 初始化项目 specify init my-project --ai claude初始化完成后，项目下会生成.specify/文件夹，包含三个子文件夹：memory/（存放constitution.md，即项目根本原则）、scripts/（供 AI 调用的脚本）、templates/（规范文件参考模板）。
六阶段工作流
Spec Kit 的工作流包含六个阶段，通过斜杠命令驱动：
1. Constitution（宪章）：定义项目的根本原则
/speckit.constitution这是每个项目只需执行一次的步骤。宪章中定义的原则在后续所有阶段都不可违背。例如：“该项目为纯前端演示项目，暂不涉及后端服务，所有 API 请求使用本地 JSON 模拟。”
2. Specify（规范）：定义“做什么”
/speckit.specify此阶段专注于需求概述，不需要指定技术栈。你只需要描述页面和功能，Spec Kit 会生成结构化的需求文档。
3. Plan（规划）：定义“怎么做”
/speckit.plan基于规范生成技术方案，包括架构设计、数据模型和 API 设计。Spec Kit 还提供了/speckit.clarify命令来识别规范中的漏洞并生成澄清问题。
4. Tasks（任务）：拆解为可执行任务
/speckit.tasks将技术方案拆解为有序的原子任务，每个任务都足够具体，可以让 AI 直接执行。
5. Implement（实现）：执行任务
/speckit.implementAI 按照任务清单逐个进行代码实现。
6. Converge（收敛）：验证对齐
/speckit.converge对比实现代码与规范、计划和任务，检查是否存在偏离。如果报告“Converged”，说明实现与规范完全对齐。
版本控制集成
Spec Kit 的一个重要优势是与 Git 工作流的深度集成。所有规范产物（spec.md、plan.md、tasks.md）都是存储在 Git 仓库中的普通 Markdown 文件。当你提交功能 PR 时，可以同时附带规范文件和代码变更，审查者既能看到你“要建什么”（规范），也能看到你“怎么建的”（代码）。
实践中的注意事项
Spec Kit 生成大量 Markdown 文件，审查负担较重。有实践者反馈“工具生成大量冗长的 Markdown 文件，审查体验差，不如直接审查代码高效。”因此，对于小型项目或快速迭代场景，Spec Kit 可能显得过于笨重。但对于需要严格规范管理的新项目和团队协作场景，它的结构化优势非常明显。
五、BMAD：AI 驱动的敏捷军团
核心定位
BMAD-METHOD 全称 Breakthrough Method of Agile AI-Driven Development（敏捷 AI 驱动开发的突破性方法），是一个将 AI 驱动开发系统化、工程化的开源框架。与 OpenSpec 和 Spec Kit 的“规范驱动”路线不同，BMAD 的核心创新在于多智能体协作——它模拟一个完整的敏捷团队，由多个专业化的 AI 代理（分析师、产品经理、架构师、开发工程师等）协同工作。
BMAD 的最新版本（v6）已扩展至 12+ 个领域专家代理和 50+ 个引导式工作流，100% 开源免费（MIT 协议）。
架构设计
BMAD 分为四层架构：
第一层：安装器 CLI。一条命令完成安装，底层依赖 Node.js + Python + uv，支持 Claude Code、Cursor、Gemini、ChatGPT 等多平台。
第二层：核心引擎。采用确定性与 AI 协作的双引擎设计——确定性模板渲染系统用代码处理能确定的事情（避免 LLM 幻觉），需要推理的事情留给 AI。这降低了生成内容的质量波动。
第三层：技能系统 + 质量体系。34+ 工作流、12+ 角色智能体、派对模式（Party Mode）、Dev Loop 自动化。质量侧配套三层代码审查体系、CodeRabbit AI 审查、CI/CD + Husky pre-commit 等。
第四层：模块生态。五个模块：BMM 核心、BMB Builder（自定义智能体）、TEA 测试架构师、Game Dev Studio（Unity/Unreal/Godot）、Creative Intelligence Suite。
安装与使用
BMAD 的安装非常简单，一条命令即可完成：
npx bmad-method install安装器会自动检测项目状态并引导你完成配置。安装完成后，在 IDE 中运行/bmad-help技能，它会自动引导你告诉下一步该做什么。
完整开发工作流
BMAD 的工作流覆盖从产品想法到开发完成的完整流程：
输入（想法/Bug/需求） → 头脑风暴（forge-idea） → 产品简报（product-brief） → PRD（bmad-prd） → UX 设计（bmad-ux，输出 DESIGN.md + EXPERIENCE.md） → 架构设计（bmad-architecture） → 开发实施（bmad-quick-dev + 三层代码审查） → 持续迭代（bmad-loop：开发→审查→反馈→再开发） → 输出：可部署代码 + 完整产品文档BMAD 的两个关键创新值得特别说明：
Agentic Planning（智能体规划）：由 Analyst、PM、Architect 等专职代理协作，通过高级提示工程和人工参与的精化过程，生成远超通用 AI 任务生成的详细 PRD 和架构文档。
Context-Engineered Development（上下文工程化开发）：Scrum Master 代理将详细计划转化为“超级详细”的开发故事文件，其中嵌入了完整上下文、实现细节和架构指导。Dev 代理打开故事文件时，就已经完整理解了“建什么、怎么建、为什么建”。
派对模式与规模自适应
BMAD 的“派对模式”（Party Mode）允许在同一会话中同时激活多个角色——PM、架构师、开发者、UX 设计师同时协作讨论，类似于开一场虚拟站会，交叉验证产出质量。
另一个特色是规模自适应：同一个工作流，处理 Bug 修复时轻量快速，处理企业级系统时自动展开完整规划。这避免了“杀鸡用牛刀”的资源浪费。
适用场景与注意事项
BMAD 最适合复杂系统、多团队协作和游戏开发场景。但它的学习曲线也最陡峭。有用户反馈：“混乱的指令、零散的生成结果、反复的修改调试，不仅没省时间，反而消耗了更多 Token。” 关键在于理解其多代理协作的核心逻辑——一旦掌握，它能帮助团队少走很多弯路。
六、三大工具对比与选型建议
| 维度 | OpenSpec | GitHub Spec-Kit | BMAD |
|---|---|---|---|
| 定位 | 轻量级迭代 | 规范驱动开发 | 企业级全流程 |
| 复杂度 | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 核心理念 | 先对齐再动手 | 规范即可执行代码 | AI 即敏捷团队 |
| 工作流 | Propose → Apply → Archive | Constitution → Specify → Plan → Tasks → Implement → Converge | 头脑风暴 → PRD → 架构 → 开发 → 审查 → 迭代 |
| AI 工具支持 | 22+ 种 | 20+ 种 | 多平台 |
| 最佳场景 | 快速原型、个人项目、存量改造 | 新产品、团队规范、GitHub 生态 | 复杂系统、多团队协作、游戏开发 |
| 学习曲线 | 低 | 中 | 高 |
| 开源协议 | MIT | MIT | MIT |
选型决策指南
按项目复杂度选择：
- 简单项目（1-2 周）：OpenSpec
- 中等项目（1-3 月）：Spec-Kit
- 复杂项目（3 月以上）：BMAD
按团队规模选择：
- 1-2 人：OpenSpec
- 3-10 人：Spec-Kit
- 10 人以上：BMAD
按项目类型选择：
- 存量系统改造：OpenSpec（棕地优先）
- 游戏开发：BMAD + BMGD
- 企业级合规：BMAD Enterprise
简而言之：想要轻量灵活、不被绑架，选 OpenSpec；想要开箱即用、GitHub 官方背书，选 Spec-Kit；想要覆盖从需求到部署的全流程、多智能体协作，选 BMAD。
这三者并非互斥关系。OpenSpec 和 Superpowers 可以互补——OpenSpec 擅长“想清楚”（把模糊需求结构化为 proposal、design、spec、tasks 四件套），Superpowers 擅长“做到位”（brainstorming 审查设计缺陷）。
七、结语
SDD 的核心价值不在于工具本身，而在于它代表了一种思维方式的转变：从“让 AI 猜我要什么”到“我先想清楚要什么，再让 AI 精确执行”。正如 SDD 研究所指出的，SDD 的核心是建立“规范→验证→生成→运营”的闭环，强化需求与代码之间的语义对齐。
Vibe Coding 并没有错，它是 AI 编程的起点而非终点。SDD 是 Vibe Coding 的进化——在最终的实现阶段，AI 仍然用“氛围编程”的方式写代码，只不过不再根据模糊指令去猜，而是拿着一份清晰的规范去执行。人类负责定义意图、约束和验收标准，AI 负责高效地将规范转化为可工作的代码。
这才是 AI 编程的正确打开方式。
