原来乱在哪里
我们现在用的电脑运行 Omarchy。我经常重装系统，也在同一台机器上试不同的 Agent、图像模型、内容生产工具和桌面软件。最初的问题不是“缺一个 AI 应用商店”，而是事情散在不同地方：服务是否开机启动、模型文件在哪里、哪个脚本是临时测试、哪次调用真的成功、哪个账号由什么安全存储管理，下一次都要重问。于是电脑有了独立的运维目录。它自己的 .qiming/START.md 是短入口，.qiming/conventions.md 放本机规则；assets/ 存长期管理对象，work/ 存具体工作和验收。启明没有要求这台电脑改用一套通用的 members/ 文件夹，而是沿用这个项目已经采用的名称。
现在给一个可照着做的例子。你用 Linux 或 Omarchy，准备长期使用本地图像、语音或代码模型，也可能有 Pi、Codex、OpenCode 这些操作它们的 Agent。先在自己愿意备份的位置建目录。下面的路径是示例，不会自动扫描或修改你的系统：
mkdir -p "$HOME/Work/local-ai-management"
cd "$HOME/Work/local-ai-management"启明做了什么
一次具体工作是部署 ComfyUI 和一个 Qwen 图像模型。若只看最终目录，可能会看到模型文件、插件、工作流 JSON、两张图片和几个脚本；这些文件本身讲不清结果。启明先把用户的目标变成一条工作记录：要部署什么，怎样判断服务能运行，怎样判断模型文件正确，怎样判断文生图和图片编辑真的成功。然后分出两个需要长期照看的对象：ComfyUI 是本机运行的服务会员；Qwen 图像模型是它下面需要单独校验、升级和测试的模型会员。模型卡用 part_of 指向服务卡，两张卡都能追溯到部署任务。临时下载、测试图和一次性命令没有被机械地各自登记成会员。
把已有说明、你亲手写过的脚本或模型来源链接放进来即可；大体积权重仍可留在模型盘。安装启明种子后，在当前目录明确说：“在这个目录启用启明。这个项目专门管理我本机部署和维护的 AI。先只读检查我已有的服务、模型和 Agent，保留原有安装。今天先从一个模型开始，给我看清单、未知项和最小验证计划。”官网开始页有真实安装命令。首次不要说“管理整台电脑所有东西”，否则范围太大，连失败时该回退什么都说不清。
第一次盘点建议让 Agent 交出三个东西。第一是一张现状表：哪些是正在运行的本地服务，哪些只是已下载模型，哪些是云服务账号，哪些是临时实验。第二是一个待确认表：模型版权与来源、真实安装位置、凭据 provider、端口是否只在本机开放、备份是否存在。第三是今天要做的一个小任务。每一项都标“实际观察”“来自旧文档”或“还没检查”。这份盘点只是开始，不应直接把所有东西宣布为会员。
假设你选择一个图像服务。先给服务建档，再给需要单独维护的模型建档，并把模型的 part_of 指向服务。任务写成“验证模型可做什么”，验收可分为：模型文件来自哪里且哈希相符；服务能识别模型；提交最小输入后能产出可打开的文件；用户确认结果是否符合用途。你可以把工作流 JSON 和验证脚本放在已有工作目录里，不必为了符合启明示例而重排磁盘。项目实例通过本地 profile 知道这些记录在哪里。
如果你今天真要开始，先不要想象半年后的知识库。第一天只做三件事。第一，把目录建好并明确告诉 Agent 这是什么项目。第二，让它只读盘点一个已经存在的 AI 服务和一个模型，报告“看到了什么、没看到什么”。第三，从中选一个可在半小时内完成的目标，例如打开服务并生成一张测试图。任务目标越小，验收越容易真实完成。
你可以直接说：
在当前目录启用启明。这里专门管理我自己部署的本地 AI。
保留已有文件，不移动模型权重，不修改系统服务。
先只读核对一个图像服务和一个模型：入口、版本、来源、
是否运行、上次验证是什么、还有哪些信息只是旧文档。
给我一个今天能完成的最小验证任务。如果目录是空的，盘点结果当然会写“尚未发现服务”；这不是失败。Agent 可以先建立项目入口和一条准备部署的工作记录，下一步等你给出模型来源或安装范围。不要让它为了填满空表而把系统上所有软件都猜进这个项目。
留下了什么
若把真实目录简化成一张不含私人路径的地图，大概是下面这样。会员档案通过本项目启明工具的受控 plan → apply 写入；测试图片仍在原输出位置，档案只指向它们，不复制一堆大文件：
电脑运维目录/
├── .qiming/START.md 今天从哪里继续
├── .qiming/conventions.md 本机操作与凭据边界
├── assets/图像服务.json 长期服务会员
├── assets/图像模型.json 模型会员，属于图像服务
├── work/模型部署.json 安装、校验与真实出图的逐条验收
└── work/性能调研.json 特定参数下的对比，默认工作流未改你打开短入口，能找到今天的工作；打开部署任务，能找到检查与测试图；打开模型会员，能找到它属于哪个服务。这个路径不是让所有用户照抄的固定模板，而是展示“入口、对象、工作、证据”怎样各司其职。没有这张关系图，六个文件名和两张图片仍然只是六个文件名和两张图片。
完成一次测试后，再问“这个调用将来还会不会重复”。如果只是试一次，保存任务结果。如果每次都要先检查服务、选择模型、提交同一种输入、核对输出，可以把这段步骤做成服务下面的 Skill 或小脚本。Skill 应告诉 Agent 什么时候加载、从哪份会员档案取得当前服务入口、失败时停止在哪一步；脚本应有清楚的输入输出和测试。一个可重复调用的工具需要维护时再入会，第一次临时命令不必入会。
第一次实际调用时，再给明确授权：“只对这个本地服务做一次测试生成；输入是我提供的测试提示词，输出放在本项目指定的测试位置。先列出可能消耗的显存与磁盘，执行后检查文件能否打开，记录服务版本、模型、参数和输出；失败也保留错误。”这样得到的工作记录能回答“到底试过没有”。如果模型文件刚下载，就先校验文件；如果服务还没启动，就先核对服务，别跳过中间条件直接宣布模型不可用。
第一次交接时，关掉当前聊天，换一个新会话，只给一句话：“继续这个本地 AI 项目。先从项目入口说出当前服务和模型分别是什么，上次真实验证做到了哪一步，还有哪项未验证。暂时只读。”它若能指出模型归属、上次测试与待复查项，接续才算有了实际效果。若它读到的只是一个空模板，或把昨天在线说成今天在线，你就知道需要修的是入口和状态时效，不是再增加十层目录。
验证到哪里
接下来才是执行和验收。服务层检查了用户服务的启用与运行状态，并访问本机状态接口；模型层核对了三个关键文件的 SHA-256，确认插件能枚举模型、编码器和 VAE；能力层分别提交文生图和图片编辑任务，得到两张可打开的 512×512 PNG，并目视检查内容。部署任务的每条验收条件指向不同证据。它没有写一句含糊的“本地 AI 已部署完成”，而是说明“服务可达”“文件正确”“这两种生成已实测”。其他分辨率、其他工作流和重装后的恢复不因此自动通过。
后来我们想加速出图，又新开了性能调研任务，而不是改写原部署结论。在同一台机器、同一分辨率、同一步数和同一种子下，记录了基线约 89.77 秒与 EasyCache 约 40.68 秒的两次任务。报告还写着图片编辑和更多提示词尚未测，默认工作流没有因此被悄悄改掉。这样做的好处很直观：下一位 Agent 若要开启快速模式，先知道这个数字来自什么条件，也知道要复核画质；不会把一次基准测试误当成所有场景的速度承诺。
你可以从这件事看见启明的实际工作顺序：一个目标先成为任务；任务定义可观察的验收；真正要长期维护的服务和模型各有身份；脚本、图片和日志归到任务或会员名下；每条完成声明都有范围；下一步留下尚未验证的事项。混乱没有凭空消失，而是被拆成“我现在能找到什么、相信什么、下一次先检查什么”。
下次系统升级或重装，新的 Agent 从项目入口找到服务和模型的稳定身份，按照记录重新核对版本、文件、依赖和真实调用。注意：有管理档案不等于模型权重已备份，哈希匹配也不等于服务功能正常。恢复时要把目录资料、实际模型文件、软件依赖和安全凭据分开准备，然后在新环境再跑最小测试。启明保存恢复路线，不能代替真正的备份介质。
工作稳定后再考虑一次重装演练：在另一处空目录预演恢复，把项目文件、模型原件、安装包或重装方法、外部依赖、安全凭据入口分开核对。只有重新启动服务并完成一张新的测试图，才能说这个用途在新环境恢复。我们本机已有部署和出图证据，但这篇教程不会声称那套 AI 已完成完整换机恢复；下一次做这件事时，应按同样的验收顺序记录。