在 AI 辅助开发的浪潮中，“Vibe Coding” 虽然听起来很酷，但本质是依靠直觉和 AI 的模糊理解——你在和 AI “对暗号”，能不能跑通全靠运气。

为了让这种开发模式从「玄学」走向「工业级可靠」，SDD（规范驱动开发） 应运而生，而 OpenSpec 正是落地这一理念的开源框架。

如果你熟悉 TDD（测试驱动开发），会发现 SDD 其实是 TDD 思想在 AI 时代的延伸：先定义"什么是正确的"，再让 AI 去实现。TDD 用测试用例描述预期行为，SDD 用规范文档描述系统应该如何工作。

1. 核心理念：从 Vibe Coding 到 SDD

本质变化：TDD 用测试用例约束代码，SDD 用规范文档约束整个系统的设计和实现。两者都遵循"先定义正确，再实现"的原则。

2. 执行三剑客：Command, Rule, Skill

在 OpenSpec 或类似的 AI Agent 框架中，这三个概念定义了 AI 的边界和能力。值得一提的是，这套体系并不只是理论——腾讯云 CodeBuddy 的 Skill/Rule 机制就是一个具体的产品化落地：

Rule：静态上下文

Rule 提供持续生效的指令，Agent 在每次对话开始时都会加载这些内容。适合：

• 🔧 项目命令：npm run build、bun test 等常用命令
• 📐 代码风格：ES 模块 vs CommonJS、命名规范等
• 📁 项目结构：API 路由放在哪、组件如何组织
• 🔗 规范引用：指向代码库中的标准示例文件

Skill：动态能力

Skill 是按需加载的专业能力包，只有当 Agent 判断相关时才会加载。适合：

• ⚡ 自定义命令：通过 /命令名 触发的可复用工作流
• 🔄 自动化流程：配合 Hooks 实现自动化
• 📚 领域知识：特定任务的详细指令（如部署流程、数据库迁移等）

在 CodeBuddy 中的落地

CodeBuddy（包括 VS Code 插件 WorkBuddy 和终端工具 CodeBuddy Code）对 Skill/Rule 有完整的支持：

Skill 目录结构：

.codebuddy/skills/
├── pdf/
│   └── SKILL.md          # PDF 文档处理专家
├── data-analysis/
│   └── SKILL.md          # 数据分析能力
└── code-review/
    └── SKILL.md          # 代码审查工作流

每个 Skill 通过 SKILL.md 定义，支持 YAML Frontmatter 声明元数据：

---
name: deploy
description: 项目部署工作流
allowed-tools: Read, Write, Bash
---

你是部署专家，负责执行以下流程：
1. 运行构建命令
2. 上传到目标服务器
3. 清理 CDN 缓存
...

两个层级：项目级（.codebuddy/skills/，团队共享）和用户级（~/.codebuddy/skills/，个人通用）。项目级优先级更高，适合团队统一规范；用户级则是你跨项目通用的个人能力包。

核心区别：上下文窗口的效率

如果把所有内容都放在 Rules 里，Agent 的上下文窗口会被大量可能用不到的指令塞满。而 Skills 的按需加载机制，让你可以提供丰富的专业能力而不牺牲效率。

实践建议：Rule 与 Skill 的分工

保留为 Rule：

• 项目命令清单（build、test、lint）
• 代码风格规范（命名、导入、文件组织）
• 规范文件引用（指向标准示例）
• 工作流指令（如"修改后运行类型检查"）
• 简短且高频使用的内容

迁移为 Skill：

• 详细的多步骤操作流程（部署、发布、数据库迁移）
• 特定场景才需要的指令
• 可复用的工作流（PR、Issue、代码审查）
• 包含脚本执行的能力
• 超过 50 行的详细指南

3. OpenSpec、Rule 和 Skill 的关系

在 GitHub 的 Fission-AI/OpenSpec 项目中，这三者共同构成了 SDD 的完整实践：

• OpenSpec = 流程框架（我们要先做什么、后做什么）
• Skill = 执行能力（AI 会什么工具和技能）
• Rule = 行为约束（AI 必须遵守什么规则）

OpenSpec (流程 / 框架)

定义：OpenSpec 是整个 规范驱动开发（SDD） 的方法论和工具本体。它定义了从"提议 (Proposal)" → “规格 (Spec)” → “任务 (Tasks)” → “设计 (Design)” → “实现 (Apply)” → “归档 (Archive)” 的一整套标准工作流。

作用：它像是一个项目经理，规定了"我们要先写文档对齐需求，再写代码"这一核心原则，并提供 CLI 工具来管理这些步骤。

Skill (技能 / 能力)

定义：Skill 指的是 AI Agent 所具备的特定操作能力。在 OpenSpec 初始化时，它会在项目的 skills 目录下（如 .codebuddy/skills/、.claude/skills/ 等，取决于你使用的工具）生成一系列技能文件。

作用：它像是赋予 AI 的"技能书"。有了 Skill，AI 才能听懂 /opsx:new、/opsx:apply 这种指令。

Skill 实际上是将 OpenSpec 的 CLI 命令封装成了 AI 可以调用的函数或工作流，让 AI 知道"当用户说创建新变更时，我需要去运行 openspec new 命令并读取输出"。

Rule (规则 / 规范)

定义：Rule 是注入到 AI 上下文中的约束条件或编码规范。通常定义在 openspec/config.yaml 或专门的规则文件中。

作用：它像是公司的"员工手册"或"代码规范"。当 AI 使用 Skill 去生成某个文档时，Rule 会告诉 AI：“必须使用中文”、“所有的常量都要大写”、“必须包含回滚计划"等。

层级：Rule 可以是全局的（对所有步骤生效），也可以是针对特定产物（Artifact）的。

4. 它们是如何协同工作的？

在 OpenSpec 的工作流中，这几个元素形成了一个闭环：

1. OpenSpec/SDD (框架层)：你告诉 AI “我要做一个支付功能”，AI 并不直接写代码，而是先生成一份 SDD 文档。

2. Rule (约束层)：AI 在构思文档时，会检查你的规则库，确保设计符合你的架构偏好。

3. Command (执行层)：文档确认后，拆解成一个个具体的 Command 分发给 AI Agent。

4. Skill (支撑层)：AI 使用它自带的 Skill（如阅读现有代码库、运行测试脚本）来确保 Command 执行成功。

这与 TDD 的循环类似：规范（测试）→ 实现 → 验证 → 重构，只是粒度从函数级别提升到了系统级别。

5. 工具实践：CodeBuddy IDE 的 Craft Spec

SDD 的理念已经开始在主流 AI 编程工具中落地。以腾讯云 CodeBuddy IDE 为例，它内置的 Craft Spec 功能就是 SDD 流程的产品化实现。

从想法到代码的完整流程

在 CodeBuddy IDE 中，你不需要手动搭建 OpenSpec 的目录结构——IDE 直接将 SDD 流程融入了开发体验：

1. 自然语言输入：用一句话描述你的需求（如"帮我做一个博客系统”）
2. 自动生成 PRD：AI 将模糊想法转化为结构化的产品需求文档
3. 设计原型：基于 PRD 自动生成设计方案
4. 任务拆解：将设计拆分为可执行的开发任务
5. 代码生成：逐个任务生成代码，过程中人可以 Review 和调整
6. 集成部署：支持接入腾讯云 CloudBase、Supabase 等后端服务，一键部署

与 OpenSpec 的对应关系

为什么这比 Vibe Coding 好？

关键区别在于中间有一个对齐环节。Vibe Coding 是"说→写"的两步流程，中间没有确认；而 Craft Spec 是"说→对齐→写"的三步流程——AI 先把它的理解以 PRD 和设计方案的形式呈现给你，你确认后再进入编码阶段。这一步看似多余，实则避免了大量返工。

对于个人开发者，这意味着你可以用自然语言快速启动一个项目，同时保留了"先想清楚再动手"的工程纪律。对于团队，PRD 和设计方案本身就是可追溯的文档产物。

6. 进阶：MCP + OpenSpec，企业级高效开发实践

在企业中，将 OpenSpec 的 SDD 流程与 MCP（Model Context Protocol）工具生态结合，可以构建强大的开发流水线。以下是具体场景：

场景一：MySQL MCP + OpenSpec

场景：AI 需要基于现有数据库设计新功能

没有 MCP 时：AI 只能看到 schema 文档或 ER 图，可能与实际数据库不一致

有 MySQL MCP 后：

1. 规范阶段：AI 调用 MySQL MCP 直接查询真实数据库 schema
2. 设计阶段：AI 基于实际表结构设计新功能
3. 实现阶段：AI 生成与现有表风格一致的建表语句

用户：新增一个用户收藏功能
AI（OpenSpec）：先查库 → 生成 Spec（包含真实的user_id字段类型）
AI：根据 Spec 生成代码，自动匹配现有编码风格

场景二：日志 MCP + Skill 实现智能调试

场景：线上出现问题，AI 自动分析日志定位问题

工作流：

1. 用户描述问题（如"支付回调失败"）
2. OpenSpec 生成调试任务
3. Skill 调用日志 MCP 查询相关错误日志
4. AI 分析日志生成诊断报告

Skill: diagnose-payment-failure
├── 调用日志 MCP 查询最近1小时支付相关ERROR
├── 调用监控 MCP 获取异常指标
└── 生成诊断报告 + 修复建议

场景三：内部 API MCP + OpenSpec 规范生成

场景：新需求需要调用多个内部 API

工作流：

1. 规范阶段：AI 调用 API MCP 查询可用接口
2. Spec 包含：接口地址、参数、调用顺序、错误处理
3. 实现阶段：AI 生成统一调用层代码

企业实践建议

将内部工具封装为 MCP 后，AI 不仅能"看到"这些工具的存在，还能真正执行操作，形成规范 → 执行 → 验证的闭环。

7. SDD 与传统软件工程方法的对比

关键洞察：SDD 并不是要替代 TDD，而是弥补 TDD 在 AI 时代的断层。TDD 解决的是"如何确保代码正确"，SDD 解决的是"如何确保 AI 生成的系统设计正确"。

8. 实施 SDD 的挑战与应对

挑战 1：规范文档的质量依赖

问题：如果规范写得好，AI 就能生成高质量代码；如果规范模糊，AI 仍然会"幻觉"。

应对：

• 规范文档需要明确 输入、输出、边界条件
• 使用 Checklist 而非开放式描述
• 引入人工 Review 环节

挑战 2：规范与实现的同步

问题：代码变更后，规范可能过时。

应对：

• 将规范纳入 版本控制
• 使用 双向链接（如 Obsidian）关联规范与代码
• 定期审计规范一致性

挑战 3：团队协作成本

问题：写规范可能比写代码还花时间。

应对：

• 从小项目开始试点
• 建立 规范模板，降低写作门槛
• 利用 AI 辅助生成规范初稿

9. 总结

实践建议：如果你正尝试从"随便写写"转向"专业级 AI 开发"，建议从建立项目的 Rule 开始——这能立竿见影地减少 AI 乱写代码的情况。进一步，可以在 CodeBuddy IDE 中体验 Craft Spec 的完整流程，或者用 OpenSpec 跑一个小项目，感受一下"先写规范再写代码"的 SDD 模式。

参考资料：

• Fission-AI/OpenSpec GitHub 项目
• CodeBuddy IDE
• CodeBuddy Code Skills 文档

• AI 编程
• OpenSpec
• SDD
• Vibe Coding
• 开发方法论
• TDD
• CodeBuddy