我的Vibe Coding实战流程

过去这一年，我对Vibe Coding的理解发生了明显转变——不再是“让一个AI帮我写代码”，而是像管理一个小型研发团队一样，管理一组AI。最近，我就用这套流程，将LLM-TradeBot在不到一周的时间里，从0搭建到了可运行版本。下面，我把目前稳定在用的一整套流程记录下来，供大家参考。
1. 先选对“主力AI员工”
如果只记住一条经验，那就是：选对模型，能极大减少返工、修BUG、推倒重来的隐形成本。
在能力允许的情况下，尽量选择当下综合能力最强、上下文稳定的模型，而不是“能用就行”。在我的流程里，目前的AI分工如下：
- Claude Code：核心开发主力，负责规划与编码；
- Codex：负责代码Review与风险检查；
- OpenCode：负责高频小改动与自动执行。
IDE层面，我依然把Claude Code作为主战场，它非常适合长时间、高强度的Vibe Coding。

2. 架构师 + 程序员的“双层AI架构”
这是我认为最关键的一步。不要让一个AI既当产品经理，又当架构师，还当底层码农，这样几乎一定会导致：前期很爽、后期失控、最终形成“屎山”。我的做法是明确AI的角色分工，分为AI架构师和AI程序员两层。
AI架构师（大脑）
我会选择一个擅长系统思考和产品设计的模型，让它只专注做四件事，不涉及具体编码：
1. 构思整个系统的目标和边界；
2. 拆分开发阶段和模块；
3. 为每一步生成「给AI IDE用的Prompt」；
4. 验收阶段性成果，并给出下一步指令。
这里有一个重要原则：不要让AI架构师陷入实现细节。上下文越干净，它的判断越稳定。
AI程序员：专心干活，不做决策
真正负责写代码的是AI程序员，流程非常简单：
- 把AI架构师给出的Prompt，原样丢给AI程序员（我选用Claude Code）；
- 监督它完成具体工作，包括编码、读文档、跑测试、修BUG。
测试结果、异常情况、设计偏差，我会原封不动反馈给AI架构师，由它判断是继续推进，还是调整方向。这样做能明显感觉到：系统是“被管理着往前走”的，而不是失控地生长。

3. Code Review 必须独立出来
这是我最近新增、但非常重要的一步。当代码规模开始变大时，我会把代码丢给Codex，让它只专注做两件事，不参与设计、不写新功能：
- 逻辑Review；
- 风险检查（包括边界、异常、潜在Bug）。
它的核心作用就是判断“这里有没有坑”，这一层能挡掉非常多未来才会暴露的问题。

4. 不要害怕推倒重来
这是Vibe Coding里最反直觉、但也最重要的一点。去年12月，我尝试开发一个MEME Auto LP系统，随着代码越来越多，逻辑越来越绕，明知道方向不对，却舍不得重写，最终导致：越修越乱、越改越偏，最后完全背离初衷。
最终我选择：新建文件夹，全部重来。换了流程、换了模型组合，用现在这套多Agent方式，开发反而异常顺利。很多时候，与其花时间修补“屎山”，不如让更智能的AI，重新写一座干净的“山”。

5. 测试、验收、提交：用Git控制AI
最后一点，非常务实：一定要用Git。我目前的配置是GitHub私有仓库+GitHub Desktop/自动生成Commit Message，每完成一个阶段，就按照“测试→确认无误→提交”的步骤操作。
这样做，你永远拥有三种权利：回滚、覆盖、推翻重来，这也是控制AI不乱写、不乱删、不乱来的最有效手段。
最后
如果只是开发一个很简单的小工具，其实任何AI IDE都能直接搞定。但只要项目稍微复杂一点，Vibe Coding的核心就不再是“写代码”，而是“设计一套能持续推进的AI协作流程”。
对我来说，现在这套流程，已经足够稳定地支撑中大型项目开发。以上，记录在此。 #你都用vibe coding做过什么？#

我的Vibe Coding实战流程

全站热榜

创作者周榜