最近社区里冒出个高频词“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很擅长一本正经地把一个旧版本或根本不存在的API写得像真的，你复制过去运行，可能直接就报错，或者能运行但特别别扭。我的经验是：如果某个接口名看起来怪怪的，搜索一下官方文档；如果文档里没有这个名字，十有八九是AI在瞎编，不要跟它争辩，直接说“换成平台文档里标准的用法”。

4.2 我把debug三板斧练熟练了

跟AI协作修bug，我长期用三个固定动作。

第一招，把报错信息原样贴回去。小程序控制台里看到的报错提示往往比系统大白话有用得多，里面会直接写明是哪个文件、哪一行、什么变量是空的。很多人习惯自己读源码去找，其实把报错原样扔给AI，它定位往往比人快。

第二招，让AI“解释这段代码在干什么”。有时候看起来好像没报错，但功能就是不对。我会把相关代码整个贴给它，加上一句：“解释一下这里的执行流程，特别是打卡按钮点击后数据是怎么读写的。”AI的解释通常能让我很快发现逻辑断层，比如“点击后写入的是新数据，但读取的时候用的是旧键名”，这种问题光靠看代码很容易忽略。

第三招，也是最实用的一招：构造一个最小复现场景。如果问题是“统计数字不对”，我不会直接说“帮我改统计”，而是说“我现在假设有三条打卡记录，日期分别是几号到几号，按现在的逻辑，计算出来的连续天数是多少，问题可能出在哪”。把范围缩到最小，AI的准确率会明显提升。

4.3 什么时候必须自己动手，别指望AI

vibe 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”一遍才能想起来当初是怎么设计的。这个习惯看着不起眼，但等你的项目从“一次性玩具”变成“每天都要用”的工具之后，你就会感谢自己当初多做了这一步。