之前写过一篇《懒猫微服开发篇（零）：上架应用需要哪些知识》，里面列了 NPM、Linux、Docker、HTTP，后面做登录还会遇到 OIDC。

那个时候的结论是：如果你只是移植现成的开源软件，开发能力可以弱一点，但是 Docker Compose 总得会一点吧，端口、环境变量、目录映射这些东西也得看得懂。

这话没有错，就是普通用户看完可能已经被劝退了。

最近官方制作了一个项目：Lazycat Skills，也是，我之前的答案可能要改一改了。

不会写代码，也可以给懒猫贡献软件。

当然，这里的不会代码，不是说对着 AI 喊一句“给我写个软件”，然后喝杯茶回来就能上架。更现实的玩法是：找一个已经能运行的开源项目，让 AI 帮你看 Docker 配置、写懒猫的 LPK 文件、执行打包命令，再根据日志一点点修改。

说白了，AI 帮你干开发和运维的活，你负责提需求和验收。

Lazycat Skills 是干什么的？

现在的 AI 会写 Python、JavaScript，也会写 Docker Compose，但是它不一定知道懒猫微服最新的应用规范。

我以前让 AI 写配置的时候也遇到过类似问题。它看起来什么都会，YAML 写得整整齐齐，字段也挺像那么回事，结果一打包就报错。继续问，它再换一种写法，最后可能把新旧版本的配置混到了一起。

Lazycat Skills 相当于给 AI 准备了一套懒猫开发手册。

仓库里和普通应用移植关系比较大的有：

  • lazycat-developer-expert：负责判断这是打包、路由、认证还是上架问题。
  • lazycat-lpk-builder：把 Docker 镜像、Docker Compose 或源码转换成 LPK。
  • lazycat-dynamic-deploy：处理安装应用时需要用户填写的参数。
  • lazycat-advanced-routing：处理路径转发、二级域名和 TCP/UDP 端口。
  • lazycat-auth-integration：处理 OIDC 登录和用户身份。

AI 遇到打包问题就去看打包文档，遇到 OIDC 再去看认证文档，不用一次把所有资料都塞进上下文。这个设计和我们查手册也差不多，用到什么再看什么。

安装方式也很简单，在项目目录执行：

1
npx skills add whoamihappyhacking/lazycat-skills

或者你干脆把GitHub链接扔给AI，然后就可以对它说：

1
2
3
帮我把当前的 Docker 项目打包成懒猫微服 LPK 应用。
请先读取 Lazycat Skills，再检查端口、环境变量、
持久化目录、权限和 CPU 架构，最后生成 LPK V2 配置。

这个 Skill 不是替你开发一个软件，而是让 AI 更懂懒猫。

以前的教程还能看吗？

可以看，但是需要注意版本。

我之前写懒猫全栈上架指南时，主要讲的是 lzc-build.yml、lzc-manifest.yml 和应用图标。现在仓库的 main 和 v2 分支已经按照 LPK V2 编写，应用元数据和运行配置被拆开了：

  • package.yml：应用名称、版本、作者、多语言和权限。
  • lzc-manifest.yml：容器、路由、环境变量和数据目录。
  • lzc-build.yml：正式版本如何构建和打包。
  • lzc-build.dev.yml：开发调试时的覆盖配置，可选。

以前文章里的 Docker、路由和数据持久化思路没有过时，但是具体字段应该以新版 Skill 和文档为准。

有意思的是，这正是 AI Skill 适合做的事情。人很容易搜到一篇旧文章照着抄，AI 也一样。现在直接把当前规范装进项目里，至少不会上来就拿旧版 Manifest 硬套。

最适合普通人的方式：搬一个 Docker 应用

第一次做应用，不建议让 AI 从零写网盘、相册或者密码管理器。这类软件看起来很常见，实际上涉及账号、权限、数据库、文件上传和数据迁移，后面全是坑。

最简单的方式是找一个自己已经使用过的开源项目，而且最好已经提供 Docker 镜像或者 docker-compose.yml。

比如项目文档里有这样的内容：

1
2
3
4
5
6
7
8
9
services:
  app:
    image: example/app:latest
    ports:
      - "8080:8080"
    environment:
      - TZ=Asia/Shanghai
    volumes:
      - ./data:/app/data

以前我们需要自己分析：

  • 8080 是应用端口。
  • TZ 是环境变量。
  • /app/data 需要持久化。
  • example/app:latest 是需要复制到懒猫镜像仓库的镜像。

现在这些工作可以先交给 AI。它会读取 Compose，再生成懒猫对应的服务、路由、权限和存储配置。

LPK 的 Manifest 和 Docker Compose 本来就有不少相似之处，所以 Docker 应用移植是最容易成功的路线。

第一次选项目，我建议满足下面几个条件：

  1. 已经有公开可用的 Docker 镜像。
  2. 最好只有一个容器，最多再带一个数据库。
  3. 有 Web 界面，打开浏览器就能使用。
  4. 文档里写清楚了端口、环境变量和数据目录。
  5. 不依赖 GPU、USB、宿主机网络和特殊硬件。
  6. 有明确的开源许可证，允许重新分发。
  7. 确实有人会用，而不是单纯为了上架凑数量。

懒猫商店需要的还是应用场景。数据库、开发库和只有程序员才会使用的中间件，原则上并不适合当作第一个上架项目。

纯前端项目更简单

如果连 Docker 都觉得麻烦，还可以先找一个纯前端项目。

我以前移植过纸砚双拼，这种 Vue、React 写的工具，构建完成后基本就是 HTML、JavaScript、CSS 和图片。懒猫可以直接托管静态文件，不需要数据库，也没有数据持久化的问题。

计算器、文本处理、格式转换、小游戏、学习工具，这些都很适合拿来练手。

大致流程就是：

  1. AI 读取源码，确认使用什么命令构建。
  2. 执行 npm install 和 npm run build。
  3. 找到生成的 dist 或 build 目录。
  4. 写 LPK V2 配置，把根路由指向静态文件。
  5. 打包后安装到自己的微服测试。

这类项目甚至不一定需要自己做 Docker 镜像。

不会代码，也可以做原创应用

再往前一步，就可以让 AI 根据自己的需求写一个小工具。

我之前用 Amazon Q 写过一个 Docker 客户端 Containly，后来也上架了懒猫商店。它的起点很简单：群晖里的容器多了以后，我记不住每个服务的端口，每次登录 Container Manager 又比较麻烦，所以想要一个简洁的面板，能看容器状态、URL、日志，也能做启动和停止。

Containly 容器管理界面

最早用 GPT 写，项目大了之后，它经常忘记之前改过什么。后来换成可以直接操作本地目录的 Amazon Q，体验就好很多。现在 Claude、Codex 这一类工具也能直接读取文件、修改工程、运行命令和查看报错。

所以不会写代码并不代表做不了软件。很多时候，能把自己的问题说清楚，比上来就讨论用 React 还是 Vue 更重要。

比如可以直接告诉 AI：

1
2
3
4
5
6
7
我想做一个运行在懒猫微服上的网页工具。
它用来记录家里的设备、IP 地址和管理页面，
支持搜索、分类和导出，不需要注册账号。

请先给出最小可用版本，不要一次加入太多功能。
项目可以本地运行后，再读取 Lazycat Skills，
生成 LPK V2 配置并部署到测试设备。

不要第一次就让 AI 做十几个功能。先把最小版本跑起来，再一点点加。这个和正常开发没有区别，只不过以前是程序员敲代码，现在是你和 AI 结对。

实际怎么开始？

首先还是安装懒猫的命令行工具：

1
npm install -g @lazycatcloud/lzc-cli

然后在准备移植的项目目录安装 Skill：

1
npx skills add whoamihappyhacking/lazycat-skills

我建议第一轮不要让 AI 直接修改文件，先让它做检查：

1
2
3
4
5
6
7
8
9
10
11
12
我不会写代码，想把这个项目移植到懒猫微服。

请先不要修改文件，检查以下内容：
1. 项目使用什么开源许可证；
2. Docker 镜像是否公开可下载；
3. 支持 amd64 还是 arm64；
4. 应用端口、环境变量和持久化目录；
5. 是否需要访问互联网、局域网或用户文稿；
6. 是否适合提交到懒猫应用商店。

检查完成后，再按照 Lazycat Skills 的 LPK V2 规范生成文件。
每次执行命令前，用中文告诉我这条命令是干什么的。

代码看不懂不要紧，命令看不懂也可以继续问。最重要的是报错不要只截最后一行，更不要只告诉 AI“不能用”。把完整日志交给它，说明自己点了什么、原本想看到什么、最后出现了什么，排查会快很多。

打包和安装使用：

1
2
lzc-cli project build -o release.lpk
lzc-cli app install release.lpk

能够生成 LPK，只能说明配置通过了打包检查，还不能说明应用真的能用。

最容易踩的几个坑

第一个是数据持久化。

很多应用第一次安装可以正常打开，写数据也没问题，结果重启或者升级之后全部没了。因为数据写在容器内部，没有映射到 /lzcapp/var 或 LPK V2 对应的文稿目录。

所以测试的时候不要只看首页能不能打开。先创建几条数据，重启应用，再升级一个版本看看数据还在不在。

第二个是镜像。

自己电脑上能拉取，不代表商店审核时也能拉取。正式上架前，需要把公网可访问的镜像复制到懒猫官方仓库：

1
lzc-cli appstore copy-image <镜像名称>

复制完成后，再把返回的 registry.lazycat.cloud/... 地址写进 lzc-manifest.yml。

第三个是架构。

有些镜像只有 amd64，有些只有 arm64。在 M 芯片电脑上构建成功，也不代表放到另一种架构的微服上就能运行。这个问题我以前移植镜像时也踩过，所以第一轮就让 AI 检查镜像清单，省得最后再返工。

第四个是默认密码和权限。

示例里的密码只能拿来测试，不能原样上架。应用需要联网、访问局域网、读取文稿或者使用 GPU，也应该在 package.yml 中声明对应权限，而不是一股脑把权限全部打开。

第五个是 AI 一本正经地写错。

Skill 能减少错误，但不能保证项目一定成功。第三方镜像的启动方式、文件权限、健康检查、Host 校验都可能有自己的脾气。遇到问题继续看日志，实在不行就在社区里问，不要和一个错误配置死磕。

上架之前还要做什么？

正式上架需要注册懒猫开发者，准备应用名称、介绍、图标、截图、使用须知和多语言信息。

然后构建并提交：

1
2
lzc-cli project build
lzc-cli appstore publish ./your-app.lpk

商店审核不是只看能不能打开，还会看应用有没有真实场景、依赖是否能下载、启动是否正常，以及重启和升级以后会不会丢数据。

我觉得普通用户反而很适合做这一部分。程序员可能觉得服务返回 HTTP 200 就算完成了，普通用户会在意按钮好不好找、手机上能不能点、第一次打开知不知道密码在哪里、报错能不能看懂。

软件并不是代码写完就结束了。能安装、能使用、能升级、数据不丢，才算一个完整的软件。

贡献的不只有代码

如果实在不想碰终端，也一样可以给懒猫生态做贡献：

  • 找到值得移植的开源项目。
  • 帮开发者测试安装和升级。
  • 补充官方WIKI提PR补充使用教程。
  • 把问题整理成可以复现的步骤。
  • 帮忙维护应用版本和用户反馈。

懒猫商店里的应用越来越多，靠的不只是会写代码的人，也需要愿意折腾、愿意测试、愿意把过程记录下来的人。

就像我之前写懒猫教程一样，很多内容并不是坐在那里背文档背出来的，而是自己遇到问题，问技术、看日志、试几遍，最后把操作记录下来。下一位遇到相同问题的人，就不用再从头踩坑了。

总结

所以，不会代码，可以给懒猫贡献软件吗？

可以。

最简单的是移植一个已经提供 Docker 镜像的开源应用，再简单一点可以从纯前端工具开始。有了本地 AI 编程工具和 Lazycat Skills，写 LPK 配置、执行命令、分析日志这些事情，已经不一定需要自己从头学会。

但是不会代码不等于什么都不用管。

你至少要知道自己为什么要做这个应用，打开以后应该是什么样子，哪些数据不能丢，以及出了问题怎么完整地告诉 AI。

我一直觉得技术不应该只是程序员的专属技能。普通用户图方便，专业用户图折腾，中间缺的无非是一套好用的工具和一份能看懂的文档。

现在工具已经有了，可以先找一个自己真正想用的软件，把项目链接交给 AI，然后告诉它：

先别急着写代码，帮我看看这个软件能不能移植到懒猫微服。

这就算迈出第一步了。