当游戏世界会自己"忘事儿"的时候，你该怎么办？
你玩过那种让人抓狂的游戏体验吗？明明已经把一个敌人打死了，镜头一转再转回来，那个敌人居然又站起来了，血条也满了，像什么都没发生过。这不是bug，这恰恰是当下所有AI生成的"世界模型"正在面对的真实困境。
过去两年,视频生成技术突飞猛进,你只要给一段文字或者一张图,AI就能生成一段以假乱真的动态画面。于是有人琢磨,能不能把这种技术做成可以互动的"世界",你做一个动作,世界就给你一个合理的反应,像玩游戏一样。这类系统被称为交互式视频世界模型,谷歌的Genie系列、国内的LingBot、YUME都是这个方向的代表作。
问题是,这些模型有一个共同的软肋。它们本质上是靠"看图说话"的方式生成下一帧画面的,模型看着之前的画面和你的动作提示,去猜下一帧应该长什么样。这套逻辑对付"画面看起来对不对"这件事很擅长,但对付"世界的事实对不对"就很吃力了。角色死了没有,弹药还剩多少,任务完成到哪一步了,这些信息如果不在当前画面里露脸,模型就压根不知道该怎么保持它们的连续性。
这篇来自Alaya Lab的论文,题目叫《Programmable World Model》,中文可以译作"可编程世界模型",瞄准的正是这个痛点。他们给出的诊断很直接：现在的视频世界模型只有一套生成画面的本事,却没有一个真正记账的账本。
核心问题：世界模型为什么记不住事
我们先把这件事的难度摊开来讲清楚。
一个真正可交互的世界,至少需要三种能力。第一是能针对具体的个体下达指令,比如"让二号敌人闭嘴",而不是笼统地说"让战斗安静一点"。第二是要有一个不依赖当前画面的、持续存在的全局状态,包括那些暂时不在镜头里的东西,比如背包里的道具、藏在墙后面的敌人。第三是允许用户提前编好规则,比如"血量归零就倒地",而不是每次都临时口头描述想要的结果。
现有的视频世界模型在这三件事上普遍力不从心。它们的控制接口大多停留在摄像机运动、笼统的动作指令或者高层次的文字提示上,没法精确对准某一个实体。它们也没有独立于画面之外的持久状态记录,一旦某个角色离开镜头,它的血量、状态就没地方存了。用户想改变世界规则,往往只能靠改提示词,而提示词改变的是这一次生成的倾向,并不构成一条会一直生效的规则。
论文里做了一个类比性的实验对照,用两个现有的代表性系统LingBot-World-V2和YUME来测试这个短板到底有多严重。测试的场景很朴素,一场战斗,有几个角色,按剧本设定其中一个会在某个时刻死亡。结果显示,LingBot-World-V2的角色计数准确率只有40.75%,状态准确率更是低到8%。这意味着,十次战斗里差不多九次,死亡这件事在画面上根本没有被正确地呈现出来。YUME稍微好一点,状态准确率58%,但离及格线还有不小差距。
这组数字说明了什么？说明这些模型即便画面生成得再流畅、再逼真,它们对"世界现在到底是什么状态"这件事,基本是猜的,而且猜错的概率相当高。
这就好比你请了一个技术非常好的画师给你画连环画,画师画技一流,每一张单独看都精美绝伦,但你告诉他"第三格里那个人已经死了",画师画完第四格,那个人又站起来挥手了。画师没有恶意,他只是没有一个持续更新的剧本在手上,每画一格都只看上一格的画面去猜接下来该画什么。如果剧本本身不存在,画师注定会画出前后不一致的故事。
方法解读：把"记账"和"画画"这两件事分开做
论文提出的解法说起来其实挺朴素：既然一个系统同时要负责"记住世界发生了什么"和"把这些事情画出来",那就把这两件事彻底拆开,分别交给两个专门的模块去做。
**世界的状态演化,交给一个轻量级的执行引擎来管;画面的生成,交给一个预训练好的视频生成模型来管。**
引擎负责的是硬逻辑,谁的血量减了多少,谁死了没有,胜负条件是否达成,这些全部由明确写好的规则来判定,不靠模型去猜。视频模型只负责把这份已经确定好的状态,尽可能逼真地画出来。
这个思路听起来简单,但要真正落地,中间需要一个"翻译层",把引擎里那些抽象的状态数字(血量、状态、位置)转换成视频模型能理解的视觉指令。这个翻译层怎么设计,直接决定了整套系统好不好用。
状态表征：为什么选3D方框,而不是文字或者完整3D模型
论文花了不少篇幅讨论这个"翻译层"该用什么形式来表达世界状态,这一段其实是全文最见功力的部分。
想象一下你要给一个不认字的翻译描述"世界现在的样子",你可以用大白话("这里有个红色跑车,停在一栋现代建筑旁边"),也可以给他一整套精确的三维建模数据(带骨骼、带材质、带每一帧动画曲线的完整场景)。前者省事但太模糊,翻译听完还是不知道跑车具体停在哪个位置、朝哪个方向;后者精确但极其昂贵,你得先做出这套三维动画才能给他看,费时费力,而且真实录制的游戏视频里根本不会自带这种数据,想训练模型都找不到足够的素材。
论文把这个选择范围画成了一条光谱,从纯文字描述,到2D框和掩码,再到粗糙的三维骨架,一直到完整的三维场景加渲染级细节。越往右走,控制越精细,但训练数据越难获取,推理时系统需要自己填补的细节也越多。
关键性的洞察在这里：训练阶段和推理阶段,这个表征的获取方式其实是反过来的。
训练时,你手里已经有一段真实录制好的视频,你要做的只是从这段已经发生过的画面里,把它对应的结构化信息提取出来,这是"从已实现的动态倒推结构"。但推理阶段完全不同,用户只给了一个高层指令,比如"这个角色摔倒了",系统必须先凭空构造出这个动作对应的完整时序结构,然后再让生成模型把这个结构画出来,这是"从状态转变正向构造结构"。
这两个方向如果难度不对等,训练学到的东西在推理时就用不上。用一个具体场景来说明这个不对等有多大：一个角色从站立摔倒在地,如果表征选得粗,系统只需要描述"这个物体的整体位置、朝向、占地范围发生了变化"就够了；但如果表征选得太细,系统就必须自己编排出这个人四肢每一节骨骼具体怎么弯折、身体怎么扭转、着地瞬间怎么形变,这已经等同于重新做一次动作捕捉和物理仿真了。前者是一句话能说清楚的事,后者相当于要系统自己造出一整套动画师的技能。
论文最后选定的方案是"状态增强的三维定向包围盒",英文缩写OBB。
*OBB(Oriented Bounding Box,定向包围盒)：一种用位置、尺寸、朝向三组简单参数来描述一个物体在三维空间里大致占据了多大范围、朝向哪个方向的表示方法,不需要知道这个物体具体长什么样,也不需要骨骼和材质。*
每个OBB除了几何信息,还挂载了这个实体的身份标签、语义类别(是人还是车)、动态状态(是活着还是死亡)等附加信息,这就是"状态增强"的含义。
这个选择的巧妙之处在于,它刚好卡在了"系统该管什么"和"该甩给生成模型什么"的分界线上。位置、朝向、存活状态这些属于世界事实,必须精确掌控,交给引擎。而具体这个角色长什么脸、衣服什么材质、倒地那一瞬间肢体怎么扭曲,这些细节留给预训练好的视频模型去发挥,它本身就很擅长这个。
这就像一个乐队指挥和乐手的分工。指挥只管拍子、强弱、进入退出的时间点,这些是必须精确控制的"结构",指挥不会去规定小提琴手每根手指具体怎么按弦。如果指挥非要事无巨细地规定每个手指动作,乐手反而发挥不出该有的水准,而且指挥自己也没那个精力去设计几十种乐器的指法。反过来,如果指挥完全不管拍子,只说"演奏得感人一点",乐队大概率会乱成一团。OBB扮演的正是这个"指挥"的角色,管住关键节奏,把演奏细节交给专业的乐手。
从世界状态到画面：状态编译器怎么工作
有了OBB这套表征,接下来的问题是怎么把它变成视频生成模型能直接吃下去的信号。论文引入了一个叫状态编译器(state compiler)的确定性模块来完成这一步。
*状态编译器：一个不涉及任何学习、纯粹按固定规则运算的程序,负责把引擎维护的三维世界状态,按照当前摄像机的位置和角度,投影转换成画面里每个像素对应的控制信号。*
具体来说,编译器把每个实体的三维包围盒,按照当前镜头的视角投影到画面上,同时给投影出来的区域打上三种标签：身份、语义类别、运动方向。
身份标签解决的是一个很实际的麻烦：一个角色被镜头遮挡一下,或者走出画面又走回来,系统怎么知道"这还是刚才那个人"。论文的做法是维护一个身份编码库,每个持续存在的实体分配一个固定的编码槽位,这个槽位从头到尾跟着这个实体,不会因为暂时消失又出现而丢失。
语义标签解决的是另一个问题,如果一个角色是初次出现在镜头里的(比如刚从画面外走进来),系统压根没有它的外观参考,这时候至少可以靠"这是一个人类角色"或者"这是一辆车"这样的类别信息,让生成模型有个起点去合理地画出它的样子。
方向标签则是为了解决一个很容易被忽略的歧义：画面里一个物体的位置在移动,到底是这个物体自己在动,还是摄像机在动造成的错觉？编译器直接从引擎记录的三维世界坐标里计算这个实体自身的真实速度,把它旋转到当前镜头坐标系下,量化成前后左右上下静止七种状态中的一种。这样即使摄像机剧烈晃动,一个原地不动的角色依然会被标记为"静止",不会被误判成在移动。
这个设计其实解决了一个很容易被忽视的日常认知误区。你坐在一辆行驶的火车上,看窗外一棵树往后飞速掠过,这棵树其实压根没动,是你自己在动。如果不做这层区分,系统很容易把"世界在动"和"我在动"这两件事搞混,进而在生成画面时出现奇怪的抽搏或者错位。方向标签就是专门给系统装上的"这棵树到底动没动"的判断力。
渲染模块：让预训练视频模型来完成最后一步
有了状态编译器输出的这套控制信号,剩下的就是把它喂给一个视频生成模型,让模型画出最终的画面。
论文选用了一个叫LingBot-World-v1的预训练视频生成骨干网络,在它原有的摄像机控制通路之外,额外加装了一个可训练的"结构化空间控制网络"(Structured Spatial ControlNet),专门用来接收编译器产出的身份、语义、方向这三张控制图。
训练过程中,原有的骨干网络参数是冻结的,只训练新加的这一小部分控制模块。这样做的好处是,预训练模型原本积累的那些关于光影、材质、动作细节的生成能力被完整保留下来,新加的模块只负责告诉它"这个位置该有什么、是谁、往哪个方向动",不去干涉它具体怎么画。
对于长时间连续生成的场景,论文还设计了一套跨片段的记忆机制,分成时间记忆和空间记忆两部分。时间记忆保留最近几个片段的画面信息,越近的信息保留得越细,越远的信息压缩得越粗,这样既能记住细节又不会让记忆量爆炸。空间记忆则是把之前生成过的画面,通过估计的深度信息重新投影回三维世界坐标系里存起来,下次镜头转回同一个地方的时候,直接从这个记忆库里取出对应画面重新投影回来,而不是靠模型凭空瞎猜那个地方长什么样。
这套机制解决的是长视频生成里一个经典的老问题,镜头转过去又转回来,场景细节全变了。论文的实验里有一个例子,镜头做大角度旋转,原本躲在初始视角背后看不见的三个角色,在转过去之后被正确地渲染出来,而且外观和位置都符合引擎里记录的状态。这说明这套空间记忆确实在起作用,不是靠模型碰运气。
数据从哪来：一套自动化的标注流水线
训练这样一套系统,需要大量带有摄像机参数、实体身份、语义标签、运动方向标注的视频,而这类标注在真实世界的视频里几乎不存在,没人会拍视频的时候顺手把每个物体的三维包围盒记录下来。
论文因此搭建了一条自动化数据处理流水线,从没有任何标注的游戏录屏视频里,反向提取出训练所需的全部信息。
流程大致是这样：先用一个叫ViPE的工具估计每一帧的摄像机参数和深度图,搭建起一个统一的世界坐标系;再用一个视觉语言模型(Qwen3-VL)自动看视频、生成场景描述,并且列出画面里出现的可数物体类别;然后用SAM3这个分割追踪工具,针对这些类别对视频里的每个实体做逐帧分割和身份追踪;再用WildDet3D这个工具,结合深度图和摄像机参数,把每个实体的2D框提升成3D包围盒;最后通过连续帧包围盒中心点的位移,计算出每个实体的真实运动方向,排除掉摄像机运动带来的干扰。
这套流水线用《赛博朋克2077》《极限竞速地平线6》《侏罗纪世界:侵略》(原文里是《Grand Theft Auto V》,即侵入者,通常译作《侠盗猎车手5》)这三款游戏的第一人称和第三人称录屏视频作为原料,批量生产出配套的训练数据。
这一步的意义容易被低估,但其实是整套系统能落地的地基。没有这套自动标注流水线,前面所有精妙的表征设计都会卡在"训练数据从哪来"这一关上,再好的架构设计也是空中楼阁。
基准测试：CombatStateBench到底测了什么
为了系统评估这类"世界状态是否被忠实呈现"的能力,论文专门构造了一个叫CombatStateBench的测试集,包含50段战斗场景。每段场景先从第一帧重建初始三维布局,然后由一个AI代理按照设定好的游戏规则,自主推演出一段完整的战斗剧本,包括谁在什么时候死亡、镜头怎么运动、角色怎么移动。
评测用了两个指标。第一个叫计数准确率(Count Accuracy),随机抽取8帧画面,让一个视觉语言模型(用的是Qwen3.6-27B)去数画面里"还活着的角色"数量,和引擎记录的真实存活人数做比对。第二个叫状态准确率(State Accuracy),针对每一次死亡事件,抽取死亡之后的3帧画面,判断是否至少有一帧真的呈现出了角色死亡的样子。
前面提到过,LingBot-World-V2和YUME在这两项指标上的表现分别是40.75%/8.00%和32.00%/58.00%。论文提出的方法在同样的测试集上达到了计数准确率94.00%,状态准确率98.00%,分别甩开两个基准53到62个百分点、40到90个百分点。
在画面质量这一侧,论文用VBench基准的四项指标做了对比,成像质量、主体一致性、背景一致性、时间稳定性,新方法在全部四项上都拿到了最高分,其中主体一致性达到94.74%,比LingBot-World-V2高出近13个百分点。这说明把世界状态明确管理起来这件事,不仅没有牺牲画面质量,反而因为角色身份和状态更加确定,画面本身的连贯性也变得更好了。
这组对比其实提示了一个容易被误解的观点。很多人可能以为,给系统加上这么多结构化约束,画面会因此变得僵硬、失去生成模型原本的灵活性。实际情况恰恰相反,约束用对了地方,反而让生成结果更稳、更一致。
论文还展示了一批额外的场景来测试泛化能力,包括一个从没在训练数据里出现过的牛头怪场景、一个赛车游戏场景、人和车混合出现的场景,以及一段长达897帧、持续有NPC陆续进入画面的连续生成序列。这些例子说明这套框架不是针对某一款游戏死磕出来的窄口径方案,换一个完全不同的美术风格和游戏类型,同样的架构照样能用。
写在后面
读完这篇论文,让我印象最深的不是那个94%和98%的数字对比,而是它对"表征选择"这个问题的那段推导。很多论文遇到"要不要用更精细的3D表示"这个问题时,直觉都是"越精细越好,越精细才越可控"。这篇论文的态度是反过来的,它明确指出精细本身是有代价的,代价体现在两个地方,一个是训练数据获取的成本会指数级上升,另一个更隐蔽,是训练和推理这两个阶段获取同一种表征的路径完全不对等。这个"训练推理不对称"的框架其实可以套用到很多其他生成式AI的场景里去思考,不只是视频生成。
论文里那个"角色从站立到摔倒"的例子也值得单独说一说。它把这个简单的例子当成了一把尺子,用来衡量任何一种候选表征到底"贵不贵"。这种"用一个具体动作场景去检验抽象设计选择"的思维方式,比论文里那些公式本身更值得学。
CombatStateBench这个基准测试目前只覆盖了战斗场景里的生死判定,这算是一个相对简单、边界清晰的测试床。真实的可编程世界里,状态远比"活着或死了"复杂得多,比如背包里道具的组合逻辑、多个角色之间此消彼长的关系、任务进度的分支判定,这些更复杂的状态一致性,目前还没有看到对应的评测标准。这大概是接下来这个方向最值得追问的地方,一个引擎能不能维护住"生死"只是入门题,真正难的是维护住一整套错综复杂的规则网络还不崩。
Q&A
Q1：Programmable World Model解决了什么核心问题？
A：它解决的是现有视频世界模型缺乏持久世界状态的问题。传统模型只靠画面生成来"记住"世界发生的事,角色死亡等状态信息很容易在长时间生成中丢失或出错,该框架把状态管理和画面生成拆成两个独立模块,分别用引擎和视频模型负责。
Q2：为什么选择3D OBB作为状态表征,而不是更精细的3D模型？
A：因为更精细的表征(如完整3D场景、骨骼动画)在训练时数据获取成本极高,而且推理阶段系统需要凭空构造这些细节,难度堪比自己做动作捕捉。OBB只需要位置、尺寸、朝向等简单参数,足够表达世界事实,又把外观和动作细节留给生成模型自由发挥。
Q3：CombatStateBench测试结果显示新方法相比现有模型提升有多大？
A：在计数准确率上,新方法达到94%,比LingBot-World-V2的40.75%和YUME的32%高出53到62个百分点;状态准确率达到98%,比两者的8%和58%高出40到90个百分点。