AI 写代码越来越快了，但"看起来对，跑起来废"的场景也越来越多了。SDD 不是又一个银弹口号，而是从根上回答了这个问题：代码写得快没用，代码写得对才有用。而"对"的标准，从来不藏在代码里。
引言：效率陷阱
2025 年，AI 编程工具大爆发。Cursor、Copilot、Claude Code、Windsurf------一个 prompt 下去，几十行甚至几百行代码秒出。
然后呢？
- "功能跑通了，但逻辑不是我想要的"
- "改了三次 prompt，AI 还是歪到同一个坑里"
- "三个月后回来看代码，完全不知道当初为什么这么写"
- "需求稍微变一下，整个模块基本要重写"
这不是 AI 不够强。这是你给它的输入------一段模糊的 prompt------本身就不足以承载一个精确的系统意图。
AI 只是在忠实地执行模糊。模糊进去，偏差出来。
SDD（Specification-Driven Development，规范驱动开发）解决的正是这个问题。但我不想堆概念，我用因果链给你拆开------从上一步，必然推到下一步。拿掉任何一节，后面的都站不住。
第一节：LLM 的底层原理------为什么 AI 写代码天然是"发散"的？
要理解 SDD，先得理解它要对抗的对手到底是什么。
LLM 的原理很简单：自回归语言模型，逐 token 预测下一个词。 给它一段上下文，它计算"下一个最可能出现的 token 是什么"，吐出来，拼到上下文后面，再预测下一个。循环往复，直到输出结束。
这里有一个关键属性，很多人忽略了------LLM 的输出天然是概率分布上的"发散"过程。
LLM 不是"推理"，不是"设计"，不是"架构"。LLM 就是"根据上下文猜下一个词"。你给它多少约束，它就收敛多少；你给它多少自由度，它就放飞多少。
打个比方：你让一个人"画点什么"，他可能画只猫、画座山、画个三角形------纯粹随机。但你给他一张参考照片说"照着这个画"，他就能画出你想要的。区别只有一个：参考信息的精确度和约束力。
这就是 LLM 编程的真正困境：
- 你给一句"帮我写登录" → LLM 在几十亿参数的概率空间里，对"登录"这个概念的自由联想可以跑出无穷多种结果。JWT？Session？OAuth？数据库用哪个？前端用什么框架？每一个"没说的"维度，都是 LLM 的一个发散维度。
- 维度越多，发散越严重。一个需求有 N 个未定义的维度，LLM 的输出空间就是 N 维概率分布的笛卡尔积。你能撞对一次，撞不对两次。
所以 Vibe Coding 的本质问题不是"运气不好"，而是把收敛的责任全部丢给了 LLM 的概率分布，自己只给了一个最弱的约束信号。
第二节：因为 LLM 天然发散，所以需要提示词来"收敛"
既然 LLM 是发散引擎，那要让它的输出不跑偏，只有一个办法：加约束。
提示词（prompt）就是这个约束。你每多说一句话------"用 React + TypeScript""状态管理用 Zustand""登录接口走 POST /api/auth/login"------你就是在人为压缩 LLM 的概率空间，把它的输出方向往你想要的区域"掰"。
这是一个从发散到收敛的过程：
无约束："写个登录" → 无穷多种可能
有约束："用 React+TS，JWT 认证，Zustand 状态，POST /api/auth/login" → 缩小到几十种
强约束：写一份规范文档，定义所有边界条件和验收标准 → 收敛到 1 种提示词的本质，就是收敛信号。 你给 LLM 的所有信息，本质上都是在做一件事：用你的意图去压制它的概率发散。
第三节：SDD 就是提示词的极致精细化
这里到了一个关键的认知跃迁------
SDD 跟 prompt engineering 不是两件事。SDD 就是 prompt engineering 的终极形态。
| 层级 | 约束形式 | 收敛力 |
|---|---|---|
| 零级 | "帮我写个功能" | ★☆☆☆☆ |
| 一级 | "用 XX 技术栈，做 YY 功能，要有 ZZ" | ★★☆☆☆ |
| 二级 | 结构化 prompt（角色+上下文+任务+格式） | ★★★☆☆ |
| 三级 | 多轮对话迭代 refine | ★★★★☆ |
| 四级（SDD） | spec.md + plan.md + tasks.md，规范性文档体系 | ★★★★★ |
区别在哪？
- 普通 prompt 是一次性约束------你说完，LLM 生成，结束了。下次再说可能约束就不一样了。
- SDD 把约束结构化、持久化、可迭代、可验证------不是"这次你给我收敛"，而是"任何时候、任何人、任何 AI，拿到这份规范，都必须收敛到同一个方向。"
SDD 并没有发明什么全新概念，它只是把 prompt engineering 这件事推到了极致。 把"几句话"变成"一套文档体系"，把"一次性"变成"持续迭代"，把"凭感觉"变成"可验证"。这就是 SDD 的全部秘密。
SDD = 把 prompt 写成一个可以在团队间传递、被 AI 严格对齐、能自动化验证的结构化规范体系。
第四节：意图与执行之间，缺一座桥------SDD 的桥怎么搭
人类的想法是模糊、隐含、动态的。你脑子里有个"登录功能"的样子，但你没法用一段 prompt 把它精确传达给 AI。
机器的执行是精确、显式、静态的。你给什么，它做什么，一字不差。
这中间缺一种东西------一种能把"脑子里想的"变成"机器能精确执行的"表达形式。
传统开发没有这个问题，因为代码是人一句一句写的，人在写的过程中自然完成了"意图→代码"的翻译。但 AI 跳过了这个翻译过程------你丢一句话，它直接出代码。翻译发生在 AI 的"黑箱"里，你控制不了。
这就是 AI 编程的第一性矛盾：不是 AI 不够聪明，而是意图的表达通道太窄。
第五节：因为矛盾没解决，所以出现了 Vibe Coding 的四大痛点
Vibe Coding（氛围编程）------靠感觉写 prompt，靠运气看结果------就是这个矛盾的直接产物。
因为意图表达不精确，所以：
| 痛点 | 具体表现 | 根因 |
|---|---|---|
| 起点模糊 | "大概做这个功能"，AI 拿到的是半成品的需求 | 人类没习惯把需求说清楚 |
| 过程黑箱 | prompt 丢进去，代码出来，中间发生了什么？不知道 | 没有中间干预机制 |
| 结果不可预测 | 同一个 prompt 连续跑两次，结果可能完全不同 | 没有对齐标准 |
| 不可追溯 | 三个月后回看代码："这谁写的？为什么这么写？" | 决策链条全部丢失 |
这四个痛点不是独立的并列问题。它们是一个因果链：因为起点模糊 → 所以过程黑箱 → 所以结果不可预测 → 所以不可追溯。
没有解决起点模糊，后面的都白搭。
第六节：因为这些痛点，Code-First 在 AI 时代失效了
传统开发的范式是什么？代码是第一性产物，文档是附属品。 谁权威？代码。文档可以是过期的、残缺的，没关系，代码说了算。
这套范式在 AI 时代出问题了：
AI 生成的代码，本身就变成了你理解不了的"黑箱"。 你没有写它，你甚至不一定能读懂它的全部逻辑。你手里只剩一个 prompt 和一个输出，中间是一条完全黑暗的隧道。
传统 Code-First 的三根支柱全部断裂：
- 代码作为唯一真理来源 ------ AI 生成的代码，你敢当真理来源？它可能是幻觉、可能是过拟合、可能是理解偏差。
- 测试验证正确性 ------ 测试只能验证"代码做了预期的事"，不能验证"代码做的事是不是你想要的"。测试员不知道你的意图。
- 可读代码 = 可维护系统 ------ AI 写出来的代码也许可读，但它背后的设计决策完全不可见。你看到 WHAT，看不到 WHY。
所以结论很直接：代码不能继续当真理来源了。权威必须上移。
第七节：因为权威必须上移，SDD 的核心机制是"规范即真理"
这里就是 SDD 最关键的权力反转：
过去：代码是真理，规范是代码的附属文档。
现在：规范是真理，代码是规范的实现产物。
这不是换个说法。这是整个开发范式从根上的翻转。
怎么把权力交给规范？靠一个关键机制：五层执行模型。
第八节：五层执行模型------从底线到顶层的权力链
┌──────────────────────────────────────────────┐
│ 第5层·治理层：管理规范演化 │
│ 版本控制 · 安全策略 · 人机决策 │
├──────────────────────────────────────────────┤
│ 第4层·验证层：确保实现与规范实时对齐 │
│ 合约测试 · 模式验证 · 漂移检测(Drift Detection) │
├──────────────────────────────────────────────┤
│ 第3层·执行层：运行时实现 │
│ 骨架架构(人治) + 业务逻辑(AI生成) │
├──────────────────────────────────────────────┤
│ 第2层·生成层：将意图转换为可执行形式 │
│ 代码生成 · 类型定义 · SDK · Mock │
├──────────────────────────────────────────────┤
│ 第1层·规范层：定义系统行为 ------ 最高权威！ │
│ API模型 · 消息契约 · 领域模式 · 策略约束 │
└──────────────────────────────────────────────┘这是 SDD 区别于所有传统范式的核心架构。关键点：
- 规范层在最底层，却是最高权威。 地位最高，位置最稳。不是代码之上的"美好希望"，而是代码之下的"地基约束"。
- 生成层是编译器。 不是你给 AI 说"帮我写登录"，而是你写好规范，AI 按规范产出代码。输入从自由文本变成了结构化规范。
- 验证层是 GPS。 漂移检测（Drift Detection）持续比对实现和规范，一旦代码偏离规范，立即告警。不是"跑通就行"，而是"对齐才算"。
- 治理层是演进机制。 规范不是写完就锁死的死文档。需求变了，规范先变，代码跟着变。不是"改代码顺便补文档"，而是"改规范，重新生成代码"。
这五层合在一起，回答了 SDD 最核心的操作性问题：怎么让"权威上移"不是一个口号，而是一个可执行的架构？
第九节：落地路径------八步结构化工作流
有了架构模型，还需要可落地的流程。GitHub Spec Kit 提供了八步工作流，每一步都有明确的人类检查点：
| 步骤 | 做什么 | 谁主导 | 关键产物 |
|---|---|---|---|
| ① Constitution | 团队宪法：不可违背的原则 | 人类 | constitution.md |
| ② Specify | 功能规范：WHAT & WHY | 人类 | spec.md |
| ③ Clarify | 需求澄清：AI 追问模糊点 | AI | Q&A 记录 |
| ④ Plan | 技术计划：HOW 高层方向 | AI | plan.md |
| ⑤ Checklist | 验收清单：规范完整性检查 | AI | checklist |
| ⑥ Tasks | 原子化任务：可并行的执行项 | AI | tasks.md |
| ⑦ Analyze | 一致性分析：spec/plan/tasks 三方对齐 | AI | 分析报告 |
| ⑧ Implement | TDD 执行：严格按任务列表实现 | AI | 代码 + 测试 |
人类负责掌舵（What & Why）。AI 负责划桨（How）。
这里面最颠覆直觉的一条是：
这听起来很反直觉------"一行代码的事，至于吗？" 但这就是 SDD 和所有传统范式的核心分歧。你直接改代码，你修的是症状 。你改规范重新生成，你修的是根因 。系统性修正，而非打补丁。
第十节：同一理念，两种落地------Spec Kit vs OpenSpec
SDD 不是只有 Spec Kit 一种实现。目前主流的两种范式：
| 维度 | Spec Kit（GitHub） | OpenSpec |
|---|---|---|
| 定位 | 重规范：完整端到端流程 | 轻规范：最小侵入性 |
| 工作流 | 8 步全流程 | 4 步精简流程 |
| 适合 | 中大型项目、团队协作、长期维护 | 快速迭代、小团队、概念验证 |
| 门槛 | 高，需要团队对齐 | 低，单人也行 |
| 核心理念 | 规范是产品 | 规范是工具 |
两者没有优劣。重规范防漂移，轻规范提速度。 选哪个取决于你的项目和团队阶段。
第十一节：这对你意味着什么？
如果你是开发者，尤其是正在转型 AI 工程化的开发者，SDD 给你三个关键启示：
第一，你的角色变了。 你不是"写代码的人"，你是"定义系统意图的人"。代码是 AI 写的，但规范是你写的。你从执行者升级为设计者。
第二，表达能力变成了硬技能。 过去，"能写清楚需求"是加分项。现在，它变成了刚需。因为你写的不是 prompt，是规范。规范不清晰 = 代码必然漂移。
第三，AI Agent 开发天然适配 SDD。 你在做 LangGraph Agent 开发对吧？Agent 的 tool 定义、状态机、边界条件------这些本质上就是"规范"。写好规范，Agent 的行为才能可控。不是让 Agent 自由发挥，而是让 Agent 严格对齐你的意图。
总结：完整因果链回顾
让我们把整条因果链串联起来，验证每一节是否只能从上一节推出来：
① LLM 的自回归原理：逐 token 预测下一个词 → 天然发散
↓ 因为发散
② 需要提示词来收敛输出，压缩概率空间
↓ 因为简单提示词收敛力不足
③ SDD = 提示词的极致精细化：结构化、持久化、可迭代、可验证的约束体系
↓ 这个约束体系回答了什么？
④ 意图与执行之间必须有一座稳健的桥（根本矛盾）
↓ 因为桥不稳健
⑤ Vibe Coding 四大痛点：起点模糊 → 过程黑箱 → 结果不可测 → 不可追溯
↓ 因为这些痛点绕不过
⑥ 传统 Code-First 在 AI 时代失效（代码变黑箱，权威来源断裂）
↓ 因为权威层错位
⑦ 必须把真理来源从"代码"上移到"规范"（权力反转）
↓ 因为权力反转不能只是口号
⑧ 需要可执行的架构：五层模型（规范→生成→执行→验证→治理）
↓ 因为有架构模型
⑨ 需要可落地的流程：八步工作流（人类掌舵，AI 划桨）拿掉任何一节，后面都不成立。这就是因果链的力量------不是罗列知识点，而是推导必然性。
更重要的是，这条链揭示了一个底层规律：SDD 的本质不是"新方法论"，而是把 prompt engineering 推到了架构层面。 你从"说一句话让 AI 写代码"，进化到"构建一套约束体系让 AI 在体系内精准运行"。这不是技术升级，这是认知升级。
延伸思考：SDD 的边界
任何方法论都有边界，SDD 也不例外：
- 不是所有项目都值得 SDD。 一次性脚本、快速原型、个人小工具------Vibe Coding 完全够用。判断标准：如果项目复杂到写代码之前就需要考虑架构和数据模型，就值得用 SDD。
- 规范本身就是成本。 写一份好的 spec.md 可能比写代码还花时间。但这份投入在长期维护和团队协作中会成倍地收回来。
- SDD 不是测试的替代品。 它是测试的上游。好的规范让测试有了明确的"正确答案"可对照，但它不替代测试本身。
写于 2026-06-15
核心灵感来源：GitHub Spec Kit、OpenSpec 社区、以及 Vibe Coding 的真实踩坑感受。
spec kit 使用相关可以参考这篇文章：Spec Kit 实战完全指南