1. 从“先实现再说”到“让 AI 替你实现”：我理解的 vibe coding
先说结论：vibe coding 就是顺着感觉写代码，把大部分实现细节交给 AI 助手，自己把注意力放在“我想要什么效果”上。它的核心不是偷懒，而是把编程从“敲每一行自己手写”变成“描述清楚 + 快速验证 + 不断修正”，英文社区里那句名言很贴切：just vibe it，顺着那口气把东西做出来。我最早是在一个周末试了下这个思路，本来只想做个内部工具的小原型，结果不到四十分钟就把能跑通的版本端出来了，放在以前至少要折腾一个晚上加半个白天。从那以后，我就正式把 AI 辅助编程从“偶尔玩玩”变成了日常主力工作方式。
这个思路适合谁呢？首先是各行业里有点技术底子但没时间深耕代码的运营、产品、数据分析师，其次是像我这样需要频繁验证想法的全栈爱好者。它不是要替代你思考，而是把你从“语法细节的泥潭”里捞出来，让你把创造力花在问题本身。你可以不理解闭包、不背设计模式，但你需要知道自己想要什么页面、什么交互、什么数据流，然后把这种“想要”精确地翻译成 AI 能执行的 prompt。换句话说，vibe coding 的真正门槛不是代码，而是需求拆解能力。
我自己用了大半年，踩过不少坑，也沉淀出一套比较稳定的玩法。下面我把最核心的几个部分拆开讲：整体思路怎么搭、实操流程怎么走、工具链怎么配、遇到问题怎么排错。每个部分都是我实际跑过的，不是纸上谈兵。
2. vibe coding 的整体思路：从“灵光一现”到“能跑就行”
2.1 核心流程：一句话需求 → 拆解 → 生成 → 验证 → 迭代
我发现很多人用 AI 编程的最大误区是：上来就丢一大段抽象描述，比如“帮我做一个电商后台管理系统”，然后等着 AI 吐出一坨代码。结果往往是一堆骨架，跑都跑不起来。正确的做法是先拆。
以我常做的内部小工具为例，我会先问自己三个问题：这个工具最核心的一个动作是什么？谁会用它？它输入什么、输出什么？比如我曾经想做一个小型登记页面，核心动作就是“用户填表单，管理员看列表”，输入是表单字段，输出是表格汇总。拆清楚之后，我再把需求按这样的格式丢给 AI：
我要做一个小型网页应用，单页即可，不需要登录。功能分为两部分：第一部分是用户提交表单，包含姓名、手机号、留言；第二部分是管理员查看所有提交记录，按时间倒序排列，不需要数据库，使用本地 localStorage 存储。页面用纯 HTML + CSS + JavaScript 实现，样式要清爽，移动端能看。先给我完整的 index.html 代码。
这样一句话里包含了功能范围、技术选型、存储方式、界面要求和输出格式。AI 一次性生成完整文件的成功率会高很多。如果上来就写“后台管理系统”，它大概率会给你铺一个多余的前后端框架，反而不好收拾。
拆解的时候有个小技巧：把“结果”先想清楚再告诉 AI。不是“帮我做个表单”，而是“提交后显示成功提示，并且数据存到本地，刷新页面后列表还在”。后者本质上是把验收标准写进了 prompt，AI 生成的东西从一开始就是可验证的，而不是一个徒有其表的空壳。
2.2 为什么“先跑起来”比“一次写对”更重要
传统写代码讲究一次把逻辑想清楚再动手，vibe coding 则相反：先让 AI 给你一个能跑的版本，哪怕这个版本只有 70 分，也要先跑起来。原因是，AI 生成的代码你不实际运行，光靠看很难发现逻辑 bug，而一旦跑起来，报错信息、页面表现、交互效果会直接告诉你下一步该改哪。
我有一次让 AI 写一个倒计时跳转逻辑，生成完我扫了一眼觉得没问题，结果一运行，页面一直停在倒计时 0 却不跳转。原因是一个毫秒级的时间判断写得不够严谨，属于典型的一眼看不出来、一跑就暴露的问题。这就是“先跑起来”的价值：用真实运行结果当裁判，而不是用眼睛当裁判。
当然，“先跑起来”不意味着代码可以随便乱来。我给自己定了一条底线：AI 生成的每段关键逻辑，我一定要求它用注释解释一遍，确认自己看得懂主线，再往下走。这个习惯能救命的，尤其是项目变大以后，前面埋的坑不搞清楚，后面每改一次都是连环爆炸。
2.3 验证驱动的开发节奏：每改一步，立刻测一步
我的典型节奏是这样的：收到 AI 的代码后，先复制到本地环境跑通，然后立刻做一个最小动作验证。比如生成的是一个表单页，我会手动提交一条假数据，看列表是否更新；生成的是一个接口调用，我会在控制台打印 response，看数据长啥样。每次验证耗时都不超过一分钟，但能帮我在问题出现的最早期抓住它。
这个节奏本质上是把传统开发里的“单元测试”降级成了“手动冒烟测试”，对新手特别友好。你不用学 pytest、Jest 这些工具，只需要做到“改一点、跑一下、看一眼”。等项目的核心链路稳定了，再去考虑自动化测试，那是另一个阶段的事，对 vibe coding 来说不是起步的必要条件。
3. 实操环节：从需求文案到第一版可运行代码
3.1 提示词模板：我自己最常用的三种结构
搞了这么久，我总结出三段式的 prompt 结构最稳：
- 背景信息：一句话说清楚这是什么项目、给谁用、技术栈是什么。
- 任务目标：这一轮到底要做什么，是新建文件、改某个函数，还是修一个 bug。
- 验收标准：做完后怎么算是对的，界面长什么样，数据从哪里来、往哪里去。
举个例子，我在做一个数据看板项目时，要让 AI 帮我加一个筛选下拉框，我会这么写：
背景：这是一个纯前端的销售数据看板，使用 Vue 3 + ECharts，数据从已有的 data.js 变量读取。任务：在页面顶部加一个产品线筛选下拉框，选项从 data.js 中动态提取，不能写死。选择某项后，下方所有图表根据该产品线重新筛选数据并更新。验收标准：默认显示“全部”选项，切换到其他产品线时，折线图和柱状图的数据都同步变化，且控制台无报错。
这样写的好处是 AI 不会跑偏。它知道从哪里拿数据、改哪些图、默认值是什么、成功标准是啥。对比一下，“帮我加个筛选功能”这种 prompt，AI 往往会随机给你一套方案，经常和你的数据格式对不上，来来回回浪费好几轮对话。
3.2 建一个“会话备忘录”：解决 AI 失忆问题
AI 对话是有上下文窗口的，聊得越长，前面的信息越容易被挤出去或者被忽略。我的做法是：在每一个比较长的项目里，单独开一个文件叫 PROJECT_NOTES.md，把项目的技术栈、目录结构、核心约定全部写进去。每次新开一轮对话，第一句话就是把这份笔记的核心内容粘给 AI，让它“先读背景再干活”。
比如我会写：
项目背景：销售数据看板，Vue 3 + Vite + ECharts。数据集中在 src/data.js，导出变量 salesData，字段包括 date、productLine、revenue、orders。组件目录在 src/components 下，已经存在 SalesChart.vue。约定：样式使用 scss，所有组件用
