先交代一下背景我最近用AI以对话式开发的方式也就是大家说的 vibe coding把一个小程序从零到一做了出来并且已经顺利跑完了本地调试和真机预览的全流程。整个过程差不多花了两天实际写代码的时间可能不到一个小时剩下的时间全在和AI沟通需求、调样式、修边界情况。这篇记录就把我踩过的坑、摸索出来的对话套路以及最后的成品效果事无巨细地分享出来。如果你是个想入门小程序开发但一直没动手的新手或者你已经在写业务代码、但想试试让AI帮你加速日常开发再或者你单纯好奇“AI写代码到底能不能真正落地”这篇文章应该都能给你一些参考。我不会只展示“AI好厉害”的成果更想聊聊它哪些地方特别顺手、哪些地方差点把我气到摔键盘。1. 为什么我拿“小程序”开刀做 vibe coding我手头其实攒了好几个想做的小工具一开始纠结过要不要先做个网页版或者命令行工具但最后选小程序是因为它能逼着AI走完一套完整的项目闭环而不只是生成几个零散的脚本文件。1.1 小程序对AI来说是个“天然好捏”的载体小程序有一套固定的目录结构页面文件、组件文件、配置文件、样式文件分工明确逻辑层和视图层分离。这套约定比传统前端项目要死板得多但死板反而给了AI非常大的优势它不需要去猜你的工程搭建方式而是直接按照平台约定生成一套能跑起来的骨架。我用的是某小程序开发框架AI生成的代码几乎不用改目录结构文件放对位置就能直接编译。相比之下如果你让AI“写一个Web应用”它反而容易迷茫因为 React、Vue、工程化工具链、CSS方案都有太多分支选择生成的代码往往能看但不好接。而小程序这边页面就是 JSON 配置加 WXML 结构加 JS 逻辑加 WXSS 样式AI在这套稳定上下文里表现得非常靠谱。另外小程序天然带有云开发能力数据库、存储、云函数都是开箱即用这对“快速做出一个工具型产品”是致命加分项。你不用自己搭后端也不用处理域名备案和服务器部署AI生成的前端代码可以直接对接云开发语法。可以说小程序的开发范式正好长在AI的舒适区里。1.2 我最终要做一个什么样的成品我不是想做一个花里胡哨的Demo而是想解决一个真实生活问题平时经常需要在多个平台间收集零散信息比如临时记一笔金额、存一段随手抄来的文字、记录某个地点的坐标。用备忘录太乱用笔记软件太重打开即记、按标签快速筛选才是刚需。所以我把目标定为一个极简的记录工具小程序核心功能只有三个快速新增一条记录、按标签筛选历史记录、支持简单的关键词搜索。界面走极简风不需要登录本地缓存优先数据量大了才引导用户用云开发同步。这个尺寸的项目既能考验AI的完整度又不至于复杂到失控。提示给AI下需求的时候目标越“单一”越好。我见过很多翻车案例上来就描述“做一个社区团购社交积分商城”AI生成出来的东西既不像话也没法调试。小步快跑先从最小可行版本开始。2. 工具选型和对话式开发的方法论工欲善其事必先利其器。vibe coding 看起来像是“随便聊就能出代码”但实际效果天差地别。我试了两三个AI编程工具最后稳定在一个老牌通用AI助手上面下面说说我的选型维度和对话技巧。2.1 AI编程工具怎么选更顺手当前市面上的AI助手非常多我的筛选标准归纳下来就三条上下文长度、代码库理解能力、多轮对话的稳定性。上下文长度决定了它能记住多少你之前的修改。我一开始用某个开源本地模型试过靠聊天窗口连续对话结果它过一会儿就把前面定好的页面结构给忘了让我非常头疼。后来换成云端服务上下文拉长之后整体流畅度明显上了一个台阶。代码库理解能力比很多人想象的重要得多。一个懂小程序工程的AI会知道修改一个页面的时候需要同步改 JSON 里的导航栏配置、JS 里的数据字段、WXSS 里的样式类名。弱一点的AI只会改你提到的那一处导致页面能编译但整体风格稀碎。多轮对话稳定性则关乎体验。开发过程中你肯定会反复提出小调整比如“这个按钮往上挪一点”“字太大”“颜色太艳”如果AI每次调整都会顺带把无关代码也改一遍那对比差异就很痛苦。我用的那个工具在这一点表现尚可但也不是每次都能精准命中。2.2 我最常用的三段式需求表达法跟AI沟通需求我强烈建议不要甩一两句话就让开工。要把你的需求拆成三个部分我称之为“身份 任务 边界”。身份是让AI知道你在做什么场景任务是具体的功能描述边界是告诉AI哪些不能做或者先不做。一个典型的开场prompt是这样的你是一个熟悉某小程序开发框架的前端工程师请帮我创建一个极简记录工具小程序首页是记录列表底部有新增按钮点击后弹出半屏输入面板支持填写文本、金额和标签本次先不要接云开发数据库数据存本地缓存。最后再加一句生成时请把文件清单列出来每个文件标注用途。这套说法的好处是AI会在生成代码之前先做一层工程规划。我实测下来只要把“任务”描述清楚AI给出的文件结构基本能对得上省去了大量来回纠偏的对话。2.3 从“模糊想法”到“技术需求”的翻译技巧作为非科班出身的人我一开始根本不知道小程序里“弹出半屏输入面板”在技术上叫半屏弹层还是底部抽屉也不清楚要用到什么组件。但我学会了让AI帮我做翻译先描述感受再让它给我技术方案。我第二次对话时直接说我想在首页做一个按钮点击后从底部滑上来一个浅灰色的面板里面可以输入文字这个在你们小程序里一般用什么组件实现AI直接给出了可用的方案还推荐用内置的半屏弹层组件。那一刻我发现vibe coding 的门槛比你想象低你不需要懂专业名词只要能把想要的效果描述出来AI会帮你把概念转成代码语言。心得有时候与其直接问“我要实现XXX功能”不如先说“我想要一个什么样的体验”让AI给你补充技术选型。它给出的名词解释和组件推荐本身就是在帮你补课。3. 实操记录两天做出一版能跑的小程序下面进入正题我把整个开发过程按时间线拆开记录关键节点、核心对话和最终代码形态。如果按照本文的步骤走大概不需要两天你可以压缩到半天。3.1 初始化项目骨架的完整流程我先在本地安装好小程序开发者工具然后新建了一个空白项目。接下来我没有像传统流程那样手动创建一堆文件而是直接打开AI对话窗口把下面这段需求扔了进去。我需要一个记录工具小程序要求如下使用原生小程序开发不需要第三方UI库tabBar 有两个页面一个用于记录列表一个用于标签管理记录列表页需要支持下拉刷新每条记录在列表上展示标题、标签和金额数据先存本地缓存封装一个 storage 模块方便后续替换成本地数据库请先创建 project.config.json 之外所有必要文件并标注每个文件的职责AI返回了完整文件清单包括 app.js、app.json、utils/storage.js、pages/index/index、pages/tags/tags 等约10个文件。我不需要自己动手创建任何文件只需要在工具里点同步就能看到。这个环节最惊艳的不是代码本身而是AI把所有基础配置一次性给齐比如页面路径注册、tabBar 的图标路径占位、全局样式变量基本不用再手动排查。3.2 核心页面和交互的搭建过程记录列表页是整个小程序的门面。AI生成的基础版本做了一个纵向列表通过 data 数组循环渲染。但首批代码并不完美主要问题在于没有空态页面首次使用一片空白让人误以为报错了。我于是追加了一个调整需求当记录列表为空时展示一个居中的提示文案和插图文案用“还没有记录点右下角添加一条吧”。添加记录交互我一开始没想清楚所以让AI自己提方案。AI给了一个底部半屏弹层方案里面包含一个多行输入框、一个标签选择器和一个金额输入框。提交时做基础校验标题为空就轻提示不阻断输入。这部分生成得比较稳定我几乎只改了标签选择器的样式把胶囊式标签改成了更适合单手操作的网格样式。存储层是比较容易忽略但非常重要的部分。AI生成的 storage 模块封装了 get、set、remove 几个方法还做了 JSON 解析异常保护。如果后端数据格式变了或者本地缓存里的数据损坏了不至于整个页面崩溃。这套封装我后面在真实设备上跑的时候的确派上了用场。3.3 如何一步步让AI把风格调成我想要的样子我审美比较固定喜欢大字号、粗细对比明显、背景干净的风格。但AI默认生成的是典型的“模板小程序感”浅灰色背景、蓝色按钮、方角卡片。为了调整观感我用了风格参考法把一段直接描述发给AI。请把首页列表的卡片改成白色背景、大圆角、细边框标题字号放大到34rpx且加粗标签使用浅色底深色字金额右对齐并用等宽字体风格。整体风格走清爽、克制、偏纸质笔记本质感的路线。颜色主色用深灰辅助色用浅绿不要用任何渐变色。这里AI的文案理解能力是关键。它能把“纸质笔记本质感”转化成“大留白”“细分割线”“米白背景”等具体样式参数。经过三轮调整最终的视觉风格跟我的预期大概重合了80%。剩下那20%是我自己手改的样式变量实在不值得为了它跟AI来回磨。3.4 云开发接入从纯本地到数据同步第一版跑通后我开始给它加“后手”通过云开发把数据备份到云端。为什么要加这一步因为纯本地缓存有一个致命问题小程序更新或者清理缓存后数据就没了。万一用户换了台设备记录就彻底丢失。接入云开发不需要写任何后端接口。AI生成了一段云函数代码用于同步本地记录与云端集合。我只需要在开发者工具里创建对应环境名再配置好 collection 权限即可。AI生成的云函数写得相当工整错误处理完备代码质量甚至比很多外包团队的初始版本高。不过这里有一个很重要的教训AI对云开发环境配置的理解是默认“你已经有环境了”它不会提醒你去开通云服务也不会帮你处理环境ID。这一步折腾了我将近一个小时最后是我自己发现环境列表是空的创建之后所有请求才恢复。注意用AI生成对接云开发的代码时提前把“环境ID”“集合名”“权限设置”这些边界条件在prompt里说明否则AI会给出一份理论正确但跑不通的代码。后来我在第二次类似项目中吃了这个亏。3.5 真机预览与编译调试的实操记录开发工具里的模拟器跑得很好不一定是真机没问题。我碰到最典型的问题是底部安全区适配iPhone 全面屏底部那条横线直接覆盖了tabBar点按区域直接失效。AI在代码里没有处理这个因为开发工具默认不显示真机的完整安全区。解决办法是让AI在样式里加上环境变量的适配代码使用 safe-area-inset-bottom 处理 tabBar 高度同时给弹层底部加上安全距离。AI对这个问题的理解很快替换样式后真机表现正常。另一个高频问题是组件自带的默认样式在不同平台下的表现不一致。比如单行省略的写法在开发者工具里正常在部分安卓机型上会显示三行。这些属于平台级差异AI的代码规范没问题但没法预判所有机型。我的策略是凡涉及文本截断统一用多行截断写法并用样式覆盖默认行为。4. 我在 vibe coding 过程中踩过的具体坑这一节是我认为最有价值的部分。网上许多教程讲到AI生成代码都是报喜不报忧但实际开发过程中狗血剧情真的不少。我整理了五个最具代表性的翻车现场每个都附上了排查思路和最终解法。4.1 需求描述太抽象代码能跑但完全不是我想要的第一次给AI描述首页时我说的是“要好看一点”。结果AI给了一套带轮播图和动态背景的模板式页面完全不适合记录工具。我意识到问题在于“好看”是主观感受不是可执行指令。从那次以后我所有需求描述里必须带上参考关键词比如“类似苹果备忘录的极简风格”“参考豆瓣电影的卡片布局”AI的生成效果立刻稳定了一个档次。4.2 上下文窗口再长也挡不住它“记忆飘移”聊到第25轮的时候AI突然把之前定义好的存储字段名改了从 text 改成了 content。这导致列表页和新增页彻底失联页面能编译但数据根本显示不出来。排查花了我20分钟。后来我学乖了涉及关键字段名和公共模块时直接把前后端依赖关系发给它并提醒“不要改动storage模块的对外方法名”。实操心得如果你在一个项目里长时间对话一旦发现AI开始频繁“自创”命名果断开启新对话并把目前的完整文件结构和核心导出字段贴进去。新对话虽然丢了记忆但至少不会继续在错误的命名上叠加。4.3 样式“越调越崩”不如在关键节点锁版AI改样式存在一个天然缺陷它没有“视觉记忆”。你让它把按钮改成青色它会把全站所有按钮都改成青色甚至把选中的标签也改成青色。改完你告诉它太青了它又可能把卡片背景也带了。在连续五轮样式调整之后我意识到必须“锁版”每次对样式满意后就明确告诉AI“当前样式已确认后续只修改交互逻辑不要改动任何颜色和间距”。这招非常管用它后续的改动基本不会触碰样式。4.4 AI对“平台差异”缺乏直觉真机跑了才知道开发者工具和真机是两个世界这句话在小程序里尤其正确。AI能处理代码层面的兼容问题但无法感知物理设备上的表现差异。比如自定义弹层在部分安卓机上有蒙层穿透问题点击蒙层关闭的同时也会触发底层页面的滚动事件。这些BUG在模拟器上完全无法复现只能靠真机用户反馈。我的排查方式是把问题描述给AI告诉它“点击蒙层会连带触发底层页面的滚动应该使用 catch 冒泡捕获还是禁用底层滚动”也就是给出二选一的处理方向。AI给出的方案准确且不引入新问题。4.5 别被“一次性生成”的爽感骗了结构化重构才是老江湖的做法在项目快收尾时我突然想加一个数据统计功能让AI把所有记录按月份汇总。AI尝试直接在列表页里塞一段汇总函数代码逻辑没有问题但页面开始变得臃肿。这一步是我主动叫停并要求它重构的把统计逻辑抽到独立模块页面只做展示。AI重构后的代码清晰很多甚至把没必要传给页面的字段都过滤掉了。这件事给我的启发是AI能加速编程但架构设计的主动权还是要留在自己手里。你可以不懂每个函数的内部实现但至少要能判断哪些代码正在变得不可控并果断指挥AI来一次重构。5. 如何把AI写代码这件事真正变成你的开发习惯项目收官后我复盘了整体工作流。vibe coding 并不是“让AI替代你写代码”而是“让你用产品经理的思维来管代码”。它带来最大的变化是开发和设计之间的反馈循环被压缩到分钟级。以前改一个按钮可能要翻半天代码现在一句话就办到了。5.1 我给新手的三条“降噪”建议第一每个功能模块单独开一个对话。比如新增记录一个对话标签管理一个对话云开发一个对话。不同模块之间的技术栈虽然相同但对话上下文如果混杂在一起AI容易把A模块的风格带进B模块。你可以把公共字段发给每一个对话但不要在同一个对话里跨模块做大改。第二一定要让AI先输出计划再生成代码。我通常会在具体需求后面加一句“先输出你的实现计划计划确认后再写代码”。这个要求会显著提高代码的符合度。AI在写代码之前已经规划好了不会写一步想一步结构性错误少非常多。第三养成版本控制的习惯。没上正经代码托管工具之前我全靠手动备份文件。有一次AI把一整页代码改出问题我想退回前一版居然找不到只能靠AI重新生成再手动缝合极其痛苦。后来把项目托管好每次让AI改完方便随时对比。5.2 vibe coding 的适用边界我现在更愿意把 vibe coding 定义成“创意快速验证工具”而不是“生产级开发手段”。如果你要做的是一个内部工具、个人作品集、课程项目、Hackathon Demo它几乎是无敌的效率神器。但如果你要做一个需要大量真实用户、有复杂权限系统、涉及高并发场景的商业项目那AI能帮的忙就很有限了。它比较拉胯的方向包括复杂的动画交互、深度的性能调优、跨端行为差异大的业务逻辑。AI能生成看起来正确的代码但离生产级还有距离。你要是把这些代码直接上线可能等着你的就是体感卡顿和线上事故。5.3 从这次记录里提炼的通用工作流现在每当我有一个想试试的产品点子我都会走一遍这套流程在文档里用大白话写清楚“这个产品要解决什么问题”不写技术方案。把文档发给AI让它提出技术选型和文件结构。让AI生成骨架代码并直接编译确认项目能跑通。逐个页面做交互和视觉优化每页一个对话窗口。本地功能做完后在开发者工具里反复编译和清理报错。最后才是真机预览并重点检查安全区、兼容性和异常提示。这套流程已经把我要做的项目从“一个月才能上线”压缩到“一个周末出Demo”。我觉得对于那些经常有想法但被实现成本挡在门外的人来说这真的是一个特别好的时代。你不一定需要成为一个资深程序员才能做出一款像样的产品你只需要懂逻辑、有审美、能说清楚需求剩下的都交给AI跑腿。6. 最后再说点实在的如果你读完这篇也想试试我建议从明天就开始不用等一个所谓的完美时机。找个周末选一个你自己真的会用到的小工具打开AI助手把第一句话发过去“请帮我创建一个极简记录小程序。”就这么简单。我这次做完之后最大的改变不是掌握了多少新框架用法而是养成了“把每个灵感快速做成原型”的习惯。以前我会说“这个想法不错但要做出来太累了”现在我会说“先让AI写个一版反正半小时能搞定”。哪怕最后这个版本不会上线它也会让我对“做产品”这件事保持持续的信心。最后分享一个特别有价值的个人经验AI写代码的最高境界不是让它帮你写而是让它陪你讨论。闲聊时的灵光一现、代码审查时的叫板质疑、技术方案上的讨价还价这些才是最值得你投入时间的部分。技术永远在迭代但那种能跟工具深度协作的感觉一旦你体验过就很难再回去了。
