garden-skills gpt-image-2 技能实战：用结构化 JSON 模板生成动漫 Key Visual 主视觉图
garden-skills gpt-image-2 技能实战：用结构化 JSON 模板生成动漫 Key Visual 主视觉图
导读
本文围绕 garden-skills 仓库中 gpt-image-2 技能的分镜叙事模板 anime-key-visual.md 展开，系统讲解如何用一张图承载整部作品的"动漫主视觉（Key Visual）"：从适用场景判定、缺失信息提问顺序、主模板 JSON 结构、参数策略到三种实用变体，并延伸到仓库源码层的渲染与执行链路。读完本文，你将掌握一套可直接复制运行的动漫 KV / 轻小说封面 / 游戏卡面提示词工程方法，以及它在 Garden 本地生图（Mode A）与宿主委托（Mode B / C）两种工作流中的落地方式。
一、模板定位：什么是"动漫 Key Visual 单图"
在 gpt-image-2 技能的分层模板体系中，anime-key-visual.md 属于 references/storyboards-and-sequences/（分镜与叙事序列）分类下的一个单模板文件。它的核心哲学是：一张图代表整部作品——把所有世界观、角色关系、氛围浓缩进一个强叙事的单画面里。
它面向的具体产出物包括：
- 动漫 KV / 主视觉
- 轻小说封面
- 同人志封面
- 动漫海报
- 游戏卡牌主图（不含 UI）
该模板的典型视觉特征可以概括为五条：
| 特征 | 说明 |
|---|---|
| 画面密度 | 一张图聚集多个角色，或单角色 + 极强氛围 |
| 构图与灯光 | 戏剧性构图、戏剧性灯光 |
| 画风 | anime / 半写实风格 |
| 比例 | 通常竖版 3:4 或 4:5 |
| 版面 | 必须预留 title 位（标题安全区） |
值得注意的是，整个 references/ 体系由方法论总文档 prompt-writing.md 统摄，它定义了"一级分类目录 + 二级单模板 Markdown 文件"的目录规则，并规定每个模板文件必须包含「适用范围 / 何时使用 / 提问顺序 / 主模板 / 参数策略 / 自动补全策略 / 变体 / 避免事项」。anime-key-visual.md 正是这一标准的忠实实现，也是理解整套模板体系的最佳样本之一。
二、何时使用：与相邻模板的边界判定
模板明确给出了"使用"与"不要使用"两条判定线，这也是做模板路由（template routing）时的关键决策依据。
使用条件（满足其一即可命中本模板）：
- 用户提到"动漫 KV / anime 主视觉 / 轻小说封面 / IP 海报"
- 用户希望一张图就能讲完世界观
- 用户希望 anime 风格的高完成度大图
不要使用（需改路由到同分类或相邻分类的其它模板）：
| 场景 | 应改用模板 |
|---|---|
| 多分镜叙事（一页多格讲故事） | manga-spread-page.md |
| 4 格段子 / 反转漫画 | four-panel-comic.md |
| 真实人物大片 | founder-portrait.md |
| 电影级概念大场景（无角色主角化、重场景） | concept-scene.md |
这一"边界表"设计在技能层面非常重要：SKILL.md 要求 Agent「按任务类型只读取最贴近的具体模板文件，不要一次性全读整个 references/」，因此正确的路由判定直接决定了出图质量。
三、信息采集：缺失信息优先提问顺序
KV 是"信息高度浓缩"的产物，缺任何一个关键维度都会让画面失真。模板给出了严格的提问优先级，Agent 在渲染 prompt 之前必须按此顺序澄清：
- 作品 / 主题——这是 KV 的灵魂，缺失时画面没有叙事锚点
- 主角形象（数量 + 关系）——决定构图的角色权重分配
- 世界观 / 时代 / 氛围——决定场景、色调与情绪基调
- 风格：现代 anime / 90s anime / 半写实
- 是否需要 title 位——决定是否预留标题安全区
- 比例——竖版 KV 通常
3:4/4:5
这里遵循 prompt-writing.md 的提问总原则："精准、少量、只围绕模板关键字段，不要泛泛而问"。例如不要问"你想要什么感觉"，而应直接问"作品主题是什么？主角有几位、彼此是什么关系？"。同时要遵循「能合并的问题尽量一次问完」的用户输入工具规则（见 SKILL.md 的"用户输入工具"章节），避免反复打断用户。
四、主模板拆解：动漫 Key Visual 单图的 JSON 结构
模板的核心是一份完整的 JSON 提示词结构模板。需要强调：这份 JSON 是"提示词结构模板"，不是 API 请求体模板（SKILL.md 的"重要约束"明确说明），最终交给图像模型的始终是渲染后的 prompt 字符串。它本质上把 KV 的所有决定因素显式声明出来，让模型没有自由发挥的空间。
完整主模板如下（含默认值，可直接运行）：
{
"type": "动漫 Key Visual",
"goal": "生成一张可作为动漫 / 轻小说 / IP 主视觉的单图",
"ip": {
"title": "{argument name=\"ip title\" default=\"霜白幻想曲\"}",
"tagline": "{argument name=\"tagline\" default=\"这场雪，下了一千年\"}"
},
"characters": {
"count": "{argument name=\"character count\" default=\"3\"}",
"items": [
"{argument name=\"character 1\" default=\"少女主角，银白长发，蓝瞳，雪白连衣裙\"}",
"{argument name=\"character 2\" default=\"剑士同伴，黑发，战甲\"}",
"{argument name=\"character 3\" default=\"小动物伙伴，雪白狐狸\"}"
],
"composition_relationship": "{argument name=\"composition\" default=\"主角居中，同伴左右护卫，动物在脚边\"}"
},
"world": {
"scene": "{argument name=\"scene\" default=\"冰封城市，远景城堡，飘落雪花\"}",
"lighting": "{argument name=\"lighting\" default=\"冷蓝主光 + 暖金边缘光\"}",
"atmosphere": "{argument name=\"atmosphere\" default=\"史诗、孤独、坚定\"}"
},
"style": {
"art_style": "{argument name=\"art style\" default=\"现代 anime + 半写实 + 厚涂背景\"}",
"color_palette": "{argument name=\"color palette\" default=\"冰蓝 + 月白 + 暖金\"}"
},
"title_block": {
"enabled": "{argument name=\"title block enabled\" default=\"true\"}",
"main_title": "{argument name=\"main title\" default=\"霜白幻想曲\"}",
"sub_title": "{argument name=\"sub title\" default=\"FROZEN FANTASIA\"}",
"position": "{argument name=\"title position\" default=\"画面顶部居中\"}"
},
"aspect_ratio": "{argument name=\"aspect ratio\" default=\"3:4\"}",
"constraints": {
"must_keep": [
"主角作为绝对视觉中心",
"灯光方向统一",
"色板严格统一",
"标题与主角不重叠"
],
"avoid": [
"角色塞太多导致脸部小到不可识别",
"背景过亮淹没角色",
"色板出现额外鲜艳色",
"标题字体过多种类"
]
}
}
4.1 字段职责与设计意图
对照 prompt-writing.md 推荐的通用骨架（type / goal / subject / scene / layout / style / details / constraints），KV 模板把 subject 细化成了 ip + characters，把 scene 细化成了 world，并新增了 KV 专属的 title_block。各字段职责如下：
type：模板类型名（"动漫 Key Visual"），用于模型理解这是一张 KV 而非其它类型画面。goal：图像用途声明，直接写明"可作为动漫 / 轻小说 / IP 主视觉"，避免模型画出"插图感"而非"海报感"的画面。ip：作品名 + 宣传语（tagline）。tagline 是 KV 情绪浓度的重要来源（如默认的"这场雪，下了一千年"）。characters：角色数量、逐个形象清单与构图关系。composition_relationship是 KV 与普通插画的关键分野——它把"谁在画面什么位置、谁是谁的衬托"显式写死。world：场景 + 灯光 + 氛围三段式。注意灯光被单列为一个字段，这是 KV"戏剧性灯光"特征的直接落实。style：画风 + 色板。KV 的色板要求"严格统一"，通常控制在 3～4 种主色以内。title_block：是否启用 title 位、主标题、副标题、位置。这是 KV 区别于概念插画的功能性标志。aspect_ratio：竖版 KV 默认3:4。constraints：must_keep（必须出现）与avoid（必须避免）双列表，是通用骨架中constraints字段职责的具体实现。
4.2 参数策略：必问 / 可默认 / 可随机
模板把每个字段按 prompt-writing.md 的参数三分法标注：
| 类别 | 本模板字段 | 说明 |
|---|---|---|
| 必问（缺失显著影响结果） | 作品名、主角、世界观 | 信息不足时按"缺失信息优先提问顺序"主动澄清 |
| 可默认（缺失可用默认值） | 风格、配色、标题位 | 默认值已给出可直接工作的参数 |
| 可随机（可自动补全） | 背景细节 | 仅在风格范围内合理生成，不破坏主体一致性 |
4.3 自动补全策略
当用户明确表示"你来补全 / 随机生成 / 先给我一个 demo"时（prompt-writing.md 第九节的触发条件），模板允许只问最关键的 1～2 个问题，其余走默认：
- 主角数默认 1～3 人——超过 3 人自动切换群像构图思路
- 世界观 → 自动决定配色：冷世界 = 蓝白 / 末世 = 焦土棕 / 校园 = 暖橙。这条"主题 → 配色"映射与 concept-scene.md 的自动补全策略（赛博 = 霓虹 / 武侠 = 水墨 / 末世 = 焦土棕 / 太空 = 深紫）是同一套设计语言
- 默认竖版
3:4
五、三个变体：从单角色强氛围到群像与自动补全
主模板覆盖大多数场景，变体则在主模板结构上做少量字段调整（prompt-writing.md 第十节规定"变体不应完全脱离主模板"）。
5.1 变体 1：单角色 + 极强氛围 KV
适合个人主角、情绪浓度极高的主视觉（如角色个人 PV、小说单行本封面）。核心是把角色压到 1 个，把氛围词提到最高优先级：
{
"type": "单角色 + 强氛围 KV",
"characters": {
"count": 1,
"items": ["{argument name=\"character\" default=\"长发少女，逆光\"}"]
},
"world": {
"atmosphere": "孤独 + 神秘"
},
"constraints": {
"must_feel": "电影海报感"
}
}
注意这里使用了 must_feel（而非主模板的 must_keep）——变体可以按需引入额外约束键，只要不推翻主模板的骨架。
5.2 变体 2：群像 KV（5+ 角色）
适合动画首播主图、团队 IP 集结海报。构图上采用金字塔式层级：
{
"type": "群像 KV",
"characters": {
"count": 6,
"composition_relationship": "金字塔构图：主角顶 + 配角围绕"
},
"constraints": {
"must_feel": "团队感、史诗、可作为动画首播主图"
}
}
5.3 变体 3：自动补全模式
用户只给一句作品概念，其余全部自动决定：
{
"type": "动漫 KV 自动补全",
"mode": "auto-fill",
"rule": "用户给一句作品概念，自动决定主角、构图、世界观、标题",
"constraints": {
"must_feel": "可直接首发"
}
}
mode: "auto-fill" 是整套模板体系统一的自动补全标记，同类用法也出现在 four-panel-comic.md、manga-spread-page.md 等模板中，属于可跨模板复用的约定。
六、避免事项：KV 最常见的翻车点
模板末尾给出了一份"失败模式清单"，这些是渲染 KV 时必须写进 avoid 约束或人工把关的红线：
- 不要让角色数量超过 7——超过 7 个角色，画面中个体脸部会小到无法识别，主视觉立刻失去"主角感"
- 不要让灯光方向不统一——多光源、方向混乱会毁掉 KV 的戏剧性
- 不要让标题盖在主角脸上——title 位必须与主角错开
- 不要使用超过 4 种主色——色板一旦突破 4 色，"统一感"就会被稀释
- 不要让背景细节超过角色细节量——背景是衬托，不是主角，细节量必须让位给角色
这五条与主模板 constraints.avoid 中的"角色塞太多 / 背景过亮 / 额外鲜艳色 / 标题字体过多"互为补充，构成 KV 出图质量的硬性校验标准。
七、源码级落地：从 JSON 模板到最终图片的执行链路
模板本身是提示词工程资产，真正的出图能力由 gpt-image-2 技能的脚本层承担。理解这条链路，KV 模板才能真正"跑起来"。
7.1 三种运行模式（做任何任务前先判定）
SKILL.md 明确要求：第一步必须先确定当前运行模式，用轻量探测脚本：
node skills/gpt-image-2/scripts/check-mode.js
# 拿结构化结果给上层程序用：
node skills/gpt-image-2/scripts/check-mode.js --json
三种模式的判定条件与行为差异：
| 条件 | 模式 | 是否调用脚本 | prompt 落盘 | 图片落盘 |
|---|---|---|---|---|
ENABLE_GARDEN_IMAGEGEN 为真 且 有 OPENAI_API_KEY |
A（Garden 本地生图） | ✅ generate.js / edit.js |
✅ 自动 | ✅ 自动 |
ENABLE_GARDEN_IMAGEGEN=1 但没 KEY |
A? | ❌（先要 KEY） | — | — |
| 未启用 Garden 且 宿主有图像工具 | B（Host-Native 委托） | ❌（用宿主工具） | 可选 | 由宿主决定 |
| 未启用 Garden 且 宿主无图像工具 | C（Advisor 顾问） | ❌ | ✅ 必须 | ❌（无法） |
- Mode A：完整跑通"选模板 → 填字段 → 渲染 prompt → 调脚本 → 出图落盘"，是唯一真正持有图像工具的端到端模式。
- Mode B：技能退化为提示词工程指引，把渲染好的 prompt 直接传给宿主自带的
image_generation/dalle/nano_banana/ 图像 MCP 等工具。 - Mode C：技能退化为高质量 prompt 顾问，只产出可复用的 prompt 文本，不能假装出图成功。
7.2 Mode A 下的生图命令
在 Mode A 下，渲染好的 KV prompt 可以通过以下两种方式喂给生成脚本：
方式一：直接传文本 prompt（适用于短 prompt）
node skills/gpt-image-2/scripts/generate.js \
--prompt "动漫 Key Visual，冰蓝月白色调，竖版 3:4，预留顶部标题位……" \
--size 1024x1536 \
--quality high
方式二：用提示词文件（推荐，KV prompt 较长且需版本管理）
node skills/gpt-image-2/scripts/generate.js \
--promptfile garden-gpt-image-2/prompt/anime-kv-20260424-153045.md
脚本的完整参数可见 generate.js 的 help 输出：--model、--size、--n、--quality（auto | high | medium | low）、--background（transparent | opaque | auto）、--moderation（low | auto）、--output-format（png | jpeg | webp）、--output-compression（0～100）等。
从 generate.js 的 run() 可以看到完整调用链：
loadAmbientEnv()按process.env→<cwd>/.env→<cwd>/.gateway.env→~/.gateway.env的顺序加载环境变量（shared.js）readPromptInput()读取--prompt或--promptfile内容savePrompt()把最终 prompt 落盘到garden-gpt-image-2/prompt/<task-slug>-<timestamp>.mdbuildPayload()组装请求体，其中model优先级为 CLI 参数 >OPENAI_IMAGE_MODEL> 默认gpt-image-2（shared.js）postJson()向{OPENAI_BASE_URL 或 https://api.openai.com/v1}/images/generations发起 POST（shared.js）extractGeneratedBytes()优先解析data<a href="https://link.gitcode.com/i/299c26dcb0048df8b5fd39b1b22903f5" target="_blank">0].b64_json，兼容data[0].url（[shared.js）saveImage()落盘到garden-gpt-image-2/image/<task-slug>-<timestamp>.png
7.3 环境变量：KV 生图前需要配好的东西
| 变量 | 是否必需 | 说明 |
|---|---|---|
ENABLE_GARDEN_IMAGEGEN |
Mode A | 模式开关，取 1 / true / yes / on 时启用 Mode A |
OPENAI_API_KEY |
Mode A | 实际调用图像 API 必需 |
OPENAI_BASE_URL |
可选 | 默认 https://api.openai.com/v1，可指向任意 OpenAI 兼容网关 |
OPENAI_IMAGE_MODEL |
可选 | 默认 gpt-image-2，可换成 gpt-image-1 / dall-e-3 等网关支持的型号 |
值得注意的是，整个技能"默认实现按 OpenAI 兼容接口工作，不写死任何第三方网关"（SKILL.md），KV prompt 的渲染与模型选择因此完全解耦。
7.4 输出约定与命名规则
除非用户显式指定，所有产物按以下约定落盘：
- 提示词：
garden-gpt-image-2/prompt/<task-slug>-<timestamp>.md - 图片：
garden-gpt-image-2/image/<task-slug>-<timestamp>.png
其中 <task-slug> 由任务语义自动提取（如 anime-kv），<timestamp> 形如 20260424-153045。命名与目录创建逻辑实现在 shared.js 的 buildDefaultImagePath / buildDefaultPromptPath / savePrompt 中。KV 任务跑完后，Agent 应按 SKILL.md 的要求用一句话向用户交代：当前是什么模式、prompt 落在哪、图（如有）落在哪。
八、实战流程：一次完整的动漫 KV 生成
把以上所有部分串起来，一次完整的 KV 生成遵循 SKILL.md 定义的模式感知工作流（前 6 步三模式共用，第 7 步按模式分叉）：
- 跑
check-mode.js确定模式（A / B / C） - 判断任务类型：这是"生图"任务（生成动漫 KV），不是"改图"
- 路由到分类：
storyboards-and-sequences→anime-key-visual.md - 只读该模板文件，不读整个
references/ - 按 JSON 模板渲染：命中主模板的
{argument ...}参数，default标记的字段可用默认值 - 澄清关键信息：按"作品名 → 主角 → 世界观 → 风格 → title 位 → 比例"顺序，只问缺失且显著影响结果的项目（如"作品主题是什么？主角有几位？"）
- 按模式分叉出图：
- Mode A：prompt 落盘
garden-gpt-image-2/prompt/，调用node skills/gpt-image-2/scripts/generate.js --promptfile ... - Mode B：把渲染好的 prompt 传给宿主图像工具
- Mode C：prompt 落盘后直接展示给用户，附"如何使用"建议
- Mode A：prompt 落盘
- 一句话汇报：模式、prompt 路径、图片路径
九、总结
anime-key-visual.md 是一个结构完整、可直接落地的"单图主视觉"提示词模板：它通过 ip / characters / world / style / title_block / constraints 六组字段把"一张图讲完一部作品"的所有决定性因素显式化，通过"必问 / 可默认 / 可随机"的参数策略控制信息采集成本，通过单角色强氛围、群像、自动补全三个变体覆盖从个人 PV 到动画首播主图的不同强度需求，最后用五条避免事项守住 KV 出图质量的底线。把它放进 gpt-image-2 的三模式工作流中，再配合 generate.js 与 shared.js 的调用链，即可完成从一句用户需求到一张落盘 KV 图的完整闭环。
如果你想在同一主题上扩展能力边界，可以继续阅读同一分类下的 manga-spread-page.md（多分镜叙事页）与 four-panel-comic.md（4 格段子漫画），以及方法论总文档 prompt-writing.md（JSON 模板设计规范）。