批量生成与产物管理

规模化出图的第一道坎，不在工具，而在用词。当你说"给我来一套"时，技能必须先替你拆清楚：你要的是变体，还是多个资产？这两个词指向两条截然不同的执行路线，一旦混淆，要么浪费调用，要么交出一堆"长得一样却都不对"的图。

n 与"不同 prompt"的根本区别

技能里有一个参数叫 n——同一句提示词要画几张。它的语义只有一个：n 是"同一句话的多个变体"，不是"多个不同的资产"。

换句话说，n=4 给你的是同一个主体、同一种风格、同一套构图意图下的四次掷骰子：四张近似的图，供你挑一张最顺眼的。而"封面 + 头像 + 配图 + Banner"是四个不同的资产，各自有各自的画面——它们需要四句不同的提示词，而不是 n=4。

内置批量：一个资产一次调用

这里要破除一个常见误解："批量"这个词本身，不等于要切到 CLI。你想要很多张图，但没有点名命令行、API 或模型路径——那就留在内置 image_gen。内置模式下的批量法则只有一条：

把"一套小红书 9 图"拆开

假设要为一篇笔记做成组 9 图。它们共享同一套视觉语言（同配色、同字体气质、同 3:4 竖版），但每一张承载的内容不同：首图最抓人、留白最多，后面 8 张分别讲一个点。正确的拆法是——1 句"共享风格基底" × 9 句"逐图内容"：

你只需把这句模板里的占位逐图替换，发 9 次内置调用即可。共享基底那段一字不动地重复出现在每一句里——这正是让 9 张图"看起来是一套"的关键。下面是把这个循环交给智能体的样子：

CLI generate-batch 与 JSONL 批文件

什么时候才动用 CLI 的批量？只有两个条件同时成立：用户明确点名要走 CLI / API / 模型路径，并且确实要一次性跑很多句不同的 prompt。这时 generate-batch 才登场——它需要 OPENAI_API_KEY，并吃一个 JSONL 批文件：每行一个 JSON，描述一个独立任务。

JSONL 批文件属于中间产物，放进 tmp/imagegen/，用完即删；终稿图写到 output/imagegen/。文件名要稳定、有描述性。一个最小批文件长这样：

命名与产物管理

批量一多，文件名就是你唯一的导航。几条原则贯穿始终：

• 稳定且具描述性。 文件名要能让人一眼读懂"这是哪个资产、第几版"。用 xhs-cover.png / xhs-page-03.png，别用 image_final_final2.png 这种。
• 不覆盖已有资产（除非用户明确要替换）。要新版就另存兄弟名：hero-v2.png / item-icon-edited.png。
• 每个交付物都要落地。 批量产物若不逐一移进工作区，等于没交付。
• 舍弃的变体不必留。 用 n 挑剩下的那些近似图、跑废的中间稿，删掉即可——别让它们污染目录。

落地铁律：每个交付物进工作区

内置工具默认把图存到 $CODEX_HOME/generated_images/...。这对"只是预览"足够，但对项目要用的资产是致命的——它不在你的工作区里，发布时就会"找不到图"。批量场景下这条尤其要命：一组 9 张，只要漏移一张，整套就残缺。

1. 生成在默认路径

   内置调用先把每张图落在 $CODEX_HOME/generated_images/。

2. 逐一 move / copy 进工作区

   收尾前把每一个交付物移进项目目录，并按命名规范改成稳定描述性文件名。

3. 校验数量与覆盖

   9 张就该有 9 个文件；确认没覆盖已有资产、没漏移、没把成品只留在默认路径。

最后，无论走内置还是 CLI，收尾时都汇报三件事：每个文件的最终保存路径、用到的最终提示词、以及用了哪种模式。批量场景下，把这三件事按资产列成清单，对方一眼就能核对"该有的都在、都对"。