我做了一个本地优先的 AI 图片工作台：Loomora v1.0.0 正式发布

Loomora 是一款面向个人创作者的 AI 图片创作、管理与编辑桌面应用。Windows 和 macOS v1.0.0 已经发布。

反馈、咨询联系：believe_rl@163.com

过去一段时间，我一直在做一件看起来简单、实际很容易失控的事：把 AI 生图真正融入日常创作流程。

很多工具可以生成图片，但生成之后往往还要面对另一组问题：提示词散落在聊天记录里，参考图找不到来源，作品越积越多却无法整理，想换一个模型还要重新适应一套界面，简单编辑和文字识别又得切换到其他软件。

Loomora 的目标不是再做一个"输入提示词、等待图片"的页面，而是把创作前后的完整过程放进一个安静、可长期使用的桌面工作台：从提示词、参考图和生成队列，到本地作品库、图片编辑、OCR、版本记录与再次创作，都在同一个应用里完成。

从一次生成，变成一条完整的创作链路

Loomora 当前的核心工作流是：

配置生图服务
  -> 输入提示词或添加参考图
  -> 进入可追踪的生成队列
  -> 自动保存图片与创作记录
  -> 在作品库中整理、编辑和识别文字
  -> 复用原提示词或参考图继续创作

这条链路里，生成结果不是一次性的"消息附件"。每次创作都会保留提示词、参数、Provider、Profile、模型、参考图、时间和本地文件位置。之后无论是在历史对话还是作品库里，都能重新找到当时的上下文。

快速创作区支持文本生图、参考图创作、批量生成、比例、尺寸、质量和输出格式。界面不会把所有选项一股脑展示出来，而是根据当前服务和模型的能力动态决定哪些控件可用。

例如某个平台不支持参考图，对应入口会被隐藏；模型最多生成 4 张时，数量控件不会允许选择 10 张；第三方兼容接口不支持流式中间图时，应用会自动降级为普通请求。缺少接口地址或 API Key 时也会立即提示，不会让一个无效任务长时间等待。

Provider 是平台方言，不是全世界共用的一套标准

在接入不同生图平台时，我越来越确定一件事：OpenAI-compatible 只能算一种 Provider 方言，不能当成所有平台共同的底层协议。

不同平台在以下方面经常不一致：

• 接口路径与鉴权方式；
• 文生图、参考图和多参考图的字段结构；
• JSON、Base64、图片 URL 与 multipart 文件上传；
• 同步响应、流式响应和异步任务轮询；
• 比例、尺寸、质量、格式和批量数量；
• 任务取消、错误结构和结果下载方式。

因此 Loomora 将生成流程拆成了公共调度层和 Provider 适配层。

创作界面
  -> 统一生成请求
  -> Provider 能力声明与校验
  -> 平台适配器
  -> 统一生成结果
  -> 队列、历史记录与本地保存

公共层只负责队列、进度、取消、重试、本地保存和历史记录。每个平台如何组织请求、上传参考图、轮询任务以及解析结果，都由自己的适配器处理。

目前内置 OpenAI-compatible 和 Replicate。后续接入 SiliconFlow、智谱、通义、火山引擎或本地 ComfyUI 时，不需要反复修改创作页面和作品库，只需要实现一层相对薄的适配器。

服务配置采用多 Profile 设计。每个 Profile 独立保存 Provider、接口地址和模型，API Key 通过 Electron safeStorage 按 Profile 加密保存。重新生成、参考图创作和失败重试默认使用用户当前选择的服务，同时在作品信息中保留生成来源用于追溯。

图片生成只是开始，作品沉淀才是长期价值

图片一多，文件夹很快就会失去可读性。Loomora 的作品库不是简单地把目录中的图片铺出来，而是围绕长期积累做了完整的管理能力。

作品默认按日期归档，并按照日期和修改时间由新到旧展示。瀑布流保持原图比例，支持日期时间轴、搜索、专辑、标签和颜色筛选。

外部图片既可以通过系统文件框多选导入，也可以直接拖进作品库。导入时使用 SHA-256 检测重复内容，避免同一张图片被反复保存。

作品库目前还包括：

• 收藏、回收站与恢复；
• 多选和批量整理；
• 查看、编辑和复制完整提示词；
• 记录模型、生成服务和参数；
• 重命名、导出和打开文件位置；
• 将现有作品作为参考图继续创作；
• 编辑版本对比和历史版本恢复。

下载、导出和"另存为新图"都会先打开系统文件框，由用户决定文件名和保存位置。编辑保存为新图时会使用最新日期归档，不会因为继承旧文件信息而沉到作品库底部。

灵感不只是浏览，还应该能够立即复用

灵感广场保存了一组可以直接复用的画面案例和提示词。浏览时可以查看完整提示词，也可以把推荐规格填入快速创作，或者直接把案例图片作为参考图开始新的创作。

这里的重点不是展示更多图片，而是尽量缩短"看到灵感"到"开始创作"之间的距离。

编辑、马赛克、版本记录与离线 OCR

内置编辑器基于 TOAST UI Image Editor，支持裁剪、翻转、旋转、涂鸦、形状、文字、滤镜、颜色、透明度和画布缩放。工具名称、按钮和悬浮提示进行了中文化，颜色工具也补充了详细选色、HEX 输入和色相指示。

马赛克不是游离在编辑器之外的一次性操作，它和其他编辑动作一样会进入撤销、重做与历史记录。图片另存为新版本后，可以在作品详情中进行版本对比和恢复。

OCR 使用随应用保存的 Paddle.js 模型，在独立的隐藏工作窗口中运行。识别过程不会把图片上传到外部 OCR 服务，也不会阻塞主界面；用户可以随时取消识别并复制结果。

为什么坚持本地优先

Loomora 并不是完全不联网：调用生图 Provider 和检查应用更新都需要网络。但作品管理、图片编辑、OCR、标签、收藏、回收站和历史记录都尽量留在本机。

本地优先带来的直接好处是：

1. 作品不依赖某个平台是否继续提供历史记录；
2. 提示词、标签和版本信息可以跟图片长期保存在一起；
3. 切换 Provider 不需要迁移整个创作资产；
4. 本地编辑和 OCR 不需要上传图片；
5. 用户可以自主选择存储目录，并进行本地备份与恢复。

API Key 不会写入作品目录或备份包，而是通过系统安全存储加密。生产安装包也会排除开发环境地址、测试密钥、本地作品和首次引导状态。

桌面端实现与发布

Loomora 使用 Electron 31、Vue 3 和 Vite 5。主进程负责窗口生命周期、本地文件、系统文件框、Provider 请求和 OCR 工作窗口；渲染层通过启用 contextIsolation 的预加载桥接访问桌面能力，没有开启 Node.js 集成。

Windows 使用 NSIS 安装包，允许用户选择安装目录，卸载时会询问是否同时删除本地数据。macOS 使用 DMG 作为手动安装包，同时生成 ZIP 供自动更新使用。

自动更新采用双渠道策略：

国内用户：优先检查 Gitee Release
国际与备用：检查 GitHub Release

Windows：latest.yml + EXE
macOS：latest-mac.yml + ZIP + DMG

更新检查失败不会影响离线创作。发布凭据只存在于本地发布环境，不会被提交到仓库或打进安装包。

下载 Loomora v1.0.0

Windows 安装包已经发布，约 100 MB。

• 国内下载：Gitee Releases
• 国际与备用下载：GitHub Releases
• 文件名：Loomora-Setup-1.0.0-win-x64.exe
• SHA-256：df158d980151c031fb33d0c29429207f363c43191340e7e0ff69f90dbb59fd5e

macOS 安装包已发布到 GitHub Release：

• DMG：Loomora-1.0.0-mac-x64.dmg
• ZIP：Loomora-1.0.0-mac-x64.zip
• 更新清单：latest-mac.yml
• SHA-256：SHA256SUMS.txt

Gitee Release 目前仅保留 Windows 附件，macOS 包因单附件大小限制无法上传。

下载后可以在 PowerShell 中校验安装包：

Get-FileHash ".\Loomora-Setup-1.0.0-win-x64.exe" -Algorithm SHA256

输出应与上面的 SHA-256 完全一致。

写在最后

Loomora v1.0.0 仍然只是第一版。我希望它最终成为一个能够长期承载个人创作资产的桌面工作台，而不只是某一个模型或某一家平台的操作界面。

接下来会继续完善更多 Provider 适配、macOS 发布、更新体验、大型作品库性能和创作资产管理。如果你在使用中遇到问题，或者对新的生图平台接入、工作流设计有建议，欢迎联系我。

联系邮箱：believe_rl@163.com

使用与授权说明

Loomora 源代码公开，采用 PolyForm Noncommercial License 1.0.0，允许个人学习、研究、评估及其他非商业用途。该许可不属于允许自由商用的开源许可证，任何商业使用、收费部署、再销售或其他盈利行为都需要取得作者书面授权。

Loomora 名称、Logo、应用图标和视觉识别属于作者个人品牌资产，源码公开不代表授予品牌使用权。项目中的第三方依赖和资源仍分别遵循各自的许可证与使用条款。