Wan 2.6 API 生产指南：异步任务、预算护栏、工程师集成
TL;DR
- 把 Wan 2.6 当作异步视频工作流来集成，不要当成实时工具。
- 实际可用的路由切分是：
- 文生视频（text-to-video）：先有创意，再生成视频
- 图生视频（image-to-video）：当首帧很关键时使用
- 参考视频（reference-video）：需要从已有片段延续身份一致性时使用
- 在当前仓库文档中，文生视频与图生视频都被记录为 2-15 秒，而参考视频被记录为 2-10 秒。
- 对生产团队来说，最难的一般不是写 prompt，而是：任务处理、花费控制，以及只在当前端点文档真正支持的地方做路由相关的假设。
1. 选对 Wan 2.6 的路由
理解 Wan 2.6 最清晰的方式，是把它看作三个生产入口，而不是一个泛泛的"视频模型"：
| 路由 | 最佳场景 | 关注点 |
|---|---|---|
| 文生视频（Text-to-video） | 创意发散、分镜草图、脚本优先的生成 | prompt 要结构化，时长要精打细算 |
| 图生视频（Image-to-video） | 产品图、主视觉、品牌安全的首帧 | 输入素材质量和长宽比更重要 |
| 参考视频（Reference-video） | 角色一致性、固定代言形象、身份延续 | 预算逻辑要单独算，它有自己的成本路径 |
生产上最大的错误，就是把这三条路径压缩进同一个心智模型。它们共用同一个家族名，但行为并不一致。
2. 集成模型：先异步
- 提交生成请求
- 立刻持久化任务 ID
- 轮询状态或消费回调
- 尽快保存最终产物，因为生成链接是有时效的
这样一来，你在生产环境要关心的问题就很好预测：
- 围绕重复提交的幂等性
- 轮询上的退避（backoff）
- 结果持久化
- 面向用户的进度状态
- 任务离开你后端之前的预算控制
如果你的内部设计仍然假设"用户点一下按钮就立刻拿到视频"，在流量上来之前先把这个假设改掉。
3. 当前 Evolink 上的路由形态
当前仓库中面向 Evolink 的样例使用的是统一端点：
POST https://api.evolink.ai/v1/videos/generations代表性的模型名包括：
wan2.6-text-to-videowan2.6-image-to-videowan2.6-reference-video
这个统一路由就是你在本代码库中，应用代码应当对齐的集成面。
示例：文生视频
curl --request POST \
--url https://api.evolink.ai/v1/videos/generations \
--header 'Authorization: Bearer YOUR_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
"model": "wan2.6-text-to-video",
"prompt": "A cinematic multi-shot sequence of a runner crossing a neon-lit city bridge at night",
"aspect_ratio": "16:9",
"quality": "720p",
"duration": 10,
"prompt_extend": true
}'示例：参考视频
curl --request POST \
--url https://api.evolink.ai/v1/videos/generations \
--header 'Authorization: Bearer YOUR_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
"model": "wan2.6-reference-video",
"prompt": "character1 walks into a bright cafe, orders a drink, then turns and smiles to camera",
"video_urls": [
"https://your-cdn.example.com/reference-character.mp4"
],
"duration": 5
}'4. 时长与参数的纪律
本仓库当前记录的是：
- Wan 2.6 文生视频：
2-15秒 - Wan 2.6 图生视频：
2-15秒 - Wan 2.6 参考视频：
2-10秒
这一点很重要，因为过时的"只支持 5 / 10 / 15"假设会扭曲：
- 预算计算器
- 前端校验逻辑
- 队列规划
- 面向用户的文案
5. 成本模型与预算护栏
至少要做到：
- 在服务端封顶最大时长
- 在业务用不上 1080p 的场景里封顶最高画质
- 把参考视频的预算与普通 t2v/i2v 的预算分开核算
- 按用户、按功能、按路由追踪花费
- 让重试保持幂等，这样一个抖动的客户端就不会把同一次生成重复计费
参考视频在这里特别重要。即使它属于同一个家族，也应当被当作一条独立的预算路径，因为它的运营成本逻辑跟普通文生视频用法并不一样。
6. 团队真正会遇到的可靠性问题
下面几类反复出现的工程问题，往往比 prompt 技巧更值得关注：
路由漂移
供应商家族会演进。如果你的应用把旧博客里的假设硬编码进代码，而不是对齐当前的路由文档，最终就会在"支持的时长、参数名、计价逻辑"上和线上行为对不上。
素材处理
图生视频和参考视频路由的上限，完全取决于你传进去的素材质量。上传坏图、过期 URL、源素材前后不一致，这些问题会伪装成"模型质量差"的表象，其实全都是管线问题。
异步状态处理
用户感知到的大多数痛点都来自薄弱的任务处理：
- 没有把任务持久化
- 超时处理做得很差
- 重复提交
- 缺少清晰的"pending / running / failed / completed"生命周期
把这几点修掉之后，Wan 2.6 对终端用户来说就会明显感觉更"可投产"。
7. 推荐的工程模式
一个稳健集成的模式如下：
- 在提交之前就校验时长、画质和路由选择。
- 把请求 payload 的哈希和任务 ID 一起存起来。
- 在轮询或队列回调上使用退避。
- 生成完成后立刻持久化最终媒体的元数据。
- 为每条路由分别设定预算上限，避免产品侧不小心把参考视频当成默认便宜路由来用。
一旦真实流量开始打进系统，这套模式比任何 prompt 小技巧都重要得多。
8. FAQ
我的前端应该按什么时长来设计？
2-15 秒，参考视频被记录为 2-10 秒。我可以写一份通用的 Wan 2.6 音频契约文档吗？
不要。除非你已经验证过具体路由页和你对外暴露的端点行为，否则请把音频相关的承诺写成路由级别的，而不是家族级别的。
生产上最安全的默认配置是什么？
在仍然满足产品目标的前提下，使用最便宜的画质和最短的时长，然后只在工作流确实证明需要时，才选择性升档。
什么时候应该用参考视频？
当"与已有片段保持一致性"是产品本身的需求时，才用它。如果不是，就不要默认付出这份复杂度代价。
下一步
- 在 Wan API 家族合集 上对比路由选择
- 如果你还在主力档位和电影级档位之间犹豫，使用 Wan 2.5 vs Wan 2.6 决策指南
- 打开 Wan 2.6 模型页 查看当前总览与价格入口
