Vibe打金计划(10)：终章，打到金了。

https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.milka 最终，喵卡上线了，做为“Vibe打金计划”的第一个产品，确确实实爆到了金币，还得到了一个光荣的“原创”标记。应用的结构和机制虽然其实很简单，但自我感觉还是相当不错的。 先来简单介绍一下这个应用本身的机制吧。 --- # 喵卡应用机制 ## 数据库 由于以前打算用MySQL后来又改掉了，所以现在用的是懒猫提供的minidb插件，minidb是一个很轻量级的文档式数据库，非常适合卡片这种简单的内容。 ### 主题（卡片包） 应用中最主要的维度就是主题，也可以称为卡片包，它包含了一组N张卡片。 除了标题和说明外，其实还预留有图片、排序编号等字段。 主题其实也可以单独设置风格，只是目前还没有做到。  ### 卡片/卡面 喵卡中应用了“卡面(card-face)”的概念，也就是说卡片的正面和背面其实是一样的数据结构，都包含一个标题和一个说明。 每面都是一条单独记录，也就是说未来有可能一张卡面可以用在不同的卡或主题中，但是目前还就只是一一对应的关系。 两面对应的样式是有所不同的，正面更注重标题，背景虽然标题也是主体，但说明部分比正面的视觉权重要稍高一点，甚至可以溢出滚动，也就是说可以放进去不少内容。 ### 关联数据 卡片的正面和背面由关联数据关联到主题，关联数据才是决定哪个卡面与另一个卡面相对应，同时属于哪个主题的。 理论上，有可能打乱卡面和卡背做一些小游戏，或者做成“多维”的卡片，即不只是正反两面，但这需要以后去扩展了。 ## 界面 主界面去掉了一切原本计划的管理功能，比如排序删除修改等。只留下添加主题和卡片的表单。所有的内容管理，包括未来的卡片修改排序或主题的单独编辑，都会放到设置页面。 帮助界面也从原来的计划中去掉了，改成初始数据中的一个卡片包。总之对于主界面，最主要的就是尽可能减少干扰。  列表页面很适合随意浏览，你看到哪个不熟悉的内容，先想一想，然后点开看答案，或许就会印象越来越深刻了。  幻灯片的界面将来会改成计时自动翻转的方式，可以不用按键盘坐在那里就能记忆。 ## 应用 背单词是记忆闪卡的最常见的应用，但实际上这些有正反两面的卡片还有很多其他的作用，比如百科知识、历史、文学诗歌，各类知识都可以用这种形式表现。   甚至谜语，台词，冷笑话，脑筋急转弯，只要你能想到的关系到两值数据的需要记忆或隐藏一半的信息，都可以找到合适的闪卡玩法。 ## 内容 在开发这一类的应用中，其实往往被忽略的一个问题是：内容从哪里来。虽然第一版的应用是主要靠用户自己创建和输入，但毕竟太麻烦了。 所以后续的升级中会加入各种导入或批量输入的方法，也包括官方的数据（卡包），争取尽可能让大家可以方便得到可用的内容，如果能够互相分享当然就更好了。  我甚至在做一个AI提示模板，让用户可以通过提示词要求AI一次性生成大量卡片内容，导入到喵卡里就可以使用。   （截至发稿前，其实上面有的界面和功能已经做好了，估计很快就能更新上去。） ## 副产品 对了，想到之前提过MySQL、Minidb、File-pickers做的demo还没有完成，算是跳票了吧，我想再改改把它改成真正有意义的工具再说。另外还有Refly画板和提示词库等，也都等过段时间再分享吧。 另外的副产品就是由此生成的内容库了，其实我自己也在用它学习词汇，怎么说呢？自己用自己的产品还是挺习惯，学得不累：P --- # 开发历程 整个开发历程其实在12篇《Vibe打金计划》中都提过了，但是在这里还是要吐一下槽。 ### 什么“说一句话剩下的AI就帮你做好了”真的是夸张的说法。 的确有的简单功能可以得到这样的惊喜，但是如果你对产品的逻辑和技术架构完全没有概念，当AI犯健忘或糊涂的时候就完蛋了。 ## 需要不断调教的AI 除了提要求，不断的反馈信息、反复抽卡，你还需要随时调整你的思路找到最好的方法。 有时要求它给你全部的代码，有时只要一小段，有时甚至只让它给你一个思路就好。 有一次发现不知什么时候，AI把原本信息提示的功能替换成简单的console.log了，这个功能偏偏还是在我一直不想再和它同步的主应用代码里。 我是实在不想让它再乱动主应用代码了，于是我这么说: > // 显示通知 showNotification(message, type = "info") { console.log(`${type.toUpperCase()}: ${message}`); // 这里可以实现更复杂的通知系统 } >为app.js里这个函数写一个很简单的提示框，在页面上提示信息，3秒钟后自动消失。 >尽量只在这个方法之内实现功能，不要改动主程序代码太多 于是它给我最简单的修改方式，我只在这个方法里修改并加了几行样式表就解决了问题。 ## 要求单模块功能 必要的时候，就只能要求它做独立的功能，把新的功能放在新的页面上，这样才不致于改坏文件，毕竟代码一到上千行，AI就会开始有点找不到北了。 比如在开发批量输入的页面时，我是这样对AI说的： >现在所有功能已经正常，应用已经上线。请写一个新的批量卡片数据生成的功能： >* 从一个固定格式的csv文件批量导入数据生成卡片数据 >* 可以上传文件或在文本框中输入这个数据，但即使是上传文件，也可以在文本框中预览和修改。 > …… > …… > …… >* 可以用单独的页面容器设计，不需要与app.js使用同样的页头和导航中，返回链接回到主应用。 > >请完全在一个新的文件中实现这个功能，只从原来内容引入必要的方法，只在设置页面增加一个到这个页面的入口。 由于Refly有知识库的关系，其实尽管是从头开发新页面，AI还是可以找到相关的知识，而且不受其他干扰，可以更有效地拿到正确结果。 ## 内容库的生成方法 对于内容（卡片包）的填充，我是在Refly上开了一个新的聊天线程。 我先把批量添加时生成的csv格式喂给它，然后让它“手工”整理第一个列表。 在确认了格式没什么问题之后，我又让它先写一段提示： >撰写一个提示词模板，包含【主题】和【详细要求】两个用户可以自行修改的字段。然后稍微详细些说明这种数据格式的特点和要求，包括正反面通常的意义（正面用来提醒和回忆，背面是要反转才会揭示的答案），也包括对逗号（比如半角逗号的字段要用半角引号括起来）和回行的处理。同时对字数提一定的要求，不要太长，除非用户在【详细要求】中有说明。  按Claude的一贯风格，它给我写了一个巨长的Markdown提示语，在试过多个主题效果可以之后，我把这个提示词也放进了应用。  或许有一天，等AI不要钱了，或者等算力舱普及了（哪个更近一点？），我们就可以只说一个主题，然后让AI自动生成卡片库了。 ## 还有一条宝贵的经验是：Gemini可以兜底！ 虽然Gemini也有它爱钻牛角尖的坏毛病，但是实测发现，对于Claude Sonnet 4犯的迷糊毛病，Gemini 2.5 Preview可以完美地擦干净它的屁股！ 这条我就说这么一句，信不信由你，不信可以自己试试：） --- # 喵卡升级计划 ## 更好的体验 其实我最终目标是做成一款炫酷的应用，所以现在的极简风格应该只是一个开始阶段。 在未来，卡片的风格和动效只会越来越好，主题也会有更多的背景、配色甚至装饰可选。 语音和链接也是我想做的功能，不过语言的物料还是个麻烦，不知道TTS引擎到底发展成什么样了，能否在懒猫上跑得动。 ## 分享与共享 其实这些记忆信息，有时候很适合用来分享。 之前小红书上有段时间不是流行背单词或学英语么？所以我计划再开发一个生成分享资源的形式，比如把卡片导出成漂亮的单独页面或列表，你随时可以把你的知识点生成一张图片分享到社交媒体去。 至于大家的共享，就只能期望有真正使用的用户之后了，或许会搞个卡包共享的网站之类，这些都是后话。 ## 更多使用场景 游戏化的测试场景一直是我想做的功能，所以在幻灯片优化好之后，我会为其加入计时计分或问答等玩法。 打印也是另一个计划中的功能，虽然纸质媒体已经不多受待见了吧，但如果能快速打印出实体的记忆闪卡，让小朋友能远离手机一会儿，大概也算是这个应用的一个功德？ --- # 相关文章 如果你对《Vibe打金计划》全系列有兴趣，以及想了解这个应用从构思到诞生的全过程，补课链接在这里： * [《Vibe打金计划之序章: 系统提示词》](https://lazycat.cloud/playground/guideline/745) * [《Vibe打金计划(1)：小白学打包应用》](https://lazycat.cloud/playground/guideline/753) * [《Vibe打金计划(2)：数据库功能测试与演示》](https://lazycat.cloud/playground/guideline/758) * [《Vibe打金计划(3)：一二三，分步走》](https://lazycat.cloud/playground/guideline/806) * [《Vibe打金计划(4)：新手调试一路通》](https://lazycat.cloud/playground/guideline/814) * [《Vibe打金计划(5)：懒猫minidb插件》](https://lazycat.cloud/playground/guideline/822) * [《Vibe打金计划(6)：怎样更有效地使唤AI》](https://lazycat.cloud/playground/guideline/843) * [《Vibe打金计划(7)：lzc-file-pickers插件》](https://lazycat.cloud/playground/guideline/844) * [《Vibe打金计划(8)：24小时开发原创应用?!》](https://lazycat.cloud/playground/guideline/869) * [《Vibe打金计划(9)：可爱又可恨的AI酱》](https://lazycat.cloud/playground/guideline/874) * [《Vibe打金计划(10)：终章，打到金了。》（本篇）](#) - * [《Vibe打金计划 番外篇:歪路子入门》](https://lazycat.cloud/playground/guideline/754) * [《边画边体验：用SVG-Edit绘制应用图标》](https://lazycat.cloud/playground/guideline/818) 另外在本系列几乎全程使用了Refly应用，同时表示感谢： https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly 后续的应用开发我会写单独攻略，还请到[喵爸联萌](https://lazycat.cloud/playground/user-profile/319/dynamic)的个人信息页中点一下“关注”🫶。

7小时vibe+5小时手搓：一个应用的开发全过程

之前的《Vibe打金计划》中，喵卡的开发大约总计时间24小时（跨度一周）。 https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.milka 这次打算挑战一次更快速的Vibe编程。 虽然应用的规模和难度不一样会影响开发时间，AI的“听话程度”也会造成很大的误差。但我还是打算试一下，并尽可能插进去一些新课题的研究，争取让需求难度和开发量差不太多。 本次依然是我们的老朋友Refly。 https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly # 首先还是整理需求。 这个应用将是一个给图片加画框和装饰的小应用，它的核心有点类似CSS中的border-image，以九宫格的形式将边框适合图片。但是border-image无法直接绘制到canvas上，所以导出图片有些麻烦。 在交互手段和界面上，它要比喵卡少一些数据处理和管理功能，但是要处理素材图片上传和展示，所以还是有点难度。 同时我打算让它关联到图片文件格式，使用户从网盘可以直接打开它。 **而且，其实这个需求我在两周前开始开发喵卡之前就已经计划好了，当时一口气准备了四五个项目的计划，打算一个个的开发出来。** 我依然提供了一个详细的需求文档，甚至画了一张界面示意图，但这些时间不打算计入开发时间里。  （上图在最终上线时有少量缩水，只能下次更新增加了。） 我把文档和图一起提交给AI,但依然先不让它开始编码： >请认真阅读和分析这个需求文档，将其重新整理成一份逻辑更通顺，表达更加明确的需求文档。不需要编码，我将在检查表述正确之后才要求编码。  这次开始时我打算用Gemini 2.5 Preview，它整理的需求文档质量看上去也还好。  # 开始计时 00h:00m ## 第一天的晚上19:30 正式编码 首先我让它生成了简化一些的目录结构，因为模块化会引起更多的问题。  它自动写的配置文件，看上去好像还行但我仍然不打算用它  打包文件我按照我的计划放在app文件夹中。  这一次我打算从前端开始开发，因为上次的CSS太屎山了。而且这个应用的主要功能还是在前端部分实现的。很快Gemini就给了我一个大约的界面预览。  反复调试了一会，由于border-image其实不是什么复杂的问题，所以初始的架构和边框部分大约在15分钟以内就实现了。  # 20:45 边框基本实现 00h:15m 然后我打算把生成图片的部分做完，这样来说核心的功能实现能跑通，应该就不会有太大的变数了。 在这里gemini给我推荐了一个第三方库html2canvas。 但是实际上，html2canvas并不支持border-image，复制出来的图片是没有边框的。  所以算是走了个弯路，但好在我测试的早，所以浪费的时间不多。 大约半小时后，边框可以成功复制到剪贴板了。 ## 21:12 复制到剪贴板实现但存bug 但是图片的比例和图片的外缩有一些问题。   因为我打算制作通用于不规则卡通边框的功能，所以每个边宽度都会不同，边框“盖住”图片的程度也会不同。 于是要反复与AI确认和解释为什么要有不同的边宽，不同的大小，以及图片为什么要有外扩。 但是Gemini的理解能力还是很强的，只要你和它解释清楚逻辑，运算定位什么的就是它的强项了。比起自己要去开发每边的缩放比例之类可是简单多了。 ## 21:20 边框bug修复但层次错误 总计2小时 折腾了2小时左右，最核心的功能基本跑通了，生成的图片基本达到了我的预期：  # 休息 总计时02h:00m 由于要哄娃睡觉，此处休息了几个小时 ## 处理比例问题 之前的边框达到了预期，但显示比例还有问题，由于图片的宽高比和分辨率不同，边框要大小适合也要考虑一个比例，甚至窗口缩放的比例也同样要计算进去！    于是又反复折腾了一个小时，因为AI只是你让它做什么它就做什么，所以你的工作状态也会影响到它。这里我明显是有些累了，已经半夜两点多，好在比例的问题也解决了，所以第二天再继续。 # 核心功能完成 总计时 03h:10m ## 人算不如天算 第二天的Gemini情况比较糟糕，具体是当代码到了一定的体量，它就开始不断的省略，给我的代码很碎片，而且前后记忆不太一致。 给我的感觉是，好像AI也有“心流”一样，当心流被打算，可能很难恢复到之前的状态。 于是没办法，好在文件还不多，我把所有文件交给Claude，第二天的工作由claude接受完成。 由于从之前喵卡中得到了经验，聊天记忆太久了其实不是什么好事，于是我新开了一个聊天线程，放弃了和Gemini的纠结记录，只是把之前的项目文件重新导入给Claude让它去先理解： >请理解附件中的文件及代码内容，并在此基础上修改。 代码中已经实现了边框部分的功能，不要改动现有结构及功能。 现在我希望开始增加“装饰”的功能，  Claude在这一方面还不错，很快地理解了问题，并给我提供了它修改的代码部分。加上由于我在系统提示词中设置了严格的要求，所以原有Gemini开发的功能除了稍有走样外，基本得到了保留。  添加装饰的部分基本实现，边框也得到了保留。  但是现在的问题是，Claude并不理解之前纠结过的屏幕缩放问题，而且Dom元素和canvas元素不对齐的情况越来越明显了。 如果说Claude有些东西还不擅长，那么它擅长的是什么呢？要我说，它擅长的是“重构代码”，这里要加个黑脸🌚 即使是平时正常的小改动，Claude都会动不动把代码给重构了，优化一些只有它自己会注意到的优化问题。我不知道是不是跟人类程序员学的，但这个毛病其实很讨厌。 即使前面说的开发挺顺利，其实也已经完全重构过两次代码了！好在它的重构也比较快…… ## 但是这一次，我打算主动让它完全重构代码。 由于之前对边框部分实现得也相当好，所以我打算趁它还有记忆，把整个应用的机制改为全canvas的模式，即每一步都直接在 canvas上绘制，这样就避免了无法所见即所得的问题。 没想到啊，这家伙对我说：这个方法很好，而且是主流解决方式，巴拉巴拉…… 我就一头黑线，你咋不早说？ 所以这里有一个心得，有一些优化的机制，如果你自己不知道或不提出来，AI不会建议你用更好的模式去实现，它只会死板的按你的需求去做。 至重构且进行一番调式完成，又过了两个多小时。 # 总计时间 05h:45m  在重构完成后重新实现装饰功能，以及调试恢复边框功能，又增加了25分钟。 但所幸的是这一次非常顺利，整个流程完美跑通了，实际生成的图片也完全符合要求。 ## 终于，可以开始后端了。 这个应用的后端比较简单，因为主要是记录上传历史、保存以前生成的图片，以及素材管理。 我初期打算不用数据库，直接列举文件夹中的文件就好了。 所以，其实AI在一两个回合的问题里就给我写完了所有的代码！ # 总计约 07h:00m 可惜好景不长，在跨时两天总工作小时为7小时左右的时候，AI的记忆力终于又崩了。 之前提到的Claude爱重构代码的毛病又犯了，每次给我的解决方案都是完全不同的，会把之前的功能用新的方法写出来，然后还会漏掉功能或改掉以前正常的功能。 下图是我废弃的问答，在Refly中如果你觉得AI开始频繁出错答非所问，可以轻松地废弃掉这些线程，从较早之前的线程开始。  不过这一次重新开始了三四次支线后，结果还不理想，而且投入的时间和得到的有效回答相比，有效的效率越来越底，所以我打算还是放弃。 懂得放弃也是一种重要技术。 ## 转手动 好在是，项目的基本功能已经差不多了，我想了下还是不跟他磨了。刚好我也需要了解一下这个机制学习一点写法，于是决定开始自己读代码修改。 由于所剩的修改大部分是CSS，所以其实还好。个别的JS和后端文件，就要一点点的查找整个功能链路去判断。 这个过程花了我大约5个小时。 虽然其实很久了，但我认为如果AI不崩，大概再有个一两个小时就能够搞定整个应用了。 这个Refly画板因为需求相对简单，而且没有包含后端的调试，所以比之前的喵卡画板要小得多,真实有效的回答其实只发生在绿色部分里。  如果是代码大神，编这样一个小应用估计用不了太久，可能总共三五个小时也就搞定，说不定更少。 但是我用的时间里也还包含初始素材的处理和素材配置文件的制作、界面的交互梳理和美化，这7+5个小时算是由需求出发，从零到一的完整全栈开发过程。 自我感觉还是不错的。