通义万相2.2-图文生视频-5b工作流

你大概遇到过这种情况：图生视频的接口接上了，单条能跑，但一上批量就乱——任务排队、超时重试、产物丢帧、想对比两个版本又说不清哪次改坏了。这篇不讲协议也不讲客户端怎么配，只讲工作流怎么搭得稳：参数怎么固化、并发怎么排、失败怎么降级、日志和抽检怎么留痕。

你大概遇到过这种情况：图生视频的接口接上了，单条能跑，但一上批量就乱——任务排队、超时重试、产物丢帧、想对比两个版本又说不清哪次改坏了。这篇不讲协议也不讲客户端怎么配，只讲工作流怎么搭得稳：参数怎么固化、并发怎么排、失败怎么降级、日志和抽检怎么留痕。

另外提醒一句：模型价格、版本差异、限额这类会变的数字，本文一律不写死，需要时到站内对应页面核对当时的数字。工作流本身的搭法是相对稳定的，这才是值得先花时间的东西。

先把任务拆成四段，再谈接口

很多人一上来就问接口怎么调，其实接口是最不该先操心的部分。建议先把一条视频的生命周期拆成素材准备、提交生成、轮询取件、后处理归档四段，每段单独设失败边界。这么拆的好处是，某一环崩了，你知道该从哪儿重跑，而不是整条链路推倒重来。

• 素材准备段：固定画幅比例、首帧来源和命名规则，否则后面批量对齐全靠人肉
• 提交生成段：只负责提交与拿任务号，别在同一个脚本里做裁剪和转码
• 轮询取件段：只管等结果和下载，不管内容加工
• 后处理归档段：与生成段解耦，方便换模型或换参数时只重跑其中一段

四段之间用文件或任务号传递状态，不要靠内存里的变量黏在一起。这样你换模型、改参数、临时插一批急活时，都不用动整条脚本。素材段的命名规则尤其要早定，后面抽检和归档全靠它。

把参数固化成配置文件，别写死在脚本里

时长、分辨率、运动幅度、随机种子这类会反复调的项，全部抽成一份配置，脚本只读不写。写死在脚本里的后果是，你改了三次参数，回头已经说不清哪条视频是哪个配置跑出来的。同一批素材想对比，配置差异必须能一眼看出来。

每次改配置留一条版本记录，写明改了什么、对应哪批素材。参数口径以站内模型资料页为准，别凭印象填；模型资料页的路径是 /models，具体数字到那里核对当时的版本。

并发与排队：让任务稳稳跑完

并发不是越高越好。按账号额度开并发，先用小批量试出稳定并发数，再放大；宁可多跑一轮也别硬顶限流。硬顶的代价是触发限流后整批任务被拖慢，反而更亏。提交、轮询、下载三段分开限流，别用一个池子通吃。

1. 先跑小批量拿十来条素材试跑，观察成功率和平均耗时，找到不触发限流的并发上限
2. 轮询用退避别一秒一次硬刷，采用逐步拉长间隔的策略，减少无谓请求
3. 超时分三档连接超时、单次轮询超时、整任务总时限各设各的，不要一个值通吃
4. 失败进重试队列重试次数上限写死，超限的直接落盘成待人工清单，不要无限重试

整任务总时限这一项最容易被忽略。有些镜头生成就是慢，如果总时限设得太短，会把本来能成功的任务判死；设得太长，又会拖住整个批次。建议按镜头复杂度分档，而不是全局一个值。

产物归档与日志：出问题能复盘

批量跑起来之后，真正让人头疼的不是生成失败，而是「这条视频到底是哪次参数跑的」。所以每条任务都要留一份记录：任务号、输入首帧、参数快照、开始与结束时间、最终状态、产物路径。产物按批次目录存放，文件名带上镜头号和参数版本，避免同名覆盖。

• 任务记录：任务号、首帧、参数快照、起止时间、状态、产物路径
• 目录规则：按批次建目录，文件名含镜头号与参数版本
• 抽检比例：每批固定抽几条人工看一眼，别整批盲信
• 检查重点：首帧是否对上、时长是否达标、画面有无明显崩坏
• 工具口径：日志字段尽量对齐站内质量检查工具的口径，方便后续批量筛查

抽检的重点是首帧对不对、时长对不对、有没有明显崩坏，而不是逐帧审美。工具口径方面，可以到站内 /tools/quality-check 看它的检查项，让日志字段与之一致，后续做批量质量筛查时能直接衔接。

验收与迭代：怎么判断这次改动值得留

验收前先定清单：画面是否贴合首帧、运动是否自然、时长与画幅是否达标、文件能否正常播放。改参数或换模型时，用同一批素材跑对照，只比清单上的项，不做整体感觉式评价。感觉式评价听起来省事，但没法复现，也没法交给别人判断。

线上效果和清单结论对不上时，先查素材与抽帧环节，再怀疑生成环节。很多「模型不行」的结论，其实是首帧选得不对或者裁剪裁歪了。不适用范围也要说清楚：镜头本身要做复杂运镜或多人互动时，图文生视频这条路的稳定性会明显下降，建议先拆镜头，别指望单次生成搞定。

想横向比较不同接入渠道的稳定性和费用，可以到站内导航页看看有哪些可用通道，再到价格追踪页核对当时的数字，避免拿旧记录做决策。