我的 Vibe Coding 实践录
最近是真的喜欢上了 Vibe Coding（氛围编程）。
曾经和朋友闲聊时，我打开笔记软件，上面密密麻麻记满了我很多产品级的 Idea。但苦于时间和精力，我已经无法像大学期间那样，投入足够的时间将这些 Idea 转化成实际可用的产品。但现在，大模型所带来的 Vibe Coding 让我能够轻松解决这些问题。
对于很多刚刚上手进行所谓 Vibe Coding 的朋友，他们很容易将实操过程误解成“抽卡编程”、“盲盒编程”、“许愿编程”或者“一句话编程”。但实际上理想状态下并不是这样。因为这种制造出来的代码潜在问题比较多、可维护性差，非常不利于之后的迭代和维护。通过最近几个月的 Vibe 实践，我沉淀出了一套相对成熟的工作流，希望能给大家一些参考。
为了方便理解，我将这套基于多模型分工的开发流整理成了下面的图表：
graph TB
%% 节点样式定义
classDef highModel fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
classDef lowModel fill:#fff3e0,stroke:#e65100,stroke-width:2px;
classDef doc fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,stroke-dasharray: 5 5;
classDef human fill:#fafafa,stroke:#333,stroke-width:2px;
Start(💡 Idea) --> Survey
subgraph Phase1 [Step 1: 调研与定义]
direction TB
Survey[Claude Code + Opus]:::highModel
Survey --> |反复刁难| PRD_DOC[PRD / Guide / Milestone]:::doc
Tech{技术栈风控} --> |Search MCP| Latest[最新依赖]
Tech --> |Context7| Docs[AI友好文档]
Latest & Docs --> PRD_DOC
end
PRD_DOC --> Coding
subgraph Phase2 [Step 2: 低成本实现]
direction TB
Coding[OpenCode + Minimax]:::lowModel
Coding --> |Oh-My-OpenCode| Agents(多Agent / Ultrawork):::lowModel
Agents --> MVP[M0: MVP代码]
end
MVP --> Review
subgraph Phase3 [Step 3: 审查与迭代]
direction TB
Review[Claude Code Review]:::highModel
Review --> Check{错误检查}
Check --> |Bug多| FixDoc[生成 Fixs.md]:::doc
Check --> |Bug少| AutoFix[直接修复]
FixDoc --> |回炉| Coding
end
AutoFix --> Final[🚀 M0 交付]
Final --> |新需求| Next[M1 迭代]
linkStyle default stroke:#333,stroke-width:1.5px;
第一阶段：项目的调研与定义
首先，是调研阶段。我会和大模型对话（我个人习惯 Claude Code 配合 Claude Opus 4.6，这是目前逻辑性最强、编程能力 SOTA 的组合），讨论产品的需求点，让它沉淀成为一个具体的 PRD.md。这个需求文档上记载着产品的需求点、技术实现、里程碑和代码规范。
产品需求点是由你的 Idea 开始发散聚合成的具体内容，但初始版本肯定会有很多问题。所以要和 LLM 讨论清楚，列出 P0、P1、P2、P3 不同重要性的需求点。LLM 很容易找出你逻辑上的漏洞，通过反复交流，这会成为一个可行的 PRD。但是 AI 和人类一样，都讨厌“一句话需求”，所以在尽可能的情况下，要让多个大模型去反复“刁难”你的 PRD，让它变得更加完善。
然后，你需要对整个产品的技术栈进行规范。虽然 LLM 对各种技术栈基本一视同仁，但它存在两方面的缺陷：一是在知识库上它是落后于现有技术的，即使是现在最先进的模型，仍然使用着一年前的语料进行训练，如果不进行限制，它很容易使用有安全漏洞的库或已停止维护的依赖。二是对于某些语料过少、使用案例不多的语言或库，大模型的支持并不好，导致这些成为“非 AI 友好语言”。
针对这些问题，会有一些通用的解决办法：
- 接入 Search MCP：让 LLM 能够接触到最新的安全可用的依赖和框架，用提示词要求它运用最新最安全的库去打造项目。
- 接入 Context7 MCP 或使用 AI 友好框架：Context7 MCP 能帮助模型获取特定的上下文，或者尽量使用支持 llms.txt、
claude.md、agents.md的框架和依赖。
当然，对于我们个人来说，可能并不用像之前一样去深入了解每一个框架的底层，但我们需要保有经验和最佳实践，心中要有实现某一个领域产品的最佳技术实践方案。
接下来，你需要实现一个里程碑文档（Milestone）。这个文档就是你的产品从 MVP 到逐步迭代完善的方案，M0 应当是一个最小可行版本，但应当高屋建瓴，打好基础架构，避免之后跑偏。
最后是代码规范。比如我常用的限制，就是要求做好代码的模块拆分，要求每个代码文件不超过 150 行。因为一旦超过 150 行，人类的可读性就将下降，而且 AI 的编辑成本、检索消耗的 token 数也会增加。你可以在代码规范里要求对每一个模块加上单元测试，并且在实现之后必须执行单元测试，确保无代码规范问题和逻辑问题。
可以看到，我的 PRD.md 内容是包含以上四个模块的。你可以在项目根目录建立一个文件夹，用来保存这四个 md（PRD、TRD、Guide、Milestone），但我个人一般直接写到一个 PRD.md 里也可以，区别不大。
第二阶段：项目的实现阶段
就是开始开工了。这时候我一般会切换到 OpenCode 配合 Minimax 2.5（Kimi 2.5、GLM-5 等同理）。原因很简单，国产的 Coding Plan 比较便宜，适合处理这类复杂任务，且国产模型能够大致对标 Claude Sonnet 4.5，根据 PRD 完成这些任务并没有什么问题。
但是这个时候，我一般会使用 Oh-My-OpenCode 的多 Agents 协作模式（Ultrawork）。它的 ultrawork 模式允许最大程度地利用上下文，让多个 Agents 并行（每个 Agent 完成不同的任务、负责不同的职责），能够达到又快又好的效果。
当然，Claude Code 也有对应的 oh-my-claudecode，只是 OpenCode 的 TUI（终端用户界面）更加好看，所以在干这种活的时候，我喜欢用 OpenCode。
第三阶段：项目的中间阶段与迭代
当 M0 实现之后，这时候不要着急去实现 M1 阶段的需求。我在这个时候又会回到 Claude Code，只不过此时它扮演的角色是严格的 Code Review 审查官（因为Claude Opus的逻辑性、编程能力更强）。它需要去审查之前“较弱”模型的错误，并且予以订正。
接下来，就是人工的审阅和运行。对于很多 Vibe Coder 来说，他们并不在意这一步，认为代码只要跑起来就行，多个模型检查一遍，然后懒得看了。但实际上大模型也会偷懒、也会犯错，而且多个大模型可能也会犯同样的错误（说不准用的那个较弱模型就是这个较强模型蒸馏出来的，同样的错误也可能再犯一次）。
在项目的中间阶段，如果检查出来较多错误，可以让 AI 写出一个 fixs.md，里面标明 P0～P4 的 Bugs 需要修复，再次让大模型去修复。如果是少量错误，那么没必要生成 md 这一步，直接让 AI 工具去改就行了。任何新增的需求可以放到之前 PRD.md 里面，然后新建一个 M* 阶段即可。
思考：这与 OpenSpec 有何不同？
有些朋友会说，我的这个逻辑是不是和 OpenSpec 有点像?其实我也是在跑通这套流程很久后，才发现两者确实有异曲同工之妙。简单来说，OpenSpec 胜在规范性和强约束，但流程相对重且繁琐，更适合团队协作；而我的范式则更注重灵活性（通过多模型、多工具、多 Agents 组合），对于追求效率的个人独立开发者来说，这或许是更轻量、更顺手的选择。
写在最后
以上其实是不涉及强前端交互的开发逻辑。如果涉及前端页面的强还原，那其实又会有点不同，我们可能还得引入 Figma MCP 或者 D2C（Design to Code）的 Skill 来完成整个前端的开发。
其实从目前的体感来说，前端的交互开发相比后端的逻辑开发可能更难一些。因为后端逻辑是可以用 CLI 工具直接读取的，它可以去了解链路和解决逻辑上的问题。但是前端交互涉及浏览器和视图、键鼠交互、触摸交互，AI 工具很难直接操作和测验。引入 Browser MCP、Sandbox MCP、自动化测试的成本其实并不低。
我目前的套餐就是 GitHub Copilot Pro（10美元，支持Claude Opus）+ Minimax Coding Plan Plus（49元），基本每个月的成本并不高，相对来说是可接受的。