在 HiAPI 上使用 ltx-2.5-fast/text-to-video 制作短视频

为什么 ltx-2.5-fast/text-to-video 适合短视频创作

短视频是一场体量游戏，而观众的注意力预算很短。你需要大量片段、快速周转，以及一种能毫不犹豫丢弃废片的方式。这决定了哪种生成模型值得接入你的流水线。

ltx-2.5-fast/text-to-video 是 HiAPI API 上的一个文生视频模型，它有两个在这里很关键的特性：它会在生成画面的同时产出原生音频，并且输出1080P。实际效果是，一次调用返回的片段在形态上已经可以直接发布——你不需要把无声视频轨与另外生成的音乐床拼接，也不需要在片段可展示之前先对低分辨率草稿做超分。

模型名中的 fast 指向的正是同样的权衡：以吞吐量优先于极致保真度。对于短视频创作——竖屏片段、钩子、社交平台剪辑——这通常是正确的一侧。你会迭代更多次，而迭代次数比任何单帧都更重要。

一个简单的流水线示意：

text prompt ──► ltx-2.5-fast/text-to-video ──► video track (1080P)
                                          └──► audio track (native)

一个输入、两个输出、一个待管理的资产。本指南后续所有内容都基于这一形态。

在写提示词之前先规划片段

提示词到片段的工作中最常见的错误，是为整段视频写一个提示词。让模型“做一个 30 秒广告”，它会平均各个节拍，产出的东西感觉哪个都不是。先做分解。

把视频拆成镜头单元

写好脚本，然后在每一处视觉变化处切开。每一个切点就是一个生成单元。一条典型的短视频通常落在四到八个单元。为每个单元给出：

• 一个编号和一句话描述发生了什么
• 预期时长
• 音频意图（台词、环境床、纯音乐、静音）
• 关于是否必须与上一镜头在视觉上衔接的备注

让每个请求保持小规模

小单元重新生成便宜，重新排序也便宜。如果第 3 个镜头不对，你重跑第 3 个镜头，而不是整段。把衔接的工作排除在模型的职责之外：如果两个镜头需要流畅衔接，分别生成它们，然后在剪辑器里拼接，而不是要求一个长的连续镜头。

提前确定目标形态

宽高比、时长范围和片段的用途决定其他一切。在第一次请求之前就确定这些，因为之后更改意味着重新生成所有内容。如果你要为多个渠道制作，按渠道分别规划镜头列表，而不是裁切一个母版——构图差异足够大，裁切会看起来像裁切。

把镜头列表当作纳入版本控制的数据。产出了好片段的提示词就是资产，你会希望它和消费它的代码一起放在版本控制里。

能产出可用片段的提示词模式

写提示词要像结构化的镜头描述，而不是散文。稳定的模板给你可复现性：当重试成功时，你知道是哪个字段变了。

五个字段

[subject]   who or what is on screen, with concrete visual detail
[action]    what happens during the shot — one continuous motion
[camera]    framing, angle, and movement (e.g. slow push-in, static wide)
[lighting]  time of day, source, mood
[audio]     what should be heard: dialogue, ambience, music character

一个填好的示例：

subject: a woman in a canvas work jacket, mid-30s, workshop background
action: she lifts a ceramic mug from a shelf and turns it in her hands
camera: static medium shot, slight shallow depth of field
lighting: warm afternoon window light from camera left
audio: quiet room tone, faint hum of a kettle, no music

站得住的规则

• 每个镜头一个动作。 一个提示词里两个动作会在它们之间折中。如果镜头需要第二个节拍，那就是两个镜头。
• 描述可见的东西，而不是它的含义。 “她看起来松了一口气”没有给模型任何东西。“她的肩膀落下并呼出一口气”给了它可渲染的东西。
• 明确说明镜头行为。 不说明镜头行为是通往不可用片段最快的路，因为模型会选一个你不想要的默认值。
• 具体说明音频意图。 原生音频意味着提示词会影响声音。说清楚你要台词、环境声、音乐还是静音——不要让它隐含。
• 避免否定堆叠。 “不要文字、不要水印、不要多余的人”往往会招来被点名的东西。改为描述你想要的画面。

保留提示词日志

你发送的每一个提示词，都存储完整文本加上参数。当片段有效时，提示词是可复用的产物；当它失败时，日志告诉你漂移的是提示词还是参数。

通过 HiAPI API 发起请求

生成通过 HiAPI API 进行，模型标识符为 ltx-2.5-fast/text-to-video。调用是一个单一请求：你发送提示词和生成参数，返回一个作业，其结果就是片段资产。

最小请求形态

确切的字段名和支持的范围来自 API 文档中该模型的参考页——在硬编码任何东西之前先去那里查看。下面的结构展示了一个可用调用的形态：

curl -X POST "https://api.hiapi.ai/v1/video/generations" \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ltx-2.5-fast/text-to-video",
    "prompt": "static medium shot, a woman in a canvas work jacket lifts a ceramic mug from a shelf and turns it in her hands, warm afternoon window light from camera left, quiet room tone with a faint kettle hum",
    "duration": <clip length in seconds>,
    "resolution": "1080p"
  }'

把 duration 占位符替换为模型接受的值。只发送你需要的内容：提示词、时长、分辨率，以及参考页列出的任何宽高比或音频控制项。

最低限度要发送什么

• 模型标识符，与发布完全一致
• 用你的模板组装好的完整提示词
• 时长，从模型支持的范围中选择
• 输出分辨率，当模型允许你选择时

把响应当作作业，而不是文件

把每个响应当作作业记录：一个标识符、一个状态，以及——完成后——对资产的引用。把作业标识符与你的提示词和参数一起持久化，这样你库里的每个片段都能追溯回产生它的请求。

把 API 密钥保持在服务端，并从环境注入。不要在客户端构造提示词。

下游处理原生音频与 1080P 输出

调用返回的是已经带音轨的 1080P 片段。你接下来做什么决定了这是否有意义。

组装前先审看

每个片段都完整尺寸、不静音地看一遍。具体检查两件事：

• 音画同步。 原生音频是与画面一起生成的，不是从画面推导的。确认声音与动作匹配——拿起杯子不应该听起来像关门。
• 音频电平与特性。 生成的音频可能比你预期的更响或更轻。在以单位增益放入时间线之前检查峰值。

快速拒绝。审看时需要修复的片段，通常重新生成比修复更便宜，尤其当修复点在提示词里时。

组装，而不是重新生成

用你们团队已经在用的剪辑工具把镜头剪在一起。因为每个镜头回来时都是完整的 1080P 资产，组装就是普通剪辑：修剪头尾、设置转场点、在你添加的画外音下把音频压低。

在原生音频能发挥价值的地方保留它。随画面生成的环境床和房间底噪通常比叠上去的素材音轨更贴合，因为它们是为那一帧生成的。只在你需要特定人声或授权音乐的地方替换音频。

为目标渠道导出

导出为目标平台期望的编解码器、宽高比和时长，并在批量生产之前用样本导出对照该平台的要求做验证。1080P 源给你为不同宽高比重新构图的余地，但重新构图后要重新检查构图——你认可的画面可能经不起裁切。

把迭代成本和质量控制在可控范围

生成按你请求的工作量计费——片段长度和分辨率都会影响一次调用的成本。这意味着你的迭代纪律就是你的成本控制。三个刻意的做法：

先重新生成，再重写

如果片段接近但不对，把同一个提示词再跑一次。生成并非完全确定，第二个样本有时能清除轻微瑕疵。如果同一提示词两次重跑都以同样方式失败，问题就在提示词——改它。

一次只改一处

当你编辑提示词时，只编辑一个字段。如果你同时改变主体、镜头和光照而结果变好了，你什么可复用的都没学到。单变量迭代会收敛；散射式编辑产生的片段你无法复现。

区分提示词问题和参数问题

问失败发生在哪个轴上。构图、动作和情绪是提示词问题。长度、分辨率和格式是参数问题。通过缩短片段来修复构图问题浪费一次调用；通过重写提示词来修复长度问题同样如此。

按顺序升级

1. 重跑同一提示词。
2. 调整一个提示词字段。
3. 更改一个参数（时长、分辨率）。
4. 重新设计镜头。

大多数可修复的片段在第 1 步或第 2 步解决。跳到第 4 步是让便宜的迭代变昂贵的方式。

最后，限制尝试次数。在你的作业层为每个镜头设置重试上限，达到就停止——这个镜头需要重新思考，而不是另一个样本。

常见失败模式及如何调试

大多数提示词到片段的问题都落在少数几个类别里。以下是每类首先该看的地方。

片段与提示词不符

首先检查提示词的具体性。模糊的主体和未说明的镜头行为是常见原因。用五字段模板重写镜头，并明确镜头行为。

动作混乱或分裂

你可能要求了不止一件事发生。把镜头拆成两个生成单元，每个只含一个连续动作。

音频与画面不匹配

查看提示词的音频字段。如果你让它隐含，模型就选了一个默认值。直接说明音频意图——环境声、台词、音乐特性或静音。

片段长度或形态不对

这是参数问题，不是提示词问题。验证你发送的值在模型参考页列出的范围内，并确认你的客户端是按预期序列化它们，而不是丢弃了它们。

请求失败或超时

按顺序检查：模型标识符拼写与发布完全一致；API 密钥存在且有效；请求体是有效 JSON；未超出速率限制。生成是异步工作，所以响应慢不一定是失败——轮询作业而不是重新提交，否则你会为同一个片段付两次钱。

多次运行结果不一致

一定程度上是预期的。记录每个提示词和参数集，这样你能区分真正的回归与正常波动，并保持你的重试上限不变。

最快的调试循环总是相同：拉取作业记录，读取实际发送的确切提示词和参数，一次改一个字段，直到片段与你规划的镜头一致。