# SDC：Claude Code的规格驱动开发插件，用结构化工作流告别"氛围编程"

> SDC（Spec-Driven Claude）是一个专为Claude Code设计的规格驱动开发（SDD）插件。它通过/sdc.clarify、architect、tdd、backend/frontend等专业代理和斜杠命令，强制执行"先写规格、后写代码"的流程，解决AI编程中常见的"氛围编程"问题——即代码看起来对但实际不符合需求的情况。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-11T21:43:20.000Z
- 最近活动: 2026-04-11T21:57:25.191Z
- 热度: 159.8
- 关键词: Claude Code, 规格驱动开发, SDD, AI编程, 工作流, 测试先行, 代码审查, 多代理
- 页面链接: https://www.zingnex.cn/forum/thread/sdc-claude-code
- Canonical: https://www.zingnex.cn/forum/thread/sdc-claude-code
- Markdown 来源: ingested_event

---

## "氛围编程"的陷阱

在使用AI编程助手（如Claude Code）时，许多开发者都遇到过这样的困境：你描述了一个功能需求，AI迅速生成了代码，代码看起来合理、语法正确，甚至能运行——但实际行为却与预期不符。

这种现象被称为"氛围编程"（Vibe Coding）：AI生成的输出在表面上看起来是对的，但缺乏对真实意图的准确理解。根本原因在于需求描述往往模糊不清，而AI倾向于基于统计模式生成"最可能正确"的代码，而非"真正正确"的代码。

规格驱动开发（Spec-Driven Development, SDD）正是为了解决这一问题。它要求在编写任何代码之前，先编写完整、详细的规格说明，明确所有接口、类型、验收标准和业务规则。只有当规格被批准后，才进入实现阶段。

SDC（Spec-Driven Claude）将这个理念深度集成到Claude Code中，通过结构化的工作流和专业化的代理，强制执行SDD流程。

## SDC的核心理念

### 规格即契约

在SDD中，规格定义了完整的契约：
- **API契约**：端点、状态码、请求/响应结构
- **类型定义**：TypeScript接口（或等效物）供前端使用
- **DTO/Schema**：后端的输入验证
- **验收标准**：可验证的行为定义"完成"
- **业务规则**：仅从契约看不明显的逻辑

后端和前端独立阅读同一份规格，得出一致的结果。没有错位，没有重写。

### 何时使用SDD

SDD并非适用于所有场景：
- **适合SDD**：引入新行为的功能开发
- **直接实现**：Bug修复、小的视觉调整、轻微重构

理解这个边界对于高效使用SDC至关重要。

## SDC工作流详解

SDC安装四个全局斜杠命令到Claude Code，形成一个完整的工作流：

### 第一阶段：澄清与理解（/sdc.clarify）

**参与者**：你 + Claude

这是整个流程的起点。你描述功能，Claude提出有针对性的问题来消除歧义，并评估范围是否适合一个规格，或者应该拆分。

**关键产出**：
- 明确的需求描述
- 范围边界定义
- 是否需要拆分的建议

### 第二阶段：架构设计（architect代理）

**参与者**：architect代理（使用opus模型）

architect代理负责编写完整的规格文档，保存在`docs/specs/`目录下。它呈现规格摘要并等待你的明确批准，然后才继续。

**这是SDD的关键控制点**：在规格被批准之前，不会开始任何实现工作。

### 第三阶段：测试先行（tdd代理）

**参与者**：tdd代理（使用sonnet模型）

根据验收标准编写测试——在实现存在之前。测试会失败，这是预期的。测试先行的方法确保：
- 验收标准是可验证的
- 实现有明确的目标
- 回归测试已经就位

### 第四阶段：并行实现（backend + frontend代理）

**参与者**：backend代理和frontend代理（都使用sonnet模型）

两个代理并行工作，使用已批准的规格作为契约。由于规格已经明确了所有接口细节，两个代理之间不需要协调。

### 第五阶段：精炼与审查（/refine）

代码审查聚焦于：
- 架构违规
- 安全问题
- 命名规范
- 缺失的错误处理

### 第六阶段：测试验证（/test）

编译 + 静态检查 + 运行测试，确保一切通过。

### 第七阶段：提交记录（/commit）

生成符合语义化版本规范的提交信息。

### 第八阶段：文档更新（docs代理）

**参与者**：docs代理（使用haiku模型）

更新CLAUDE.md和代理配置，反映结构变化。

## 不同场景的工作流变体

SDC提供了针对不同类型任务的优化工作流：

| 场景 | 工作流 |
|------|--------|
| 后端Bug | backend → /test → /commit |
| 前端/UI Bug | frontend → /test → /commit |
| 视觉变更 | design → frontend → /test → /commit |
| 重构 | /refine → /test → /commit |
| 文档过时 | docs → /commit |

这种灵活性确保SDC不会成为简单任务的负担，同时在复杂功能开发中保持严格的质量控制。

## 并行开发支持

当项目使用git worktree时，多个功能可以在不同的Claude Code会话中并行开发：

```
会话A: /sdc.clarify → architect → [批准] → tdd → backend ∥ frontend → ...
                              ↓
                    会话B现在可以开始：
                    /sdc.clarify → architect → [批准] → tdd → ...
```

**关键规则**：
- 一次一个规格——在规格批准前不要开始下一个
- 实现阶段可以并行——一旦tdd开始，新会话可以开始下一个规格
- 无文件冲突——每个实现会话通过worktree隔离

## 技术栈支持

SDC目前支持以下技术栈：

**后端**：NestJS、Express、FastAPI、Django、Rails

**前端**：Next.js、React+Vite、Angular、Vue

模板是纯Markdown文件，添加新栈只需：
1. 创建`templates/agents/backend-<stack>.md`或`templates/agents/frontend-<stack>.md`
2. 在`commands/sdc.init.md`的检测逻辑中添加栈名称
3. 提交PR

## 安装与初始化

### 快速安装

```bash
bash <(curl -fsSL https://raw.githubusercontent.com/Jpecamargo/sdc/main/install.sh)
```

### 源码安装

```bash
git clone https://github.com/Jpecamargo/sdc
cd sdc
bash install.sh
```

### 项目初始化

在任何项目中打开Claude Code并运行：

```
/sdc.init
```

这会检测技术栈，创建`.claude/`结构和CLAUDE.md。

### 卸载

```bash
bash <(curl -fsSL https://raw.githubusercontent.com/Jpecamargo/sdc/main/uninstall.sh)
```

## 项目结构

初始化后，项目会获得以下结构：

```
.claude/
├── agents/
│   ├── architect.md      # opus - 规格、契约、验收标准
│   ├── tdd.md            # sonnet - 从验收标准写测试
│   ├── backend.md        # sonnet - 你的后端栈
│   ├── frontend.md       # sonnet - 你的前端栈（如适用）
│   ├── design.md         # sonnet - 设计系统规格
│   └── docs.md           # haiku - 保持CLAUDE.md同步
└── commands/
    ├── orchestrate.md    # 将请求路由到正确代理
    ├── clarify.md        # 在规格前解决歧义
    ├── commit.md         # 语义化提交
    ├── test.md           # 编译+检查+测试
    └── refine.md         # 代码审查和违规修复

docs/specs/
└── _template.md          # 包含所有必需部分的规格模板
```

## 可用命令参考

| 命令 | 用途 |
|------|------|
| /sdc.init | 初始化项目：检测栈、创建.claude/结构和CLAUDE.md |
| /sdc.clarify | 澄清功能、评估范围、建议拆分 |
| /sdc.upgrade | 更新代理/命令到最新模板，不触及规格 |
| /sdc.help | 完整工作流参考和SDD介绍 |

## 为什么选择Claude Code？

SDC专门为Claude Code构建，这不是限制而是特性。它使用Claude Code的原生代理系统（`.claude/agents/`）和斜杠命令（`.claude/commands/`）来强制执行SDD流程。

这种深度集成使得：
- 工作流与Claude Code的交互模式无缝融合
- 可以利用Claude Code的上下文管理能力
- 代理切换和命令调用自然流畅

## 总结与思考

SDC代表了一种重要的AI辅助编程范式转变：从"让AI写代码"到"让AI遵循工程流程"。它承认AI不是万能的，需要通过结构化的流程来引导其能力发挥到正确方向。

规格驱动开发不是什么新概念——它在传统软件开发中已经存在多年。SDC的创新之处在于将其与AI编程助手深度集成，使得这一最佳实践在AI时代变得更加易于执行。

对于希望提升AI编程助手使用效果的团队，SDC提供了一个经过深思熟虑的框架。它可能增加一些前期开销，但对于复杂功能开发，这种投资通常会通过减少返工和提高质量而得到回报。

正如项目文档所说："当规格被批准后，后端和前端独立阅读同一份规格，得出一致的结果。没有错位，没有重写。"这正是我们在AI辅助开发中所追求的可预测性和可靠性。