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

May 22, 2026 · 8767 字
AI

前段时间参加南客松 S2 黑客松,我们做了 What-if Studio 这么一个东西:你输入一句“我不接受这个结局”,它就帮你组一个虚拟剧组,导演们讨论、争吵、提案、分工,最后给你一段可播放的平行结局短片。想法很直白——很多人看完一个故事之后最强烈的感受是“如果这里不是这样就好了”,我们想把这种感觉做成一个能操作的产品。

做的时候我们没走“输入一句话,等一分钟,吐一个视频”的黑盒路线,而是把前端做成了一整个会动的片场:导演室、主舞台、剪辑区、录音区、素材区都在同一张 D3 画布里,导演们陆续进场,讨论通过 SSE 实时滚动,用户可以缩放、旁观、查看角色卡片,到了需要素材的时候弹任务卡,最后再进视频生成。后端是 FastAPI + SQLAlchemy + SQLite,对象流分了 ProjectSessionVideoJob 三层,讨论流和任务流各推一路 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_idpurpose(这一镜头服务什么叙事目标)、durationcharacterslocationactioncameraemotionstart_frame_specend_frame_specreference_assetsaudio_notesmodel_preferenceretry_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 这条阶段骨架,但 editrender 之间缺少真正的镜头级编排,系统知道自己在“做视频”,却不知道自己在“做哪几个镜头”。没有 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_specshot_cardsasset_requests 这类对象,只要这层做好,后面接图片 Agent、接不同视频模型、接人工确认都顺。

再补图片资产层

角色三视图、场景图、关键帧一旦进来,What-if Studio 才真正开始拥有“重拍”的能力,而非“重新抽一遍”。这一步做完,系统对视频模型的依赖就会从“全靠你理解我”变成“我给你足够多的约束,请你把它做出来”,生成稳定性会立刻提升一截。

最后做镜头级模型路由

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

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

粤ICP备2025414119号 粤公网安备44030002006951号

© 2026 Saurlax · Powered by Astro