引言：当 AI 写代码成为日常
2024 年，AI 辅助编程工具迎来了爆发式增长。Cursor、GitHub Copilot、Claude Code 等工具让开发者体验到了前所未有的效率——输入一段自然语言描述，几百行结构完整的代码就像瀑布一样倾泻而出。
这种仅凭直觉、对话和模糊意图驱动的开发模式，被 OpenAI 创始工程师 Andrej Karpathy 在 2025 年 2 月命名为 Vibe Coding（氛围编程）。它的核心主张很激进：忘掉代码的存在，用自然语言描述你想要什么，让 AI 全权处理。如果报错了，就把错误信息扔给 AI，让它自己修。
听起来很美好，对吧？
但现实往往比想象更骨感。
Vibe Coding 的“三个月墙”
社区观察到一个反复出现的模式，被形象地称为 “三个月墙” ：
- 第 1-3 个月（兴奋期） ：AI 太厉害了！一天搞定一个功能！项目飞速推进。
- 第 4-9 个月（平台期） ：为什么新功能总是破坏旧功能？修一个 bug 引出三个新 bug。
- 第 10-15 个月（衰退期） ：这坨代码没人能维护了，不如重写。
为什么会这样？因为 Vibe Coding 本质上是 零上下文的编程。
当项目只有几百行代码时，AI 的上下文窗口能装下全部代码，它的推断和猜测大概率是对的。但当项目膨胀到几万行、几十个模块时，AI 只能基于局部信息做决策——而这些决策往往和其他模块冲突。
数据也证实了这一点。Veracode 在 2025 年对 100 多个模型、80 个编码任务进行测试后发现：约 45% 的 AI 生成代码包含了 OWASP Top 10 级别的安全缺陷。GitClear 对 2.11 亿行代码的分析则显示，AI 辅助编程时代的代码重复率增长了 4 倍——AI 不擅长抽象，更擅长“复制粘贴”。
问题出在哪里？大模型本质上是概率预测引擎。没有硬性约束的概率输出，必然走向工程的混沌。
SDD：给 AI 编程装上“导航”
这就是 SDD（Spec-Driven Development，规范驱动开发） 登场的背景。
SDD 是一种将 “规范（Specification）” 作为软件开发核心驱动力的工程范式。它的核心哲学可以概括为一句话：意图即真相（Intent is the Source of Truth） 。
翻译成大白话就是：先想清楚要做什么、写下来，再让 AI 去实现。
在传统开发中，代码是第一公民——先写代码，后补文档，需求文档只是“参考材料”。在 SDD 中，规格是第一公民——先写规格，后生成代码，规格是“可执行契约”。
SDD 的核心理念是将传统软件开发生命周期中那些被验证有效的实践——需求分析、系统设计、任务分解——进行压缩和自动化，并将其作为 AI 生成代码的强制前置步骤。
意图（Intent）→ 规格（Spec）→ 计划（Plan）→ 执行（Execution）
在动手写代码之前，先确保：
研究数据显示，人工精炼的 Spec 可以将 LLM 的代码错误减少 50% ——不是因为 AI 变聪明了，而是因为好的 Spec 消除了 AI 的“猜测空间”。
SDD 的核心文档体系
SDD 通过三份核心文档完成“第一次创造”（心智创造），然后由 AI 完成“第二次创造”（代码实现）。
1. 需求文档（Proposal.md / PRD）
回答 “做什么” 和 “为什么做” 。
这份文档定义软件应该做什么、为什么做，而不是怎么做。它包含用户需求、验收标准和约束条件，成为所有后续工作的权威来源。
2. 技术设计文档（Design.md / Plan.md）
回答 “怎么做” 。
确定满足规范的技术方法——架构选型、技术栈、设计约束。这份文档是技术实现的蓝图。
3. 任务拆解文档（Tasks.md）
回答 “先做什么、后做什么、什么可以并行” 。
这三份文档加在一起，构成了 SDD 的完整规范体系。规范不是写完就丢的“开工前的废纸”，而是驱动 AI 代码生成的“活文件” 。
Spec Kit：GitHub 的 SDD 工具包
理念有了，怎么落地？
GitHub 开源了 Spec Kit——一个规格驱动开发的工具包。它的核心主张只有一句话：让规格成为可执行的东西，直接生成可工作的实现，而不是写完就丢的脚手架。
Spec Kit 通过一组结构化的斜线命令（Slash Commands）来驱动开发流程：
| 命令 | 作用 | 产出物 |
|---|---|---|
/speckit.constitution | 建立项目治理原则与开发规范 | constitution.md |
/speckit.specify | 定义要构建什么（需求 + 用户故事） | spec.md |
/speckit.clarify | 通过结构化提问澄清模糊点 | 需求校验 |
/speckit.checklist | 生成质量检查清单 | 检查清单 |
/speckit.plan | 选定技术栈、产出技术实现计划 | plan.md |
/speckit.tasks | 把计划拆成可执行任务清单 | tasks.md |
/speckit.analyze | 跨产物一致性与覆盖度分析 | 分析报告 |
/speckit.implement | 按计划执行所有任务，生成代码 | 源代码 |
整个流程可以概括为四个阶段：
指定（Specify）→ 规划（Plan）→ 任务（Tasks）→ 实施（Implement）
安装和使用 Spec Kit 也很简单。首先通过 uv 安装 CLI 工具：
bash
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
然后初始化项目：
bash
specify init my-project --integration copilot
cd my-project
初始化后，你的 AI 编程助手（如 GitHub Copilot、Claude Code、Gemini CLI 等）就能识别上述 /speckit.* 命令了。
接下来就可以按顺序执行命令：先建立项目章程（/speckit.constitution），再定义需求规格（/speckit.specify），然后制定技术计划（/speckit.plan），拆解任务（/speckit.tasks），最后让 AI 执行实现（/speckit.implement）。
Spec Kit 的设计思路很清晰：把“结构化开发指令”做成了一套可加载的技能。你不需要自己造轮子，GitHub 已经把标准化的 SDD 流程打包好了。
SDD vs Vibe Coding：一场正面交锋
| 维度 | Vibe Coding | SDD |
|---|---|---|
| 核心假设 | AI 能理解你的意图 | AI 需要明确的规格才能正确执行 |
| 启动速度 | 极快 | 较慢（需要先写 Spec） |
| 可维护性 | 差（无文档、无约束） | 好（Spec 即文档） |
| 可协作性 | 差（只有作者知道“氛围”） | 好（Spec 是共享语言） |
| 安全性 | 45% 代码含安全漏洞 | Spec 约束安全边界 |
| 适用规模 | 小项目（<1000 行） | 中大型项目 |
| 天花板 | 三个月墙 | 取决于 Spec 体系质量 |
但这两者并非对立关系。
Vibe Coding 和 SDD 更像是一个光谱的两端。对于一个验证想法的周末项目，写完整的 Spec 可能过于工程化。对于一个要长期维护的生产系统，纯 Vibe Coding 则像是在慢性自杀。
更务实的选择是 混合策略：
- 原型验证、个人工具脚本 → 可以用 Vibe Coding 快速试错
- 需要长期维护、多人协作的项目 → 应该走 SDD 流程
总结：SDD 的真正价值
SDD 不是要消灭 Vibe Coding，而是为 AI 编程增加工程纪律。
在代码生成成本越来越低的今天，真正稀缺的不是写代码的能力，而是 清晰、可执行、可验证的意图。SDD 正是将这种意图文档化、结构化、可执行化的方法论。
第一，品质与速度的平衡。 结合 AI 的自动化能力与严谨的规划流程，既提升生产效率，又保障系统架构质量。
第二，知识的可传承性。 通过活文档与 Git 版本控制，每一次修改都有明确的脉络可循，方便团队协作与后续维护。
第三，角色的重新定位。 工程师从“写代码的人”转变为“意图设计者”和“架构把关人”。
回到开头的问题：AI 写代码很快，但如何确保它写的代码是对的、安全的、可维护的？
SDD 给出的答案是：先想清楚，再让 AI 动手。
这可能是在 AI 编程时代，工程师最需要掌握的新技能。
