Spec-Driven Development：起源、方法论、工具与炒作背后的真相

2026年3月13日

可用 - Kiro：kiro.dev 提供免费计划

spec-driven-development
sdd
methodology
ai-agents
kiro
claude-code
vibe-coding
news-date:2026-03-13
created-at:2026-03-13
updated-at:2026-03-13

tl;dr — SDD 是对真实问题的合理回应。概念有意义，工具尚未成熟，成本较高，ROI 证据几乎仍停留在轶事层面。值得理解，也值得保持怀疑。

核心问题

2025 年，Claude Code、Cursor、Codex 等 AI 代理已不再是”美化版自动补全”，而是能够自主执行复杂任务的工具。随之而来的是 vibe coding：你用自然语言描述需求，代理生成数百行代码，你在没有完全理解的情况下批准。

结果是：代码能跑，直到需要维护的那一天。架构决策隐形。技术债以工业速度累积。

METR 在 2025 年对有经验的开发者进行了一项严格研究（真实开源项目），结论是：使用 AI 工具的开发者平均比不使用时慢 19%。原因正是非结构化 prompt 引发的调试循环，吃掉了代码生成节省的所有时间。

Spec-Driven Development 是业界试图从根本上解决这个问题的答案。

什么是 Spec-Driven Development

SDD 是一种以规范（spec）为主要制品的开发方法论——不是代码。

传统流程是 prompt → 代码 → 迭代，SDD 的流程变为：

Spec → 计划 → 任务 → 代码

Spec 在任何实现之前就定义了意图、约束、验收标准和架构。AI 代理随后针对这个结构化输入执行，而不是解读一段模糊描述。

重要区别：使用 Kiro、Spec Kit、Tessl 等工具时，spec 本身由 AI 生成。你用自然语言描述目标，代理产出规范文件——通常是 requirements.md、design.md、tasks.md——然后在实现阶段以这些文件作为上下文。Spec 不是分析师手写的前期文档，而是开发者与代理对话的产物，出现在代码之前几分钟。

SDD 有三个采用层级：

Spec-first： spec 在实现前生成，用作当次任务的引导，完成后丢弃。
Spec-anchored： spec 在任务完成后继续维护，作为系统演进和后续维护的活文档。
Spec-as-source： 最激进的层级。Spec 就是源代码，生成的代码只是编译产物，标注 // GENERATED FROM SPEC - DO NOT EDIT。Tessl 正在尝试实现这一目标。

SDD Triangle： Drew Breunig 在 2026 年 3 月提出，spec、测试与代码是三个需要始终同步的节点。代码推进时 spec 要更新，spec 变化时要写新测试，测试失败时代码要改——有时 spec 本身也错了。保持三者同步很难，这是 SDD 最核心的挑战。

工具生态

SDD 工具空间在 2024 年底至 2026 年初爆发式增长。按层级划分：

第一层 — Spec 框架： 定义和管理规范制品 → Spec Kit、Tessl、Kiro、BMAD、OpenSpec、cc-sdd
第二层 — 计划与任务系统： 将 spec 转换为可执行任务图 → Taskmaster、Agent OS、Beads、Feature-Driven-Flow
第三层 — 执行代理： 编写和修改代码 → Claude Code、Cursor Agent、Codex、Devika、OpenDevin、CrewAI
第四层 — AI IDE： 将所有层级整合进单一工作流 → Kiro、Windsurf、Cursor、Claude Code、Copilot

大多数开发者目前只使用第三层——这正是 vibe coding 问题的所在。

工具对比

工具	类型	方法	状态
Spec Kit (GitHub)	CLI	宪法式 spec + 4 个阶段	开源，GA
Kiro (AWS)	IDE	EARS 符号，3 个文档	GA，免费层
Tessl	CLI + Registry	Spec-as-source（最激进）	封闭 Beta
BMAD	CLI	多代理，按角色分配 persona	开源
OpenSpec	CLI	提案 + 审批工作流	开源
Plumb	CLI	通过 git hooks 同步 spec/测试/代码	PoC（`pip install plumb-dev`）
smart-ralph	CLI	SDD 最小脚手架	开源

Kiro 实战

Kiro 是已在使用 VS Code 的开发者最易上手的切入点。它是 Code OSS 的 fork，由 AWS 内部小团队构建，刻意定位在 AWS 生态之外——你不需要 AWS 账户。访问 kiro.dev 下载安装包，用 GitHub 或 Google 登录即可。

三步工作流

第一步 — 需求

用自然语言描述你要构建什么。Kiro 将其翻译为 EARS（Easy Approach to Requirements Syntax）符号：

WHEN usuário submete formulário de login
  AND credenciais são válidas
THEN sistema deve autenticar o usuário
  AND redirecionar para o dashboard
  AND registrar o evento de login com timestamp

这种符号强制要求显式约束，且机器可读。你在进入下一步之前审查并调整生成的 requirements.md。

第二步 — 设计

Kiro 分析你现有的代码库，生成包含架构决策、技术栈选择和组件结构的 design.md。对于 React + Node.js 项目，输出示例：

## Architecture

Frontend: React 18 com React Router v6
Backend: Express 4.x com middleware JWT
Database: PostgreSQL via Prisma ORM
Auth: bcrypt (salt rounds: 12) + JWT (access: 15min, refresh: 7d)
Testing: Jest + Supertest para integração

你在任何代码生成之前审查这份文档。与项目实际架构的分歧在这里暴露——而不是在 400 行生成代码之后。

第三步 — 任务

Kiro 生成按依赖关系排序的 tasks.md：

- [ ] Task 1: Setup de banco de dados e schema de usuários
- [ ] Task 2: Endpoint POST /auth/register com validação Joi
- [ ] Task 3: Endpoint POST /auth/login com geração de tokens
- [ ] Task 4: Middleware de autenticação JWT
- [ ] Task 5: Endpoint POST /auth/refresh
- [ ] Task 6: Testes de integração para todos os endpoints

你控制执行哪些任务、何时执行。代理每次实现一个任务，任务之间有审查节点。

Steering files

Kiro 支持 steering files——为整个代码库定义持久性标准的配置文件：

# .kiro/steering/code-style.md
- Use TypeScript estrito, sem `any` implícito
- Prefira `async/await` sobre callbacks
- Nomes de variáveis em camelCase, constantes em SCREAMING_SNAKE_CASE
- Funções públicas devem ter JSDoc

Hooks

Kiro 支持基于事件的 hooks——在定义的触发器响应时自动启动的代理：

{
  "hooks": [
    {
      "name": "security-audit",
      "trigger": "on-save",
      "agent": "Verifique vulnerabilidades de segurança no arquivo salvo"
    },
    {
      "name": "test-generator",
      "trigger": "on-file-create",
      "pattern": "src/**/*.ts",
      "agent": "Gere testes unitários para o novo arquivo"
    }
  ]
}

有效之处： 在实现前审查设计文档，与在事后审查 500 行生成代码，有本质区别。问题在正确的层级暴露。Steering files 消除了大量关于风格和约定的重复 prompt。顺序任务流让代理上下文保持专注——一次一个问题，而不是整个系统。

不足之处： 在独立测试中，Kiro 为一个简单 bug fix 生成了 16 个验收标准。对小改动，overhead 是真实的。中等复杂度功能的 spec 生成需要 30–45 秒。EARS 符号有学习曲线，对没有正式规范经验的人不直观。Kiro 使用 Open VSX 扩展注册表（非微软官方），这意味着不支持 C#——对 .NET 团队是严重限制。Autopilot 模式（无监督执行多个任务）结果不够可预测，逐任务审批才是真正价值所在。

定价： Free（50 次交互/月）· Pro $19/月（1,000 次交互）· Pro+ $39/月（3,000 次交互）

真实代价

1. 前期工作违背开发者直觉

“spec 由 AI 快速生成”是真的，但”快速”不等于”免费”。在第一行有用代码之前，你要经过多轮审查：审查生成的 spec、纠正被误解的意图、调整架构计划、批准或拒绝任务。每一轮都需要真实的人工注意力。对中等复杂度的功能，这个 overhead 可能小于事后调试 vibe-coded 代码的成本；对一个简单 bug fix，代价远超收益。

2. 每个阶段都倍增的 token 成本

SDD 的每个阶段（spec → 计划 → 任务 → 实现）在生产代码写出之前就消耗 token。使用推理模型时，代理级别的使用量可能是标准使用量的 100 倍。重度 SDD 会话会定期触及上下文限制，自动压缩需要 3–12 分钟。目前没有公开基准对比 SDD 与直接开发的总成本（token + 人工审查时间）。

3. 迭代过程中的上下文降解

这是讨论最少却可能最严重的问题。AI 生成的 spec 在实现阶段被反馈给 AI。每次压缩或会话重启都会丢失细节。实现代码的代理无法完整访问规范代理记录的决策。结果：随着上下文降解，代码开始悄悄偏离 spec。

4. 部署后 spec 变得具有误导性

问题不是 spec 与代码之间的时间距离——现代 SDD 工具在同一周期内生成两者，相隔几分钟。真正的问题是部署后发生的事：边缘案例只在生产环境出现，用户真实行为与建模的不符，性能问题在负载下才暴露。Spec 不被更新。如果用于指导未来维护（spec-anchored），过时的 spec 会主动产生误导：代理信任它，基于已不存在的现实生成代码。

5. 无人真正管理的制品扩散

每个功能生成多个 markdown 文件。“代理保持 spec 最新”的隐性承诺站不住脚——有人需要以审查代码同等的严格性审查 spec 的每次变更。实践中这不会发生。Spec 积累、偏离代码，变成噪音而非信号。

6. Spec 不消除非确定性

同一份 spec 在不同执行中可能产生不同实现。更高的精度减少变化但增加编写成本。写得不好的 spec——团队刚接触这套方法论时最可能的结果——会产生组织良好但做错事情的代码。

7. AI 嵌入的瀑布开发风险

来自 Thoughtworks 和独立分析的最有结构性的批评：当前实践的 SDD 有成为**瀑布开发（加 AI）**的风险。你仍然在前期定义一切，期望现实配合。对于需求真正未知的探索性开发，以上下文为导向的方法适应性更好。

适用场景

SDD 适合：

企业团队，在大型既有代码库上开发，架构漂移代价高昂
受监管环境，需要审计追踪和需求可追溯性（EU AI Act、金融、医疗）
稳定领域，有明确合约：API、数据 schema、合规规则
有 TDD 或 BDD 成熟度的团队，希望将这种纪律延伸到 AI 层
仿真与移植：SDD 最亮眼的用例——用现有系统的测试作为规范，将系统重新实现到另一门语言

SDD 可能是过度工程：

个人项目和快速原型
需求真正未知的探索性开发
小改动或孤立 bug fix
没有纪律在实现后保持 spec 更新的团队

诊断

SDD 是对真实问题的合理回应。Vibe coding 产生代码的速度超过了团队的治理能力。Spec 是恢复这种治理的工具。

但与 TDD 的对比很有启发性。TDD 已有 25 年历史，有大量实证据，而严格意义上的市场实际采用率约为 8%（在代码之前始终编写测试）。SDD 正在产生炒作，因为它解决了代理时代的一个可见问题，但它继承了同样的根本挑战：开发者更愿意交付。任何增加前期工作的方法论都会与这种直觉作斗争。

容易找到好处、找不到权衡的方法论，仍处于营销阶段，尚未到成熟阶段。Spec-Driven Development 还没有完成这个验证。

值得关注的工具：Spec Kit（开源灵活性和 IDE 独立性）、Kiro（IDE 结构化工作流）、Tessl（最激进的 spec-as-source 愿景，尚未被证实）、Plumb（最难且尚未解决的问题的参考实现——在初始实现后保持 spec 活跃）。