# MiniMax H3 分镜实战：首帧参考、镜头衔接与逐镜验收

多镜头视频中，每个镜头只有一个明确目标、一个验收标准，更容易控制返工。本篇用 `minimax-h3` 将商品展示拆成分镜，不保证分别生成的片段拥有完全一致的几何、光线或运动。

## 先规划剪辑，再生成素材

用剪辑语言写顺序。以台灯展示为例，下面时长只是方案，不是模型性能实测。

| 镜头 | 预期动作 | 衔接依据 | 验收条件 |
| --- | --- | --- | --- |
| A：介绍，5 秒 | 固定视角展示桌上的台灯 | 台灯形状、桌面位置 | 不变形，不多出物件 |
| B：细节，5 秒 | 缓慢靠近灯罩 | 同样的材质与颜色 | 灯罩全程可识别 |
| C：结尾，5 秒 | 保持结束构图 | 同样的朝向与光线 | 留出稳定画面供后期加标题 |

精确品牌标识和最终字幕独立制作，不依赖生成镜头精确呈现文字。分镜表是本地制作记录，不是 API 额外字段。

## 为每个镜头选参考模式

需要约束开场画面或首尾画面时用 `frames_images`：一个 URL 是首帧，两个 URL 按首帧、尾帧排序。不想固定首帧、只想参考主体时，检查 H3 的普通 `images` 模式。不要将 `frames_images` 与 `images`、`videos`、`audios` 混用。

素材必须有使用权限，并保留版本。首帧模式应先准备好原图裁切，构图可能跟随原图，而不是与原图冲突的比例指令。选择路由前，先看 [H3 / Turbo 选型指南](/zh/docs/media/minimax-h3-selection)中的规格和模式限制。

## 提交一个已规划的镜头

下面请求体用首帧描述镜头 B。将占位 URL 换成可读取的获批图片，提交前检查完整实时 schema。

```json
{
  "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 指南](/zh/docs/models/minimax-h3)发送到 `POST /v1/tasks`。把返回 ID 与本地分镜 B 关联，再按 [Node.js 任务工作流](/zh/docs/media/video-nodejs)恢复轮询原任务。三个镜头是三个独立管理的任务，本篇不暗示存在分镜或批量提交端点。

## 检查完整片段和剪辑接点

完整播放每段，不只看首帧。检查主体是否持续存在、机位运动、画面边缘和需要使用的音频。再把相邻片段放进剪辑时间线，检查切点前后的主体大小、位置、色温和运动是否符合预期。

若要从已通过的片段抽取一帧作为下一镜头的首帧，应在自己的剪辑流程中提取并审核。后续请求仍是新的计费任务，也可能发生偏移。保留原始商品图作对照，不把生成帧视为绝对准确的商品事实。

## 按镜头恢复与返工

技术失败记录错误和实际收费结果；任务成功但不符合创意要求时，标记拒收，只调整该镜头的提示词或参考图。自动重复网络请求不能解决“已成功但不可用”的创意问题。

给每个镜头设置尝试预算，用[批量预算指南](/zh/docs/media/batch-budget)核算合格成片成本。一起保存 `镜头 ID → 需求版本 → 素材版本 → 任务 ID → 验收结论 → 费用`。不要因为一个镜头返工就重做已经合格的全部镜头。

契约与来源核对日期为 2026-11-03。[MiniMax 原生视频 API](https://platform.minimaxi.com/docs/api-reference/video-generation-v2-create)使用不同封装，平台任务采用上面的 `model` 和 `input`。本篇没有执行生成来验证连贯性，也不提供实测连贯性承诺。

## 对比与实践方法

- [参考素材预检](/zh/docs/media/reference-asset-preflight)

## 更多交付场景

- [对白与音画验收](/zh/docs/media/minimax-h3-dialogue-review)