多镜头视频中，每个镜头只有一个明确目标、一个验收标准，更容易控制返工。本篇用 minimax-h3 将商品展示拆成分镜，不保证分别生成的片段拥有完全一致的几何、光线或运动。
先规划剪辑，再生成素材
Section titled “先规划剪辑，再生成素材”用剪辑语言写顺序。以台灯展示为例，下面时长只是方案，不是模型性能实测。
| 镜头 | 预期动作 | 衔接依据 | 验收条件 |
|---|---|---|---|
| A：介绍，5 秒 | 固定视角展示桌上的台灯 | 台灯形状、桌面位置 | 不变形，不多出物件 |
| B：细节，5 秒 | 缓慢靠近灯罩 | 同样的材质与颜色 | 灯罩全程可识别 |
| C：结尾，5 秒 | 保持结束构图 | 同样的朝向与光线 | 留出稳定画面供后期加标题 |
精确品牌标识和最终字幕独立制作，不依赖生成镜头精确呈现文字。分镜表是本地制作记录，不是 API 额外字段。
为每个镜头选参考模式
Section titled “为每个镜头选参考模式”需要约束开场画面或首尾画面时用 frames_images：一个 URL 是首帧，两个 URL 按首帧、尾帧排序。不想固定首帧、只想参考主体时，检查 H3 的普通 images 模式。不要将 frames_images 与 images、videos、audios 混用。
素材必须有使用权限，并保留版本。首帧模式应先准备好原图裁切，构图可能跟随原图，而不是与原图冲突的比例指令。选择路由前，先看 H3 / Turbo 选型指南中的规格和模式限制。
提交一个已规划的镜头
Section titled “提交一个已规划的镜头”下面请求体用首帧描述镜头 B。将占位 URL 换成可读取的获批图片，提交前检查完整实时 schema。
{ "model": "minimax-h3", "input": { "prompt": "一个连续镜头，展示首帧中的桌上台灯。相机缓慢靠近灯罩。保留台灯轮廓、奶油色表面和桌面位置。光线柔和稳定。没有切镜、额外物件或文字。", "frames_images": ["https://assets.example.com/lamp-shot-b-start.png"], "seconds": 5, "resolution": "768P", "aspect_ratio": "16:9" }}按 H3 API 指南发送到 POST /v1/tasks。把返回 ID 与本地分镜 B 关联，再按 Node.js 任务工作流恢复轮询原任务。三个镜头是三个独立管理的任务，本篇不暗示存在分镜或批量提交端点。
检查完整片段和剪辑接点
Section titled “检查完整片段和剪辑接点”完整播放每段，不只看首帧。检查主体是否持续存在、机位运动、画面边缘和需要使用的音频。再把相邻片段放进剪辑时间线，检查切点前后的主体大小、位置、色温和运动是否符合预期。
若要从已通过的片段抽取一帧作为下一镜头的首帧，应在自己的剪辑流程中提取并审核。后续请求仍是新的计费任务，也可能发生偏移。保留原始商品图作对照，不把生成帧视为绝对准确的商品事实。
按镜头恢复与返工
Section titled “按镜头恢复与返工”技术失败记录错误和实际收费结果；任务成功但不符合创意要求时，标记拒收，只调整该镜头的提示词或参考图。自动重复网络请求不能解决“已成功但不可用”的创意问题。
给每个镜头设置尝试预算，用批量预算指南核算合格成片成本。一起保存 镜头 ID → 需求版本 → 素材版本 → 任务 ID → 验收结论 → 费用。不要因为一个镜头返工就重做已经合格的全部镜头。
契约与来源核对日期为 2026-11-03。MiniMax 原生视频 API使用不同封装，平台任务采用上面的 model 和 input。本篇没有执行生成来验证连贯性，也不提供实测连贯性承诺。