What-if Studio 与视频生成工作流

前段时间参加南客松 S2 黑客松，和队友一起做了 What-if Studio：输入一句”我不接受这个结局”，系统会组建一个虚拟剧组，几个导演角色在画布里讨论、争吵、提案、分工，最后交付一段可播放的平行结局短片。思路很直接——很多人看完一个故事之后最强烈的感受往往集中在某个节点本可以是另一个走向，这种感觉最后被具象成一个能操作的产品，上线之后也确实拿到了不错的方向反馈。

实现上没走一句话进、一段视频出的黑盒路线，而是把前端做成了一座会动的片场：导演室、主舞台、剪辑区、录音区、素材区全在一张 D3 画布里，导演们陆续进场，讨论内容通过 SSE 实时推，用户可以自由缩放、旁观、查看角色卡片，到了需要素材的环节弹出任务卡，最后进入视频生成。后端是 FastAPI + SQLAlchemy + SQLite，对象流按 Project、Session、VideoJob 分为三层，讨论流和任务流各走独立的 SSE 通道，多智能体用 AutoGen 的 RoundRobinGroupChat 搭了一套导演会，视频生成接了 SiliconFlow 上的 Wan。整条 demo 链路闭环跑通了，方向在黑客松场景下也站得住。

但做完之后越来越觉得，这个 demo 离真正可用还差得远。差距不在模型——视频生成这件事真正难的地方几乎都不在最后那下模型调用，而在前面的拆解、约束、资产沉淀，以及后面的镜头回修与路由决策。这篇文章主要聊的并不只是 What-if Studio 本身，更多是做完它之后围绕视频生成工作流展开的调研和思考，以及下一代应该往哪走。

起点

先说 What-if Studio 当前做到了什么程度。

剧组即界面

聊天框在很多 AIGC 产品里被当成唯一的交互形态，但它把创作过程压缩得过于扁平了——用户只看到一句需求和一个结果，中间的判断、妥协、风格冲突全被吞掉。What-if Studio 前端选了另一条路，把 Agent 做成一个可浏览的片场，这表面上是展示层的选择，背后却非常工程化：只要系统需要承载多个 Agent、多个阶段、多个异步任务，就早晚得有一个能解释当前状态的界面。把这层从一开始就建出来，后面再加镜头规划、资产锁定、失败重试、人工确认节点的时候界面就不会塌。目前前端已经支持了 Agent 运行态可视化、闲聊引擎、剧本审阅弹窗、视频生成进度这些交互，最基本的可观测性算是做出来了。

多智能体的价值

现在的讨论链路是几类角色分工协作，而不是单 Agent 独白。AutoGen 里搭了五个 Agent：Narrative Director 偏叙事逻辑，Visual Director 偏镜头和视觉结构，Sound Director 偏声音设计，Material Director 偏素材选择，Critic 负责收束成 Markdown 脚本并以 FINAL_JSON 输出结构化结果。每个 Agent 开头声明 JOIN 或 SKIP，跳过还是参与让它自己判断，参与的导演以轮询方式各说一轮，最后 Critic 统一汇总。这套设计天然适合放在视频工作流最前面——用户给出的原始需求往往很粗，像”我不接受这个结局""想让某个角色活下来”这种输入，离可执行的视频 prompt 还差很多层，多智能体讨论能在一开始就把需求转成更稳定的中间物：改写原则、情绪弧线、镜头重心、角色保留项、不能碰的设定。对 What-if Studio 这种意难平改写产品来说这一步尤其关键，因为要处理的远不只是生成一个爽感片段，还有原作立场、角色命运、观众心理补偿和影视表达技巧之间的平衡。

现有视频链路的局限

当前这版生成部分，翻一下 video_pipeline.py 就知道，本质上还是把讨论结果压成 prompt，再调用视频模型。它能交付一个结果，也能让整条链闭环，但远没到理想状态——中间产物还很少，没有稳定的角色设定卡，没有场景圣经，没有镜头卡，没有关键帧缓存，也没按镜头去路由模型，脚本和生成之间是一条很粗的单通道，模型一旦漂移，系统几乎没有抓手去修。这正好把问题暴露得很清楚：下一代 What-if Studio 重点该补哪几层。

拆解

做完 What-if Studio 之后开始系统性地翻市面上其他视频生成产品怎么做工作流，越看越觉得：表面上大家都在做一句话成片，真正拉开差距的其实是背后有没有把工作流拆对。很多人刚接触视频生成时以为流程是剧本直接到视频模型，真正做起来才发现中间至少还有四层：资产、镜头、路由、质检。

需求不是 prompt

用户输入的”把这个意难平改成 HE”，说到底只是一个创意意图，不是执行指令。一个可执行的视频项目至少得先补上这些东西：改写目标（到底是抢救某个事件，还是重排整段叙事）、原作约束（哪些人物关系不能被写崩）、观众收益（是情绪补偿、人物救赎，还是世界观修补）、风格锚点（偏电影、偏漫剧、偏预告片，还是偏概念短片）、交付边界（是做 8 秒情绪镜头，还是 60 秒完整片段）。这一层更像 writers’ room，而不是模型调用。What-if Studio 现在的多导演讨论其实已经踏在这个位置上了，接下来最该强化的方向是让讨论结果沉淀成结构化约束，而不是让聊天更像人。

剧本要拆成分层资产

面向视频模型的剧本不能只有自然语言，真正能驱动生成链路的剧本至少得拆成三份：面向叙事的 beat sheet，讲清楚这一段情绪的推进和冲突节点；面向镜头的 storyboard 文本，讲清楚景别、机位、运动、调度、时长；面向生成的 shot card，讲清楚角色、场景、动作、起止状态、参考素材、模型偏好。很多平台型产品从外部看像一个超大 Agent，实际落地时往往会先把这几层拆开，用户看到的是一句话生成分镜，系统内部更合理的做法一定是先把一句话重写成多张镜头卡，再跑图片和视频模型。这也是为什么即梦这类 AI Agent 工作流看起来会先调大量图片 Agent——外部产品形态未必把内部实现完全公开，但从交互和产物推断，一个成熟的系统大概率会先补角色图、场景图、关键帧和分镜卡再进视频阶段，因为缺了这些中间资产，角色一致性、镜头衔接、局部返工几乎无从谈起。

角色一致性靠资产

只要开始做连续镜头，角色一致性就会变成第一道门槛。一句”黑发少女，冷静，穿校服”远远不够，系统真正需要的是一套角色圣经：稳定视觉 token（发型、脸型、瞳色、服饰层次、年龄感），禁止项（不要改变发色、不要忽然变成熟龄脸），三视图与多姿态参考，不同情绪下的表情边界，在不同光线和机位里的保真策略。这也是主流工作流里图片生成模型比预想中更重要的原因——视频模型不是孤立工作的，它前面经常会有一层图片资产生产链，专门负责生成角色三视图、场景设定图、关键帧、道具参考图，很多看上去是视频产品的系统，真正的生产量大头反而落在图片侧。对 What-if Studio 来说这一层几乎是下一步最该补齐的，因为产品核心是替你重拍一个你已经很熟的故事——越是用户熟悉的 IP，角色一致性越不能靠抽卡。

镜头卡才是调度单元

一个稳定的视频流水线不应该以整段剧本为最小执行单位，而应该以镜头卡为单位。理想的 shot card 至少要带这些字段：shot_id、purpose（这一镜头服务什么叙事目标）、duration、characters、location、action、camera、emotion、start_frame_spec、end_frame_spec、reference_assets、audio_notes、model_preference、retry_policy。工作流一旦切到镜头级，很多事就变得可工程化了——同一个项目里，开场大全景可以走偏氛围型，对话镜头可以走参考图更强的模型，过渡镜头可以走首尾帧控制，问题镜头可以单独重生成不用整段报废，镜头级缓存也更自然，前面已经锁好的角色资产和场景资产都能复用。

视频模型只是执行层

选模型常常被当成最核心的技术决策，但做到后面会发现它更像一层路由问题。当工作流足够完整时，模型的职责会收缩成一件事：根据镜头类型执行最合适的生成任务。系统需要的不是唯一的最强模型，而是一个会选模型的调度器。这个调度器至少要判断：这是纯文生视频还是图生视频、是单角色镜头还是多角色互动、需要的是高一致性还是高动态、需要首尾帧强约束还是给模型更大自由度、有没有可用的图片参考和视频参考和音频参考、失败后应该换提示词还是换参考资产还是直接切另一模型。从这个角度看，视频模型更像渲染后端，真正决定体验上限的是前面的资产组织能力。

能力

做完工作流拆解之后，系统过了一遍市面上几个主流视频生成模型的能力边界，搞清楚它们分别适合放在工作流的哪一层，哪些能力已经能确认、哪些还不能写得太死。

WAN

What-if Studio 现在就接的 Wan，对它相对熟一些。Wan 系列的优点在于能力边界清楚，而且很适合被工程系统调用。Wan 2.2 明确给出了文生视频 T2V、图生视频 I2V、文本加图像联合生成 TI2V、语音驱动视频 S2V，以及角色动画和替换相关能力。阿里云的万相参考生视频接口文档明确支持 0～5 张图像、0～3 段视频作为参考输入，图像和视频总数不超过 5，参考接口还支持多角色引用和角色一致性标记，这对多人镜头非常关键。Wan2.1-FLF2V 这条线明确支持首帧加尾帧控制，用首尾两张图去生成中间过渡视频。几条能力结合起来看，Wan 很适合做约束比较强的镜头，以及需要把多角色参考资产吃进去的镜头。

Seedance

Seedance 2.0 支持文字、图片、音频、视频四种模态输入，支持全模态参考输入与编辑，明确强调原生音画同步，同时覆盖文生视频、图生视频、多模态生视频场景。这意味着它适合承担把多种上下文揉进一个镜头的任务，尤其是需要音画同步、参考素材比较丰富的场景。但关于很多创作者最关心的几个细节，官方页面并没有写得足够具体：没有在模型页明确写出首尾帧控制，没有明确写出视频续写或延长，也没有明确写出以前几秒视频作为条件继续往后生成。产品层面是否可能在上层工作流里提供类似能力是另一回事，在技术文章里最好将这两层分开——底层模型页确认的是全模态参考与音画同步，某些产品功能里出现的尾帧、补帧、拼装能力未必等于底层模型原生公开能力。这类边界区分对做平台的人很重要，设计工作流时不能把上层产品体验错当成底层 API 保证。

HappyHorse

HappyHorse 走的是另一种方向：把多模态参考、电影感和音视频同步整合进一个生成入口。从 HappyHorse 可确认的信息来看，它至少明确支持文生视频、图生视频、一个或多个参考图像、参考视频与音频参考等多模态输入（最多可组合到 12 个输入），以及原生音视频同步、唇音同步、环境音效与多语言旁白类。如果某个镜头天然需要声音和画面一起成型，HappyHorse 这类模型会很有吸引力，它的接口思路更像把更多上下文一次喂进去。同样需要克制的是边界判断——至少从官方页面的公开表述里，目前还没有看到首尾帧控制、通用视频续写、以前几秒作为条件做稳定延展这几个点被明确写实，所以在工作流设计里更稳的做法是把它理解成强多模态输入、强音画一体的生成候选，而不是默认它能承担所有过渡控制任务。

模型分工

如果从 What-if Studio 的下一代形态出发，这几个模型应该放在不同位置，各管一段：

位置	更适合的模型	适合做什么
角色与场景资产锁定后的视频执行	WAN	图像参考、多角色参考、首尾帧过渡
多模态上下文压到单镜头	Seedance	文本、图像、音频、视频一起参与生成
音画一体、电影感镜头	HappyHorse	多模态输入、音视频同步、唇音联动

断层

回头看 What-if Studio 当前这一版的实现，它和成熟视频工作流之间的断层很具体。

• 缺角色资产层：讨论结果现在会收束成脚本，但还没有继续下钻成角色卡、场景卡、关键帧集合，视频模型吃到的上下文虽然比一句 prompt 多，却还是不够稳。如果要做 IP 改写，角色资产层基本不能省——没有它，系统只是在理解你的遗憾，还没有能力稳定地重拍它。
• 缺镜头执行层：当前链路已经有 collect → analyze → discuss → edit → render → deliver 这条阶段骨架，但 edit 到 render 之间缺少真正的镜头级编排，系统知道自己在做视频，却不知道自己在做哪几个镜头。没有 shot card，失败就只能整段返工，模型路由也无从谈起。
• 缺生成路由层：目前的生成端更接近单模型直连，适合 demo，不适合平台化。一旦进入生产，很快会碰到这些问题：对话镜头要不要优先走参考图更强的模型、转场镜头要不要优先走首尾帧、纯氛围段落要不要放松约束换动态性、同一个项目里能不能一部分镜头走 Wan 一部分走 Seedance 或别的模型——这些都不是 prompt 工程问题，而是路由器问题。
• 缺版本化中间产物：创作系统和一次性生成器的最大区别在于中间产物能不能存下来。What-if Studio 下一步最值得补的，是把每个阶段的产物都显式化、版本化：改写原则 rewrite_spec、角色圣经 character_bible、场景圣经 scene_bible、镜头卡 shot_cards、关键帧包 keyframe_pack、生成配置单 generation_manifest、质检报告 qc_report。只要这些东西存下来了，系统才能真的具备复拍、回滚、局部返工、迁移模型的能力。

下一代

下一代 What-if Studio 的工作流大概可以拆成下面几层。

编排

多智能体的职责应该是把自由输入逐步压成结构化资产，而不只是聊天。当前导演会的体验可以保留，它非常适合意难平改写这个题材，但讨论结束后应该继续往下拆成多个专门 Agent：Lore Guardian 负责原作边界和角色不崩，Showrunner 负责故事总体取舍，Script Planner 负责 beat sheet，Shot Planner 负责镜头卡，Character Bible Agent 负责人物视觉资产，Scene Bible Agent 负责场景与道具资产，Model Router 负责每个镜头选模型，QC Agent 负责一致性、连续性、违和感检查。当前 demo 用 AutoGen 没问题，它很适合快速把多人讨论搭出来，下一步如果要把状态、工具调用、人工确认、重试分支、长流程恢复做得更扎实，可能需要考虑往 Microsoft Agent Framework 迁移。原因很朴素：What-if Studio 后面要处理的是一条跨多个工种、多个资产、多个外部模型的生产链，到那个阶段，显式状态机、可恢复执行、带类型的中间对象比大家轮流聊更重要。

数据

这一代最核心的升级是数据形态的转变。每个阶段都应该输出结构化对象，而不只是好看的自然语言，导演会结束之后不直接进视频生成，先落地一份中间规范：

{
  "rewrite_goal": "救下小天狼星，并保留大战后的代价感",
  "non_negotiables": ["哈利的成长不能被抹平", "情绪基调不能变成纯喜剧"],
  "character_bibles": [],
  "scene_bibles": [],
  "shot_cards": []
}

结构化的意义不只在于方便程序读取，更在于方便人介入——用户可以在任意层级确认或打回，不用等到最终视频生成完毕才第一次发表意见。

资产

角色资产层会是下一代 What-if Studio 的分水岭。理想流程里，导演讨论完之后先做一轮图片资产生成，再进视频：角色三视图、角色情绪板、场景设定图、道具参考、每个关键镜头的首帧或关键帧。这一步可以完全 agent 化——一个 Agent 负责把角色描述转成标准视觉 token，一个 Agent 负责为不同镜头生成参考图，一个 Agent 负责筛掉不稳定结果，再把通过的资产挂回镜头卡。很多平台看起来像在直接生视频，真正稳定的部分往往都藏在这一层。

路由

下一代 What-if Studio 不应该绑定单一视频模型，而应该绑定一套镜头路由规则。按镜头类型来分：有强参考图和明确构图的镜头优先走 I2V，需要从 A 过渡到 B 的镜头优先走首尾帧控制，需要多模态上下文一起压进来的镜头优先走参考能力更强的模型，纯氛围镜头允许更大的自由生成空间，某个镜头失败之后先换参考资产、再换提示词、最后才换模型。这样做有两个直接好处：成本更可控，不是所有镜头都值得用同一种最贵能力；可修复，系统不需要整片重来，只需要知道这张镜头卡适合哪条重试路径。

交互

What-if Studio 最有价值的地方在于共创过程，用户交互节点应该做得更明确：导演会后确认改写方向，角色资产生成后确认人物是否像，镜头卡生成后确认叙事节奏，关键帧生成后确认视觉一致性，视频出来后只针对坏镜头局部返工。到这步，What-if Studio 就真正把用户拉进了影视工作流里，而不只是让他们作为旁观者观看 Agent 讨论。

工程

只谈创意不谈工程，视频工作流很快会失控。下一代至少要补这些基础设施：资产哈希与复用（避免重复抽同一角色图），镜头级缓存（单镜头失败不拖累全片），prompt 模板版本化（能比较哪版更稳），模型能力表（清楚记录每个模型能吃什么输入），成本账本（知道钱花在哪种镜头上），失败分流（区分素材问题、路由问题和模型问题）。这些基础设施不太显眼，但决定了 What-if Studio 能不能从 demo 走到产品。

落地

导演会产物结构化

这是成本最低但收益最直接的一步。现在已经有多智能体讨论，下一步是让它稳定输出 rewrite_spec、shot_cards、asset_requests 这类对象，只要这层做好，后续衔接图片 Agent、不同视频模型、人工确认节点都会顺很多。

补图片资产层

角色三视图、场景图、关键帧一旦进来，What-if Studio 才开始真正拥有重拍的能力，而不是重新抽一遍。这一步做完，系统对视频模型的依赖就会从完全依赖模型理解意图，变成由系统给出足够约束请模型执行，生成稳定性会立刻提一截。

镜头级模型路由

等前两层成立，再谈多模型协同才有意义，因为那时候系统已经积累了足够多的上下文，能区分某个镜头到底该走 Wan、该走偏全模态参考的路线、还是该走更强音画一体的路线。模型不再是全局开关，而是工位。

做完 What-if Studio 这一个 demo，比较清楚的感受是：视频生成产品的真正壁垒不在于接了多少模型，而在于有没有把创意到约束到资产到镜头到生成到回修这条链做成一个可追踪、可插手、可复用的系统。当前 demo 版已经证明了改写意难平不是一句 prompt，而是一场可视化、可参与、可被编排的创作过程，接下来要做的就是让这场讨论真正接上工业化的视频工作流，让导演会不只产出观点，还产出能被下一环节稳定消费的资产——到了那一步，What-if Studio 才会从一个会说话的 demo，长成一个真正能拍片的 AI 剧组。