从今年年初开始“vibe coding”这个词一直在我时间线上刷屏。一开始我也以为这只是又一个被炒热的流行标签直到上个月我连续用这套方式从零做了三个小demo才意识到它改变的确实不只是“写代码的方式”而是“从脑子里一个模糊念头到屏幕上跑起来的东西”之间那段路的走法。这篇就聊聊我踩出来的完整路径从idea到demo工具怎么选指令怎么给迭代怎么跑以及哪些地方会莫名其妙浪费掉你两小时。1. 先聊清楚 vibe coding 到底在解决什么问题1.1 什么是 vibe coding它和普通“用AI写代码”有什么不一样vibe coding 这个词最早被广泛传播是 Andrej Karpathy 在一次分享里提到的。他用的说法很形象——你说不清自己在干嘛就是跟着感觉走一句话一句话地把需求喂给AI让它把代码写出来而你主要负责“看它跑起来没有”“哪里不对再告诉它改”。很多人的第一反应是这不就是让AI写代码吗我早就这么干了。但琢磨一下会发现vibe coding 的核心差别不在“用不用AI”而在你把自己摆在什么位置。传统用AI写代码你的角色更像“审查者”脑子里有一个明确的设计方案知道要用什么框架、什么模块、什么数据结构AI只是帮你把已知的逻辑敲出来最后你一行行review。vibe coding 不是这样。你更像是“产品经理加测试员”脑子里只有一个粗糙的想法甚至不知道这个想法应该用什么技术栈落地你一边和AI对话一边看它产出的结果一边修正方向。AI负责“把想法用代码试出来”你负责“判断这个方向对不对”。整个过程里你会频繁写出自己不完全看得懂、但跑得通的代码——这是 vibe coding 最让人不适、也最让人上瘾的地方。1.2 它真正降低的是“翻译成本”不是“学习成本”网上讨论 vibe coding 时最常被误解的一点是以为它可以让你完全不学编程就做出产品。我的实际体感是它降低的绝对不是学习成本而是从想法到可运行代码之间的翻译成本。举个例子。我想做一个“在网页上给照片加滤镜的在线工具”。如果走传统路线我得先确定用纯前端还是前后端分离图片处理放在浏览器端用 Canvas 还是上传到服务器UI框架选什么颜色矩阵怎么算这些决策本身对一个不熟悉前端生态的人来说每一个都是一道门槛随便选错一个方向后面要推倒重来。vibe coding 的路径完全不一样。我只需要说做一个网页工具用户上传一张照片能在左侧选择几种常见滤镜右侧实时显示出效果可以下载处理后的图片。AI会直接告诉我用 HTMLCSSJavaScript 加一个 Canvas 就能搞定然后一篇一篇把代码吐出来。我不需要事先知道 Canvas 的 API只需要在它跑起来之后点一点、看一看说“这个复古滤镜太暗了再提亮一点”“加一个滑动条控制模糊程度”。决策从“技术选型”变成了“产品体验判断”这就是它在降低的那部分成本。这也解释了为什么我建议有编程基础的人也别急着看不起它——它压缩的恰恰是写样板代码、搭工程结构、查文档这些最没创造性的时间把精力腾出来放在产品感觉上。1.3 vibe coding 不等于“放手不管”你的审美和技术判断仍然值钱我最开始尝试的时候犯过一个错误把需求说得特别宽泛然后等着AI给我一个完整项目。结果它给出一个能跑的网页但代码里到处是重复的函数、魔数、臃肿的依赖改一个小按钮样式都会牵一发动全身。那一刻我意识到vibe coding 对“判断力”的要求其实更高了。你需要能判断AI给的方案是不是过度设计了这段代码看起来不对劲的时候是应该让它重构还是先跑通再说以及最重要的——什么程度算“可以了”。这个东西靠感觉但感觉是有门槛的。没写过代码的人可能觉得“能跑就行”写过几年代码的人会知道“能跑”和“能改、能维护、能给别人看”之间差着一个银河系。所以我的个人结论是vibe coding 不是零基础者的天堂而是有经验者的杠杆。零基础用它能做出来demo有基础用它才能做出来产品。2. 从 idea 到 demo 的工作台我目前用的这套组合及理由2.1 工具不用多三样就够对话式IDE、AI助手、一个能跑的运行时经常有人私信问我 vibe coding 要用什么“专业工具”好像有什么神秘软件。实际上我跑通整个流程靠的就是下面这三样环节我用的工具作用写代码的编辑器Cursor 或 VS Code承载对话、展示代码、提供运行环境AI对话/生成核心编辑器内置的AI或Claude/GPT的网页版理解和生成代码帮你排查报错运行时本机安装的 Node.js / Python / Java让代码真正跑起来我的主力是 Cursor因为它的对话能和当前打开的文件、报错信息联动不需要我把报错内容复制来复制去。如果你不想用 CursorVS Code 加 GitHub Copilot 或者下载任一一款支持 AI 对话的编辑器也一样工具本身不是瓶颈关键是你能不能把“想法”清晰地描述出来。只有一个例外——如果目标就是写一个特别小的、纯前端的工具页比如计算器、图片格式转换器直接用 Claude 或 ChatGPT 网页版拿到代码粘贴进 HTML 文件双击用浏览器打开连编辑器都省了。我在做那种“一次性小工具”时经常这么干五分钟内搞定。2.2 为什么我不建议从“新建空白项目”开始很多跟我一样从传统开发走过来的人第一次 vibe coding 会有个执念让AI帮我搭一套完整的前端工程脚手架——Vite、React、路由、状态管理一步到位。我一开始也这么想着后来发现这是最容易翻车的开局方式。原因在于AI生成的代码规模越大越容易出现“上下文漂移”。你问它“帮我初始化一个 React 项目”它给你几十个文件你再让它改某个组件的样式它可能只改了目标文件但另一个文件里 import 的东西和你的需求对不上于是一个报错接一个报错。最糟的是你还不知道哪儿错了因为每个文件看起来都挺正常的。后来我换了一套思路先让AI给出一个最小可运行版本甚至都不用文件拆分直接在单个 HTML 文件里把核心逻辑跑起来。确认核心流程没问题之后再让AI把“能跑的东西”拆解成“工程化的结构”。这个顺序和传统开发完全相反但配合 vibe coding 的对话式节奏反而特别顺。2.3 环境准备Node.js 是默认选择Java 或 Python 看场景跑 demo 用哪个运行时取决于你的目标形态我在几个常用选项里做了对比网页工具/小应用Node.js配 npm是默认选择因为前端工具链都基于它装组件、启动本地服务都方便。数据处理/算法验证Python 更省事PYPI 生态里什么都有一行 pip install 就装好依赖。安卓 App / 后端微服务Java配 IntelliJ IDEA 或 VS Code更合适尤其是要做成能在手机上跑的 demo。IDEA 社区版就够用不一定非得上旗舰版。如果你不确定你的 idea 到底该用什么技术栈可以把决定权交给AI。我自己常用的第一句开场白是“我要做一个XX这个场景最适合用什么技术栈假设我是新手给我一套最简单的起步方案。”AI会给一个推荐项还会告诉你为什么比你花一下午去论坛考古靠谱得多。2.4 把版本管理从第一天就跟上哪怕只有你一个人这一点是我从一次惨痛经历里学到的连着两天改一个 demo第三天跑不起来了但完全想不起前两天改了哪里、哪一步改坏了。从那以后我养成了一个习惯——每完成一个可运行的小阶段就提交一次 commit。哪怕只有我一个人开发Git 仓库也是必须的。用 vibe coding 还有一个额外的好处因为每次改动都是对话驱动的提交信息可以直接用对话里的那句指令比如“add photo filter feature”。下次想让 AI 回滚到某个状态或者问它“为什么这个功能这样实现”直接翻 commit 记录和对应的对话效率非常高。我见过不少人做完 demo 之后后悔没建 repo希望看到这篇的你别踩同一个坑。3. 实操全过程从“我想做一个记账小程序”到跑起来3.1 第一轮对话把抽象想法“翻译”成AI能执行的指令这节我拿一个我最近做的真实案例来演示一个给个人用的记账小程序。整个过程我几乎没有手动写过代码每一行都是跟AI聊出来的。第一轮我给的指令是这样我想做一个记账小程序用在浏览器里。主要功能添加一笔支出金额、分类、备注、日期按分类和月份查看账单列表能统计某个月的总支出。先不用登录和数据库数据保存在浏览器本地就好。请给我最简单的实现方案最好一个文件就能跑起来。注意我在这句话里做了几件事说清了产品边界记账、支出、分类、月份统计、说清了技术要求浏览器、本地存储、不登录、不用数据库、说清了交付约束最简单、一个文件能跑。AI 秒懂给了我一个用 HTML CSS JavaScript localStorage 的方案然后一整个文件就出来了。有一个细节值得说如果你第一轮就说“帮我做个记账App”AI 会立刻往重了做——给你脚手架、给你后端、给你数据库配置然后你在配置环境上耗费一小时。“最简单、一个文件、先跑起来”这些限制词是 vibe coding 里最重要的魔法词。3.2 让“错误”成为你的下一步指令来源跑起来之后第一个版本是这样的表格能添加支出列出明细按日期排序顶部显示总支出。但我试了一下之后发现两个问题第一分类是自由输入的导致“吃饭”和“餐饮”成了两个分类统计结果就乱了第二没有“编辑删除”功能输错了只能删掉本地缓存重置。我没有自己动手改代码而是直接把我的感受发给AI现在有两个问题1. 分类必须是固定的几个选项不要自由输入2. 每条记录要能编辑和删除。分类我先用这么几类餐饮、交通、购物、娱乐、居住、其他。AI 把 HTML 里的输入框换成了下拉选择器给每条记录都加了编辑和删除按钮。整个过程大概三分钟。这个节奏非常典型——你不是在“指挥”AI写代码而是在“验收”它写出来的东西然后把“验收意见”反馈回去。用传统开发的心态你会觉得这像在开一个需求变更会用 vibe coding 的心态这就是最自然的工作流。3.3 迭代从“能用”到“像样”样式与交互细节的调优核心逻辑跑通以后我开始提视觉和交互上的要求。这些要求如果写成传统的 UI 设计稿没两页纸下不来但在 vibe coding 里就是几句大白话界面设计得清爽一点整体风格偏日式极简不要用默认的表单样式。月份统计的部分用卡片展示支出分类不同的颜色。移动端也要能正常看。AI 在原来的文件里动了 CSS加了几段响应式布局配色换成了低饱和度的感觉。浏览器里刷新一下整个观感立刻不一样了。第二轮我又追加了支出金额输入框要带货币符号月份切换用左右箭头底部的统计数字要突出显示。这些细碎的调优如果全都走“提需求-排期-开发-测试”的流程没有一周拿不下来用 vibe coding 一边聊一边改半小时就妥了。这里有个经验我要特别强调一次不要提超过三到五个修改点。我试过一次给AI列十个问题它改完以后有一半没改对有些地方还改出新的 bug。后来我改成每轮聚焦三五个点改完立刻验证通过之后再提下一批成功率直线上升。看起来很慢实际反而快。3.4 数据与持久化一个容易踩的坑记账小程序跑到第二周我遇到一个问题浏览器 localStorage 里的数据被我不小心清了所有记录都丢了。虽然只是测试数据但这也提醒了我——本地存储不等于持久化存储刷新网页还在换个浏览器、清个缓存就没了。如果你做的 demo 只是给自己验证想法localStorage 够用了但如果想分享给别人试用或者数据稍微重要一点就得让AI把存储层换成“后端数据库”。我当时的路子是让AI在本地跑一个最小的 Node.js 后端服务数据存到 SQLite 文件里前端通过接口读写。听起来很“重”但AI只需要几分钟就搭好了而且整个过程没有让我手动安装数据库、写建表语句——全部靠对话完成。这也是 vibe coding 一个隐藏的好处你可以渐进式地给 demo“加厚度”从纯前端到带后端从本地存储到数据库每一步都有可运行版本兜底不至于一开始就被工程复杂度劝退。4. 我在 vibe coding 路上踩得最疼的几个坑4.1 “上下文越权”问题AI 改着改着就丢了前面的需求这是我最常遇到的坑也直接决定了你对 vibe coding 的体验是好是坏。AI 的注意力窗口虽然是有限的但实际上的瓶颈在于当你的项目文件越来越多、对话轮数越来越长AI 很容易“只盯着你最后这句话”而忘了最开始定下的约束。最典型的一幕我在一个项目早期约定“不要引入第三方 UI 框架用原生 CSS”。到了第五轮我让它加一个弹窗组件它直接引了一个 UI 库install 了一堆依赖。我当场就有点哭笑不得——你不能说它错但它违反了项目最底层的约定。我的应对方案是两招开新会话时把项目简介和关键约定重新粘一遍。我常驻一个PROJECT_CONTEXT.md文件里面写清楚“这个项目是什么、技术栈是什么、哪些约定不可违反、当前完成到哪一步”每次开新对话或让AI做较大改动前先把这个文件贴给它。不要在一个对话里做太多不相关的事。“修登录逻辑”和“改首页样式”这两件事放在同一个对话里AI在改后者的时候很可能把前者改坏。分开对话各自独立出问题也容易定位。4.2 能跑 ≠ 安全AI 生成的代码里可能存在隐藏雷vibe coding 轻松愉悦的氛围会让人放松警惕但我在用 AI 写的代码里发现过不少让我后背发凉的细节。最吓人的一次我让它写一个图片上传功能它直接把上传接口拿来做图片处理且没有限制文件类型和后缀等于别人可以往我的服务器传任何文件。要知道我本来只是想要一个“个人相册”demo。从那以后我养成了一个强制习惯只要涉及用户输入、上传、登录、支付、数据导出这类敏感功能哪怕demo也必须让AI详细解释这段代码在干什么有没有安全风险然后我再单独针对安全性篏一轮对话问“这个接口有没有注入风险”“这个文件上传有没有校验”。如果你对安全不熟至少记得一句不要让 AI 生成的和用户数据相关的接口裸奔。另外API 密钥和 token 的问题也值得说一句。AI 有时会把一个硬编码的 key 直接写到代码里而你还不知道它是什么。我一般做完 demo 之后会全局搜一下api_key、secret、password这类词看看有没有不该出现的东西。真有的话立刻删掉用环境变量替代。4.3 不要盲目“重构”AI重构会让你的项目陷入循环崩溃我犯过的最浪费时间的一件事贪图“代码质量”让AI把一个能跑的小项目拆成多目录多模块的工程化结构。它拆到一半import 路径乱了好几个文件报红。我让它修它改了这个文件另一个文件又报错最后进入“按下葫芦浮起瓢”的循环整整耗掉一个下午最后我不得不从之前的 commit 回滚。我的教训是demo 阶段不要追求工程化跑通 结构。如果确实要重构务必在重构前提交一次 commit然后让AI一次只移动一个模块每个模块移动后都跑一遍原有功能确认没问题再动下一个。慢是慢了点但至少不会掉进循环。4.4 判断一个 idea 适不适合用 vibe coding 快速出 demo经过这阵子的尝试我总结出哪些想法适合、哪些不适合用 vibe coding 做供你参考适合的类型原因工具类网页记账、待办、图片处理交互边界清晰技术方案成熟数据可视化和报表AI 对图表库很熟出效果快小游戏贪吃蛇、2048逻辑不复杂反馈直接内部工作流的自动化脚本写出来给自己用不必追求完美不太适合的类型原因需要大量复杂交互和状态管理的 AppAI 容易把状态搞乱改起来很头疼强依赖某一特定硬件/平台的 App缺少环境AI 很难验证高并发或高安全要求的系统需要系统设计和专业的性能测试已有大量遗留代码的业务项目AI 难以快速理解历史上下文我个人的建议是刚开始学 vibe coding从“工具类网页”入手是最稳妥的。这类项目技术栈成熟、AI 生成的方案不容易跑偏而且给你带来的正反馈非常及时——通常十分钟内就能看到能用的成品。4.5 给新手的 v0 到 v1 练习清单如果你已经跃跃欲试我给你一套从小到大、从易到难的练习题都是我自己练过的路径做一个在线计算器纯前端用一个 HTML 文件做一个待办事项列表加入 localStorage 持久化做一个 Markdown 预览页面输入左边渲染右边做一个简单的记账页面加入分类和月份筛选做一个用公开 API 的查询工具比如查天气、查汇率每做完一个都试着用对话让AI加一个新功能然后观察它是怎么在原有代码上做改动的。积累到第五个你会发现你在给 AI 下指令的时候已经不再是一个“只会描述现象的外行”而是能说出“请把数据层和渲染层分开”“请用函数封装这段逻辑”这些真正的行话了。到这一步你就已经摸到 vibe coding 的门道不再是被 AI 带着走而是你在带着 AI 干活。我个人在实际操作里最大的体会是vibe coding 这把火烧掉的不是程序员的价值而是“从想法到demo之间那些磨磨蹭蹭的等待时间”。以前一个念头落地先考虑三天、再搭建一周、再写三周等真正跑起来的时候热情已经凉了一半。现在从 idea 到一个能点击、能交互、能给别人看的 demo通常就是一个晚上的事。这个速度带来的最大变化不是产出多了而是你愿意去尝试那些以前觉得“不值得做出来”的小想法了——而很多大东西恰恰是从这些小想法里长出来的。