MiniMax Hailuo 2.3

标准与 Fast 应视为两条不同生产路线，分别记录模型 ID、任务参数、等待、失败和采用结果。

如果把两者混在同一统计中，团队无法判断速度变化是否以动作、细节、表情或镜头遵循为代价。

Hailuo 2.3 同时存在标准与 Fast 路线时，最重要的管理动作是禁止团队只写‘用了 Hailuo’。每个任务必须记录精确模型 ID、入口、时长、分辨率、提示优化设置、镜头指令和输入文件。否则审片人员看到两个不同结果时，无法判断差异来自版本、参数、素材还是随机性，更无法为后续批量制作建立规则。

Fast 的价值要从完整周转而不是单次生成观察。若它更快地产生更多需要返修或废弃的镜头，整体制片周期未必缩短。项目应分别统计请求等待、生成、下载、审片、返修和重新提交，并以合格镜头完成时间为核心。标准版与 Fast 版必须使用相同样本和审片人，任何混合统计都会遮蔽真实取舍。

时长与分辨率组合要在 API 编排前固化成兼容矩阵。制片系统先校验参数是否合法，再提交任务；参数错误、服务错误、内容失败和审片失败分别计数。这样，工程问题不会被误写成模型质量，模型问题也不会被系统重试隐藏。每次官方文档变化后，兼容矩阵需要重新生成并经过小规模回归。

镜头样本不能只选视觉冲击强的动作。短漫剧还需要静态对白、微表情、手部和道具交互、多人走位、镜头运动以及上下镜衔接。测试表应描述可观察问题，例如人物身份、身体运动、物体轨迹、构图遵循和局部闪烁，而不是使用‘电影感’或‘更真实’等无法复核的形容词。

API 返回的任务 ID 应进入项目证据链，与输入哈希、模型参数、输出文件、审片结论和人工修复连接。发行时，最终母版还要补充声音、字幕、生成内容标识、权利和平台回执。Hailuo 官方页面可以证明公开能力存在，只有这条项目链才能证明某个镜头如何被制作和为何被采用。