最近社区里冒出个高频词“vibe coding”意思是“靠感觉编程”——你不用一板一眼抠语法而是用大白话不断跟AI描述想法、反馈体验、调整方向让AI写代码你主要管节奏和决策。我给自己定了个小目标用AI“vibe”出一个能用的习惯打卡小程序从零开始不查传统教程、不当“翻译官”全程只描述需求。结果当天晚上就跑通了第一个能用的版本后面又花两三天打磨成了给家人天天在用的工具。这个过程让我重新想了想“编程到底难在哪”。以前写个小程序最劝退的不是业务逻辑而是“万事开头难”——环境配半天、框架不懂、各种规范记不住。但换了一种互动方式之后我发现想法的实现链路被大大缩短了。这篇文章就记录一下我的完整操作过程、遇到的各种问题以及一些不那么“正确”但很实用的心得给同样想用AI做小工具的朋友一个参考。1. 为什么我想用AI“vibe”一个小程序1.1 vibe coding到底是什么适合谁玩vibe coding这个概念简单说就是“你提供想法和感觉AI提供实现”。比如你想要一个“绿色调的卡片样式”你不需要记得绿色色值也不需要知道圆角在代码里叫border-radius你只要说“做成清爽的绿色卡片圆润一点”AI会帮你补全具体实现。这个工作方式特别像带一个执行能力很强但经验不足的实习生你把需求和感受讲清楚对方给你一版结果你再反馈“这里太挤了”“那里颜色太深了”它马上去改。但要说清楚的是vibe coding不代表完全不需要基础。我自己有一些编程基础能读懂代码大概在干什么会看报错信息这让我在AI“犯糊涂”的时候能及时叫停。如果完全没碰过代码也不是不能玩但至少要花半小时了解几个基本概念文件是什么、函数是什么、报错日志怎么看。否则AI给你一个“运行不了”的版本你都不知道该把哪句话复制回去问它。1.2 为什么是小程序而不是App选小程序而不是App原因很实际。第一是分发成本低做完之后分享一个码就能用不用上架应用商店走审核第二是跨端体验统一不用同时适配安卓和iOS第三是对个人开发者来说小程序平台给了很多现成能力云数据库、用户登录、消息推送都有现成接口省去自己搭服务器的麻烦。当然还有一个更重要的原因小程序这个技术形态本身就很适合AI生成。它的页面结构是模板标签加逻辑脚本分离的模式组件和样式命名比较规范数据绑定方式也是固定的。这意味着AI见过的代码样本多、规律强生成出来的东西大概率能跑通。相比之下一些冷门框架AI就很容易一本正经地编造不存在的API。1.3 先给需求划个边界别让AI自由发挥很多人刚开始玩AI编程最容易犯的错是一口气把所有想法都倒给AI“我要做一个打卡小程序要有日历、统计、排行榜、打卡提醒、分享海报、主题换肤……”AI确实能给你生成长长的代码但大概率是个缝合怪跑起来各种报错你也听不懂它解释。我这次一开始就想清楚了功能边界也做了取舍需求类型具体内容状态核心功能添加习惯、每天打卡、连续天数、本月日历视图必须做周边功能打卡记录统计周/月、数据导入导出选做明确放弃排行榜、分享海报、自定义主题、多设备云同步砍掉这个取舍非常关键。砍掉云同步意味着数据只用本地缓存就够了不需要搞账号系统和网络请求砍掉排行榜意味着不需要后端和多人数据管理。整个项目的复杂度和AI需要掌握的信息量一下子降下来了所以它生成的东西才够稳。2. 工具与流程选择这套配置是我反复试出来的2.1 用到的AI工具不止一个角色要分清楚我这次实际用到了两个AI工具角色完全不同。一个负责“写代码”我把需求丢给它它返回完整的小程序项目结构和主要代码另一个负责“答疑和debug”当遇到报错或者看不懂的代码时我会把报错信息原样贴给它让它解释问题出在哪、怎么改。为什么要拆开用因为“从需求生成代码”和“对着报错修代码”这两个场景对上下文的要求不一样。前者需要AI记住你整体的产品设想后者则需要它聚焦在某一个具体错误上。如果混在一个对话里用AI很容易被前面的长篇需求带偏给出的修复方案可能把别的功能改坏了。2.2 三个核心提示词模板可以直接拿走用AI“vibe”小程序提示词不需要多花哨但要把关键信息说清楚。我常用的提示词结构是三层第一层是总目标“我想做一个习惯打卡小程序用户能添加多个习惯每天给每个习惯打卡可以查看连续打卡天数和本月打卡日历。数据用本地缓存就行不用云同步。用小程序原生写法给我一个能直接运行的初始版本。”第二层是单项需求“把打卡按钮改成圆形图标点击后变成实心对勾颜色用绿色打卡后数字跳一下要有一个动画反馈。”第三层是bug修复“我运行的时候报错了提示xxx方法未定义页面打不开。这是我的源码文件帮我看看是哪里少定义了。”这三层对应的其实是产品经理、交互设计师、测试工程师三种角色的话术。你不需要什么“魔法提示词”只要做到一点每次跟AI说的话都像在跟一个只听得懂人话但不懂你脑子里画面的同事沟通那就够了。2.3 为什么“一个功能一个功能地喂”效果最好第一次尝试时我把所有功能一次性扔给AI结果它生成了一个文件特别长、但逻辑混乱的版本。后来我改成“一次只提一个核心功能”效果立刻不一样了。原因很简单AI的生成质量高度依赖于它对当前任务上下文的理解。你一次只让它解决一个问题它的注意力是集中的你让它一口气解决十个问题它要么把代码搞得很复杂要么就会漏掉其中一两个需求。我这次的实际顺序是先把页面框架跑通再加打卡功能再加连续天数计算最后才做日历视图。每一步都建立在前面已经验证可以运行的基础上。一旦某一步出问题问题范围也被限制得很小排查起来非常容易。这种做法看着慢实际是最快的。3. 完整实操过程从一句话到真正能用的小程序3.1 第一阶段用一段需求描述“逼”出第一个能跑的版本我第一句发过去的话是这样写的“我要做一个习惯打卡小程序。用户进入后能看到一个习惯列表可以添加习惯每天点击习惯旁边的打卡按钮就算完成。完成后按钮变成绿色对勾。习惯数据保存在本地缓存里不用登录。页面尽量简洁先做出一个能正常打开、能添加习惯、能打卡的版本。”听上去没啥技术含量但这句话已经把平台类型小程序、核心流程列表-添加-打卡、存储方式本地缓存、交互反馈绿色对勾都定死了。AI很快返回了一个项目结构清单和一个可以打开的版本包含三个页面相关的文件、一个数据缓存工具文件、一个样式文件。第一次打开时其实并不顺利界面能渲染但添加习惯的输入框弹不出来。我把代码翻了一下发现AI把“弹窗组件”的触发条件写成了页面加载时自动执行而实际应该绑定在按钮的点击事件上。这个是小问题但给了我一个重要提醒“直接用AI生成代码第一次能跑通常指的是能渲染出界面不代表所有交互都正确你得逐个按钮点过去测一遍。”3.2 第二阶段连续打卡天数这个逻辑是对话中最烧脑的一关跑通基本打卡后我加了第二个核心需求“帮我计算每个习惯的连续打卡天数。规则是如果今天已打卡从今天往前数如果今天还没打卡从昨天往前数。中间断了一天就算连续中断。”这一段描述里藏了很重要的前提什么是“连续”。很多小程序第一次做这个功能都会踩坑因为“连续打卡”至少有三种定义。一种是严格按照自然日今天没打就断开一种是给一次宽限今天忘打了但昨天打了也算连续还有一种是允许补卡。我明确选了第一种最严格的规则主要是逻辑简单AI理解起来也不容易跑偏。AI生成的计算函数大概是这样的function calcStreak(dates, habits) { let streak 0; const today formatDate(new Date()); let cursor today; // 若今天未打卡则从昨天开始算 if (!dates.includes(today)) { cursor getYesterday(today); } while (dates.includes(cursor)) { streak 1; cursor getYesterday(cursor); } return streak; }这里我需要稍微懂一点逻辑才能判断它算得对不对。让我自己凭空写这个函数可能要折腾好久但让我判断AI写的逻辑是否正确这件事容易多了。这就是vibe coding对有一点基础的人最友好的地方你不用自己写但你得能“验收”写出来的东西。后来我提了一个新需求“如果今天没打卡不要立刻显示0而是显示昨天为止的连续天数再加一行小字提示今天还没完成。”AI也很快改了逻辑还顺便加了一个“昨天连续天数”的变量用于展示。3.3 第三阶段把界面从“能跑”改成“想用”功能全跑通之后我最不满意的就是样子。字体大小不统一、卡片间距很挤、颜色灰扑扑的整体感觉像十年前的内部工具。这个阶段我全程用“感觉词”去修改“把卡片的圆角再大一点给打卡完成的按钮一个绿色背景数字显示用大号字加粗今天未打卡的卡片加一个浅灰色边框让用户一眼看出今天该打哪个。另外所有文字间距拉开一点别挤在一起。”AI会把这些描述翻译成具体的样式代码比如将圆角值从8改成16给未完成卡片加上边框颜色和描边宽度属性。中间有一个有意思的细节我想让打卡后的按钮有一个“弹性跳动”的动画但没有直接说“动画参数”只说“像弹起来一样反馈一下”。AI配合页面的动画能力做了一小段缩放动画效果超出我的预期。不过视觉这件事AI没法帮你做审美判断。我试过让它“变好看”但如果没有具体方向比如更大、更扁、更圆、更绿、更淡它只能给出一版最中庸的结果。所以你要是对界面有要求最好先有个参考印象再用大白话拆解成“是什么颜色偏浅/深、是什么形状偏圆/方、间距是偏大/小”AI才能接得住。3.4 第四阶段假数据测试与真机体验功能看着都正常了不代表真的可靠。我花了很长时间做“假数据测试”直接用本地缓存造了一组连续打卡、断卡、未打卡的数据分别看统计对不对。如果你不造假数据光是每天真实打卡一个连续几天的记录就要等好几天根本没法验证逻辑对不对。具体做法是直接在调试面板里跑一段脚本往缓存里写数据然后刷新页面看结果。这里有一个经验给AI提测试需求时不要只是说“帮我测一下”而要告诉它“我需要造一组数据连续打卡5天然后断一天再连续打卡2天计算出来的最近连续天数应该是2”。AI生成的数据样本越具体你越能一眼看出算得对不对。真机测试更是必不可少。在模拟器上一切正常一上真机就可能暴露问题。我遇到最典型的问题是字体在部分机型上偏小、输入框弹出后遮挡了按钮。这些在模拟器里基本复现不出来只能靠真机逐个检查。小程序提供了真机预览的入口把扫码的二维码转到手机上十分钟就能过一遍主要页面。4. 踩坑记录与排查技巧AI生成的代码不可能一次就对4.1 最常见的几类翻车现场用AI开发小程序的这阵子我整理了一下遇到过的典型问题很多都是共性的问题类型表现在哪常见原因应对方法组件名写错页面空白或组件不渲染AI用了其他框架的命名习惯把报错信息丢给AI让它修正命名生命周期函数位置不对数据没有在页面加载时取出来逻辑写在了不会自动执行的函数里让AI解释“这个函数什么时候被调用”事件绑定丢失点击按钮没有反应按钮上没有绑定处理函数检查模板里的声明和脚本里函数名是否一致缓存数据格式不统一有时读不到数据两次写入的数据结构不一致统一使用同样的存储键和结构API被写成了过期版本能运行但不建议大语言模型的信息更新有延迟查找平台官方文档核对这里面最有迷惑性的是最后一类。AI很擅长一本正经地把一个旧版本或根本不存在的API写得像真的你复制过去运行可能直接就报错或者能运行但特别别扭。我的经验是如果某个接口名看起来怪怪的搜索一下官方文档如果文档里没有这个名字十有八九是AI在瞎编不要跟它争辩直接说“换成平台文档里标准的用法”。4.2 我把debug三板斧练熟练了跟AI协作修bug我长期用三个固定动作。第一招把报错信息原样贴回去。小程序控制台里看到的报错提示往往比系统大白话有用得多里面会直接写明是哪个文件、哪一行、什么变量是空的。很多人习惯自己读源码去找其实把报错原样扔给AI它定位往往比人快。第二招让AI“解释这段代码在干什么”。有时候看起来好像没报错但功能就是不对。我会把相关代码整个贴给它加上一句“解释一下这里的执行流程特别是打卡按钮点击后数据是怎么读写的。”AI的解释通常能让我很快发现逻辑断层比如“点击后写入的是新数据但读取的时候用的是旧键名”这种问题光靠看代码很容易忽略。第三招也是最实用的一招构造一个最小复现场景。如果问题是“统计数字不对”我不会直接说“帮我改统计”而是说“我现在假设有三条打卡记录日期分别是几号到几号按现在的逻辑计算出来的连续天数是多少问题可能出在哪”。把范围缩到最小AI的准确率会明显提升。4.3 什么时候必须自己动手别指望AIvibe coding再舒服也有一些坚决不能偷懒的时刻。第一个是账号和密钥类配置每个开发者需要用自己平台账号申请相关ID等标识信息这是个人资料AI替代不了必须自己在控制台创建。第二个是数据结构相关的核心逻辑比如打卡日期存成“YYYY-MM-DD”还是时间戳这个决定会影响后面所有统计AI往往会根据你第一次需求随口选一个格式但你要想清楚哪种更适合后续扩展存日期字符串比较直观够用但如果以后要跨时区同步可能就要改成时间戳了。第三类是涉及安全和隐私的代码比如用户数据集合、支付相关内容。这些领域最好老老实实用官方文档推荐的写法不要完全信任AI生成的方案。这里我不是说AI一定会出错而是这种场景一旦出错成本很高不值得把主动权完全交出去。5. 一些记录和感想以及给想试的人几条实在建议5.1 我的真实投入产出记录一开始说用AI做小程序很快但“快”到底体现在哪我给你一个真实账本。从启动到能用其实只花了大概3个小时第一个小时生成骨架并跑通页面第二个小时加上打卡和连续天数逻辑第三个小时把样式和动画调了一遍。但后面两天我一直在打磨细节和测试又花了6到7个小时。所以准确地说AI帮我压缩的是“从0到60分”的时间至于“从60分到90分”该花的心思一分都少不了。这个分配非常有代表性。你可以把AI当成一个帮你快速摆脱空白稿的工具但它不会替你做产品决策不会替你做测试更不会替你做审美判断。你想把东西做得好用总有一段路只能靠自己走。5.2 这个体验改变了我对“编程”的认知很多人觉得编程难在写代码本身我这次真实的感受是代码反而是最简单的一部分。真正难的是把脑子里模糊的想法变成一件件具体可验收的东西“连续的打卡天数”到底怎么算界面是“清爽”还是“拥挤”今天没打卡的卡片要不要提醒这些问题比语法难多了。AI把写代码的门槛拉开之后更多人可以更早地体会到“设计产品”这个过程本身的乐趣。以前没有编程基础的人想做一个小工具脑海里的想法还没落地就被“我不会写代码”这件事劝退了。有了AI之后你甚至可以连项目结构都不用管只要把想法一层一层说清楚AI就能帮你逐步变成真的产品。这种“想法快速成形”的感觉是会上瘾的。5.3 这条路的边界在哪什么时候别用虽说vibe coding让人上瘾但我也踩到了它的边界。目前看这三个场景我会谨慎使用第一涉及复杂权限和大量业务状态的系统比如多人协作、角色管理这种项目光靠对话容易失控第二性能敏感型功能AI生成的代码在小数据量下没问题但要处理大量数据时性能明显不够你得自己做优化第三长期维护的项目AI生成的代码风格和结构不一定规范几个月后再看你会很难受因为它不会按你喜欢的方式写注释和分文件。还有一点要提醒别人能“vibe”出来不代表你也可以完全复刻。因为中间会出现很多需要判断的时刻——AI给了一个看似合理的方案但和实际需求不一样你要能识别出来并把它纠正回去。这些判断来自你对业务的真实理解AI给不了。5.4 想上手的话从这里开始如果你看完也想试试我的建议很简单找一个你平时想过但一直没动力做的小工具不要做太大能解决一个具体小问题就行然后给AI写一段包含三要素的需求——是什么、核心流程是什么、数据存哪里。AI给出结果后不要急着加功能先逐个按钮点一遍把能跑的基础版本稳住再一个功能一个功能地加。特别提醒一句存好你的对话记录。AI给出的代码版本经常是从上一个版本基础上来回改的如果你后来改坏了回退到你保存的上一个能跑的版本比让AI“重新改回去”要靠谱得多。我这次就是因为每个版本都存了一份才能在几次改乱之后快速恢复到能用的状态。最后再分享一个我自己摸索出来的小习惯每完成一个功能就让AI写一段很短的使用说明存进项目的备注文件里。这样过几天你再打开这个项目不用重新“vibe”一遍才能想起来当初是怎么设计的。这个习惯看着不起眼但等你的项目从“一次性玩具”变成“每天都要用”的工具之后你就会感谢自己当初多做了这一步。