目录

在 AI 代写代码的时代，更具价值的技能正从「写代码的能力」转向「写规格的能力」。象征这一趋势的，正是规格驱动开发（Spec-Driven Development，SDD）。2026 年，Claude Code、GitHub、AWS 等主要工具纷纷支持它，作为 vibe coding 的「下一步」而备受关注。

本文将面向初学者，梳理规格驱动开发是什么、为何现在需要它、基本的四个步骤、主要工具，以及如何与 vibe coding 搭配取舍。

SPEC-DRIVEN DEVELOPMENT · 规格当主角

「Specify → Plan → Tasks → Implement」

— 每一步都留下文档，让 AI 无须猜测

STEP 1

Specify

用文字把要做什么写清楚。

STEP 2

Plan

补上设计、技术与约束。

STEP 3

Tasks

拆解为可逐项审查的小单元。

STEP 4

Implement

AI 依照规格进行实现。

1. 什么是规格驱动开发（SDD）？

规格驱动开发，是一种把「规格（spec）」当作项目主角（中心文档），并由此让 AI 推导出实现的开发方式。它不是一上来就让 AI 写代码，而是先把「做什么、怎么做」整理成结构化的文档，再由 AI 智能体读取这份规格来设计、拆解与实现。

可以把它想象成「盖房子前的设计图」。如果没有设计图就让木匠「随便盖得好看点」，成品就会参差不齐、返工频繁。AI 智能体也一样，含糊的指令会催生「猜测」。先把规格这张设计图定下来，就能减少 AI 迷失方向、擅自实现的余地。

💡 一句话概括：SDD ＝「在写代码之前先写规格」的开发。规格是「正本」，代码是由它生成的派生物。从上下文工程的视角看，规格也是你能交给 AI 的最佳「上下文」。

2. 为何是现在？vibe coding 的「三个月之墙」

vibe coding（边随兴对话边开发的方式）能以极快的速度产出原型，但规模一大就容易崩塌。在媒体报道和实务中，常有人提到：凭一时冲劲写出的代码，大约三个月就会撞上「技术债之墙」，维护成本随之膨胀。AI 生成后被原样搁置的代码大量留存于生产环境，事后再也无从修复。

规格驱动开发能在设计阶段就消除这种「需求漂移（drift）」。先把规格定下来，前期会多花些功夫，但能让后续的「返工」大幅减少。GitHub 报告称，使用其自家工具后，「从零重做」的次数大致减少了一个数量级（* 厂商报告数值）。

VIBE CODING

快速 · 适合探索

  • 原型与验证极快
  • 可边对话边探索方向
  • 但规模一大就容易崩塌
  • 需求漂移、债务不断累积
SPEC-DRIVEN DEVELOPMENT

易维护 · 适合交付

  • 规格是「正本」，迷失更少
  • 从设计上防止需求漂移
  • 前期投入更多
  • 返工大幅减少，更易维护

甚至有人说「2026 年，让工程师拉开差距的，是写规格的能力胜过写代码的能力」。交给 AI 的范围越广，人类的工作就越发转向「精确定义要做什么」。

3. 基本流程——四个步骤

不同工具的叫法略有差异，但规格驱动开发大体都遵循同样的四个步骤。关键在于，每一步都留下一份文档（多为 Markdown 文件），供下一步读取。诀窍是不要把信息只放在 AI 的「脑子里」。

① Specify

用文字描述要做什么——功能、目的、用户、验收条件。

② Plan（设计）

补上怎么做：架构、要用的库以及约束。

③ Tasks（拆解）

把计划拆成可逐项审查的小单元，能一项一项地确认。

④ Implement

AI 对照规格逐个任务地实现。人类专注于审查与批准。

⚠️ 人工审查是必须的：即便采用规格驱动，也绝不能省略对 AI 生成代码的检查。SDD 不是「甩手不管」的工具，而是让人更容易掌舵的机制。

4. 主要工具（Spec Kit、Kiro 等）

截至 2026 年，多数主流编码智能体都支持 SDD。下面列举几个代表。

GitHub Spec Kit

一款开源 CLI（在 GitHub 上拥有 9 万以上星标）。它支持 Specify → Plan → Tasks → Implement，并可与 Claude Code、GitHub Copilot 等 30 多种智能体配合使用。

AWS Kiro

它会先走完 Requirements → Design → Tasks 三个阶段，再生成代码；配备能按任务挑选最佳模型的 Auto 路由器，CLI 与网页端均可使用。

其他

BMAD、OpenSpec、Tessl、Google Antigravity、Cursor 也都提供各自的 SDD 流程。大多数主流工具都以某种形式支持它。

其实不必依赖专用工具——只要「先用 Markdown 写好规格，让 AI 读完再去实现」，就能实践这套思路。这样做还能让 AI 无视你规则的问题更少发生，因为你是以一份清晰的文档把规格交了出去。

5. 与 vibe coding 的搭配取舍

重要的不是「哪一个对」，而是「何时用哪一个」。2026 年务实的答案是混合（hybrid）——探索用 vibe，交付用规格驱动。

  • 适合 vibe coding 的场景：验证想法、一次性的原型、一个人小规模试做。只想尽快做出「某个东西」的阶段。
  • 适合规格驱动的场景：需要长期维护的生产系统、团队开发、规格至关重要的产品。当你着眼于整个开发生命周期时。

也就是说：先用 vibe 迅速找到方向，一旦决定就这么做，再把它落到规格里仔细打磨。两者并非对立——按阶段分别使用才是聪明之举。

6. 如何从今天开始尝试

不必立刻安装任何专用工具，也能从小处起步。

  • 先写一页规格：针对想做的功能，把「目的、输入/输出、验收条件」以要点形式写进 Markdown。
  • 让 AI 读完规格再请它写代码：告诉它「请严格按这份规格实现；有任何含糊之处来问我」。别一上来就说「做出来」。
  • 把任务切小：不要一次全做，而是实现一个功能、审查、再下一个。把流程整理进 Claude Skills 能提升可复现性。
  • 持续更新规格：一旦有变更，先改规格再改代码。让规格保持为「正本」，正是 SDD 的核心。

💡 对初学者同样有效：当你用 AI 做应用时，仅仅先写好规格，就能显著提升成品质量。即便你不擅长编程，也能用上这个技巧。

总结

把规格驱动开发归纳为三点。

  • 是什么：在代码之前先写「规格」，并把它当作「正本」让 AI 来实现。规格是中心文档。
  • 为什么：因为它能在设计阶段防止 vibe coding 的「需求漂移与技术债」，并减少返工。
  • 怎么用：探索用 vibe、交付用规格驱动的混合方式。人工审查是必须的。

先从「动手之前先写一页规格」开始吧。在 AI 时代，脱颖而出的不是写代码最快的人，而是能精确定义要做什么的人。配合阅读 vibe coding 和上下文工程，能让你把握 AI 开发的全貌。

FAQ

Q. 编程初学者也能做规格驱动开发吗？

A. 能——甚至可以说对初学者最有效。在写任何代码之前，只要用文字把「要做什么」理清楚，就能让 AI 的输出更稳定、质量更高。无需专用工具，从 Markdown 笔记就能起步。

Q. vibe coding 现在过时了吗？

A. 没有。对探索和原型而言，vibe coding 依旧最快。这不是新旧之争——按阶段分别使用才是 2026 年的主流：探索用 vibe，进入生产则用规格驱动。

Q. 规格应该写得多详细？

A. 以能传达「目的、输入/输出、验收条件」的粒度为准。太细会僵化，太含糊则会让 AI 猜测。就像一个好提示词的六个要素那样，瞄准既具体又灵活的中间地带。

Q. 用了 SDD 就不需要代码审查了吗？

A. 不。即便采用规格驱动，人工审查仍是必须的。SDD 是把 AI 引向正确方向的机制，而非省略检查的工具。只有当人对规格与实现两者都做过审查，才能安全地交付。