Spec-Driven Development (SDD)

来源： wiki/sources/wechat-batch-a-agent-dev-tools
相关概念： wiki/concepts/harness-engineering, wiki/concepts/vibe-coding-to-sdd, wiki/concepts/harness-architecture

Spec-Driven Development（SDD）是一种以规格说明（Specification）作为唯一真实来源（Single Source of Truth）、代码作为其派生产物的 AI 编程方法论。核心原则：先定义 WHAT，再让 AI 做 HOW。

定义

"SDD is version control for your thinking." — Microsoft

传统版本控制管理代码的演变历史；SDD 管理的是思考的演变历史——为什么做这个功能、边界在哪里、成功标准是什么。当代码可以被 AI 秒级重写时，真正有价值的不是代码本身，而是代码背后的决策。

四阶段模型

三文件体系（Spec Kit）

GitHub 的 Spec Kit 提出标准工具链：

1. spec.md — 需求规格：回答"做什么"和"为什么做"，不涉及"怎么做"
2. plan.md — 架构方案：基于 spec 生成的技术方案，AI 起草、人审核
3. tasks.md — 任务清单：将 plan 拆解为可执行的原子任务
4. constitution.md — 项目级"宪法"：不可违背的约束条件，所有 Spec 必须遵守

好 Spec 的六要素

1. Problem Statement — 定义"为什么做"
2. Success Metrics — 定义"做到什么程度算完"（必须可测试，如"P95 < 50ms"）
3. User Stories — 定义"谁在什么场景下用"
4. Acceptance Criteria — 定义"怎么验证"
5. Non-Goals — 定义"什么不做"（防止 AI 自作主张）
6. Constraints — 定义"技术约束"

粒度检验标准： "用不同技术栈实现这个 Spec，Spec 是否仍然有效？"如果答案是否，说明混入了 HOW。

工具生态

实战数据

• 成功案例：5 人 7 天用 Qoder 开发 QoderWork，完成传统需要 20 人数周的工作量
• 效率提升：API 变更周期缩短 75%（arXiv 金融领域论文）
• 质量提升：人工精炼 Spec 可将 LLM 代码错误减少 50%
• 规模化验证：Stripe 通过 Harness Engineering + SDD 交付 1,300 个 AI PR

失败数据对比

• 无 Spec 约束：45% 的 AI 生成代码包含安全漏洞（Veracode 2025）
• AI 编程时代：代码重复率 4 年增长 4 倍（GitClear 2.11 亿行研究）

五大陷阱

1. 过度规格化 — Spec 写得比代码还长，退化为伪代码
2. 规格腐烂 — 代码迭代了十几个版本，Spec 还在 V1
3. 规格官僚化 — 改一个按钮颜色也要走全流程
4. 上下文依赖陷阱 — Spec 里混入了 HOW
5. AI 猜测空间未消除 — 成功标准模糊

与 Vibe Coding 的关系

SDD 和 Vibe Coding 不是对立，而是光谱的两端：
- 探索阶段用 Vibe Coding — 快速试错
- 一旦决定要做 — 立刻补 Spec
- 进入正式开发 — 严格 SDD

Vibe Coding "三个月墙"规律：兴奋期（1-3月）→ 平台期（4-9月）→ 衰退期（10-15月），因为本质是零上下文编程。

与 Harness Engineering 的关系

SDD 位于 Context Engineering 和 Harness Engineering 的交叉地带：
- constitution.md = 约束层
- spec.md = 需求层
- plan.md = 执行层
- tasks.md = 调度层

四层组合构成完整的"AI 驾驭框架"（Harness）。

创建于：2026-06-16 | 基于微信公众号文章合集批次 A