在 Android 上使用 OpenMinis（下文简称 Minis） 维护博客，不只是让 AI 生成一段文字，还涉及源码存储、文件编辑、环境检查和 GitHub 提交发布。
这篇文章记录我的具体使用方式：文件放在哪里，AI 和手机编辑器如何配合，新开会话后怎么接着做，以及提交发布前需要完成哪些检查和确认。
目标是把日常写作和维护整理成一套清楚、可检查、可恢复的流程。
本文以我的 Android 环境为例。挂载名称、手机目录和项目名都是我自己的配置，不是所有 Minis 用户的默认设置。iOS 等平台的底层实现也不完全相同。
一、我打算怎么用 Minis
我把 Minis 当作一个能实际操作文件的 AI 助手，而不只是聊天窗口。
在这套流程中，我可以让它：
- 根据我提供的经历和资料整理文章，保存成 Markdown 文件。
- 修改博客的配置、样式和主题代码。
- 检查图片路径、文章链接、Git 差异和仓库状态。
- 在开发环境具备条件时，运行构建和本地预览。
- 在我审核并明确确认后，提交代码、推送 GitHub，再检查发布结果。
我负责决定写什么、内容是否准确，以及什么时候可以发布。AI 负责执行和检查，但不能替我决定“这篇应该上线了”。
还有一个容易误会的地方：命令在手机里运行，不代表 AI 模型一定在手机里运行。 如果连接的是云端模型，发给模型的提示、文件片段和工具结果仍可能经由网络处理，因此不能随便把凭据或不该外传的内容交给它。
二、手机里的 Linux 和电脑有什么不同
我当前使用的是 Android 上的 Alpine Linux + PRoot 环境，架构是 aarch64。
它可以运行 Git、Python、SSH 等命令，但不是一台独立虚拟机，也不是一台始终在线的服务器。
对我日常维护博客来说，主要有四个区别：
- 软件包和兼容性不同。 Alpine 使用
apk，不能直接照搬 Ubuntu 的安装命令；有些依赖还涉及 CPU 架构或 musl 兼容问题。 - 手机存储不是普通 Linux 文件系统。 外部目录的符号链接、权限和 Git 对象写入可能有差异。
- 后台不保证一直运行。 本地预览服务可能受到 Android 后台限制，不适合把手机当作长期对外提供服务的博客服务器。
- AI 的不同命令调用不一定共享终端状态。 上一次执行了
cd，不能假定下一次还在相同目录，所以操作时应显式指定项目路径。
因此，我的分工是：手机负责编辑和管理源码，GitHub 保存已推送的版本，云端负责正式构建和发布。
三、先分清 Minis 里的几个目录
这是我最需要记住的一部分。
下面只列与这套博客工作流相关的目录，不是完整的 Linux 文件系统：
1 | /var/minis/ |
workspace：适合临时工作，不是我的永久博客目录
/var/minis/workspace/ 可以用来放临时脚本、检查报告或正在处理的资料。
它和当前会话有关。换一个聊天窗口，不应假定工作区还是同一个。 这不意味着关闭聊天就一定删文件，而是不能把它当作跨会话固定入口。
所以，我没有把最终博客工作树和 Git 元数据长期放在这里。
shared、skills、memory：跨会话，但仍属于应用内部
这几个目录解决的是“换聊天还能用”的问题：
shared/放需要跨会话访问的文件。skills/放相对稳定的操作规范和辅助脚本。memory/放偏好、约定和历史记录。
但要区分两个概念：
跨会话保留，不等于卸载 App 后保留。
这些数据仍在应用内部。卸载或清除应用数据前，应按它们可能丢失来准备。
mounts：我和手机编辑器操作同一份源码的入口
我在 Minis 的“挂载外部文件夹”设置中，授权了手机上的：
1 | Kaifa/Blog/ |
并把挂载名称设为 Blog。在 Linux 里，它对应：
1 | /var/minis/mounts/Blog/ |
同一个博客目录，有两种查看方式：
| 使用方式 | 路径 |
|---|---|
| 手机文件管理器 | 内部存储下的 Kaifa/Blog/zqf-blog/ |
| Minis 的 Linux | /var/minis/mounts/Blog/zqf-blog/ |
它们是同一份文件，不是两份需要来回复制的仓库。
Android 多用户或工作资料可能让完整存储路径不同，所以我主要记住自己授权的文件夹，不照抄别人手机上的 /storage/emulated/... 数字。
至于终端默认所在的 /root，它只是 Linux 内的用户目录，不是我的博客目录，也不代表手机已经取得 root 权限。
四、我的博客项目实际放在哪里
博客使用 Hexo 和 Flatpaper 主题，目前的源码目录是：
1 | /var/minis/mounts/Blog/zqf-blog/ |
写文章主要看 source/_posts/ 和 source/_drafts/；配图放在 source/images/。修改网站设置时，要分清站点 _config.yml 和主题覆盖文件 _config.flatpaper.yml。
这里列出的源码不包括 node_modules/、构建生成的 public/、Hexo 缓存和本地凭据。这些不应该随着普通文章一起提交。
五、为什么源码和 Git 元数据分开放
在电脑上，通常一个项目文件夹里就有完整的 .git/ 目录。
但这次在手机上测试时，直接把 Git 对象放进外部挂载目录遇到了写入问题。所以我目前采用：
1 | 外部手机存储 |
工作树里的 .git 是一个文本指针文件，内容类似：
1 | gitdir: /var/minis/shared/blog-git/zqf-blog.git |
这样安排后，我可以用手机编辑器打开外部文件，Minis 则通过内部 Git 元数据管理同一份源码。
需要记住两个限制：
- 不要随便删除或修改
.git指针。 移动工作树或内部目录，也可能需要重新处理路径。 - 只复制外部文件夹，不等于备份了完整 Git 仓库。 特别是未推送的提交和暂存状态，它们不全在外部文件夹里。
第一次下载为了减少传输量，只获取了 main 最新版本所需的文件，旧历史没有完整拉下来。当前版本能正常编辑和提交，不等于全部历史都已经离线保存在手机里。
SSH 认证也单独保存在应用内部。公钥可以添加到 GitHub，私钥不能写进文章、粘贴给 AI，或者顺手放到博客图片和附件目录中。
六、为什么还要给博客创建一个 Skill
文件还在，不代表新会话中的 AI 就知道该怎么操作。
比如，它需要知道：
- 我是在 Android 的 Minis 里操作，不是在 Windows 电脑上。
- 博客应该去外部挂载找，不应该重新下载到当前会话的 workspace。
.git是指针文件，不是损坏后需要删除的垃圾。- 写文章要遵循现有模板和时区。
- 推送
main可能触发正式发布，不只是“帮我存一下”。 - 我确认前，不能提交、推送或部署。
为此，我创建了一个专用 Skill：
1 | /var/minis/skills/zqf-blog-mobile/ |
我更愿意把它理解成给 AI 的“项目交接说明”，而不是一段万能提示词。
每次新开聊天，都可以先说：
使用 zqf-blog-mobile 技能，检查我的手机博客环境和现有改动。先告诉我当前状态，不要提交、推送或发布。
如果技能没有被自动加载，就明确要求读取 SKILL.md。不能只因为以前写过一次规则，就假定每个新窗口都已经读到了。
检查脚本也可以单独运行：
1 | python3 /var/minis/skills/zqf-blog-mobile/scripts/preflight.py |
它会核对路径、分支、本地改动、工具是否存在，并生成用于比较内容变化的指纹。它不会联网拉取，也不会提交和发布，因此里面的 origin/main 只是本地缓存，不代表刚刚核实过 GitHub 的最新状态。
Skill 是操作规范，不是系统权限锁。 它可以让协作更明确，但重要动作仍要看实际改动和执行结果。
七、以后写一篇文章，我会怎么做
1. 先给素材和范围，不急着发布
例如：
使用博客技能，根据我下面的记录整理一篇文章。不要编造我没有做过的测试，先保存到草稿目录，完成后给我阅读链接，不要提交和发布。
这比一句“帮我写篇博客”更能说明我的意图。
草稿放在：
1 | source/_drafts/文章英文名.md |
我当前的站点设置是 render_drafts: false，普通构建默认不渲染草稿。草稿里还会显式写明：
1 | published: false |
但这些设置各有用途，不能混为一谈：notify: false 只是不通知 QQ 群，不会阻止正式文章上线；也不能仅凭某个 front matter 字段就承诺文章已经获得访问保护。
2. 看正文，也检查开头的元信息
一篇文章不只是正文，还包括标题、日期、摘要、固定链接等 front matter。
我最常检查这些字段：
| 字段 | 我关注的内容 |
|---|---|
title |
是否准确、自然，不夸大实际做过的事 |
date / updated |
使用站点的 Asia/Shanghai 时区，旧文保留首发时间 |
permalink |
固定链接明确，不与已有文章冲突 |
excerpt / description |
是否忠实概括内容，是否包含不该公开的信息 |
tags / categories |
沿用已有分类习惯，不留空占位项 |
cover |
有图片才填写，不能引用不存在的文件 |
notify |
是否允许向 QQ 群发新文章通知 |
文章配图可以放在：
1 | source/images/posts/public-post/文章英文名/image.webp |
正文里引用的是网站路径：
1 | /images/posts/public-post/文章英文名/image.webp |
这里不带 source，也不是手机的完整目录，更不是只在 Minis 内部有效的预览链接。
3. 我可以自己改，也可以让 AI 改
用支持 Android 文件夹访问的编辑器，打开 Kaifa/Blog/zqf-blog/ 并授权，就可以编辑同一份 Markdown。
手动改完后，我会让 AI 重新读取文件，不要按它上一轮记住的内容继续覆盖。反过来，AI 改过以后，我也要注意编辑器是否仍留着旧缓冲区。
尽量不要两边同时保存同一个文件。手机上“文件没同步”的问题，有时其实是某个编辑器把旧版本重新写回去了。
如果只想改一小段，可以明确说：
重新读取这篇文章，只修改第二节的表达，保留我手动补充的内容，不改标题、固定链接和发布设置。
4. 满意后，再进入发布审核
我看完草稿不代表 AI 就可以立即推送。
准备发布时，需要整理正式文章路径，检查草稿状态、日期和通知开关，再给我展示最终差异。从草稿转为正式文章，也是需要让我看到的变化。
如果我只是想把当前草稿做成本地 Git 提交，也要明确说“只提交草稿，不发布”，而不是让 AI 自己猜。
八、本地构建与预览：已经在手机上跑通
这篇文章先写成本地草稿，随后移入 source/_posts/，设置 published: true，再进行构建和预览。整个测试过程没有暂存、提交、推送或部署。
放进正式文章目录，只表示它可以进入 Hexo 的普通构建；不代表文章已经上传 GitHub，更不代表网站已经上线。
下面记录这套环境的实际操作方式。目录和辅助脚本是我为自己的博客准备的，不是安装 Minis 后就自动带有的通用配置。
1. 第一次准备环境：先检查，再安装
这次实测使用的版本是：
| 工具 | 实测版本 |
|---|---|
| Node.js | 22.23.2 |
| npm | 10.9.1 |
| pnpm | 10.34.6 |
| Hexo | 锁文件中的 8.1.2 |
这些版本是本次记录，不代表以后必须永远保持同一个小版本。新会话先检查实际状态：
1 | node --version |
如果工具已经存在，不需要每次写文章都重新安装。首次准备时，我使用 Alpine 的包管理器安装 Node.js 和 npm，再安装 pnpm：
1 | apk add nodejs npm |
这些安装需要联网下载软件包，但不是博客发布操作。将来重装应用时，先重新核对项目所需版本，不要直接升级全部依赖，也不要删除锁文件来绕过安装错误。
2. 分开保存：外部编辑源码，内部安装依赖
我的主要编辑目录仍是：
1 | /var/minis/mounts/Blog/zqf-blog/ |
它对应手机文件管理器中的 Kaifa/Blog/zqf-blog/，文章、图片、主题和正式配置都在这里维护。
构建和运行环境则单独放在应用内部：
1 | /var/minis/shared/blog-dev/ |
这样做是为了避开外部挂载在符号链接、硬链接和权限上的兼容问题。内部副本没有 Git 元数据、GitHub 工作流或凭据，不是另一个需要提交或推送的仓库。
首次准备副本时，需要同步构建所需的源码、主题、配置、package.json 和 pnpm-lock.yaml，排除 .git、凭据、已有依赖和生成文件。不能简单把整个项目连同本地秘密文件一起复制。
安装依赖的实际命令是：
1 | cd /var/minis/shared/blog-dev/site |
各个选项的作用：
--prod：只安装 Hexo 构建所需的生产依赖，不安装部署用的 Wrangler 开发依赖。--frozen-lockfile：严格使用现有锁文件，不自动更新依赖版本。--ignore-scripts：跳过依赖的安装脚本。--package-import-method=copy：从依赖存储导入包时使用复制，避免依赖硬链接兼容性。
这套选项已经在当前项目中验证成功，但不能保证适用于所有 Node 项目。有些项目需要原生编译或安装脚本，必须另外检查。依赖准备好后，普通改文章不需要重装；只有依赖文件变化时才重新评估。
3. 每次改完，先同步到预览副本
外部源码和内部副本不自动同步。
例如，这次只改了本篇文章，可以在确认外部文件已保存后，同步这一份文件：
1 | cp /var/minis/mounts/Blog/zqf-blog/source/_posts/openminis-mobile-blog-workflow.md \ |
它只是复制这篇文章到已经准备好的内部目录，没有 Git 操作。第一次同步新目录中的文件时，还需要先创建对应目录。
如果同时修改了图片、配置、主题或其他文章，也要同步相应文件。删除和重命名同样要在副本中处理，否则预览可能留下已经不用的旧内容；处理前先核对路径，不使用未经检查的整目录删除。
我会坚持一个原则：只在外部工作树写正式内容，内部副本只是拿来检查结果。 在副本里直接改正文，即使预览好看，也不会自动变成主仓库里的修改。
4. 构建：检查它能不能生成完整页面
同步完成后，在内部副本里执行：
1 | cd /var/minis/shared/blog-dev/site |
这个命令调用 Hexo 的 generate，生成结果在内部的 public/ 中，不会把文件推送到 GitHub。每次命令都写明 cd，避免新一轮调用回到其他目录。
首次构建成功生成了 143 个文件，包括本篇文章的 HTML。后续只改一篇文章时，Hexo 可能只重新生成少量页面；不能因为增量构建没有再次显示 143 个文件，就认为构建失败。
当前 Hexo 会自动加载站点的 _config.flatpaper.yml 主题覆盖配置，不需要把它再当作站点主配置手动叠加。
构建没有报错只是第一步，还要检查生成的页面、链接、图片和手机排版；它也不能证明第三方服务或线上部署已经正常。
5. 启动：使用现有的本地预览启动器
在这套环境里，我优先使用已经准备好的启动器：
1 | python3 /var/minis/shared/blog-dev/start-preview.py |
它会检查 4000 端口是否已被使用，把服务输出写入日志，并记录启动时的进程信息。它只能用于这套已准备好的环境；其他用户需要自行创建等效配置和脚本。
如果端口已有服务，不要反复启动。先确认已有服务是否就是博客预览，能正常访问就直接使用；如果是其他程序占用，再决定如何处理。
启动器实际运行的 Hexo 命令相当于：
1 | cd /var/minis/shared/blog-dev/site |
这是另一种前台运行方式，不是启动器执行完后还要再执行一遍的步骤。手动在交互终端运行时，会占用该终端，停止可按 Ctrl+C。让 AI 后台启动则应重定向日志，并核实进程和 HTTP 响应，不能仅凭一句“已启动”判断成功。
6. 打开网页：在这台手机上查看
在同一台手机的浏览器中打开：
127.0.0.1 指当前设备。它不是公开网址，在另一台设备打开相同地址，也不会访问到这部手机。服务只监听本机，不需要开放公网端口或建立穿透。
这次已经检查了文章、首页、搜索索引、RSS 和站点地图，本地样式、脚本及所检图片请求正常；在 412px 手机宽度下，没有整页横向溢出，长代码块可以在块内横向滚动。
构建不会自动弹出网页，服务启动也不等于内容已经提交。 要查看结果，仍需自己打开地址；改外部文章后，先同步，再刷新网页。
7. 新会话继续运行，或打不开时怎么检查
blog-dev 放在跨会话的 shared/ 下，因此换聊天窗口后可以继续定位。但这并不保证服务还在运行，也不代表卸载后环境还会保留。
新会话里，我可以直接这样要求 AI：
使用 zqf-blog-mobile 技能，检查本地预览环境。把刚修改的文章同步到内部副本并构建；如果预览服务没有运行就启动，已经运行则不要重复启动。给我本地阅读地址，不要暂存、提交、推送或部署。
如果页面打不开，先查看日志和 HTTP 响应：
1 | tail -n 30 /var/minis/shared/blog-dev/state/server.log |
常见排查顺序是：地址和端口是否正确 → 服务是否仍在运行 → 内部副本与依赖是否存在 → 文件是否已同步 → 构建日志是否报错。
server.json 只记录启动时的进程号，不能凭它认定进程现在仍活着。Android 可能暂停或终止服务；重新启动前核实当前进程和端口，不能照抄旧 PID 随便结束其他程序。
需要停止后台预览时，可以让 AI核对记录、进程命令和进程组后，只停止这个服务，不使用会误杀其他 Node 程序的全局结束命令。
8. 本地测试不联系线上服务
state/preview.yml 把预览 URL 改为本机，并关闭评论、统计等线上功能。内部的 scripts/minis-local-preview.js 为预览响应加上限制外连的 CSP 和 noindex 标记。这两部分只在构建环境里，不会写回正式源码。
因此，远程音频、第三方评论或外部图片可能在这份预览中不可用。这是本地隔离的边界，不应为了“看起来全部正常”擅自开启线上请求。
AI 摘要缓存原本由 deploy 保存，本地没有缓存时会跳过摘要渲染，不会自动调用外部模型补齐。构建日志中的 scheduled-qq 也只是生成待办 JSON，不代表已经发送 QQ 消息。
对我来说，日常本地运行的顺序就是：
1 | 编辑并保存外部源码 |
这一轮只解决“写完后在本地看看”。是否提交、推送、通知或发布，仍然是后面单独审核、单独确认的事情。
九、保存、提交、推送、发布，是四件不同的事
这四个动作必须分开理解：
| 动作 | 意味着什么 |
|---|---|
| 保存文件 | 内容写进手机文件，Git 还不一定记录了这个版本 |
git commit |
创建本地提交，仍然没有自动上传 GitHub |
git push |
把提交推送到远端；在我的仓库里可能触发自动发布 |
| 网站上线 | 云端流程完成，网站确实出现新内容，需要另行核验 |
我目前仓库的发布设计是：
1 | 手机编辑源码 |
新增文章还可能由另一条工作流发送 QQ 群通知。notify: false 可以关闭该文章的通知，但不会停止网站发布。
GitHub 工作流能够从仓库中查到；Cloudflare 监听 deploy 的设置来自我现有的流程记录，这次写文章没有重新核对控制台。基础设施改动后，需要以实际设置为准。
因此，在我的项目里，“推送 main 帮我备份一下”不是一个无害的同义词。它可能让当前代码正式上线，也可能调用外部 AI 服务。若暂时不想发布，应先保留本地或使用另行确认的备份方案，不能直接拿生产分支试试。
我要求的确认流程
在执行提交或推送前，AI 应先给我一份清楚的审核摘要：
- 新增、修改、删除了哪些文件。
- 文章的标题、链接、公开状态和关键变化。
- 是否有我之前留下的暂存内容或尚未推送的提交。
- 实际完成了哪些检查，哪些没有验证。
- 是否触发 QQ 通知、外部 AI 摘要或部署。
- 准备使用什么提交说明、推送哪个分支。
然后停下来等我确认。
我可以这样回复：
只提交当前审核过的草稿，不推送。
或者：
确认按刚才的清单提交并推送 main，触发发布，QQ 不通知。
如果确认后文件又变了，或者远端多了新提交，就应重新检查，不能拿旧的“同意”继续执行新的内容。
特别是修改主题时，主题目录还保留了使用工作分支、禁止直接在 main 提交的指引。它和站点日常 main 发布流程之间需要先明确分支方案，不能让 AI 静默忽略其中一套规则。
推送成功也要看最终结果
我希望最后收到的是分阶段结果，而不是一句笼统的“已发布”：
1 | 本地提交：是否成功 |
看不到某个阶段的状态，就直接说明没有权限或尚未验证。访问网站得到 HTTP 200，也可能只是旧页面，不足以证明新文章已经上线。
十、如果卸载 Minis，哪些东西还在
这也是我选择外部挂载，而不是把所有文件塞进应用内部的原因。
| 数据 | 卸载或清除应用数据后的预期 |
|---|---|
| 普通外部文件夹里的文章、图片、主题和配置 | 通常保留；前提是没有放在应用专属目录，也没有另外删除 |
| 已经推送到 GitHub 的版本 | 不受手机卸载影响 |
| Minis 内部 Git 元数据和未推送提交 | 应按会丢失来准备 |
| SSH 私钥、安装的工具和内部开发环境 | 需要恢复或重新配置 |
| 内部 Skill、记忆和会话工作文件 | 不应依赖卸载后的自动恢复 |
外部源码保留下来时，.git 指针可能也还在，但它指向的内部目录已经不存在。这时不是“Git 自己坏了”，而是原来的 Git 元数据丢了。
恢复时应该先备份保留下来的文章，再重新建立仓库环境、核对并合入本地修改。不能一上来就用远端版本覆盖手机上唯一的未发布稿件。
我的 Skill 另外保存了一份不含凭据的外部副本：
1 | Kaifa/Blog/_minis-skills/zqf-blog-mobile/ |
它位于博客仓库旁边，而不是博客源码里面。以后重装 App，可以拿它恢复操作说明，但它不是 Git 历史或 SSH 私钥的备份。
外部挂载主要解决“换编辑器、换会话或卸载应用”的问题，不能解决手机丢失、存储损坏或误删。重要内容仍应有独立备份；需要推送时，也要遵守审核和发布边界。
十一、遇到问题，先检查，不要急着重建
给自己留几个排错提醒：
- 新会话找不到博客： 先检查挂载和技能是否加载，不要立即重新克隆。
- Git 报目录不存在： 检查
.git指针与内部元数据目录，先保护已有文件。 - Git 报
invalid mode for object creation: copy： 我这里遇到过系统配置写入无效值的问题，不代表文章丢了。应核对具体配置后再处理，不能靠删除仓库解决。 - 下载安装长时间没动静： 查看日志、网络和进程，区分慢与断线。不要不停启动重复任务，也不要把“后台还在跑”当作已经完成。
- 文章没显示： 核对是否仍在草稿目录、正式构建用了什么配置，以及云端是否部署了当前提交。不能直接拿未来日期或某个未验证字段当发布控制。
这些细节适合放进 Skill 持续维护，文章保留主要思路，避免每次换会话都从头踩一遍。
最后：把边界说清楚，比一句“交给 AI”更重要
对我来说，手机维护博客最重要的不是把电脑上的所有功能原样搬过来，而是建立一套自己能理解、能检查、能恢复的流程：
1 | 外部文件夹保存源码 |
以后新开一个会话，我最常用的开场白大概就是：
使用 zqf-blog-mobile 技能，先检查现有文件和仓库状态。我们继续写博客，但先保存本地，等我看完再决定是否提交。
文件在哪里、AI 可以做到哪一步、发布前谁来确认——把这几件事讲清楚，手机才是一张能放心继续写下去的工作台。
评论