图生视频 API 工作流：Runway、Wan 2.7、Vidu 与生产环境 API 模式

你手里有一张静态图片——一张产品渲染图、一张已签核的主视觉、一张角色设定图——你需要让它动起来。不是生成一个大致相似的新场景，而是让那一帧本身动起来。这正是图生视频（i2v）所做的事情，而它与“输入提示词然后指望模型画出你脑海中画面”是截然不同的集成方式。本文是实操版本：准备源图、控制运动起始与结束的位置、编写能驱动动画而非重新描述画面的提示词，并处理好轮询与回调，避免一次长达数分钟的渲染拖垮你的后端。

还在纠结是否要使用 i2v 而非文生视频？本文假定你已经做出决定，并希望把 i2v 用好。

何时适合使用图生视频

当起始帧不可妥协时，就该使用 i2v。模型不是在凭空创造主体；它接收你的图片并添加运动，因此任何必须保持品牌一致或造型一致的内容都能得到文生视频无法保证的安全保障——真实 SKU 的产品图、将已批准的主视觉转化为页头循环动画、保持面部一致的角色设定图，或者固定起始帧和结束帧、让模型填充过渡过程的 before→after 效果。如果主体是灵活的，文生视频通常工作量更小。i2v 的核心价值就在于静态图是固定的。

2026 年的图生视频格局

i2v 领域竞争激烈且门槛很高。作为背景值得了解，尽管下文可调用的工作流运行在一个精选模型集上：

• Runway Gen-4 / Gen-4.5。 Gen-3 Alpha 的后继者；推动了跨镜头的“世界一致性”以及基于物理的运动和刻意的运镜。Gen-4.5 的 i2v 被广泛视为广告或客户交付物中追求紧凑创意控制的最佳选择（Runway Research，“Introducing Runway Gen-4，”2026；ZNIX 模型汇总，2026）。Gen-4.5 图生视频也已上线 HiAPI，模型 ID 为 runway-gen-4.5/image-to-video；参见 Runway Gen-4.5 API 指南。
• Vidu Q3。 围绕首帧和尾帧条件构建——起始帧、目标结束帧、提示变化，它填充中间部分——最高支持 16 秒 1080p 带音频（Vidu，“AI Image to Video，”2026）。
• Kling 3.0。 擅长从参考静态图生成复杂的人体运动，原生支持 4K 和唇形同步（TeamDay.ai，“Best AI Video Models 2026，”2026）。
• Seedance 2.0。 字节跳动的模型（2026 年 2 月 12 日）能在帧间保持产品细节、标志和文字稳定——正是电商 i2v 所需要的（opencreator.io，“AI Video Models Comparison 2026，”2026）。

强模型之间的模式是一致的：首帧控制是基本要求，尾帧控制不再稀奇，而锚定两端是防止片段在最后一秒发生漂移的最可靠方法。下文的工作流正是围绕这一原则构建的。在 HiAPI 上，你可以调用的两个 i2v 模型是 Seedance 2.0（字节跳动）和 Wan 2.7 图生视频（阿里巴巴）。

第 1 步——准备源图

这是人们经常跳过、然后怪罪模型的步骤。使用 i2v 时，你的第一帧就是质量的天花板。发送任何内容之前，需要做好三件事：

• 将宽高比与输出匹配。 以 4:3 渲染源图却请求 16:9 的片段，模型就必须裁剪或填充——你失去了对最终保留内容的控制。先确定输出比例，再按该比例制作静态图。Seedance 还接受 adaptive 比例，自动匹配源图尺寸。
• 以你想要的输出分辨率渲染。 480p 的源图不会变成清晰的 1080p 片段；对模糊输入进行放大只是让模糊动起来。
• 干净地构图主体。 清晰、不杂乱的主体让模型更少误判。杂乱的背景和模糊的边缘正是奇怪运动的来源。

然后托管它。API 以 URL（first_frame_url）接收源图，而非文件上传，因此它必须能通过 HTTPS 访问——你的存储桶、CDN、签名对象存储。localhost 路径或 API 无法抓取的链接会导致任务失败。

第 2 步——带首帧提交任务

在 HiAPI 上，每个模型（包括视频）都通过一个异步任务 API 运行。你创建一个任务，立即获得一个 taskId，渲染在服务端进行。将文生视频变成图生视频只需一个字段：添加 first_frame_url。以下是最小调用，使用 Seedance 2.0：

curl -X POST https://api.hiapi.ai/v1/tasks \
  -H "Authorization: Bearer sk-<your-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedance-2-0",
    "input": {
      "prompt": "Slow cinematic push-in, a soft light sweep travels across the surface, the subject holds steady and in focus",
      "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg",
      "aspect_ratio": "16:9",
      "duration": 5,
      "resolution": "720p",
      "generate_audio": false
    }
  }'

这就是完整的图生视频请求。重要的输入字段：

• first_frame_url — 用于生成动画的静态图；它的存在正是 i2v 的关键。
• aspect_ratio — 匹配源图（或使用 adaptive）。
• duration — 输出秒数；越长成本越高，也给运动更多漂移的余地。
• resolution — 480p / 720p / 1080p；主要的成本调节项。
• generate_audio — 静音循环和产品图请关闭。

完整的请求和响应结构见文档。Wan 2.7 图生视频遵循相同的创建-轮询-下载流程，但其输入不同——它在 media 数组中携带源帧，输出 720p 或 1080p——因此请查阅文档了解其确切结构，而非直接复用 Seedance 的请求体。

第 3 步——当结局重要时添加尾帧

首帧控制片段从何处开始，并让模型决定如何结束——这正是漂移悄然出现的地方，因为模型在即兴创作后半段。如果通过最后一帧的连续性很重要，也要把它固定住：

{
  "model": "seedance-2-0",
  "input": {
    "prompt": "The product rotates a quarter turn and settles, light resolving to a clean studio key",
    "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg",
    "last_frame_url": "https://cdn.your-domain.com/assets/product-three-quarter.jpg",
    "aspect_ratio": "16:9",
    "duration": 5,
    "resolution": "720p"
  }
}

现在两个端点都固定了，模型只填充它们之间的运动。这是产品揭晓和 before→after 过渡的主力模式，也是解决“片段直到最后一秒都很好”的最有效单一修复方法。保持两帧处于同一主体和构图——如果起始和结束图像差异过大，模型就必须在它们之间凭空创造路径，你又回到了猜测的状态。

第 4 步——为静态图编写运动提示词

提示词在 i2v 中承担不同的职责，弄错会浪费渲染。在文生视频中，提示词构建整个场景。在图生视频中，模型已经能看到场景——它就在你给的帧里——因此提示词的职责是随时间的变化，而非内容：

• 以运镜开头。 “Slow dolly-in”、“gentle pan left”、“push-in then hold”。运动模型能可靠地遵循运镜动词；明确给出一个。
• 描述主体如何运动，而非它是什么。“Steam begins to rise”、“the fabric sways”、“the screen wakes and glows”。你在编排动画，而非重新列举物体。
• 不要重新描述画面。 重述源图中显而易见的内容会与模型对抗，并可能将其拉向重新生成而非动画化。
• 让运动在时长内合理。 一个 5 秒的片段无法承载一个 20 秒的故事。

一个好的 i2v 提示词读起来像给摄影师的动作指示，而非给画家的场景描述。

第 5 步——轮询或接收回调

视频消耗的是 GPU 分钟，而非毫秒。渲染特意设计为异步，因此它永远不会保持连接打开。创建任务后，你有两种方式知道它完成了。

轮询直到达到终态——适合脚本和原型：

curl https://api.hiapi.ai/v1/tasks/<taskId> \
  -H "Authorization: Bearer sk-<your-key>"
# data.status: queued -> handling -> archiving -> success (or fail)
# on success, read data.output[0].url and download it promptly — the URL expires

接收回调适用于原型之外的任何场景。与其坐在轮询循环中，不如传入回调，让 HiAPI 将终态推送给你：

{
  "model": "seedance-2-0",
  "input": { "prompt": "...", "first_frame_url": "https://cdn.your-domain.com/assets/product-front.jpg", "aspect_ratio": "16:9", "duration": 5, "resolution": "720p" },
  "callback": { "url": "https://your-domain.com/hooks/hiapi", "when": "final" }
}

无论哪种方式，输出 URL 都是有时限的。任务一旦变为 success，立即将 data.output[0].url 下载到你自己的存储——不要将其热链接到页面中或交给客户，因为它会过期。

经得起考验的生产模式

几个习惯能将演示脚本与大规模运行的东西区分开来：

• 规模化时优先使用回调而非轮询。 每个任务一个轮询循环是浪费计算和限流压力。一个回调端点下载结果并更新你的记录，其扩展性远好于数百个轮询器。
• 使提交幂等。 重试和至少一次回调都会发生。为每次渲染设置一个稳定 ID（源图 + 提示词 + 参数，哈希化），以便重试不会悄悄产生——并计费——一个重复片段。
• 成本是分辨率 × 时长。 视频按秒计费，费率随分辨率上升，因此 1080p 10 秒片段远贵于 480p 5 秒片段。在 480p 迭代，锁定提示词和运镜，然后只以交付分辨率重新渲染保留的片段。实时费率见定价页面——它们会变动，因此不要硬编码到代码中。
• 按可用片段而非渲染次数做预算。 三个片段中只保留一个，你每个可交付资产的实际成本就是标价的三倍——这个比率，而非每秒费率，决定了你的预算，这就是为什么在 480p 锁定提示词能收回成本。
• 尽早验证源 URL。 API 无法抓取的首帧是最常见的可避免失败——提交前检查它是否可通过 HTTPS 访问。

常见问题

在请求中，图生视频与文生视频有何不同？ 一个字段。任务调用在其他方面完全相同；添加 first_frame_url（源图）即可将其从文生视频切换为图生视频。在 HiAPI 上，两者都通过相同的 POST /v1/tasks 端点运行。

我可以同时控制首帧和尾帧吗？ 可以。first_frame_url 固定起始帧；添加 last_frame_url 固定结束帧，使模型只填充两个固定端点之间的运动。同时固定两端是控制过渡和防止片段结尾漂移的最可靠方法。

Runway Gen-3/Gen-4 API 支持图生视频吗？ Runway 的 Gen-3 和 Gen-4 系列支持图生视频，并在电影级控制方面表现出色——这就是更广泛的格局。本指南中的可调用工作流运行在 Seedance 2.0 和 Wan 2.7 图生视频上，HiAPI 将它们托管在一个任务 API 之后。Runway Gen-4.5 图生视频在同一 API 上运行；Runway Gen-4.5 API 指南中有一个可用的请求示例。

图生视频渲染需要多长时间？ 数分钟，而非数秒——视频是真实计算。这就是 API 异步的原因：你创建任务，然后轮询或接收回调，因此长时间渲染永远不会阻塞你的请求。

要点总结

图生视频适用于当一张特定静态图必须按原样出现在屏幕上然后运动起来的情况。质量天花板在你写下第一个提示词之前就已由源图的分辨率、宽高比和构图决定——因此先准备好它，并将其托管在稳定的位置。固定首帧以控制片段开始的位置，当结局必须落地时添加尾帧，并将提示词写为运动和运镜方向，而非重新描述模型已经能看到的画面。然后将其视为它本来就是的异步任务：轮询，或者更好的做法是接收回调；使提交幂等；在 URL 过期前下载；以交付分辨率按可用片段做预算。

准备好后，将源图通过 Seedance 2.0 模型页面或 Wan 2.7 图生视频运行，然后接入上方的任务 API，并在扩大规模前查看定价页面上的实时每秒费率。（想先找免密钥选项？参见免费文生视频选项。）