从 Vibe Coding 到 Spec Coding

前面几章讲的都是怎么用 AI 编程。这一章讲的是怎么用对 AI 编程。

区别在哪里？用 AI 写代码谁都会。打开 Cursor，随便说几句，AI 就开始写了。但写出来的代码是不是你想要的？能不能直接用？需不需要反复修改？这些问题的答案，取决于你用的方法。

2025 年的 AI 编程世界里，有两种截然不同的方法论：Vibe Coding 和 Spec Coding。

什么是 Vibe Coding

Vibe Coding，可以翻译成"氛围编程"或"凭感觉写代码"。它的做法是：你有一个模糊的想法，告诉 AI，AI 开始写代码，写出来不太对，你再补充一些信息，AI 再改，来来回回，最后勉强凑出一个能跑的东西。

这种方式有几个问题。首先，需求是散落在聊天历史里的。你说一句，AI 理解一点，过几轮对话 AI 把前面的需求忘了。其次，AI 做的很多技术决策你没有参与，可能选了不合适的方案。最后，代码写完了，但你也不太清楚它具体实现了什么，文档也没有。

对于一个人随便折腾的小项目，Vibe Coding 问题不大。大不了就是一坨屎山代码，反正只有你自己用。但在团队里，如果每个人都这么干，最后就是一座巨型屎山。直到某一天 CTO 受不了了，痛定思痛说：这个项目我们重构吧。

什么是 Spec Coding

Spec Coding，规范驱动开发，是完全相反的思路。核心原则是：在写任何代码之前，先把规范写清楚。

这里说的规范不是那种几百页的需求文档。它可以是一个简单的 Markdown 文件，描述你要做什么、为什么做、怎么做、验收标准是什么。关键是形成一个明确的、可执行的蓝图，然后 AI 根据这个蓝图来写代码。

为什么要这样做？因为 AI 写代码的能力和理解需求的能力是不对等的。它可以很快地写出一堆代码，但如果需求不清晰，写出来的代码只是"看起来像那么回事"，实际上可能完全不是你想要的。

前期工作准备得越充分，AI 写代码就越能够一次性到位。这个道理其实很简单，但很多人不愿意做。觉得写文档太繁琐，不如直接让 AI 动手。结果就是后期反复修改，浪费更多时间。

软件工程早就告诉我们一件事：完成一个项目会产生大量文档——需求文档、设计文档、测试文档、部署文档。代码只是其中一个环节。AI 时代没有改变这个本质，只是把写文档和写代码的过程都加速了。

规范驱动开发的工作流

一个典型的 Spec Coding 工作流是这样的。

首先是定义阶段。你用自然语言描述你要做什么。比如"我要给网站加一个用户评论功能"。这时候你和 AI 讨论需求细节，来回几轮对话，把评论功能具体包括什么、不包括什么、有什么特殊要求都聊清楚。AI 帮你把这些整理成一个 requirements.md 文件。

然后是设计阶段。需求清楚了，开始讨论怎么实现。评论功能需要改哪些数据库表？API 接口怎么设计？前端组件怎么组织？这些技术决策不是 AI 一个人做的，是你们一起讨论的。讨论完形成一个 design.md 文件。

接着是任务拆分阶段。把设计拆成具体的任务。任务 1 是创建评论表，任务 2 是写后端 API，任务 3 是前端评论组件……形成一个 tasks.md 文件，每个任务有明确的边界和验收标准。

最后才是实现阶段。AI 按照任务列表一个个完成，每完成一个就标记一下。你 review 代码，确认符合预期，再继续下一个。

这个流程看起来繁琐，但实际上比 Vibe Coding 更高效。因为大量的返工被前期的规范工作消除了。需求聊个三五轮，代码一次到位——这是真实体验。

工具支持：GitHub Spec Kit

2025 年 GitHub 官方发布了一个叫 Spec Kit 的开源工具包，专门支持规范驱动开发。

Spec Kit 的设计思路是把规范变成"可执行的蓝图"。它定义了四个阶段：Specify（定义目标和用户成果）、Plan（规划架构和约束）、Tasks（拆分成可测试的任务单元）、Implement（AI 逐步实现并接受 review）。每个阶段都需要验证通过才能进入下一个阶段。

使用方法是通过一系列斜杠命令。比如 /speckit.constitution 用来定义项目的核心原则、编码规范、安全策略；/speckit.specify 用来创建具体功能的规范；/speckit.plan 用来制定技术计划；/speckit.tasks 用来生成可执行的任务列表。

Spec Kit 的亮点是它可以和各种 AI 工具配合使用——GitHub Copilot、Claude Code、Gemini CLI 都可以。而且它强调规范是一个"活文档"，会随着项目演进不断更新。

这个工具特别适合从 0 到 1 的新项目，尤其是企业级团队需要清晰度、合规性和可追溯性的场景。

项目地址：github.com/github/spec-kit

工具支持：OpenSpec

另一个值得关注的工具是 OpenSpec，由 Fission AI 开发。

和 Spec Kit 相比，OpenSpec 更轻量、更敏捷。它的设计目标是让规范驱动开发能快速融入你现有的工作流，特别适合改造已有项目（所谓的"brownfield"项目）。

OpenSpec 的工作流程更简单：提议（propose）一个变更，AI 审核并实施，然后归档（archive）。每一个 proposal 都是一个独立的文档，记录这次变更的目标、方案和验收标准。

安装方法很简单：

npm install -g @fission-ai/openspec@latest

然后在项目目录里执行：

openspec init

它会问你用什么 AI 工具，然后在项目里创建一个 openspec 文件夹，并给你一段提示词让你发给 AI。AI 读了这段提示词之后，就知道怎么按照 OpenSpec 的规范来工作了。

我自己的实践是这样的：如果我想给项目加一个新功能，不再是想到一出是一出，而是先让 AI 生成一个 OpenSpec proposal。有时候我有很多想法但不着急实现，就先让 AI 把这些想法都做成 proposal 放着。后续实现一个，就归档一个。

OpenSpec 配合 2025 年最新的 Claude Opus 4.5 模型，基本上需求聊三五轮，代码就能一次到位。这种体验确实让人"卧槽"。

项目地址：github.com/Fission-AI/OpenSpec

AWS Kiro：IDE 级别的 Spec 支持

2025 年 7 月，AWS 发布了一个新的 AI IDE 叫 Kiro。它直接把规范驱动开发内置到了 IDE 里，不需要安装额外的工具。

Kiro 的设计理念是：你只需要用自然语言描述你想做什么，Kiro 会自动帮你生成三个文件。第一个是 requirements.md，包含用户故事和验收标准。第二个是 design.md，包含技术架构、序列图和实现注意事项。第三个是 tasks.md，是具体的任务清单。

然后 AI 根据这些规范文件来写代码，每完成一个任务就在任务清单上打勾。你可以看到进度，可以随时介入 review。

Kiro 还有一个叫 Hooks 的功能，可以设置触发条件。比如每次文件保存后自动跑测试，每次提交前自动检查安全问题。这让规范驱动不只是写代码的规范，也包括了工作流程的规范。

另外 Kiro 支持 MCP（Model Context Protocol），可以连接外部数据源和工具。和 AWS 服务的深度集成也是它的卖点。

当然，你不一定要用 Kiro。即使用 Cursor 或者 Windsurf，也可以手动在项目里创建 docs 文件夹，按照 requirements.md、design.md、tasks.md 的结构来组织规范文档。AI 看到这些文档自然就会按照规范来工作。工具只是辅助，方法论才是核心。

更轻量的方法：PDD

如果觉得 Spec Coding 还是太重，有一个更轻量的变体叫 PDD（Prompt Driven Development），提示驱动开发。

PDD 的核心是四个步骤。

第一步是 Context Curation，喂料。不要直接问 AI。先收集这次任务需要的上下文——相关的文档、类型定义、数据库 schema——用 @ 符号喂给 AI。上下文越准确，AI 的输出就越靠谱。

第二步是 Intent Definition，下指令。写伪代码和注释，而不是让 AI 自己想。比如"写一个函数，处理用户登录，参考 @AuthService 的逻辑，返回 JWT token，处理密码错误和账号被锁定两种异常"。这比直接说"帮我写登录功能"精确得多。

第三步是 AI Generation & Iteration，生成与迭代。AI 生成代码，你跑一下，有错误把 error log 甩回给 AI，让它自己修。来回几次直到跑通。

第四步是 Expert Review，专家审核。代码跑通不等于代码正确。你作为"架构师"要检查安全性、性能、业务逻辑是否正确。AI 不会替你做这个判断。

PDD 比 Spec Coding 轻很多，适合规模不大的任务。它的核心思想和 Spec Coding 是一致的：先想清楚再动手，而不是让 AI 瞎猜。

落地的挑战

规范驱动开发虽然好，但落地有困难。

最大的挑战是习惯问题。很多开发者觉得"明明我用 AI 一句话就能解决，为什么非要先写规范文档"。对于简单任务确实如此。但对于复杂任务，先写规范反而更快。这个转变需要亲身体验才能理解。

另一个挑战是维护成本。如果规范文档和代码脱节，规范就变成了形式主义。代码改了文档没改，下次 AI 读了过期的文档，写出来的代码更有问题。解决方法是把更新文档作为每次任务的一部分——代码改完，规范文档也要相应更新。

团队协作的挑战更大。Spec Coding 不只是一个工具的问题，是整个开发流程的变革。它需要配合 Git 工作流的改造、Code Review 标准的升级。团队里有人坚持写规范，有人坚持 Vibe Coding，最后的代码质量还是会参差不齐。

Spec Coding 的本质不是工具，而是流程变革。 工具免费，但"让工具在团队里跑通"的经验，才是最昂贵的。

我的实践建议

根据这些原则来选择方法：

个人小项目，时间紧，随便折腾——用 Vibe Coding 没问题。反正只有你自己看代码，效率优先。

个人正式项目，打算长期维护——建议用 OpenSpec 或类似的轻量规范。每次改功能先写一个 proposal，实现完归档。这样几个月后你还能知道当时为什么这么做。

团队项目，多人协作——必须用规范驱动开发。可以用 Spec Kit，可以用 Kiro，也可以自己定义规范模板。关键是团队达成一致，每个人都遵守。

企业级项目，需要合规和审计——全流程规范驱动。需求、设计、任务、代码都有文档可追溯。这时候 Spec Kit 或者 Kiro 的价值最大。

还有一个建议：从小处开始。不要一上来就想着改变整个团队的工作流。先自己试试，在一个小功能上用规范驱动开发的方式做一遍，体验差异，再考虑推广。

下一章是 OpenSpec 实操教程。上面讲了为什么要做 Spec Coding，下一章手把手演示怎么用 OpenSpec——从安装初始化到完整的项目案例，让你真正把规范驱动开发跑起来。