Posts

SDD（Spec-Driven Development），规范驱动开发，是AI原生时代一种全新的开发范式。 很多人初识SDD可能是通过Vibe Coding，刚入行的工程师、缺少技术背景的使用者或许仅仅把SDD当成一种工具，其实不然，在从业多年的工程师看来，SDD这种范式对软件工程领域来说是一次巨大的突破和革新，也是AI原生时代研发工作的＂第一性原理＂。 下面，跟着我进行一次思维升维之旅，为你全面拆解SDD方法论！ 一、AI驱动的研发范式演进过程 首先，请让我带你回顾一下，AI爆发带来的研发范式演进过程，看看SDD是在什么背景下诞生的。 开发者都感受过 AI 的高效，但也有点感觉别扭，究其根源，在于目前我们与AI的协作模式，这种协作模式的演进，大致分为三个阶段： Phase 1：AI作为外部知识引擎 这是最初的协作模式，比如网页版的DeepSeek等。在这个模式下，我们把AI当做外部知识库，手动把问题或代码复制给它，再把它吐出的答案＂搬＂回来（这也是大多数普通用户的使用方式）。 每次交互，我们都是“人肉序列化器”，将复杂的场景上下文，“压缩”成文本再与AI交互。 Phase 2：AI作为嵌入式辅助 这是当前最主流的协作模式，比如VS Code中的AI插件、或者Cursor这样的"AI原生IDE"。 AI “嵌入”到我们的IDE里，能“看到”打开的文件、能智能补全、能在侧边栏与你对话。这相比于 phase 1 是一个飞跃，极大地减少了"人肉切换"的摩擦。 但是，这个"辅助"依然有着局限性： 视野受限：它的上下文，局限在"当前工作区"，对当前打开的文件理解透彻，但对整个项目架构、服务间的依赖等认知不足，缺少全局视野。 环境绑定、行动受限：它的行动被囚禁在IDE上下文环境中，无法作为一个独立代理被部署到任意环境去执行任务，如CI/CD流水线、远程服务器环境等。 phase 2极大增强了我们的编码能力，但本质上仍未脱离“辅助开发者”的范畴，是许多人停留的"局部最优解"。 Phase 3：AI作为原生工作流的智能体 这个阶段，AI从"被动辅助"变成了能"主动"工作的智能体，它能够感知项目全局、能理解人类意图并自主分解成一系列具体执行步骤（如重构这个包）、能利用工具与环境交互（跑shell命令、写文件等）。 AI成为了将人类意图转化为一系列实际行动的"执行者"，典型代表，就是以Claude Code为首的CLI AI Agent（命令行AI智能体）。 SDD正是在Phase 3背景下提出的人机协同研发的一种全新范式。 二、软件工程中"信息的丢失"问题 深入 SDD 之前，我们先看一个软件行业几十年来的根本矛盾：人类意图与代码实现之间的巨大鸿沟。 通常在开发中，各角色是这样协作的： 产品经理 把业务过程 翻译成 用人类语言描述的PRD（需求文档）。 架构师 把PRD 翻译成 技术设计方案。 开发者 再把技术设计方案 翻译成 一行行代码。 这个逐步"翻译"的过程，充满了"信息的丢失"，人类语言的歧义、主观臆断等。比如，产品说"这个按钮点了要立马能显示"，开发者可能理解成"API响应时间小于200ms"，也可能忽略了这句话。 更麻烦的是，文档（PRD、技术方案等）与最终的代码，基本上是脱节的。项目在迭代，代码飞速向前，而文档的更新"看心情"，最终文档在角落慢慢腐朽，成为"代码考古"的障碍。 数十年来，人们发明了UML、敏捷、Scrum等各种方法和工具，想缝合这条鸿沟，收效甚微。我们始终认为：**文档只是"指南"，代码才是"真理"！ ** AI时代的爆发，给了我们颠覆这个"真理"的机会。 三、SDD：规范(Spec)成为"真理之源" SDD实现了一次**“权利反转”**，其核心思想就一句话：规范才是"真理之源"。 SDD范式，是代码服务于规范，那份无歧义、可被机器理解的、结构化的"规范"，成为项目唯一的至高无上的"真理之源"。而代码，则降级为"真理之源"在某种特定技术栈（如Java + SpringBoot + Mysql）下的编译产物。如下图所示： 在这场"权利反转"中： 项目的核心：“修改代码” 变成 “维护规范”。 重构的核心：“大规模迁移代码” 变成 “基于同一份规范，生成另一个技术栈的全新实现方式”。 解决bug的核心：“修正错误代码” 变成 “修正错误的规范”。 要实现上述"权利反转"，“规范"必须具备一个特性：能被机器理解和执行。这就是 AI Agent 要扮演的新角色：“编译"人类的意图。 ...