上个周末我参加了某个开源社区组织的“Vibe coding 动手做出原型”实操活动一口气用AI做了好几个能跑的原型过程相当上头。先把结论放在前面Vibe coding不是玄学它确实能帮你在一个下午之内把脑子里的模糊想法变成可以点击、可以提交、可以演示的界面临近成品。这篇文章我会把这套玩法的完整链路拆开讲清楚从工具选型、需求描述、提示词写法到高频翻车点和一个可复现的完整案例一次讲透。先说清楚适合谁看。如果你是自己有产品想法但不太会写代码的人或者你是被各种“乱七八糟需求”缠住的研发想快速做demo验证再或者你只是单纯好奇AI编程到底能玩到什么程度这篇都可以给你一个很具体的参考。我尽量不写虚的都是自己真跑过的过程中间那些“AI突然抽风”的时刻也没藏都拿出来说。1. 理解Vibe coding先搞清楚它改变了什么1.1 Vibe coding到底是什么“Vibe coding”这个词最早出现在一场大型业界对话里当时甚至被当成一个玩笑段子大意是“我不看代码写了什么凭感觉一直往下加需求然后让AI帮我搞定一切”。结果几个月过去大家发现这套方式真的能干活而且干活速度离谱于是“Vibe coding”正式从段子变成了工作流。我用一个更生活化的类比来解释。传统编程就像开手动挡汽车你得懂离合、换挡、油门配合每一段路况都要自己处理。Vibe coding相当于你坐在副驾驶只负责说“去东站走快速路中间别停”主驾驶上的AI帮你踩油门刹车打方向盘。你不需要知道发动机怎么工作但你得知道目的地对不对、路线有没有绕远这是人的核心价值。所以Vibe coding的本质是把“编码执行”这个环节外包出去人专注于“表达意图”和“验收结果”。目标很清楚用对话生成代码用运行结果做反馈用直觉做修正。你不需要会写每个函数但你要能看懂一个界面出来以后好不好用一个流程走下来顺不顺一个报错信息代表什么方向的问题。很多程序员第一次接触会本能地抵触“这不就是让AI写一堆垃圾代码吗”实话说如果硬把它当成生产级开发主力确实容易翻车。但要是把它用在“原型阶段”会发现它完美匹配。原型本来就是要快速试错、快速推翻的东西最怕的就是精雕细琢了半天结果方向错了。Vibe coding让你用很小的成本把想法变成可感知的东西然后赶紧拿给真实用户看。1.2 为什么它和“做原型”是天生一对做原型这件事成功标准从来不是“代码写得漂亮”而是“想法被看见了没有”。一个能点击、能输入、能展示错误状态的半成品比一份一百页的需求文档更能说明问题。Vibe coding恰好把“让想法被看见”这件事的门槛降到了历史最低。传统做原型最简单的路径是写HTML/CSS/JS或者用Figma画高保真图。前者有技术门槛后者画不出数据流转的真实状态。Vibe coding直接让你跳过了“从0搭环境”这个最劝退的环节。我实测下来的感受是一个带数据存储、多页面跳转、基础交互的小工具原型从描述需求到第一个能跑的版本大概只要一杯咖啡的时间。而且它提供了一个传统方式很难给到的东西可修改性。手画原型改一版要重画半天的图用AI做原型你只要说“把按钮从蓝色改成绿色”“把列表改成卡片”“加一个筛选功能”它几秒钟就改给你看。这种即时反馈带给人的创造欲很惊人你会忍不住从一个功能加到另一个功能最后得到一个超出预期的完整demo。当然Vibe coding的能量边界也要提前知道。它擅长做“看得见、点得着”的东西不擅长做需要高并发、强一致、复杂安全策略的后台系统。一句话总结它负责让想法“长出来”你负责判断这个想法“该不该长成大树”。2. 动手前的三件套需求描述、任务拆解、工具选择2.1 用三段式把需求一次说清楚很多人在Vibe coding上碰壁第一原因不是AI不行而是需求没说清。对着AI长篇大论讲了二十分钟业务背景结果它理解偏了生成的界面完全不是想要的。这其实和人沟通一样你得先讲清楚“谁在什么场景下遇到了什么问题”AI才知道该做什么。我给团队内部整理过一套“三段式需求描述法”实际用下来非常稳。第一段说背景这个产品是给谁用的解决的是什么问题。第二段说核心功能列出必须有的功能点按优先级从高到低排。第三段说限制条件不能用哪些技术栈、要什么风格、需要什么运行方式。这三段加起来控制在300字以内效果最好。举个例子。我这次做“路演点子收集箱”原型时第一版描述是这样写的做一个活动工具原型名字叫“路演点子收集箱”。场景是路演活动现场观众用手机扫码打开页面提交自己的点子包括标题、一句话描述、昵称提交成功后进入一个展示大屏。主持人需要在管理页能查看所有点子、置顶某一条、删除不合适的内容。数据先存在浏览器本地不接后端。页面风格要简洁现代适合投影大屏展示。这个描述里包含了场景路演活动、用户观众和主持人、功能提交、展示、置顶、删除、技术约束浏览器本地、风格要求简洁现代、适合大屏。AI拿到这样的信息基本不会理解偏。第二点要说清楚的是“不要做什么”。这很反直觉但特别重要。AI有很严重的“加戏”倾向你不告诉它不要登录系统它可能就自动生成一个注册登录页你不说不要联网拉取数据它可能就调用一个无效的API。所以在需求描述里显式地加一句“不要XX”往往比“要XX”更能防止跑偏。2.2 把原型拆成一轮一轮的小迭代Vibe coding最大的坑是“一次性需求给太大”。有一个朋友一上来就让AI生成“一个完整的电商管理后台”结果AI生成了几千行代码页面十几个看起来声势浩大但点开全是写死的假数据稍微改一个交互逻辑就直接崩溃。原因也很好理解大需求拆不细AI就会自己脑补结构脑补的东西跟你的预期误差极大而且出错之后很难定位。所以我的习惯是把原型拆成三轮小迭代。第一轮叫“骨架轮”目标只有一个页面能打开主要模块能看见。第二轮叫“流转轮”目标是把核心数据流跑通比如提交的内容能出现在列表里点击按钮能触发状态变化。第三轮叫“打磨轮”目标是视觉细节、交互反馈、边界状态比如空列表怎么办、超长文本怎么展示、按钮禁用状态等。每一轮只做一件核心事做完立刻运行验收验收通过再进下一轮。这样做的好处是AI的“翻车范围”被控制住了出了问题你很快能知道是哪个环节引起的。把大项目拆小本质上是在帮AI降低执行难度也是在帮自己降低排查成本。2.3 工具组合怎么选Vibe coding并不是只靠一个AI工具就能完成全部工作的我自己的常规配置是“AI对话助手AI编程工具本地运行环境”三件套。AI对话助手用来做方案讨论和提示词推演。你可以先问它“做一个多页面共享数据的纯前端工具数据用localStorage够用吗”它会告诉你不同方案的取舍。这部分对话不用生成代码纯粹是用AI当顾问避免做出技术上不合理的原型。AI编程工具则是核心执行器。现在主流选择分两种一种是能直接修改本地代码的智能IDE适合要频繁迭代、调试的场景另一种是云端的一体化生成平台输入需求直接渲染网页适合快速出静态演示。我建议做原型优先选能改本地代码的IDE类方案因为它能让你在运行、发现错误、修复之间形成闭环而不是生成完一堆代码就彻底失控。本地运行环境也别忘了。AI生成的静态页面如果直接双击HTML文件打开常常会因为浏览器安全策略导致局部功能失效最好用类似“本地静态服务器”的方式跑起来。这类工具很轻量装好之后在项目目录里运行一条命令就能起来然后浏览器访问本地地址即可。可视化、可点击的界面比纯看代码更直观。3. 实操全记录从零做一个“路演点子收集箱”3.1 这个原型要解决什么问题这次我分享的案例是一个真实发生在我身边的小场景。某个做路演活动的朋友向我吐槽活动现场观众想贡献点子但只能写在纸条上递上去主持人在台上念效率低还容易漏。东西一多根本没法排序、没法筛活动结束之后整理这些纸条更是灾难。我一听这太适合拿Vibe coding来练手了。给它设计了三张核心页面观众提交页每个人进来可以快速填三个字段然后提交大屏展示页自动轮播所有点子适合投影到会场屏幕上主持人管理页能看到完整列表对任何一条做置顶或删除操作。数据我需要它存在浏览器本地好在关掉页面再打开时数据不会丢。这个原型的边界特别清晰不涉及登录、不涉及权限、不涉及后端。它就是一个纯前端的小工具让信息流的“提交—展示—筛选”在三份视图中流转。既能把Vibe coding的核心流程完整覆盖到又不会因为复杂度失控导致演示失败。如果你也想尝试Vibe coding我很建议从这类“单场景、单角色、纯前端”的小工具入手而不是一上来就挑战大型系统。3.2 第一轮先让页面能打开我第一轮给AI的提示词严格按照前面说的“背景功能约束验收”结构来写。这里把原文贴出来供你们参考你是一位资深前端开发者。现在要做一个路演活动工具原型“路演点子收集箱”。场景是观众在活动现场用手机提交点子主持人侧大屏自动展示。请用HTML/CSS/JS实现三个页面submit.html观众提交页字段为“点子标题”“一句话描述”“昵称”提交按钮、screen.html大屏展示页标题下方用于轮播显示点子卡片、admin.html管理页表格列出所有点子每条有置顶和删除按钮。数据存储用localStorage保证提交后三个页面能看到同样数据。风格简洁现代深蓝色主色适合投影。先不要引入任何第三方库不要太复杂的样式。完成后告诉我如何在本地启动。这段提示词包含了角色设定资深前端开发者、任务目标三个页面、功能清单提交/展示/管理/置顶/删除、技术约束localStorage、不引第三方库、验收输出告诉怎么启动。AI理解得很到位直接生成了三个HTML文件和一个简单的启动说明。我按说明在项目目录里跑起了本地服务器打开localhost网页三个页面都能正常渲染页面框架已经立住了。这一轮的验收标准很简单页面上有对应的表单、卡片、表格样式大致符合预期没有控制台报错。第一轮不建议追求完美。AI生成的按钮间距可能不均匀颜色可能偏灰这都是正常的。骨架轮的使命是让“一个能看的东西”出现这样后续的修改才有参照物。如果一上来就纠结边距和配色往往会陷入无限修改的循环连主干流程都推不下去。3.3 第二轮把数据流转跑通到了第二轮我开始加真实的数据交互逻辑。先自己在提交页里提交几条测试数据然后打开大屏页看效果。结果发现一个问题数据确实存进localStorage了但大屏展示页完全不知道要读数据页面一片空白。这里补充一个知识点localStorage是浏览器基于同源策略共享的同一个浏览器、同一个域名下的不同页面都可以读到同一份数据。所以理论上提交页写入的数据大屏页和管理页刷新后是能拿到的。问题在于AI第一轮生成的大屏页压根没写“读取并渲染数据”的逻辑它只是搭了一个空壳。于是我针对这个环节发了第二轮指令大屏展示页目前是空的。请修改screen.html页面加载时从localStorage读取全部点子以卡片形式展示默认显示最新提交的一条每5秒自动切换到下一条切换时带一点淡入淡出效果如果没有任何点子显示“等待观众提交点子”的提示文案。只改screen.html不要动其他文件也不要改动数据结构。这次“定点爆破”式的指令很快奏效。AI在screen.html里加了一个定时器轮播逻辑同时处理了空数据提示。刷新页面之后我提交的几条测试点子开始在大屏上轮流出现滚动播放的交互感觉一下就出来了。接着处理管理页。管理页除了要把所有点子列出来还要有置顶和删除两个操作。删除比较直观点击后从localStorage里移除该条即可。置顶稍微复杂一点需要把某条记录的标记位改变然后在读取列表时排到最前面。还是同样的思路分开发指令让AI一次只处理一个功能。这里给出其中一条提示词在管理页的每个点子行增加“置顶”按钮。点击后把该条点子的isPinned字段设置为true并排序到列表最上方再次点击可以取消置顶。已经置顶的点子用明显的背景色标出。同样只改admin.html保持现有表格结构。改完之后我完整跑了一遍用户操作路径提交页录入三条点子、管理页置顶其中一条、删除一条、回到大屏页看轮播。数据流转完全符合预期这个原型的核心价值已经被实现了。数据流转轮最需要关注的是“状态变化后界面有没有同步”。我见过很多人做完原型单看每个页面都正常但一操作就发现列表不刷新、置顶不生效、删除后数据还在这往往是因为AI生成代码时给列表写的是静态初始化数据没有和localStorage做双向绑定。验收第二轮的时候记得多做一步一直在页面操作然后刷新页面确认所有变化都持久化下来了。3.4 第三轮视觉与交互收尾功能跑通之后进入第三轮打磨。这个阶段的心情其实和装修房子很像主体工程没问题了但越看越觉得细节粗糙。长标题把卡片撑得歪七扭八移动端输入框字号太小会触发自动缩放大屏轮播切换没有过渡动画切换太快看得有点生硬……这些问题不影响功能但影响演示观感。对付这些细节我建议不要让AI整体重写样式而是“指哪打哪”。一次只提一条样式诉求改了看完再提下一条。比如我发过这样一条指令样式问题卡片里的长标题目前会撑破布局。请给标题加两行省略号截断卡片高度固定为一致的高度三条数据在一屏内显示不全时允许滚动。只调整CSS不要改动HTML结构和JS逻辑。这条指令的关键约束是最后的“只调整CSS不要改动HTML结构和JS逻辑”。没有这个约束AI很可能觉得“帮你改得更彻底一点”结果顺手重构了整个布局给你惹出一堆新问题。AI的“越权发挥”在打磨阶段特别常见管住它的冲动比催促它干活更重要。视觉打磨轮还有一些可以批量处理的小项主色调统一、卡片圆角、间距层级、空状态文案、大屏切换动画时长。这轮做完整个原型已经从“打工人做demo”升级到“可以拿去给用户做演示测试”的程度了。我最终把三个页面连起来完整跑了一遍录制了一段演示视频发给朋友他看完的第一反应是“这工具下周活动就能用。”4. 高频踩坑与排查技巧实录4.1 五个绕不开的坑Vibe coding的过程中我踩过的坑和见过的坑基本可以总结为五类。列出来供你们提前避雷。第一个坑是“需求一次给太大”。这是最普遍的问题前面也反复提到过。AI面对超大需求时并不会跟你确认细节而是默默按它自己的理解生成一大堆东西里面至少一半不是你要的。下场就是你对着一个庞然大物无从下手。第二个坑是“不建版本快照”。AI改代码很经常是“大范围重写”可能你让它加个按钮它把整个文件的HTML结构都换了。如果过程中没有保留上一步的可用版本一旦改坏了就回不去了。解决方案是在本地项目里用类似快照的方式每跑通一个功能就同步一次代码记录。第三个坑是“AI想当然地加戏”。你不说清楚“不要什么”它就自动帮你加登录、加搜索、加外链、加各种你以为会来但根本不需要的东西。对付它的方式其实还是前面说的在提示词里写“不要引入未要求的逻辑”“只改动指定的文件”。第四个坑是“报错信息不会看”。很多人遇到红字报错就慌了直接把整个页面截图丢给AI也不说发生了什么操作。正确做法是把报错原文完整复制附上“我刚刚做了什么操作、期望什么结果、实际发生了什么”AI能很快定位。第五个坑是“反复改样式改到崩溃”。最开始让AI把按钮改大一点改完发现标题被挤掉了让AI再调标题结果卡片间距又乱了。样式之间的连锁反应很多最有效的办法是改样式前先把内容结构定死并且明确告诉AI“只动CSS”。我把这五个坑和对应解法整理成了一个速查表。高频问题典型表现解决思路需求过大生成内容大量偏离预期拆成骨架轮、流转轮、打磨轮三轮无版本快照改坏了无法回滚每完成一个功能就同步一次代码记录AI自行加戏多了登录、搜索等多余功能提示词中显式声明“不做XX”报错不知怎么排查只能整屏截图信息量不足复制报错原文补充操作步骤与期望样式连锁混乱调一处毁三处先定结构和逻辑再分条提样式诉求4.2 把报错喂给AI的三个动作调试是Vibe coding绕不开的一环。我发现很多新手在第一次遇到报错时会直接给AI发一句“报错了帮我看看”然后配上整个屏幕的截图。AI不是算命先生它看到这样的信息也只能猜。你可以明显感受到回复质量忽上忽下。后来我摸索出一个标准动作分三步第一步把报错信息原样复制包括文件名和行号不要截图里的模糊小字第二步补充你刚刚做了什么比如“我在submit.html点了一下提交按钮”第三步说清楚预期结果和实际结果的差异比如“我以为会跳转到大屏页实际页面卡住没反应”。三段信息给全AI的定位速度提升一个量级。如果你连报错信息都找不到记得教它“帮我看一下控制台和网络面板的区别”AI对话助手通常能解释清楚把解释贴给编程AI就能继续推进。调试这件事本质上是给AI足够的线索而不是考验它会多少魔法。还有一个经验当你把报错喂给AI后它给出的修复代码如果又引入了新的报错别慌这很正常继续把新报错完整复制给它循环两三次通常能稳定下来。怕的是你中途失去耐心开始自己胡乱改代码那样反而会把原本容易修复的问题复杂化。Vibe coding要求你沉住气把“让AI自我迭代”当成调试手段的一部分。4.3 防止AI越改越乱小步提交加约束“小步提交”听起来像是正经软件工程的词汇但在Vibe coding里也是救命稻草。我的做法是每完成一个完整的功能闭环就运行一次本地服务器确认它能工作然后做一次代码快照备注上“完成提交功能”“完成置顶功能”这样的说明。这样就算AI后面某个改动把整个页面搞崩我也可以直接回到上一次能用的版本然后重新下指令而不是在原地崩溃。与此同时每一次提示词里都要夹带约束条件。最常见的约束是“改动范围控制”。比如“只修改此文件”、“不要改变数据结构”、“不要引入新的库”。这些约束不是套话而是切切实实能让AI行为收敛的指令。我自己做过对比实验不写约束的时候AI经常顺手把其它页面的路径改掉页面全崩写上约束之后它就会老实很多。还有一种更精细的约束是“行为边界描述”。例如在置顶功能的指令里我特意补充“再次点击可以取消置顶”这会让AI处理状态的两个方向。如果在需求描述里漏了这种双向逻辑AI一般只会实现单向操作这正是很多原型“功能怪怪的”的深层原因。4.4 写提示词的五条实用经验把零散的提示词心得收敛成五条基本可以覆盖Vibe coding的大部分使用场景。第一条用“角色背景任务约束验收”的结构来组织提示词。角色设定是为了让AI调用更成熟的语境背景是让它理解场景任务要具体到页面和交互约束要明确划线验收是告诉它完成后你要什么形式的输出。五段式结构是效率最高的模板。第二条一次只说一件事。无论是功能修改还是样式调整一次提示词只聚焦一个目标完成并验收后再发下一条指令。有人会觉得这很慢但实际算总账这种“增量式”的方法比“让AI一口气做完”整整快一倍。第三条不要用空洞的形容词。与其说“做得好看一点”不如说“卡片圆角改为16px主色用深蓝#1E3A8A间距统一为24px”。AI对抽象感觉的理解非常依赖具体的参考锚点参数越明确结果越稳定。第四条报错信息永远原样粘贴。不要自己“翻译”成大白话AI对原文报错信息的理解能力远比你转述准确。第五条遇到AI反复出错时停下来开一场“对话外对话”。也就是切到AI对话助手单独问“这个功能如果用最简单的方案实现应该怎么做”把它的方案再看一遍修正思路后重新给编辑AI下指令。很多时候问题根源是方案本身不对而不是代码执行的细节不对。5. 从原型到真实产品边界与合作方式5.1 哪些原型适合Vibe coding哪些不适合虽然Vibe coding很强大但它的适用范围是有边界的认清这个边界能帮你省很多事。适合用Vibe coding做的原型通常具备这样几个特征核心价值是“信息展示和信息流转”用户操作路径简单数据量不大不需要实时同步安全要求不高业务流程能在单一设备或单一浏览器内闭环。比如我这次的路演点子收集箱、一个个人记账页、一个小团队的任务看板都很适合。反过来有些场景我不建议用Vibe coding硬做。涉及真实金钱交易的系统账务逻辑出错代价太高涉及多角色复杂权限的组织系统权限模型一旦设计错改起来比重写还难面向大规模真实用户的高并发服务原型阶段的代码结构基本无法承载还有算法主导的产品AI生成代码容易在数学模型上偷工减料。这些场景适合用来做高保真界面demo不适合直接作为正式系统使用。判断标准其实很朴素你做的这个原型如果出了问题最多损失一次演示那就可以Vibe coding如果出了错可能导致真实业务亏损或者数据丢失那就要交给正规开发流程。原型阶段的价值是降低不确定性而不是制造新的风险。5.2 交接与工程化的准备用Vibe coding做出来的原型除非就是临时演示一下否则最终大概率要交给工程师进行工程化重构。很多人在交接这一步翻车因为原型代码是AI生成的没有注释、没有规范、甚至没有README工程师接手后脑子里一片空白。这其实可以通过原型阶段的几个小动作来缓解。第一在原型功能稳定之后让AI给整个项目写一份README说明每个文件的作用、数据结构字段的含义、本地启动方式。这个过程不需要你自己动手写一句话提示词就能搞定。第二让AI梳理核心函数清单标注每个函数的输入和输出相当于生成了一份简易的技术文档。第三把演示过程中用户反馈最多的几个问题记录下来作为重构时的需求优先级依据。交接时最好附上一份简短的“产品行为说明”讲清楚哪些是刻意设计、哪些是原型阶段的凑合实现。比如“数据存在localStorage重构时需要换成服务端存储”“大屏轮播效果用定时器实现正式版需要考虑屏幕长连接性能”。有了这些说明工程师才能理解原型背后的设计意图。其实这里有个反直觉的点Vibe coding让原型的生成成本变得极低于是“重构一个原型”的决策门槛也变得更低。很多时候与其在AI生成的乱糟糟代码上打补丁不如让工程师参考原型的交互效果重新实现。原型真正的交付物不是代码而是已经被用户验证过的交互流程和功能优先级。5.3 人和AI的合理分工最后说一点我对人和AI协作模式的思考。Vibe coding并不是要把人的工作全部替代掉它改变的只是分工结构AI负责从描述到实现的翻译工作人负责判断方向、验收结果、决定方案。这个分工里最重要的能力反而是“审美判断”和“产品直觉”。我见过有人AI代码生成得飞快但做出来的原型没人爱用因为根本不知道该做什么东西。也见过完全不会写代码的产品经理靠Vibe coding做出来的原型让开发团队看了都惊讶。差别不在于谁用AI用得熟练而在于谁更清楚“要解决的问题是什么”。还有一点很关键验收时你要把自己放在“第一次使用这个产品的新用户”的位置上而不是“看着代码段运行激动的创造者”的位置上。很多细节比如空状态提示够不够清楚、按钮位置是否明显、表单提交后有没有反馈都要以新用户视角去体验。我每次做完一轮都会刻意隔几分钟再打开页面模拟一个陌生人第一次使用它。分工责任越清晰协作越高效。你负责问“为什么做”“给谁用”“好用吗”AI负责问“怎么做”“用什么实现”“代码报错怎么修”。当两边都在自己擅长的事情上发力时一个原型的迭代速度会快到你自己都觉得不可思议。我个人在实际操作中最深的体会是Vibe coding最迷人的地方并不是“不用写代码了”而是它让我敢把那些模糊的想法快速丢到现实世界里去碰撞。以前想到一个好点子光在脑子里模拟就要好几天现在一杯咖啡的功夫就能变成一个能点的原型拿给朋友看完两分钟就知道该改哪里该砍哪里。这种快速失败、快速调整的节奏才是它真正的价值所在。如果你准备开始试我的建议只有一条不要先学一堆理论直接选一个你身边真实存在的小需求打开AI工具用三段话描述清楚让它先出一个能跑的版本。代码写得乱不重要的先跑起来跑起来你就赢了。但记得做之前一定要想清楚那个“不要逻辑”——你在思考这一步上投的三分钟抵得上AI瞎折腾半小时。剩下的事情跑起来再说。