scenario-identity-library

场景身份库

概览

游戏或品牌以具名身份为基础：角色和道具在发布的每张图片中都必须保持可辨识。本技能端到端地处理这一生命周期：访谈了解需求、生成并审核主视觉图、将获批图片归档到具名集合、组装图集，并在制作新图片时重新调用该库。各图的具体机制由同级技能负责，这里不再重复：scenario 负责连接和核心流程，scenario-consistency 负责借助参考图保持外观一致，scenario-quality-gate 负责给出通过／不通过的判定。如果你的可用技能中缺少这里提到的同级技能，请让用户安装（npx skills add scenario-labs/skills --skill <name>）；在无人值守的情况下，根据工具架构继续操作并标出缺失项。

快速参考

阶段	机制	规则
需求简报	访谈，并将答案写成不可更改事项的枚举	生成任何内容之前
锚点	生成主视觉图，并审核至通过	已上传的美术作品跳过生成
资料库	集合命名为 character: <name> 或 props: <name>	仅限通过审核的图片
图集	使用 Grid Maker 组装已获批图片	成员变更后重新组装
重用	使用 collections_list 进行前缀匹配，通过 search 查找成员；参考图遵循 scenario-consistency	之后的任意会话

从访谈到锚点

生成之前先进行访谈：答案将成为后续每张图片都要重申的基准枚举（scenario-consistency），因此此处的疏漏会在之后造成偏差。询问对象是什么、轮廓和比例、调色板的名称或十六进制色值、让它容易辨认的两三个标志性细节（例如破裂的前照灯、黄铜搭扣）、渲染风格，以及这组图片需要哪些视角：单独的全景图无法为参考槽提供足够细节来保持特写一致，因此需要拍摄特写的身份还需要正面面部或标志性细节特写，以及精确的侧面图。非交互式运行需采用任务提供的信息，并标出其余缺失项。用户如果已有美术作品，则跳过生成：根据 scenario-consistency，其绘图或照片就是上传的锚点。

在首次运行前，为整个身份选定一个支持参考图的模型（先用 recommend，再通过 scenario-consistency 中的架构检查）：后续每个视图都要使用该模型的参考图字段，因此不支持参考图的模型应在此处就被排除，而不是等到第三个视图时才发现。生成主视觉图，即背景简洁的中性全景图（整洁的锚点最能让参考槽分离出身份特征：画面中除需求简报要求的内容外不包含任何元素，也不包含文字），然后根据 scenario-quality-gate 进行审核，并预先固定轮次上限（默认值为三轮）；如果缺少该技能及其审核机制，则按需求简报中的枚举进行评审，并使用相同的轮次上限。主视觉图是其他所有图片引用的锚点。

资料库是一个命名集合

使用确切名称 character: <name> 或 props: <name> 调用 collection_create，然后为主形象调用 collection_add_assets（目录工具，写入通道；创建调用只接受名称和作用域对，不包含描述字段）。名称就是注册表键：集合不是 search 的目标，因此后续会话需要通过分页读取 collections_list（读取通道），匹配前缀来找到资料库，然后使用 search 拉取成员（target="assets"、 filters={"collection_ids": [...]}，再加上针对所需视图的 tags 筛选条件，这样就不会把归档的图纸混入参考拉取结果）。准入是把关环节：只有通过审核的图像才能进入，因为之后每次生成都会从这个池中采样，将其视为参考事实；只要有一个成员不符合模型设定，就会污染后续每次拉取。按照基础设定加差异项构建视图基线，每个视图调用一次 model_run，逐一审核，并为每个通过审核的视图添加对应标签后归档（使用 asset_add_tags，如 hero、back 等），这样后续会话就能区分各个成员。重新设计（更换服装、发型、年龄）会改写简报中的枚举内容，需要基于旧版制作新的主形象（遵循 scenario-consistency）：以此重建视图和图纸，并在下次拉取前对已被取代的成员调用 collection_remove_assets，否则一次拉取就会将两个版本都放进参考字段。

图纸是拼装出来的，而不是生成的

Scenario 的 Grid Maker 会将已批准的图像拼成一张图纸：其 ID 是固定的一方工具 model_scenario-grid-maker（这是 Scenario 专用于此工作的唯一确定性工具，因此发现操作只会重新推导出它）；使用 model_schema_get 读取其架构。截至本文撰写时，它接受 images（最多包含 100 个文件的数组；即使只有一个资源也要封装成数组）以及布局字段：columns、在未设置时根据数量计算得出的 rows、padding、backgroundColor，以及固定的 cellRatio 列表（默认值为 auto）。它没有提示词字段：请按阅读顺序排列 images 数组，因为数组本身就是布局。图纸本身也是一个资源，无需审核即可归档（它拼装的是已批准的图像，并非生成结果）：为其添加标签（使用 asset_add_tags，例如 sheet），然后归档；成员发生变化后，应重新构建图纸，而不是编辑它：只拉取带视图标签的成员（切勿只拉取普通成员列表，否则旧图纸会成为网格单元），并使用 collection_remove_assets 替换旧图纸。图纸方便人查看；当模型可用参考槽位不足时，也可将整个转面图压缩到一个参考槽位中；若槽位充足，则优先使用单张已批准图像。

示例：快递机器人 Nima

1. 访谈得出以下简报：圆润的轮廓、铜色外壳、一个有裂纹的头灯、帆布邮差包、赛璐璐着色；视图包括正面、背面、左侧和四分之三视角。
2. 使用简报中的原话调用 recommend；model_schema_get 确认存在真正的参考字段（否则选择下一个候选）；调用 model_run 生成主形象；如果 model_run 返回 job_id 但没有资源，则调用 jobs_wait；按照 scenario-quality-gate 审核并迭代，直至通过。
3. 调用 collection_create 创建 "character: Nima"；使用 collection_add_assets 添加主形象，并标记为 hero。
4. 使用主形象作为参考字段，按照基础设定加差异项生成另外三个视图；通过审核后，为每个视图添加对应标签并归档。
5. 对带视图标签的成员运行 Grid Maker（本会话已持有这些 ID；刚归档的资源可能尚未出现在 search 索引中），将 images 按 [front, back, left, three-quarter] 排列，并设置 columns: 4；为输出添加 sheet 标签并归档。
6. 几周后，收到需求“雨巷中的 Nima”：collections_list 找到 character: Nima，从 search 获取成员，将带 hero 标签的成员和两张符合模型设定的图像放入参考字段，并按照 scenario-consistency 编写提示词。

常见错误

• 未经访谈就开始生成：模糊的需求无法枚举，素材库也会因此偏离预期。
• 收录未经门控的图像：失败的图像会根据 scenario-quality-gate 进行迭代，否则就不会被收录。
• 向 Grid Maker 提示词或期待它进行生成：它只会排列其 images 输入，仅此而已；生成应由视图运行完成。
• 将图像表作为 img2img 的 image 传入：这会锁定构图（scenario-consistency）；图像表只能通过真正的参考图槽位传入。
• 使用自由格式的集合名称：按照约定，Nima stuff 无法查找；character: 和 props: 前缀是查找约定。
• 每个视图使用不同模型：不同模型系列的参考图行为各异；一个经过模式校验的模型即可承载完整身份。