在 HiAPI API 上使用 flux-3-max/image-to-video 构建短视频

为什么图生视频适合短视频制作

短视频的成败取决于第一秒。这使静态图像成为你手上最有价值的资产，也使图生视频成为这类工作的自然原语。你从一张已经掌控的画面开始——产品图、人物肖像、风格化背景——然后要求模型将其延展为运动。

与文生视频相比，后者每一次渲染都像重新掷骰子。你描述一个场景，得到某个结果，然后花许多轮迭代试图找回脑海中设想的构图。而在图生视频中，构图、色调和主体身份在生成第一帧运动之前就已锁定。你的提示词只需回答一个问题：从这里开始，什么会改变？

这种分工恰好对应短视频内容的实际生产方式。一部短片很少是一次连续生成——它由若干节拍组成：钩子、演示、反应、收尾卡。每个节拍都可以是一次独立的图生视频调用，由它自己的静态图作为种子，这意味着你可以重新生成某个节拍而不触动其他节拍。

这一原语也契合交付格式。短视频很短，因此每个请求范围明确、推理成本低，输出可直接放入编辑时间线。下游步骤——裁剪、转场、字幕、音频混合——都留在你现有的管线中，而非塞进一次庞大的生成调用里。

图生视频不适用的情况：当你确实需要在一个无法拍摄的环境中实现单一连续的镜头运动，或者镜头没有稳定的锚定帧。在这些情况下，文本驱动的方式更诚实。但对于大多数短视频工作，一个锚定的首帧加上运动提示词，既更可预测，也更容易迭代。

选择真正能动的首帧

图生视频中最常见的失败，是一张漂亮的源图却让模型无从动画化。平坦、均匀布光、构图紧密的画面是一张好照片，却是一个糟糕的种子。在把任何内容送给模型之前，请从运动潜力而非图像质量的角度评估这张静态图。

主体分离

模型需要知道什么该动、什么该保持不动。主体边缘清晰、与背景区分明显，就能给它一个明确的答案。当主体融入背景——色调相近、剪影后方纹理繁杂、大量重叠——运动往往会在整个画面上涂抹开，而不是跟随你的主体。

运动空间

运动需要空间。如果主体从边缘到边缘填满画面，平移或推近就无处可去，肢体运动会发生裁切。留有一点头部空间、可见地面或一侧开放背景的画面，能给模型执行镜头运动和身体动作的余地，而不会在边缘产生伪影。

单一的明确焦点

短视频在手机上观看，第一秒常常处于静音状态。具有单一主导焦点的静态图能瞬间被读懂，并给运动一个主体。拥挤的画面迫使模型分散注意力，得到的片段会显得躁动却并不动感。

景深线索

具备前景、中景和背景的画面——即使定义松散——也能支撑视差。在分层画面上做轻微的镜头运动，能产生令人信服的纵深感。平坦画面则产生幻灯片效果。

实用检查清单

• 是否有一个清晰且可信地能运动的主体？
• 背景是否足够分明，能保持不动？
• 预期运动方向上是否有空白空间？
• 画面在缩小后是否仍然可读？
• 这个场景两秒钟的片段会好看吗？

如果一张画面在其中两项或更多项上不合格，请重拍或换一个种子，而不是试图用提示词来修复。提示词工程无法挽救一个没有运动空间的构图。

为 flux-3-max/image-to-video 编写运动提示词

大多数薄弱的提示词都在描述场景。图像已经做了这件事。运动提示词应该描述随时间发生的变化——什么在动、朝哪个方向、以什么速度，以及在此过程中镜头如何表现。

以动作为先，而非主体

与其写“一个穿红夹克的女人站在街上”，不如写“当她将肩膀转向镜头时，夹克面料随之移动，然后静止下来”。第一种版本只是复述静态图；第二种告诉模型该动画化什么。点名运动元素、运动方向和终点。

明确指定镜头行为

镜头语言是运动提示词中杠杆最高的部分，因为它控制整个画面。有用的模式：

• 固定镜头，主体运动——最安全、最可控的选项。
• 缓慢推近——增加紧迫感，适合钩子。
• 横向跟拍——即使主体静止，也能读作运动。
• 手持漂移——增加能量，但可能引入需要裁剪的晃动。

如果你不指定，模型会替你选择，你就会更频繁地重掷。

在片段内安排运动节奏

描述弧线，而非仅仅是状态。“起初静止，转身在约三分之一处开始，到结尾时画面归于平静”给模型一个时间线。读起来像单一瞬间的提示词，往往产生要么没有运动，要么是匀速漂移，显得机械。

保持简短且具物理感

两到四句话通常足够。优先使用物理性、可观察的动词——转、抬、漂、定、展——而非“感觉”“传达”“戏剧性”这类解释性词汇。关于情绪的形容词属于静态图，而不属于运动描述。

每个镜头一个运动想法

如果你发现自己描述了三个同时发生的动作，那就是三个镜头。拆分开来能得到更干净的渲染，并在某个节拍失败时只重掷它。

组织 API 请求

每次生成都是对 HiAPI API 的一次请求，每个请求都应足够自描述，让你几个月后还能重建它。把请求载荷当作记录，而非草稿纸。

请求的结构

一次 flux-3-max/image-to-video 调用在概念上有三个块：源图、提示词和输出规格。大致如下伪代码：

request = {
    "model": "flux-3-max/image-to-video",
    "input": {
        "image": image_url_or_reference,
        "prompt": motion_prompt,
    },
    "params": {
        "duration": duration_seconds,
        "aspect_ratio": aspect_ratio,
        "seed": seed,
    },
}

图像是你的锚点——传入稳定、带版本的引用，而不是会被覆盖的本地文件。提示词就是上一节中的运动描述。其余都是你应该刻意固定的参数。

固定你想复现的内容

• 种子。在打磨提示词时固定它，让输出的变化来自提示词而非采样噪声。想要多样性时再释放它。
• 时长。短视频偏好短片，让一个序列中各镜头的时长保持一致，时间线的计算就会简单。
• 宽高比。在项目层面一次性选定，所有静态图和输出都从它派生。

用镜头清单包裹请求

把每次生成作为一行存进一个小清单——镜头 id、图像引用、提示词、参数、输出引用。这一单一产物让你可以确定性地重跑任何镜头、对提示词修订做差异比较、追溯哪个输入产生了哪个片段。这就是迭代与猜测之间的区别。

异步处理响应

视频生成不是瞬时的。围绕提交-轮询来设计客户端，把任务 id 与清单行放在一起，并立即将输出写入持久存储，让下游组装永远不依赖某个请求处于活动状态。

组装多镜头序列

短视频是一个序列，构建它的最干净方式是把每个镜头当作一次独立生成，然后在时间线层组装。抵制要求一次长连续渲染的诱惑。

先规划节拍

在生成任何内容之前，先把序列写成镜头清单。对于一段十五秒的片段，三到五个镜头通常合适：一个赢得第一秒的钩子、一两个承载想法的节拍，以及一个落地的收尾画面。每个条目配一张静态图、一个运动提示词和一个时长。

保持跨镜头连续性

独立生成会产生漂移。用三个习惯来保护连续性：

• 共享视觉词汇。使用同一次拍摄或同一风格参考的静态图，让色调和光照在各镜头间匹配。
• 一致的宽高比和时长。统一的片段长度让剪切和转场变得简单。
• 提示词一致性。在意图感受为同一场景的镜头间复用相同的镜头语言描述。

为剪辑而设计

镜头在相接处不必完美匹配——它们需要干净地剪切。在每个片段的头部和尾部多生成一点，这样你就有可供裁剪的余量。在运动中结束一个镜头并切到新角度，远比试图让每一帧都匹配更能掩盖细微的连续性错误。

在模型之外组装

拼接、转场和字幕叠加在你的编辑层完成——脚本驱动的管线或时间线工具。模型的工作是产出好片段；时间线的工作是把它们变成视频。让镜头清单与剪辑保持同步，这样重新生成的片段可以直接放入而无需重建序列。

处理原生音频

flux-3-max/image-to-video 在生成画面的同时生成音频。这很方便，但它改变了你规划序列的方式：音频是生成的一部分，而非后期制作的补充。

为声音而提示，而非仅为运动

如果某个镜头应有特定的声音特征——环境街道噪声、机械嗡鸣、面料摩擦——就在提示词里说明。运动描述往往隐含声音，明确点名有助于模型将音频事件与视觉节拍对齐。如果某个镜头应该安静，也要说明；静音是有效的设计选择，也是有用的对比。

围绕音频事件规划剪切

逐镜头生成的音频在各镜头之间不会连续。这使每次剪切都成为潜在的音频跳变。两种可行策略：

• 在运动处剪切。把转场放在高运动时刻，让声音的不连续读作冲击而非错误。
• 切到底轨。在序列下铺一条连续的音乐或环境音轨，让生成的音频作为质感居于其下，从而掩盖逐镜头的不连续。

尽早决定保留什么

并非每段生成的音频都可用。片段一返回就立即评估，在清单中标记音频是保留、压低还是替换，并让剪辑遵循该决定。在最终组装时才发现一半片段需要替换音频，代价高昂。

留出余量混音

将生成的音频保持在适度音量，并在其上方为旁白或音乐预留空间。原生音频往往密度较高；在混音中留出余量，能保留日后添加解说而无需重新渲染画面的选项。

迭代与成本纪律

打磨是视频项目悄悄变贵的地方。让质量和花费都可预测的纪律很简单：只重跑发生变化的部分。

一次只改一个变量

当某个镜头不奏效时，判断问题出在画面还是提示词。先修画面——它评估起来更便宜，且约束下游一切。画面正确后，在固定种子下迭代提示词，这样你能将差异归因于提示词文本。同时改变图像、提示词和参数，不会告诉你哪个改动起了作用。

用清单作为差异工具

因为每个请求都记录了其输入和参数，重跑就变成机械操作：选出提示词发生变化的行，提交它们，其余不动。一个五镜头序列中修改了一个提示词，应该只花费一次生成，而非五次。

廉价预览，刻意定稿

用较低保真度或较短时长做探索性渲染，以确定构图和节奏，然后在镜头清单锁定后渲染最终版本。探索性渲染用于决策；最终渲染用于交付。混淆两者是预算蒸发的方式。

为整个序列做版本管理

锁定序列时给镜头清单打标签。如果后续更改破坏了连续性，你可以回到已知良好的版本，而不是凭记忆重建提示词。带版本的参数是“可重跑的管线”与“一堆一次性渲染”之间的区别。

按镜头而非按分钟预算

因为每个镜头都是独立请求，成本随镜头数量和修订数量扩展——这两者你都直接控制。按镜头清单规划，让生成花费在你决定增加节拍的那一刻就可见，而不是在月底才看到。当前定价见 HiAPI 定价面板。

从一张静态图和一个运动提示词开始，针对 HiAPI API 上的 flux-3-max/image-to-video，让镜头清单从那里生长。