懒猫微服开发篇（零）：上架应用需要哪些知识

懒猫微服的可玩性在于可以让开发人员放开手脚来做一些事情，等于是提供了一个可靠的基础设施。那么理所当然我们可以把开源的知识应用到上面，比如开发或者移植应用，或者干脆部署一些好玩的东西。这在传统NAS上实现起来很困难，甚至都没有包管理工具。 我们看一看开发懒猫应用，需要什么样的知识？ 那么，开发懒猫微服的应用需要掌握哪些技能呢？ ### NPM 懒猫微服的 CLI 本质上是一个通过 NPM 全局安装的工具包，因此掌握一些基本的 NPM 使用方法是必要的。 ```bash npm install -g @lazycatcloud/lzc-cli ``` 这个工具是用 JavaScript 编写的，但如果你只是为了使用而非开发，那么并不需要掌握这门语言。当然，你也可以选择使用 pnpm 或 yarn 作为包管理工具，或者通过 NVM 来创建 Node.js 虚拟环境。 如果在 macOS/Linux 上遇到了权限不足的问题，其实不一定要使用 `sudo`。默认情况下，npm 的全局目录是 `/usr/local`，普通用户对其没有写权限。比如我们可以看到： ``` ll /usr/ total 0 drwxr-xr-x 918 root wheel 29K 6 5 14:05 bin/ drwxr-xr-x 32 root wheel 1.0K 6 5 14:05 lib/ drwxr-xr-x 417 root wheel 13K 6 5 14:05 libexec/ drwxr-xr-x 8 root wheel 256B 6 10 09:31 local/ drwxr-xr-x 230 root wheel 7.2K 6 5 14:05 sbin/ drwxr-xr-x 43 root wheel 1.3K 6 5 14:05 share/ drwxr-xr-x 5 root wheel 160B 6 5 14:05 standalone/ lrwxr-xr-x 1 root wheel 25B 6 5 14:05 X11@ -> ../private/var/select/X11 lrwxr-xr-x 1 root wheel 25B 6 5 14:05 X11R6@ -> ../private/var/select/X11 ``` 因此我们可以通过设置 npm 的全局安装目录，规避权限问题。在当前用户目录中创建一个文件夹并添加到环境变量中即可： ```bash npm config get prefix /usr/local mkdir ~/.npm_packages npm config set prefix ~/.npm_packages/ npm config get prefix /Users/home/.npm_packages export PATH=~/.npm-global/bin:$PATH ``` 开发的技能是可选的，如果你只是移植现有的应用的话，那么具备一些Docker Compose的知识就足够了，这个我们后面再说。 如果是开发原创APP的话，那么无论是Vue，React，Go，Python都有用武之地，只要是Web的应用能够本地运行或者打包成Docker就能上架商店。相信很多开发的小伙伴也会做一些Devops的事情，这部分的技能是可以完全迁移过来的。 ### Linux 很多NAS是基于FreeBSD或者Linux改的，懒猫微服是基于debian12， 虽然在设计之初是针对非专业玩家。但是后来也开放了SSH，可以做和其他Linux一样的事情，给了root用户，所以可以底层操作文件，网络，查看分区，监控，以及系统负载。 所以不是只有树莓派或者自己笔电装机才能学Linux，懒猫微服的系统重启之后会复原（除了root目录和网络设置），所以请随便折腾。 虽然有了一套很完善的图形客户端，但是相信很多专业的玩家还是更加喜欢用传统Linux的方式来看待这个微服，我管他叫做拆解系统设计。 举个例子：用 `htop` 查看负载、用 `nmtui` 配置网络、用 `lsblk` 查看磁盘分区、用 `systemctl` 设置服务自启。深度定制的系统，让我们可以完全无视内核，以及grub的这些东西。甚至连sambda，webdav这些server都不用自己安装。 ### Docker Docker好像对NAS玩家是必须的，无论是群晖，威联通。与传统NAS不一样的是，懒猫微服集成了三套docker，分别是系统组件，playground和应用商店。 playground就是我们刻板印象的Docker， 这里叫做`pg-docker`，所以需要懂一些Docker的知识，比如下载，打包，上传，还有数据卷的贡献。甚至包括Docker- compose的使用。 应用商店也是基于Docker运行的， 上架软件时有两种方式： 1. **直接打包**：这个一般用于原创应用或者移植开源无docker版本的应用。调试的时候可以使用懒猫内置的Docker Registry 的image进行测试，颇有VS code remote的风格。这个调试模式叫做devshell。 2. **Docker 镜像迁移**：一般用于已有的docker image的迁移，由于国内出海宽带不足，访问Docker经常失败。所以需要使用懒猫提供的Docker Registry 来做一个国内版本的镜像。然后再做目录的映射。 ### OIDC 这个稍稍有点跑题，前面的都是传统Devops需要的东西。这里的OIDC叫做OpenID Connect，是单点登录实现的一种。传统的认证有基于cookie的，或者基于JWT的。OIDC是后者，也是单点登录中最优雅的实现。除了OIDC之外，你可能听说过SAML，Oauth，其实也都是Single Sign-On的不同实现，而Oauth是和OpenID Connect 源同一脉，Oauth的各家实现千差万别，而OpenID Connect 既统一了规范，解决用户态的问题。换句话说OAuth 2.0只是用来授权，颁发的是`Access Token`，而对于访问者是谁还需要开发人员自己存数据库。OIDC则是引入了`ID Token`，这通常是通常是 JWT，所以认证直接请求IDP解码就好了。大致是这个流程： 下图是 OIDC 的基本流程：  #### 能够学到哪些知识： 1. 微服内部的官网看起来是根据OpenResty改的（个人推断），所以可以来复习一下nginx或者OpenResty相关的知识 2. Docker的使用，容器这几年还是挺火的，移植应用必备，甚至还支持web VNC。 3. HTTP 知识：有些情况需要对http的请求做特殊的处理，比如加一些自定义header或者cookies 4. 单点登录：微服内置了OIDC的认证，应用能够自动帮助我们申请CLIENT_ID和CLIENT_SECRET，简化了和IDP打交道的环节。 ### 总结 如果你熟悉 Web 开发、Docker 和基本的 Linux 操作，那么你已经可以快速上手懒猫微服的应用开发。无论是移植开源项目，还是开发原创 App，只要能够在本地运行或打包为 Docker 镜像，就可以顺利上架到应用商店。 懒猫微服不仅仅是一个面向普通用户的 NAS 系统，更是一块为开发者打造的自由试验田 —— 它就是一台稳定可靠的 Debian 云主机，你可以在上面尽情发挥创意与技术。 

科幻感AI僚机：懒猫AI算力舱使用体验

>本文为“懒猫AI算力舱”这个产品的个人应用体验与对产品的思考，非AI撰写，阅读大约需要……我也不知道多久，反正用不了多久（￣︶￣）↗　 # 颜值 关于颜值 ，啥也不说，先上图：  || |---|---|---| 这是什么？是黑暗勋爵的太空船？是星际殖民者的神秘基地？是赛伯反叛军的黑客装置？ 没错，我也是颜值派，而且是黯黑系颜值派。 可其实我并不是因为颜值才想要懒猫AI算力舱这个东西的。远在知道它长什么样子之间，我就想让它加入我的装备库了。 当然，对于外观我也是有一种信任感在的，毕竟它的兄长——懒猫微服长得就很俊。 | |---|---| 兄弟俩配在一起更帅。 小巧而强大，是我之前对懒猫微服入手时的第一印象；而懒猫算力舱给我的印象是，更小巧而更强大。 仅从照片上看，你会觉得它很酷，然而这种感觉可能是不完全的，因为它并不能代表你把它拿在手里时的那种紧密的重量感和金属触感。 所以如果你已经被它的外观吸引了，那么建议你再拿在手里掂一掂感受它的坚实，用手摸一摸感受它一体化的造型和细致的倒角，用心感受一下它体内传递出来的黯黑能量……（啊，白色版另论）  我曾经开玩笑地跟老王说，他这是冲着星战风格卯上了。因为这个科幻造型和合金材质，完全不是传统迷你主机那种廉价工业化设计加塑胶外壳能比的，分明就是一架未来太空船的设计。 套用我在评价微服时说过的类似的话：对于为老派星战系列和变形金刚而着迷的一代老少年，没能拥有乐高死星，没有拥有顶配金属擎天柱，但能在桌子上摆这样一个计算设备，也未尝不算顺便圆了一点科幻梦（又多圆了一点）。 # 定位与动机 至于颜值以外，从我个人的角度来讲背景是这样的： 在用了十多年的苹果之后，由于对AI的需求（~~而且穷~~），我决定抛弃果子阵营。并在之前配了一台显卡是4070TiS的PC，4070这个显卡跑小参数的AI足够快，但因为显存只有12G，基本上运行不了14B以上的模型，所以就有点鸡肋。加上我不玩游戏，入5090之类的在短期内实在没有必要。 还有一个重点是，我不是很想在主力机上不间断跑AI，那会导致其他的事情做不了或很缓慢。我更习惯在主机上只“开发”新提示词，继而同时在云端服务器或其他电脑上批量抽卡。 在这种情况下我就会感觉很需要一台“僚机”，它可以其他啥都不干，只要闷头一个劲跑AI就可以了—— 而懒猫算力舱就是在恰好在我这个“感觉很需要”的时间口上出现的。 我认为这个产品的定位差不多就是这样，机如其名，它是一台专门用来提供AI算力的设备。 之所以叫“僚机”因为它并不是副飞行员（copolit）那样的纯软件角色，也不像显卡坞之类的外设扩展，而是一台独立的迷你计算机。 同时，它也是对懒猫微服的功能扩展，结合微服的网络穿透能力，算力舱就可以为你所有的设备提供AI服务，真正的成为懒猫一直在打造的“私有云”的一部分。 恰好我已经拥有了懒猫微服，习惯了它的网穿体验，基本上不需要任何学习成本就可以在所有设备上运行应用。而其简单的应用架构又使得连我一个不懂技术的人都可以在AI的协助下开发自己需要的应用。 甚至微服内置的相册还有自动同步相册和AI查找去重等功能，对于平均每天会生成和抽卡上千张AI图的我来说，这个组合可以说再合适不过了。  另外，由于我也算是懒猫微服的资深用户加“自甘吹”了，除了前面说过对外观的信任感，对于设备与技术，包括海底捞式的服务，在一年多的高频度使用中，我已经建立起了对懒猫团队的充分信任。 我是相信这个极客基因满满的团队，至少目前很长一段还不会被资本污染的阶段里吧，是不会因为眼前的小小商业利益而以次充好的，因为对于技术的偏执追求和对产品的完美化理想主义会阻止他们这么干。 所以以我的观点，基本上可以闭眼冲。 # 连接设备 由于算力舱本质上算是一台独立的电脑，你甚至不一定需要懒猫微服（当然二者相乘会得到彼此优势的更大发挥）。 安装时基本上不需要看说明书。背面只有必要的接口，插上传说中的碳化镓电源适配器（感谢小笼包妹妹贴心地送了我欧标转换插），把HDMI接口接到显示器上，再在USB口插上键鼠接收器，直接开机就可以打开内置的Ubuntu界面了。 由于我家里连接网线有些不方便，所以尽管套装里配备了高级的山泽网线，我仍然打算直接使用Wifi，只要在Ubuntu的GUI里设置无线网络就好了。 而对于充满黑科技懒猫微服来说，只要算力舱在它能访问到IP的范围内，它就可以自己找到。要做的一切只需要从懒猫安装一个AI应用，剩下的跟随引导很容易就可以将算力舱和懒猫微服连接起来了，基本上属于即插即用。 而相应的，拥有了微服穿透能力的算力舱，立刻就可以被你的所有设备访问到，只要安装了（作为主要服务入口的AI浏览器）的设备，无论是PC或平板还是手机，都可以随时随地享用到AI的服务。 # 日常辅助 这里的AI浏览器，是一个经过特别定制打造的Cromite，也就是功能和性能都基本上相当于Chrome，AI服务的入口是以流览器插件的形式置入，所以可以轻量到几乎无感。  基本的官方应用包括AI自动翻译网页、AI总结、AI辅助文字撰写、微服全网盘搜索、文生图、文生视频等，当然还包括我最需要的ComfyUI与Ollama。 而由于内置了Ollama，而且大部分LLM类功能的插件都是连接到Ollama的，所以相当于可以自由地拉取包括满血版Deepseek在内的所有Ollama支持的开源模型，并可以在设置中选择针对各项功能的或你所偏好的模型。 没用多久，我就已经习惯了在搜索时随时看到AI的解释，在看视频时看到AI的总结，随手翻译网页中的内容，而且完全不需要在意什么Token…… 为了更有僚机感，我目前把算力舱放在机箱顶上。它看上去就像一个外置硬盘盒，美观却几乎没有存在感。风扇只在大量运算的时候才会响起来，并不比我的电脑声音大，看来散热设计也相当好。  由于是GUI用户，不像极客们那么爱代码，所以虽然配置好了SSH，我还是配上一个小号的移动显示器，这样就可以随时监控状态并查看生成的图片和视频等。  由于是独立系统，我打算为它配上自动脚本定期工作，但是目前还没有开始折腾。 或许等自动脚本配置好之后，我会把它移到和微服同一个房间，让它们兄弟相逢。但至少目前，让我再多养养眼也好。 # 图片生成 其实对我来说，日常的AI辅助还只是捎带的益处，我真正需要AI的地方还是绘图创作。 懒猫的算力舱内置了文生图和文生视频两个官方应用，但是由于系统是新推出的，还需要一定的完善，所以这两个应用相对还是比较简单，显然不能满足我这个深度AI艺术爱好者的需求。 但幸运的是，算力舱同时也内置了一套ComfyUI，于是这就好玩了。 虽然要使用ComfyUI还需要事先做一点技术准备，但这难不到有AI辅佐的本技术小白，基本的Linux命令还是知道几个的。 于是在AI的指导下，我开通了算力舱的SSH登录，以便把我需要的模型下载到合适的位置；并把ComfyUI的output目录挂载到了懒猫网盘。于是随时随地，甚至出门时在手机上都可以打开ComfyUI指挥算力舱干活了。  关于实测的性能，坦白来说算力舱的架构是更适合LLM推理的，绘图上并不比我的4070快；但算力舱的优点仍然远大于速度上缺点，主要是因为它——显存超大啊！ 前面也说了，由于我想要的是一台僚机，不是用来跑游戏，不需要即时的渲染，所以显存容量就成了我最需要的特点。 拿视频来说，以前在4070上充其量能跑动的是7b的wan2文生视频，想运行14b的图生视频，简直就是痴人说梦屡开屡崩。而对算力舱的64G显存来说，wan2.2的图生视频跑起来完全没有问题，开起队列来一口气能跑几十条视频用来抽卡，简直是爽到飞。 (悄悄说句题外话：我曾经也有远程借用过变总4块3090的传说级服务器用来绘图，速度上感觉没有太大差异，只不过……反正我是承受不起他那个超级巨大的机箱尺寸ƪ(˘⌣˘)ʃ) # AI应用开发+孵化 懒猫微服的应用核心都是基于Docker的，所以算力舱也是基于Docker提供AI算力的服务。而且于微服应用的机制本身就很开放很简单，所以即使对我这个已经在AI辅助下在应用商店上架了不少应用的Vibe半吊子开发者来说，上手也很容易。 算力舱为了提供语音服务功能，内置了一个文字转语音的TTS引擎，于是我只需要编写我拿手的前端，一个自己开发的好用的TTS应用就有了。  官方的文生图虽然简单，但内置的Flux引擎是开放的，于是我同样只需要编写一个前端，一个相对来说功能更多的文生图应用就诞生了。  因为想试试内置的Ollama，又是编写了一个前端，一个AI~~撩妹~~情感聊天应用又出来了。  熟悉了这种机制之后，在AI编写后端我手写前端的情况下，基本上快则两三天，慢则一周之内出一款应用，从真正意义上解放了我的创造力。 更值得期待的是，有了这些自适应各终端的前端设计流程，等把它们的体验打磨得比较完善了，我只要修改一下后端引擎，应该就可以对接其他云端或本地的AI服务，针对更广泛应户群的公众应用应该就不远了。 所以对于我来说，不担拥有了僚机，还有了一个AI应用孵化器！ # 发展空间 如果要用一个长句描述这个产品，我会说： > 懒猫AI算力舱是一个外观科幻炫酷、配置实在、做工精致、功能多样化的，能够与懒猫微服及各种终端完美配合、又能独立运行的强大的微型AI运算设备。 自然，问题肯定是也有，比如我比较在意的用户体验还需要仔细打磨，比如目前还未完善的同步能力，但毕竟是全新且完全原创的系统；也肯定有人会像喷微服那样来喷算力舱配置不够顶级之类……但至少对我个人来说，它只要能够满足目前的需求，而且更重要的是只要架构和发展路线合理，加上追求完美的研发和客服素质，这个产品就会有无限的发展空间。 按我的角度，从懒猫“私有云”的愿景角度来看，如果懒猫微服算是服务器与存储容器，算力舱就是AI工作站。 它们的组合解决了针对日常设备（尤其是移动设备）商家超过实际需求的升级速度与用户日益增长的存储需求及运算压力之间的矛盾，让用户可以用平凡廉价的终端设备使用到更高级且更方便的服务，也降低了用户对商用云服务的需求及成本。 其实，我在十多年前就预期过这样的家庭运算中心设备，幻想着每个家庭自己有一台中心电脑，然后桌面电脑、平板、手机都只是终端式的外设，成本可以很低。但当时是期望苹果或谷歌这样的商家总有一天会转向这样的开发，万万没想到是国内的一个原创小企业最先实现了它。 这种对预期的符合，也是我愿意做懒猫自甘吹的主要原因。 当然，现在回头想想，从大企业的角度，这样产品并不利于移动设备的升级和售卖，所以他们短期也不太可能这么做。毕竟如果大家都只升级家庭中心设备，对手机和电脑的需求，以及对商用云服务的需求就会降低。 可是对于最终用户的我们来说，这不正是一件好事么？ 试想你把全家升级换代手机的成本改为投资一套家用私有云，除了装逼属性有所损失，换来的却是时时处处都能安全免费且自由访问的个人资源和AI能力，不再受商业化产品的订阅捆绑，其实是一桩非常合算的买卖。

懒猫游戏首发，快来娱乐区和小伙伴组一把紧张又刺激的无名杀

 作为一款集生产力与娱乐为一身的懒猫微服怎么能少的了娱乐呢？ 无名杀作为古风游戏区开源界扛把子（笔者瞎说的），也是很荣幸的作为第一款上线懒猫微服娱乐区的“3A”（笔者瞎说的）大作上线了 。 https://appstore.lazycat.cloud/#/shop/detail/lzc.game.noname 首先就是在懒猫应用商店娱乐区将应用安装到你的盒子中，安装完成后打开游戏。  能看到无名杀有很丰富的玩法，像经典的身份，国战和对决以及挑战模式，不仅有斗地主、单挑还有非常新颖的战棋、塔防、炉石和乱斗玩法，这众多的玩法就足矣让我眼花缭乱了。  当然近 300+ 的武将也是十分震撼的，我已经沉迷于挑选三国美女中无法自拔了…  当然三国的帅哥也挺好看的，但是美女武将请让我先选，嘿嘿嘿…  不过但是，道理我都懂可是这佐藤雏是不是来错时代了…这不是三国吗，emmmmm，不过毕竟佐藤雏是神嘛，既然是神那穿越也就可以理解了对吧，我们不要拘谨于这点小细节。当然如果不需要某些武将的话在设置中是可以关闭的。  在设置中除了能够设置武将之外还能看到全部的卡牌，这里标准的三国杀卡牌都是比较全的，并且除了标准的技能和装备卡牌之外，看看我还发现了什么  对没错，居然还有古剑奇谭卡牌？？？虽然没看懂但我大受震撼。  稍等一下，让我快速击败他们然后我们看看联机模式（笔者战斗中…）。  好了好了让我们继续看看联机模式，基于懒猫微服强大的网络功能，在懒猫微服安装的无名杀会创建一个联机服务器，只要我们在懒猫微服的客户端里邀请好友加入盒子，就能和好友一起组队联机痛快的杀一把无名杀了，并且支持跨平台（支持 Android、IOS、Windows、MacOS、Linux 同时在线）一起畅快游玩嗷。  打开联机模式后就可以创建一个房间，等待好友连接到你的懒猫微服后打开游戏（游戏是安装在盒子里的，好友可以直接在线游玩）然后进入联机模式就能看到你创建的房间了，点击进入你的房间，然后你（房主）就可以开始游戏了。  随后就是与好友痛快的厮杀一场了。 写了这么久，都看到最后了。大家是不是应该给天真一个点赞收藏评论一键三连呢？同时也记得给开发者一个五星好评支持一下嗷，有问题也可以在懒猫应用商店反馈给开发者，开发者也会及时修复处理并提交修复给上游促进游戏可持续发展。 最后感谢无名杀开发者和开发社区的贡献，感谢他们给我们带来如此好玩的游戏。同时感谢移植的开发者小伙伴们，帮助我们实现游戏部署安装做出的适配工作。 版权声明：文章由作者原创未经许可禁止转载，文章中的部分素材来自互联网，如有侵权请联系作者进行删除。无名杀基于 GPL-3.0 license 开源版权归原作者所有，源代码地址 <https://github.com/libccy/noname>，移植 Fork 版本源代码地址：<https://gitee.com/runui/lzc-game-noname>

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喂食”这同一结果。 既然未来可能无法避免，为何不早些训练自己的喂食技能呢？

深度长文：NAS大降价的年代，我为何接受溢价来购买懒猫微服（附送回本攻略）

最早知道懒猫微服，是去年的时候，那个时候最直观的感觉就是价格比同类型产品要贵一些，但是很极客风，不过硬件配置比传统NAS要高出很多。但在现在各种小主机盛行的年代，这台机器就显得性价比不高，甚至有些人认为有割韭菜的嫌疑。 今年朋友又过来推荐，说是售后很好，可以根据自己的需求来答疑，比如把三方监控放在存在NAS里，比如想用私服搭建游戏服务器等等，而网上不管怎么样，还有说情绪价值一定给拉满的。  第一次咨询的时候，是和CEO通了个电话，抱着将新将疑的态度购买回来，拆箱，测评。相信其实很多人即使没听过王勇，也一定听过或者用过Deepin。大学的时候使用过一段时间的deepin，很多细节确实符合国人的使用习惯。这个背书对于技术人来说，实在是一下子路转粉。想想自己在电话里还跟对方说，其实专业的技术人员，不用和我说这么直白的词，再想想王总在Deepin以及Emacs方面的贡献， 实在是有些惭愧。  我本身是开发者，问题是技术细节相关的，比如为何这个实现和群晖类不一样，对某处设计比较反常识的地方询问和拆解，总的来说，像是上了侠客岛一样，平时自认为是开发人员里面最懂Infra的，结果到这里谁的Linux都比我玩的好。  目前重度使用了一周多，每天都会在VIP群里问问题。主要把维护的问题解决出来，好像附送了一个终身的云厂商支持一样。从他们的宣传来看，7 * 18的支持显得更加实在一些，服务相比海底捞有过之无不及。我本身用过不少7 * 24小时支持的云厂商，要么低峰时候找不到人，而24小时支持又何尝不是对技术从业者的压榨呢？比如随时on-call，倒班机制是我本人深恶痛绝的，有些厂家号称是7 * 24 小时支持，但是经常已读乱回要么不回，或者干脆说这个问题和他们产品的交叉是涉及第三方，然后索性不管了。有意思的是，当使用两个公司交叉的业务时，都要让我去找对方。但是在懒猫这里就不会发生这样的问题，之前用的商店里的dify有问题，他们去找移植应用的人去修改了。  还有一个卖点，是硬件终身售后，甚至包括磁盘和后续的数据恢复（前提是不加密），有些推吞吐量高要求的情况甚至可以做 Raid0，然后外接 NAS 或者硬盘仓备份，所以这不是一款后端存储的产品，而是放在存储和用户之间的加速器，作为家庭的边缘算力，前面接 MBP 后面接存储池这样子。 商店目前上架了 1000+的应用，虽然官方的应用不多，但是很多三方应用都是他们的开发人员移植的，于是后来才有了越来越多的开发者也跟着移植的过程，在移植的过程中，可以学 docker-compose 的用法，以及跨架构打包 docker image ，还有单点登录的集成。这些都是我的兴趣点，而且也想学一学里面设计的机制，大学毕业的时候我想设计一款 NAS，那也仅仅是基于 centos 做了一些改动，后来买了威联通，虽然不常开案例问问题，但问的也仅仅是关于这个产品本身的东西，包括专业程度和响应级别都不是能够一概而论的。甚至连 trouble shooting 上传日志都很方便。  全容器化的服务以及对操作系统的修改，可以看出沿袭了当年在 deepin 的风骨。包括应用商店在内，很多系统组件都完全采用用容器托管。还有自己的单点登录系统，而对于 OIDC 的支持其实很多企业都没有做到。还有一点不得不提的，开发者的社区很活跃（主要指的是微信群和上架应用商店），每天都会有几位开发人员默默的上架应用和攻略。慢慢的我也熟悉了把 docker images 转换成为懒猫商店的模式。也上架了自己的几个应用，有原创的，也有把喜欢的开源项目移植过来。  最喜欢的原生应用是网盘和清单，首先说网盘曾经有一篇为什么没有人去做网盘的帖子，讲述了网盘研发成本高，就连曾经宣称用不限速的阿里云盘也变节了。改善 NAS 生态是刀山火海、暗礁遍布，却仍要做那一股清流；研发与售后成本明摆在前，却仍坚持全线自研，把服务做到极致。清单有种小清新的感觉，极简风格，日常记录一些 todo，主要同步之后多平台编辑实在很舒服。打破了关于以前产品自带的软件都很烂的固有观念。  想起来《琅琊榜》中的一句话拿来形容创始人，“如此愚蠢，却又如此有胆识的人，已经很久没见到了。” 我一直相信技术是服务生活的，但慢慢的变成了炫技以及慢慢变成了改需求以及最后变成了漫长的牛马生涯，在学生时代一直有一个远景，做一款全平台的软件自己用，后来发现学习成本巨大，而且也没有资金外包出去，虽然这几年接触了flutter，但也没有构建一个全新的跨平台产品出来。 有了懒猫微服之后，这一切都解决了，只需要打包好 docker image，如果可以的话就上架商店给其他人用。用公网访问，TLS 证书卸载这些都一步搞定。当我们默默的喷绿联，极空间丢数据，群晖如何守旧不肯升级CPU，以及限制磁盘认证的问题。曾经我们还忽略了这样一款从操作系统，软件生态，甚至应用商店。这款机器比我之前 DIY 构想的还要完善，完美。 我想去拆解他的技术细节。但是不想再出来一个商业竞品来扰乱这份宁静。在我看来这是一款充满着技术者热情和情怀的产品。 **附送：懒猫微服社区激励机制一览** | 贡献类别 | 具体动作 | 奖励金额 | 备注条件 | | ------------------------------- | -------------------------------------------- | ------------- | ------------------------------------------------------------ | | **应用移植** | 成功将一款高质量的自托管应用移植并上架商店 | **100 元/款** | - 必须功能正常- 开源应用需标注上游作者- 若多人移植同一应用，仅首位上架者得奖 | | **对接账户系统 / 网盘右键菜单** | 在移植基础上完成接口对接 | **+50 元/款** | - 自己移植并对接：共 **150 元/款**- Fork 他人应用并补充对接：**50 元/款** | | **应用攻略编写** | 发布含截图且经验证可行的攻略，并关联商店应用 | **50 元/篇** | 鼓励分享使用经验，惠及社区 | | **不予奖励的应用类型** | 纯网页游戏、离线 Web App、纯数据库软件等 | —— | 可自由上传，但暂无红包激励 | > **核心要点** > > 1. **先到先得**：同款应用仅首位合规上架者获奖。 > 2. **质量至上**：功能正常、信息完整方可审核通过。 > 3. **额外加成**：完成账户系统/右键菜单对接可叠加奖励。 > 4. **知识共享**：高质量攻略同样有奖，鼓励经验传播。 社区激励机制：https://developer.lazycat.cloud/store-rule.html 懒猫打金服：https://playground.lazycat.cloud/#/guideline/448

写给小白的移植指南(一)：如何移植网站应用到懒猫，爆金币

和懒猫的结缘，是我在X上闲逛时，无意中刷到了王总的信息流。 于是翻着他的blog，一篇篇刷下去，很吸引人，尤其是通宵敲代码的那些经历，让我共鸣了。 于是参加抽奖活动，居然中了个充电器。 在大佬坚持不懈的安利下，我在5.18买了个猫。 他说移植一个应用，奖励100元，如果是原创应用，奖励更多。 经过一个多月的努力，终于让我薅回来了。 今天复盘一下移植app的经历，希望对大家有帮助。 ## 先说说我的痛点 - 我完全不知道什么是docker - 甚至都没写过命令行代码 - 不知道咋移植 - 无从下手 - 不知道从哪里找应用 ## 迈开第一步 既然不知道如何移植，最快的办法，就是看其他大佬怎么移植的。 我在懒猫商店发现了这么一个应用： https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.game2048 注意到它，是因为我之前玩过1024的游戏，跟他这个差不多。 于是跟着这个应用详情，我来到了github的地址。  在github上可以看到，这是一个静态网站，也没有什么docker镜像之类的东西。  于是我跑去VIP群（每个懒猫用户都有一个VIP群），问这种东西咋移植。 很快有人回复：可以参考它的lpk文件。但是需要进ssh，写代码，我一阵头大。 后来，我发现了大佬开发的这个应用： https://appstore.lazycat.cloud/#/shop/detail/top.j0k3r.lpk-inspector 真是福音啊，进去搜2048，  直接点进去，就能看到它的配置，真是太方便了。  ### **看配置** 从上面可以看到，每个lpk应用，都有3个文件。 icon.png 是应用图标， manifest.yml 里面是主要的配置。 content.tar 里面是网站发布后的一些文件。 具体字段就不阐述了，可以去看官方文档： https://developer.lazycat.cloud/ ### **开始移植** 到了这一步，相信很多程序员就可以自己操作了。 我打开VSCode，下载下来代码，编译网站，按照要求准备好这3个文件，打包成lpk，安装到懒猫。 这些步骤基本没有什么卡点，我就不废话了。 ### **注意事项** 对于简单的html应用、游戏，官方可以上架，但没有激励，毕竟这种应用太多了，可以理解。 ## 最后想说的 我在没移植之前，觉得太难了。 等移植完第一个app，内心成就感爆棚：原来我也可以！ 当然，除了这种静态网站应用，还有很多其他类型的应用，我会在后续文章中分享如何移植。 如果你也想移植应用，爆金币，不妨从2048开始，这种是最简单的。

大佬原创应用：九匠音乐使用体验

## 🤔 介绍 懒猫商店已经有很多音乐播放器，但体验下来，这款是目前最干净、简洁的。 这是社区大佬@halo_芒鸽 的原创应用，官方对于原创有奖励，好羡慕。 https://appstore.lazycat.cloud/#/shop/detail/mcloud.mg.app.jjmusic  在夜间模式下，有些按钮是看不清了，为了方便演示，我还是切回日间模式。 ## ✨ 特色功能 ### **导入音乐** 打开之后，界面非常清爽，你需要在右上角的设置，导入音乐。  选择懒猫网盘里，你存放音乐的文件夹，我只有几十首歌曲，扫描很快。 封面图我选择均显示，页面会好看些。 ### 创建歌单 在左侧可以创建歌单，标题还支持表情符号，建完排序就挺有意思的。  在歌曲右侧的3个点，可以把歌曲添加到歌单里。  音乐播放很简单，点击暂停，再次点击播放。 ## 💡 实际使用体验分享 我自己用了，真实感受如下： ### 优点满满： - ✅ **启动超快**：2几秒钟就能启动 - ✅ **界面清爽**：没有花里胡哨的装饰，专注功能本身 ### 小缺点也要说： - ❗ **功能还在扩展**：相比一些老牌工具网站，功能还不够全面 - ❗ **界面较简洁**：有些人可能觉得不够炫酷 移动端的体验还不太好，但大佬响应速度很快，新的功能还在持续迭代。 ## 🎉 总结 对于专注简洁，这个播放器绝对值得一试！ 虽然它可能不是最功能最全面的工具，但它的优势在于：**简单、纯净、实用**。 希望原创应用发展的越来越好。

TalkFlow使用初体验：去中心化的聊天工具

## 这是什么？ TalkFlow是社区大佬的一个原创应用，我们看下应用描述： 100%纯血去中心化分布式通信工具，完美适配懒猫微服硬件平台，通过懒猫微服可靠的网络穿透能力进一步提升稳定性。端到端加密聊天和群聊，军用级加密标准，内置安全模块已被应用于荷兰海军物联网设施和美国CIA通信工具等其他真实场景。独立密钥对卡包，加密状态一切清晰可见，只有你自己配置的密钥对和构建的证书可以解密数据。可与本地AI通过中继和内置SEA模块进行安全的远程通信，其中包括自然语言物联网控制器，与懒猫微服算力仓兼容。一切开源，可审计，TalkFlow非营利性项目工作组免费提供全天24小时技术和安全援助. 一句话简单概括：这是个看起来很牛X的加密聊天工具。 https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.ponzs-talkflow ## 核心功能使用 ### 1. 安装注册 打开应用，它的颜值很高，注意你要点击一下，才能进功能  初次进入时，会有个key，要记得保存在本地，只会出现1次，以后就再也看不到了。  进入之后，默认是聊天页面，是空白的，只有别人给你发消息，才会在首页看到  ### 2. 添加好友 点击左侧联系人，在右上方可以添加好友  这里可以输入对方的key，或者下方的按钮扫码  自己的二维码，可以在这里看：点击头像，右侧有二维码  在电脑端不好扫码，在手机端可以用相机，同时它也有客户端  如果想用同一个账号登录，就要用的第1步保存的key了。 对方同意后，就可以在联系人看到了  不过目前我试的消息会有一些延迟，因为节点在美国。 ### 3. ai对话 左侧的位置，集成了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打金计划(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)的个人信息页中点一下“关注”🫶。