导读Vibe Coding 很容易上手但没有方法论的话项目做大一点就会变成屎山。这篇文章整理了一套在 GitHub 上获得数千 star、被广泛采用的最佳实践帮你把 AI 协作从「玄学」变成「工程」。一、先说一个很多人都踩过的坑用 AI 写代码起步真的很爽。你说「帮我做个个人网站」AI 噼里啪啦给你生成一堆文件浏览器一打开哇还挺好看的。然后你说「再加个评论功能」AI 又改了一堆。然后你说「把颜色换一下」AI 改了但评论功能不见了。然后你说「把评论找回来」AI 改完颜色又回去了。就这么来回拉扯到最后代码乱成一团你自己都不知道哪里动过AI 也越来越摸不清楚这个项目到底是什么状态。这不是 AI 的问题是方法论的问题。二、这套方法论从哪来的GitHub 上有个仓库叫 vibe-codinghttps://github.com/EnzeD/vibe-coding作者是 Nicolas ZulloNicolasZu。他用这套方法 100% vibe coded 出了好几个真实产品包括一个 3D 二战空战游戏和一个工厂建造类游戏。仓库现在有 4500 star还在持续更新。核心理念就一句话「规划就是一切。不要让 AI 自己规划否则代码会变成屎山。」这句话跟大多数人对 vibe coding 的理解完全相反——大家都以为就是随口聊、AI 全包办。但真正做过稍微复杂一点项目的人都知道越放任 AI 自主决策后面越难收拾。下面把这套方法论完整拆一遍。三、整体流程先看一眼需求文档PRD ↓ 产品原型 ↓ 技术栈规划 ↓ 架构文档 数据模型 ↓ 实施计划双 AI 评审 ↓ Memory Bank 整理 AGENTS.md 创建 ↓ 按任务一步步执行代码是最后才出现的。前面这些步骤都是在跟 AI 一起把「我想做什么」说清楚。四、第一步把需求写清楚不要上来就让 AI 写代码。先让它扮演产品经理帮你把想法问清楚。推荐的方式是每次让 AI 问你 3-5 个问题你回答然后再问下一轮循环几次之后再让它把结论整理成一份 PRDProduct Requirements Document产品需求文档也就是项目里的PRD.md。不要一上来就让它直接生成完整 PRD那样基本都是通用模板跟你实际想做的偏差很大。PRD 的基本结构一句话说明这个项目是什么 目标用户是谁 核心使用场景 MVP 功能范围包括「不做什么」 页面清单 验收标准写完之后有个很好用的验证方式——把 PRD 丢回给 AI问它「这份需求文档是否足够清晰有没有哪些地方你作为执行者看不明白的」它一般会挑出几个问题你回答完再更新到 PRD 里。几轮之后PRD 基本就齐了。整个过程是迭代出来的不是一次写完的。PRD 也不需要很大很全关键是人能读懂AI 能清楚知道核心功能和做到什么程度。五、第二步做产品原型需求确认了下一步不是写代码是先把页面画出来。有了原型你才能快速判断「这是不是我想要的效果」而不是代码写了一半才发现方向不对。搁以前光这一步就能省掉好几天的返工。这里介绍两个工具HuaShu Skill15k stargithub.com/alchaincyf/huashu-design直接生成 HTML 原型可交互安装完在对话里就能用。Open Design52k stargithub.com/nexu-io/open-design一个独立的本地应用web app 本地 daemon可选 Electron 桌面端思路是调度你本地已有的编码 Agent 来出设计它在 README 里致敬并借鉴了 HuaShu 的设计方法论。注意它和 HuaShu 形态不同HuaShu 是装进 Claude Code 的 skill在对话里直接就能用Open Design 要单独安装运行。如果你就在 Claude Code 里干活HuaShu 上手最快想要更完整的设计工作流再考虑 Open Design。原型出来之后完全可以通过对话继续迭代——觉得风格不对告诉 AI 调整某个页面的交互不是你想要的描述清楚让它改。改着改着如果发现跟 PRD 里描述的不一样了记得同步更新 PRD保持两份文档一致。HTML 原型确认之后让 AI 从原型里提取一份DESIGN.md。这份文档不是重新描述视觉效果而是给 AI 看的——主要写页面和路由的对应关系以及一些 AI 容易猜错的交互细节比如评论为空时显示什么、提交失败怎么提示。六、第三步规划技术栈需求和设计都定了现在才讨论用什么技术。把 PRD 和设计稿一起给 AI让它推荐技术栈。提示词里加一句「请推荐最简单但足够健壮的方案不要为了炫技选复杂框架」。技术栈文档TECH_STACK.md包含三层第一层选什么为什么选。前端用什么、后端用什么、数据库用什么每个选择说明理由。第二层每个选择的背景。让 AI 后续碰到模糊情况时能自己判断不瞎猜。第三层明确不做什么。比如「不引入状态管理库」「不用 UI 组件库」。这一层很关键不写清楚AI 默认会往「更完善」的方向走自动给你加一堆用不上的东西。七、第四步整理架构文档技术栈定了把项目的代码结构也写清楚。ARCHITECTURE.md里要写•项目目录结构每个文件夹负责什么•每个关键文件的作用•数据是怎么流动的前端 → 接口 → 数据库如果项目涉及数据库数据模型可以单独放一份DATA_MODEL.md写清楚每个集合的字段和接口设计。这个文件不是写完就完了。每次完成一个重要功能要让 AI 把新增的结构补进来保持「新鲜度」。下次开新对话AI 读完这个文件就能快速接上上下文不用从头猜项目长什么样。八、第五步出实施计划文档都整理完了出实施计划IMPLEMENTATION_PLAN.md。实施计划是把「完成整个项目」拆成一个个足够小的步骤每个步骤有明确的完成标准和验证方式任务顺序从简单到复杂。这里有个好用的做法先让一个 AI 出一版然后把这份计划交给另一个更强的模型来评审专门找问题请评估这份任务清单是否合理 1. 每个任务是否足够小能单独交给 AI 执行 2. 每个任务是否有明确的完成标准和验证方式 3. 是否存在任务依赖顺序错误 4. 是否有「完善首页」「实现后台」这类太大的任务 请直接指出问题不要写代码。根据评审意见修改直到两个模型都觉得没问题这份计划才算可以执行了。九、Memory Bank 是什么做完前面这些步骤你手里会有一批文档。这批文档统一放在memory-bank/目录里就是所谓的 Memory Bank。AI 没有持久记忆每次开新对话它都不知道之前发生过什么。Memory Bank 解决这个问题——让 AI 每次开始前先读这些文档保证它对项目的理解始终连贯。标准的 Memory Bank 包含 7 个文件文件作用PRD.md需求文档DESIGN.md页面路由和关键交互状态TECH_STACK.md技术栈及不做什么DATA_MODEL.md数据字段和接口ARCHITECTURE.md代码结构动态更新IMPLEMENTATION_PLAN.md实施计划PROGRESS.md当前进度下一步做什么最后这个PROGRESS.md特别重要。每完成一个任务就让 AI 更新它记录做了什么、验证了什么、下一步是哪个任务。开新对话时先读这个文件AI 就能立刻接上。十、创建 AGENTS.mdMemory Bank 建好之后还要在项目根目录新建一个AGENTS.md让 AI 知道这个项目有 Memory Bank每次开始写代码前必须先读里面的文档完成任务后必须更新PROGRESS.md。最关键的是把这条设为「Always 规则」每次进入对话自动触发不需要每次都手动提醒Always 规则 - 写任何代码前必须先阅读 memory-bank/ 中的所有文档 - 完成任务后必须更新 memory-bank/PROGRESS.md - 完成重要功能后更新 memory-bank/ARCHITECTURE.md十一、开始执行文档都准备好了可以开始写代码了。执行阶段只有一条铁律每次只执行一个任务。标准的任务提示词请阅读 AGENTS.md以及 memory-bank/ 中的所有文档。 请根据 PROGRESS.md 判断下一个未完成任务。 只执行 IMPLEMENTATION_PLAN.md 中这一个编号任务。 要求 1. 不要一次性执行多个任务 2. 不要新增 PRD 没有定义的功能 3. 完成后告诉我改了哪些文件和如何验证 4. 验证通过后再更新 PROGRESS.md每完成一个任务亲自验证通过了再做两件事git commit存档然后开新对话进入下一轮。对话越长AI 性能越差越容易跑偏。新对话 Memory Bank 读取才是保持稳定输出的正确方式。十二、卡住了怎么办执行过程中如果走偏了或者 bug 解决不了按这个顺序处理第一步回滚。OpenCode 里可以用/undo可以连按多次/redo撤销回滚Claude Code 里可以用/rewind。如果要用 Git 回到上一个稳定版本先确认当前没有需要保留的未提交修改再让 AI 帮你选择合适的回退方式。这就是为什么每个任务完成都要 commit。第二步换角度重描述。先让 AI 分析原因再让它提方案不要直接让它改代码。第三步喂给最强模型。实在不行用 RepoPrompt 把整个代码库打包成一个文件交给最强的模型来分析。记住一条原则不要在一个错误方向上死磕超过 30 分钟。时间到了就回滚换方向。十三、别忘了后端和部署前面整套流程重点都在「设计」和「实现」——把页面和功能做出来。但真实项目常常不止一个静态页面只要系统里有接口、要把数据存下来还记得开头那个评论功能吗评论总得存到某个地方就绕不开后端。后端不一定要从服务器、数据库到接口都自己搭建。现在已经有很成熟的Serverless无服务器方案你只需要关心项目需要什么功能平台会提供数据库、函数运行环境和部署能力省去大量后端搭建与维护工作。CloudBase云开发就是腾讯云提供的其中一种。它提供数据库、云函数、静态托管等能力很适合用来快速完成带留言、登录或数据保存功能的小应用。如果你还不熟悉 Serverless 或 CloudBase也不用先学完所有概念再开始。可以直接把你的需求、原型和技术栈文档交给 AI让它给出一套基于 CloudBase 的实现方案并一步步指导你创建环境、设计数据、编写云函数、连接页面和完成部署。用哪种后端 / 数据存储最好在第三步「规划技术栈」时就写进TECH_STACK.md别等代码写一半才临时拍脑袋。功能做完还得让别人能访问这一步就是部署。常见几种选择方案适合费用CloudBase带后端能力的应用托管、数据库、云函数按官网当前套餐与用量确认Vercel前端或全栈项目部署按官网当前套餐与额度确认Netlify静态站点或前端部署按官网当前套餐与额度确认一句话选型想要一体化、带完整后端可以优先了解 CloudBase只是把一个前端或轻量项目挂上线也可以了解 Vercel 和 Netlify 的免费方案并提前确认目标用户所在网络的访问情况。这套流程说起来步骤不少但做过一遍之后会发现前面的文档准备越扎实后面写代码越顺。与其写了一半发现方向错了全部推倒不如花两个小时把文档做好然后让 AI 一步步往前走。