熟悉的兄弟都知道我是一名产品经理，一直都是脑子里虽然有想法但不好自己实现，直到 Vibe Coding 出来，说实话我巨兴奋。

因为它突然给了我一种感觉「我好像能自己做东西了」，不需要为了一个小工具去求开发大佬了，我只要把想法讲清楚，AI 就能帮我把东西搭出来。

然后我就开始猛猛蹬，然后就是

页面能打开，按钮能点，但点完没反应路由能跳，但跳到奇怪的地方你让它修，它顺手改坏别的地方

然后就是得出了一个结论「AI 写代码还是8 行」，哈哈哈。

但是我反复折腾下来后越来越觉得问题不是 AI 不会写代码，而是我太会让 AI 瞎猜了。

Vibe Coding 不是说一句愿望，它自动吐出一个完整产品，它更像是我们带了一个很能干、手速很快、但特别依赖上下文的实习生。

你说清楚，它干得飞快你说模糊，它开始脑补它一脑补，项目就开始堆屎山

所以这篇不是劝退 Vibe Coding，恰恰相反我是想说「Vibe Coding 确实牛逼，但前提是你得把它从瞎写代码变成按流程施工」

一、不要！一上来就让 AI 写代码

很多人第一步就错了，刚有个模糊想法直接就是

帮我做一个食谱分享 App

这对 AI 来说约等于没说。

它不知道这个 App 给谁用不知道要不要登录不知道食谱能不能公开不知道是否支持上传图片不知道有没有收藏、搜索、评论不知道移动端是不是主场景不知道数据库字段怎么设计不知道空状态、加载状态、失败状态怎么处理...

诶～你没说，它就猜。

猜页面猜路由猜字段猜技术栈猜 UI 风格...

最后你得到一个「看起来能跑」的东西。

能跑不等于能维护能打开不等于能上线能 demo 不等于能产品化

说白了Vibe Coding 真正的第一步不是 Coding，是把事情想清楚。

二、正确姿势是先让 AI 审问你

我现在做 AI 项目，从来不会一上来就框框写代码，第一步，我永远会让 AI 反过来问我。

直接丢这段：

在写任何代码之前，先用 Planning 模式审问我的产品想法，不要默认任何信息。请持续向我提问，直到以下内容都清楚为止：1. 产品目标2. 目标用户3. 核心功能4. 页面和路由5. 用户流程6. 数据结构7. 异常场景8. 技术栈9. UI 风格10. MVP 范围在问题没有问完之前，不要写代码...

这一步巨关键，因为 AI 最危险的能力，不是写错代码，而是它会替你做产品决策。

你没定义 MVP，它给你加后台你没定义字段，它自己造数据库你没定义 UI，它随机配色...

看起来很勤奋，实际全是负担，所以顺序一定是：审问 → 文档 → 代码，跳过前两步，后面你就等着补锅吧。

三、写代码前，先准备施工图

不要把 AI 当代码生成器，把它当工程队，工程队再厉害没有施工图也会乱盖。

我现在建议每个稍微正经一点的 AI 编程项目先准备 6 份 Markdown，不用写得非常复杂但一定要有！！

1. 这个东西到底做什么（PRD.md）

这份文件解决一个问题那就是「别让 AI 加戏」，里面写清楚：

产品是什么给谁用解决什么问题MVP 做哪些功能哪些功能暂时不做什么叫完成

比如你只想做一个简单工具，AI 却给你加会员、积分、后台、权限系统，看起来很厉害。但你要的只是自行车，它给你造了个半成品航母。

PRD 的作用就是告诉AI：哥们，你只需要做这里写的，别自己瞎发挥

2. 用户怎么走（Flow.md）

这份文件写页面和流程，比如：

/是首页/login是登录页/dashboard是后台/recipes/[id]是详情页点击「新建」去哪里保存成功跳哪里保存失败提示什么没数据时展示什么...

AI 很怕你不定义路径，你不定义它就自己造路，造着造着，就出现链接不通、按钮乱跳、页面重复...

这就是很多项目越写越乱的开端。

3. 技术栈别让 AI 猜（TechStack.md）

很多人直接说

用 React 做一个网站

这句话太虚了。

React 哪个版本？Next.js 还是 Vite？TypeScript 要不要？Tailwind 还是 CSS Module？shadcn/ui 用不用？数据库是 Supabase 还是 Firebase？登录用 Clerk 还是自己写？

你不锁定，AI 就会随机发挥，所以这份文件要写死，技术栈越清楚，AI 越不乱搞。

4. 别再让 AI 随机审美（Frontend.md）

这份文件要写：

主色背景色字号层级间距规则圆角大小卡片样式按钮状态移动端断点是否暗色模式是否 Bento Grid是否需要动效

不要说做得高级一点，这句话等于没睡。你要说：

整体风格：暗色科技感主色：#3B82F6卡片圆角：12px布局：Bento Grid按钮：hover 时放大移动端：单列布局...

5. 数据别临场发明（Backend.md）

这份文件至少写清楚：

有哪些表每张表有哪些字段字段类型是什么表之间什么关系哪些字段必填哪些字段可以为空权限怎么控制...

不要让 AI 现场发明你的数据世界。

6. 把大任务切成小块（Implement.md）

别对 AI 说：

帮我做一个电商网站

太大了哥们，你要拆成：

初始化项目安装依赖创建目录结构搭建首页布局做商品卡片做商品列表接数据库做商品详情做购物车接支付做发布前检查...

每一步最好单独做、单独测、单独提交。

Vibe Coding 不是一口吞大象、是让 AI 一块一块搭乐高。

四、再加 3 个文件，项目才不容易失控

上面 6 份是施工图，但项目跑起来后最好再加三个「记忆文件」，不然 AI 新开一个对话，还是会失忆。

1. 项目规矩（Agent.md）

用 CC 就写 Claude.md；用 Codex 就写 Agents.md；用 Cursor就配 .cursor/rules 或类似规则文件...

里面写项目规矩：

1. 写代码前先阅读 PRD.md、Flow.md、Tech_Stack.md2. 所有组件放在 src/components3. 只能使用 Tailwind，不写内联样式4. UI 优先使用 shadcn/ui5. 所有页面必须移动端优先6. 不允许未经确认新增依赖7. 每次完成后更新 progress.md8. 每次修改后说明改了哪些文件

这东西直接写进规则里，就像 AI 的员工手册，后面就不用每次都重新口头教育了。

2. 项目进度（Progress.md）

AI 最大的问题之一是新会话断上下文，今天你让它做登录，明天开新窗口，它不知道昨天做到哪，你让它继续，它可能直接重写一遍。

所以要有进度文件，写清楚：

已完成什么当前正在做什么下一步做什么已知 bug哪些地方不要动最近一次修改了什么

这文件看着土但非常有用，它解决的是 AI 协作里最烦的上下文断掉的问题。

3. 踩坑记录（Lessons.md）

这个很多人不用，但我觉得很值，每次 AI 犯错不仅要让它修，还要让它长记性。

比如：

不要在未确认前新增依赖不要修改已稳定的路由结构所有页面完成后必须检查移动端修 bug 时只修相关文件，不要顺手重构全项目...

时间长了这份文件就会变成项目的避坑手册，AI 不是不能变聪明。前提是得给它一个积累经验的地方。

五、提示词就是管理

很多人喜欢收藏神级 Prompt，但真正有效的 Prompt 更像任务单。

烂提示：

帮我做个好看的后台

好提示：

请先阅读 Claude.md、Progress.md、PRD.md 和 Frontend.md现在只执行 Implement.md 的步骤1.1任务：构建 dashboard 页面要求：1. 文件位置：src/app/dashboard/page.tsx2. 左侧固定 120px sidebar3. 右侧主内容区4. 桌面端两列 Bento Grid5. 移动端单列6. 使用 shadcn/ui Card7. 数据先用 mock8. 不要新增依赖9. 完成后更新 progress.md10. 告诉我修改了哪些文件...

空数据没处理接口失败没提示按钮重复点击会崩loading 没有表单乱提交移动端挤成一团API Key 还可能暴露到前端...

请先为这个功能设计测试用例，不要写实现代码测试用例包括：1. 正常流程2. 边界情况3. 空数据4. 接口失败5. 权限不足6. 重复点击7. 移动端展示测试设计确认后，再实现代码如果项目里有 ESLint、Prettier、测试命令，也要写进规则生成的代码必须遵守 ESLint 和 Prettier提交前需要通过 npm run lint 和 npm test如果某个修改可能影响测试，请提前说明

AI 写得快但验收不能省，不然你只是把技术债生成速度提升了 10 倍。

六、Git 不是可选项，是保命绳

Vibe Coding 最大的爽点是快，最大的问题也是快。

AI 一次可以改很多文件，改对了很爽，改坏了也很爽，所以 Git 必须用。

每完成一个稳定小功能就提交一次：

git add .git commit -m "add dashboard layout"git push

不要等项目快写完了再提交，那不叫版本管理，那叫留遗书。

正确节奏是：

完成一个小功能本地跑一下没问题就 commit再做下一步

AI 改坏了，直接回滚，没有 Git，你只能靠记忆撤回。

七、报错时，别只会说“又崩了”

很多人调 bug 的方式巨抽象，报错一出来就直接跟 AI 说：

又报错了，修一下

不是哥们，AI 是神啊？还是那句话，这对 AI 等于没说。你要给它完整上下文：

我刚才执行了：npm run dev期望结果：打开 /dashboard 后正常显示列表实际结果：页面白屏错误信息：TypeError: Cannot read properties of undefined at ProductList.tsx:15相关代码：粘贴 ProductList.tsx请只分析这个错误原因，不要修改无关文件...

这才叫有效调试，错误信息 + 相关代码 + 刚做了什么 + 期望什么 + 实际发生什么。你给得越完整，AI 修得越准。

八、工具别梭哈，谁擅长什么就干什么

不要迷信单一工具，我的理解很简单：

Claude：适合想清楚，做需求审问、文档、架构拆解CC/Cursor：适合动手实现，按计划一步一步改代码Codex：适合查漏补缺、跨文件分析、修复杂 bug视觉模型：适合根据截图还原 UIGitHub：保存版本Vercel：部署上线Supabase / Clerk：快速解决数据库和登录

我个人倾向：Claude 负责想，CC/Cursor 负责做，Codex 负责查，Git 负责兜底，Vercel 负责上线。

别让一个工具干所有事，谁好用我用谁，谁擅长什么就让谁上。

九、发布前最后过一遍清单

本地能跑，不等于能发布。发布前至少检查这些：

主流程是否能完整跑通空数据、加载中、接口失败是否有状态移动端是否正常登录态过期是否处理API Key 是否暴露npm run lint 是否通过npm test 是否通过环境变量是否配置完整

真的别嫌麻烦，很多 AI 项目不是死在写不出来，是死在没人验收。

十、最后

Vibe Coding 最迷人的地方是它让普通人也能做东西。但它最危险的地方恰恰也是这个。

它会让你产生一种错觉：

AI 会写代码，所以我不用思考AI 能生成页面，所以我不用设计结构AI 能修 bug，所以我不用看报错AI 能跑起来，所以我不用测试

哥们真不是这样...

AI 能把开发门槛打下来一大截确实不假，但它不能替你想清楚产品、不能替你定义边界、不能替你做最后验收、更不能替你承担混乱项目的后果！！！

所以 Vibe Coding 的核心，不是收藏多少 Prompt，而是你能不能把事情拆清楚、能不能给 AI 足够上下文、能不能控制它每次只做一件事、能不能让项目越写越稳。

以后真别再把 AI 当许愿池了，一定要把它当工程队。

施工图给清楚、规则立起来、进度管起来、验收别偷懒....

这样写出来的产品才真正能落地～