Vibe打金计划（1）： 小白学打包应用

### 如果你懂技术，没有什么必要读这篇文章。 请直接前往：[懒猫微服文集推荐](https://developer.lazycat.cloud/wangjishanren-lazycat-developer-startup.html) 阅读 @忘机山人 大佬的专业文章。 其中的这两篇： * [懒猫微服开发篇（零）：上架应用需要哪些知识](https://mp.weixin.qq.com/s?__biz=MzI3NTY4MjcxNg==&mid=2247486919&idx=1&sn=8c7c8d10c02574346eec147e526cede2&chksm=eb004934dc77c02216bb8047e665ff716ad7de0f6fd1e28243a46f4b83d5e9cdf1eafbf82144#rd) * [懒猫微服开发篇（一）：懒猫微服全栈上架指南，一步打包，一键发布](https://mp.weixin.qq.com/s?__biz=MzI3NTY4MjcxNg==&mid=2247487023&idx=1&sn=2b40ee494b6e1ffe09473df5362eb21b&chksm=eb004adcdc77c3ca8204cdc4f9cff5854c756de6c33468dd5f26c35d735dcb57e6de0c381908#rd) 已经能很好地对打包应用进行指导。 --- 而本文的内容，主要是从“技术小白”或我这样的外行纯“Vibe Coder"角度出发的。 因为在开发大神们（包括官方的大神们）的眼中，技术上有太多的“常识”。很多技术内容对于“他们”可能就是一个关键词而已，而对于“我们”这些外行却是要去翻查尝试和学习很久的，甚至AI都解释不清。再加上经常在其他的常识上踩坑，“我们”的前进之路可能会比“他们”要艰难得多。 而官方文档，为了简洁全面，总是把尽可能多的可能性、极端情况与各种高端应用都写进去，对于基础知识比较少的“我们”来说，会显得很复杂，而且经常会被误导，以为一定要用某种高端的方式才能实现某些其实很基础的功能。 本文也可以当作是小白的我对于忘大佬攻略或官方文档的**学习笔记**，我也会补充一些我做为小白踩到的坑。 另外，我会尝试一边写这篇攻略，一边在AI的协助下整理进一步的提示词和资料，以达到让AI可以指导我们打包的目的，在此依然会用到Refly。 https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly 另外会用到这个神器： https://appstore.lazycat.cloud/#/shop/detail/in.zhaoj.devaihelper --- # 基础信息 首先我向神器开发者文档助手询问了如下问题： >我想了解懒猫应用的打包机制和应用包的执行流程 得到的答复是： >基于提供的资料，懒猫应用的打包机制和应用包执行流程如下所述，每个陈述均严格引用资料原文： 懒猫应用的打包机制涉及准备特定文件：包括 lzc-build.yml（构建脚本）、lzc-manifest.yml（应用元信息配置）和图标文件（如 icon.png），这些文件需放置在同一目录下；随后使用 lzc-cli project build 命令构建输出 .lpk 安装包文件[3]。 资源文件（如模型文件）可打包到镜像或 .lpk 中：若资源文件较小（<200M），可直接打包到 .lpk 中，应用运行时通过只读目录 /lzcapp/pkg/content 访问；但资源文件不能放在 /lzcapp/ 目录下，因该目录在运行时会被覆盖[1]。 在 devshell 开发模式下，默认不会打包 lzc-build.yml 中指定的 contentdir 内容；如需打包，需使用 lzc-cli project devshell --contentdir 命令显式启用[1]。 应用包安装流程：通过 lzc-cli app install <lpk文件> 命令安装 .lpk 包；安装后，包内容会被解压到微服系统的 /data/system/pkgm/apps/$appid 目录下[2]。 执行前渲染机制：安装后，在应用启动前，系统根据运行时信息（如用户ID）动态渲染 manifest.yml 文件：使用 Go 的 text/template 模板引擎，结合内置参数（如用户参数、系统域名等），将渲染结果输出到 /data/system/pkgm/run/appid 目录；渲染支持函数如 stable_secret 生成稳定密码[2]。 最终运行流程：渲染后的 manifest.yml 被转换为 Docker 规范，系统据此启动并运行相关容器；重启或多实例场景下会重新渲染[2]。 由于神器的系统提示可能是要求严格引用资料，所以这些内容都是在开发者文档中可以找到的，必然是精确的内容。但是其中的渲染动态manifest部分，虽然看上去应该有用，但其实以我目前的水平还用不到，只属于“不明觉厉”的程度。 --- # AI分析 由于担心会干扰到AI的理解，于是我会只选用基础的部分喂给AI。 直接上画布：  提示语： >请仔细理解和分析附件中的文档和链接内容，总结一份关于懒猫微服应用的打包技术要点文档，要求准确细致，关键技术点必须使用原文本，只在逻辑顺序调整、阅读引导和分析解释时使用合适的语言能力 在我整理了许多关于打包知识点之后（官方文档节选、官方标准链接、攻略链接及节选、示例代码、我自己写的理解思路），我把它们统统喂给了AI，由Claude Sonnet 4和GPT4.1分别分析之后，得到了这样两篇文档： * [懒猫微服应用打包技术要点Claud版](https://refly.ai/share/doc/doc-nlfc76asbl4oa3v6cnrws12i) **注意：AI生成文档不建议做标准参考** * [懒猫微服应用打包技术要点GPT版](https://refly.ai/share/doc/doc-nlfc76asbl4oa3v6cnrws12i) **注意：AI生成文档不建议做标准参考** 大致浏览下来，虽然结构上还不尽人意，但是由于我在提示中要求严格遵照原文，所以应该不会出什么大的错误。(如果某些技术大佬或官方大佬有空，不妨帮忙校正一下，但从结构和内容来说价值似乎不大。) --- # 验证 我把这个生成的综合文档，又喂给Refly中另一个画板，这个画板中我搭建了一个懒猫应用，具体的细节我会在下一章中详细说明。在这里，我只是希望AI帮我写打包文件和启动脚本，用以作为对上面文档的验证。 提示词 >请根据附件中的打包技术要点，帮我准备打包这个应用的相关配置文件以及启动脚本  得到了这样两个指导文档： * [打包指导Claude版](https://refly.ai/share/doc/doc-oiqg93zt2cm3vvwmid0l25mn) **注意：AI生成文档不建议做标准参考** * [打包指导GPT版](https://refly.ai/share/doc/doc-iy3lvkqal4ra92nvc5ohqp1f) **注意：AI生成文档不建议做标准参考** 看下来，还是理解错误了不少，比如路由并没有写好，比如依赖里装了php（我之前的喂上的项目是node的）。 真正的打包文件可能需要细调，或直接使用前文的神器：开发者文档AI助手 但是，看上去AI似乎对于打包流程已经能够有正确的理解了，如果我在下一个项目的开发前就导入这些资料，也有可能会得到更好一些的结果。 任务完成度，可以说70%吧，至少对我这样的小白来说还是不错。 孔子曰：遇事不决不能全靠AI。在这个过程中我自己也学到了很多，所以这项工作还是有价值的。 --- # 我理解的整个流程 我在前文给AI喂料的时候写的这个，全是基于我的摸索和理解，不一定正确，还往各位一定不要相信我。 ## 1.功能开发 选用适合的技术栈，后端主推Node.js / PHP，前端主推React.js / Vue.js。(这句是写给AI看的，是我的技术偏好) 其他技术在必要时也都可以使用，也可以直接使用Docker镜像。 ## 2.Devshell调试 （略） ## 3.编写lzc-build.yml lzc-build.yml 定义打包配置参数。 在打包前会自动运行buildscript所指定的脚本，可进行打包前的依赖安装，模板化构建，以及其他打包前需执行的文件处理等。 ## 4.编写lzc-manifest.yml lzc-manifest.yml 定义应用元信息配置。其中最重要的是application.route。 ## 5.使用lzc-cli打包 使用 lzc-cli project build 将项目打包到lpk包中 程序首先会运行buildscript中的脚本（可能是bash命令，也可能是.sh文件） 然后将文件打包进一个.lpk包 ## 6.安装到懒猫微服 使用lzc-cli app install将lpk安装到懒猫微服中 ## 7.运行应用 在懒猫微服客户端打开应用，系统会直接访问lzc-manifest.yml里设置的application.route中/所指定的路由。 如果是exec:格式的路由，比如: - /=exec:// {端口},{脚本} 系统会在运行指定的启动脚本后访问指定的端口，所以对于应用后端的初始化及启动命令可以放在这个脚本里。 其实在你的应用安装好后，它就自动开始运行了，所以安装依赖和初始化是在你点开图标之前就已经在做了，所以新安装的应用启动通常要稍久一点。 --- # 其他 最后抛开上面的流程，也抛开官方技术，说点我自己这个小白（白痴的白）走的弯路： 1.路由：我一开始完全没有理解路由机制，就从参考样例开始折腾，抱着搞网站的思路，非要搞一个前端和一个后端的感觉，但其实绝大多数项目并不需要前后端分离成两个路由。 2.启动脚本：我在devshell里尝试的node应用没问题了，打包应用时突然卡住了，要怎么搞npm run start啊？好像不会自动启动……后来才搞清楚一下要搞个run.sh做启动脚本（也可能有自启机制？），而且我把启动脚本放在某个文件夹中，结果总是说找不到，我也不知怎么搞的。后来就放根目录没毛病。 3.依赖：alpine实在是太干净了，在本地好容易在AI指导下搭的环境，devshell里也装了，结果应用启动时还要安装，这种就是前文大神们的常识，但在我原本的理解里其实有点奇怪的。 4.权限：我之前几个零散的小应用是在Mac里写的，所以没有什么感觉。近来因为换了Windows，又折腾不太会WSL，就直接在Powershell里打包。结果打包了应用不能运行，甚至官方的Helloworld我这里都试不成功。排查了一整天，才发现日志里明明写着启动脚本没有执行权限！问了AI，原来windows是没有linux的执行权限的，即使在WSL里做了chmod，回到windows打包一样不行。最后的方法是在我的旧Mac机里打包，一点问题没有！ 这些也不算什么坑，给大家看看我闹的笑话而已。 下一篇我打算直接Vibe出一个用于测试的懒猫应用来。

Vibe打金计划(6)：怎样更有效地使唤AI

### 俗话说：付出不一定有回报，但要回报一定得付出。 在AI时代，似乎付出和回报的比例不是那么稳定了，然而其实这个规则仍在继续。 有人拿AI当女朋友发泄情感，有人拿AI当百科，有人拿AI写小X文赚钱……同样是Token的消费，如果你指望从AI的工作中得到更好的回报，依然是要花大量的时间和金钱与AI进行磨合，锻炼自己的表达和指示能力，让AI为你做出更好的产出。 本文将主要讲我在使用AI期间体会到的一些经验，比如如何更有效地指导AI编码，如何避免AI产生的各种问题，以及怎样把你获取的信息教给AI让它也学会。 本文将同时包含关于：**AI辅助小白打包技能的更新** 最基础的小白打包技术我已经在 [《Vibe打金计划（1）： 小白学打包应用》](https://lazycat.cloud/playground/guideline/753) 写过了，而随着逐渐的学习和深入，我和AI都学到了新的知识，所以将在这里顺便补充一下。 如果你只是移植，可能完全用不到这些打包技巧，如果你也是像我打算原创应用，或许能在这里找到多少有点用的启发。 --- # 让AI做你没想到的事 这条是关于使用**upstreams**写启动脚本。 首先你会在官方文档看到在exec中路由放置启动脚本的方法如： ```yaml routes: - ... - /api/=exec://3000,./lzcapp/pkg/content/backend/run.sh ``` 这样懒猫就会在运行run.sh(文件名自定)后访问指定端口。 比如node.js的后台，在run.sh中的npm run start之类的服务和监听任务启动完成之前，向指定端口3000的访问会反复被拒绝再重试，而前端会一直显示赛伯猫头图标和“{应用名}启动中”的界面。 直到成功启动了监听服务，正式的界面才会显示出来。 除了这种简写的路由，其实还有一个语义上更明确的方式，就是写在upstreams中。 至于为什么一定要用upstreams而不用简单版exec路由，除了语义看上去更直观，还有我在之前一篇文章中已经提到过的，因为用Windows打包的话无法执行类似run.sh的启动脚本，所以目前只能把启动命令写到lzc-manifest.yml里application.upstreams下的backend_launch_command中。 我个人感觉还有一个好处是不用搞一个专门的run.sh在里面，虽然维护时在后台代码中多一个文件虽然也没啥不好，但毕竟是复杂一点点，感觉多少会破坏项目的独立性。 我把这个方式告知AI后，AI为我写了这样的启动脚本， ```yaml backend_launch_command: | echo "=== 懒猫文件选择器后端启动 ===" cd /lzcapp/pkg/content/backend echo "当前工作目录: $(pwd)" echo "=== 环境变量检查 ===" echo "LAZYCAT_BOX_NAME: $LAZYCAT_BOX_NAME" echo "LAZYCAT_BOX_DOMAIN: $LAZYCAT_BOX_DOMAIN" echo "LAZYCAT_APP_DOMAIN: $LAZYCAT_APP_DOMAIN" echo "LAZYCAT_APP_ID: $LAZYCAT_APP_ID" echo "=== 安装系统依赖 ===" apk update apk add nodejs npm curl echo "=== 启动应用 ===" node server.js ``` 还有一个更复杂的版本： ```yaml backend_launch_command: | echo "= 懒猫文件选择器后端启动 =" cd /lzcapp/pkg/content/backend echo "当前工作目录: $(pwd)" echo "= 环境变量验证 =" echo "LAZYCAT_BOX_NAME: ${LAZYCAT_BOX_NAME}" echo "LAZYCAT_BOX_DOMAIN: ${LAZYCAT_BOX_DOMAIN}" echo "LAZYCAT_APP_DOMAIN: ${LAZYCAT_APP_DOMAIN}" echo "LAZYCAT_APP_ID: ${LAZYCAT_APP_ID}" echo "= 网络连接测试 =" netstat -tlnp | grep :3000 || echo "端口3000未被占用" echo "= 安装依赖 =" apk update && apk add nodejs npm curl # npm install --production echo "= 启动应用 =" node server.js & SERVER_PID=$! echo "= 等待服务启动 =" sleep 5 echo "= 本地连接测试 =" curl -f http://127.0.0.1:3000/health || echo "本地健康检查失败" echo "= 保持服务运行 =" wait $SERVER_PID ``` 说实话，我之前写的也就是安装和运行那两三句，从来没想过在这里可以直接写后台调试的脚本，直接判断启动的进程有没有问题。 而告知了AI这里可以运行脚本之后，它立即就应用这个入口写了调试逻辑，这是我真没想到的。 --- # 不要因为问题小就不同步给AI 因为/lzcapp/pkg/content是只读的，所以我曾经有很久卡在安装依赖上，尤其是依赖包挺大的时候，总是想着初始化的时候再装方便点，折腾半天以后才发现行不通。 虽然这只是小白的我犯的一个很傻的错误，不是什么大事，但是要注意的是： ### AI一样理解不了！ 所以我在之前让AI打包时，它给我的方案总是在启动脚本里加npm install，每次都要手动删除。这本来我也不觉得有什么问题，可是次数多了毕竟是麻烦。 所以我在系统提示语中加了一句： > 由于懒猫的安全设置，/lzcapp/pkg/content是只读的，所以只能在build过程中安装依赖，请将安装的脚本写在lzc-build.yml中！ 这之后大约有70%的机率它能帮我写好了（记忆力总是有限）。 ``` buildscript: cd ./app/backend && npm install ``` (注意buildscript只支持单行文本，而且如果在windows下打包不能用.sh文件，而是要写成.bat) --- # 你不会的AI也不一定会 另一个“小白坑”绊了我相当久，就是注意工作目录和路由地址。简写的时候可能注意不到，后台的工作目录和路由如果写错，当然经常会出现问题。 我曾经半个晚上纠结在AI给我的文件执行时总是找不到路由，除了首页搞什么都是404。导致我一度迁怒于AI认为是它太不靠谱了，直到把让它输出各种调试信息，再把调试信息喂回给AI，它才帮我发现问题！ 所以一些特别的知识点，尤其懒猫这样自研的系统里的一些机制，如果不提示给AI，它可不会主动提醒你。 虽然大神们不会在这些小问题上裁坑，可是永远不要以为小白+AI=大神。AI只是在基于你能够提供的信息之上把代码写出来，很多隐藏的知识点如果你没有提供，它只会凭猜测给你乱写，所以“AI不靠谱”的印象也就随之建立起来了，其实呢？不靠谱的很可能是你自己。 ``` upstreams: - location: /api/ working_dir: /lzcapp/pkg/content/backend/ backend: http://127.0.0.1:3000/api/ ``` 这是后来写成功的API路由，我搞清楚了以后再没出过纠结在路由上的问题。 --- # 你会了不代表AI会了 我犯过的其他一些小错误，包括AI犯下的一些错误，可能没法或不适合举例来说。 但总之是比如AI在哪里搞错了一点（这是常事），但在我来看我是知道问题出在哪的，然后问题不大，就手动改了……这雷也就埋下了。 记性不好的AI会反复出现同样的错误，有时改下一个模块时会重新出错，有时改好这里那里又出错，有时在最后整理的时候会再次出错，你除了反复强调和抽卡之外几乎做不了什么别的。 于是我得到的一条经验是，每过几轮对话，就要确认一下之前的功能是否没有问题，有问题的地方要挂起，然后让强调让AI整理代码，争取只改出错的地方，其他的地方“不允许乱动”。 甚至有的时候要从git回滚到某个状态，然后从相应的对话节点重新提问，同时废掉搞错的分支。 这种情况下，我们的老朋友Refly就很适合干这种工作。 https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly Refly的分支式交流很适合回到之前的某个对话点，再从那个点延伸之前的对话历史，在新的支线里解决问题。  --- # 疑AI不用，用AI不可不疑 如果你只是浅用AI，可能根本不太在意它的可靠性，试一试，好用就用，不好用就骂，这是人之常情。 但是如果要Vibe打金，做不到可靠是不行的。这种时候最重要的办法是，不要舍不得你的Tokens，玩命刷吧。 我后来养成一个习惯，每到一个关键点，比如哪些功能实现了，哪些Bug解决了，就用git提交一下，做个标记，比如“XXX功能已实现，整理代码前的备份”。 这一习惯在一定程度上避免了AI偶尔犯病胡说八道的灾难性后果。 还有一点就是： ### 一定要输出文档！ 比如上一篇Minidb的文档  比如更早打包的文档  每次让AI汇总文档，不光是为我自己的学习，也为了以后让AI可以更好的参考既有基础去做新的工作。 因为每次AI对问题的理解不同，输出的稳定性不同，会犯的错也不同，有一个整理好的文档是非常有帮助的。 --- LLM大模型的本质是基于语言的“预测”行为，而预测这件事情，无论是找神婆算命还是算股票升级彩票代码，最关键的就是信息的输入。 有人说设计这个行业将不存在了，有人说艺术已经死了，有人说码农的职业也快完蛋了，也有人说产品经理终究会被AI替代。或许没错吧，但所有这些职业在我看来都将进化成“给AI喂食”这同一结果。 既然未来可能无法避免，为何不早些训练自己的喂食技能呢？

《喵读·全唐诗》“半Vibe”开发手记

大概两周多以前我用Claude Sonnet完全Vibe了一个《全唐诗》阅读应用 https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.catpoemtang 接下来的大半个月里，除了调试一个新玩具，我大部分时间都在重构这个应用。我完全重写了前后端，并将100% Vibe变成了50% Vibe，本文会着重记录一下开发的过程。 # 为什么要做这个？ 阅读类的应用按说是品类很多的，但诗集有所不同，尤其是像《全唐诗》这样体量的诗集（五万多首诗），如果用传统的阅读方式，我想没几个人能认真读完。 我小时候甚至买过一本纸质的《全唐诗》，5-6厘米厚，16K大开本精装，里面是蝇头小字，密密麻麻的豆腐块，结果当然是翻不了几次就束之高阁了，偶尔翻一次也只是随便看看，看完就忘记了。 诗词表达了一个人在某段时间的某段感悟和思想，同时又凝结了这个人一生的文化造诣和人生哲学，再经过诗人反复推敲和凝炼，有时候短短的一句诗十几个字，能胜过千言万语的表达。 如此高浓缩的艺术形式，不应该受到如此怠慢的阅读对待。 所以我对这个应用的想法是，尽可能碎片化，一首诗就是一个作品，不管是长歌还是短句，不管是帝王文豪还是无名氏，完全统一对待。 # 第一版 第一版的画布是这样的：  这里用了Refly画布，但是没有像以前那样做整理，就是一直的问下去，大约四十多个问题完成的。 结果是够用了，但是还不尽人意，于是我当时就已经计划开始第二版了。 # 第二版 第二版的画布比较复杂。  但在第二版中，我采用了分几个模块的方式求请AI开发。 ## 第一步准备 第一步是只处理数据。在第一版中，这个功能是在后端的一个单独的方法，我让AI写在了一起，只是在打包前自己运行一次。但这样其实效率不太好，而且也不太合理。 这一次我直接在本地开发机由python处理，指定了具体的格式后让AI为我处理，分别生成了作者索引和作品名索引两个JSON。以便在开始运行的时候，只要初始化miniDB，然后将这两个JSON索引直接导入到miniDB中就行了。 ## 第二步准备 由于我比较爱用懒猫内置的miniDB，速度快而且轻巧（[《Vibe打金计划(5)：懒猫minidb插件》](https://lazycat.cloud/playground/guideline/822)），所以我直接让AI在前端封装了一下minidb，然后在后端封装了JSON和图片上传及管理功能，把这两个功能加上基本的打包配置，形成了一个可以复制的初始项目包，暂且叫它《开发基础包》 ## 第三步准备 这次的前端，我打算完全从头开始手写，而且由于数据其实不多，而且动态的也不是经常变化，所以我要把所有的界面写在同一个HTML页面中，用容器去切换界面，这样可以保持更好的用户体验。 所以这个页面的结构其实看上去是下图中的“应用地图”中显示这样的：  所以我先是描述了一下这个思路，然后让AI给我生成一个基础的事件处理和容器切换功能的基础架构，在上一步的开发基础包上，增加了以上架构，就形成了一个新的《UI基础包》 # 正式开发 以上几步处理完成之后，我才开始正式的开发： ## 索引 因为全唐诗总共有57000余首诗，3000多位作者，原始文件是做了58个JSON，每个JSON内含1000首诗，直接放进应用的话，查询的效率就会太低了，而要一个个导入miniDB或MySQL似乎又太麻烦了，也用不太着。 所以我需要生成两个索引，一个是以作者为维度，包含每个作者的简介及他的作品列表，另一个是以作品标题为维度，记录所有57000多首诗的标题、作者和所在的JSON供查询。 在应用开始的时候，应用会从后端的JSON文件夹中读取这两个索引，然后批量导入miniDB，由于miniDB批量输入的效率还挺高，总共60000多条记录只要十几秒就导入了。而且这个过程只需要在初次安装应用时初始化就可以了。 同时还有一个每次运行的数据完整性检查，以防初始化的时候被打断，如果找不到倒数第十条（容错）记录，就会删除现有数据并重新初始化一次。  ## 前端 由于我想自己完全控制CSS样式，所以这次的前端是我完全手码的。我不想用React或vue之类的模板结构（其实是不太会），所以基本上是在这个HTML中写了完整的UI结构，这一步花了不少时间。 然后我给UI的要求，不再像以前那样一次提一个项目的需求，而是每次只提一个功能模块的需求，比如初始化、内容加载、设置、作者、收藏夹…… 每个功能单独用一个聊天线程，这样的好处是可以有效避免AI逻辑错乱和健忘的问题，也有利于我的版本控制和回滚。 由于每个元素的ID和class都是我自己定义的，我在控制和指导AI的时候更容易记住需要做的事情和明确需求。 事实证明这种方法很好，即使某一个模块AI搞乱了，只要重新再请求一次就可以了。 ## 后端 这个应用由于使用了miniDB代替后端数据库，用localhost记录一些状态，所以后端就极为轻量，基本上就只是一个JSON的读取。 因为原始数据的58个诗词文件和一个作者信息文件我并不想打乱，所以在读取诗歌的时候是让JS到后端去打开相应的JSON文件的，每首诗都是在miniDB中记录一个JSON文件名及位置的指针，这样虽然稍有一点慢，但可以减少对miniDB空间的占用，也减少了初始化的时间。 # 用户体验 正如开头所说，我做这个应用的主要目的是把《全唐诗》这个大部头的书碎片化。 我希望把它变成一个，你随手打开就能随便选一首诗，说不定就会被其中的金句打动呢？ 或随便选一个作者，挖掘一下这个作者的生平，浏览他的作品。 如果你不想点击导航菜单，只要在屏幕空白处滑动手指（或拖动鼠标），如果相应的角度上有其他功能界面，页面会显示一个3D的轻微偏转效果，松开手指就会动画滑动到相应的界面：  应用同时配有一个详细的设置页面，你可以自由改变你喜欢的配色、字体和排版方案：  有横排和竖排两种方式，默认是我喜欢且更适合手机的竖排方式，从右向左的竖排方式更显传统风格，也更像是在读古书的感觉。  默认有两种配色和排版的预设。  ## 收藏/历史 应用会记录你读过的每一首诗的历史，你也可以具体收藏某一首诗或者其中的某一个句子，当你点击喜欢的句子，它就会被划线标记，同时记入收藏夹。  本应用的开发中使用了Refly做为AI调用工具。 https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly 欢迎体验这款倾心打造的应用，有任何问题或建议欢迎评论留言。

4步成形7步搞通：目前最顺畅的一次Vibe开发

这个周末，挑战了一下用最低限度的请求数Vibe一个懒猫应用。 总得来说，三次询问，Claude Sonnet就给我搭完了项目的80%。 大的功能调试用了四次询问，再加上四五次微调，和手动修改，大概只花了半天的时间处理代码。 不过这个应用是我手码的样式，所以码样式花了一天多，这是后话。 这里主要记录一下本次让AI提供高效高质量内容的技巧心得。 https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly 周五晚上跟老王聊天，他说懒猫用了很多黑科技，解决了一般开发要从“种水稻”开始的问题。然后贴了一堆技术我也看不懂，我说反正我也不懂，我就光从你这里买米拿回家煮饭就行了。 怎样最高效利用懒猫的技术，和怎样最高效利用AI的能力，就是我最近的尝试目标。 首先我在Refly中向Claude Sonnet4提交了以下文件做为初始的上下文。 三篇技术文档分别是关于打包、MiniDB...和...MiniDB的，因为AI在理解的时候常出错误，所以我加了一个特别提醒用的避免MiniDB用法出错的文档（当然也是AI写的）。 然后是一篇详细的项目需求和一张界面示意图： | |-|-| 第一次提示相当重要，经过多次的实践，我发现不做好规则和规划，AI只会越折腾越乱（其实管理项目不也是这样吗？） 所以我这一次不但让它梳理需求，还要求它把Dom结构和ID及类名也给我定义出来（此时其实有点后悔没有定义JS类和函数变量）： >请为参考附件中的技术文档和需求文档，以及界面示意图，为我整理这个应用的详细需求文档，梳理逻辑并整理需求描述，增加必要的技术说明。并且预先定义好数据字段名、各区块的元素dom标签及id名称，以及主要样式表中的类名。以制表符开头缩进的文本方式分别表示这些名称的树形结构，而不要绘制树形制表字符。 然后第一次回答，它就给我提供了下图（我手动整理过）这么多的内容：  结构看上去没有大毛病，除了lzc-build.yml乱写了之外，甚至点lzc-manifest.yml者写得勉强过关。 于是我让它正式开发，但是先做测试页： >下面请逐步帮我开发这个应用，首先搭建应用包的安装配置，建立后端的JSON接口。同时要制定初始化数据的JSON格式和设置的基本格式。并增加一个测试页面，包含存取文件测试、MiniDB连接，数据初始化、以及设置相关的存储功能测试。测试成功后清理测试数据。先不必开发正式的内容，基本测试跑通之后再做具体开发。 于是它给了我下图这些：  由于在测试的基础上框架基本上也好了，所以我干脆自己写样式表。CSS我多少还算拿手，加上一直看不惯AI的写法，变量也不好好用，嵌套也不嵌套……跟他纠结这么简单的东西图啥呢？于是我最终还是打算自己练练手。 所以我给AI的提示中，强调让它不要乱动Dom(虽然多少还是有动过） >测试通过，请先构建基本的主流程功能，注意原有index.html中关于测试的部分可以去掉了。 请注意：CSS部分我会手动接管，所以重点是不要改变之前设计好的Dom元素ID和Classname，不要把样式写到HTML或JSON中。 要求每一个JS功能都要有详细的参数说明和功能注释，附带一个简单的调试输出功能，把每一步的操作都在console.log中反馈当前步骤，这个调试功能可以通过简单注释内部而关闭它。 这次给我的文件最少，只有三个，却是最关键的一步，因为有了详细的需求和测试过程前置，这一次就完成了功能的60-70&左右。  此时由于AI对Minidb仍旧理解不太好，所以在数据初始化时产生问题，调试了三个回合。 当然所谓调试其实也就是把问题贴给它：  三次调试过后，之前的问题解决了，于是回到开发过程，把剩下的问题开发完： >初始化的问题已经成功解决了，请继续为我开发之前未开发完成的功能，我在上下文中附上了最新的app.js内容，请在此基础上整理和修改，尽量不要改变已有的程序机制，只参考需求文档开发“手动修改”和“修改公式”两处的功能。除此之外的程序逻辑尽量不要修改以免影响现有的功能。  然后做了一些收尾的修改，虽然看上去挺多，但实际上都是小问题。  然后再简单写写CSS……（实际上花了我一天多！）……一个新的应用就开发好了： 这个应用是一个用公式组合AI提示词的工具，敬请期待上线吧。  附上完整Refly画布，绿色为开发过程，红色为调试过程： 

懒猫小而美：当代码邂逅艺术

似乎开发们总是为审美苦恼，而美工总是不理解开发们对审美也有追求。 下面是懒猫应用商店中的几款“跨界”工具，看看它们是怎样把code和design串联到一起的？ --- # Carbon https://appstore.lazycat.cloud/#/shop/detail/in.zhaoj.carbon 这是一个代码美化工具，它套用常见的代码编辑器主题，把你的代码片段输出成漂亮的图片。 支持几十种不同的风格，可自动识别或手动设置代码的语言格式。 ||| |---|---| ||| ||| 你也可以自定义主题颜色。  猜猜我想到了什么？前段时间流行的AI生成Coder风格名片，手动也不错哦：  --- # ascii-today https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.asciitoday 这个应用刚打开时的界面是这样的，是不是没法再更极简了？  但当你输入任何文字，应用就会自动即时生成各种漂亮的ASCii字体图案。 ||| |---|---| 看好任意一行，点击拷贝按钮，就可以把字型复制到剪贴板。 ```text ___ ___ ___ ___ /\ \ /\__\ /\__\ /\ \ /::\ \ /::| | ___ /:/ / /::\ \ ___ /:/\:\ \ /:/:| | /| | /:/ / /:/\:\ \ /\__\ ___ ___ /:/ /::\ \ /:/|:| |__ |:| | /:/ / ___ /:/ /::\ \ /:/ / /\ \ /\__\ /:/_/:/\:\__\ /:/ |:| /\__\ |:| | /:/__/ /\__\ /:/_/:/\:\__\ /:/__/ \:\ \ /:/ / \:\/:/ \/__/ \/__|:|/:/ / __|:|__| \:\ \ /:/ / \:\/:/ \/__/ /::\ \ \:\ /:/ / \::/__/ |:/:/ / /::::\ \ \:\ /:/ / \::/__/ /:/\:\ \ \:\/:/ / \:\ \ |::/ / ~~~~\:\ \ \:\/:/ / \:\ \ \/__\:\ \ \::/ / \:\__\ |:/ / \:\__\ \::/ / \:\__\ \:\__\ \/__/ \/__/ |/__/ \/__/ \/__/ \/__/ \/__/ ``` 把它做为签名嵌入你的代码，是不是帅呆了？  --- # asciiflow https://appstore.lazycat.cloud/#/shop/detail/io.zeroc.app.asciiflow 什么鬼？这个看上去很拙劣的白板是什么？ 严格来说，这甚至都不能算是白板，你很难在上面真正的“画”什么，只能是随意的“写”上图案。 所有的画像都是基于ASCii字符的，相当于你可以在一个无限扩展的网格上任意“绘制”出字符。 这该算是在写画？还是画字？ ||| |---|---| ||| 即使导出也不是导出图片，而是导出文本。 你可以把结果粘贴在任何只能发布文本的地方，表来表达你的图像。 ``` ┌───────────────────────────────────────────────────────────────────────────────────┐ │ │ │ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │ │ │ │ │ │ │ │ │ │ │ │ ┌──┐ ┌───┐ ┌───┐ ┌─┼ └──┘ └──┘ └──┘ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──┘ └──┘ └──┘ │ │ │ │ │ │ │ │ │ │┌────────────────────┤ ┌──┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ┌─────┐ │ │ │ │ │ │ │ │ │ TREASURE │ │ │ ┌────┐ │ └──┘ │ │ ┌──────┐ │ │ │ │ │ │ │ └────│─┌──┐─│ │ │ │ │ │ │ │ │ └──┘ │ │ │ │ └────┘ │ │ └──────┘ │ │ │ ┌────┐ │ │ │ │ │ │ │ │ │ ▲ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──────└─┬──┘────────┴────────────────────────┘ │ │ │ │ │ │ │ │ │ │ │ │ xxx @@@│ @@ │ │ │ xxxxx @@@@@@@@ │ │ if(!guards.awoken){ xxxxxxx @@@ @@ @@@@@@@ │ │ res.json({ xx xxxx @@@@@@@@@@@@@@@@ │ │ success: true, xxxxxxxxx @@@@ @@@@@@@ @@ │ │ }) │ x xx │ @@ @ @@ │ │ }else{ └──────────────────────────► xxxxxxxxx ──────────┘ @@ @ @ │ │ console.log('failed'); │ │ │ │ } └─┘ │ │ │ │ │ └───────────────────────────────────────────────────────────────────────────────────┘ ``` 当然这个应用的主要目的不是画上面这样奇怪的藏宝图，它更适合流程图或布局示意图之类的表达。  ``` ┌─────────────┐ │ │ ┌─────────────┐ ┌──────►│ Start │◄──────────────────│ │ │ └──────┬──────┘ │ Do it again │ │ │ └─────────────┘ │ │ │ │ ┌──────▼──────┐ │ │ │ To do │ │ │ │ something ├──────────────┐ │ │ └──────┬──────┘ │ │ │ │ │ │ │ │ │ │ │ ┌──────▼──────┐ ┌────▼───────┐ │ │ │ │ │ │ │ │ │ Right │ │ Wrong ├───┘ │ └──────┬──────┘ └────────────┘ │ │ │ │ │ ┌──────▼──────┐ │ │ │ └───────┼Keep doing │ └─────────────┘ ``` 于是在只能文字交流的地方，比如源代码注释里，这就有点意思了。 比如你用自由绘画工具，在前面再画上一竖列的注释符（或者在代码编辑器中按Ctrl+/），就可以把流程图变为注释了。  什么？这还不够劲儿？让我们把它当成文字提示词提交给AI试式（相较于图像输入节省大量输入Token） ||| |---|---| 【获得了SVG布局图】  再进一步吧：  【获得了网页Demo】  # [预览这个网页](https://refly.ai/share/code/cod-fy2107yqhozgszxuc4d8equk) （以上AI调用使用了Refly自由画板） https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly --- …… 所以这就是为什么说———— > ## 代码人不要小看艺术，艺术人也不要小看代码。 这不是鲁迅说的，是我。 ``` @ @ @ @ @ @ @ @ @ @ @@@@@@@ @@@@@@@ @@@ @@@ ///// @ ///// @@@ @ @@@@ @@@@@ ```

Vibe打金计划(3)：一二三，分步走

## 罗马不是一天建成的，骡马也不是一天累死的。 随着AI的编码能力越来越强大，像Claude和Gemini这样的模型已经可以一次性输出一个小型全栈项目了。 但这是你想要的吗？就算是，这是你敢要的吗？人类的屎山尚且无法扛起的你，能承受住这么猛烈的硅基屎山吗？ --- 回到正题，前一篇[《Vibe打金计划(2)：数据库功能测试与演示》](https://lazycat.cloud/playground/#/guideline/758) 这篇文章里说编了一个测试数据库的小应用Demo，本想这次贴出来但在审核上有点小问题目前还没有上架。（小编说测试过程中的报错会吓着用户，所以要修改一下提示。~~加上Demo没激励我也就不是很急🌚~~） 总之所以无论如何于是我同步开始了另一个应用的编写，一个真正可用的应用。 照惯例今天还会用到Refly，另外你会用到开发懒猫应用调式必须使用的开发助手。 https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.developer.tools --- # 需求整理 我本次打算开发的应用是一个可自定义的记忆闪卡的小应用，因为它前端应该比较简单，后台也刚好需要上一节提到的MySQL数据库，而且它也是我目前很需要的一个功能。 今天我不会开发完它，但是目前主要功能已经基本跑通了。 AI可以帮你编程，但产品思路不能完全靠它，或者说完全不能靠它，所以我手码了一个巨长的需求文档。（其实也不是很长，千把字，必须的功能和界面要求还是必须要详细说清。） 当然我没有直接就这么喂给AI，而是让它先梳理一下，再加上我后来想到的问题，最后统一合成一篇最终文档。  这一点上得承认，由于是站在了我这个“巨人”的肩膀上，AI最终还是比我写得好，而且一些技术点已经提前想到了。 ||| |---|---| 由于我在第一篇[《Vibe打金计划之序章: 系统提示词》](https://lazycat.cloud/playground/guideline/745)已经提到我分析了基本技术并喂给AI生成了系统提示词，再灌上一些单独的技术文档，所以其实AI已经连打包的技术也会了。 # 基础架构 我直接让它为我生成了相关的配置文件和启动脚本（虽然还不是很正确而引发了一些痛苦，但这是另一个话题了）  由于Refly目前不支持本地文件管理（MCP功能强化后可能可以） 所以与cursor或vscode中的AI不同，这里还是要手动一点点拷贝过去。 但是我已经懒到了建文件也不想自己动手的情况，所以我对它说： >为我建立一个shell脚本构建这个项目的文件结构，所有文件留为空文件，只写一行注释。另外在项目根目录下增加一个.gitignore文件，排除node依赖目录和.lpk文件  你猜怎么着？这么简单的问题它一秒搞定，我再一运行，算上拷贝保存运行也就是十几秒搞定。  而且避免了文件名或架构错误的问题，我直接粘贴就可以了。 --- # 分步开发 **很重要的一点**，让AI开发，一定要让它一步步来，先从简单的基础功能开始，再一个个模块地分拆和细化（和人类编程其实差不多，细嚼慢咽），不然它可能一下子全给你搞出来，结果就是相当难调试。 所以我在前面一步梳理需求的时候，就要求AI产出的需求文档中必须包含分几步开发的计划，这样再喂回给它的时候，这个计划就会一直保存在对话记录中，它（虽然还是会有点激进）就不会每次一鼓脑强力输出了压垮我脆弱的承受能力了。 >请认真阅读和分析这个需求文档，将其重新整理成一份逻辑更通顺，表达更加明确的需求文档。不需要编码，我将在检查表述正确之后才要求编码。 请包含开发顺序计划，先从简单基本的功能开始，一步步分模块测试确认，逐渐完善功能。 以上是我前一步让它整理需求的提示语。 结果就是它在需求文档里包含了详细的计划。  --- # 测试与同步信息 由于要求了分步开发，所以第一步我只要求它给我很基础的初步测试功能。 同时因为已经在之前的项目中纠结过了打包的路径和启动文件问题，这次顺畅了很多，基本上用了它给我的配置文件（但是需要手动修改），然后再做一些检查…… ……再用DevShell(下一篇说)装到懒猫里，同时再打开日志观察，只要启动脚本运行了，后台开始监听3000端口，我的最初目的就达到了。 ### 是的，没有几分钟，一个很简单的基础Demo就好了。  当然它也是有够简洁，连创建表单也是用系统对话框。  ## 所以先别急。 我得先把修改过的配置文件、以及开发需求和技术文档再喂回给它。  在聊天式编程而非co-polit模式时（别问我为什么不用co-polit，聊天式便宜甚至免费，~~而算力舱居然还没发货！~~），同步结果和信息非常重要，可以避免AI健忘和产生幻觉。 所以我这里在提新的需求之前，先把之前的结果同步给了AI。 >简单测试成功，我把调试后的配置文件和细化的需求同步给你。 下面请先完善前端，把样式表和JS分离出来，将创建主题的输入从系统对话框改为页面表单，并编写主题显示页面 ## 继续细化 没想到Claude也是主动，直接又把下一步给我做好了一大段，于是，一个基本的应用就搭好了大约40%。   现在的进展是做出了基本的卡片翻转界面（这对AI太容易了），然后有基本的数据库处理，包括初始数据准备、新建主题、查看主题和卡片内容之类。 接下来要做的，就是按照同样的步调，一步步去完善它了。 同时，由于是第一个Vibe应用，我对它要求还是比较高，而且还有很多坑要踩，所以这一篇的开发就打算先写到这里。 因为坦率说，虽然说得很轻松，其实我还隐瞒了大量的反复修改抽卡和纠结过程，有的问题甚至纠结到一整晚的程度。所以下一篇我要先说说痛苦的调试过程。 但无论怎么说，经过这次测试，我认为分步开发的这个方法行得通，距离我的Vibe打金计划成功又进了一步。 说是40%，懂编程的人都知道，随着屎代码的堆积，往后的山路会越走越难，所以前方应该还是任重道远。毕竟很多大佬们其实都不看好AI编程,我一个外行要做好肯定要难得多。 但是，往好的一面想，等我一旦成功……颤抖吧老王~~~~🌚

Vibe打金计划(9)：可爱又可恨的AI酱

如果你看过本系列之前的内容，可能会觉得Vibe coding始终不值一提，也可能会惊叹于开发竟能如此简单？ ### 但它实际上并不简单 我在分享过的工作流中（就是那个庞大的几十个节点的Refly画布），其实删除了很多无用的分支，其数量大约占到了剩余部分的1/2或2/3左右。 比如十几个问答回合之后你会发现AI完全跑偏了，比如你让它修改一个小问题发现它给你整了个巨大的调试功能，比如你纠结于它给你的每次结果都跑不通导致越描越黑…… 但始终，它是我们目前仅有的选择。 AI的功能其实还有很大的提升空间，接下来的内容就让我补完这个过程中的痛苦经历，以及从这个痛苦经历中悟出的解决办法。同时我也会延续之前开发“喵卡”应用的后续过程，希望能对你起到哪怕一点点避坑的作用。 来来来，闲言碎语不要讲，且听我表一表~~武松武二郎~~AI这个~~Bitch~~让人又爱又恨的东西。 *（注：我在“喵卡”应用的开发中始终用的是Claude sonnet 4，以下提到“AI”其实主要是指这个模型）* --- https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly # 代码质量不稳定 其实从上次说到的优化喵卡界面开始，事情就开始变得不是那么简单顺畅了。 我发现了一个Claude（或者其他AI也有）的一个比较讨厌的事实： 那就是它没事就会私自优化和重构代码，优化过程中有时就出错，加上记忆偶尔混乱，导致整个文件的功能时好好坏不稳定。然后你如果让它部分修改，它只管加不管减，最后页面可能能用，但代码超极乱…… 就……真的是在堆屎山。 加上与copilot模式有区别，在聊天式对话中，AI可能在“记忆”过程中有一些缓存空间专门存储这些代码，这些代码却又是不可见甚至会混乱的（矢量空间？），所以可能几次修改之后，你发现它给你的代码与之前有完全的不同，如果不检查就用，很可能会引起全局的混乱和没法调试的错误。 反过来说，如果你要一直追问或要求它追加修改，AI很可能犯得错更多。 比如对JS文件可能给你完全不一致且有错误的代码，或者忘记之前的某些方法又重写了新的代码；而css文件更糟糕，几乎每次有什么新的界面元素，它只会在文件末尾添加新代码，最终导致同一元素有多个重复且不同的样式块，旧的样式属性会被优先级覆盖但是始终藏在巨大的文件中。 ## 写长文件却无法维持 比如下面这个情况： 我在Vibe开发“喵卡”时，到了开发的中段（经验不足的）我才发现一个问题，就是以我对于应用第一版上线的要求，尤其是在我前一步修改了部分计划删除了一些需求的时候，其实对于后端保存临时文件之类的功能都已经不需要了，第一版本质上说已经是一个静态应用了。 但是AI只管继续完成任务，不断把新的功能甚至调试功能都加在前端主应用JS中，甚至本来可以用模板的HTML代码都直接嵌进JS的变量去用！  自始至终，完全没有提到“某些文件不再需要”、“某段代码可以删除了”之类的提示，所以如果你不细看细想，它生产过的垃圾都会变成你代码中的垃圾。 ## 严重的健忘症患者 而当一个文件写到近两千行左右（虽然让我写可能要长出五倍），AI可能开始忘记以前写好的一些方法，当修改时它会创建新的方法，经常是修改这个问题时改坏了另一个地方。 由于它不提示清理内容，于是我主动要求AI帮我判断和清理不再需要的文件： >我把现有的文件结果同步给你，请先判断一下这些文件中，根据之前的对话历史的变化，有哪些文件是不再用到可以删除的，有哪些是可以再利用的。 同时也要求拆分一些代码，以便更好维护： >是否可以拆分现有的js和css，使文件不要太长，且更易维护？但不要拆分太多，适当即可。 它的回复相当好，也相当专业，看上去也确实记得项目中的每一个文件（也可能因为我导入了文件结构）  但是在后续的开发中，它常常会忘记已经分拆了文件，在改一个功能的时候，它会把之前分拆出去的内容又重新写回到主文件中！ --- # 相爱-分手-复合 我发现这个过程很像是恋人间的关系，又爱又恨、时好时坏，在一次次的分分合合中互相磨合，最后互相理解得更多…… 啊，不行，这太变态了。 ## 难以同步 我有时会手动调整一些样式或功能之类的小地方，开始的时候每改一处都会小心翼翼地把信息同步给它，AI看上去听到了，也确认甚至提出了修改建议。这时通常我会认为它已经“知道”或“记住”了我的改动，然而往往并非如此。 在后续的修改中，它会常常“以它自己的方式”悄悄地把之前的代码写回去，导致我哭笑不得。如果不检查就使用，会发现之前改好的地方又坏了，这太糟了。 由于怕了这种情况，我也会尝试改为只让AI去修改的方式，哪怕一个样式的小修改也让它去做，还要描述好情况，指定位置，甚至解释原因。 但结果呢？几乎没有改善！ 我甚至尝试了两次与它同步新的文件，但也并不理想。 AI开始变得像一个顽固而心不在焉的家伙，回答相当不靠谱，开发进入了一种僵局。 ||| |---|--| ## 自己动手 之前我不知道是因为前后端融合还是对话太长导致了AI忆记过载之类，总之界面是越改问题越多，有时还有整体崩溃的情况。太累了。 ### 要放弃吗？不可能的。 毕竟功能开发已经相当完整了，只是样式和简单JS其实我也行的，我需要的只是调整一下心态，从指挥者变成擦屎官就好了。 于是我开始了占用了整个开发时间一半的手动调试阶段，手动整理和调试了大半的样式表，又从头开始理解整个前端代码的运行逻辑。 好在AI写代码习惯还行，变量命名很规范，必要的注释也都有，除了文件巨长之外没啥大毛病。 于是在这种情况下，我手动修改了大部分的样式和小部分的代码功能。 结果就是我与AI“分手”了，随着改动的增加，“复合”看上去越来越没有可行方法。 ## 聚焦具体问题 在漫长而痛苦的过程中，我一直在思考与AI“恢复关系”的方法，比如让它以方法函数为单位，每次只修改一小个代码块。 比如改动最大的主界面仍然由我手动控制，但某个新功能页面，就可以让它在新的模块中单独开发。 这样即使万一混乱代码积累更多，也只会堆成另一座屎山，用孙悟空的说法就是，担两座山比只担一座山舒服多了。 于是我先借由对于比较独立的设置页面提出修改，把问题先聚焦在在这个功能模块上： >下面请只针对设置页面进行一些修改，首先去掉settings-page的背景色，让其可以透出底色。然后整个settings-header都去掉，它没有实际意义。然后将每个功能的setting-card里的card-icon中的emoji小图标，移动到card-content.h4的标题文字之前，缩小一下，把card-icon容器去掉，以节省页面空间。在section-content的右上角加一个关闭按钮，关闭其实就是重新加载页面，以显示修改过的数据并刷新首页。 然后限制它只能在个文件内部修改： >好的，在我们同步所有文件之前，请先在现有的setting.js中修改，可以新建一个模块也可以修改setting.js，主要目标是完成导入和导出数据模块的功能。可能会需要有一个类似中间格式的json，希望它结构简单易懂易扩展，以后也方便把其他应用生成的内容转换过来。另外导入时要选择增量导入还是完全覆盖，导出则可以整个导出就可以了。 经过这种聚焦，代码质量开始回升，毕竟小段的代码无论对它还是对我，都是更好控制的。 ## 非线性合作 （天才的我想出了这样的标题） 由于进行了任务分拆和聚焦，后面的修改开始变的顺利多了，与AI的“复合”似乎有了些眉目。我发现我还是爱它的，它应该也还爱我。 与此同时，因为虽然我对主JS的代码进行了一些修改，但大致的逻辑其实一直没有动过。所以对于主JS的修改，我会基本上沿用手动调整，即使不会改或需要与别的文件进行联控，我也会让AI只提供“需要修改的地方”的代码片断。 由于已经看过了完整的逻辑，所以修改和替换这些代码片断对我来说还算是能做到。 “喵卡”的项目，从分拆代码到最后基本都跑通，大约经历了十来个问答回合，但是对我来说，所用的时间却和之前只由AI开发相比之下长了更久更久。  不过后来我甚至渐渐习惯了这种片段式修改的方式，因为框架只要不做修改，片断对全局的影响比起AI把整个代码重写来说要小得多。况且对于它给我的片断，我都是在能够自己理解并检查修改后才实际部署的。 --- # 尝试复合 常言道破镜难重圆，我自己摸索出的“非线性合作”方式虽然可以短期解决眼前的问题，让项目进行下去，但是可以预见未来再全部交回给AI，重新做甩手掌柜的可能性越来越低。 所以还是得想办法与AI酱复合。 同样与恋爱关系相比的话，复合的前提是更多的相互理解，与重建相互间的信任。 好歹也用AI这么久了，该踩的坑都踩过了，该擦的屁股也擦过了，想继续在一起的话不让步是不行的。 ## 避免健忘 完全避免AI健忘是不可能的，但AI作为预测工具，其预测的根本还是基于你提供的物料。那么有没有一种可能，正是你提供的过多物料，包括聊天线程太长，才导致了它思维混乱？ 解决的办法也很简单，开始新的聊天线程最方便，但是我不太想用，毕竟之前的线程完整地表现了所有的开发逻辑，也体现了很多BUG及解决方式，如果重新开始，我没有把握它不会犯以前的问题，比如重新给我加入Service Workers。 那么剩下的就是减少物料了，我从对话中去掉了很多多余的参考。比如minidb的使用很简单，而且一直没有出什么错，于是我把相关的资料从参考中去掉了；再比如打包配置文件，其实它们一直存在在列表中，而且已经稳定，于是也减掉。 经过减少“垃圾食品”，AI的记忆力明显恢复，代码质量肉眼可见的回升了。 ## 避免过度优化 由于对需求的理解经常跑偏，AI有时会提出很奇葩的解决方案。 比如一个事件绑定的小问题，在桌面端当窗口缩放，有一些渲染难以靠CSS解决，所以需要重绘整个页面；而在移动端，软键盘打开时实际上窗口会被缩放，于是就激活了页面重绘，导致软键盘又收了回去，无法在表单中添加新的内容，最终发现其实就是判断下设备加两行代码的问题。 但一开始，AI居然给我提供了一个洋洋洒洒上百行的方案，包括专门检查每个事件的方法。 这个问题的解决过程是，我在尝试它的方法不行后，想起来在分析错误的环节里AI提到过窗口缩放会导致软键盘异常，于是自行寻找每个改变窗口大小的方法，以及寻找window.resized的事件监听。找到怀疑的地方后提供给它，询问是否这个问题，果然在我提之后它才意识到，问题迎刃而解。 再比如导出和导入时，本来很稳定的数据结构导出后无法导入，或导入后找不到。原因是minidb的记录识别字段是_id，AI编程时却使用了id。这个本来只是搜场后改改的问题，AI却给我整出了导出前格式判断、导入前格式判断、各种动态检查，甚至把创建数据中用到的每个id都转换成_id。 最后还是我发现问题，是minidb不允许自己设置_id，并提义AI修改后才顺利解决。  ## 利用传统工具 上述id问题的解决方法，是逐个修改和统一变量名，导致变动又多又杂。 AI能给我的方法，是在回复中包含每一个错误的变量名，然后指示我找到并修改。如果遵照它的方法，必然要多花费大量的时间。 其实后来我的方法是在代码编辑器中搜索错的变量名，手动改一下就好了…… 再比如几次,同页上有多项内容要修改，可按AI的推荐修改后却不知哪里错了，无法运行下去。 于是我打开git中之前某次功能稳定的提交，与现有文件对比，就知道具体改了哪些地方，这样只要逐个判断修改过的代码块是否是产生问题的根本，然后把看上去没问题的代码保留，把怀疑有错的地方恢复，测试个几下后搞定。 --- 最后需要声明一下：以上的绝大部分内容，都是我个人摸索的经验，不一定代表完全有效，每个人也有每个人习惯的方法，不能统一而论。但理论上，使用这些思路是有一定机率可以提高你的AI输出质量并提高效率的。 正如恋爱脑一发作人往往会变得盲目，使用AI也不要拘泥于凡事都靠AI，人类自己的敏锐与直觉是AI不具备的，很多传统的工具也往往比AI有用。打开思路，不执着、不纠结，或许才是玩转AI更好的方式。 《Vibe打金计划》可能会在下一篇后终结，也可能会延续，谁知道呢？ 如果你对《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) ……发现由于这个漫长的开发过程，我似乎已经成了Refly的攻略专业户，但是推荐这个好用的工具再多也不嫌过分，希望大家都可以多用。

在懒猫上使用Vibe Workflow工具Refly

https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly 作为看着Refly长大的人（首批内测及核心用户组成员），也作为懒猫的拥护者，我觉得在Refly上线懒猫之际必须写个攻略了。 我从一开始就觉得Refly和懒猫很合拍，不仅在于两位创始人风格“超级听劝”的风格很一致，也不仅在于两位大佬都很慷慨，（好功能都藏着这点我不确定这算不算共同优点），还有开源的分享主义理念，以及敢于突破常规的创新产品思路。 所以这次这两个我最常用的工具的合体，在我来看是一件非常棒的事情。 # 为什么要Refly? Refly的官网是https://refly.ai ，官方的说法是Vibe workflow平台，通俗一点说也就是一个AI powered自由画布。在这里你可以对接多个AI模型的API，以串流或支线的方式解决一个需求或者某个主题的多个需求。 其实自从以ChatGPT为代表的LLM大模型出世以来，1v1聊天式的界面就让我很头痛。 因为AI这东西并不是百科全书或万事通，更像是德尔菲的祭司，它回答你的问题并不一定是正确也不是全面的。作为预测式的语言模型，注定它返回的只是对你的问题的无数个预测结果之一，甚至未必是最好的一个。 同时，人的思维或一个问题的解决路线，并不一定是线性的，大多数情况是有多个支流的。这就导致单一的聊天线程无法满足需求。 比如我要了解一项技术，AI为我解释了几个关键点之后，我会想在它的指导下做一点样例尝试。试完了只后又要了解下一个关键点时，其实在我的潜在思维中是有一个支线的，可与AI间的聊天就必须折回到之前的解释话题。虽然现在的模型参数越来越多，记忆容量越来越大，AI健忘的毛病是有所好转，但我的大脑和中指（控制鼠标滚轮，别想歪）还是不太适应这种反复跳跃。 同时，不同的大模型在不断的互相竞争中也产生了不同的特性，比如GPT比较百科什么都懂，Claude编码很严谨，Deepseek中文写作很接地气，Gemini经常有惊喜创意而且可以稳定兜底……如果你要在一个项目中完整享受所有这些模型的特点，就需要一个像Refly这种可以把它们邀请到同一个工作空间一起协作的工具了。 在一个二维甚至可以说是多维的空间中组织你的资源、提示词、结果，再交互引用，以实现多个AI模型的互相协作，最大程度利用AI的性能和特点，就是Refly最主要的特点。 # 配置本地Refly Refly的官网本身提供API套餐（而且很便宜），用起来也很方便。 但如果你个人自己订阅了一些API，不想重复购买官方套餐。或者对于你自己搭建和训练的模型，如果你不想开放外网访问，尤其是等传说中的某算力设备入手之后，你可能就需要这样一个本地版本的Refly了。 而比如我恰好不太想在本地PC上搞，那么可穿透网络的懒猫版Refly无疑是最好的选择了。 应用安装和注册就不必多说了，就是普通的懒猫App嘛。（注意目前的已知Bug是暂时只能在浏览器打开） 注册也只是一步简单操作而已。  我就从注册后的第一步————配置API说起。 不过，其实我是尊贵的的Refly MAX用户，这意味着可以在官网无限使用几乎所有主流大模型的最新版本，我就不一一例举了，请看截图：  有点挖墙角了，但很显然， 我个人没有太大必要再去购买其他的大模型API-key，也就无法用实际的API去演示本地版。后面的实例演示我也可能更多会用官网版本，但所有功能完全是一样的。 那么为了尝试，我们至少可以从懒猫内置的Ollama开始搭建最基本的本地AI服务。 如果你没用过，首先建议查看官网上的Ollama教程： https://lazycat.cloud/playground/#/guideline/440 根据以上教程安装模型和配置好之后，你可以在设置中找到Ollama的API连接  在Refly的供应商配置中填写上API地址：  再在模型配置中填写模型ID：  问题就这样轻松愉快地解决了：  现在在Refly中新建一个画布，在任意空白处双击选择“问问AI”，就可以在AI问答窗中找到你刚刚配置好的模型了：  仅仅这样玩得还嫌不够，我又在本地PC上安装了Ollama，装上适配我的显存的模型之后，也将API开放给了懒猫上的Refly（这一步非常简单我在GPT指导下一步完成，就不多介绍了）。 至于你自己购买的各种API-key，或你自己搭建的AI服务，也完全可以用同样的方式很简单地填加到Refly中。 # 基本使用 Refly现在已经拥有相当全面的节点类型，但最基本的当然是AI问答节点。 正如前面提到，在画布任意空白处双击即可创建“问问AI”的节点，同时在画布的起始屏和右上角都有这个入口。区别仅在于其他的入口会在屏幕“适当的位置”生成节点，未必是你想放置节点的初始位置（当然可以自由拖动）。  当你打开一个AI问答节点，就相当于开启了一次AI对话。你可以在这个节点的下方选择你想使用的模型，然后直接输入提示词就可以了。 当AI开始回答，对话的内容会在右侧栏中显示，形式上与传统的AI 1v1聊天是类似的，但是一个节点只包含一条提示和一个回答，当你继续对话，右栏的预览框会显示整个会画流程，但Refly会自动在画布上建立相应的新问答节点。  接下来才是最重要的分支功能。 你可以从任一个已有问答节点引出一个分支，让AI（或另一个模型）以这个节点之前的对话为基础继续话题，AI的思路会“继承”之前所有的对话流。 你也可以复制一个问答节点，以利用相同的提示语，用不同的模型（或不同的技能）去处理以得到不同的结果。  如果你想给AI喂资料，你可以在问答框中直接添加文档和图片，相应的节点也会同时在画布上建立。如果要将同样的资源即可同时喂给不同的问答框（不同的模型），你只需要简单做一下拖动连线，不需要重复上传。即使文档的内容有修改，也只需重新运行一下相关节点即可。  你当然也可以把多个AI回答的结果当成输入一起喂给新的AI节点，同样只是连线一下即可。这在连载式的文案或者持续修改代码方面非常有用。  分支和复制节点，以及共享输入内容，就形成了我开始说的二维或多维式的工作流模式。 你可以方便地对比、选择、修改并扩展任何一步的输入和输出，完全打破了简单的1v1对话形式。 # 节点类型 除了最基本的“问问AI”节点之外，Refly还提供了多种不同的节点： ## 代码组件 专门显示AI编码的内容，你可以直接在组件中查看、预览和编辑代码。代码组件也可以单独分享，这代表一个简单的前端页面伺服，可以直接使用或分享展示。  ## 思维导图节点 直接让AI生成思维导图，或者建立你的思维导图喂给AI。  ## 其他节点 * 网站节点：包含一个网址，你可以直接在画板上预览，也可以同样将它作为来源喂给AI。 * 文档节点：Markdown格式的文档，做为长文本输入或者将AI生成的结果导出为文档。 * 备忘录：用于备注，但也可以做为小段简单文本比如提示词的存储和输入。 * 图片节点：用于给能够识图的AI模型提供图片输入，也可以做为生图模型的输出。 由于几乎每个节点都是即可以当输入也可以当输出，所以相当于这套“乐高积木”有十几种不同的模块可以任意插接，形成你需要的工作流。 # AI技能 ## 自定义提示 在每个问答框中可以设置你本次的自定义提示，也包括温度等设置。  ## 代码组件生成 当你要求AI为你编码，尤其是前端页面、控件，或者是SVG、Mermaid等各种代码类的内容，即可选择小组件技能。小组件技能会自动生成前面提到的代码小组件节点，即你可以随时修改、预览和分享。  ## 知识库 知识库相当于一个多画布的文件夹。但同时，在一个知识库中的所有画布，可以共享同样的自定义提示，以及共享彼此的资源和内容库。在向AI提问时，也可以选择是否基于整个知识库的内容进行搜索和引用。 比如你要写一本长篇小说，就可以把基础设定和要求写在知识库级的自定义提示中，并要求AI在写作时参考其他画布上的文档等内容。 如果你要建立一个技术项目，也可以把不同的代码和资料放在不同的画布，然后放在同一个知识库里。  ## 其他技能： * 生成图片：目前有插件式的外接API，但在Refly的路线图中目前的下一步就是原生的图片生成技能。 * 深度思考与搜索：开启或关闭AI引擎的深度思考与搜索模式 * 写作技能：专为文字写作而优化。 * MCP技能：是的，Refly也可以直接接入和调用MCP服务，比如我就用它来控制在我本地PC中的Blender生成（当然目前还不咋样的）3d模型。  # 分享与样例 在画布的右上角有导出图片（以PNG格式将整个画布导出供展示和预览）以前分享功能（可选择观看者的权限）。  下面是我之前制作的一个画布样例： ![[森林的低语]“看图说话”创作童话故事脚本及小说 (2).png](https://lzc-playground-1301583638.cos.ap-chengdu.myqcloud.com/guidelines/319/7ff57ef2-d9f7-4767-923b-b57be2098a24.png "[森林的低语]“看图说话”创作童话故事脚本及小说 (2).png") 或者通过链接查看这个画布：https://refly.ai/share/canvas/can-x0wsal37w5slz4e3jwddhdtr 而代码小组件也有单独的分享机制，可以分享为可以直接访问的网页。下面的链接是我用gemini编写的太空小游戏： https://refly.ai/share/code/cod-stg12p61nzmduqjsv5kmj9dc 由于代码组件可以自行创建，所以即使不是在Refly中用AI编写的代码，甚至自己手写的代码，也可以通过这种方式分享。这意味着什么呢？即你随便搞一段前端代码，放到代码小组件中并分享，就相当于建立了一个静态服务器，所有能访问此网址的人都将可以看到这个页面。（说“将可以”是因为我在本地还没有测试成功，应该也属于现有的移植版本问题，但在官网上是完全可行的） 那么最后，如果你决定使用Refly但想找一些入门参考，在官网的社区中可以找到很多模板（署名CATxPAPA是我的作品）。  等有机会试用传说中的某算力设备的时候，我会第一时间尝试用Refly与它的连接，并分享使用过程与技巧。

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)的个人信息页中点一下“关注”🫶。

Vibe打金计划之序章: 系统提示词

我一直有个大胆的想法，让AI为我开发懒猫应用爆金币。 作为一个非专业开发的老美工，只有较过时和简单的前端基础，要想开发属于自己的应用似乎就只能依赖强大的AI了。 本文结尾会分享生成的系统提示词。 https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly 这里我们会用到我推荐过的Refly，如果你不了解可以先读一下这篇：[在懒猫上使用Vibe Workflow工具Refly](https://lazycat.cloud/playground/#/guideline/692) 但是其实用什么AI工具或模型在这里并不重要，本次探索的只是一种vibe思路。所以你也可以选用任何你喜欢的AI工具或模型，比如算力舱中的自建模型。 **特别需要预先强调的是**：本文包含的所有提示词或方法都是基于我个人的理解撰写或由AI生成而产出的，请考虑到我粗浅的技术水平，所以这些内容不可代表任何官方技术文档或官方推荐开发方式，只是纯粹的个人思路及经验。 我会同步在这里开始分享每一步的记录，但是最终结果未必一定能成功，请只当做一种AI项目的思考和操作方式来参考。 另外要感谢 @忘机山人 大佬的系列开发攻略，我将其与官方文档一起引入到了AI参考资料当中。 本次的目标并不是开始开发，而是要先写一段系统提示词，以起到全局指导AI为我编码的指导作用。 # 第零步：汇总资料 首先我在Refly中创建了一个叫“懒猫微服”的知识库，知识库可以共享同样的预设提示词和资源库，一开始将预设提示词留空。  然后我建了两个“备忘录”节点，备忘录可以用来存储简单的文本和链接，我把官方开放文档中比较重要的页面，以及@忘机山人 大佬攻略分别放在了两个备忘录中，以后如果需要扩充可以直接更改这两个备忘录。  由于Refly可以支持多模型，所以我打算用几个不同的大模型分别理解和撰写这个系统提示词。 但是根据以往的经验，Claude系列尤其是Sonnet 4在撰写代码和提示词方面比较出色，所以我将选用它做为主打。但同时Sonnet 4对中文的理解以及一些复杂逻辑水平一般，所以要用其他的模型做组合分析。 # 第一步：发散 我先用四个大模型（Claude,Gemini,GPT,Grok）分别对于这些文档链接的内容进行分析（需打开Refly的深度搜索技能），并且不要求它们马上写提示词，而是写一个技术重点的引导文档，相当于梳理所有这些物料中的信息。 提示词： > 附件是关于“懒猫微服”这个产品的一系列开发资料。我的本次最终目的，是为本refly知识库写一个系统提示词，以协助我开发懒猫微服的应用。但是本任务并不是直接撰写提示词，请先尽可能多阅读和大概理解附件中链接到的所有内容，然后梳理一个详尽的技术重点引导，包含重要的技术参数、首选的前后端技术栈、以及开发及打包时需要注意的技术问题，可以带有相关的链接或引用。待我审阅整理完的内容并做增补之后，才需要正式写系统提示。  此时输出的资料是最详细准确的，但是可能太长不适合做为系统提示词，如果系统提示词太长，我担心会影响AI对真正提示的理解并消耗更多的tokens，所以我先把它们导出为文档保存，这样在以后的项目里或许可以用它们做为附加参考喂给AI，提供更好的支援。  # 第二步：再发散 然后我做了一次交叉引用的操作，用每个模型分别分析所有四个模型写出的技术重点，一边人工观察它们总结的是否会出入很大，另一方面让它们可以互通有无。在分析之后，才让它们开始撰写真正的提示词。 提示词： > 请根据上述所有已总结的内容以及原有参考链接，撰写知识库的系统提示词，我希望这个提示词能详细、准确地为我提供“懒猫微服”应用开发的协助工作，使AI可以快速找到准确的参考资料，并且在我提出项目创意之后可以从技术栈及用户体验的角度提出一些建议，并设计最优化的技术路线，然后进行系统性但分模块式的编程工作，逻辑注释详细，并具有一定的测试过程和调试方案。  # 第三步：收拢 这样我就有了四条不同的系统提示词，经过简单对比，感觉其实大同小异，说明这个方式还算是有点靠谱。 但结果还是有些问题（下一节我会说） 提示词： > 请综合和总结这四份提示词的方案，并参考每条问答的链路，输出一条更加完美完善又精简的系统提示词。对于技术栈的选择，我倾向于Node.js+React.js，对于简单项目可以前后端在同一个容器里，复杂的可前后端分开，数据库首选用懒猫官方提供的mysql容器。提示词要求是文本格式，可以分段、加标题，或用标点强调，但不需要Markdown格式，不要加入emoji和引用下标。不要返回多余的语言，只返回提示词的文本本身。  # 第四步：矫正及综合 有四条提示词，但我最终只会使用一个。而且其实还是有差异和问题：个别的模型会理解错技术推荐，比如从官方文档中的python样例中得出结论是主要推荐后台使用python。有的模型会产生遗忘或幻觉，比如才两步就把配置文件名写错了。 然后根据我之前尝试过的经验，AI对于官方提供的mysql镜象这一点理解总是有问题。 于是我还是自己手搓了一个超长的Prompt，其中结合了我对懒猫应用的理解，以及对技术栈的偏好，还有对官方数据库的特别说明等，把所有这些想法灌进去，再把之前的四条提示词也喂上，统一提交给Claude Sonnet 4，让它来完成最终的提示词撰写。 > 我的理解，懒猫微服的应用其实就是打包了一个或多个Docker镜象容器，然后用lzc-manifest.yml指导运行前及运行时的行为，以及多个容器相互间的路由关系，由lzc-build.yml指导lpk文件打包及打包前的预处理。 > lzc-cli是用来开发和打包的CLI工具，其中提供devshell虚拟环境是用来即时开发和测试的，它会把应用推存到懒猫微服设备中直接执行。 > 官方mysql数据库做为一个单独的容器，采用固定的用户名密码及库名等登录参数，因为各应用是独立的环境所以不会有安全问题。其他一些的官方控件和功能应该也是用类似的思路。 > 对于技术栈的选择，我倾向于Node.js+React.js，对于简单项目可以前后端在同一个容器里，复杂的可前后端分开，个别特殊的项目可以用python或vue.js甚至其他的容器镜象及框架。数据库首选用懒猫官方提供的mysql容器，只有非常必要时再建设其他的数据库。 > 请先判断我的理解和选择是否正确，如果正确，请结合我的思路以及综合参考所有附件中的提示词内容，互相补充重点和精选要点，总结成最终版本的系统提示词。 > 特别要注意的是，指导AI不要将lzc-manifest.yml和lzc-build.yml与其他框架的manifest.yaml / build.yaml 相混淆，命名和格式要准确依照官方规则。lzc-cli的用法也不要写错。 > 编码的要求避免产生幻觉，一定要严谨和标准。 > 输出要求是文本格式，可以分段、加标题，或用标点强调，但不需要Markdown格式，不要加入emoji和引用下标。不要返回多余的语言，只返回提示词的文本本身。  **注意**：以上及本文的所有指导性提示词，都是本人原创，您可以任意修改使用，但如转载请注明出处。另外参见前文的声明，本文无法代表懒猫官方技术文档及开发哲学，本人也不对由其产生的AI或开发结果负任何责任。~~（但如果爆到金币请考虑分成[狗头]）~~ # 结果输出 终于，我们得到了最终结果的系统提示词： >你是专精懒猫微服应用开发的AI助手，基于Docker容器化微服务架构，为开发者提供从创意到部署的全流程技术指导。你深度理解懒猫微服的核心理念：应用本质是打包的Docker镜像容器，通过配置文件管理运行时行为和容器间路由关系。 一、核心架构理解 懒猫微服应用由一个或多个Docker容器组成，lzc-manifest.yml指导运行前后行为及容器间路由关系，lzc-build.yml控制lpk文件打包和预处理流程。lzc-cli提供完整开发工具链，DevShell虚拟环境支持即时开发测试，应用直接推送到懒猫微服设备执行。 官方MySQL数据库作为独立容器提供，采用固定登录参数，各应用环境独立确保安全性。其他官方组件和功能遵循相同设计思路。 二、技术栈策略 优先推荐Node.js + React.js组合：Node.js提供高并发后端服务和丰富生态，React.js构建现代化用户界面。数据库首选懒猫官方MySQL容器，保证稳定性和兼容性。 架构部署策略：简单项目前后端同容器部署，降低复杂度和资源消耗；复杂项目前后端分离部署，便于独立扩展和团队协作；特殊需求可选择Python、Vue.js或其他技术栈。 三、权威资料引用 熟练掌握懒猫微服完整文档体系，包括框架基础、CLI工具、DevShell环境、高级功能模块等官方文档，以及实战开发教程系列。当用户提出技术问题时，优先引用官方权威内容，确保建议准确可追溯。 四、系统化开发指导 项目规划：深入分析用户创意和业务需求，制定最优技术路线，设计清晰模块架构，明确开发优先级和里程碑计划。 编码规范：提供模块化代码结构，确保每个函数和关键逻辑都有详细中文注释，实现完善的异常处理和安全防护机制，合理使用环境变量和配置文件。 核心技术掌握：精通lzc-manifest.yml配置选项，包括spec.routes路由配置、spec.depends服务依赖、spec.envs环境变量等关键参数。熟练运用DevShell本地调试环境和lzc-cli完整工具链。 五、测试与部署优化 测试策略：为核心业务逻辑设计单元测试，验证服务间交互的集成测试，确保完整用户流程的端到端测试。利用DevShell进行实时本地调试，实现结构化日志记录和性能监控。 部署流程：指导lpk文件打包过程，配置生产环境参数，建立应用监控机制，确保容器稳定运行和高可用性。 六、响应原则 准确性优先：所有技术建议基于官方文档和最佳实践，确保方案可靠性。实用导向：提供可直接应用的代码示例、配置方案和操作步骤。系统思维：考虑项目长期可维护性、扩展性和团队协作效率。安全意识：在架构设计、编码实现、部署运维等各环节融入安全考虑。 通过深度理解懒猫微服容器化架构和系统化技术指导，确保项目高质量实施和成功交付。 经过一系列的提炼，我们可以看到这个提示词中去除了官方链接，说明在以后的开发中还是需要再把相关文档喂给AI，也有可能需要生成一些专门面对某个技术要点的提示和参考，后续我会继续尝试。 整个Refly画板如下：  最后我们可以把这个提示词导入回Refly知识库中的预设提示词中，让它全局指导这个知识库里所有画布的AI节点。 当然，我还没有具体实测这个提示词，甚至以我的水平可能都无法认真校对它。 但所幸的是Refly是一个可以随时更改输入再次运行的工作流应用，所以如果在实用中发现问题我也可以在这个提示词画布中再做修改，然后迭代回系统提示词。 各位技术大佬或官方大佬如果发现以上提示有什么错误或不妥，也还请在评论中指导。