封面为 AI 生成的示意插图（内容由AI生成），非论文原图 视频世界模型记不住的事，这篇论文交给一段程序去做 Programmable World Model 深度解析：把“世界状态”从像素里拿出来，装进可执行的规则里 论文：arXiv:2609.10540（cs.CV）· 2026-09-09 · 团队：Alaya Lab · 项目页与代码已开源 先讲一个大家都遇到过的尴尬。 现在最火的视频世界模型，能生成以假乱真的街景、赛车、打斗场面，你推一下摇杆，画面就跟着动。但你多看几秒钟就会发现不对劲：刚才被打倒的那个角色，下一段画面里又站起来了；走出镜头的车，再回到镜头里时颜色变了；你明明写了“门被锁上”，几秒后它就自己开了。 生成得很美，可它 记不住关于这个世界的任何一条硬事实 。 9 月 9 日发布在 arXiv、来自 Alaya Lab 的这篇 Programmable World Model（PWM） ，就是冲着这件事来的。它给出的答案有点反直觉：不要再逼视频模型去记东西了—— 把“世界是什么”这件事，从生成模型里整个搬出来，交给一段程序。 论文速览 标题： Programmable World Model 作者： Zheng-Hui Huang, Guixu Lin, Jiacheng Lin, Yi-Chuan Huang, Ruihan Yu, Muyao Niu, Siqi Yang, Yu-Lun Liu, Yung-Yu Chuang, Kaipeng Zhang, Zhixiang Wang 团队： Alaya Lab（项目负责人 Zhixiang Wang，通讯作者 Zhixiang Wang、Kaipeng Zhang） 编号： arXiv:2609.10540 （cs.CV）· 2026-09-09 代码： github.com/AlayaLab/pwm 项目页： alaya-lab.github.io/pwm 一、先看清它要打的三个“卡脖子”问题 论文开篇把现有交互式视频世界模型的缺陷列成了三条，条条都打在要害上： 控制粒度太粗。 现有接口主要让你指定相机、动作或一句高层提示词，很难“点名”某一个实体去操作它。 没有独立于画面的全局状态。 很多信息是画面里看不见的——屏幕外的角色、背包、任务进度、交互历史——但世界模型没有一个地方存它们。 规则没法“编程”。 你可以用提示词哄模型生成一个“门开了”的结果，但那不是一条会持续生效的可执行规则；下一次交互它照样按自己的性子来。 提示词能换来一次结果，换不来一套规则。 二、先看全局：三段式架构 PWM 的整体设计可以用一句大白话概括： 把“世界怎么演化”和“画面怎么生成”彻底拆开。 拆完之后是三个组件接力： 编码智能体（agent） ：把自然语言描述编译成可执行的世界程序； 轻量引擎（engine） ：执行程序，维护一份显式、持久的世界状态； 生成式渲染器（renderer） ：把世界状态渲染成画面。 中间还需要一个“翻译层”，把引擎里的三维状态变成视频模型看得懂的控制信号——这是全文最巧的设计，后面单独讲。 参考图像 ＋ 自然语言世界描述 （描述阵营、血量、可执行规则等） 编码智能体：把描述编译成世界程序 程序里写的是实体状态与状态转移规则 轻量引擎：维护显式、持久的世界状态 3D 有向包围盒 ＋ 属性 ＋ 实体间关系 ＋ 可执行规则 屏幕外实体、血量、物品、任务进度也都记在这里 状态编译器：把 3D 状态投影成像素对齐的控制 identity（是谁）· semantic（是什么）· motion（往哪动） 额外给出相机相对的物体运动，区分“物体动”与“镜头动” 生成式渲染器：只负责“看起来像” 预训练相机可控视频模型，按控制信号合成下一段视频 段落写入时间记忆与几何对齐空间记忆，支撑长时程 玩家动作 记忆回注 一句话概括这次解耦： 上半段负责“世界是什么”，下半段负责“看起来像什么”。 状态可执行、可验证，外观才交给生成模型。 图 1 PWM 三段式架构：世界程序 → 状态引擎 → 控制编译 → 生成式渲染（示意图由 AI 生成，内容由AI生成） 三、拆开看①：世界状态到底长什么样 这是理解整篇论文的关键。PWM 不用像素、也不用稠密 3D 场景来表示世界，而是用 一组带着状态的 3D 有向包围盒（state-augmented 3D OBB） 。 官方给的世界状态由四部分组成： 几何 ：每个实体一个 3D OBB，规定它的位置、尺寸和朝向； 属性 ：身份标识、语义类别，以及功能性属性——比如血量、阵营； 关系 ：实体之间的关系，比如敌对、归属； 规则 ：可执行的世界规则，规定玩家动作和事件如何改变上述状态。 初始化时，系统先用现成的 3D 检测器从第一帧里恢复出可见实体和它们的几何布局，拿到初始 OBB 和持久 ID；其余属性、关系和规则，则由编码智能体根据你的自然语言描述补齐。 举个论文里的战斗场景：智能体把检测到的人物分成两个对立阵营、初始化血量和战斗状态、规定有效的攻击关系、定义开枪后的伤害/死亡/目标更新。于是世界跑起来了——但注意， 它跑的不是一套完整的 3D 游戏资产与底层物理模拟，而是一个轻量的“盒子世界” ：OBB 提供几何骨架，结构化的状态、关系和规则提供交互语义。 为什么选这个中间的抽象层级？论文专门做了一段“表示权衡”的讨论：文本太省但给不了几何约束；2D 框和掩码是图像空间的，换个视角就失效；而完整 3D 场景、关节模型、G-buffer 虽然控制更精细，但训练监督更贵、推理时要显式维护的自由度更多，还容易出现“训练时从观测里提取的表示”和“推理时从高层状态构造的表示”对不上的问题。OBB 恰好落在一个既能被程序直接编辑、又不至于失控的甜点上。 图 2 概念示意：实体被 3D 包围盒“框住”，位置、尺寸、朝向都是可被程序直接改写的变量（插图由 AI 生成，内容由AI生成） 四、拆开看②：状态编译器，把 3D 状态“翻译”成像素 引擎算完 ≠ 画面能画。引擎给出的状态是世界坐标系的，还包含很多“在画面里没有直接对应物”的变量（血量、背包、阵营）。所以中间必须有一步 状态编译 ： 把实体 OBB 在 目标相机 下做投影，得到它该出现在画面的哪块区域； 给这块投影区域挂上三类属性： identity （是哪一个持久实例）、 semantic （属于什么语义类别）、 motion （它自己正朝哪个方向动）； 额外提供一份 相机相对的物体运动状态 ——因为一个包围盒在画面上位移，可能来自物体自身在动，也可能只是镜头在动，两者必须分开告诉渲染器。 关键点在于： 这一步是确定性的（deterministic），而且不改变底层世界状态。 这保证了“引擎说世界是什么样”和“渲染器被要求画成什么样”之间不会漂移——这正是长时程一致性的来源。 五、拆开看③：渲染器只负责“好看” 渲染器是一个预训练的、相机可控的视频生成模型。它拿到的是上面那套像素对齐的控制信号，再加上视觉历史，合成下一段视频（chunk）。为了撑住长时程，论文做了两件记忆上的事： 时间历史 ：已完成片段进入时序记忆，保证画面连续； 几何对齐的空…