封面为 AI 生成的示意插图（内容由AI生成），非论文原图

视频世界模型记不住的事，这篇论文交给一段程序去做

Programmable World Model 深度解析：把“世界状态”从像素里拿出来，装进可执行的规则里

先讲一个大家都遇到过的尴尬。

现在最火的视频世界模型，能生成以假乱真的街景、赛车、打斗场面，你推一下摇杆，画面就跟着动。但你多看几秒钟就会发现不对劲：刚才被打倒的那个角色，下一段画面里又站起来了；走出镜头的车，再回到镜头里时颜色变了；你明明写了“门被锁上”，几秒后它就自己开了。

生成得很美，可它记不住关于这个世界的任何一条硬事实。

9 月 9 日发布在 arXiv、来自 Alaya Lab 的这篇 Programmable World Model（PWM），就是冲着这件事来的。它给出的答案有点反直觉：不要再逼视频模型去记东西了——把“世界是什么”这件事，从生成模型里整个搬出来，交给一段程序。

一、先看清它要打的三个“卡脖子”问题

论文开篇把现有交互式视频世界模型的缺陷列成了三条，条条都打在要害上：

• 控制粒度太粗。现有接口主要让你指定相机、动作或一句高层提示词，很难“点名”某一个实体去操作它。
• 没有独立于画面的全局状态。很多信息是画面里看不见的——屏幕外的角色、背包、任务进度、交互历史——但世界模型没有一个地方存它们。
• 规则没法“编程”。你可以用提示词哄模型生成一个“门开了”的结果，但那不是一条会持续生效的可执行规则；下一次交互它照样按自己的性子来。

二、先看全局：三段式架构

PWM 的整体设计可以用一句大白话概括：把“世界怎么演化”和“画面怎么生成”彻底拆开。拆完之后是三个组件接力：

1. 编码智能体（agent）：把自然语言描述编译成可执行的世界程序；
2. 轻量引擎（engine）：执行程序，维护一份显式、持久的世界状态；
3. 生成式渲染器（renderer）：把世界状态渲染成画面。

中间还需要一个“翻译层”，把引擎里的三维状态变成视频模型看得懂的控制信号——这是全文最巧的设计，后面单独讲。

三、拆开看①：世界状态到底长什么样

这是理解整篇论文的关键。PWM 不用像素、也不用稠密 3D 场景来表示世界，而是用一组带着状态的 3D 有向包围盒（state-augmented 3D OBB）。

官方给的世界状态由四部分组成：

• 几何：每个实体一个 3D OBB，规定它的位置、尺寸和朝向；
• 属性：身份标识、语义类别，以及功能性属性——比如血量、阵营；
• 关系：实体之间的关系，比如敌对、归属；
• 规则：可执行的世界规则，规定玩家动作和事件如何改变上述状态。

初始化时，系统先用现成的 3D 检测器从第一帧里恢复出可见实体和它们的几何布局，拿到初始 OBB 和持久 ID；其余属性、关系和规则，则由编码智能体根据你的自然语言描述补齐。

举个论文里的战斗场景：智能体把检测到的人物分成两个对立阵营、初始化血量和战斗状态、规定有效的攻击关系、定义开枪后的伤害/死亡/目标更新。于是世界跑起来了——但注意，它跑的不是一套完整的 3D 游戏资产与底层物理模拟，而是一个轻量的“盒子世界”：OBB 提供几何骨架，结构化的状态、关系和规则提供交互语义。

为什么选这个中间的抽象层级？论文专门做了一段“表示权衡”的讨论：文本太省但给不了几何约束；2D 框和掩码是图像空间的，换个视角就失效；而完整 3D 场景、关节模型、G-buffer 虽然控制更精细，但训练监督更贵、推理时要显式维护的自由度更多，还容易出现“训练时从观测里提取的表示”和“推理时从高层状态构造的表示”对不上的问题。OBB 恰好落在一个既能被程序直接编辑、又不至于失控的甜点上。

四、拆开看②：状态编译器，把 3D 状态“翻译”成像素

引擎算完 ≠ 画面能画。引擎给出的状态是世界坐标系的，还包含很多“在画面里没有直接对应物”的变量（血量、背包、阵营）。所以中间必须有一步状态编译：

• 把实体 OBB 在目标相机下做投影，得到它该出现在画面的哪块区域；
• 给这块投影区域挂上三类属性：identity（是哪一个持久实例）、semantic（属于什么语义类别）、motion（它自己正朝哪个方向动）；
• 额外提供一份相机相对的物体运动状态——因为一个包围盒在画面上位移，可能来自物体自身在动，也可能只是镜头在动，两者必须分开告诉渲染器。

关键点在于：这一步是确定性的（deterministic），而且不改变底层世界状态。这保证了“引擎说世界是什么样”和“渲染器被要求画成什么样”之间不会漂移——这正是长时程一致性的来源。

五、拆开看③：渲染器只负责“好看”

渲染器是一个预训练的、相机可控的视频生成模型。它拿到的是上面那套像素对齐的控制信号，再加上视觉历史，合成下一段视频（chunk）。为了撑住长时程，论文做了两件记忆上的事：

• 时间历史：已完成片段进入时序记忆，保证画面连续；
• 几何对齐的空间记忆：让模型在镜头大幅转动、重新看到之前区域时，能找回一致的画面。

用论文自己的话说，这里的立场很清晰：表现（appearance）继续交给生成模型，事实（state）交给引擎。

六、训练数据从哪来：三个 3A 游戏 + 一条五步数据引擎

这套方法要吃“视频 + 结构化控制”的配对数据，公开数据集里没有现成的。论文的做法是从三款游戏里采无 HUD 的游戏录像：《赛博朋克 2077》（第一人称视角）、《极限竞速：地平线 6》与 《侠盗猎车手 5》（第三人称，多机位视角）。

采下来之后，一条数据引擎负责把原始视频加工成训练对，共五步：相机参数估计、语义类别发现、实例分割与跟踪、物体轨迹恢复、条件图生成。

七、实验：94% 和 98% 是怎么测出来的

论文搭了一个专门的基准 CombatStateBench，共 50 段片段。每一段都由数据引擎从首帧重建初始 3D 布局（实体、3D 框、语义属性、相机参数），再由 AI 智能体在给定规则下自动演化出一段战斗过程，覆盖静态/动态相机、物体运动以及“初始就在画面外”的角色。每个序列都带同步的 3D 框、实体状态、相机参数、投影控制与实例掩码，并且要过一遍自动验证器（检查首帧重投影、距离一致性、框几何、着地、时间连续性、规定的相机与物体运动、状态转移是否持续）——全过才留用。

评测方式也值得单独说：裁判是一个视觉语言模型（Qwen3.6-27B），只给它生成的 RGB 画面，不给包围盒、不给角色身份、不给应有数量、不给死亡位置等任何特权标注。两个指标：

• 计数准确率（Count Accuracy）：每段随机抽 8 帧，共 400 帧，让裁判数“可见且活着”的角色数量，与引擎记录的数量比对；
• 状态准确率（State Accuracy）：对 50 次死亡事件，在状态转移后均匀抽 3 帧，问裁判是否至少有一帧呈现了死亡角色。

表 1｜单位：%。数据来自论文 Table 1（50 段 CombatStateBench 片段）。表格在窄屏下可横向滑动。

结论很直观：在画质类指标上三家互有胜负（PWM 的成像分 67.62 略高，YUME 的时序稳定性 98.76 也很强），但在“画面对不对得上世界状态”这件事上，差距是断崖式的——计数准确率 94.00 对 40.75 / 32.00，状态准确率 98.00 对 58.00 / 58.00。

定性结果里还有几个细节值得注意：大角度相机旋转后，模型能正确“揭出”初始视野之外的角色的存在；在赛车游戏和包含人、车等异构类别的场景里也能沿用同一套机制；论文还展示了一段 897 帧的自回归序列，期间大量 NPC 陆续入场，状态依旧保持。

八、它真正的贡献，不只是那两个数字

如果只记一句话，我建议记论文结论里的这句立场：让状态变得可执行、可验证，让外观保持生成式（state is executable and verifiable, while appearance remains generative）。

它带来的三个连带效果是：

• 可审计。世界状态是一份显式数据结构，不是网络权重里的隐变量——你可以打印它、断言它、为它写测试。
• 可编程。“门在满足什么条件时打开”是一条规则，而不是一句祈祷式的提示词。
• 可解耦演进。想要更清楚的状态？换引擎。想要更逼真的画面？换渲染器。两个方向互不绑架。

九、冷静看：四个还没解决的问题

• 对比方式对基线不完全公平。两个基线模型本身没有实例级状态接口，论文只能通过“切换提示词”来告诉它们状态转移。这个差距里，有多少来自架构差异、有多少来自接口不对等，论文没有拆开验证。
• 指标是宽松的全局指标。计数准确率和状态准确率都由 VLM 裁判给出，不要求实例级逐一对应。它们能证明“画面对得上状态”，但证明不了“对得像不像”。
• 数据域偏游戏。训练数据来自三款 3A 游戏的画面，评测基准又是基于同类游戏内容自动生成的。真实世界、开放域、非游戏场景的表现尚未验证。
• 盒子世界的表达力有上限。OBB 撑不起细粒度姿态、形变、接触与流体等物理细节。这套表示擅长回答“谁在哪里、什么状态、能不能做某事”，不擅长回答“这一拳打上去具体怎么变形”。

另外需要说明的是：论文正文没有专门的“局限”章节，以上四条是本文基于论文方法、评测设置与实际适用范围所做的判断，不代表作者结论。

十、一句话总结

你觉得“显式状态 + 生成式渲染”这种分工，会不会成为下一代世界模型的默认范式？欢迎在评论区聊聊。