把改图变成可回溯版本树的本地工作台（Layerive）

文生图页面擅长从零生成一张新图。真正麻烦的是拿到图之后的活：改一行文字、换掉一个主体、只动选中的一块区域、把画布往外扩一圈。这类改动通常靠反复改提示词重生成，模型还经常顺手改掉你不想动的地方。

Layerive 把这些改动拆成工作台里一个个具体工具：识别文字后直接编辑、框选区域描述改动或给一张参考图、按目标比例扩图、抠出素材、整图去水印。每次生成或编辑产出一个版本，可以回看、对比，也能从任意一个版本往下分支。

Layerive 是本地运行的 AI 图片创作工作台，用 TypeScript 写，输入提示词或图片，输出可回溯、可分支的图片版本树，素材和对话留在自己机器上。

模型接入由使用者自己决定。图片、对话、编辑历史和模型设置都留在本机，只有发往你配置的模型服务的请求会离开。仓库地址是 https://github.com/newljs/Layerive，许可证为 LGPL-3.0，主要语言 TypeScript。

主要功能

仓库顶层包含 electron/、server/、src/ 等目录和 Layerive.bat 启动脚本，完整安装步骤没有在本次事实节选中给出，依赖与构建命令需要在 README 的 Get started 章节自行确认。

• 项目与版本树管理：项目库提供卡片和列表两种视图，支持搜索、收藏、复制、重命名和软删除。每个项目记录描述、封面、当前图片、默认模型和未完成的工作台状态，当前标签页在刷新或后台丢弃后能恢复打开的项目。项目可以单个导出或导入为 ZIP，也支持完整的本地备份与恢复。
• 文生图：一条提示词一次生成 1–4 张图，多个结果归属同一个版本，任意一张都能选出来继续编辑。每次调用只返回一张图的供应商会被拆成多次请求，可能分别计费；遇到限流会自动退避重试。多图请求里，由视觉模型自行判断提示词要的是同一内容的候选，还是喜怒哀乐这类逐图变体。
• 融合（Fusion）：在画布工具栏末端打开 Fusion，右侧栏可选 Basic fusion（默认）、Change outfit、Transfer pose、Group photo，侧栏顶部固定一个 Exit fusion 按钮用于恢复项目对话与编辑。参考图支持上传、粘贴或从项目已生成的图片里选，静态 PNG/JPEG/WebP 单张上限 10MB。把参考图拖到主图目标上，或选中参考图再点目标，可附加指令细化意图，由视觉模型判断后交给图像模型执行。这项功能需要视觉模型和一张支持双图编辑的图像服务，参考图无效或意图不明确时任务会停下并给出说明。
• 图生图与提示词改图：从上传、粘贴或历史图片出发描述下一步改动，应用会自动选一个与源图比例最接近的受支持输出尺寸。
• 局部重绘：可以从图像内部或外部拖出选区，选区允许超出工作台边缘。在选区面板里写改动描述，或上传、粘贴一张参考图（PNG/JPEG/WebP，最大 10MB）。举例来说，选中人像的头部再上传一张狗的照片，视觉模型会推断替换意图、定位两个主体并规划提示词。
• 批量编辑：以画布当前显示的图片为共享参考，在同一个提示词编辑器里插入不可编辑的变量标签，输出 2–50 张，构成一个每行一张图、每行一组变量输入的矩阵。也可以切到「提示词列表」标签导入 TXT，一行一条提示词，或直接粘贴多行，条数即输出张数（2–50 条，每条最多 1000 字符），每一行作为该图的完整提示词原样使用。每行都会单独发起一次图像模型调用，可能分别计费。
• 批量文生图：不需要输入图，每行提示词产出一张独立图片，变量模板与提示词列表两种输入方式与批量编辑一致。面板里可以设置「统一风格提示词」，默认从项目风格提示词初始化，也能单独编辑，它会被追加到每一行上以保持整批风格一致；openai 类供应商还能选输出格式与透明背景。
• 模型日志：工作台标题栏的按钮可以查看当前项目的视觉规划输出、生成的提示词、脱敏后的请求与响应元数据、耗时和错误。API key、图片 Base64 和返回的图片字节不会写进这些日志。

它的实际表现

• Star 数：337
• Fork 数：79
• Watcher 数：1
• 开放 Issue：4
• 许可证：LGPL-3.0
• 主要语言：TypeScript
• 创建时间：2026-08-30
• 最近一次提交：2026-10-12
• 最近一次发布：v0.1.9（2026-10-12）
• 仓库体积：201491 KB

近 30 天增长、提交频率、Issue 响应时长这几项，事实表里没有给出数值。

这些数字说明什么

337 个 Star 配 79 个 Fork，说明有一部分人不只是点了收藏，而是把仓库拉到了本地。Watcher 只有 1，关注更新的人远比收藏的人少，这与项目偏工具、偏实用有关。

创建于 2026-08-30，最近一次提交在 2026-10-12，仓库仍在更新。发布记录里 v0.1.5（2026-10-01）到 v0.1.9（2026-10-12）之间连出五个版本，版本号还停在 0.1.x，这两点合起来指向一个处在早期、迭代密集的状态。

开放 Issue 只有 4 条，对一个已经有 337 Star 的仓库来说不算多。这 4 条里有 3 条跟参考图上传能力有关，需求指向相当集中，说明这块当时还不到位。

语言占比里 TypeScript 49.5%、JavaScript 38.1%、CSS 12.2%，主体的前端代码加上 electron/ 与 server/ 两个目录，指向一个带本地服务端的桌面应用形态。许可证选的是 LGPL-3.0，属于偏严格的一类，打算把它嵌进闭源产品之前需要先读条款。

数据看不到的部分

Star 数说明不了生成质量。一张图改完之后主体有没有漂、文字有没有糊、选区边界处理得干不干净，这些只能自己跑一遍才知道，数字层面完全反映不出来。

4 条开放 Issue 是当时未关闭的数量，不代表问题的总量，也不代表严重程度。已经修掉的问题不会出现在这份清单里，读者看到的是一个截断面。

项目新这件事有两面。提交活跃说明有人在维护，同时也意味着接口、配置方式和目录结构还有可能变，跟着教程搭起来的环境未必长期稳定。

文档是否跟得上版本，数字里没有线索。README 有 26.2 KB，功能描述相当细，但它与最新代码是否同步、示例是否还能跑通，需要自己核对。本地运行对硬件的要求、生成一张图大概要等多久、一次批量任务要花掉多少模型额度，事实表里也都没有数据。

仓库体积 201491 KB 对源码仓库来说不小，里面包含哪些资源，事实表没有说明，无法据此判断代码量。

同类工具横向对照

下面两个项目跟 Layerive 不在同一条产品线上，放在这里只是给正在做工具选型的人一个位置参照。

Toonflow 和 FanBox 都不是图片工具，列在这里只是给同类选型一个参照，不构成直接比较。回到 Layerive 本身，它的门槛不在界面而在模型：视觉模型和图像模型都要自己接，仓库里没有提供托管的模型服务，对只想打开就用的人是一道坎。另外它只能处理图片，需要批量产出视频的人应该去看 Toonflow 那类工具。

所以值不值得试

值得试的情形：日常工作是围绕同一张图反复调整，换衣服、换姿势、改文字、扩画布，并且希望每一次改动都能回看、对比、从中间某个版本重新分叉；同时在意素材归属，不希望图片和对话躺在别人的云端项目里，也愿意自己去申请和配置模型 API 密钥。

先别急的情形：只想体验一下文生图，出几张图就结束，版本树带来的收益基本用不上；需要上传多张参考图，开放 Issue 里三条都在提这件事，说明这项能力当时还不完整，可以等它落地再评估；打算把项目嵌进闭源产品分发，先看清楚 LGPL-3.0 的义务再动手。

使用这类工具还有一层边界要自己把握。生成和编辑过程中，图片会被发送到你配置的模型服务，素材能不能出本机、服务商的条款怎么规定，需要自己确认；用他人肖像、商标或受版权保护的素材做编辑和融合，也要先取得授权，误用带来的责任由使用者承担。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.1 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。