Spec Coding（规格编程）

定义

Spec Coding（规格编程）的核心是规格先行——先用结构化文档定义"做什么"和"验收标准"，再让AI严格按照规格生成实现。

如果说Vibe Coding是"随意生成"，那Spec Coding就是"约束生成"：规格是不可篡改的合同，代码必须服从规格。

"需求越模糊，AI写得越快，返工越多。Spec Coding解决的就是这个问题。"

核心理念

1. Spec as Source of Truth

规格文档取代代码，成为开发流程的首要产物。代码是规格的实现，而不是反过来。

2. 可执行规格

规格不只描述需求，还能直接驱动AI生成实现。规格中的每一条需求都可以被验证——有就是有，没有就是没有。

3. 结构化流程

从需求到实现，每一步都有明确的产出物和验收标准：

阶段	产出	说明
Constitution	项目治理原则	代码质量标准、测试要求、性能基线
Specify	功能规格	用户故事、功能描述、验收标准
Plan	技术方案	技术栈选型、架构设计、数据模型
Tasks	任务清单	可执行的实现步骤，按依赖排序
Implement	代码实现	AI按规格和计划逐步执行

为什么需要Spec Coding

Vibe Coding的困境

Vibe Coding适合快速原型，但在以下场景会碰壁：

团队协作：没有规格，不同人用AI生成的代码风格和架构不一致
复杂业务逻辑：模糊的自然语言描述无法覆盖所有边界情况
质量要求：需要可追溯的需求-实现映射，而非"生成了就行"

Spec Coding的解决思路

用规格消除歧义，让AI的每次生成都有明确的验收标准
用结构化流程替代"一次性生成"，支持多轮迭代和增量开发
用任务清单实现可追溯：每个实现都能对应到具体的需求条目

Spec-Driven Development 流程详解

阶段一：Constitution（治理原则）

在项目启动时定义全局约束：

代码风格和质量标准
测试覆盖率要求
性能和安全基线
技术栈约束

阶段二：Specify（功能规格）

描述"做什么"，不涉及技术实现：

用户故事和使用场景
功能边界和约束条件
验收标准（可测试、可验证）

阶段三：Plan（技术方案）

确定"怎么做"：

技术栈选型及理由
系统架构和模块划分
数据模型和API设计
关键技术决策记录

阶段四：Tasks（任务分解）

将方案拆解为可执行步骤：

按依赖关系排序
每个任务有明确的输入输出
支持并行执行

阶段五：Implement（实现）

AI按任务清单逐项执行：

每完成一个任务，对照规格验证
发现规格遗漏时，回溯更新规格
最终输出：代码 + 测试 + 文档

代表工具

SpecKit — GitHub官方推出，支持30+ AI编程代理（Claude Code、Copilot、Cursor、Gemini CLI等），拥有60+社区扩展，是当前Spec-Driven Development的事实标准
OpenSpec — 轻量级规格驱动工具

与Vibe Coding的关系

Spec Coding 不是替代 Vibe Coding，而是解决不同的问题：

维度	Vibe Coding	Spec Coding
核心思路	随意生成，快速迭代	规格先行，约束生成
适用阶段	原型验证、探索性开发	正式开发、团队协作
质量保障	人工后续优化	规格驱动的自动化验证
前期投入	低（直接开始写）	高（需要先写规格）
典型组合	用Vibe Coding验证想法 → 用Spec Coding落地实现

适用场景

团队协作项目（多人需要统一的开发标准）
需要可追溯性的企业级开发
复杂业务逻辑的AI辅助实现
遗留系统改造（Brownfield）
合规要求严格的行业（金融、医疗）

局限性

前期投入高：写好规格本身需要时间和专业度
灵活性降低：不适合快速原型阶段和探索性开发
学习曲线：需要理解Spec-Driven Development方法论
工具依赖：流程的顺畅程度依赖工具链的成熟度

适用场景对照

维度	Spec Coding
人类角色	架构师——定义规格和验收标准
AI角色	严格执行者——按规格生成实现
核心优势	可追溯、可验证、团队一致
适用场景	团队项目、企业级开发、合规场景
代码质量	规格驱动的质量保证

实战示例：同一需求的 Spec Coding 写法

需求：构建一个天气查询页面，调用 OpenWeatherMap API 显示当前天气

第一步：编写 Spec 文档

# Spec: 天气查询页面

## 功能需求
- 用户输入城市名称，点击按钮查询
- 调用 OpenWeatherMap Current Weather API
- 展示：城市名、温度（摄氏度）、湿度、风速、天气图标
- 支持加载状态、空状态、错误状态

## 数据模型
interface WeatherData {
  name: string
  main: { temp: number; humidity: number }
  wind: { speed: number }
  weather: [{ icon: string; description: string }]
}

## API 规格
- Endpoint: GET /data/2.5/weather?q={city}&appid={key}&units=metric
- 成功: 200 + WeatherData
- 城市未找到: 404
- API Key 无效: 401

## 验收标准
- [ ] 输入中文城市名可正常查询
- [ ] 温度显示为摄氏度，保留整数
- [ ] 加载时显示骨架屏动画
- [ ] 错误时显示可操作的提示文案
- [ ] 空状态显示引导文字
- [ ] 组件可单独测试，无外部副作用

第二步：将 Spec 输入 AI 工具

将上述 Spec 文档交给 Claude Code / Cursor，AI 严格按照规格生成：

React 组件 + TypeScript 类型
API 封装层 + 错误处理
单元测试
对照验收标准逐项通过

关键特征：规格先行，AI 按合同执行。代码质量由 Spec 保障，而非依赖 AI 的"发挥"。适合团队协作——Spec 就是沟通语言。