Vibe Coding 之 SDD 工作流：让 AI 按规范自动写代码

最近在 D2 大会上听到一个概念叫 SDD（Spec-Driven Development）规范驱动开发，觉得非常有启发。简单说就是：你写规范，AI 写代码。今天来聊聊这套工作流。

一、SDD 是什么？

SDD 的核心思想可以用一句话概括：实现一次”权力的反转”。

在传统开发中，文档服务于代码——代码是主角，文档是附属品。而在 SDD 中，代码服务于规范——那份结构化的、无歧义的规范，取代了代码，成为项目唯一的”真理之源”（Single Source of Truth）。

代码，降级为这份”真理之源”在某个特定技术栈下的自动渲染产物。

这意味着：

• 维护软件的核心，从”修改代码”，变成了”演进规范”
• 调试 Bug 的核心，从”修复错误代码”，变成了”修正产生错误代码的规范或方案”
• 技术重构的核心，从”大规模迁移代码”，变成了”基于同一份规范，生成一个全新技术栈的实现”

二、SDD 工作流的四个阶段

第一阶段：意图定义（spec.md）

目标：澄清并固化”做什么”（WHAT）和”为什么做”（WHY）。

输入：高层级、模糊的自然语言想法。

核心活动：人机协作进行头脑风暴，挖掘边缘场景，澄清模糊地带，定义验收标准。

输出：spec.md 需求规范。这份文档的核心是完全与技术实现解耦，它只关心用户故事、功能需求和成功标准。

实战示例：

# spec.md — issue2md 工具需求规范

## 用户故事
作为开发者，我希望输入一个 GitHub Issue/PR/Discussion 的 URL，
它就能自动将其转换为 Markdown 文件，方便归档和知识管理。

## 功能性需求
1. 支持 Issue、PR、Discussion 三种类型
2. 自动识别 URL 类型，无需手动指定
3. 包含标题、作者、创建时间、状态、主楼内容、所有评论
4. 可选：Reactions 统计、用户主页链接

## 非功能性需求
1. 只支持公有仓库
2. Token 只通过环境变量 GITHUB_TOKEN 获取
3. 默认输出到 stdout

第二阶段：技术规划（plan.md）

目标：决定”如何做”（HOW）。

输入：spec.md 和开发者提供的技术栈约束。

核心活动：AI Agent 基于规范，进行技术选型、架构设计、模块划分、API 契约定义。

输出：plan.md（技术方案）及其附属文档（如 data-model.md、api-spec.json）。

第三阶段：任务分解（tasks.md）

目标：将”如何做”分解为”一步步怎么做”（ACTIONS）。

输入：plan.md 及其所有附属设计文档。

核心活动：AI Agent 分析技术方案，将其拆解成一系列具体的、原子化的、可执行的开发任务。识别任务之间的依赖关系和可并行点。

输出：tasks.md（任务列表）。关键特性：任务支持并行标记 [P]，为多 Agent 协同工作提供可能。

第四阶段：自动化实现

目标：完成所有任务，生成最终产物。

输入：tasks.md。

核心活动：AI Agent 严格按照 tasks.md 的指令，逐一执行任务，包括创建文件、编写代码、运行测试等。

输出：可运行的软件代码、测试用例、文档等。

三、为什么 SDD 是 AI 原生开发的未来？

3.1 解决 AI 的”模糊性”难题

大模型本质上是基于统计的，对模糊指令的理解存在不确定性。SDD 通过结构化的规范，将模糊的自然语言，转化为 AI 可以精确执行的”机器语言”，极大提升了输出的可靠性。

你不再需要祈祷 AI “猜对”你的心思，而是通过一份严谨的规范来精确地”编程”AI 的行为。

3.2 加速软件”迭代”循环

在传统模式下，需求变更意味着昂贵的人工代码修改成本。在 SDD 模式下，“业务逻辑”的核心被固化在更高层次的 spec.md 中。当需求变化时，我们只需修改规范，然后快速地”重新编译”整个实现。

软件开发的迭代速度，从”周/天”级别，提升到了”小时/分钟”级别。

3.3 释放 AI 的”并行”潜力

tasks.md 中的并行标记 [P]，为多个 AI Agent 协同工作，或单个 AI Agent 并发执行任务提供了可能。这突破了人类开发者线性工作的瓶颈。

3.4 创造真正的”活文档”

当文档（规范）成为驱动代码生成的唯一源头时，“文档与代码不一致”这个困扰我们几十年的问题，便被彻底根除了。规范即文档，文档即代码，代码即实现。

四、实战：用 Claude Code 跑 SDD 工作流

Step 1：启动会话与角色设定

claude

启动后，Claude Code 已经自动加载了 CLAUDE.md 和 constitution.md。

关闭 Plan Mode（按 Shift + Tab 切换），因为我们需要多轮对话来澄清需求，而不是让 AI 急于产出结果。

Prompt 1：角色设定

你好！现在的任务是：我们要从零开始设计并实现 issue2md 工具。

你现在不仅是资深的Go工程师，更是一位经验丰富的产品经理。
我有一个初步的想法，需要你通过向我提问，帮助我澄清需求、
挖掘边缘场景，最终目标是共创一份高质量的 spec.md。

我的初步想法是：做一个命令行工具，输入一个GitHub Issue/PR/Discussion的URL，
它就能自动将其转换为Markdown文件。

请开始你的提问。

Step 2：需求澄清与头脑风暴

AI 会提出一系列高质量的问题，帮你把模糊想法”具象化”。你需要回答这些问题，给出清晰的边界。

关键原则：

• 做减法：明确不要 PR diff、不要下载图片、不要自定义模板
• 明确 Flag：确定哪些功能是可选的
• 安全优先：Token 只通过环境变量获取，不要提供 --token 参数

Step 3：生成 spec.md

回答完所有问题后，给出最终指令：

现在，所有的需求都已清晰。

请扮演"需求编译器"，执行以下操作：
1. 在项目根目录下创建 specs/001-core-functionality/ 目录
2. 创建 spec.md 文件，包含：
   - 用户故事
   - 功能性需求
   - 非功能性需求
   - 验收标准
   - 输出格式示例

请直接执行工具生成文件。

Step 4：生成目录结构

基于这份 spec.md 和 constitution.md，请为这个功能设计详细的包结构。
请调用 Bash 工具，创建以下目录：
- cmd/issue2md/
- internal/{github,parser,converter,cli,config}

到这里，你就有了清晰的规范和标准的项目骨架。接下来可以进入 plan.md → tasks.md → 自动化实现的流程。

五、SDD vs 传统开发

维度	传统开发	SDD
核心产物	代码	规范文档
需求变更	修改代码	修改 spec.md
技术重构	迁移代码	基于规范重新生成
文档维护	手动同步	规范即文档
并行开发	人类线性工作	AI 多 Agent 并行
迭代速度	周/天	小时/分钟

六、总结

SDD 不仅仅是一种新方法，它是与 AI Agent 能力天然契合的核心引擎。它将开发者从繁琐、重复的实现细节中解放出来，让我们能将更多的智慧和精力，投入到更高价值的业务建模、架构设计和工作流优化中去。

核心要点：

1. 规范是真理之源 — 代码只是规范的一个编译产物
2. 四阶段流程 — spec.md → plan.md → tasks.md → 自动化实现
3. 人机协作 — 人负责需求澄清和验收，AI 负责技术规划和代码实现
4. 活文档 — 规范即文档，彻底解决文档与代码不一致的问题

如果你还没试过用 AI 跑 SDD 工作流，强烈建议从一个小项目开始体验。一旦习惯了这种开发范式，你可能就不想回到传统模式了。

---

参考资料：

• D2 2026 大会：《LM辅助编程的短期效率红利与长期技术债陷阱》- 茹炳晟
• D2 2026 大会：《Skills》- 宝玉