游戏开发,能不能成为AI世界模型的"编译器"?

2016年,AlphaGo打败李世石那会儿,很多人第一次意识到一件事:如果一个系统能被清晰地判断输赢,它就能通过自我对弈疯狂进步。

围棋有规则,输赢分明,这是它能被强化学习驯服的根本原因。

那问题来了:为什么写代码的AI(比如各种Coding Agent)也进步神速,但生成3D场景、生成视频的AI却总感觉卡在半山腰?

这篇来自新加坡国立大学、香港科技大学等机构联合发布的论文,给出了一个挺扎心的答案:不是数据不够多,也不是算力不够猛,而是这类任务从根上就缺一个"判卷子的人"。

而他们找到的答案,有点意外:游戏引擎。

一、代码为什么能进步这么快

先说清楚一件事,写代码的AI能突飞猛进,靠的不是代码本身有多特殊,而是代码这个东西天生自带"判官"。

你写一段代码,编译器立刻能告诉你语法对不对,测试用例能告诉你逻辑对不对,运行时能告诉你会不会崩溃。

这套反馈机制被称为RLVR(强化学习+可验证奖励):一种让AI通过明确的对错信号自我迭代的训练方式,DeepSeek-R1等推理模型的爆发式进步都靠它。

这套机制的关键不在于"代码"这两个字,而在于它提供了两层验证:一层是廉价、客观、可自动化的机器验证(编译器和测试跑一下就知道对不对),另一层是人类的主观验收(代码跑通了,但架构烂、不符合产品需求,照样被打回重写)。

这两层验证叠加起来,才是代码类AI进步飞快的真正原因。

反观生成一段视频、一个3D场景,现在业内怎么打分?

CLIP相似度、FVD(Fréchet视频距离)、MLLM当裁判(让另一个大模型去评判生成质量好不好),这些指标本质上都是"看着顺眼就给高分"的模糊代理指标,论文里管这类信号叫Fuzzy Proxy(模糊代理)。

问题是,这些分数经常和真实质量对不上。

一个视频物理规律乱七八糟,但只要色彩鲜艳、构图讨喜,CLIP照样能打高分。这就是典型的"奖励作弊"(reward hacking):AI学会了讨好评分标准,而不是真正把事情做对。

论文里给出了一个很直白的数学解释:假设你手头的奖励信号Rf和真实质量Q*之间存在偏差,这个偏差可以拆成两部分,一部分是随机噪声,另一部分是系统性偏见。

噪声只是让训练效率打折扣,但偏见是致命的:如果这个偏见方向恰好是可以被"钻空子"的,那模型会拼命朝着这个方向优化,分数越冲越高,但真实质量反而越来越差。

这就好比一个学生发现,老师改作文只看字数和好词好句的密度,压根不细看逻辑。

那这个学生会怎么做?疯狂堆砌华丽辞藻,写一堆语法通顺但内容空洞的废话。作文分数蹭蹭往上涨,但写作能力其实原地踏步,甚至倒退了。如果一直用这套评分标准训练下去,你培养出来的不是好作家,是"作弊高手"。

这就是当下3D生成、视频生成、世界模型领域正在发生的事。

二、游戏引擎:一个被忽略的"裁判员"

论文提出的核心洞察是,游戏开发这件事里,其实天然存在着一套双重验证系统,而这套系统被行业忽视了。

想想开发一个游戏是怎么运作的。

你在Unity(一个主流的游戏开发引擎)里摆一个箱子,如果这个箱子和椅子的碰撞体积重叠了,引擎立刻会报错,这是碰撞检测。

你想让NPC(游戏里的非玩家角色)从A点走到B点,引擎的Navmesh系统(导航网格,决定角色能不能寻路通过某片区域)会告诉你这条路能不能走通。

你写了一段脚本,引擎运行时会告诉你有没有崩溃、有没有死循环。

这些都是廉价、客观、自动化的检查,和代码编译器的角色一模一样。

但游戏开发不止于此。就算所有的物理检查、碰撞检测都通过了,一个真正的游戏开发者还是可能拒绝这个场景:氛围不对、和设计意图不符、玩起来别扭。

这一步是人类主观的验收,和代码审查里"通过了测试但架构烂"被打回是同一个逻辑。

论文把这套组合拳命名为RLHEV(人类工程师联合验证的强化学习):一种把游戏引擎的自动检查和人类开发者的最终验收结合起来的训练方法,用公式表达就是在满足引擎硬性门槛(比如碰撞不能穿模)的前提下,最大化"人类验收得分减去各种物理违规的惩罚项"。

这个设计的巧妙之处在于分工:引擎负责密集、便宜、可重复的结构性检查,人类只需要在这些检查都通过之后,把关最后一道"这东西真的对吗"的问题。

打个比方,这就像餐厅后厨的双重把关:厨房质检员会检查每道菜有没有超过保质期的食材、温度够不够、分量对不对,这一层可以自动化、可以每分钟检查一次。

但最后端到客人面前的那道"这道菜好不好吃、符不符合这家餐厅的调性",还得靠主厨亲自尝一口。

如果没有质检员这一层,主厨每道菜都要从头到尾盯着,根本忙不过来。如果没有主厨最后把关,质检合格的菜也可能难吃得要命。两层缺一不可,这就是RLHEV想复制的结构。

三、把这套流程存下来:UWDP协议

光有验证机制还不够,论文还提出了一件更细致的事:把整个开发过程完整记录下来。

这里有个很扎心的洞察:一个做完的游戏场景,只能告诉你"结果是什么",完全不能告诉你"为什么这样做是对的"。

一份最终交付的3D场景,你看不到设计师最初的意图是什么,看不到中间试了多少次失败的方案,看不到引擎报了什么错、又是怎么修复的,更看不到人类审核员当时提出了什么批评意见。

这就好比只保留一份考卷的最终答案,而把演算过程全部撕掉。老师批改的时候,只能判断这道题对不对,却完全没法知道学生是蒙对的,还是真的理解了解题步骤,更没法知道这个学生上一次做错的题是怎么改对的。如果不保留演算过程,你就永远没法用这些数据去训练下一个"更会做题"的模型,你能训练的只是"更会蒙对答案"的模型。

论文提出了UWDP(统一世界开发协议):一套把游戏开发全过程,包括设计意图、场景状态、编辑动作、引擎检查结果、渲染证据、人类审核意见,全部结构化记录下来的数据格式。

一条完整的UWDP记录长这样:设计简报是什么、涉及哪个物体、场景当前状态如何、执行了什么编辑动作、引擎返回了什么检查结果、渲染出来的画面证据、人类审核员的决定,还有修复动作之间的关联和风险备注。

整个采集流程也很朴素:解析设计简报,生成候选编辑,记录引擎快照和检查结果,把失败转成具体的修复动作,不断循环直到引擎测试通过并且人类审核通过,最后把整条轨迹连同监督信号一起存下来。

这条完整的轨迹数据,才是这篇论文认为真正值钱的东西,比最终那个"做好的场景"值钱得多。它记录的是"怎么把一件事做对"的完整过程,而不只是"做对了"这个结果。

四、AWoMo:让世界模型在开发流程里边干边学

有了RLHEV这套验证逻辑和UWDP这套数据记录格式,论文提出了具体的落地系统:AWoMo(智能体世界模型)。

AWoMo不是一个孤立的生成模型,而是嵌在一整套开发工作流里的角色组合:一个提议编辑的模型、一个执行动作的智能体控制器、一个负责检查的游戏引擎、一个负责验收的审核者,再加上一个存储轨迹的数据库。

它的运行逻辑是一个五步循环:提议、渲染、验证、修复、审核。

模型先提出一个编辑方案,引擎执行并渲染出结果,同时定位出哪里出了问题;智能体根据引擎反馈的问题给出修复动作;这个循环持续进行,直到审核者最终点头接受或者拒绝。

这个模型的底层核心是UnifiedGameAssetModel,一个基于Cosmos 3(一个面向物理世界的全模态基础模型)持续预训练出来的模型,拥有约28.9亿参数,支持文本、图像、3D高斯资产、网格、以及Unity、Unreal、Godot、MuJoCo这几种游戏引擎和物理仿真表示之间的转换。

它的预训练数据里包含87745条被接受的样本和504条被拒绝的样本,值得注意的是,被拒绝的样本也被保留下来,因为它们提供了"验收信号"里那一半负面案例,而这一半案例在传统的最终成品数据集里基本是缺失的。

论文里有一个特别值得琢磨的细节:这套系统同时打通了"理解"和"生成"两个方向。

生成是从设计意图出发,正向映射到一个可执行的场景程序;理解则是反过来,从观察到的图像、视频或场景,反推出这个场景背后的结构和意图。

论文的观点是,这两个方向本质上共享同一套监督信号:创造一个生成目标的那次编辑动作,同时也创造了理解这个目标所需要的大部分标注数据。这就好比学做菜和学品菜其实是同一套知识体系的正反两面,一个厨师如果既会做菜又会精准地尝出别人菜里少放了什么调料,这两种能力大概率是互相成就的。

五、实验结果:全套验证信号确实管用

理论讲完了,接下来看数据。

论文首先在自建的UnitySceneBench(一个包含200个Unity资产编辑样本的评测基准)上做了对比实验,测试模型判断一个资产编辑是该接受还是该拒绝的能力。

| 方法 | 主分数 | 准确率 |

|---|---|---|

| 零样本CLIP | 约0.55 | - |

| 模糊代理基线 | 约0.53 | - |

| 监督微调基线 | 约0.53 | - |

| 离线RLHF(仅人类反馈) | 约0.51 | - |

| 仅引擎验证的RLVR | 约0.58 | - |

| **完整RLHEV** | **0.681** | **0.665** |

完整RLHEV拿到了最高分,比第二名高出接近0.1个百分点,而且这不是运气,论文还专门在不同训练样本规模下(从40条到720条)做了8个随机种子的重复实验,曲线显示这个优势是稳定的,不是某一次运气好。

有意思的是,只用人类反馈的Offline RLHF,和只用引擎反馈的Engine-based RLVR,单独拿出来都打不过全套组合,这恰好印证了论文最核心的假设:两种信号必须叠加,少一种都不够。

接下来是泛化能力测试,这才是真正考验这套方法有没有"真本事"的地方。

论文设计了两种迁移场景,一种是同引擎内的分布偏移(比如Unity内部换一批风格差异较大的场景),另一种是跨引擎迁移(从Unity迁移到Unreal或者Godot)。

| 迁移场景 | 从零训练 | 先在源域预训练再迁移 |

|---|---|---|

| Unity内分布偏移 | 0.25 | **0.75** |

| Unity迁移到Unreal | 0.25 | **0.35** |

| Unity迁移到Godot | 0.15 | **0.35** |

同引擎内的迁移效果非常显著,从0.25直接跳到0.75。跨引擎迁移的提升幅度小一些,但方向依然是正的,而且损失值和代理分数也同步在变好。

论文对这个现象给出的解释是,不同引擎的碰撞语义、导入格式、导航系统天差地别,所以源域的经验没法完全平移过去,但至少提供了一个不错的起点,再加上目标域的少量微调,就能把这个起点校准过来。

最后一组实验测试的是这套体系生成的数据,能不能帮助其他任务的智能体表现得更好。

| 基准测试 | 原始基线 | 简单数据增强 | AWoMo增强 |

|---|---|---|---|

| R2R(视觉语言导航) | 76.01% | 76.18% | **76.61%(+0.79%)** |

| Gymnasium MuJoCo(机器人控制) | 1568.44 | 1648.03 | **1724.73(+9.96%)** |

| D4RL Gym-MuJoCo(离线强化学习) | 18.30 | 25.56 | **27.16(+48.43%)** |

D4RL这个基准上的提升幅度最夸张,接近50%。这说明用AWoMo这套流程生成的辅助训练数据,确实能让下游的具身智能体(能感知环境并做出动作的AI系统)表现得更好,而不只是在游戏资产分类这一个孤立任务上有效。

六、这套方法也有它的软肋

论文自己也很坦诚地列了几条最尖锐的质疑,值得拿出来说说。

第一条是最直接的:游戏毕竟不是现实世界。

在游戏引擎里训练出来的经验,能不能真的用到现实机器人身上?论文承认目前的实验里完全没有真实扫描数据、没有真实机器人,这个"从模拟到现实"的桥梁还没搭起来,只是提出了游戏引擎是一个"验证信号丰富的训练场",但离真正解决现实迁移问题还很远。

第二条是引擎奖励也能被钻空子。一个设计粗糙的碰撞检测阈值,同样可以被AI找到漏洞、专门去讨好这个阈值而不是真正把物理关系摆对。论文的应对策略是用多重验证器、随机化探针、加上人工审核兜底,而不是指望单一的引擎信号就能万无一失。

第三条更微妙:不同游戏引擎之间的经验能不能互通?实验数据显示能,但幅度有限。这提醒我们,这套体系目前更像是一个"在同一套规则体系里进步很快"的机制,跨体系迁移仍然需要额外的校准成本。

写在后面

读完这篇论文,最让我想不通又想通了的一点是:我们一直在讨论怎么让AI"更聪明",但很少去讨论"谁来告诉AI它做得对不对"这件事本身有多难。

代码有编译器,围棋有输赢,数学有对错,这些领域进步飞快,不是因为AI在这些领域特别擅长,而是因为这些领域天生自带裁判。而视频、3D、世界模型这些领域,长期以来都在用"看着顺眼"当裁判,这本身就是一种偷懒,也难怪进步会卡壳。

游戏引擎这个选择挺妙的,它不是凭空造了一个新裁判,而是发现了一个早就存在、每天都在被无数游戏开发者使用、却从来没被当成"AI训练基础设施"的现成系统。这种"重新发现已有资源的价值"的思路,比造一个全新工具更让人觉得聪明。

另外一个让我意外的细节是,论文特意强调了"被拒绝的样本也要保留"。这其实是个反直觉的操作,大部分数据集的直觉是只留好的、扔掉差的,但这篇论文认为差的样本恰恰是训练"审美判断力"最重要的负样本。这让我想起,教一个人分辨假币,光看真币是学不会的,必须见过大量假币才行。

这套体系最终能不能真的接上现实世界,论文自己也没给出答案,只是留了个开放性的问题:当AI开始大规模参与到人类的创造性劳动过程中,并且从这个过程本身学习,这会不会是比"AI训练AI"更靠谱的一条自我进化路径?

Q&A

Q1：AWoMo是什么?

A：AWoMo是论文提出的智能体世界模型,它嵌在游戏开发工作流里,负责提议场景编辑、观察引擎和人类的验证反馈,并把这些开发轨迹转化为训练数据,持续自我提升。

Q2：RLHEV和普通的强化学习训练有什么不同?

A：RLHEV把游戏引擎的自动化检查(比如碰撞检测、物理稳定性)和人类开发者的最终验收结合起来,前者提供密集廉价的结构性奖励,后者提供稀疏但更贴近真实需求的验收信号,两者缺一不可。

Q3：这套方法在跨游戏引擎场景下效果怎么样?

A：论文测试了从Unity迁移到Unreal和Godot的效果,发现先在Unity上预训练再做目标域适配,比从零训练效果更好,分数从0.25/0.15提升到0.35,虽然提升幅度小于同引擎内迁移,但方向是正的。