视频模型记不住棋盘，那就别让它记：OpenMise 的两阶段拆分

先看一个失败案例。

提示词写得非常明确：生成两个人面对面下国际象棋的写实视频，完整展示西班牙开局，严格依次执行 e4 e5、Nf3 Nc6、Bb5 a6，直到王车易位。要求棋步合法、棋盘状态连续，不得出现多余棋子、错误落点或棋子凭空消失。

Seedance 2.5 生成的结果是：人物对了，动作对了，布景和光影都正确渲染——但棋子位置逐渐混乱。 上一帧还在原位，下一帧换了格子，甚至多出一枚棋子。

这就是视频创作者熟悉的"抽卡"：写清楚了，生成结果还是穿墙或跑偏。运气好一次就中，运气不好要反复生成整段。

清华与宾夕法尼亚大学的团队开源了一个叫 OpenMise 的工具，处理的正是这件事。他们的判断很直接：问题不是模型不会画棋盘，是它被要求同时做两件互相矛盾的事。

一、一个模型被要求同时做的两件事

把那个下棋的任务拆开，模型实际上要同时完成：

前两行的性质和后三行完全不同。状态管理和规则推理要求确定性——不许有任何偏差；视觉渲染是概率性的——差不多就行。

而扩散模型的工作方式本质是概率采样。它擅长在像素空间里生成"看起来很对"的东西，但不擅长维护一个精确的状态机。让它一边记住棋盘、一边画光影，等于让它同时做一个会计师和一个画家。

团队的原话是：这既要求模型具有精确的细节把控能力，又要求模型具有高质量的视频渲染能力，目前所有的视频生成模型几乎都没有能力同时做到这两件事。

二、拆分：让确定的归确定，模糊的归模糊

OpenMise 的方案是把「直接生成视频」改造成「Builder + Render」两阶段。

Builder 阶段： Agent 调用 Blender，把场景、人物、动作、摄影机、灯光安排进同一个三维世界，输出一段白模视频和一份可编辑的工程文件。

Render 阶段： 把白模视频连同人物参考图、提示词一起交给现有的视频生成模型（文章开头那个例子里用的是 Seedance 2.5），完成写实渲染。

关键在于谁来干什么：

白模是那个交接点。 它把"棋子在哪个格子、第几帧移过去"这类绝对不能错的信息固定下来，交给下游模型当作参考。下游模型不再需要维护棋盘状态，只需要把已经确定的构图渲染得好看——这是一件简单得多的事。

官方的说法是：如果仅靠 Seedance 2.5 反复生成再挑出符合物理规律的那一条，可能需要几十次才能达到同样效果，甚至永远达不到。

这句话要打个折听——"几十次"没有给出实验条件，"永远达不到"是定性判断。但方向是对的：概率采样去逼近确定性约束，成功率随约束数量指数下降。 这和长程任务的复合成功率是同一个数学结构。

为什么这个拆分的接口是一段视频？ 这不是随手选的。一个接口要能承接上下游，得同时满足三个条件：

第三条最容易被忽略，但它是"能不能真的用起来"的分水岭。如果每改一次都要从头跑完整条链，这个拆分在工程上就不成立。

反过来看那些拆不动的方案，多半卡在第一或第三条：接口是一种只有自家系统能读的中间格式（下游不认），或者中间状态一旦生成就无法局部修改（只能整体重来）。

白模视频这个接口之所以成立，正因为它足够"笨"——一段普通视频，谁都能吃，谁都能改。

三、Builder 的第一个难题：看得见不等于读得懂

Builder 听起来像"调个 Blender 就完了"，实际不是。团队在实验里发现了一句话，值得单独拎出来：

场景能够显示，和系统已经理解了场景，存在很大的 gap。

以 3DGS（三维高斯泼溅）扫描为例。它保存的是空间中的高斯分布与外观信息——能渲染出一个看起来很真实的房间，但不天然提供房间名称、门的位置、真实尺度、可行走地面、碰撞边界。

对一个要规划路径的 Agent 来说，这些恰恰是全部。它看见了一个房间，但不知道哪里能走、门有多宽、地板在哪个高度。

所以场景接入后要做三步：

做完这三步，一个"看得见的房间"才变成"可以规划路径和机位的空间表示"。

这个区分对整个 AIGC 三维方向都成立：渲染资产和可计算资产是两回事。 扫描出来的漂亮场景，对生成模型是输入，对规划系统还是原始数据。

四、Builder 的第二个难题：路径要算人物的宽度

有了空间表示，接下来是让人物走过去。

这里有个细节，专业做三维动画的人会觉得理所当然，但做 Agent 的人容易漏掉：人物的运动要拆成两部分处理。

• 路径控制：决定角色在场景中的位置和朝向，依据可通行区域规划路线；
• 动作控制：用骨骼动画与脚部约束安排迈步、抬脚、落脚、身体姿态。

拆开之后才能做一件关键的事：路径校验不只看中心线，还要算人物占用的空间。

官方举的例子很形象：如果只检查中心线，"路线穿过门"是成立的；但人会撞——肩膀的宽度超出门框。这个错误在只做中心线校验的系统里发现不了，只能等到渲染出来才看见人穿墙。

脚部约束同理：步态要和整体位移匹配，脚要落在地面上。如果路径是一条斜线而步态是水平循环的，看起来就是"滑步"。

这一类错误有个共同点：它们在像素层面很难判断，但在几何层面一眼就能查出。 这也正是两阶段拆分的价值——把错误从"要看成片才知道"提前到"白模阶段就能发现"。

五、Builder 的第三个难题：灯更大不等于灯更亮

摄影机和灯光要和人放在同一条时间轴上，这件事的难点在于自然语言到参数的翻译。

创作者说的是"背后跟拍"“缓慢推进”“进入卧室后环绕”。这些在三维系统里必须拆成具体的量：

• “背后跟拍” = 机位 + 观察目标 + 焦距 + 跟随距离 + 时间段 → 摄影机关键帧
• 狭窄空间里，相机要沿人物先前经过的路径跟进，再调整距离与朝向——否则人物在走廊转弯时，相机就切进墙里了
• 到了卧室，人物环视房间，镜头要在同一时间轴上切换观察目标

灯光同样要参数化。团队特别说了一句："灯更大"和"灯更亮"不是同一个操作。 尺寸影响光影的柔和程度（面积光源越大，阴影越软），功率决定照明强弱。混为一谈的话，你说"柔一点"，系统给你调亮度，怎么调都不对。

对 3DGS 扫描场景，他们还接了 KIRI 的近似重打光，让扫描出来的墙面和地板能呈现新的受光变化——保留扫描的视觉基础，同时给布光留出调整空间。

这一整套的意义在于：路线、动作、运镜不再是三段各自生成的动画，而是一份相互对齐的拍摄安排。 改一处不会牵动全部。

六、拆分的代价：开源了什么，没开源什么

到这里该说清边界了。OpenMise 的仓库说明里有一段话，比任何宣传都值得读：

当前开源版本以 Agent Skills、参考文档及技能自带的可选模型辅助脚本提供这些工作流程，并附展示视频。仓库不包含独立应用、Blender 执行后端、插件服务或模型权重。 使用时，Agent 读取技能并通过你已有的 Blender 工具操作场景。

翻成直白的话：

而且明确写了：下载仓库不会自动安装演示中的完整工具链。

所以它的定位是"方法论 + 技能包"，不是"开箱即用的工具"。你真想跑起来，至少要自备：Blender 环境、Blender MCP 之类的执行桥、一个能写三维脚本的 Coding Agent、以及下游的视频生成模型（Render 阶段那个渲染服务也不在当前开源版本里）。

这个边界划清之后，才能正确评估它的价值：它给的不是一个产品，是一套已经被验证过的分工方案。

对于做 AIGC 工具链的团队，这套方案的价值可能比自己搭一遍更高——因为它把"哪些事该交给确定性系统、哪些该交给生成模型"这个判断，用可运行的技能描述下来了。

七、这套方法不适合什么

拆完再看它的边界，会更清楚它该用在哪儿。

第一，环境不轻。 需要 Blender、需要 Agent 能调 Blender 的桥接（MCP 之类）、需要一个能写三维脚本的 Coding Agent，外加下游的视频模型。这不是"装个包就能用"的工具，是一套需要搭起来的工作流。

第二，白模阶段要人看。 官方描述的流程里，Builder 输出草稿后是"让创作者先检查棋局怎样推进"。检查这一步目前是人在做，不是自动闭环。所以它省的是"反复抽卡的算力与时间"，不是"人的判断"。

第三，适合结构重要的场景，不适合纯风格化生成。 如果任务本身就没有精确的空间约束——比如"生成一段抽象的粒子动画"“做一段氛围空镜”——那两阶段拆分只是多加了一道工序，收益接近零。它真正解决的是"必须按计划发生"这一类需求。

第四，两次计算换一次命中，未必总账更省。 白模渲染要算力，下游渲染也要算力。它省下来的是"反复重生成几十次"那部分浪费。如果一条视频本来就一两次就能生成对，这个拆分反而是净亏。 只有当约束足够多、抽卡成功率足够低时，账才算得平。

这四条合起来，指向一个不算宽的适用区间：空间结构关键、约束多、抽卡成本高的内容生产——短剧、教学演示、产品解说、需要精确运镜的实拍替代。这也正好是官方提到的方向。

八、这个思路能迁移到哪

“把一个大任务拆成两个小任务，各交给最合适的工具”——这个原则本身不新，难的是判断在哪切。

OpenMise 给出的切法是：按确定性要求切。

判断一个任务该不该拆，可以问三个问题：

三条都成立，就值得拆。

举几个同构的例子：

• 文档生成：数据核对（确定性）与文案润色（概率性）该分开。先让程序把数字对齐，再让模型写句子，比让模型"自己注意别算错"可靠得多。
• 代码生成：接口契约与实现细节。契约可以用 schema 和类型系统固定，实现交给模型。
• 数据报表：口径计算与图表呈现。算错了图表再漂亮也没用。
• 视频创作：就是 OpenMise 做的这件事——空间与动作归三维软件，质感归生成模型。

反过来说，有些场景不该拆：

• 精确部分无法形式化（比如"判断这段话有没有攻击性"，只能靠模型）
• 拆开之后接口传不动（中间状态太复杂，无法序列化）

最后一条常常是真正的障碍。 OpenMise 能成立，很大程度上是因为"白模视频"这个接口足够简单——它就是一段视频，任何视频模型都吃得下。如果中间状态是一堆无法表达的隐向量，这个拆分就落不了地。

九、关键要点

1. 问题不是模型不会画棋盘，是它被要求同时做两件矛盾的事。 维护棋盘状态要求绝对确定，渲染光影是概率采样。扩散模型擅长后者，不擅长前者。

2. OpenMise 的切法是按确定性切。 Builder 用 Blender 管坐标、路径、动作、机位、灯光（确定性系统），Render 用视频模型管材质、光影、外观（概率生成）。白模视频是接口。

3. "反复生成几十次"这个说法没有实验条件，但方向对。 用概率采样逼近确定性约束，成功率随约束数量指数下降——这和长程任务的复合成功率是同一个数学结构。

4. 接口选视频不是随手定的，它要同时满足三个条件。 下游不需要额外训练就能用（视频模型天生吃视频）；损失的信息不影响下游任务（白模丢了材质光影，但保住空间结构、运动轨迹、镜头构图）；改一处能局部重做（路线错只重出白模，风格不对只重渲染）。第三条是能不能真用起来的分水岭——每改一次都要跑全链路，这个拆分在工程上就不成立。

5. 看得见不等于读得懂。 3DGS 扫描能渲染出真实房间，但不提供房间名称、门的位置、真实尺度、可行走地面、碰撞边界。要补三步：坐标校准、尺度校准、空间标注。

6. 路径校验必须算人物占用空间，不能只看中心线。 "中心线穿过门"和"肩膀撞上门框"是两回事，后者在像素层面看不出来，在几何层面一查就现。

7. 人物的整体位移与骨骼动作要分开处理。 路径决定去哪，动作决定怎么走；两者必须对齐，否则就是"滑步"。

8. "灯更大"和"灯更亮"不是同一个操作。 尺寸影响阴影柔和度，功率影响照明强度。自然语言到参数的翻译是这一步的真难点。

9. 开源的边界要说清：仓库里只有 Skills、文档、辅助脚本和展示视频。 没有独立应用、没有 Blender 执行后端、没有插件服务、没有模型权重，下载后不会自动装好工具链。

10. 判断该不该拆，问三个问题： 是否同时存在"绝不能错"和"差不多就行"的部分；精确部分能否被形式化；两段之间的接口是否可交付。三条都成立就值得拆。

11. 接口能不能传出来，常常是真正的障碍。 OpenMise 能成立，很大程度因为"白模视频"足够简单——一段视频，谁都能吃。如果中间状态是一堆无法表达的隐向量，这个拆分就落不了地。