写在前面
2025 年初，Andrej Karpathy 在 X 上提出了 “Vibe Coding” 这个概念：
“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
“I ‘Accept All’ always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment.”
说白了就是：完全信任 AI，不看代码，不读 diff，报错就贴，能跑就行。
用这种方式快速验证想法确实爽，但做稍微复杂点的东西，问题很快就来了：
- 对话长了，AI 开始”失忆”，前面定好的字段命名后面全忘了
- AI 自信地写出根本不存在的 API，编都不带眨眼的
- 改了登录逻辑，支付流程莫名其妙挂了
这些是 Vibe Coding 的经典坑，但让我更头疼的是另一类情况——过度设计：
- 让 AI 做个数据导出，它造了异步任务队列 + 分片下载 + 断点续传。其实就几千条数据，同步生成 Excel 直接下就行
- 让 AI 做个用户权限，它给我设计了 RBAC + ABAC + 权限继承。其实就管理员和普通用户两种角色
代码能跑，但复杂度远超需求，维护成本也跟着上去了。
有了 AI 能力之后，我的时间不该花在反复调教、改 BUG 上。我想要的很简单：快速完成满意的功能。
折腾了一段时间后，我摸索出一套工作流。用 Vibe 的方式探索方向，用 Spec 的方式保证质量。
这篇文章分享一下我的做法。
整体思路
我的做法分两个阶段：Vibe 发散 和 SDD 落地。
IMPORTANT
核心逻辑：先用 Vibe 的方式把方向聊对，再用 Spec 的方式把代码写对。
Vibe 阶段产出的研究报告，就是 SDD 阶段的输入。报告里定好了做什么、用什么技术、大致怎么拆分，后面写代码就不容易跑偏。
Vibe 阶段用来探索方向。idea 还不清晰的时候，跟 AI 聊，找可行性，定技术栈。这个阶段不写代码，只输出一份研究报告。
SDD 阶段用来保证质量。拿着研究报告进入 Coding Agent，用 OpenSpec 管理开发流程。先出 proposal，review 通过再写代码。
两个阶段的分工：Vibe 负责方向，SDD 负责执行。
用什么工具
这套流程可复制，工具可以换。
Vibe 阶段，我用 Gemini。你也可以用 ChatGPT、Claude 或其他擅长探讨的模型。
SDD 阶段，工具有几个选择：
- OpenSpec：我在用的，轻量、流程清晰，贴近实际开发流程
- Spec-Kit：GitHub 出的，64k stars，支持的 Coding Agent 更多
- 还有 Kiro、Tessl 等，可以参考 Martin Fowler 的对比文章
这些工具思路差不多，选一个顺手的就行。
Coding Agent 层面，Cursor、Claude Code、Codex、Gemini CLI 都能配合 SDD 工具用。
WARNING
不过有一点要说清楚：基座模型的质量直接决定产出质量。同样的流程，用 Claude 和用一个普通模型，效果差很多。我选 Claude Code 不是因为工具好用，而是因为 Claude 的代码能力目前最强。工具可以换，但模型质量不能妥协。
先聊方向
这个阶段要做的是把模糊的 idea 变成一份清晰的研究报告。不写代码，只聊方向。
两种聊法
跟 AI 探讨的时候，我发现自己有两种状态：
探路者模式。脑子里就一个模糊的想法，能不能做、怎么做都不知道。这时候主要是让 AI 帮我找可行性、选技术栈。聊着聊着，某个方案让我眼前一亮，差不多就可以往下走了。
细化者模式。方向大概有了，但细节还没想清楚。这时候主要是让 AI 帮我细化方案、确认技术点。关键技术点都聊到了、实现路径也大致清晰了，就可以进入下一步。
两种模式的结束信号不一样，但目标一样：输出一份足够清晰的研究报告。
为什么用 Gemini
Vibe 阶段，我用 Gemini。
选它的原因是：Gemini 是 Google 家的，搜索能力原生集成。聊技术方案的时候，给的信息更贴近最新潮流，不容易查到过时的东西。
模型的选择也有讲究。我的优先级是 2.5 Pro > 2.5 Flash Thinking > 2.5 Flash。Pro 的推理能力最强，探讨复杂方案的时候更靠谱。Flash 系列速度快，简单问题用它就够了。
这个阶段不写代码，只需要聊清楚”做什么”和”怎么做”。信息检索能力比代码能力更重要。
聊完怎么出报告
探讨到位之后，别急着写代码。先让 Gemini 输出一份深度研究报告。
我的做法：
- 让 Gemini 总结一下讨论结果
- 自己过一遍，确认没遗漏重要的点
- 让 Gemini 生成一个 Deep Research 的提示词
- 新开一个 Gemini Deep Research 会话，把提示词贴进去
- 拿到深度研究报告
这份报告就是进入 SDD 阶段的输入。我一般保存成 idea.md 和 report.md，后面初始化 proposal 的时候会用到。
如果你发现报告里有明显遗漏或者方向偏了，多半是前面探讨阶段聊得不够透。回去补几轮再出报告，别硬往下走。
再动手做
拿到研究报告之后，就进入 SDD 阶段了。这个阶段要做的是把报告变成可运行的代码，而且要保证质量。
SDD 是什么
SDD 是 Spec-Driven Development，核心思想是：先写规范，再写代码。
不是拿到需求就让 AI 开干，而是先让 AI 出一份 proposal，描述要做什么、怎么做、分几步。人 review 通过之后，再按 proposal 写代码。
TIP
这里的好处很直接：问题在 review 阶段发现成本低，代码写完之后再发现成本高。
市面上 SDD 工具不少，我选 OpenSpec。选它的原因：
- 轻量：就是一套目录结构 + 几个命令，没有复杂的配置
- 工具无关：支持 Cursor、Claude Code、Codex、Gemini CLI 等主流 Coding Agent
- 流程清晰：proposal → review → apply → archive，四步循环
在公司写过代码的应该都熟悉这套：需求评审、技术方案设计、排期、开发、交付。OpenSpec 就是把这套搬到了 AI 协作场景：
| 传统开发流程 | OpenSpec 对应 |
|---|---|
| 需求设计 | proposal.md |
| 需求评审 | review proposal |
| 技术方案设计 | design.md |
| 技术方案评审 | review design |
| 排期拆分 | tasks.md |
| 开发实现 | apply |
| 交付验收 | archive |
| 沉淀文档 | specs/ 目录 |
流程没变，只是执行者从”人 + 人”变成了”人 + AI”。该有的环节一个没少，效率却提上来了。
上手也简单，npm install -g openspec 装完，openspec init 一敲就能用。
怎么跑起来
拿着 Vibe 阶段产出的 idea.md 和 report.md，开始 SDD 流程。
第一步：初始化项目
mkdir my-project && cd my-project
openspec init初始化之后，项目里会多一个 openspec/ 目录：
openspec/
├── specs/ # 当前规范（系统的"记忆"）
├── changes/ # 进行中的变更（proposal + tasks）
├── archive/ # 已完成的变更（可追溯）
├── AGENTS.md # AI 助手指南（怎么用 OpenSpec）
└── project.md # 项目上下文（技术栈、约定、领域知识）其中 AGENTS.md 是给 AI 看的使用说明。project.md 是项目的”记忆中枢”，存放技术栈、约定、领域知识——后面经验部分会讲怎么用好它。
第二步：初始化 proposal
打开 Coding Agent（我用 Claude Code），执行：
/openspec:proposal 帮我初始化一个 proposal 用于实现原始想法 @idea.md 的功能，具体可以参考 @report.md ultrathink这条命令做了三件事：
- 引用
idea.md和report.md，把 Vibe 阶段的产出带进来 - 让 AI 生成 proposal.md + design.md + tasks.md
ultrathink触发深度思考模式，确保方案考虑周全
第三步：review
AI 生成完之后，别急着往下走。打开 proposal.md、design.md、tasks.md，逐个过一遍：
- 方案是不是你想要的？
- 技术选型对不对？
- 任务拆解合理吗？
有问题就让 AI 改，改到满意为止。这一步多花点时间，后面能省很多事。
第四步：apply
review 通过之后，让 AI 按 tasks.md 逐步实现：
/openspec:applyAI 会边做边更新 task 进度。做完一个 task，就标记一个完成。
第五步：archive
全部完成之后，归档这次变更：
/openspec:archive归档会把 proposal 移到 archive/ 目录，保持 changes/ 干净。下次新功能，再起一个新的 proposal。
这就是一轮完整的 SDD 循环。
一些经验
SDD 流程跑起来之后，踩了一些坑，下面有几个实践经验值得分享一下。
用好 project.md
前面提到 project.md 是项目的”记忆中枢”。这玩意用好了，AI 就不是每次都从零开始瞎猜了。
老项目，init 完让 AI 帮你填：
请阅读 @openspec/project.md，帮我根据当前项目的技术栈和代码规范填充内容AI 会自己扫一遍项目，技术栈、命名规范、架构模式，该填的都给你填上。
新项目，不用一次填完，每次归档顺手带一句：
/openspec:archive 当前 proposal 已验证完成，帮我归档，顺便更新 @openspec/project.md做三五个 spec 下来，项目知识就攒得差不多了。后面再起新 spec，AI 上来就知道你的代码风格、目录结构、技术偏好，不用每次都从头说起。
一个 spec 做一件事
一个项目不可能一个 proposal 就做完。我的做法是：渐进式堆砌。
两种情况：
主动规划。一开始就知道功能很大，拆成多个 spec。先做 MVP 核心功能，跑通了再加其他的。比如做一个内容管理系统，第一个 spec 只做”文章增删改查”，第二个 spec 再加”分类标签”，第三个 spec 加”搜索”。
做着发现。做的过程中发现”如果加个这个功能体验会更好”。这时候别直接改当前 spec，新开一个 spec 来做。保持每个 spec 边界清晰。
不管哪种情况，核心原则是：一个 spec 尽量只做一件事。
出错了怎么办
用这套流程，错误会少很多。但也会出错。出错的时候，处理方式分两种：
需求或设计不匹配。比如做着做着发现，当初设计的方案根本行不通，或者需求理解有偏差。这种情况别硬撑，直接回溯。回到 proposal 阶段重新来，该改设计改设计，该补探讨补探讨。
设计正确但实现出错。方向没问题，就是代码写错了。这种情况不用推翻重来。把报错信息和对应的 task 引用告诉 AI，让它定点修复。比如：
task 3.2 的实现有问题，报错信息如下：xxx。请修复。AI 有了上下文，纠错效果会好很多。
什么时候让 AI 慢下来
前面提到 ultrathink 可以触发深度思考模式。不是每次都要用，但有几个场景建议用：
初始化 proposal 的时候。这是整个项目的基础，方案想不清楚后面全是坑。这时候主动触发深度思考。
卡壳的时候。AI 来回修改同一个问题，改了几轮还是不对。这时候让它慢下来想想，别一直快速试错。
失焦的时候。你说了好几遍需求，AI 还是理解不对。这时候触发深度思考，让它重新梳理一遍上下文。
判断标准很简单：如果你觉得 AI 在瞎忙，就让它慢下来。
什么时候用
这套流程不是万能的，也不是所有场景都要走全套。
我按变更规模分三层：
大重构 / 大 feature / 探索性功能。走完整流程：Vibe 阶段探讨 + Deep Research，SDD 阶段 proposal → review → apply → archive。初始化 proposal 的时候触发深度思考。
小体验优化。不需要回 Gemini 探讨，直接在 Coding Agent 里起一个轻量 spec。proposal 简单写写，task 列几条，review 一下就开干。
很小的改动。改个文案、调个样式、修个明显的 bug。直接改，不用起 spec。
判断原则：流程是为了控制复杂度，不是为了增加仪式感。
如果一个改动你闭着眼睛都知道怎么做，就没必要走流程。
最后
总结一下这套工作流的核心：
- Vibe 阶段：跟 Gemini 探讨方向，输出 Deep Research 报告
- SDD 阶段：用 OpenSpec 管理开发，proposal → review → apply → archive
Vibe 负责”做什么”，SDD 负责”做对”。两个阶段配合，既保留了 AI Coding 的发散探索能力，又避免了过度设计和反复返工。
这套流程我在 0→1 的新项目和老项目迭代新功能上都验证过，效果不错。不敢说是最优解，但至少比纯 Vibe Coding 可控很多。
工具会不断迭代，模型会越来越强。但”先想清楚再动手”这个道理，应该不会过时。
希望对你有帮助。
