说实话我以前一直觉得“VibeCoding”这种词就是程序员圈子里的又一个新潮概念听着玄乎实际上离正经项目很远。但上周末我用两个小时的整块时间真刀真枪试着用自然语言描述需求、让AI帮我写代码做出来了一个能玩、能分享、还能计分的小程序——“猜对了么”。从跟AI对话到真机预览跑通整个过程大约两个小时这中间还包括我中途去泡了杯咖啡的时间。这个小程序玩法不复杂屏幕中央显示一张图片下面是四个备选词你根据图片内容猜一个最贴切的词。选完立刻显示对错接着进下一题最后统计总分。听起来简单但“图片加载、随机抽题、选项状态、计分逻辑、标题动态切换”这些东西摊开来看又是一个麻雀虽小五脏俱全的微信小程序项目。这篇文章我就把整个VibeCoding过程、核心代码设计、踩过的坑一次说清楚给想尝试用AI辅助开发小程序的朋友一个可以直接照抄的参考。写这篇内容之前我先说清楚适合谁看你如果完全不懂代码但想用VibeCoding捣鼓出自己的小程序可以看思路和踩坑部分。你如果有一点点前端基础想在两小时内做一个能跑的游戏类小程序那核心功能和代码实现的部分可以直接照着抄。1. 从“跟AI聊天”到“成品小程序”VibeCoding的完整思路我先给VibeCoding这个概念做个大白话解释——它不是一种编程语言也不依赖某个具体工具而是一种“用自然语言跟AI对话让AI帮你生成代码”的开发方式。你描述需求AI补全细节你负责验证和微调整个过程像“聊天式开发”讲究的是快速验证、快速纠错。1.1 为什么选中了“看图猜词”这个题材做小程序的第一步不是打开编辑器而是想清楚做什么。我选看图猜词有三个原因。一个是数据简单。看图猜词的核心资产是一个题库每道题包含“图片、正确词、干扰词”这三样东西用数组就能装下不需要数据库也不需要后端。第二个原因是交互路径短。用户打开就是看题、点答案、看结果三步走完一轮非常符合小程序“即用即走”的调性。第三个原因是我私心——图片猜词天然适合分享。用户答对了想晒分答错了想吐槽这种情绪驱动比单纯的答题打卡强太多。确定题材之后我给AI下的第一个指令大概是这样的我要做一个微信小程序看图猜词游戏每道题有一张图片和四个选项点击选项判断对错下一题按钮进入下一题最后显示得分。这个指令听起来简单但AI能理解是因为我一次把“页面结构、交互事件、数据流”都说清楚了。1.2 小程序不是唯一选择但它是这个场景下的最优解其实做H5游戏也行甚至用网页版更快但我毫不犹豫选了微信小程序。原因很现实小程序有天然的分享卡片和社交传播路径。用户在微信里玩完直接转发给朋友对方点开就能玩不需要再走一遍注册或下载流程。对于“猜对了么”这种需要两个人较劲比分的游戏社交属性比技术炫技重要得多。另外小程序开发不需要管理服务器只要能跑通纯前端逻辑就可以通过微信开发者工具直接预览、上传、审核。我第一版就是纯前端实现题目数据全部写死在代码里暂时不涉及远程接口。这个决策保证了“两小时跑通”这个目标不被后端环境拖累。等以后题库需要动态更新了再去接云开发或后端服务也不迟。2. 两小时开发时间轴从念头到能玩我试着把整个开发过程还原成时间轴你大概就能感受到VibeCoding和传统开发的节奏差异。最关键的一点是——不要一次性把需求说完要分阶段让AI出活每一阶段都要能跑。2.1 第一个小时把需求“聊”清楚我给自己定的第一个目标是打开开发者工具能看见一个能点、能跳的静态页面。所以我先让AI生成了一个小程序骨架首页显示题目和选项点击选项后高亮对错底部有一个“下一题”按钮。第一轮对话我只要求这些其他什么都没加。当时我给AI的完整描述是请生成一个微信小程序项目包含 index 页面页面顶部显示“第X题 / 共X题”中间显示一张图片图片下方有四个居中的按钮作为选项点击正确选项时按钮变绿并提示“答对了”点击错误选项时按钮变红并展示正确答案。页面底部放一个按钮“下一题”点击进入下一题。这段描述里我把“状态视觉反馈”这个关键点也带上了因为AI默认生成的交互往往比较寡淡你不多说一句它就不做。AI很快给了一套项目文件结构、wxml模板和js逻辑我复制进微信开发者工具第一版直接就能编译通过。第一次看到空白模拟器里出现自己“聊”出来的页面时说实在的还挺有成就感的。2.2 第二个小时让AI写代码与手工缝纫静态页面跑通之后我进入第二阶段把题库数据接进去加入随机抽题、计分逻辑、题目进度、最终成绩页。这个阶段AI生成的代码就不那么“完美”了。比如它默认题库只有三条数据我手动扩到十条又比如它写的下一题逻辑没有判断题目是否耗尽答完最后一题还会继续跳显示undefined。这就是VibeCoding的真实面——AI能快速给你80分的架子但剩下20分的边界处理和人味儿还是要靠人补。我用了一个很实用的办法把AI生成的代码分成“能用”和“不能用”两类。样式、布局、基础交互基本能用先留下。数据逻辑、边界处理问题多要么给AI提更多上下文让它修要么我直接动手改。这个“人工缝纫”的环节没有想象中耗时大概二十分钟就调通了。2.3 上线前的关键一步小程序备案与发布如果你只是自己玩那到开发者工具里预览就够了。但想发给朋友玩就必须走微信小程序的发布流程。这一环节我直接说结论现在新注册小程序都需要先完成备案备案会要求在后台填写主体信息、服务内容标识、备注信息。备注信息这一栏很多人不知道怎么写我写的是“看图猜词小游戏包含图片展示、选项选择、得分统计功能不涉及用户生成内容”。简单说就是说明白你的小程序是什么、有什么功能、有没有敏感内容不用长篇大论。备案审核通过之后再用开发者工具上传代码在微信公众平台提交审核审核一般几个小时内就能过。这一步不算是开发环节但如果你是第一次做小程序建议把备案时间预留出来它不一定像代码一样“两小时搞定”。3. 核心功能拆解猜词逻辑与交互细节接下来进入正题——把“猜对了么”小程序里几个关键功能掰开揉碎讲清楚。我用的是原生微信小程序语法没有引入框架。这样对新手最友好而且微信开发者工具里调试也最顺畅。3.1 题库设计与随机抽题逻辑题库是这个小程序的地基。我用了最简单的数组结构每道题包含四个字段分别是图片地址、正确答案、干扰项数组和整道题的提示词。下方是该段数据结构的一个简化示例方便你直接参考。const questions [ { image: /images/cat.png, answer: 猫, options: [猫, 狗, 兔子, 老虎], hint: 这是一种喜欢抓老鼠的宠物 }, { image: /images/watermelon.png, answer: 西瓜, options: [西瓜, 南瓜, 冬瓜, 哈密瓜], hint: 夏天很解渴的水果 } ];每次开始游戏时我会把题库打乱顺序再截取前12道作为本局题目。打乱用了一个经典的洗牌算法核心思路是倒序遍历数组将当前元素与前面随机位置的元素交换位置。这个写法的好处是每条数据只会参与一次交换不会出现重复选取的问题。function shuffle(arr) { const list [...arr]; for (let i list.length - 1; i 0; i--) { const j Math.floor(Math.random() * (i 1)); [list[i], list[j]] [list[j], list[i]]; } return list; }我有一个教训千万不要在每次渲染时都调用一次随机函数生成选项顺序。那样做会导致一个问题——用户还没点击选项可能已经悄悄换了位置看起来像页面闪了一下。我最终的方案是每局开始时只洗一次所有题目顺序同时把每道题的四个选项洗乱整个游戏过程中数据不再变动只有用户点击后的状态变化。3.2 选项单选的交互实现选择题的交互本质是“单选”——用户从四个选项里选一个选中后进入判定状态。这里最容易被新手忽略的是“状态锁定”。也就是说一旦用户点了某个选项在所有结果展示完成之前其他选项不能再被点击。我通过一个名为answered的布尔标记来控制初始为false用户点击选项后立刻置为true此时所有选项的点击事件都会提前返回。只有点击“下一题”时才把answered恢复为false。这个标记如果写漏了会引发连锁bug用户连续点击多个选项计分会跳变视觉上也会出现多个绿色按钮。我下面贴一段简化版的选项点击处理逻辑。它做的事情是先判断是否已经作答然后根据选项值判断对错最后把当前结果保存到 data 中用于样式渲染。handleSelect(e) { if (this.data.answered) return; const selected e.currentTarget.dataset.value; const current this.data.currentQuestion; const isCorrect selected current.answer; this.setData({ answered: true, selected: selected, isCorrect: isCorrect }); if (isCorrect) { this.setData({ score: this.data.score 10 }); } }界面层的视觉反馈靠条件 class 来实现。我对比了正确答案和用户选中项给每个按钮动态绑定一个样式类名。正确项始终显示绿色用户选错的项显示红色其他选项淡化显示。这样用户一眼就能看清“正确的是哪个、我错在哪个”。3.3 动态设置导航栏标题一个容易被忽略的体验细节这个小程序里有一个小细节我特意让AI加上了——每一道题的导航栏标题都不一样。第一题显示“看图猜词 第1题”第二题显示“看图猜词 第2题”。听起来微不足道但实际玩的时候它能给用户一种“正在一关一关往前推进”的进度感。微信小程序里设置导航栏标题有两种方式。一种是在页面的 json 文件里写死另一种是在 js 里调用wx.setNavigationBarTitle动态修改。我显然用的是第二种。每当切题时我都会顺便更新一下导航栏文字。nextQuestion() { const nextIndex this.data.currentIndex 1; if (nextIndex this.data.questions.length) { wx.redirectTo({ url: /pages/result/result?score this.data.score }); return; } this.setData({ currentIndex: nextIndex, answered: false, selected: }); const current this.data.questions[nextIndex]; wx.setNavigationBarTitle({ title: 第 (nextIndex 1) 题 }); }这里有一个要注意的地方wx.setNavigationBarTitle并不会改变页面顶部标题在微信聊天列表里的分享卡片显示那部分需要在onShareAppMessage里单独设置。如果你希望分享给朋友时卡片也带题目进度可以在分享函数里拼接参数。3.4 计分、进度条与结算逻辑计分规则我设计得很简单一道题10分总共10道题满分100分。答对加10分答错不扣分。结算页按分数区间给不同评语——90分以上是“看图猜词王者”70到80分是“眼力不错”60分以下是“再练练眼神”。这种轻量化的反馈比单纯显示一个数字更能激发用户的分享欲。进度条我没有用微信自带的 progress 组件而是用一个 view 自绘的。原因在于自绘进度条在视觉上更可控想做圆角、想做渐变、想做动画都方便。实现逻辑也很简单外层是一个灰底圆角条内层是一个按百分比拉伸的色块宽度绑定到 data 中的progressPercent每次切题后重新计算。computeProgress() { const percent Math.round((this.data.currentIndex / this.data.questions.length) * 100); this.setData({ progressPercent: percent }); }结算页的入参是得分我通过wx.redirectTo在 url 里拼接score参数然后用onLoad里的options.score读取。这里有一个新手容易踩的坑redirectTo会关闭当前页面用户点击返回时不会回到答题页而是直接退出小程序。对于“答完即走”的结算页来说这个行为是合理的不会出现返回答题页的尴尬循环。4. 踩坑实录AI写小程序最容易翻车的几个地方做这件事最有意思的部分其实是跟AI“斗智斗勇”的过程。AI写代码速度是真的快但它对微信小程序的某些“隐性规则”理解得并不透彻。下面几个坑是我实测遇到的每一个都值得你留意。4.1 图片路径和资源加载最基础的坑微信小程序的图片资源有两种主流放法一种是把图片放到项目目录下用绝对路径引用另一种是传到云端用网络地址引用。我因为初期想跑通逻辑用的是本地图片。AI第一次生成的路径是按http://localhost:3000/images/cat.png写的这在开发者工具里还能勉强显示一旦真机预览就完全空白。排查方法很简单——打开调试器的Network面板看图片有没有报404或加载失败。微信小程序的本地资源路径必须以/images/xxx.png开头不能写http://localhost更不能写相对路径../images/xxx.png。我后来把所有图片素材统一放到了miniprogram/images目录下并且在 project.config.json 做了正确配置。4.2 主包引用分包组件的限制这算是我这个阶段踩得比较深的一个技术点。为了后面扩展方便我尝试把结算页拆到分包里结果发现主包的页面如果直接引用分包里的组件在真机上会报错提示找不到组件。官方规则是主包不能引用分包中的资源反过来分包可以引用主包中的公共组件。这个限制在AI生成的代码里完全不会体现因为AI不会主动帮你做分包规划它默认所有页面都放主包。我的做法是暂时不拆分包所有页面都平铺在pages目录下。等以后题库和页面多了再按规则去把独立页面拆到分包里。如果你一开始就用了 uni-app 到微信小程序的转换链路分包配置会更灵活一点但也要提前确认组件引用关系。4.3 AI自作聪明的计分bug这是最让我哭笑不得的一次。AI生成的第一版计分逻辑在答对时不是加10分而是用this.data.score currentIndex * 10直接乘法。这个写法的结果是只要你做到最后一题不管前面正确率多低分数都是100。原因是AI想当然地以为“第几题就对应第几个十分”完全没考虑正确率。这种bug不跑一遍完整流程根本发现不了。我当时测试时一路瞎点最后得分居然是100我还愣了几秒钟。排查的办法是打印每道题的答题记录和分步得分把每轮的score变化打在调试面板里才发现只有最后一步变化中间全是0。后来我改成每次答对时在原有分数上加10问题就消失了。这给了我一个很重要的提醒VibeCoding生成的逻辑尤其是涉及状态累加、数据变化的代码你必须要拿真数据走一遍全链路测试。AI擅长生成“看起来合理的代码”但它不会替你做业务规则验证。4.4 真机调试与基础库版本差异开发者工具里跑得好好的真机上一打开就白屏这种问题我遇到过。那次的问题根源是基础库版本过低AI用了wx.getUserProfile这类接口而我的测试机基础库太老不支持。解决方式是在微信公众平台后台上调最低基础库版本或者在开发者工具的“详情-本地设置”里修改调试基础库。建议保留一个保守的“调试基础库版本”一般是2.30以上即可。另外真机调试建议直接扫码预览不要只在模拟器里看因为模拟器对很多接口的兼容性判断和真机不完全一致。关于用户手机号我也说一句很多新手一上来就想做“获取用户手机号”。但微信小程序的手机号获取现在有严格资质要求个人主体小程序基本没戏需要企业主体且通过认证。像“猜对了么”这种纯前端小游戏完全不需要手机号一个匿名用户ID就足够区分答题人了。5. 经验总结与下一步扩展建议做到这一步“猜对了么”已经是一个能正常发布、能分享、能玩的小程序了。它不算复杂但它完整地走过了从需求、设计、开发、测试到上线的整个链路这对VibeCoding的新手来说是一个非常好的样板。5.1 VibeCoding的正确打开方式我实测下来的心得是VibeCoding不等于把需求丢给AI然后什么都不管。AI的作用是帮你把“从空页面到80分成品”的时间压缩到极致而你依然需要花时间在跑测试、查边界、改样式上。但它确实让开发门槛降了一个量级——你不需要精通JavaScript也能改逻辑因为AI生成的代码是模块化的你只要找到对应的函数描述你想改的效果它就能给你新的代码块。我给准备尝试VibeCoding的朋友一个建议先从纯前端、无后端的小项目开始比如计算器、小游戏、便利贴这类项目不需要处理登录态、不依赖服务器最容易两小时跑通。等跑通了再逐步加需求让AI帮你迭代比一上来就做一个需要数据库和鉴权的商城小程序要现实得多。5.2 从“猜对了么”还能长成什么这个小程序目前只完成了核心玩法但它已经留好了扩展口。题库的数据结构里有hint字段后续可以做“提示按钮”答错或卡壳时消耗一次提示机会。目录结构也是按“主包页面公共组件”的方式排的想加入“每日挑战”“排行榜”这类功能只需要新增页面和接口不需要动现有的答题流程。如果想让题库动态更新下一步应该接入云开发。微信云开发自带云数据库、云函数和存储正好可以放图片资源和题库数据用户每次打开游戏时从云端拉取最新题目玩法就可以从“固定题库”变成“每日换新”。最后再分享一个小技巧AI生成的代码里样式部分往往是最平庸的。如果你想在小程序里做出层次感可以把view换成可点击的button同时把默认的button边框去掉自定义圆角、阴影和背景色。这样整个界面看起来就不像“AI直出”的demo而像一个正经上线的产品。“猜对了么”的按钮样式就是这么调的前后视觉效果差距非常大。