规格驱动开发是什么
从 Vibe Coding 到规格驱动开发：理解 AI 编程如何从「直觉」升级到「工程」，掌握先写规格再写代码的新范式
引言
This approach succeeds where 'just prompting the AI' fails due to a basic truth about how language models work: they're exceptional at pattern completion, but not at mind reading.
2025 年 10 月，GitHub 开源了一个名为 Spec Kit 的工具包，正式将「规格驱动开发」（Spec-Driven Development）这一概念带入 AI 编程的视野。这个看似复古的理念——先写规格再写代码——正在成为驾驭 AI 编程工具的新范式。
如果你经常使用 Claude Code、Cursor 或 GitHub Copilot 这类 AI 编程助手，一定遇到过这样的困扰：你说「帮我添加一个用户登录功能」，AI 兴冲冲地写了一大堆代码，但等你仔细一看——用的是你不熟悉的框架、安全策略和你预期的不一样、UI 风格也对不上……然后你开始一轮又一轮地修正，直到精疲力尽。
问题出在哪里？不是 AI 不够聪明，而是你给的信息不够。「添加用户登录功能」这句话看似清晰，实际上隐藏了成百上千个未说明的决策：用什么认证方式？密码有什么要求？登录失败怎么处理？需要记住登录状态吗？支持第三方登录吗？……AI 不得不猜，而猜测意味着偏差。
规格驱动开发正是为了解决这个问题而生的。
Vibe Coding：速度的代价
2025 年初，前 Tesla AI 总监 Andrej Karpathy 创造了「Vibe Coding」这个词，描述一种「接受 AI 建议而不深入审查」的开发方式。这个词迅速走红，甚至被 Collins 词典评为 2025 年度词汇。
Vibe Coding 的诱惑显而易见：你描述一个想法，AI 生成代码，看起来能跑就行。对于快速原型、黑客马拉松、一次性脚本，这种方式确实高效。但当它被用于生产系统时，问题就来了。
We allowed a developer to vibe-code an entire user authentication flow... When we later needed to extend the auth system, it collapsed. No one could trace what was connected to what.
类似的故事在业界屡见不鲜：AI 生成的数据库查询在小规模测试中运行良好，但在真实流量下系统爬行；拼接的认证模块通过了 QA，但两周后发现停用账户仍可访问管理工具。根据 Final Round AI 的 2025 年调查，18 位 CTO 中有 16 位经历过 AI 生成代码导致的生产灾难。
这并不是说 Vibe Coding 毫无价值。关键在于识别边界：
| 场景 | Vibe Coding | 规格驱动开发 |
|---|---|---|
| 原型/演示 | ✓ 适合 | 过度 |
| 一次性脚本 | ✓ 适合 | 过度 |
| 生产功能 | 风险高 | ✓ 推荐 |
| 安全相关 | 危险 | ✓ 必须 |
| 团队协作 | 难维护 | ✓ 推荐 |
规格驱动开发正是为了在保持 AI 效率的同时，避免 Vibe Coding 的陷阱。
什么是规格驱动开发
规格驱动开发的核心理念可以用一句话概括：先定义「做什么」，再考虑「怎么做」。
这听起来像是软件工程的老生常谈，但在 AI 编程时代，它有了新的含义。传统的需求文档是写给人看的，往往冗长、模糊、充满行话。规格驱动开发中的「规格」是写给 AI 看的——简洁、结构化、可执行。
想象你要盖一栋房子。传统的 AI 编程方式就像你对施工队说「帮我盖一栋舒适的三居室」，然后让他们自己发挥。结果可能不错，但更可能和你想象的大相径庭。规格驱动开发则是先画好建筑蓝图：几层楼、每层多少平米、窗户朝向、材料规格……施工队按图施工，结果自然符合预期。
在 AI 编程中，这套蓝图就是规格文档（Specification）。它不关心用什么编程语言、什么框架，只关心功能要达成什么效果、用户要完成什么任务、成功的标准是什么。
与传统开发流程相比，规格驱动开发有一个根本的不同：
| 传统 AI 编程 | 规格驱动开发 |
|---|---|
| 直接描述需求 → AI 生成代码 | 需求 → 规格 → 计划 → 任务 → 代码 |
| AI 需要猜测大量细节 | 每一步都明确，AI 只需执行 |
| 返工频繁，沟通成本高 | 前期投入，后期顺畅 |
| 适合简单任务 | 适合复杂功能 |
这种「渐进式细化」的过程，正是规格驱动开发的精髓。你不是一步到位，而是通过多个阶段逐步明确需求，每个阶段都可以审核和调整。
Speckit 工作流程概览
GitHub 的 Spec Kit 和 Claude Code 中的 speckit 命令都遵循类似的工作流程，大致可以分为六个阶段：
Constitution → Specify → Clarify → Plan → Tasks → Implement
↓ ↓ ↓ ↓ ↓ ↓
项目宪法 功能规格 澄清模糊 技术计划 任务分解 执行实现1. Constitution（项目宪法）
项目宪法定义了整个项目的基本原则和约束，比如「测试优先」「简单至上」「API 优先」等。这些原则会贯穿后续所有阶段，确保 AI 生成的方案符合你的技术偏好。
2. Specify（功能规格）
这是核心的第一步。你用自然语言描述想要的功能，AI 帮你整理成结构化的规格文档，包括：
- 用户故事：谁要做什么，为什么
- 功能需求：系统必须具备的能力
- 成功标准：如何判断功能是否达标
重要的是，规格文档只关注「做什么」，不涉及「怎么做」——不提具体的技术栈、不写代码结构。
3. Clarify（澄清模糊）
AI 会检查规格中的模糊点，提出最多 5 个关键问题。这些问题通常涉及功能边界、用户类型、安全要求等。通过问答，规格变得更加清晰。
4. Plan（技术计划）
有了清晰的规格，才开始考虑技术方案。这一步会产出：
- 技术选型（语言、框架、数据库）
- 数据模型设计
- API 合约定义
- 研究报告（解决技术决策）
5. Tasks（任务分解）
将技术计划拆分成可执行的任务清单。每个任务都有明确的 ID、描述、文件路径，可以直接交给 AI 执行。任务按用户故事分组，支持并行开发。
6. Implement（执行实现）
按任务清单逐个执行。每完成一个任务就标记完成，确保可追溯。
这六个阶段的产出物形成了一条清晰的链条：
| 阶段 | 产出物 | 作用 |
|---|---|---|
| Constitution | constitution.md | 定义项目原则 |
| Specify | spec.md | 描述功能需求 |
| Clarify | 更新后的 spec.md | 消除模糊点 |
| Plan | plan.md, research.md | 技术方案设计 |
| Tasks | tasks.md | 可执行任务清单 |
| Implement | 实际代码 | 最终交付物 |
为什么这种方式有效
规格驱动开发之所以能在「直接让 AI 写代码」失败的地方成功，是因为它解决了 AI 编程的核心矛盾：信息不对称。
当你说「添加照片分享功能」时，你脑子里可能有一个完整的图景，但 AI 只看到这几个字。它必须猜测：分享到哪里？谁可以看？需要压缩吗？有水印吗？支持批量吗？……每一个猜测都可能是错的。
规格驱动开发通过「强制你先想清楚」来解决这个问题。当你被要求写下用户故事、功能需求、成功标准时，那些你以为「显而易见」的细节就会浮出水面。这个过程本身就有价值——即使不用 AI，把需求写清楚也能减少沟通成本。
此外，渐进式细化让错误更早暴露。在 Specify 阶段发现需求偏差，修改成本几乎为零；在代码写完后才发现，可能要推倒重来。
当然，规格驱动开发不是万能的。它有明确的适用场景：
适合的情况：
- 复杂功能开发（涉及多个模块、多种交互）
- 团队协作项目（规格文档作为沟通媒介）
- 对质量要求高的场景（需要可追溯、可验证）
不适合的情况：
- 简单的 bug 修复或小改动
- 探索性编程（还不知道要做什么）
- 时间极度紧迫（没空写规格）
关键是识别任务的复杂度。一个小时能完成的事情，不需要花一个小时写规格；一个星期的功能开发，花两个小时写规格绝对值得。
但规格不是银弹
需要澄清一个常见误解：规格驱动开发减少了猜测，但没有消除审查的需求。
即使有了完整的规格，AI 仍可能：
- 错过边界情况（规格没覆盖的极端场景）
- 生成不符合性能要求的代码
- 引入潜在的安全漏洞
- 产出风格不一致的实现
这就像建筑施工：即使有了详细蓝图，验收检查仍然必要。你不会因为施工队按图纸盖完房子就直接搬进去住——你会检查电路是否安全、管道是否通畅、门窗是否牢固。
If specs define intent and agents generate the code, do we need to review code anymore? Short answer: yes, absolutely.
规格驱动开发的价值在于让错误更容易被发现，而不是消除错误本身。
小结
规格驱动开发的核心是一个简单的道理：越是复杂的任务，越需要先想清楚再动手。AI 编程工具放大了这个道理的重要性——因为 AI 会忠实地执行你的指令，但无法真正理解你的意图。
The person who communicates the best will be the most valuable programmer in the future. The new scarce skill is writing specifications that fully capture your intent and values.
记住三个关键词：
| 关键词 | 含义 |
|---|---|
| 先规格后代码 | 定义「做什么」在前，考虑「怎么做」在后 |
| 渐进式细化 | 从模糊到清晰，每步都可审核调整 |
| 减少猜测 | 明确的规格 = AI 更少的推测空间 |
了解了理念之后，下一篇《Speckit 实践指南》将带你动手实践：如何使用 speckit 命令完成一个功能的规格驱动开发流程。
配合《Claude Skills》使用，可以将规格的执行进一步自动化和标准化。