scenario-fan-cam

场景：球迷镜头

概述

球迷镜头分两阶段制作：先通过保留身份特征的图像编辑，将人物放入 16:9 的转播静帧中；再通过图像转视频，将审核通过的静帧制作成反应镜头。上传的照片仅用作身份参考，而不是起始帧：直接将其输入视频模型，只会让肖像动起来，而不会呈现转播画面。第一阶段成本低，第二阶段则不然，因此静帧应包含所有值得审核的决定。

仅使用用户本人的照片，或已获本人许可的人物照片；拒绝将名人或陌生人放入画面。如果遇到拦截，真人面孔比大多数主体更容易触发提供商的过滤机制；请参阅 scenario-moderation。连接方式和核心流程请参阅此仓库中的 scenario 技能。如果此处提到的某个关联技能不在你可用的技能中，请让用户安装它（npx skills add scenario-labs/skills --skill <name>）；若无法等待，请根据工具架构继续操作，并指出这一缺失。

快速参考

使用 recommend 发现成员，并传入该阶段的能力和用户自己的描述：它会根据实测成本和延迟进行排序，并指出专用工具；而使用能力描述进行 search，会返回数百条关键词匹配结果，让人无从选择。按照 scenario 技能的说明，选择前先查看 next_step。仅当你已能说出成员名称时才使用 search。切勿将生成模型的 ID 写成常量。下文会直接列出 Scenario 自有的单一用途工具模型：每种只有一个，发现它们只会重新得出常量。

阶段	内容	详情
1. 身份静帧	图像编辑成员（img2img）将人物合成到 16:9 的人群画面中	scenario-image、scenario-consistency
2. 静帧审核	在投入任何视频费用前，将人物相似度与照片进行比对	scenario-asset-analysis
3. 制作动画	根据审核通过的静帧生成图像转视频，呈现反应过程和一次镜头移动	scenario-kling、scenario-video
4. 身份审核	从片段中提取帧，并与审核通过的静帧进行比对	scenario-asset-analysis
5. 叠加元素	以后期图层合成比分条、频道标识和下栏信息，绝不通过生成来制作	scenario-text-overlay、scenario-video-assembly
6. 衍生版本	根据 16:9 主版本制作 9:16 和 1:1 社交媒体剪辑	scenario-formats

转播画面要有转播的感觉，才能让镜头可信；因此，两个阶段的提示词都要明确写出这些要求：长焦压缩效果，前景和背景中的人群虚化；使用刺眼的体育场泛光灯或场馆频闪灯；轻微运动模糊；摄像机搜索并重新构图，直到找到主体。让人物处于中景，身处其他球迷之间，偏离画面中心，并采用转播摄像机的高度。居中、光线充足、与视线齐平的主体，看起来会像是在体育场拍摄的写真，而不是转播中的切镜画面。

为反应过程设计一个变化弧线，而不是单一状态：先毫无察觉，然后注意到摄像机或屏幕，最后呈现用户要求的反应（欢呼、大笑、难以置信、心碎）。按照该视频系列的约定编写多节拍提示词，能让转变在一个片段内完成。

示例：在体育场大屏上看到自己，8 秒

1. 收集照片、运动或赛事、场馆氛围、服装，以及期望的反应。 使用 upload_asset 上传一次照片，并重复使用返回的 asset id。
2. 在首次生成前创建本次运行的集合（collection_create，目录写入通道，仅填写 name），然后每有一项入选内容，就使用 collection_add_assets 将其添加；它返回的 itemCount 就是回执。
3. 使用 capability="img2img" 调用 recommend，并用文字描述画面位置；优先选择支持多张参考图的排名靠前的条目，并通过 model_schema_get 查看这些输入 （该通道使用 scenario-image，参考图规范使用 scenario-consistency）。
4. 编辑提示词：“参考图中的人物坐在灯火通明的足球场人群中，16:9 电视转播切镜，长焦压缩人群效果，画面中无文字、徽标或图形”。保持底图没有文字：叠加内容稍后再加。
5. 审核静帧：使用 asset_display 展示以供批准，并通过 scenario-asset-analysis 的分析通道记录必须保持一致的肖像特征（脸部轮廓、发际线、肤色、服装）；任何已记录特征发生变化都判定失败。无人值守时，这份记录可代替用户签核。
6. 使用 capability="img2video" 调用 recommend，并用文字描述反应，然后根据 scenario-kling 或 scenario-video 检查候选项。时长要求会筛掉不符合条件的成员：duration 通常是固定枚举值，成员要么支持，要么不支持；支持该时长的档位价格差异往往很大，因此对每个候选项调用 model_schema_get，并使用 model_run 的 dry_run=true 进行比较。
7. 使用已批准的静帧作为起始图，并设置两个节拍：“她在聊天，没有察觉”，然后“她发现自己出现在体育场大屏上，起身欢呼”；使用一次缓慢的重新构图移动，设置 wait=false，超时后使用 pending_job_ids 再次调用 jobs_wait，绝不重复调用 model_run。
8. 使用平台生成的帧，将片段与已批准的静帧进行比对：先通过 asset_get 获取免费的 firstFrame 和 lastFrame，再通过 model_scenario-video-to-image-seq 获取片段中间帧（根据 scenario-video-editing，这是工具模型通道）。任何预算下，本地提取都不能替代此步骤，因为它不会生成可归档或审计的资源，也会导致审核门槛失去可追溯性。任何已记录特征发生变化都会导致片段不通过；可读的生成文字也同样如此：即使提示词要求无文字，场边广告牌和大屏字符仍会逐渐出现，片段后段尤其明显。重试时必须使用同一张静帧作为起点，绝不能从出现偏差的输出开始。
9. 使用 model_scenario-compose-video 在平台上合成（根据 scenario-video-assembly，这是工具模型通道），并在安全角落叠加来自 scenario-text-overlay 的比分条和频道标识；本地编辑器不适用于此通道。为每个叠加层明确设置 width 和 height，因为文档说明留空时会采用原生尺寸，而且无法保持预期效果；并将 durationMode: "custom" 固定为片段时长，否则图像层会使合成内容超出片段长度。合成任务成功并不能证明图层已正确绘制：从合成视频中提取一帧（免费的 firstFrame），确认每个图层都存在且位置正确后再交付。然后根据 scenario-formats 裁切为 9:16；这是调整尺寸而非重新构图，因为相关视频成员会扩展更宽的画面，而不是裁切画面。其 cover 模式会从中心裁切，因此当主体偏离中心时，应将主画面放在 9:16 合成器画布上，并调整位置以保留主体。对两者都使用 asset_display。

常见错误

• 直接为上传的照片添加动画：必需步骤是制作转播静帧；只有用户提供了已获批准的 16:9 画面时才跳过。
• 让图像或视频模型生成记分牌、频道标识或球衣赞助商文字：生成的文字会逐帧变化；应使用不含文字的画面素材，在后期合成图形。
• 采用人像式布景：居中的主体、讨喜的灯光和周围空着的座位会破坏纪录片的真实感；应让主体置身于正在做出反应的人群中。
• 只看一眼动态片段就判断相似度：变化会在眨眼间掩盖起来；应通过帧提取检查。
• 从已经出现偏差的片段重新尝试，而不是从已批准的静帧开始：错误会不断累积。
• 将主版本设为 9:16：转播画面是 16:9；竖屏版本是衍生内容。
• 整个片段都保持平淡的情绪：没有先注意、再反应的转折，结果就会像循环播放的人像，而不是球迷镜头。
• 叠加多种镜头移动：只需一次重新构图造成的偏移；人群和反应会带来动态。