科幻感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能力，不再受商业化产品的订阅捆绑，其实是一桩非常合算的买卖。

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

懒猫微服的可玩性在于可以让开发人员放开手脚来做一些事情，等于是提供了一个可靠的基础设施。那么理所当然我们可以把开源的知识应用到上面，比如开发或者移植应用，或者干脆部署一些好玩的东西。这在传统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 云主机，你可以在上面尽情发挥创意与技术。 

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

 作为一款集生产力与娱乐为一身的懒猫微服怎么能少的了娱乐呢？ 无名杀作为古风游戏区开源界扛把子（笔者瞎说的），也是很荣幸的作为第一款上线懒猫微服娱乐区的“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>

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

## 🤔 介绍 懒猫商店已经有很多音乐播放器，但体验下来，这款是目前最干净、简洁的。 这是社区大佬@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打金计划(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打金计划(8)：24小时开发原创应用?!

### 成功了! Vibe打金计划的第一个作品终于打包1.0.0提交审核了，运气好的话应该能与本文同时上线。 由于本标题党的作风一贯实诚，这里还是要特别说明一下：说是24小时，就是真的24小时。只不过实际跨度约为不到三天，因为要除去吃饭睡觉去超市以及陪娃和摸鱼的时间，是指坐下工作的时间加起来应该大约在24个小时以内。 （以后的开发中我会试着缩短这个时间。） 当然这24小时中也还不包括预先研究的时间，《Vibe打金计划》系列大约开始于两周前，而这个项目大约也是在一周前就开始研究了。只不过如同我在之前说过，原本是打算用MySQL服务的，由于各种原因，中间除了研究MySQL又研究了minidb和file-pickers两个懒猫官方插件，所以绕了点弯路多花了些时间。 如果你对《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) --- 正式重启这个应用的开发大约刚好是三天前的现在写攻略的这个时间。 # Milka！ 应用名称为《喵卡 Milka》，是一款记忆卡片的小应用。 稍后我会试着编辑文章并加入应用的链接，现在先讲述一下我用这24小时（工作时间）人工构思、指挥以及几乎完全依靠AI开发这个应用的完整过程。 整个过程使用Refly及Claude sonnet 4组织提示和编写代码，大约只手动修改了很少的部分（却花了不少时间）。 https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly --- # 整理需求 在[《Vibe打金计划(3)：一二三，分步走》](https://lazycat.cloud/playground/guideline/806)中，其实我已经写了关于这个应用的基本需求生成过程，当时它的代码也已经写好了大半，但由于始终觉得MySQL启动有点慢（也可能是我机器的问题），最终决定换用官方插件minidb，完全推倒重写这个应用。 最终的Refly画布大约是这个样子的，但是只有绿色的三组节点是整个开发过程，其中红色区是之前第一步MySQL版的内容，紫色区是minidb研究，蓝色区是file-pickers研究。  于是我在绿色区的开头引用了红色区的旧对话记录，以便尽可能的利用AI现有的记忆，然后导入了minidb和file-pickers导出的文档，写了如下的注释： >我准备完全重构这个项目，从零开始架构。但要去掉使用MySQL的镜象部分，改用懒猫官方提供的minidb插件，并使用lzc-file-pickers插件管理更新数据和增加数据包的操作，先不要编码，请先根据以上情况修改需求文档，需包含上述两个插件的简述，以及一个分步式开发的计划。等我确定需求文档的内容之后才会需要正式编码。 AI给我的第一个方案并不理想，包括把file-pickers的植入放在了太前会占用较多开发时间，另外开发计划是沿用（预测）了传统开发的惯例时长，分了五步计划，总共计划了最多11周的开发时间！**（但从另一个角度看，我是不是用vibe节省了近三个月的时间？）** ## 调整需求 于是我决定第一期先不用从网盘选择文件，先弃用file-pickers的植入。 >文件选择器的插入并不急切，因为保存的部分还是在数据库，导出为数据包也用传统方式下载到本地即可实现。所以从网盘中选择文件并升级数据包是后面的事情，可以放在较后执行。 另外全程将使用AI编程，所以期望可以在很快的时间内开发完成，计划中的时间天数没有什么用。 步骤尽量控制在三步左右。 从上一次开发得出经验，其实需求和开发计划还是相当重要的，尤其是在Refly中，AI可以全程（基本）遵守需求和计划进行开发。如果你有比我更多的开发规则经验，应该可以用更好的需求和计划指导AI进行更有效的开发。 所以我在这之后又调整了一些细节，包括整理及精简项目结构和修改配置文件，以求在开始时更好地限制和指导AI。 --- # 正式编码 计划基本满意之后，由于有详细文档的导入，我只需要一个简单的命令就可以让它开始开发了： >现在编写生成全部位于app下的文件的代码，基于第一期计划 所以虽然它在最初的计划中第一期的时间写了“1-3周”，但实际上AI只在一个交互回合中用了20-30秒就给我把大致的框架写出来了，包括每一个必要文件的完整代码。 总共9个文件，我没有仔细统计有多少行，总之可以看一下滚屏效果： https://lzc-playground-1301583638.cos.ap-chengdu.myqcloud.com/guidelines/319/1f5ac988-64ac-4cfb-ae4f-653624598271.mp4 -  以上代码只包含了很少的错误，其中包括AI常出现的写出来的代码有被打断导致语法错误的情况，这时只需要让它重新提供单个文件就行了。 ## 关于Service Workers 不过另外有一个问题是AI自动加入了Service Workers机制，这玩意让我有点头痛。可能是我不会用，也可能是因为SW太过强大了。它直接在浏览器中生成缓存，并用缓存去截断真实路由，所以一旦处理不好尤其是如果AI失忆或犯神经导致没有注销或更新记录，这个页面就会一直刷新不到修改的内容，在调试时非常麻烦。 在浏览器中还可以从开发者工具中绕过它，再清不干净可以新开一个窗口。可是在懒猫应用中，据我的猜测似乎每个应用对应的就只是一个窗体，缓存很可能是保存在本地系统对应这个窗体ID的记录里，也找不到地方清理这个缓存，要么就要写专门代码清空所有SW缓存（或许还清不干净），要么只能修改项目包id启动新的窗体才能刷到新的版本。 对大神们这可能很简单，但以我小白水平来说，我不想折腾那么多，而且懒猫基本上四舍五入算是本地(至少大多数情况下是本局域网)应用，对缓存没那么大要求，这个应用又没有太多的数据流，所以实在没必要搞这玩意。于是我在提示中严格强调了不允许使用SW。 --- # 第二期开发 除了上述的两个问题，我大约只和AI进行了三四轮有效问答回合（有效是指刨除我为了发现问题问的关于SW的几个支线问题），就把一个可用的Demo给架好了。 抱歉我对整个开发中间环节的界面都没有截图，但说实话界面基本70%符合我的要求，于是我打算让它进行下一步的开发。但是首先要确定，它是否还能记住开发计划： >目前一切功能正常，请先确认下一步的开发计划 ## 调整计划 & 美化界面 但是很明显AI又想太多了，我发现计划不太符合我的要求，于是临时修改计划（从后果看也许并不是个好的决定） >这个规划有点太长了，首先去掉社区功能。数据导入和导出，以及从网盘选择文件也先延后。这一步首先完善界面，让它基本可用，将创建主题和卡片的体验从系统对话框改为页面表单。优化体验让卡片有3D翻转的效果。请给我更新的计划。 又是用了几十秒增加了新的功能，第二期的“几周”时间又节省出来了。其实最基本的功能已经都运行正常了，于是我开始优化界面： >现在让我们做一些页面美化，首先目前的卡片显示还有一些问题，当卡片翻转时，反面没有显示卡片的背面，而是显示了水平镜面翻转的正面，可能是层次样式的问题，需要解决。然后，整个页面改为一体化，不分页头和主题，而是统一的一个浅灰色纯色背景。所有的字体用细体，不要用加粗。LOGO从现在的emoji改为assets/logo.png，限制大小为60x60px。不需要面包屑导航，不需要卡片左下方的编号显示。 ## 嘿，记得这个icon吗？  我在[《边画边体验：用SVG-Edit绘制应用图标》](https://lazycat.cloud/playground/guideline/818)中，也是使用了懒猫中的应用SVG-Edit用矢量绘制了它。 https://appstore.lazycat.cloud/#/shop/detail/cloud.lazycat.app.svgedit 由于它的中间有一个代表卡片的空白空间，我直接把导航第二层页面中的返回按钮加在了上面，如果需要返回到首页，猫的“嘴”中会显示一个返回箭头的图标。  --- # 喵卡功能说明 至此，随着界面的优化，加上一些细节的调试和修改，一个应用的雏形其实已经基本搭好了。 首先，在喵卡应用中，你可以创建无限个“主题”，至于什么主题完全由你来定。  最张见的不外乎是背英语单词，但除此之外的各种语言或其他知识，比如数学公式、历史事件、科学概念……各种知识可能都需要用记忆闪卡来强化记忆。 然后每个主题中你又可以建立多张卡片。  每张卡片都有正反两面，其实是一样的数据结构，用关联表把它们互相以及和主题联系起来。正面和反面都包含主体内容和备注两个主要字段（但显示有区别）。 你可以根据需要填写卡片内容，比如英文单词就可以在主体中分别填写中英文单词，以及助记提示和详细解释；比如历史就可以正面写简单事实，背面写时间和详情。 这样你在使用的时候会先看到正面的提示信息，在心中默记之后，点击将卡片翻过来，查看和对比背面的答案内容。 它目前有列表和幻灯片两种显示模式，适合不同的学习习惯和场景。同时也有“太空白”和“星辰灰”（是的我故意的）两种风格可以切换。   这个应用对于和小朋友做学习游戏互动来说也会很有用处，就像听写一样，可以让小朋友根据正面的提示说出或写下答案，再与背面的答案对照。 甚至多人进行趣味问答，或团队性质的脑筋急转弯或百科知识抢答赛，也是很有创意的玩法。 --- 好了，以上的过程已经比较完整地展现了我在Vibe编码的过程的主要要点和心得。如果你要开发一款与这相当或比这更简洁的应用，相信可以从中参考经验，希望能找到合适的方法以更快得到结果。 但同时，以上也只是喵卡应用开发的“顺畅”部分，时间其实只用了全部24小时中的15-16个小时。在后续的攻略中我会继续展开写一些“不顺畅”的部分，包括手动调整代码以及怎样与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

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是一个可以随时更改输入再次运行的工作流应用，所以如果在实用中发现问题我也可以在这个提示词画布中再做修改，然后迭代回系统提示词。 各位技术大佬或官方大佬如果发现以上提示有什么错误或不妥，也还请在评论中指导。

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

和懒猫的结缘，是我在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开始，这种是最简单的。