规范驱动开发（Spec-Driven Development）：一个批判性审视

董厂长2026-05-31 10:53

规范驱动开发（Spec-Driven Development）：一个批判性审视

摘要：规范驱动开发（SDD）是2025年AI辅助编码领域涌现的方法论，主张"先写规范，规范驱动AI生成代码"。本文基于对12个一手来源的交叉验证分析，系统考察SDD的定义边界、历史渊源、工具生态、实证证据与核心争议。研究发现：SDD的核心理念（spec-first）具有理论合理性，但术语存在严重的语义扩散；当前工具在实际使用中面临可用性瓶颈；且尚无对照实验证明SDD优于"普通AI辅助编码"。本文采取审慎乐观的立场，区分"已验证的事实"与"合理但未经证实的推论"，为研究者和实践者提供一份基于证据的参考框架。

关键词：规范驱动开发、Spec-Driven Development、AI辅助编码、Vibe Coding、模型驱动工程、软件工程方法论

目录

  1. 引言：问题的提出
  2. 定义与概念边界
  3. 历史脉络：从MDD到SDD
  4. [对照物：Vibe Coding与无约束AI生成的实证问题](#对照物：Vibe Coding与无约束AI生成的实证问题)
  5. 方法论定位：SDD与TDD/BDD/DDD的关系
  6. 规范格式与代码生成基础设施
  7. 三大SDD工具的设计哲学与独立评测
  8. 实证证据与证据缺口分析
  9. 系统性批评与反驳
  10. 开放问题与未来研究方向
  11. 结论与审慎建议
  12. 参考文献

1. 引言：问题的提出

2025年，AI编码工具（Cursor、GitHub Copilot、Claude Code等）的能力突破了一个临界点：从"行级补全"跃升为"全功能实现"。这一跃升带来了两种截然相反的实践倾向：

倾向一 ：Vibe Coding------"完全交给AI，不审查代码"（Karpathy, 2025[1](#1)）

倾向二 ：Spec-Driven Development------"先写结构化规范，让AI在约束内工作"（GitHub, 2025[2](#2)；Amazon Kiro, 2025[3](#3)）

本文的核心研究问题是：

SDD作为一种新兴方法论，其理论基础是否坚实？实证证据是否支持其宣称的价值？其适用边界在哪里？

本文不预设立场，而是通过多源交叉验证、反方意见的系统整合、以及对证据质量的严格审查，力求提供一份可被质疑、可被反驳、但论证过程透明的分析报告。

1.1 研究方法与来源说明

本文分析基于以下主要来源：

类别 来源 可信度评级
独立学术/准学术 METR RCT研究^[4](#类别 来源 可信度评级 独立学术/准学术 METR RCT研究4、arXiv论文5 ⭐⭐⭐⭐⭐ 独立专家评测 Birgitta Böckeler (Thoughtworks)6 ⭐⭐⭐⭐⭐ 行业雷达 Thoughtworks Technology Radar Vol.347 ⭐⭐⭐⭐⭐ 一手技术文档（有利益相关） GitHub Blog2、Spec Kit文档8、Kiro3 ⭐⭐⭐⭐ 商业推广 Specmatic9、TypeSpec10 ⭐⭐⭐)、arXiv论文[5](#类别 来源 可信度评级 独立学术/准学术 METR RCT研究4、arXiv论文5 ⭐⭐⭐⭐⭐ 独立专家评测 Birgitta Böckeler (Thoughtworks)6 ⭐⭐⭐⭐⭐ 行业雷达 Thoughtworks Technology Radar Vol.347 ⭐⭐⭐⭐⭐ 一手技术文档（有利益相关） GitHub Blog2、Spec Kit文档8、Kiro3 ⭐⭐⭐⭐ 商业推广 Specmatic9、TypeSpec10 ⭐⭐⭐)^ ⭐⭐⭐⭐⭐
独立专家评测 Birgitta Böckeler (Thoughtworks)^[6](#类别 来源 可信度评级 独立学术/准学术 METR RCT研究4、arXiv论文5 ⭐⭐⭐⭐⭐ 独立专家评测 Birgitta Böckeler (Thoughtworks)6 ⭐⭐⭐⭐⭐ 行业雷达 Thoughtworks Technology Radar Vol.347 ⭐⭐⭐⭐⭐ 一手技术文档（有利益相关） GitHub Blog2、Spec Kit文档8、Kiro3 ⭐⭐⭐⭐ 商业推广 Specmatic9、TypeSpec10 ⭐⭐⭐)^ ⭐⭐⭐⭐⭐
行业雷达 Thoughtworks Technology Radar Vol.34^[7](#类别 来源 可信度评级 独立学术/准学术 METR RCT研究4、arXiv论文5 ⭐⭐⭐⭐⭐ 独立专家评测 Birgitta Böckeler (Thoughtworks)6 ⭐⭐⭐⭐⭐ 行业雷达 Thoughtworks Technology Radar Vol.347 ⭐⭐⭐⭐⭐ 一手技术文档（有利益相关） GitHub Blog2、Spec Kit文档8、Kiro3 ⭐⭐⭐⭐ 商业推广 Specmatic9、TypeSpec10 ⭐⭐⭐)^ ⭐⭐⭐⭐⭐
一手技术文档（有利益相关） GitHub Blog^[2](#类别 来源 可信度评级 独立学术/准学术 METR RCT研究4、arXiv论文5 ⭐⭐⭐⭐⭐ 独立专家评测 Birgitta Böckeler (Thoughtworks)6 ⭐⭐⭐⭐⭐ 行业雷达 Thoughtworks Technology Radar Vol.347 ⭐⭐⭐⭐⭐ 一手技术文档（有利益相关） GitHub Blog2、Spec Kit文档8、Kiro3 ⭐⭐⭐⭐ 商业推广 Specmatic9、TypeSpec10 ⭐⭐⭐)^、Spec Kit文档^[8](#类别 来源 可信度评级 独立学术/准学术 METR RCT研究4、arXiv论文5 ⭐⭐⭐⭐⭐ 独立专家评测 Birgitta Böckeler (Thoughtworks)6 ⭐⭐⭐⭐⭐ 行业雷达 Thoughtworks Technology Radar Vol.347 ⭐⭐⭐⭐⭐ 一手技术文档（有利益相关） GitHub Blog2、Spec Kit文档8、Kiro3 ⭐⭐⭐⭐ 商业推广 Specmatic9、TypeSpec10 ⭐⭐⭐)、Kiro[3](#类别 来源 可信度评级 独立学术/准学术 METR RCT研究4、arXiv论文5 ⭐⭐⭐⭐⭐ 独立专家评测 Birgitta Böckeler (Thoughtworks)6 ⭐⭐⭐⭐⭐ 行业雷达 Thoughtworks Technology Radar Vol.347 ⭐⭐⭐⭐⭐ 一手技术文档（有利益相关） GitHub Blog2、Spec Kit文档8、Kiro3 ⭐⭐⭐⭐ 商业推广 Specmatic9、TypeSpec10 ⭐⭐⭐)^ ⭐⭐⭐⭐
商业推广 Specmatic^[9](#类别 来源 可信度评级 独立学术/准学术 METR RCT研究4、arXiv论文5 ⭐⭐⭐⭐⭐ 独立专家评测 Birgitta Böckeler (Thoughtworks)6 ⭐⭐⭐⭐⭐ 行业雷达 Thoughtworks Technology Radar Vol.347 ⭐⭐⭐⭐⭐ 一手技术文档（有利益相关） GitHub Blog2、Spec Kit文档8、Kiro3 ⭐⭐⭐⭐ 商业推广 Specmatic9、TypeSpec10 ⭐⭐⭐)、TypeSpec[10](#类别 来源 可信度评级 独立学术/准学术 METR RCT研究4、arXiv论文5 ⭐⭐⭐⭐⭐ 独立专家评测 Birgitta Böckeler (Thoughtworks)6 ⭐⭐⭐⭐⭐ 行业雷达 Thoughtworks Technology Radar Vol.347 ⭐⭐⭐⭐⭐ 一手技术文档（有利益相关） GitHub Blog2、Spec Kit文档8、Kiro3 ⭐⭐⭐⭐ 商业推广 Specmatic9、TypeSpec10 ⭐⭐⭐)^ ⭐⭐⭐

关键方法论原则：

  • 每个核心断言至少2个独立来源交叉验证
  • 区分"事实陈述"与"观点表达"
  • 工具官方的宣传数据标注为"官方宣称，缺乏独立验证"
  • 对推理性结论明确标注"推论"

2. 定义与概念边界

2.1 多源定义对比

目前对SDD的定义尚未形成共识。以下是来自不同权威来源的原始定义：

定义A （Birgitta Böckeler, Thoughtworks, 2025年10月[6](#6)）：

"Spec-driven development means writing a 'spec' before writing code with AI ('documentation first'). The spec becomes the source of truth for the human and the AI."

定义B （GitHub Spec Kit 哲学文档[8](#8)）：

"SDD inverts this power structure. Specifications don't serve code---code serves specifications. The Product Requirements Document (PRD) isn't a guide for implementation; it's the source that generates implementation."

定义C （Tessl Framework，引自Böckeler[6](#6)）：

"A development approach where specs --- not code --- are the primary artifact. Specs describe intent in structured, testable language, and agents generate code to match them."

定义D （Thoughtworks Technology Radar, 2025年11月[7](#7)）：

"An emerging approach to AI-assisted coding workflows... workflows that begin with a structured functional specification, then proceed through multiple steps to break it down into smaller pieces, solutions and tasks."

2.2 定义的共同核心与分歧点

共同核心（所有定义一致）：

  1. 先写规范，后写代码
  2. 规范成为某种形式的"事实源"（source of truth）
  3. AI参与从规范到代码的转化

关键分歧：

分歧维度 保守立场（Böckeler/技术雷达） 激进立场（Spec Kit/Tessl）
规范的生命周期 可以是一次性的（spec-first） 必须长期维护（spec-anchored/spec-as-source）
代码的地位 代码仍然重要，需要审查 代码是"最后一公里"，可以不再直接编辑
AI的角色 辅助工具 执行引擎（规范→代码完全自动化）

2.3 "语义扩散"警告

Böckeler明确警告[6](#6)：

"The term 'spec-driven development' isn't very well defined yet, and it's already semantically diffused. I've even recently heard people use 'spec' basically as a synonym for 'detailed prompt'."

Thoughtworks技术雷达独立确认[7](#7)：

"While the term's definition is still evolving..."

读者应警惕的常见混淆：

  • "Spec-driven" ≠ "Contract-first"（后者专指机器可读的API规范，如OpenAPI）
  • "Spec" ≠ "Detailed prompt"（前者是结构化的持久工件，后者是即时输入）
  • "Spec-driven" ≠ "Documentation-first"（前者的规范面向AI消费，后者面向人类阅读）

2.4 SDD的三个层级模型

Böckeler提出的三层模型[6](#6)是当前最清晰的概念框架：

层级 名称 特征 代表工具 风险递增
Level 1 Spec-first 为任务编写规范，任务完成后规范可被弃用 Kiro 低
Level 2 Spec-anchored 规范在功能完成后保留，随功能演进更新 Spec Kit（探索中） 中
Level 3 Spec-as-source 人只编辑规范，代码标注"GENERATED - DO NOT EDIT" Tessl 高

2.5 "什么是Spec？"的操作性定义

"A spec is a structured, behavior-oriented artifact --- or a set of related artifacts --- written in natural language that expresses software functionality and serves as guidance to AI coding agents."

--- Böckeler[6](#6)

与相关概念的区分：

  • vs. Memory Bank（如AGENTS.md、architecture.md）：Memory Bank跨所有会话有效；Spec只与特定功能任务相关
  • vs. PRD：Spec最接近PRD，但更面向AI Agent消费
  • vs. Prompt：Spec是持久的结构化工件；Prompt是即时输入

3. 历史脉络：从MDD到SDD

3.1 模型驱动工程（MDE/MDD）的兴衰

SDD最重要的历史先驱是模型驱动开发（Model-Driven Development, MDD）：

"Model-driven engineering (MDE) is a software development methodology that focuses on creating and exploiting domain models... technical artifacts such as source code, documentation, tests, and more are generated algorithmically from a domain model."

--- Wikipedia, Model-driven engineering[11](#11)

MDD的核心理念（"从抽象模型自动生成代码"）与SDD高度相似。两者都试图将开发者的工作重心从"编写代码"上移到"编写规范/模型"。

3.2 MDD失败的教训

MDD在2000-2010年代未能广泛成功，主要原因包括[11](#11)：

  1. 形式化语言的学习壁垒：UML/DSL需要专门学习
  2. 代码生成器能力有限：无法处理复杂业务逻辑
  3. Round-trip engineering困难：模型与代码难以双向同步
  4. 调试困难：生成的代码与原始模型的对应关系不透明
  5. 抽象层错位：在错误的粒度上建模

3.3 LLM如何改变了游戏规则

Böckeler对MDD-SDD类比进行了深度分析[6](#6)：

"LLMs take some of the overhead and constraints of MDD away, so there is a new hope that we can now finally focus on writing specs and just generate code from them. With LLMs, we are not constrained by a predefined and parseable spec language anymore, and we don't have to build elaborate code generators."

但她也指出了新的风险：

"The price for that is LLMs' non-determinism of course. And the parseable structure of MDD also had upsides that we're losing now: We could provide the spec author with a lot of tool support to write valid, complete and consistent specs."

总结对比：

MDD的问题 LLM是否解决？ SDD的新情况
形式化语言壁垒 ✅ 解决 自然语言规范
生成器能力有限 ✅ 大幅改善 LLM通用代码生成
Round-trip困难 ❌ 未解决 规范⇌代码同步仍是核心挑战
调试困难 ⚠️ 部分改善 LLM代码更"人类化"但仍有理解困难
非确定性 ❌ 新增问题 同一规范每次可能生成不同代码

本文判断：SDD有可能避开MDD的部分失败原因（特别是形式化语言壁垒），但也面临MDD时代不存在的新问题（非确定性）。Level 3 (Spec-as-source)面临的风险最高，最可能重蹈MDD覆辙。

3.4 其他历史先驱

先驱方法 年代 核心思想 与SDD的关系
Contract-First API Design 2011至今 先写OpenAPI规范再实现 SDD在API层面的前身
Design-by-Contract (Eiffel) 1986 接口前置条件/后置条件 "契约"思想的起源
BDD/Executable Specs 2006至今 Given-When-Then场景可直接运行 规范可执行性的先驱
Literate Programming (Knuth) 1984 文档与代码交织 "文档优先"理念

4. 对照物：Vibe Coding与无约束AI生成的实证问题

4.1 Vibe Coding的定义

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. ... I 'Accept All' always, I don't read the diffs anymore."

--- Andrej Karpathy, 2025年2月2日[1](#1)

Vibe Coding的边界界定（Simon Willison，引自Wikipedia[12](#12)）：

"If an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding in my book --- that's using an LLM as a typing assistant."

4.2 Vibe Coding问题的实证证据

以下证据来自多个独立来源 的交叉验证[12](#12)[4](#4)[13](#13)[14](#14)：

安全性
来源 方法 发现 时间
Semafor 扫描1645个Lovable应用 170个(~10.3%)存在信息泄露 2025.05
Veracode 多年纵向研究 LLM功能性↑但安全性未改善；大模型不比小模型更安全 2025.10
BBC/Orchids 安全研究员发现 vibe coding平台代码含安全漏洞 2026.02
代码质量
来源 方法 发现 时间
CodeRabbit^[13](#来源 方法 发现 时间 CodeRabbit13 470个GitHub PR分析 AI共创代码"重大问题"率1.7x、安全漏洞率2.74x 2025.12 GitClear14 211M行代码纵向分析 重构率25%→<10%，代码重复4x增长 2025.02)^ 470个GitHub PR分析 AI共创代码"重大问题"率1.7x、安全漏洞率2.74x 2025.12
GitClear^[14](#来源 方法 发现 时间 CodeRabbit13 470个GitHub PR分析 AI共创代码"重大问题"率1.7x、安全漏洞率2.74x 2025.12 GitClear14 211M行代码纵向分析 重构率25%→<10%，代码重复4x增长 2025.02)^ 211M行代码纵向分析 重构率25%→<10%，代码重复4x增长 2025.02
生产力（最高证据级别------随机对照实验）

METR研究[4](#4)是该领域迄今最严谨的研究之一：

研究设计：16名经验丰富的开源开发者，246个真实issue，来自平均22k+ stars的仓库，随机对照分组。

核心发现：

"When developers are allowed to use AI tools, they take 19% longer to complete issues---a significant slowdown that goes against developer beliefs and expert forecasts."[4](#4)

认知偏差发现：

"Developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%."[4](#4)

（即约39-43个百分点的感知-现实差距）

METR自己的声明限制 [4](#4)：

  • 仅测量经验丰富的开源开发者
  • 仅使用2025年初AI工具（Cursor Pro + Claude 3.5/3.7 Sonnet）
  • 不排除存在更有效的使用方式
  • 不排除后续模型进步可能逆转结果

4.3 对SDD论证的意义------诚实声明

逻辑链：

  1. 无约束AI辅助存在已被实证证明的质量和生产力问题 ✅（4.2节证据）
  2. SDD通过结构化规范提供约束，理论上可缓解这些问题 ✅（逻辑推导）
  3. 但：目前没有同等级别的实证研究证明SDD确实比无约束AI辅助更好 ⚠️

这是本文最重要的诚实声明 ：SDD相对于"普通AI辅助编码"的效果优势，目前主要是理论推导 和轶事证据 ，不是对照实验。

5. 方法论定位：SDD与TDD/BDD/DDD的关系

5.1 综合对比

维度 SDD TDD BDD DDD
核心工件 功能规范(Markdown) 测试套件 .feature文件 领域模型
工作层面 需求/设计层 代码实现层 行为描述层 架构设计层
驱动什么 AI代码生成 手动编码 开发+验收 系统分解
AI时代新价值 为AI明确执行指令 为AI提供验证标准 为AI提供行为期望 为AI提供领域知识
证据基础 弱（无RCT） 强（数十年） 中 中

5.2 关键判断：互补而非替代

Spec Kit文档内嵌了TDD[8](#8)：

"Create test files in order: contract → integration → e2e → unit. Create source files to make tests pass."

即SDD不是TDD的替代品------SDD负责"做什么"的宏观规范，TDD负责"做对了"的微观验证。两者在不同抽象层工作，天然互补。

6. 规范格式与代码生成基础设施

6.1 机器可读规范格式

格式 成熟度 代码生成支持 适用场景
OpenAPI 3.x 生产级 50+客户端, 40+服务端^[15](#格式 成熟度 代码生成支持 适用场景 OpenAPI 3.x 生产级 50+客户端, 40+服务端15 REST API AsyncAPI 成长期 多语言模板 事件驱动 Protocol Buffers 生产级 所有主流语言 高性能RPC GraphQL Schema 生产级 TypeScript为主 灵活查询 TypeSpec10 成长期 通过emitters 多协议API设计)^ REST API
AsyncAPI 成长期 多语言模板 事件驱动
Protocol Buffers 生产级 所有主流语言 高性能RPC
GraphQL Schema 生产级 TypeScript为主 灵活查询
TypeSpec^[10](#格式 成熟度 代码生成支持 适用场景 OpenAPI 3.x 生产级 50+客户端, 40+服务端15 REST API AsyncAPI 成长期 多语言模板 事件驱动 Protocol Buffers 生产级 所有主流语言 高性能RPC GraphQL Schema 生产级 TypeScript为主 灵活查询 TypeSpec10 成长期 通过emitters 多协议API设计)^ 成长期 通过emitters 多协议API设计

6.2 TypeSpec示例

typespec 复制代码 
import "@typespec/http";
using Http;

model Todo {
  id: int32;
  title: string;
  completed?: boolean;
}

@route("/todos")
interface Todos {
  list(): Todo[];
  create(@body todo: Todo): Todo;
}

此代码编译生成数百行OpenAPI YAML------体现了SDD的"高层规范→低层实现"理念。

6.3 契约测试：规范即测试

Specmatic[9](#9)展示了"规范→可执行测试"的零代码路径：API规范自动转化为契约测试，无需手写测试代码。

官方宣称效果 （注意：缺乏独立第三方验证）：

  • API开发周期减少75%
  • 流效率提升40%

7. 三大SDD工具的设计哲学与独立评测

7.1 设计哲学对比

维度 Kiro (Amazon)^[3](#维度 Kiro (Amazon)3 Spec Kit (GitHub)28 Tessl6 口号 “Vibe coding → viable code” “Intent is the source of truth” “Specs, not code, are primary” SDD层级 Level 1 Level 1-2 Level 2-3 激进程度 保守 中等 激进 工作流 Requirements→Design→Tasks Constitution→Specify→Plan→Tasks Spec↔Code双向 分发 独立IDE CLI+workspace(MIT开源) CLI+MCP(私有Beta))^ Spec Kit (GitHub)^[2](#维度 Kiro (Amazon)3 Spec Kit (GitHub)28 Tessl6 口号 “Vibe coding → viable code” “Intent is the source of truth” “Specs, not code, are primary” SDD层级 Level 1 Level 1-2 Level 2-3 激进程度 保守 中等 激进 工作流 Requirements→Design→Tasks Constitution→Specify→Plan→Tasks Spec↔Code双向 分发 独立IDE CLI+workspace(MIT开源) CLI+MCP(私有Beta))^^[8](#维度 Kiro (Amazon)3 Spec Kit (GitHub)28 Tessl6 口号 “Vibe coding → viable code” “Intent is the source of truth” “Specs, not code, are primary” SDD层级 Level 1 Level 1-2 Level 2-3 激进程度 保守 中等 激进 工作流 Requirements→Design→Tasks Constitution→Specify→Plan→Tasks Spec↔Code双向 分发 独立IDE CLI+workspace(MIT开源) CLI+MCP(私有Beta))^ Tessl^[6](#维度 Kiro (Amazon)3 Spec Kit (GitHub)28 Tessl6 口号 “Vibe coding → viable code” “Intent is the source of truth” “Specs, not code, are primary” SDD层级 Level 1 Level 1-2 Level 2-3 激进程度 保守 中等 激进 工作流 Requirements→Design→Tasks Constitution→Specify→Plan→Tasks Spec↔Code双向 分发 独立IDE CLI+workspace(MIT开源) CLI+MCP(私有Beta))^
口号 "Vibe coding → viable code" "Intent is the source of truth" "Specs, not code, are primary"
SDD层级 Level 1 Level 1-2 Level 2-3
激进程度 保守 中等 激进
工作流 Requirements→Design→Tasks Constitution→Specify→Plan→Tasks Spec↔Code双向
分发 独立IDE CLI+workspace(MIT开源) CLI+MCP(私有Beta)

7.2 Spec Kit的"宪法"（Constitution）机制

Spec Kit最独特的设计是Constitution[8](#8)------不可变的架构原则集合：

"At the heart of SDD lies a constitution---a set of immutable principles that govern how specifications become code."[8](#8)

通过模板中的"Phase -1 Gates"（如Simplicity Gate、Anti-Abstraction Gate）强制AI在生成前通过检查。这是一种创新的LLM行为约束框架。

7.3 独立评测：Böckeler的深度体验

Birgitta Böckeler（Thoughtworks Distinguished Engineer，20+年经验）是目前唯一 公开发表三工具独立评测的人[6](#6)。核心发现：

发现一：尺寸不适配（Sledgehammer-to-crack-a-nut）

"When I asked Kiro to fix a small bug, it quickly became clear that the workflow was like using a sledgehammer to crack a nut. The requirements document turned this small bug into 4 'user stories' with a total of 16 acceptance criteria."[6](#6)

发现二：审查负担

"To be honest, I'd rather review code than all these markdown files. An effective SDD tool would have to provide a very good spec review experience."[6](#6)

发现三：虚假控制感

"Even with all of these files and templates and prompts and workflows and checklists, I frequently saw the agent ultimately not follow all the instructions."[6](#6)

具体案例：Spec Kit的research步骤正确识别了现有代码结构，但AI agent随后将其当作新规范，生成了重复代码。

发现四：评价困难

"It turns out to be quite time-consuming to evaluate SDD tools in a way that gets close to real usage."[6](#6)

7.4 总结性判断

Böckeler的最终结论[6](#6)：

"The general principle of spec-first is definitely valuable in many situations... But the term 'spec-driven development' isn't very well defined yet."

她用了一个德语合成词：

"Verschlimmbesserung": Are we making something worse in the attempt of making it better?

Thoughtworks技术雷达独立确认[7](#7)：

"These tools behave very differently depending on task size and type; some generate lengthy spec files that are hard to review."

8. 实证证据与证据缺口分析

8.1 证据质量矩阵

断言 证据质量 证据类型 来源数量
"无约束AI辅助有安全/质量风险" 高 多源独立实证 4+
"AI辅助不一定提升生产力" 高 RCT^[4](#断言 证据质量 证据类型 来源数量 “无约束AI辅助有安全/质量风险” 高 多源独立实证 4+ “AI辅助不一定提升生产力” 高 RCT4 1（高质量） “当前SDD工具有可用性问题” 中-高 专家评测6 + 技术雷达确认7 2 “SDD比无约束AI辅助更好” 低 理论推导 + 轶事 0个对照实验 “规范优先能加速API开发” 中 商业案例9（缺独立验证） 1)^ 1（高质量）
"当前SDD工具有可用性问题" 中-高 专家评测^[6](#断言 证据质量 证据类型 来源数量 “无约束AI辅助有安全/质量风险” 高 多源独立实证 4+ “AI辅助不一定提升生产力” 高 RCT4 1（高质量） “当前SDD工具有可用性问题” 中-高 专家评测6 + 技术雷达确认7 2 “SDD比无约束AI辅助更好” 低 理论推导 + 轶事 0个对照实验 “规范优先能加速API开发” 中 商业案例9（缺独立验证） 1)^ + 技术雷达确认^[7](#断言 证据质量 证据类型 来源数量 “无约束AI辅助有安全/质量风险” 高 多源独立实证 4+ “AI辅助不一定提升生产力” 高 RCT4 1（高质量） “当前SDD工具有可用性问题” 中-高 专家评测6 + 技术雷达确认7 2 “SDD比无约束AI辅助更好” 低 理论推导 + 轶事 0个对照实验 “规范优先能加速API开发” 中 商业案例9（缺独立验证） 1)^ 2
"SDD比无约束AI辅助更好" 低 理论推导 + 轶事 0个对照实验
"规范优先能加速API开发" 中 商业案例^[9](#断言 证据质量 证据类型 来源数量 “无约束AI辅助有安全/质量风险” 高 多源独立实证 4+ “AI辅助不一定提升生产力” 高 RCT4 1（高质量） “当前SDD工具有可用性问题” 中-高 专家评测6 + 技术雷达确认7 2 “SDD比无约束AI辅助更好” 低 理论推导 + 轶事 0个对照实验 “规范优先能加速API开发” 中 商业案例9（缺独立验证） 1)^（缺独立验证） 1

8.2 最大的证据缺口

缺口一（最关键）：没有"SDD+AI" vs "裸AI" vs "纯手工"的对照实验。

缺口二：没有长期追踪数据（SDD工具存在不到1年）。

缺口三：没有规模化团队使用的公开报告。

8.3 对"SDD有效"的最强间接证据

  1. Contract-First的15年实践：规范优先在API层面已被验证有效
  2. METR研究揭示的机制：AI让人变慢的因素（"代码不符合项目风格"）可能被SDD缓解
  3. 逻辑论证 [2](#2)：更明确的输入→更少的猜测→更少的错误（但"清晰逻辑"≠"已验证效果"）

9. 系统性批评与反驳

9.1 批评一："Bitter Lesson"------规则不如学习

Thoughtworks技术雷达[7](#Thoughtworks技术雷达7)：

"We may be relearning a bitter lesson --- that handcrafting detailed rules for AI ultimately doesn't scale."

反驳：Bitter Lesson假设计算力无限增长；即使模型变强，"明确表达意图"的沟通价值仍在。

本文判断 ：这是最深刻的批评 ------它质疑SDD的长期生命力。短期有价值；长期取决于AI能力阶梯式跃升是否发生。

9.2 批评二：SDD是瀑布模型的回归

反驳 ：SDD可以按Story粒度迭代应用；AI将"规范→代码"时间压缩到分钟级；Spec Kit明确支持迭代模式[8](#8)。

本文判断 ：批评部分有效。关键在于粒度控制------如果被滥用为"写完所有规范才编码"，确实是瀑布回归。

9.3 批评三：虚假控制感

"Just because the context windows are larger, doesn't mean that AI will properly pick up on everything that's in there."[6](#6)

本文判断 ：当前有效的批评。SDD面临的根本挑战：如果AI不可靠地遵守规范，规范的约束价值就打折扣。这依赖基础模型进步。

9.4 批评四：审查负担转移而非消除

Böckeler："I'd rather review code than all these markdown files"[6](#6)

本文判断 ：因人而异。对技术熟练者，审查代码可能更高效；对非技术利益相关者，审查规范更现实。

9.5 批评五：MDD幽灵

"I wonder if spec-as-source might end up with the downsides of both MDD and LLMs: Inflexibility and non-determinism."[6](#6)

本文判断：Level 3 (Spec-as-source)面临此风险最高；Level 1 (Spec-first)风险最低。

10. 开放问题与未来研究方向

10.1 亟需回答的实证问题

  1. SDD对照实验：在相同任务上比较"SDD+AI" vs "裸AI" vs "纯手工"
  2. 规范维护的长期成本：6个月后规范与代码是否漂移？
  3. 任务大小的盈亏平衡点：多大的任务SDD收益超过开销？
  4. 团队vs个人：SDD在协作中的价值是否显著高于个人使用？

10.2 可观察的技术趋势

  1. 规范的自动化生成 ：从代码反向生成规范（Tessl的tessl document）
  2. "意图工程"融合：规范与Prompt工程边界模糊化
  3. IDE原生集成：SDD可能从"显式Markdown文件"演变为"IDE内置智能约束层"
  4. METR 2026年2月更新^[4](#METR 2026年2月更新4)^：追踪late-2025 AI工具的生产力影响------可能改变结论

11. 结论与审慎建议

11.1 核心结论

结论一：SDD的核心理念------"在让AI编码前先明确意图"------具有理论合理性。这是"先想清楚再动手"的永恒原则在AI时代的表达。

结论二：当前SDD术语存在严重语义扩散，三个工具对SDD的理解大相径庭（spec-first到spec-as-source），且都处于早期。

结论三 ：SDD相对于"普通AI辅助"的优越性尚缺乏对照实验验证。我们有充分理由相信它有价值（理论推导+Vibe Coding负面证据），但这与"已被证明"之间存在重要区别。

结论四 ：当前工具面临真实可用性问题（尺寸不适配、审查疲劳、AI无视规范[6](#6)），限制了实用价值。

结论五 ：SDD最可能的适用范围是中等规模绿地项目功能开发------太小则开销过大，太大则规范难以完备，棕地引入困难。

11.2 分层建议

对象 建议 风险级别
个人开发者 用AI前花5-10分钟写结构化需求（零成本spec-first） 无风险
团队试点 新API尝试OpenAPI-first + 代码生成 低风险
SDD工具采用 除非愿意承担早期采用者不稳定性，否则等待成熟 中风险
组织级推行 不建议现在强制推行，鼓励试点收集数据 需谨慎

11.3 最终反思

"The past has shown that the best way for us to stay in control of what we're building are small, iterative steps."

--- Böckeler[6](#6)
"We're moving from 'code is the source of truth' to 'intent is the source of truth.'"

--- GitHub Blog[2](#2)

这两句话代表了讨论的两极。

SDD之所以在2025年重新成为可能，不是因为"规范"变了，而是因为"从规范到代码"的成本趋近于零了。 这一变化是真实的、不可逆的。但它不自动意味着一切都应变成规范------正如打字机降低了写作成本，并不意味着每个想法都值得写成书。

最审慎的立场是：保持spec-first的习惯（这永远不会错），但对SDD工具和流程保持批判性评估------直到有更充分的对照实验证据。

12. 参考文献

本文完成于2026年5月30日。鉴于SDD领域的快速演变，文中结论的有效期可能有限。

  1. Karpathy, A. (2025, February 2). "There's a new kind of coding I call 'vibe coding'..." X (Twitter) . https://x.com/karpathy/status/1886192184808149383 ↩︎ ↩︎

  2. Delimarsky, D. (2025, September 2). "Spec-driven development with AI: Get started with a new open source toolkit." GitHub Blog . https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. Amazon. (2025-2026). Kiro Official Website . https://kiro.dev/ ↩︎ ↩︎ ↩︎

  4. Becker, J., Rush, N., Barnes, E., & Rein, D. (2025, July 10). "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." METR . arXiv:2507.09089. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. Koren, M., Békés, G., Hinz, J., & Lohmann, A. (2026, January 21). "Vibe Coding Kills Open Source." arXiv:2601.15494v1 . ↩︎

  6. Böckeler, B. (2025, October 15). "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl." martinfowler.com . https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  7. Thoughtworks. (2025, November). "Spec-driven development." Technology Radar Vol. 34 , Assess. https://www.thoughtworks.com/radar/techniques/spec-driven-development ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  8. GitHub. (2025-2026). "Specification-Driven Development (SDD)." spec-kit repository, spec-driven.md . https://github.com/github/spec-kit/blob/main/spec-driven.md ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  9. Specmatic. (2025-2026). Official Website . https://specmatic.io/ ↩︎ ↩︎ ↩︎

  10. Microsoft. (2025-2026). TypeSpec . https://typespec.io/ ↩︎ ↩︎

  11. Wikipedia contributors. (2025). "Model-driven engineering." Wikipedia . https://en.wikipedia.org/wiki/Model-driven_engineering ↩︎ ↩︎

  12. Wikipedia contributors. (2026). "Vibe coding." Wikipedia . https://en.wikipedia.org/wiki/Vibe_coding ↩︎ ↩︎

  13. Loker, D. (2025, December 17). "Our new report: AI code creates 1.7x more problems." CodeRabbit Blog . ↩︎ ↩︎

  14. Doerrfeld, B. (2025, February 19). "How AI generated code compounds technical debt." LeadDev . ↩︎ ↩︎

  15. OpenAPI Tools. (2025-2026). OpenAPI Generator . https://openapi-generator.tech/ ↩︎

相关推荐
Raink老师1 小时前
【AI面试临阵磨枪-088】Skill 如何做参数校验、依赖注入、权限控制、超时、重试、幂等？
人工智能·面试·职场和发展
城事漫游Molly1 小时前
AI与质性研究的融合（三）：AI赋能质性数据分析——从编码到理论构建的新范式
大数据·人工智能·机器学习·prompt·ai for science·智能体·定性研究
chenying9981791 小时前
语音克隆模型的难点之一：音素对齐及交叉注意力早期失效问题 （兼论旋转位置编码）——F5-TTS、SupertonicTTS、VoxFlash-TTS 对比
人工智能·实时音视频·语音合成·tts·语音克隆
凯丨1 小时前
会“做梦“的 AI：用一句话生成可以玩的世界——读懂世界模型 Genie 3
人工智能·microsoft
踏着七彩祥云的小丑1 小时前
AI学习——记忆系统
人工智能·学习·ai
ACP广源盛139246256731 小时前
GSV2221@ACP# 高带宽低功耗显示转换芯片，赋能 TRAE SOLO 设备高清扩展升级
人工智能·嵌入式硬件·电脑·音视频
大强同学1 小时前
我用 Claude Code，把 NotebookLM 变成了 Obsidian 插件
人工智能·agent·claude·skill·notebooklm
J2虾虾2 小时前
Spring AI Alibaba - Memory 短期记忆
人工智能·spring·microsoft
刘一说2 小时前
AI科技热点日报 | 2026年5月30日
人工智能·科技
热门推荐
01GitHub 镜像站点02【AI】2026 年具身智能模型和世界模型总结03DeepSeek V4 + Claude Code thinking mode 400 错误修复方案04【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法05Codex 接入 DeepSeek API 完整配置文档06裂开！ChatGPT 居然开始要手机号验证，附详细解决方法07几个好用的ip纯净度检测网站08CC-Switch & Claude 基于 Linux 服务器安装使用指南09CC-Switch 全平台下载、安装与使用全指南（Windows/macOS/Linux）10API Key 登录 Codex 也能用插件了，还支持会话删除和导出