AI 训练营第 71 天：开启规范驱动开发（SDD）新篇章

随着 AI 编程助手的广泛普及，软件开发正经历一场深刻变革——从“代码至上”转向“意图至上”。数十年来，代码始终是核心产出，而需求文档与设计图仅作为辅助“备注”。然而，当 AI 智能体成为代码生成的主力军时，这种被动模式便暴露出弊端。

业界近期涌现出一个新词——“氛围编程（Vibe Coding）”，用以形容一种高风险开发模式：开发者仅给出模糊的自然语言指令（例如“为我的 App 添加照片分享功能”），随即直接将看似可用的代码集成，完全缺乏严格的契约验证。

此举的隐患在于：模糊的指令迫使大语言模型（LLM）去臆测成千上万个未明示的需求——涵盖权限模型、存储限制至压缩标准等。一旦 AI 被迫猜测，其预设假设极易与项目实际的架构需求产生冲突。

规范驱动开发（Spec-Driven Development，简称 SDD）作为一种方法论，其核心主张是：规范文档——而非代码——才是项目的“唯一真理源”。在此框架下，架构师的信条变为：“代码仅是规范的实现细节”。规范明确了软件必须完成的任务（意图），而代码负责将这一意图落地。

团队通常依据以下三个层级来逐步采纳 SDD：

表 1：SDD 的三个成熟度等级

在传统软件开发生命周期（SDLC）中，需求文档仅具备“咨询”性质。它们是静态产物，自实施启动那一刻起便可能变得“过时”或“含糊”。开发者依据个人理解解读文档并编写代码，最终使得代码成为唯一可信的现实。

而在 SDD 模式下，规范被视为可版本化、机器可读的构建产物。传统需求是“临时性”的，而 SDD 需求则是“派生”的并深度集成至 CI/CD 流水线。通过将规范视作权威契约而非单纯建议，团队能确保每次变更均可追溯、可验证，同时优化了人类与 AI 的使用体验。

表 2：传统 SDLC 与 SDD 的对比

GitHub Spec Kit 是一款开源的命令行工具包，旨在利用可预测的四阶段门控工作流取代“氛围编程”。其核心机制是通过生成 SPEC.md 等具体产物，来约束并引导 AI 智能体。

此外，/speckit.constitution 命令用于确立项目的治理原则，借助“检查点”机制，人类可在每个门控节点验证输出，从而在架构偏离演变为技术债务前及时拦截。

若说 Spec Kit 提供了工作流，那么 OpenSpec（涵盖 OpenAPI、AsyncAPI 等标准）则代表了标准化层面。这些标准作为“通用契约”，推动团队协作从凭“感觉”走向重“验证”。

SDD 已在多个实际工程场景中彰显出显著价值：

在棕地项目（Brownfield Projects）中，SDD 能有效防止“功能漂移”。在实施变更前，先将遗留行为编码入规范，使规范成为连接新旧系统的桥梁。

某金融服务案例表明，借助 SDD 实现了集成周期缩短 75%。成功关键在於利用从规范生成的 Mock 服务器（通过 Specmatic），使前后端团队能基于契约同步开发与测试。

开发者如今采用“自规范（Self-Spec）”方法及 agents.md 文件来定义专用 AI 人格（如@security-agent）。AI 自主起草规范供人类审核，形成了“规划”与“执行”分离的智能体循环。

SDD 并非万能钥匙，它要求开发者文化进行严谨转型。作者建议架构师实施“三层边界体系”以规范 AI 智能体的行为：

表 3：三层边界体系详解

我们正迈入一个“意图即真理”的时代。伴随 AI 能力提升，代码生成速度已远超人类打字效率，主要瓶颈不再是“编写实现”，而是“定义高质量规范”。

论文提出的“金科玉律”是：采用具体情境所需的最低规范严谨度来消除模糊性。无论是从零构建新项目还是现代化改造遗留系统，SDD 都提供了一套框架，确保你的 AI 协作伙伴是主动的工程盟友，而非被动的搜索工具。

未来，随着 Tessl 等工具的成熟及更多标准的涌现，SDD 有望成为 AI 时代软件工程的基础方法论。对每位开发者而言，此刻正是拥抱规范驱动思维的最佳时机。