告别 Vibe Coding 混乱：SDD 规范驱动开发，从文档先行到 AI 协作的完整方法论
第一天用 AI 写代码效率提升 10 倍，第二周开始返工，第一个月陷入自我怀疑------这是无数 Vibe Coding 实践者的真实写照。SDD（Spec-Driven Development，规范驱动开发） 是解决这个问题的全新范式：先写文档，再写代码。借鉴建筑业的"不画蓝图不盖房"和 Stephen Covey 的"以终为始"思想，SDD 坚持所有事物都要经过两次创造------心智创造（文档）和物理创造（代码）。本文从一个浏览器翻译插件的真实项目出发，完整拆解 SDD 从需求分析到代码生成的全流程。建议收藏后动手实践。
一、Vibe Coding 的甜蜜与苦涩
1.1 什么是 Vibe Coding？
css
Vibe Coding（氛围编程）：
→ AI Coding Agent 交互面板吸引我们不停地给 AI 下任务
→ "帮我做一个用户认证系统" → AI 瞬间生成 2000 行代码
→ 上头了，沉浸其中，停不下来
主流 AI 编程工具：
┌─────────────────────────────────────────────────┐
│ claude code → Anthropic 出品，终端 Agent │
│ codex → OpenAI Agent │
│ Deepseek → harness 插件 │
│ Cursor → AI 原生编辑器 │
│ Trae → AI IDE │
│ Copilot → GitHub 辅助编程 │
└─────────────────────────────────────────────────┘
每一个都声称 10 倍效率提升
第一天：效率飞升，沉浸式体验
第二周：开始返工（AI 猜的上下文不对）
第一个月：陷入自我怀疑1.2 Vibe Coding 的三大陷阱
arduino
┌──────────────────────────────────────────────────────────┐
│ Vibe Coding 的三大陷阱 │
│ │
│ 陷阱一：上下文缺失 │
│ ┌────────────────────────────────────────────┐ │
│ │ "帮我做一个用户认证系统" │ │
│ │ → 用什么框架？NestJS？Python？Java？ │ │
│ │ → 用什么数据库？MySQL？MongoDB？ │ │
│ │ → 用 Mock 还是真实后端？ │ │
│ │ → JWT 还是 Session？ │ │
│ │ AI 不知道这些 → 自己猜 → 猜错了 → 返工 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 陷阱二：会话历史丢失 │
│ ┌────────────────────────────────────────────┐ │
│ │ 聊天窗口的上下文 → 一关窗口可能就没了 │ │
│ │ 没有持久化 → AI 失去记忆 │ │
│ │ 新会话重新猜 → 之前的决策全丢了 │ │
│ │ → 幻觉加剧 → 代码越来越乱 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 陷阱三：每一轮失败都在消耗 │
│ ┌────────────────────────────────────────────┐ │
│ │ 等待 AI 生成 → 时间消耗 │ │
│ │ Token 消耗 → 金钱消耗 │ │
│ │ 代码不对 → 改了又改 → 越改越乱 │ │
│ │ 看上去跑得起来 → 后面一堆的麻烦 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 根本原因： │
│ 不是 AI 能力不行，是我们给大模型的上下文不够 │
└──────────────────────────────────────────────────────────┘1.3 Vibe Coding vs SDD 对比
arduino
Vibe Coding（氛围编程）：
"帮我做一个 XX"
→ 直接跳到代码（第二次创造）
→ 跳过了第一次创造（设计）
→ AI 猜 → 幻觉 → 返工
SDD（规范驱动开发）：
"先写 proposal.md 需求文档"
→ 第一次创造：在大脑中设计一遍，用文档落地
→ "再根据规范写代码"
→ 第二次创造：AI 按文档驱动生成代码
→ 有据可依 → 可追溯 → 可回退
SDD 解决 Vibe Coding 问题的核心：
→ 文档是 Coding Agent 的上下文
→ 文档可持久化（git 跟踪）
→ 文档可共享、可迭代
→ AI 不需要猜，按文档执行二、SDD 的理论基础：两次创造原则
2.1 以终为始
sql
Stephen Covey《高效人士的7个习惯》
第二个习惯：以终为始（Begin with the End in Mind）
核心思想：
"所有事物都经过两次创造------
先是心智创造，然后是物理创造"
┌──────────────────────────────────────────────────┐
│ 两次创造原则 │
│ │
│ 第一次创造（心智创造） │
│ → 在大脑中设计一遍 │
│ → 花时间想清楚要做什么、怎么做 │
│ → 动手之前先有个样子 │
│ → 用各种文档落地（proposal / design / task） │
│ │
│ 第二次创造（物理创造） │
│ → 根据规范真正地执行 │
│ → AI 按文档驱动写代码 │
│ → 有据可依，不需要猜 │
└──────────────────────────────────────────────────┘
类比：
→ 不画蓝图就不盖房
→ 不写商业计划就不创业
→ 不写需求文档就不写代码
Vibe Coding 的问题：
→ 聊天窗口的诱惑让我们跳过第一次创造
→ 直接进入第二次创造（写代码）
→ 没有设计 → AI 猜 → 返工2.2 SDD 的定义
ini
SDD = Spec-Driven Development（规范驱动开发）
Spec → 规范文档
Driven → 驱动（文档驱动代码）
Development → 开发新范式（AI 协作范式）
核心理念：文档即是代码
┌──────────────────────────────────────────────────┐
│ 当代码生成成本越来越低， │
│ 真正稀缺的不是代码， │
│ 而是清晰、可执行、可验证的意图。 │
│ │
│ 这个意图由 SDD 来设计和表达。 │
└──────────────────────────────────────────────────┘
SDD 的定位：
→ 不是新工具，是新的工作方式
→ 不是可选项，是必选项
→ 是工程师的主要工作内容
→ 代码生成交给 AI，人专注于规范设计2.3 创业类比
arduino
Vibe Coding 就像不写商业计划就创业：
→ 埋头干 → 死得越快
→ 没有方向 → 每天都在改方向
→ 没有 MVP 定义 → 不知道什么时候算"完成"
SDD 就像先写商业计划再创业：
→ 花时间想清楚做什么、为什么做、怎么做
→ 定义 MVP（最小可行性产品）
→ 有方向 → 有里程碑 → 可验收
→ 每一步都有文档记录 → 可追溯三、SDD 的三份核心文档
3.1 文档全景
┌──────────────────────────────────────────────────────────┐
│ SDD 三份核心文档 │
│ │
│ ┌──────────────┐ │
│ │ proposal.md │ 需求文档 │
│ │ （是什么） │ → 头脑中这个系统应该是什么样 │
│ │ │ → 满足什么需求 │
│ │ │ → MVP 定义（最小可行性单元） │
│ │ │ → 不做什么（边界明确） │
│ └──────┬───────┘ │
│ │ │
│ ┌──────▼───────┐ │
│ │ design.md │ 技术架构文档 │
│ │ （怎么做） │ → 怎么实现 │
│ │ │ → 技术选型（框架、库、工具） │
│ │ │ → 技术难点分析与解决方案 │
│ │ │ → 架构图、数据流 │
│ └──────┬───────┘ │
│ │ │
│ ┌──────▼───────┐ │
│ │ task.md │ 任务拆解文档 │
│ │ （怎么做） │ → 先干什么、再干什么 │
│ │ │ → 什么可以并行干 │
│ │ │ → 任务依赖关系 │
│ │ │ → 验收标准 │
│ └──────────────┘ │
│ │
│ 三份文档完成第一次创造（心智创造） │
│ 代码是第二次创造（AI Agent 执行） │
└──────────────────────────────────────────────────────────┘3.2 proposal.md：需求文档
proposal.md 回答的问题：
做什么？
→ 清晰定义要做什么
→ 一句话说清楚核心功能
为什么做？
→ 解决什么痛点
→ 目标用户是谁
→ 用户场景是什么
MVP 是什么？
→ 最小可行性产品
→ 非程序员也能 Vibe Coding 的最小单元
→ 详细的举例
→ 返回格式
不做什么？
→ 边界明确
→ 只生成文档，其他不要做
→ 不是新项目时要阅读已有代码
需求文档的价值：
→ 可记录：关了窗口不会丢
→ 可共享：团队对齐认知
→ 可验收：AI 生成的代码可以对照文档验收
→ 不能走过场：是程序开发的关键流程3.3 design.md：技术架构文档
css
design.md 回答的问题：
怎么实现？
→ 技术选型（直接关系到项目成败）
→ 一个正确的选型，能让后续开发事半功倍
→ 反之，选错了会陷入泥潭
技术难点是什么？
→ 网页主要内容怎么提取？→ 搜一下 LLM 工具和分析能力很强
→ AI 模型怎么配置？→ OpenAI 兼容方式，可切换 Qwen 等
→ Markdown 格式怎么呈现？→ npm marked（通用库）
架构师的认知：
→ 和 skill、Claude Code 多聊几次
→ 快速成长为架构师
→ 利用 LLM 的搜索和分析能力3.4 task.md：任务拆解文档
task.md 回答的问题：
先干什么？
→ 任务排序
→ 依赖关系分析
什么可以并行干？
→ 独立任务并行化
→ 提升开发效率
示例任务拆解：
① 创建项目和 Git 仓库
② 配置 manifest.json
③ 实现内容提取脚本
④ 对接 AI 翻译 API
⑤ Markdown 渲染与一键复制
⑥ 界面布局与流式展示
⑦ 打扫：移除冗余代码
task.md 的价值：
→ AI Agent 可以按步骤逐步执行
→ 每步可验收
→ 出错了可以回退到某一步四、实战案例：浏览器翻译插件
4.1 项目概述
项目：md-wx-chrome-extensions（浏览器翻译插件）
核心功能：
→ 在浏览英文网页时
→ 一键提取文章核心内容
→ 调用 AI 模型翻译
→ 翻译结果以 Markdown 格式呈现
→ 一键复制
目标用户：
→ 大网红、公众号作者、md-wx 用户
技术关键词：
→ Chrome Extension（浏览器插件）
→ AI 模型可配置（DeepSeek、Qwen...）
→ npm marked（Markdown 渲染）
→ 流式输出界面4.2 SDD 实战流程
css
┌──────────────────────────────────────────────────────────┐
│ SDD 实战流程（翻译插件案例） │
│ │
│ 第一步：文档先行 │
│ ┌────────────────────────────────────────────┐ │
│ │ 编写 proposal.md │ │
│ │ → 需求：一键提取 + AI 翻译 + Markdown │ │
│ │ → MVP：先做核心翻译功能 │ │
│ │ → 不做什么：不做多语言、不做 PDF 导出 │ │
│ │ → 返回格式：Markdown 文本 │ │
│ │ → 只生成文档，其他的不要做 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 第二步：技术调研 │
│ ┌────────────────────────────────────────────┐ │
│ │ 和 Claude Code / skill 聊一聊 │ │
│ │ → 网页内容提取的难点 │ │
│ │ → AI 模型可配置方案 │ │
│ │ → Markdown 渲染方案 │ │
│ │ → 得到解决方案 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 第三步：技术架构设计 │
│ ┌────────────────────────────────────────────┐ │
│ │ 编写 design.md │ │
│ │ → Chrome Extension 架构 │ │
│ │ → content script 提取内容 │ │
│ │ → background script 调用 AI │ │
│ │ → popup 界面展示 │ │
│ │ → OpenAI 兼容方式切换模型 │ │
│ │ → marked 渲染 Markdown │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 第四步：任务拆解 │
│ ┌────────────────────────────────────────────┐ │
│ │ 编写 task.md │ │
│ │ → ① 项目初始化 + Git 仓库 │ │
│ │ → ② manifest.json 配置 │ │
│ │ → ③ 内容提取脚本 │ │
│ │ → ④ AI 翻译 API 对接 │ │
│ │ → ⑤ Markdown 渲染 + 复制功能 │ │
│ │ → ⑥ 界面按钮布局（流式） │ │
│ │ → ⑦ 打扫：移除冗余代码 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 第五步：AI 驱动代码生成 │
│ ┌────────────────────────────────────────────┐ │
│ │ 把三份文档喂给 Coding Agent │ │
│ │ → 按文档执行，不猜 │ │
│ │ → 每步生成后对照文档验收 │ │
│ │ → 不对就回退重生成 │ │
│ │ → 通过就 git commit │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 第六步：新需求迭代 │
│ ┌────────────────────────────────────────────┐ │
│ │ 更新文档 → 保持文档和代码一致性 │ │
│ │ → git 跟踪文档版本和代码版本 │ │
│ │ → 文档驱动新功能开发 │ │
│ │ → 打扫：移除冗余代码 │ │
│ └────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘五、版本控制：Vibe Coding 的安全网
5.1 Git 作为 AI 代码的验收工具
sql
版本控制的重要性：
→ AI 生成的代码需要即时验收
→ Vibe Coding 可追溯、可回退
→ AI 出现幻觉时可以快速回退
Git 是 SDD 的安全网：
→ 文档版本 + 代码版本 → git 统一管理
→ 每次验收通过 → commit
→ 不通过 → 回退
→ 新需求 → 迭代文档 → 迭代代码5.2 三级回退策略
sql
AI 生成代码出错了怎么办？三级回退：
┌──────────────────────────────────────────────────────────┐
│ 三级回退策略 │
│ │
│ 级别一：代码没到暂存区 │
│ → 直接丢弃这次修改 │
│ → git restore . │
│ → 最轻量，不影响历史 │
│ │
│ 级别二：代码到了暂存区，没提交 │
│ → 先移出暂存区 │
│ → git restore --staged . │
│ → 再丢弃修改 │
│ → git restore . │
│ → 两步操作 │
│ │
│ 级别三：已经提交了 │
│ → 回退到上一个提交 │
│ → git reset --hard HEAD^ │
│ → 最激进，历史被覆盖 │
│ │
│ 原则： │
│ → 每次让 AI 生成前先 commit │
│ → 生成后验收 → 通过就 commit / 不通过就回退 │
│ → 保持代码始终处于已知良好状态 │
└──────────────────────────────────────────────────────────┘
sql
Vibe Coding 的 Git 工作流：
开始
│
▼
git commit（保存当前良好状态）
│
▼
让 AI 生成代码
│
▼
验收代码
│
├── 通过 → git commit → 继续
│
└── 不通过 → 回退
│
├── 没到暂存区 → git restore .
├── 到了暂存区 → git restore --staged . → git restore .
└── 已提交 → git reset --hard HEAD^
│
▼
重新生成或调整文档六、AI 会话管理
6.1 开启新会话
arduino
管理 AI 会话：
为什么需要管理会话？
→ 一个会话聊太久 → 上下文膨胀 → AI 注意力分散
→ 不同任务用不同会话 → 上下文清晰 → AI 聚焦
开启新会话 = 新的上下文：
→ 把 proposal.md / design.md / task.md 喂给新会话
→ AI 获得干净的、完整的上下文
→ 不受之前会话的错误决策影响
SDD + 会话管理：
→ 文档是跨会话的"记忆"
→ 关了窗口不丢 → 文档还在
→ 新会话读文档 → 立即获得完整上下文
→ 这就是"文档即上下文"6.2 文档驱动的新会话流程
sql
┌──────────────────────────────────────────────────────────┐
│ 文档驱动的 AI 会话流程 │
│ │
│ 会话 1：编写需求文档 │
│ → "帮我写一个浏览器翻译插件的 proposal.md" │
│ → AI 生成 → 人审查 → 修改 → 定稿 │
│ → git commit proposal.md │
│ │
│ 会话 2：编写技术架构 │
│ → 喂入 proposal.md + "帮我写 design.md" │
│ → AI 根据需求设计架构 │
│ → 人审查 → 修改 → 定稿 │
│ → git commit design.md │
│ │
│ 会话 3：编写任务拆解 │
│ → 喂入 proposal.md + design.md + "写 task.md" │
│ → AI 根据需求+架构拆解任务 │
│ → 人审查 → 修改 → 定稿 │
│ → git commit task.md │
│ │
│ 会话 4+：按任务生成代码 │
│ → 喂入三份文档 + "执行 task 1" │
│ → AI 按文档生成代码 │
│ → 人验收 → 通过就 commit / 不通过就回退 │
│ → "执行 task 2" → ... │
│ │
│ 会话 N：新需求迭代 │
│ → 更新文档 → 新会话读文档 → 按文档执行 │
│ → 保持文档和代码一致性 │
└──────────────────────────────────────────────────────────┘七、需求分析的深度实践
7.1 需求分析三步法
css
┌──────────────────────────────────────────────────────────┐
│ 需求分析三步法 │
│ │
│ 第一步：清晰定义我们要做什么 │
│ → 一句话描述核心功能 │
│ → 浏览英文网页 → 提取核心 → AI 翻译 → Markdown │
│ │
│ 第二步：分析和调研 │
│ → 和 skill、Claude Code 多聊几次 │
│ → 网页内容提取的难点 │
│ → AI 模型配置方案 │
│ → Markdown 渲染方案 │
│ → 得到可行的技术方案 │
│ │
│ 第三步：花时间编写及验证需求 │
│ → 编写 proposal.md │
│ → 验证：是否清晰？是否可执行？是否可验收？ │
│ → MVP 定义：最小可行性单元 │
│ → 详细的举例和返回格式 │
│ → 明确不做什么 │
└──────────────────────────────────────────────────────────┘7.2 MVP 思维
ini
MVP = Minimum Viable Product（最小可行性产品）
产品经理思维 → 非程序员也能 Vibe Coding：
→ 先做最小核心功能
→ 验证可行性
→ 再迭代扩展
翻译插件的 MVP：
✅ 核心翻译功能
✅ Markdown 格式输出
✅ 一键复制
MVP 不做的：
❌ 多语言切换
❌ PDF 导出
❌ 历史记录
❌ 用户登录
MVP 的价值：
→ 快速验证想法
→ 减少返工范围
→ 每一步都有交付物
→ AI 可以按 MVP 范围生成代码7.3 技术架构设计的价值
css
技术架构设计直接关系到项目的成败：
正确的选型 → 事半功倍：
├── Chrome Extension API → 浏览器原生支持
├── content script → 页面内容提取
├── OpenAI 兼容方式 → 一个接口切换多个模型
├── npm marked → 通用 Markdown 渲染
└── 流式输出 → 用户体验好
错误的选型 → 陷入泥潭：
├── 用 Puppeteer 提取内容 → 太重，插件不需要
├── 用各模型原生 SDK → 切换困难
├── 自己写 Markdown 渲染 → 重复造轮子
└── 同步等待翻译 → 体验差
架构师的认知来源：
→ 和 skill 聊
→ 和 Claude Code 多聊几次
→ 上网搜，LLM 工具和分析能力很强
→ 快速成长为架构师八、新需求迭代与打扫
8.1 文档与代码的一致性
sql
新需求迭代流程：
收到新需求
│
▼
更新文档（先更新 proposal.md / design.md）
│ → 保持文档和代码的一致性
│ → 文档先变，代码后变
│
▼
git 跟踪文档版本和代码版本
│ → 文档版本和代码版本对应
│ → 可追溯某次代码变更对应的需求
│
▼
新会话读更新后的文档
│ → 获得最新上下文
│ → 按文档生成新功能代码
│
▼
验收 + commit
→ 文档和代码同步前进
原则：文档先于代码
→ 先改文档，再改代码
→ 文档是源头，代码是结果
→ 不允许"代码先行文档后补"8.2 打扫：移除冗余代码
c
打扫（Cleanup）：
记得移除冗余代码：
→ AI 生成的代码可能包含未使用的变量
→ 可能有注释掉的代码块
→ 可能有重复的逻辑
→ 可能有调试用的 console.log
打扫的时机：
→ 每个任务完成后
→ 新需求迭代前
→ 项目阶段验收时
打扫的价值：
→ 保持代码整洁
→ 减少 AI 的上下文噪音
→ 下一次生成代码更准确
→ 技术债务不积累九、SDD 工具生态
9.1 Spec-kit 框架
SDD 框架：Spec-kit
┌──────────────────────────────────────────────────┐
│ Spec-kit │
│ │
│ → SDD 的标准化工具框架 │
│ → 提供文档模板和结构 │
│ → 支持文档驱动的代码生成流程 │
│ → 文档版本管理 │
│ → 与 Coding Agent 集成 │
└──────────────────────────────────────────────────┘
当代码生成成本越来越低：
→ 真正稀缺的是清晰、可执行、可验证的意图
→ 由 SDD 设计和表达
→ Spec-kit 是承载这个意图的框架9.2 AI 编程工具定位
css
AI 编程工具的分类与定位：
┌──────────────────────────────────────────────────────┐
│ 全流程 Agent（SDD 全链路） │
│ ├── claude code → 终端 Agent，可读写文件 │
│ ├── codex → OpenAI Agent │
│ └── Trae → AI IDE，集成开发环境 │
│ → 适合 SDD 全流程：文档 + 代码 + Git │
│ │
│ 辅助编程（Copilot 类） │
│ └── Copilot → 代码补全、建议 │
│ → 适合在已有代码基础上补充 │
│ │
│ 插件增强 │
│ └── Deepseek harness → 插件形式 │
│ → 适合特定场景的 AI 增强 │
└──────────────────────────────────────────────────────┘
SDD 对工具的要求：
→ 能读写文档文件
→ 能读写代码文件
→ 能执行 Git 命令
→ 能理解文档并按文档生成代码
→ 支持多轮对话与上下文管理十、SDD 与传统开发范式对比
10.1 范式演进
arduino
┌──────────────────────────────────────────────────────────┐
│ 开发范式演进 │
│ │
│ ① 瀑布开发（传统） │
│ → 需求文档 → 设计文档 → 编码 → 测试 → 部署 │
│ → 文档厚重，周期长 │
│ → AI 时代前的主流 │
│ │
│ ② 敏捷开发 │
│ → 快速迭代，拥抱变化 │
│ → 文档轻量化，重沟通 │
│ → Sprint 周期，持续交付 │
│ │
│ ③ Vibe Coding（AI 时代） │
│ → 跳过文档，直接对话生成代码 │
│ → 效率飞升但混乱 │
│ → AI 猜 → 幻觉 → 返工 │
│ │
│ ④ SDD（规范驱动开发） │
│ → 先写文档（第一次创造） │
│ → 再让 AI 按文档写代码（第二次创造） │
│ → 文档可迭代、可追溯、可共享 │
│ → AI 有据可依，不猜 │
│ → 借鉴建筑业的"蓝图"思想和 Covey 的"以终为始" │
└──────────────────────────────────────────────────────────┘10.2 Vibe Coding vs SDD 核心对比
┌──────────────────────────────────────────────────────────┐
│ Vibe Coding vs SDD 核心对比 │
│ │
│ Vibe Coding SDD │
│ ───────────────────────────────────────── │
│ 起点 聊天对话 文档 │
│ 上下文 会话历史（易丢） 文档（持久化） │
│ AI 行为 猜（幻觉多） 按文档执行（准确） │
│ 可追溯 难（聊天记录散乱） Git 跟踪文档+代码 │
│ 可共享 难（对话无法共享） 文档可共享 │
│ 可验收 难（没有标准） 对照文档验收 │
│ 团队协作 困难（个人对话） 文档对齐认知 │
│ 新需求 重新聊（可能矛盾） 更新文档→更新代码 │
│ 回退 难（不知道回退到哪） Git 三级回退 │
│ 适合 小脚本/原型 任何规模项目 │
│ 创造次数 一次（跳过设计） 两次（设计+执行） │
└──────────────────────────────────────────────────────────┘十一、总结
11.1 知识体系图
css
SDD 规范驱动开发
│
├── 问题：Vibe Coding 的三大陷阱
│ ├── 上下文缺失 → AI 猜 → 返工
│ ├── 会话历史丢失 → AI 失去记忆 → 幻觉加剧
│ └── 每轮失败消耗时间 + Token
│ → 根本原因：给大模型的上下文不够
│
├── 理论：两次创造原则
│ ├── Stephen Covey《高效人士7个习惯》→ 以终为始
│ ├── 第一次创造：心智创造（文档落地）
│ ├── 第二次创造：物理创造（代码生成）
│ ├── Vibe Coding 跳过了第一次创造 → 问题根源
│ └── SDD 坚持两次创造 → 必选项
│
├── 三份核心文档
│ ├── proposal.md → 是什么（需求 + MVP + 不做什么）
│ ├── design.md → 怎么做（技术选型 + 架构 + 难点）
│ └── task.md → 怎么做（任务拆解 + 依赖 + 验收）
│
├── 实战流程
│ ├── 第一步：文档先行（proposal.md）
│ ├── 第二步：技术调研（和 AI 聊）
│ ├── 第三步：架构设计（design.md）
│ ├── 第四步：任务拆解（task.md）
│ ├── 第五步：AI 驱动代码生成（喂文档 → 生成 → 验收）
│ └── 第六步：新需求迭代（更新文档 → 更新代码）
│
├── 版本控制
│ ├── Git 作为安全网
│ ├── 三级回退策略
│ │ ├── 没到暂存区：git restore .
│ │ ├── 到了暂存区：git restore --staged . → git restore .
│ │ └── 已提交：git reset --hard HEAD^
│ └── 文档版本 + 代码版本统一管理
│
├── AI 会话管理
│ ├── 开启新会话 = 新的上下文
│ ├── 文档是跨会话的"记忆"
│ └── 文档驱动的新会话流程
│
├── 工具生态
│ ├── Spec-kit → SDD 标准化框架
│ ├── 全流程 Agent：claude code / codex / Trae
│ ├── 辅助编程：Copilot
│ └── 插件增强：Deepseek harness
│
└── 核心洞察
→ 当代码生成成本越来越低
→ 真正稀缺的是清晰、可执行、可验证的意图
→ 由 SDD 来设计和表达
→ 文档即是代码11.2 核心概念速查
| 概念 | 要点 |
|---|---|
| Vibe Coding | 氛围编程，直接对话生成代码，跳过设计阶段 |
| SDD | Spec-Driven Development，规范驱动开发，文档先行 |
| 两次创造 | 第一次心智创造（文档）+ 第二次物理创造（代码） |
| 以终为始 | Stephen Covey 7个习惯之二，所有事物先在脑中设计 |
| proposal.md | 需求文档：做什么、为什么、MVP、不做什么 |
| design.md | 架构文档：技术选型、难点方案、架构设计 |
| task.md | 任务文档：拆解步骤、依赖关系、验收标准 |
| MVP | Minimum Viable Product，最小可行性产品 |
| 三级回退 | git restore / restore --staged / reset --hard HEAD^ |
| 文档即上下文 | 文档是 AI Agent 的跨会话记忆 |
| Spec-kit | SDD 的标准化工具框架 |
| 打扫 | 移除冗余代码，保持代码整洁 |
11.3 一句话总结
SDD 的本质是"以终为始"------先写文档（第一次创造），再让 AI 按文档生成代码（第二次创造）。Vibe Coding 的问题在于跳过了第一次创造，直接进入第二次创造，导致 AI 靠猜生成代码。当代码生成成本越来越低，真正稀缺的不是代码，而是清晰、可执行、可验证的意图------这个意图由 SDD 来设计，由文档来承载。文档即是代码，规范驱动一切。
如果这篇文章对你有帮助，欢迎点赞 和收藏！