illo

Illo

预检 — 此副本已迁移（请先阅读）

此安装副本来自 tmchow/agent-skills，该仓库不再接收 illo 更新；规范来源现为 tmchow/illo-skill，其中已有更新的 版本。每个会话开始时，在进行任何其他 illo 工作之前：告知用户此副本停留在 0.19.x，并询问是否愿意从新来源重新安装。未经用户明确许可，绝不重新安装。 获得许可后，根据当前运行环境选择对应方式，然后确认新副本已启用，再继续：

• skills CLI（Claude Code、Cursor、Codex 等）： npx skills add tmchow/illo-skill --skill illo
• Hermes：hermes skills uninstall illo，然后运行 hermes skills install tmchow/illo-skill/illo （交互式会话：/skills install tmchow/illo-skill/illo，然后运行 /reload-skills）
• OpenClaw：openclaw skills install illo

如果用户拒绝，就继续正常使用此副本——它可以正常工作，只是不会再更新。同一会话中不要重复询问。

为文字内容创作原创、独特的编辑插画。一张图解释一个想法：一个关键判断、一段流程、一个前后对比、一个陷阱或一个循环。反复出现的吉祥物是每个场景中演绎这一想法的主体——它是主角，而不是装饰。当一个想法逐步推进时，可以做成迷你漫画：在一张图中包含 2–4 个分镜。而当想法本身就是一种可追踪的结构——管线、扇出、时间线或循环——则可以做成解说图：由同一个吉祥物以同一种风格，将结构画成手绘草图图解，并配上箭头和标注 （references/composition.md，“两种表现形式”；编辑场景始终是默认选择）。

这是可配置的品牌风格，而不是通用图像生成器。方法论保持不变；角色包和调色板是可配置参数——角色包也自带其风格：每个角色包采用一种风格，可从内置风格库中选择（riso——颗粒感半色调、墨层错位、纸张纹理、粗犷而圆润柔和的描边；另有 blueprint、woodcut、pixel、clay、manila、chalk、phosphor、enamel 和 gouache），也可使用自定义风格文件。默认吉祥物是 Blot，一滴面无表情的墨水，采用 riso 风格。调色板可从预设、用户自己的调色板文件或单一衍生色中选取。无论参数如何，成图都刻意避免照片、徽标、企业信息图、正式流程图和 UI 模型图的风格。

使用场景 — 为请求选择路径

用户想要	路径
为文章／帖子／新闻简报／URL 配图	步骤 0–7：先为来源选择路径（论点 → 覆盖范围：主视觉／主视觉+组图／组图／迷你漫画 — references/composition.md，“Source routing”），然后列出镜头清单（主视觉行 + 锚点），每个锚点配一张图，并按放置位置交错排列。
为单个概念配一张图	步骤 1 的概念分支（如果想法不够明确，最多问约 3 个简短问题），然后生成一张图。
一个序列 — 流程、之前→之后、失败→修复	如果整个过程发生在同一处，就用一部迷你漫画（在 references/composition.md 中选择形状的路径 — 由想法决定形状，绝不由目的地决定）。
可追踪的结构 — “展示流程”“绘制管道图”“映射步骤”“做成说明图”	使用说明图样式（references/composition.md，“The explainer register”）：以当前视觉风格手工绘制流程／分支／时间线／循环／堆栈／系统切片，让吉祥物成为其中发挥作用的一部分。如果某个单元的论点本身就是结构（样式入口条件），即使用户没有使用上述措辞，也可以采用此样式。
适合社交媒体的美术图	16:9（或 1:1），醒目的 ink-punch 风格；如果已配置或用户提出要求，则使用带 x 账号名的水印。
适配博客／品牌／网站的美术图	使用命名或自定义调色板，或者从一种主色推导调色板（references/palettes.md）。
他们自己的吉祥物 — “给我设计一个角色”“使用我们的吉祥物”“替换 Blot”	使用角色构建器：完整阅读 references/character-builder.md 并从头到尾遵循其中的说明。
社区角色 — “有哪些可用角色”“安装 blip”“更新 mole”“发布我的角色”	参阅 references/pack-sharing.md — 使用引擎命令 packs list/show/install/update，通过 GitHub PR 发布。
不同的视觉风格 — “使用蓝图风格”“木刻风格”“blip 的像素版本”	风格随角色包提供：通过 references/character-builder.md 中的“Style variants”构建一个风格变体包。
提供选项供用户挑选，或回答“哪个模型最好”	步骤 5b：使用 --count 生成多个变体，或循环尝试多个模型 → 将结果放入 gallery 并附上建议。
修复现有图像（多余标题、重新着色、吉祥物过于装饰）	在 references/prompt-recipe.md 中编辑提示词，并将图像作为 --ref 传回。

前置条件

• OpenRouter API 密钥。 通过 scripts/illo.py（Python 标准库，无需安装）直接调用 OpenRouter 图像 API 进行生成。密钥保存在用户的配置文件中 — 这是唯一的凭据渠道 — 由用户运行的 init 命令写入一次（权限模式为 600）。引擎绝不从环境中读取密钥，也绝不接受命令行参数传入的密钥。
• python3 和网络访问权限。无需安装其他内容。
• 引擎支持选择模型（--model）；默认模型可以可靠地生成英文标签，并能使用参考图像保持角色一致性。

设置由用户负责（绝不要亲自输入密钥）

输入 API 密钥应由用户完成。不要输入、粘贴、打印或存储用户的密钥 — 应引导他们完成初始化：

• 初始化（由用户运行）： python3 "$SKILL_DIR/scripts/illo.py" init — 此命令会通过隐藏提示符要求输入密钥（输入内容绝不回显），并写入 YAML 配置文件 ${XDG_CONFIG_HOME:-~/.config}/illo/config.yaml（权限模式为 600）。它 还可以保存非机密默认设置：--model、--palette、--aspect、 --character、--watermark。使用 --no-key 可更新偏好设置，而不 触及已保存的密钥。（如果已安装 PyYAML，则通过 PyYAML 读取配置； 如果没有安装，则内置的简易解析器仍可读取扁平键值 — apiKey、 model 等 — 因此生成无需安装依赖。只有 watermark 等嵌套设置需要 PyYAML： python -m pip install 'PyYAML==6.0.2'。）
• 可以使用相同命令和 --no-key 为用户预设非机密偏好设置， 但密钥必须由用户本人输入。

仅限 Hermes Agent：二进制资源修复预检

某些 Hermes 版本在从 GitHub 安装包含多个文件的技能时会损坏二进制文件（随附的角色设定表）：文本文件不会受影响，但二进制文件会损坏，损坏的设定表还会悄无声息地破坏角色锁定。在 Hermes Agent 下，首次使用前运行一次（以及在 doctor 报告 assets: CORRUPTED 时运行）：

bash ${HERMES_SKILL_DIR}/scripts/repair-hermes-assets.sh

此操作会使用已知正常的 SHA256 哈希值（assets/checksums.txt）验证每个随附的二进制文件，并仅从固定的不可变 URL 重新下载不匹配的文件；如果一切正常，则不会执行任何操作。在 Claude Code、 Codex、OpenClaw 或任何能够忠实安装文件的运行时下，请跳过此步骤；doctor 会在所有环境中检查资源完整性，并在需要修复时提示。

根据需要阅读这些参考资料

不要一次性加载所有内容。根据当前步骤读取相应文件：

• references/visual-style.md — riso，即默认的视觉风格：Risograph 技法、线条语言、纸张与油墨，以及明确的禁忌事项。
• references/styles/<name>.md — 其余视觉风格库（blueprint、woodcut、pixel、clay、manila、chalk、phosphor、enamel、gouache），供角色包使用。生成前，请完整阅读当前角色的风格文件。
• references/character.md — 角色规则（承重测试、避免复杂化的守则、明暗值遵循调色板）、默认角色 Blot，以及自定义包格式。开始任何角色相关工作前请阅读。
• references/character-builder.md — 设计并安装用户自有吉祥物的引导流程。创建或替换角色前请完整阅读。
• references/pack-sharing.md — 从社区仓库安装角色并通过 PR 发布角色包。收到安装或发布请求前请阅读。
• references/palettes.md — 命名预设、默认解析、自定义调色板，以及从单一颜色推导调色板的算法。选择或推导调色板前请完整阅读。
• references/composition.md — 两种表现形式（编辑式场景／解说图），解说图的结构类型与预算、场景调度、将想法转化为动作、禁止重复使用构图的规则，以及镜头列表格式。
• references/models.md — 模型阵容：易读名称到 OpenRouter id 的映射、特性、宽高比注意事项，以及 404／回退处理。传入任何 --model 前请阅读。
• references/prompt-recipe.md — 生成提示词模板，以及编辑／重新着色提示词。
• references/quality-bar.md — 生成后的检查清单和迭代规则。交付前请阅读。

assets/character-reference.webp 是默认角色的规范模型表， 也是一致性的参照（供下文的引擎使用）；自定义包则附带自己的模型表。风格校准示例不会随包提供——每个风格文件都会通过 URL 链接到自己的示例（需要时再获取）：仔细研究线条密度、负空间和强调色的克制用法。切勿照搬示例构图——请为当前作品构思全新的隐喻。

工作流

0. 预检

生成前，请确认引擎已就绪：

python3 "$SKILL_DIR/scripts/illo.py" doctor

请单独运行此命令，切勿与 && 链接——显示的退出代码本身就是就绪信号（0 = 就绪）：相邻命令失败会让健康的检查看起来像是出错。

它会报告 python、配置路径、解析后的模型／调色板默认值、是否存在自定义字符包或自定义调色板文件，以及是否找到密钥（不会透露密钥）；退出代码为 0 表示就绪。断定密钥缺失前，请先查看打印出的配置路径：在 Hermes 中，多配置文件设置可能会将 HOME／XDG_CONFIG_HOME 解析到另一个配置文件的主目录（例如 …/profiles/<name>/home/.config/illo/…），因此看起来像是密钥不存在。如果路径指向了错误的配置文件，请使用正确的 HERMES_HOME／HOME／XDG_CONFIG_HOME 重新运行，而不要认定密钥缺失。如果密钥确实缺失，请停止并让用户自行运行 python3 "$SKILL_DIR/scripts/illo.py" init——不要替他们输入密钥。在聊天会话中，用户无法在当前环境运行命令，因此请先尽量减少他们在主机上需要执行的步骤：自行运行 init --no-key（允许——它会使用默认值生成配置，并添加注释形式的 # apiKey: 占位符，权限为 600，绝不会接触密钥），然后为用户提供两个等效的一次性选项，让他们在运行 Agent 的机器上执行（那台主机属于他们——他们就是在那里安装 Agent 的）：运行 python3 <resolved absolute $SKILL_DIR>/scripts/illo.py init（隐藏输入提示），或打开 ~/.config/illo/config.yaml 并填写 apiKey: 行。密钥绝不能经由聊天传递：不要在消息中索要密钥；如果用户还是粘贴了密钥，也不要使用——请告知他们在 openrouter.ai 撤销该密钥，并在主机上设置新密钥（粘贴的密钥现在已保存在聊天记录和平台服务器中）。绝不要自行将环境变量或其他位置的密钥复制到配置中——只有用户可以填写该行——但有一个明确限定的例外：临时云工作区（Claude Code web、Codex cloud、CI）中，用户通过平台的密钥机制配置了 OPENROUTER_API_KEY。此操作本身就代表用户有意授予该工作区范围内的授权；而且 init 没有交互式提示，也没有持久化主目录——因此，在这种情况下，请仅使用一次工作区密钥生成配置（README.md 中的“云端与 CI”单行命令）。在个人机器上，环境中碰巧存在变量并不能证明用户有此意图（它可能属于其他工具）——规则不变：绝不要复制。

1. 阅读输入——并简要澄清一个不够明确的概念

两种输入，处理方式各不相同：

• URL／文章／粘贴内容／长帖自带上下文——但 切勿从第一个鲜明细节开始生成。先进行路由 （references/composition.md 中的“Source routing”）：判断来源的 形式和体裁，将来源的修辞目的与最适合绘制的细节区分开来，用一句话锁定主要论点（主图要体现 来源的目的，而非最引人注目的证据——体裁规范会说明每种体裁的主图应突出什么），然后先选择覆盖方式——主图、主图 + 每节配图 （完整文章内容）、组图、迷你漫画或分镜列表。组图需要有明确位置：内容简短的来源（一条推文、一个概念）绝不会生成组图——它们的多拍形式就是迷你漫画。找出承重节点——少数几个会引出判断、循环、输入→输出、前后对比或陷阱的地方——切勿每段配一张图。文本已经说明了主题，因此不要盘问用户，但有一种例外：包含多个重要节拍的来源（长文、复盘、多项主张的发布内容）在投入制作多张图片之前，要先询问一个覆盖范围问题——除非用户已经指定了覆盖范围。对于包含多个重要节拍的来源，如果只制作一张图，应明确说明这是主图——而不是整篇内容的覆盖图。

• 一个单独的概念或一句话（例如“画出‘你就是瓶颈’”） 通常没有充分说明要画什么。提出**最多约 3 个简短问题——只问会改变输出结果的问题——然后开始制作。**可询问：

  • 单一要点（读者应该得出什么结论？）；
  • 用途（博客／X／演示文稿 → 决定配色、纵横比和水印）；
  • 形式：一张图（默认）、迷你漫画（一张图片中包含 2–4 个分格——仅当概念本身按阶段推进时才采用），或几张单独的图片——以及任何必须包含的元素或限制。形式应由概念决定，而不是用途（references/composition.md）。

  只进行一轮简短提问，然后继续。若用户已经提供了足够信息、说了“直接做”／“单张图”／“给我惊喜”，或根据上下文答案显而易见，就完全跳过提问。用户的请求明确时，绝不要因提问而耽搁。

2. 确定角色

已安装的角色包位于 ${XDG_CONFIG_HOME:-~/.config}/illo/characters/ （格式和位置详情见 references/character.md）；doctor 会列出 已安装的角色。用户可以保留多个角色包，并在每次运行时选择。按以下顺序匹配，命中第一项即停止：

1. 明确指定——“使用 ”、“以 的形象”：使用该角色包（若用户按名称指定随附默认角色，则使用 blot）。
2. 配置默认项——若用户配置中设有 defaultCharacter，则使用该值。
3. 随附默认角色——Blot（规范见 references/character.md，角色设定图见 assets/character-reference.webp）。

确定角色后，阅读角色包的 character.md，并在所有原本会使用默认角色的地方，使用该角色包的提示词规范、价值观规则和 reference.png。

如果用户想要一个新角色，应使用角色构建器 （references/character-builder.md）；如果用户想要别人的角色，则从社区仓库安装角色包（references/pack-sharing.md）。无论哪种情况，都要先安装，再继续执行这里的步骤。

3. 规划（分镜列表）——用户要求规划或需要制作多张图片时

如果用户要求规划（“应该在哪里配图”“分镜列表”），则在生成图片前先输出分镜列表。每张图片列出：位置、单一想法、表现风格（除非该条目通过说明性内容门槛，否则采用社论风格）、场景安排（或结构类型）、吉祥物在做什么、配色，以及简短的英文标签（各表现风格的预算见 references/composition.md）。根据锚点数量决定图片数量（分段和禁止凑数规则见 references/composition.md）。如果内容中的某一段在同一地点按阶段推进，应规划为一张迷你漫画，而不是多张图片——迷你漫画与单独图片的选择规则见 references/composition.md。

4. 确定调色板（风格就是角色的特征）

风格无法单独解析：它由当前角色的素材包提供——其 character.md 中的 Style: 行会指定一个内置风格（references/styles/<name>.md；riso 对应 visual-style.md），或位于 ${XDG_CONFIG_HOME:-~/.config}/illo/styles/<name>.md 的自定义风格；若没有该行，则默认为 riso。Blot 是 riso 风格。对于任何非 riso 风格，都要完整读取对应文件：该文件提供 STYLE 和 LINE LANGUAGE 提示词区块、调色板映射、角色处理方式以及额外的 QA 检查。若用户要求同一角色采用不同风格，则应构建变体素材包（路由表），绝不能临时改换风格。

调色板：完整读取 references/palettes.md，并按其中的说明解析——该文件包含解析顺序（明确请求，然后依据用户调色板文件中的目标提示，再到配置默认值，最后使用内置 ink-punch）、命名预设、自定义调色板，以及从单个颜色推导调色板的算法。最终必须给出具体的十六进制值；若素材包采用的不是 riso 风格，还要根据该风格的调色板映射转换这些值。

5. 生成——以参考图为准，每张图只用一个隐喻

根据 references/prompt-recipe.md 为每张图构建完整提示词（场景 + 结构 + 风格 + 当前角色的规格 + 已解析的调色板十六进制值 + ≤3 个标签），将其写入文件，然后进行渲染。每次都要将当前角色的模型设定图作为 --ref 传入——这种参考条件能让吉祥物始终符合模型设定；风格和调色板来自提示词，因此二者都可以替换。素材包的设定图以其自身风格制作，因此设定图和风格始终匹配——不要跨风格混用参考图。（使用 Hermes Agent 时，必须先运行上文的资源修复预检，再首次使用 --ref——损坏的设定图会让每次渲染都基于错误信息。）

SKILL_DIR="<path to this skill>"           # contains scripts/illo.py + assets/
REF="$SKILL_DIR/assets/character-reference.webp"   # or the active pack's reference.png

python3 "$SKILL_DIR/scripts/illo.py" generate \
  --prompt-file /tmp/shot-01.txt \
  --ref "$REF" \
  --aspect 16:9 \
  --out "assets/<slug>-illustrations/01-topic.png"
  # --model <id> to override the config/default model for this image

illo.py generate 会为每张图片打印一行 JSON（{path, model, id, cost, width, height, label, prompt}；除非传入 --cost，否则 cost 为 null——gallery 会补填该值），并将相同记录追加到 <out-dir>/manifest.jsonl。 读取 .path——它可能与 --out 不同：引擎会根据实际编码为文件命名（部分模型会返回 JPEG 字节，因此请求的 .png 会生成 .jpg）。使用 .width/.height 检查是否生成了正方形图片，而请求的是 16:9（此时应重新生成）。 每张图片都要单独生成——绝不要将多个想法合并到同一画布中。默认宽高比为 16:9；社交媒体图片使用 1:1，竖版图片使用 9:16/4:5。传入 --label 可添加在图库中显示的说明文字。

整组图片看起来要像出自同一位艺术家之手。 对于任何多图组，第一张通过完整质量标准的图片（绝不能使用未经审查的渲染结果——例如锚点图的地面颜色不符合调色板，就会导致整组图片都出现问题）将成为该组的风格锚点：对于该组后续的每张图片，以及该组成员的每次重新生成，都要将其作为第二个 --ref 传入，放在角色设定图之后，以确保整组图片的线条粗细、半色调密度以及平面或立体的处理方式保持一致。单张图片也可以使用同样的方法锁定风格：将任意一张已完成的示例图作为第二个 --ref 添加。

模型选择。 传入任何 --model 之前（或用户用通俗语言指定模型，或要求“最佳质量”/“最便宜”时），请完整读取 references/models.md：该文件包含易读名称到 OpenRouter id 的映射、各模型特性、宽高比注意事项，以及对 404 错误和回退方案的处理说明。解析顺序为 --model > 配置中的 model > 内置默认值。

水印/署名（可选，默认关闭）。 此技能不提供默认水印——文本仅来自用户 watermark 配置映射（从配置文件读取）或用户的明确请求，因此安装者不会继承他人的账号标识。解析顺序、要追加的提示词行以及双次渲染注意事项，见 references/prompt-recipe.md。

5b. 批次与比较（仅在有帮助时）

默认生成一张图片。 仅当用户要求提供选项或进行比较，或者作品足够重要、值得多生成几张时，才进行扩展生成——并且先说明费用会从用户的 OpenRouter 账户扣除（通常每张图片不到 10 美分，具体取决于模型）。N 保持较小（2–4）。使用引擎的原语编排循环：

RUN=$(python3 "$SKILL_DIR/scripts/illo.py" newrun)      # -> /tmp/illo/<runid>
# record the user's VERBATIM request (URL, pasted text, concept) — the
# gallery shows it as provenance so anyone can tell what the run was for:
printf '%s' "<the verbatim request>" > "$RUN/request.txt"
# (a) VARIATIONS — same prompt+model, pick-the-best:
python3 .../illo.py generate --prompt-file p.txt --ref <ref> --count 4 --label "draft→ship" --out "$RUN/v.png"
# (b) MODEL COMPARISON — loop the SAME prompt over the chosen models
#     (full OpenRouter ids from references/models.md):
for m in <model-id-1> <model-id-2>; do
  python3 .../illo.py generate --prompt-file p.txt --ref <ref> --model "$m" --label "$m" --out "$RUN/$(basename $m).png"; done
# (c) CONCEPT VARIATIONS — different prompts (different stagings) for one idea:
python3 .../illo.py generate --prompt-file staging-A.txt --ref <ref> --label "as a funnel" --out "$RUN/a.png"
python3 .../illo.py generate --prompt-file staging-B.txt --ref <ref> --label "as a crossing" --out "$RUN/b.png"

python3 "$SKILL_DIR/scripts/illo.py" gallery "$RUN" --title "<the piece or request>" --open
# always pass --title so a saved gallery stays identifiable later;
# add --embed for a single portable file (images inlined)

每次 generate 都会自动记录到 $RUN/manifest.jsonl；gallery 会将它们汇总到同一页面，并为每张图片展示标签、模型、尺寸、费用以及可折叠的提示词——提示词切换控件让概念变化对比更易读（提示词是变化项）。始终连同推荐一起展示图库，不要只提供原始结果；在聊天会话中，则直接在聊天里展示带标签的候选项，而不是图库（第 7 步中的交付路由）。多模型失败按图片分别处理（某个模型不可用时，只会导致该次渲染报错）；保留其余结果。

6. QA 与迭代

根据 references/quality-bar.md 检查每张图片。如果吉祥物只是装饰元素或不符合锁定规范、主体的颜色值与配色方案不符、标签文字位于彩色填充区域上、强调色蔓延到角色的强调色部位及 1–2 个元素之外、出现了不需要的标题栏、构图照搬示例，或文字拼写错误，则重新生成或编辑。主体大小会因每次运行而异——如果主体太小，则重新生成（检查 JSON 中的 .width/.height：请求 16:9 却得到正方形图片时，应重新生成）。重新生成取代某次渲染后，使用 --exclude <superseded label> 重建任何交付图库（可重复使用），以免被淘汰的结果出现在审核材料中。

7. 交付——匹配会话的媒介

适当时，将最终成品复制到用户的工作文件旁；未经用户要求，绝不覆盖 现有素材。文件名承载用途——它们是文档附件中唯一保留下来的元数据， 因此要让文件名能明确识别用途：主视觉使用 00-hero-<slug>.png，然后按 内容顺序为各章节锚点使用 01-<section-slug>.png、02-<section-slug>.png，……，存放于 assets/<slug>-illustrations/。然后报告：图片数量、所用配色，以及哪些图片最出色、哪些可选——对于任何多图 任务，还要提供一份放置图：每张图片一行，注明文件名、用途（主视觉，或位于哪个章节之后），以及它传达的一个核心想法，让用户无需重新推导计划，就能将每个文件放到合适的位置。根据当前会话实际可用的方式交付图片本身：

• 文件系统会话（IDE/终端 Agent——Claude Code、Codex、Cursor）：报告每个最终成品的绝对路径（引擎 JSON 中的 .path 已经是绝对路径），多图任务还要展示图片集。磁盘上的文件本身就是原件——此处绝不输出 [[as_document]]：这是 Hermes 网关令牌，在其他运行时中只会成为无意义文本。如果运行时有自己的聊天内文件交付功能，请使用该功能。

• 聊天会话（用户使用消息平台——Hermes over Telegram/Discord/WhatsApp，或任何媒体传输可能有损且用户无法打开本地文件的聊天平台）：仅提供路径并不构成完整交付；图片必须发送到聊天中，而且最终成品必须以原始文件形式发送。平台的图片发送功能会重新压缩图片——这正是会破坏 Risograph 颗粒、半色调纹理、油墨层错位和精细手写字的原因——因此最终成品须作为文档附件发送。在 Hermes 中，为每个最终成品添加明确的 MEDIA: 附件标记——标记为 MEDIA: 紧接绝对路径，中间不留空格，并在同一条回复中加入字面指令 [[as_document]]。最终成品不得只提供裸绝对路径：裸路径可能会作为普通文本传给用户，而不是作为附件发送。

  MEDIA:/absolute/path/to/final.jpg
  [[as_document]]
  

候选方案/选项轮次可以使用普通的行内图片发送，方便用户快速浏览——请注明“预览——原始文件稍后发送”，但最终成品绝不能以这种方式发送。聊天会话中不要使用 HTML 图片集——用户不方便打开或托管它；请直接发送带标签的最终成品，并在文字中给出建议。只有在用户明确要求便携式文件时，才构建 gallery --embed（一个独立文件），并使用 [[as_document]] 将其发送。

聊天会话中发送最终回复前，请检查：

• 每个最终成品的路径都来自引擎 JSON 中的 .path，而不是请求中的 --out（实际扩展名可能不同）；
• 回复中为每个最终成品都添加了明确的 MEDIA:/absolute/path 附件标记；
• 除非明确仅发送预览，否则回复中包含 [[as_document]]；
• 交付内容中不包含已舍弃或重新生成的候选图；
• 文字说明了制作内容——角色、配色、最出色的成品；对于成套图片，还要提供放置图（哪个文件是主视觉，哪些图片分别位于哪个章节之后）——不提实现细节。

输出规范

生成前的规划要简短具体。生成后，让图片自己说话——报告制作了什么、放在哪里，不要讲风格理论。标签要少而简短；嵌入图片中的文字越少，生成效果就越可靠。