Spec-Driven Development 深度指南 — Part 1: 软件设计的演进与 SDD 的本质

Spec-Driven Development 深度指南 — Part 1: 软件设计的演进与 SDD 的本质

什么是 Spec-Driven Development (SDD)？ Spec-Driven Development 是一种全新的现代化软件工程方法论，核心在于将工程规范（Specification）作为代码生成的绝对真相来源（Single Source of Truth）。在 AI 与 Agent 普及的开发环境中，它通过系统化的文档约束来彻底解决 LLM 上下文腐烂（Context Decay）和自然语言歧义性，让意图表达具备长期持久化效力。

TL;DR: Spec-Driven Development (SDD) 的诞生并非简单因为“AI 时代需要更多文档”，而是对意图表达和跨会话知识持久化成本激增的响应。本文拆解了 AI 编程工具从“代码补全”到“自主智能体（Agent）”的三代演进，揭示为什么传统的提示词和工程方法论已无法应对新的开发瓶颈。

Series Navigation:

• Part 1 (This Post): 软件设计的演进与 SDD 的本质
• Part 2: GitHub Spec Kit 实战指南
• Part 3: 意图层基础设施与 SDD 的未来
• Part 4: 使用 GitHub Issues 构建简单的 SDD 工作流

Illustration: 从静态设计到智能驱动——软件架构工程视野的跃迁

软件工程方法论的本质

每一次软件工程方法论的变革，本质上都是对“人与工具之间认知摩擦”的响应。

• 瀑布模型（1970 时代）：对“代码写到一半发现需求错了”的响应的。
• 敏捷宣言（2001 年）：对“瀑布模型太慢、无法适应变化”的响应的。
• TDD 测试驱动开发：对“写完代码才发现设计有问题”的响应。

Spec-Driven Development (SDD，规范驱动开发) 的诞生背景，则是对一个全新问题的响应：当 AI 能在几分钟内生成几千行代码时，人类工程师的认知能力在哪个环节成为了瓶颈？

要回答这个问题，必须先理解 AI 编程工具是如何一步步进化的。

AI 编程工具的三代演进

第一代（2021-2022）：补全即智能

GitHub Copilot 发布时，它本质上是一个“超级 Tab 键”——你写了函数名，它负责补全函数体。

人写意图（函数名/注释） → AI 补全实现 → 人审查几行代码

在这个阶段，开发者始终在驾驶座，AI 仅仅是助手。代码补全的粒度小，错了也容易发现，一切还在人类直接控制范围内。

第二代（2023）：对话即编程

随着 ChatGPT 和 Claude 的出现，交互范式发生了改变。开发者开始习惯把整个功能需求粘贴给模型，直接拿回一段完整的代码。

人描述需求（自然语言） → AI 生成完整代码块 → 人粘贴到编辑器

这里出现了第一个裂缝：对话是临时的，代码是持久的。每次新开对话，上下文就丢了（即上下文腐烂，Context Decay），导致开发者发现自己在重复解释同一个项目背景。

第三代（2024-2025）：智能体即工程师

当 Cursor、Claude Code、GitHub Copilot Workspace 等 Agent（智能体）工具成熟时，AI 不再只是被动回答问题，而是可以直接修改文件、执行命令、运行测试。

人给出任务描述 → AI 自主规划并执行多步骤操作 → 人验收结果

这里出现了根本性的断裂：当 AI 在 10 分钟内生成了 3000 行代码，横跨 20 个文件，人类工程师如何验收？如何理解？如何维护？这与我们在探讨多智能体协作与 Antigravity Agents 所面临的复杂度管控挑战如出一辙。

这道断裂的认知鸿沟，正是 SDD 诞生的真实土壤。

真正触发 SDD 的三个工程现实

现实一：上下文窗口是计算资源，不是记忆

大多数人把大语言模型 (LLM) 的上下文窗口理解为“记忆”，这个比喻是错的。更准确的理解是：上下文窗口是每次推理的工作内存，会话结束就清空，下次推理从零开始。

这意味着一个基本事实：AI 本身不记得你上周跟它说的任何事情。

当项目规模增长，代码库积累了数月的架构决策时，一个新的 AI 会话面对这个代码库时看到的只是当前的静态快照。它不知道：

• 为什么选了这个架构而不是那个？
• 某个函数曾经因为什么 Bug 被重写过？
• 这个接口设计背后有什么业务约束？

这不是 AI 的缺陷，这是所有语言模型的结构性特征。

现实二：自然语言需求有无法消除的歧义性

“做一个用户登录功能”这句话，在一个有 5 年经验的架构师脑海中，会自动填充几十个隐含假设：要不要支持第三方登录？密码错误几次要锁定？使用 Session 还是 JWT？

但 AI 并没有这些贴合你团队的经验性假设。它通常会选择训练数据中最常见的那种方案，然后不声不响地执行。两天后你发现它实现的方式和你的系统架构完全不兼容，但代码已经写了 2000 行。

SDD 的核心解决之道：将 Spec 规范化，强制让这些隐含假设显性化。

现实三：代码生成速度远超人类理解速度

人类审查代码的速度大约是每小时 100-200 行（指认真审查逻辑），而 AI 生成代码的速度是每分钟几百上千行。

当 AI 在一次会话里生成大量代码，人类如果试图逐行审查，需要花几十个小时。这就是为什么在新范式下开发者经常遇到审查瘫痪（Review Paralysis）。

通过 SDD，审查的重心从“代码是否正确”转移到了“代码是否兑现了规范”——审查一份 100 行的文档规范比审查 5000 行代码要快得多。

为什么不能只靠 System Prompt 解决？

System Prompt（系统提示词）和 SDD 在本质上解决的是完全不同类型的问题。

System Prompt 控制的是“角色和风格”

System Prompt 是在每次对话开始时注入的固定指令，它有效控制了：

• AI 的角色定位（例如：“你是一个高级资深开发人员”）
• 输出格式（例如：“严格遵循 JSON 返回”）
• 语气风格和部分编码规则（例如：“不使用 Lombok”）

这些都是无状态的、对话级别的约束。

SDD 解决的是“跨会话知识持久化”

如果你的应用架构两周前决定使用 Role-Based Access Control (RBAC) 并且明确拒绝了 ABAC 的设计，那么两周后你修 Bug 或加功能时，System Prompt 无法携带最初选择 RBAC 的完整商业逻辑和折衷考量。

更深层的原因在于：系统提示词是工具配置，而不是工程资产。 SDD 主张将 Spec 作为源代码管理（Spec-as-Source）。它不仅要存在于代码库中，而且和代码一同被版本控制、提交 PR，并且具备反脆弱的工具无关性——换掉当前的 IDE，工程规范依然有效保留在 Markdown 中。

SDD 的思想起源

SDD 并不是凭空出现的流派，它的思想血统可以追溯到这几个经典方法：

• 受 TDD（测试驱动开发）启发：TDD 的洞见是“先写测试，再写代码”。SDD 也是类似的移位：先写规范，再写代码。只不过 TDD 的规范是给编译器看的单元测试，而 SDD 的规范是给 AI 提炼的结构化文档。
• 契约式设计（Design by Contract）：将传统代码层级的前置/后置条件，提升到了系统和业务意图的层级。
• 架构决策记录（ADR）：将记录“为什么做这个决策”的精神，不仅仅延展至架构层面，也囊括具体的特性实现层面。

What’s Next

SDD 的出现并不是因为“AI 时代需要更多文档”。它是由于当实现代码的成本趋近于零时，软件工程的核心价值从“如何生产代码”彻底转向了“如何精确传递意图和沉淀决策”。

在下一篇文章中，我们将带大家深入了解目前实施 SDD 最成熟的行业标杆——GitHub 推出的开源工具包 Spec-Kit，为你详细拆解它是如何落地以上这些理念的。

---

Series Navigation:

• → Next: Part 2: GitHub Spec Kit 实战指南