我是怎么用 Vibe Coding 从 0 到 1 搭起这个博客的
最近我在尝试一种更结构化的开发方式。
很多人提到 “vibe coding”，第一反应可能是：一边和大模型聊天，一边快速把东西做出来，重点是速度和感觉。
但我这次想验证的，不只是“能不能很快生成代码”，而是另一件事：
能不能把一个真实项目，用一套可重复、可收敛、可交付的方式推进下去。
这个博客，就是我用这套方式做出来的第一个验证样本。
为什么我会想试这件事
过去做小项目时，我最常遇到的问题不是不会写，而是很容易在中途失控。
一开始只是想做一个最小可用版本，结果写着写着就开始：
- 顺手优化架构
- 提前做以后可能会用到的功能
- 一边改代码一边改需求
- 前面还没闭环，后面已经开新坑
最后项目不是做不出来，而是很难形成一个干净的交付闭环。
所以这次我想换一种方式。
不是先上手写，而是先把“我要做什么、现在做哪一步、这一步完成标准是什么”这些问题拆清楚，再让工具参与执行。
我现在理解的 Vibe Coding
对我来说，vibe coding 不是“完全凭感觉写代码”。
更准确地说，它是一种：
让大模型参与项目推进，但又尽量不让过程失控的开发方式。
我把这套流程拆成了几个阶段：
- 先明确需求
- 再冻结关键决策
- 再拆里程碑
- 再定义当前任务
- 最后才进入代码执行
- 执行完必须验证、复盘、更新状态
简单说，就是把原本容易混在一起的几件事拆开：
- 需求归需求
- 决策归决策
- 计划归计划
- 当前轮任务归当前轮任务
- 执行归执行
- 收尾归收尾
这样做的好处不是“更正规”，而是更容易持续推进。
我是怎么把它落地到这个博客上的
这次我做博客时，没有一开始就让 coding agent 直接写代码。
我先把流程分成了两段。
第一段：网页大语言模型负责规划
这一段不写仓库代码，只负责把项目收敛清楚。
主要产出 4 份文档：
SPEC.mdDECISIONS.mdBUILD_PLAN.mdTASK-001.md
它们分别解决的是：
SPEC.md：这个项目到底要做什么DECISIONS.md：关键技术选择是什么BUILD_PLAN.md：要按什么顺序推进TASK-001.md：当前这一轮只做什么
这一步非常重要，因为如果前面没有收敛好，后面 coding agent 很容易重新发散，又回到边做边改需求的状态。
第二段：Coding Agent 负责执行
等到文档收敛到当前任务卡之后，我才切到 Codex / Claude Code 这类工具。
在这一段里，agent 的职责就不再是重新设计项目，而是：
- 读取已冻结文档
- 执行当前任务
- 做验证
- 输出 review
- 更新状态
- 在满足条件时生成下一张任务卡草案
这样整个过程会稳定很多。
这套流程里最关键的，不是“生成代码”
真正关键的，是这几个控制点。
1. 先冻结需求，不要边做边漂
如果需求一直没收敛，后面的所有计划都只是暂时的。
所以我先用 SPEC 把目标、约束、完成标准和不做的东西写清楚。
2. 先冻结关键决策，再拆计划
很多项目真正卡住，不是因为功能不会写，而是因为选型一直在摇摆。
比如：
- 用什么框架
- 用什么数据库
- 认证怎么做
- 编辑器用 Markdown 还是富文本
- 上传怎么处理
这些问题如果不先定，后面每一轮都会被反复拉回来。
3. 一次只允许一个当前任务
这是我觉得最重要的一点。
很多时候项目失控，不是因为工作太多，而是因为“当前任务”不够清楚。
所以我强制自己每一轮只做一个最小闭环：
- 这一轮目标是什么
- 这一轮包含什么
- 这一轮不做什么
- 这一轮完成标准是什么
- 这一轮怎么验证
这样执行阶段就不容易越写越散。
4. 执行完必须收尾
这一点以前我经常做得不够好。
代码写完，不等于这一轮完成。
一个真正的闭环至少要包括：
VerifyReview- 更新任务状态
- 更新阶段进度
- 决定是否进入下一轮
如果没有这些动作，项目表面上在前进，实际上很容易变成一堆没正式结案的工作。
这次做博客时，我的一个明显感受
我以前会觉得，文档会不会太重、太慢。
但这次实际做下来，我更强烈的感受是：
不是文档让项目变慢，而是需求和执行混在一起时，返工会让项目更慢。
前面多花一点时间把结构搭好，后面执行其实会轻很多。
尤其在大模型参与开发的场景里，这一点更明显。
因为工具本身并不缺“生成能力”，真正稀缺的是：
- 清晰输入
- 稳定边界
- 明确任务
- 可验证输出
只要这四件事做得足够好，工具的表现就会稳定很多。
这套方式适合什么，不适合什么
到目前为止，我觉得它比较适合：
- 个人 blog
- 文档站
- 小型 SaaS MVP
- 工具站
- 原型验证项目
- 范围明确的迭代开发
它不一定适合一开始就拿去套特别重的组织型流程。
但对于个人项目和小团队来说，这种方式的价值很直接：
它能让项目持续往前，而不是一直停在“想做很多，但每轮都不够完整”的状态里。
这个博客本身，就是一次验证
这个博客不仅是一个展示站点，它本身也是这套 workflow 的产物。
我想验证的不是“能不能快速搭一个页面”，而是：
- 能不能把项目收敛成明确文档
- 能不能把每轮任务拆小
- 能不能让大模型和 coding agent 各自只做自己该做的事
- 能不能形成真正的交付闭环
至少到现在，我觉得答案是肯定的。
它当然还不完美，流程本身也还在继续调整。
但比起一开始那种更松散、更容易跑偏的方式，这已经是一种明显更可控的推进方法。
接下来我还会继续优化这套流程
下一步我还想继续验证两件事：
- 多代理模式在稍复杂任务里是否真的比单代理更高效
- 这套流程在真实项目里，能不能长期保持低摩擦
如果后面验证结果足够稳定，我也会继续把这套方法整理得更完整一些。
这个博客会继续写下去。
而这篇文章，也算是给它的起点做一个记录。
相关链接
这套 workflow 模板我已经整理到了 GitHub：
如果你也在尝试用大模型和 coding agent 推进个人项目，这个仓库也许能作为一个起点参考。