scenario-thumbnails

场景缩略图

概述

制作一张封面，让观众在实际观看尺寸下也能看懂其主题。交付内容是指定尺寸的成品图片，使用准确提供的文案，并保留人物身份。连接和生成循环遵循 scenario；图片和参考图规范遵循 scenario-image。精确排版使用 scenario-text-overlay，位置规范使用 scenario-formats，需要保持统一风格的一组图片使用 scenario-consistency。如果这里提到的某个同级技能不在可用技能中，请让用户安装该技能 （npx skills add scenario-labs/skills --skill <name>）；在无人值守的情况下，根据工具架构继续操作，并指出这一缺失。

根据请求确认目标位置、主题或标题、提供的素材、准确文案、所需数量和预算。只询问会影响结果且尚未明确的事项。不要为了让图片更吸引人而虚构人物、徽标、用户评价或游戏功能。区分已获批准的角色参考图与风格示例；后者并不代表可以替换其中的人物或品牌形象。

快速参考

简述	实用构图	生成前检查项
首领或遭遇战揭示	易辨认的威胁和一个清晰可读的动作	轮廓、比例关系、已获批准的角色身份
机制说明	一个清晰的动作及其后果	所描绘的机制确实存在于提供的材料中
补丁或世界更新	以新功能为焦点	内容是已发布还是拟议内容；提供的事实
进度或奖励	状态之间清晰可见的对比	状态标签和奖励声明有依据
创作者主导的开发日志	提供的讲述者和相关游戏主题	出现的是谁、其参考资料以及实际主题
商店胶囊图	针对目标平台设计的构图	应用 scenario-formats；视频封面默认规则不适用于商店

根据简述选择构图，不要强行让每款游戏都采用大脸、照片级写实或夸张反应。方向尚未明确时，在花费资源前提出几个有实质差异的概念；在无人值守的情况下，根据提供的简述选择依据最充分的概念，记录该假设，并在获授权的数量和预算上限内继续。如果缺少必要输入或花费授权，请说明阻碍，不要生成图片。用户选定概念后，按其要求执行。遵守指定的变体数量。不要擅自将单张封面扩展成一批图片。

从需求简述到提示词

用一句话明确视觉呈现目标：观众会识别或了解到什么。设定一个主要焦点主体、辅助动作，以及一片安静区域来放置所需文案。选择缩小后仍能保持清晰的层级，而不是罗列装饰元素。只有当需求涉及明显的对比时，分割画面才有用；两个主体并不意味着必须采用分割布局。

根据实际文案来安排文案区域的大小，而不是默认预留半个画面。在缩小后的预览中比较紧凑的换行方式和主体大小；大块空白面板或较小的焦点角色，都可能削弱原本可编辑的封面。检查所述变化在该尺寸下是否仍清晰可辨。

具体描述主体、动作、构图、配色、媒介和光线。说明每个参考素材的用途，以及必须保持不变的特征。将提供商专属字段保留在通过 model_schema_get 发现的负载中，不要放进通用模板。使用 recommend 匹配能力和用户需求；用户指定模型时使用 search。避免硬编码生成模型版本或质量等级。

目标尺寸和文案都是硬性要求。使用受支持的宽高比和尺寸生成；如果无法获得精确的导出尺寸，则使用文档说明的调整尺寸途径。不要为了达到数值而悄悄裁掉角色或拉伸图像。为提供的精确徽标和文字指定确定的位置。需要文字完全准确时，优先生成干净底图，再使用 scenario-text-overlay；如果用户明确要求生成的文字融入画面，则逐字检查，并在需要时通过受支持的编辑或叠加途径修复。没有提供文案，就不要自创标题。

实例：Boss 战开发日志封面

用户提供了经批准的覆苔石质 Boss 参考图，要求制作一张插画风格的 1280x720 YouTube 缩略图，并使用确切标题 "ONE HIT LEFT"。Boss 有两条手臂、一只琥珀色眼睛，没有嘴。选定的构图是 Boss 位于右侧，下方有一名持盾的小玩家，左侧放文案。授权额度涵盖一次生成和有限修复。

1. 检查参考图并记录身份不变量。如果参考图尚未作为资产上传，请通过 scenario 上传。保留经批准的插画风格，不要替换成照片中的人物。
2. 根据该需求使用 recommend 推荐 txt2img：这是使用角色参考的新构图，而不是重新设计参考图的版式。读取合适的、支持参考图的成员的 model_schema_get。选择载荷前，检查支持的宽高比、参考图数量/基数、提示词限制和尺寸。根据需要将参考图作为架构指定的实际字段、标量或数组传入；不要假设它采用源图/强度编辑约定。若任务是编辑或重新设计现有构图，则使用 img2img。
3. 提示词应描述经批准的 Boss 和动作，并明确留出左侧文案区域。底图上不要出现文字或重复的 Boss。先使用 model_run 和 dry_run: true 为载荷估价，然后在授权额度内提交，并通过 jobs_wait 等待现有 job id。
4. 添加文字前，先将结果与 Boss 参考图对照检查。眼睛数量或轮廓发生变化时，需要进行有针对性的修正；添加文字无法修复身份问题。适当时，使用已接受的底图进行编辑，保留经批准的特征，而不是重新开始创作。
5. 将提供的标题通过 scenario-text-overlay 渲染为透明 PNG 卡片，再用 model_scenario-compose-image 将其合成到底图上。该 id 是固定的，不需要发现，因为它是 Scenario 唯一确定性图像合成器；它只接受图像图层，因此文字绝不会经过模型。检查成品，而不只是浏览器预览。通过 scenario-image/scenario-formats 输出指定的最终尺寸，并读取返回的尺寸。
6. 在 1280x720 尺寸和约 120 像素宽的预览下进行审核。小尺寸预览是一项压力测试，并非通用的平台标准。检查 Boss 和盾牌是否仍然清晰可辨、标题是否易读，以及文案和裁切是否都没有遮住标志性眼睛。检查实际缩小后的图像；仅请求高分辨率并不等于完成这项测试。
7. 通过 asset_display 和 asset_download 交付经过验证的最终图像。保留干净的底图、准确的文字、字体/版式设置以及源/输出标识符，以便修改文案时能够复用美术资源。若仍有未解决的缺陷，应如实说明，不要悄悄将失败的变体标记为已完成。

审核、修订与常见错误

有多个输出时，为每个概念或变体设置稳定的标签，并保留其源角色、载荷、job id 和 QA 结果。等待尚未完成的输出，不要重新提交。仅在剩余额度内重试失败的输出。修订时，将用户意见归类为构图、身份、文案或导出问题；复用已接受的图层，只修改指定部分。更换标题通常需要新的叠加层，而不是再次生成图像。

• 将风格示例当作角色来源，会在未经许可的情况下替换角色身份。
• 大尺寸图像即使很清晰，在信息流尺寸下仍可能层级不清。
• 较长的文案需要做版式决策，而不是自动截断或改写措辞。
• Logo 是需要保留的资产，不是让模型拼写的词。
• 添加用户从未提供的装饰性 UI、奖励和机制，会错误呈现游戏内容。
• 可读性和参考图还原度是可观察的；缩略图审核并不能证明点击率有所提升。