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。不是“帮我做个表单”而是“提交后显示成功提示并且数据存到本地刷新页面后列表还在”。后者本质上是把验收标准写进了 promptAI 生成的东西从一开始就是可验证的而不是一个徒有其表的空壳。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 不会跑偏。它知道从哪里拿数据、改哪些图、默认值是什么、成功标准是啥。对比一下“帮我加个筛选功能”这种 promptAI 往往会随机给你一套方案经常和你的数据格式对不上来来回回浪费好几轮对话。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所有组件用
Vibe Coding实战：用AI辅助编程从需求到代码的完整工作流
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。不是“帮我做个表单”而是“提交后显示成功提示并且数据存到本地刷新页面后列表还在”。后者本质上是把验收标准写进了 promptAI 生成的东西从一开始就是可验证的而不是一个徒有其表的空壳。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 不会跑偏。它知道从哪里拿数据、改哪些图、默认值是什么、成功标准是啥。对比一下“帮我加个筛选功能”这种 promptAI 往往会随机给你一套方案经常和你的数据格式对不上来来回回浪费好几轮对话。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所有组件用
