图生视频 vs 文生视频：本质差异与选型

结论先行：漫剧管线以图生视频（I2V）为核心，文生视频（T2V）只用于灵感探索与空镜补镜。本章讲清两者的技术本质差异，以及这个结论的推导过程。

1. 本质：同一个去噪主干，差别只在"条件怎么注入"

文生视频和图生视频共享同一套扩散/DiT 去噪主干（见上一章）。它们的本质差异在于：用什么条件来引导去噪过程，以及条件如何注入。

文生视频（T2V）：提示词经文本编码器变成条件向量，通过交叉注意力注入去噪主干。模型对画面的全部约束都来自这段文字。

图生视频（I2V）：在文本条件之外，把首帧图像的条件注入。主流做法（以开源的 Wan2.1-I2V、CogVideoX 为例）：

• 首帧图像经 VAE 编码成潜变量后分两步就位：先把这个 latent 置于时间轴第 0 位，其余帧位置填零/掩码；再将该张量与噪声沿通道维拼接（channel-concat）；
• 去噪时这段"已知首帧"始终作为强约束存在，模型只需回答一个问题：从这帧画面出发，接下来怎么动？

首尾帧（FLF2V）：I2V 的加强版——首帧和尾帧两端的潜变量都锁定，模型只负责补中间的运动过程。Wan2.1-FLF2V、Runway Keyframes、Pika Pikaframes 及各国产工具的首尾帧功能都是这个原理（海外功能名以各官网当前页面为准）。

参考生视频（多图参考）：再进一步，不限于首帧，把角色/物体的多张参考图特征注入（类似 IP-Adapter 的解耦交叉注意力思路），用于跨镜头的主体一致性。详见角色一致性。

交叉注意力：文字是怎么"参与"去噪的

交叉注意力（cross-attention）是文本条件进入 DiT 的通道，理解它需要三个角色（与数据库查询类比）：

• Query（查询）= 画面 patch 的 token：每个画面小块拿着"我现在该变成什么"的问题；
• Key（键）= 文本 token 的索引：提示词里每个词的"门牌"；
• Value（值）= 文本 token 的内容：门牌后面真正提供的信息。

每一步去噪，每个画面 patch 都拿自己的 Query 去和所有文本 token 的 Key 匹配，匹配度高的 Value 就被大量读取——于是"黑发"这个词的信息流进了头发所在的 patch，"逆光"流进了光源区域。提示词能控制画面局部，靠的就是这个逐 patch 的查询机制（深入见提示词工程，内有注意力映射示意图）。

信息量的碾压：为什么图像条件锁得更死

文字条件和图像条件的控制力差距，可以用信息量直接解释：

条件类型	载体	信息量（量级）
文本提示词	编码后的 token 序列	数十~数百 token
首帧图像	VAE 编码后的 latent	数万 latent 位置 × 16 通道

一帧 1080P 图像的 latent 表示比一段提示词大两三个数量级（按 token 数口径：图像 latent 切 patch 后数千~一万 token vs 文本数十~数百 token）。文字说"黑发眼镜男性"，模型要在训练分布里猜几万种黑发眼镜男性中的哪一个；首帧图直接把答案拍在输入端——脸型、发型、眼镜、服装、配色、构图、光影，全部从"需要猜的开放式问题"变成"已知的既定条件"。

而且注入方式更强：文本走交叉注意力，只是"被参考"；首帧 latent 走 channel-concat，是去噪起点的硬接线——那段位置的数据在每一步去噪中都作为已知量存在，不参与随机采样。约束强度的差距是机制层面的，不是"哪个模型更聪明"。

解耦交叉注意力：参考图怎么"插队"

参考生视频（平台"智能参考/元素/主体库"的底层思路）要解决的工程问题：首帧只能锁一帧的构图，而角色一致性需要"角色特征全程在线"，但又不能让参考图把构图也锁死（否则所有镜头都是一个构图）。

IP-Adapter（2023，腾讯 ARC）给出的方案是解耦交叉注意力：为图像特征单独开一组 Key/Value 投影通道，与文本通道并行存在、互不覆盖——

画面 patch 的 Query ──┬── 文本 K/V（提示词：动作、运镜、氛围）
                     └── 图像 K/V（参考图：角色长相、配色、画风）
                     两路结果加权求和 → 注入去噪

效果上的分工就此成立：参考图管"像谁"，提示词管"干什么"。这解释了两条实操纪律——① 参考图模式下提示词不要复述外貌（两路条件打架，图像路被稀释）；② 参考强度滑块调的就是两路的权重配比：70%~90% 甜区之上，图像路过强会把姿势构图也一起锁死，导致画面僵硬（实操见角色一致性）。

轨迹与运动控制：第四类条件注入

首帧、首尾帧、参考图之外，还有第四类条件——运动轨迹。可灵的"运动笔刷"、各平台的运镜参数化控制都属此类：用户在画面上涂抹主体的运动路径（或直接指定相机运动参数），系统把轨迹/光流编码为空间上稀疏的条件（只覆盖被涂抹的区域），注入去噪主干。它回答的问题从"从哪出发、到哪结束"细化到"中间走哪条路"——与首尾帧互补：两端锁定之外，再给自由采样的中间帧加一层路径约束。漫剧里要求精确走位的镜头（如"摘镜的手从左下向右上抬起"），用轨迹控制比纯文字描述稳定得多。

首尾帧为什么也会"中间漂移"

首尾帧把两端潜变量锁死，但并不等于全程可控：两端之间所有帧仍是自由采样，模型只是在"必须从这里出发、必须到那里结束"的约束下补全路径。首帧与尾帧差异越大（动作幅度大、机位变化大）、时长越长，中间可走的路径就越多，模型越容易走出"抄近道"的怪异轨迹（人物瞬移、动作跳步）。这就是首尾帧单段仍建议 3~6 秒的原因——两端距离近，可漂移的空间就小（时序误差的累积机制见上一章）。

2. 能力对比

维度	文生视频	图生视频
画面可控性	低：构图、角色、色调全靠文字描述	高：构图与角色在你给的图里已经确定
角色一致性	几乎不可控	可由参考图/锚定图锁定
创意自由度	高：适合探索"没见过"的画面	受限于你已产出的图像资产
返修成本	改画面 = 全部重抽	改画面 = 改图（图像可局部重绘），视频只需重抽"动"的部分
典型失败模式	构图漂移、角色每张都变、全片"开盲盒"	动作变形、运镜不听话、中途变脸
漫剧适配度	低	高（核心环节）

3. 为什么漫剧必须以图生视频为核心

回顾漫剧的制作目标：几十到上百个镜头，同一个角色，跨多集不崩。用开发者的话说，这是一次"生产发布"，不是"demo 探索"——可控性压倒一切。

图生视频把一次高风险的生成拆成了两步风险隔离：

1. 图像阶段（确定性高）：关键帧构图、角色、色调在图像模型里反复打磨，直到 100% 满意。图像还能局部重绘、PS 修手——修到完全可控。
2. 视频阶段（随机性高）：视频模型只负责"让这张已确认的图动起来"。即使抽卡失败，损失的只是"动"的成本，构图与角色永远是对的。

如果直接用文生视频，每次重抽都是"构图 + 角色 + 动作"三者一起重新赌——三者同时赌中的概率是各自概率的乘积，抽卡成本指数级上升。

这就是漫剧管线的核心工程思想：把所有能提前确定的东西在图像阶段确定下来，把视频模型的随机性压缩到只剩"运动"这一个维度。

4. 文生视频的正确定位

文生视频不是没用，而是用在漫剧管线的边缘环节：

• 灵感探索：选题期快速生成几段画面测试风格氛围。
• 空镜/转场镜：没有人格化主体的环境镜头（城市夜景、雨天窗边），不存在一致性问题，T2V 效率更高。
• 风格测试：新风格想上项目前，先 T2V 试几个镜头，确认视频模型能驾驭该画风。

5. 选型决策树

镜头里有你的角色吗？
├─ 有 → 图生视频
│   ├─ 动作需要精确衔接前后镜头？ → 加首尾帧
│   ├─ 主体运动路径需要精确指定？ → 叠加运动轨迹控制（运动笔刷等，机制见 §1）
│   └─ 角色需要跨镜头/跨集一致？ → 叠加平台参考图/元素绑定
│       （见 /principles/character-consistency）
└─ 没有（空镜/转场） → 文生视频即可，成本更低

自测

1. 为什么改画面时，I2V 比重抽 T2V 便宜？
2. 空镜/转场镜为什么可以用 T2V？
3. 首尾帧（FLF2V）相比普通 I2V 多解决了什么问题？
4. 参考图模式下，为什么提示词里复述角色外貌反而有害？
5. 首尾帧两端都锁死了，为什么单段时长仍建议控制在 3~6 秒？

查看答案

1. I2V 把构图与角色锁定在图像阶段（可局部重绘、可精修），改画面只需改图，视频只重抽"动"的部分；T2V 改画面 = 构图 + 角色 + 动作三者一起重赌，三者同时赌中的概率是各自概率的乘积，抽卡成本指数级上升（见第 2~3 节）。
2. 空镜没有人格化主体，不存在一致性问题，用 T2V 效率更高、成本更低（见第 4 节）。
3. 首帧与尾帧两端的潜变量都锁定，模型只补中间运动——角色姿态与构图被两端锁死，用于前后镜头的动作精确衔接与无缝循环（见第 1、5 节）。
4. 参考图走的是独立的图像 K/V 通道（解耦交叉注意力），负责"像谁"；提示词复述外貌会在文本通道引入第二份外貌条件，两路条件互相稀释、打架，反而引入漂移。参考图模式下提示词只写动作、运镜、氛围（见第 1 节）。
5. 两端之间所有帧仍是自由采样，模型只被"从这里出发、到那里结束"约束。两端差异越大、时长越长，中间可走的路径越多，越容易走出人物瞬移、动作跳步的怪异轨迹——两端距离近，可漂移的空间才小（见第 1 节"首尾帧为什么也会中间漂移"）。

延伸阅读

• Wan2.1（含 I2V 与首尾帧实现细节）：https://github.com/Wan-Video/Wan2.1
• CogVideoX（I2V 的 channel-concat 注入）：https://arxiv.org/abs/2408.06072
• IP-Adapter（参考图条件注入的奠基工作）：https://arxiv.org/abs/2308.06721