上一篇写了文本生图，这一篇往后走一步：让画面动起来。视频比图片多了时间维度，也多了一整套异步任务、轮询、转存的工程问题。本文用一个真实跑通的 Spring Boot 项目，把「输入一句话 → 几分钟后拿到一段 mp4」这条链路完整拆开，并给出实测数据、提示词工程方法与真实踩到的坑。
一、先说结论：视频生成和生图，差的不是"加几帧"
很多人第一次接视频模型，会带着生图的经验直接套：传个 prompt、等十几秒、拿 URL。真正上手才会发现三件事完全变了。
第一，输入变了。生图只吃文本；视频模型分成两类：T2V（Text-to-Video，纯文本）和 I2V（Image-to-Video，首帧图片 + 文本）。后者不是"可选加分项"，而是硬性输入——没有首帧，接口直接拒。这也是我实测时遇到的第一个真实报错。
**第二，时长变了。**生图十几秒出图，视频是分钟级。我这次实测：InQueue 排队 1 分钟上下，InProgress 生成约 110 秒，端到端 210 秒才拿到 Succeed。用同步 HTTP 直接等，基本会被网关超时截断。
**第三，结果会过期。**生图的图片链接约 1 小时失效；视频更苛刻——生成结果只保留 10 分钟，返回的视频 URL 有效期 1 小时。也就是说，你的服务必须"一拿到结果就立刻转存"，否则用户第二天回来只剩一个 404。
这三点决定了工程形态：提交与查询必须分离、状态必须轮询、结果必须落地。
二、认清模型：I2V 与 T2V 的分工
硅基流动当前的视频生成模型里，Wan2.2 这一代最常用的两个：
| 模型 | 类型 | 输入 | 输出分辨率 |
|---|---|---|---|
Wan-AI/Wan2.2-I2V-A14B | 图生视频 | 首帧图片 + 文本描述 | 由首帧宽高比决定 |
Wan-AI/Wan2.2-T2V-A14B | 文生视频 | 纯文本 | 1280x720 / 720x1280 / 960x960 |
图 1：视频生成模型
这里有个非常容易踩的点，我实测踩到了：I2V 的输出分辨率跟着首帧走，请求里的 image_size 会被忽略。
我当时传的是 imageSize=1280x720，首帧用的是 1024×1024 的方图，最后产出的是 960×960。对照官方说明才明白：图生视频会按首帧的宽高比自动匹配输出（16:9 → 1280×720，9:16 → 720×1280，1:1 → 960×960）。所以想让成片是横屏，得先把首帧裁成 16:9，而不是改参数。
这也顺带解释了一个产品设计问题：I2V 页面上的"分辨率下拉框"其实是个半失效控件。我的处理是保留它（T2V 需要），但在 README 和页面提示里写清楚"图生视频时以首帧比例为准"，避免用户以为是 bug。
图 2：下拉选的是 1280×720，产出却是 960×960——因为首帧是方图，I2V 按首帧比例出片
**那到底该选哪个？**我的判断很朴素：你要控制画面内容，就用 I2V；你要的是"想象力"，就用 T2V。
- 商品图动起来、老照片复活、角色一致性要求高 → I2V（首帧就是最强的控制手段）
- 概念片头、氛围素材、天空/水流这类无主体强约束的画面 → T2V
三、接口只有两步：submit 拿 ID，status 换结果
视频接口是标准的异步任务模型，比生图多一步，但逻辑很简单。
提交请求：
curl -X POST https://api.siliconflow.cn/v1/video/submit \
-H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "Wan-AI/Wan2.2-I2V-A14B",
"prompt": "生成一条温暖纪实风亲子短视频，主题为“亲情是在日常陪伴中一点点构建出来的”。人物为一位30多岁的父母和6—8岁的孩子，场景包括清晨厨房、放学路上、夜晚书桌、周末公园。画面采用自然光、手持跟拍、生活化构图，色调温暖柔和，轻微胶片质感。叙事从日常小摩擦开始：孩子想说话，父母正忙；随后父母放下手机，蹲下来倾听，和孩子一起做饭、走路聊天、在书桌前耐心陪伴。镜头多用中景和手部特写：牵手、递画、一起洗碗、拥抱。情绪由忙碌、忽略转向理解、靠近和温暖。旁白温柔克制：“亲情不是天生的默契，是一次次蹲下来倾听，一次次放下手机，一次次并肩走路，慢慢长出来的。”结尾画面为傍晚公园长椅上父母与孩子并肩坐着，孩子靠在父母肩上，字幕出现：“陪伴，是亲情最好的构建方式。”背景音乐为轻钢琴加自然环境声，节奏舒缓，结尾留白2秒。",
"image": "data:image/png;base64,....",
"image_size": "1280x720",
"seed": 1162451294
}'
响应只有一个关键字段：
{ "requestId": "yj4ouo64pwq8" }
查询状态：
curl -X POST https://api.siliconflow.cn/v1/video/status \
-H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{"requestId":"yj4ouo64pwq8"}'
成功后长这样（这台机器上的真实返回，字段已简化）：
{
"status": "Succeed",
"reason": "",
"results": {
"videos": [{ "url": "https://s3.6scloud.com/.../output.mp4?X-Amz-Expires=86400" }],
"timings": { "inference": 213.048 },
"seed": 1162451294
}
}
四个状态值要记牢：InQueue（排队）、InProgress（生成中）、Succeed（成功）、Failed（失败，看 reason）。
图 3：提交只给一个 requestId，真正的结果要靠轮询换回来
参数上还有两个细节值得说：
image支持 base64 与公网 URL 两种形态。因为我们的首帧是用户现传的、没有公网地址，所以走 base64 data URL。代价是请求体变大：862KB 的 PNG 转 base64 后约 1.15MB。所以服务端要卡体积（我给的上限是 8MB，实际使用建议先压到 1MB 内）。image_size对 I2V 来说只是"期望值"，真正的输出由首帧决定，前面已经说过。
四、工程实现：三层，各管一件事
沿用项目里生图模块的分层，新增 video 包，职责切得很干净。
Client 层只碰 HTTP，submit 与 status 各一个方法，错误统一翻译成中文：
public String submit(String model, String prompt, String negativePrompt,
String imageSize, String imagePayload, Long seed) {
ObjectNode payload = objectMapper.createObjectNode();
payload.put("model", model);
payload.put("prompt", prompt);
payload.put("image_size", imageSize);
if (StringUtils.hasText(negativePrompt)) payload.put("negative_prompt", negativePrompt);
if (StringUtils.hasText(imagePayload)) payload.put("image", imagePayload);
if (seed != null) payload.put("seed", seed);
JsonNode root = post("/v1/video/submit", payload, "提交视频任务");
return root.path("requestId").asText("");
}
Service 层管三件事：模式判定、任务缓存、结果转存。模式判定靠模型名，简单但够用：
public boolean requiresImage(String model) {
return model != null && model.toUpperCase(Locale.ROOT).contains("I2V");
}
提交前先卡住"该不该有图"，报错信息必须给出可执行的下一步，而不是只抛一句"参数错误"：
if (needImage && imagePayload == null) {
throw new VideoException(model + " 属于图生视频（I2V）模型，必须上传一张首帧图片；"
+ "如果只想用文字，请切换到 Wan-AI/Wan2.2-T2V-A14B");
}
轮询接口是这段逻辑的核心。它不是无脑转发，而是带缓存的状态机——一旦成功并落盘，后续轮询直接返回缓存，不会重复下载：
public VideoTaskState state(String taskId) {
Task task = tasks.get(taskId);
if (task == null) throw new VideoException(404, "任务不存在或已过期，请重新提交");
if (task.finalState != null) return task.finalState; // 终态缓存
VideoRawStatus raw = videoClient.status(task.taskId);
if (raw.failed()) { ... }
if (!raw.succeeded() || raw.urls().isEmpty()) return 中间态;
String localUrl = downloadVideo(raw.urls().get(0)); // 立刻转存
...
}
为什么不把 requestId 直接交给前端、让浏览器去查硅基流动？两个原因：一是会泄露 API Key，二是拿不到"本地副本"这一层——而本地副本恰恰是解决 10 分钟/1 小时时效问题的唯一办法。
Controller 层保持薄，提交走 multipart/form-data（要传图），查询走 GET：
@PostMapping("/api/submit")
@ResponseBody
public ApiResponse submit(@RequestParam("prompt") String prompt,
@RequestParam(value = "negativePrompt", required = false) String negativePrompt,
@RequestParam(value = "model", required = false) String model,
@RequestParam(value = "imageSize", required = false) String imageSize,
@RequestParam(value = "seed", required = false) String seed,
@RequestParam(value = "image", required = false) MultipartFile image) {
return ApiResponse.ok(videoGenerationService.submit(
new VideoSubmitRequest(prompt, negativePrompt, model, imageSize, parseSeed(seed)), image));
}
@GetMapping("/api/status")
@ResponseBody
public ApiResponse status(@RequestParam("taskId") String taskId) {
return ApiResponse.ok(videoGenerationService.state(taskId));
}
图 4：左侧是"输入"，右侧是"等待与结果"，异步任务的所有状态都收敛在这一屏里
前端则是"提交 → 计时器 → 每 4 秒轮询 → 出播放器"：
polling = setInterval(function () { poll(data.taskId); }, 4000);
上限设 15 分钟，超时主动停轮询并提示，避免用户挂着一个永远查不完的定时器。
五、提示词工程：视频比图片更考验"时间感"
如果说生图考的是"画面描述能力"，视频考的是**“用文字写分镜”**的能力。官方给的建议很到位，我实践下来总结成四句话：
**1. 一句话写完整，别拆成多条。**视频模型需要理解"从 A 到 B"的连续变化，断句成列表反而会丢失时序。200 词以内，中文大约 150 字以内最稳。
**2. 从动作开始，而不是从背景开始。**先给"谁在做什么"，再补环境。对比一下：
- 差：
一个雨夜的长沙老街，有很多霓虹灯，地上有积水，有个女孩。 - 好：
女孩在雨中的老街回头微笑，镜头缓缓推近，霓虹在积水里晃动，浅景深。
后者第一句就给出了运动主体，模型才知道"什么在动"。
**3. 明确镜头语言。**推、拉、摇、移、跟随、环绕，“镜头缓缓推近"这种描述对成片的稳定度影响很大。不写镜头，模型容易给一个几乎静止的画面——这也是很多人生成"假视频”（只是轻微晃动）的根因。
4. 光和氛围放在最后。暖黄路灯、霓虹反光、电影感、浅景深 这类词负责质感，放在末尾不会挤占动作描述的位置。
负面提示词同理，别堆砌。我一般就写四个：画面抖动、多余肢体、文字水印、低清晰度。
图 5：首帧是 I2V 的"剧本"
六、实测数据：210 秒，5 秒视频，4MB
不贴"理论上"，直接上这次跑通的记录。
| 项目 | 数值 |
|---|---|
| 模型 | Wan-AI/Wan2.2-I2V-A14B |
| 首帧 | 1024×1024 PNG（862 KB） |
| 请求分辨率 | 1280×720（被忽略） |
| 实际输出 | 960×960，16fps，5.06 秒 |
| 阶段耗时 | InQueue 约 60~100s，InProgress 约 110s |
| 端到端耗时 | 210 秒 |
| 上游推理耗时 | timings.inference = 213.048s |
| 产物大小 | 4.06 MB，H.264 |
| seed | 1162451294 |
几个值得注意的地方：
inference反而比端到端还大（213 vs 210），说明上游的推理计时包含了排队尾部，不能当成纯 GPU 时间看。做计费预估时用端到端更准。- 16fps 不是 24/30fps，这是模型本身的输出规格，不是转码丢失。想要更顺滑只能后期插帧。
- 5 秒是固定档位，不是参数。别指望用 prompt 写"10 秒长镜头"来延长时间。
- 落盘后通过
/generated/**访问，返回HTTP 206+Accept-Ranges: bytes，播放器拖动进度条正常——这一点很重要，Spring 的静态资源处理器默认支持 Range，但如果你自己写 Controller 返回byte[]，拖动就会卡死。
七、踩坑记录
**坑 1：I2V 忘传首帧，报错信息不友好。**第一版服务端直接抛"请求参数有误"，用户根本不知道要传图。改成明确说"该模型必须首帧，想纯文本请切 T2V"，并给出一键切换按钮后，误用率明显下降。
**坑 2：image_size 对 I2V 无效。**前面说过，输出跟着首帧比例走。这个必须写进文档，否则用户会反复调参数、以为接口有 bug。
**坑 3：base64 首帧让请求体暴涨。**862KB 的图转 base64 是 1.15MB。首帧动辄几 MB 的手机原图会很危险——既慢又容易被网关拦。服务端必须卡体积，前端最好先压。
**坑 4：任务状态存在内存里。**单机 Demo 没问题，但多实例部署时，A 实例提交、B 实例查询就会返回"任务不存在"；服务重启后历史任务也全丢。生产环境要换成 Redis 或数据库，键设 2 小时过期（和上游 10 分钟的结果保留期匹配即可）。
**坑 5：忘了"结果会过期"。**第一次跑通时我图省事只存了上游 URL，第二天再打开页面，播放器一片黑。视频比图片更疼——10 分钟后连状态接口都查不到了。唯一正确的做法是 Succeed 那一刻立刻下载转存。
图 6：落盘 + Range 支持，才敢把播放器交给用户拖动进度条
**坑 6：轮询太密。**一开始 1 秒一次，日志哗哗的、还容易触发限流。改成 4 秒一次，配上计时器，体验反而更好——用户看到秒数在走，就不焦虑了。排队阶段尤其如此：不显示任何进度，用户会以为卡死。
八、这套能力能落到什么地方
技术跑通只是开始，真正有意思的是它解决了什么。
① 电商：静态商品图变动态展示。主图 + “镜头环绕，光影流动，背景虚化” → 5 秒动态素材。I2V 的最大价值是主体一致性：商品还是那个商品，只是光在动、镜头在动。这比 T2V 从零生成可靠得多。
② 文旅：一句描述出氛围片头。"雨夜的长沙老街，霓虹倒影，镜头缓缓推近"这种描述，直接就能出可用的空镜素材。这类无强主体约束的画面，T2V 的自由度反而是优势。
③ 教育/科普：概念可视化。“细胞分裂的过程”、“行星在轨道上运行”，文字描述比找素材快得多，5 秒循环片段刚好适合课件。
**④ 内容创作：老照片与插画的"续命"。**一张老照片 + “人物缓缓抬头，看向镜头” → 情绪价值极高。这是 I2V 最天然的用法，首帧就是全部信息。
而工程侧真正沉淀下来的能力，其实不是"调了个视频接口"，而是三件可复用的东西：异步任务的状态机、外部结果的生命周期管理（10 分钟 / 1 小时）、以及把 AI 的不确定性用 UI 讲清楚（排队中、生成中、失败原因、可重试）。
九、小结
如果只用一句话总结这次实践：视频生成的工程难点不在"生成"，在"等待"和"保存"。
- 生成是异步的，所以要有 submit + status 两段式；
- 结果是会过期的，所以要在成功瞬间转存；
- 等待是分钟级的，所以要用计时器和状态文案安抚用户；
- 模型是分类型的，I2V 吃图、T2V 吃字，弄反了就是 400。
AI 能力本身很强——一句中文描述就能得到一个有镜头运动的 5 秒片段，放到两年前是不可想象的。但要把它变成能用的产品，仍然要靠这些"不性感"的工程细节兜住。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/yelangkingwuzuhu/article/details/168966679
