看到某个技术社区冒出一条项目帖子标题只有一句话Doom Compiled into an LLM。我的第一反应不是“太酷了”而是一连串问题这个 Doom 是真正可以交互的画面还是一段不断生成出来的视频它真的跑在模型里面还是模型只是在给原来的游戏引擎打辅助如果把游戏“编译”进一组权重里那“运行”这个词到底还算不算成立这些问题比标题本身更值得展开。这些年我们已经见过太多“AI 跑游戏”的变体有让模型当玩家去操作 Doom 的有让模型预测下一个画面来模拟游戏引擎的也有只是把游戏画面当作视频生成任务来做“看起来像”的。标题里的 compiled 太有煽动性它让你以为有人把 Doom 的源代码变成了一堆参数然后一个 LLM 在内部像 CPU 一样执行它。这个想象很浪漫但技术上的真相要复杂得多也更值得仔细拆。这篇文章不打算复述任何安装步骤也不假设那个项目的内部实现只有一种。我只想从原理上把这类事情拆清楚什么叫做“游戏跑在 LLM 里”它和传统模拟器有什么本质差别为什么选 Doom以及我们判断这种 Demo 时到底应该看哪些细节。1. 先别急着惊叹先拆开“编译进 LLM”这句话1.1 一个标题至少包含三种完全不同的技术方案只看“Doom Compiled into an LLM”这个标题普通人会想到一个画面模型内部有一个活着的游戏有人按键盘游戏就更新画面。但从工程实现上讲这个标题至少可能指向三种完全不同的东西第一LLM 只是“玩家”引擎还在外面。模型拿到的输入是屏幕像素或游戏状态它输出动作真实引擎负责计算碰撞、伤害和下一帧。这种做法在强化学习里很常见某种意义上只是“用 LLM 玩 Doom”并不算编译进 LLM。第二LLM 是“世界模型”用来替代游戏的状态更新函数。输入当前状态和玩家动作输出下一个状态或下一帧画面。游戏不再按二进制代码执行而是按模型的预测生成。这才是更接近“编译进模型”的方向。第三LLM 只做局部补全混合外部逻辑。地图规则、敌人 AI、伤害判定仍由传统代码控制模型只负责把状态渲染成画面或者把玩家的自然语言指令转成动作。这种方案看着最通用但它更像是一个大模型中控系统。同一个标题三种实现技术含量完全不同。如果只是为了欣赏视觉效果第三种可能最容易出效果但如果说“编译进 LLM”那真正值得讨论的是第二种。1.2 “编译”更适合被理解成一种比喻传统意义上的编译是把高级语言翻译成机器指令然后硬件逐条执行。这个过程是可解释的也是确定性的同一份代码在同样环境下运行结果一致。而把一个游戏训练进神经网络完全不是这种逻辑。模型并不知道自己“内部有一个 Doom”它只是从海量数据里学会了一件事情给定某个画面和某个操作下一步画面大概是怎样的。更准确的说法是人们把一个可执行程序的状态转移关系压缩成了一大组参数。所以这个“编译”的含义其实更接近“用拟合代替执行”图的是好听而不是精确。如果你要用这个说法去和同事沟通最好先解释清楚它不是说模型内部跑着一个二进制镜像也不是说权重里藏着完整的代码逻辑。更准确的理解是一段传统程序的功能被神经网络的参数化表示替代了。注意看到这类标题时先不要脑补“模型里真的在运行一个游戏引擎”。大多数情况下它只是把“状态到状态的映射”变成了“网络前向计算的预测”。2. 为什么这种实验偏偏要选 Doom2.1 Doom 是 AI 研究里一块绕不开的试验田如果只是想证明“模型能生成连续视频画面”其实有很多更简单的选择比如 Minecraft 的走路演示或者找一个固定摄像头下的街道场景。但 Doom 不一样。Doom 不是一段风景视频它是一个实时、第一人称、需要玩家在三维空间里移动和射击的游戏。画面里有敌人移动、弹道飞行、开门、伤害数字还有玩家自己视角的转动。这些元素让模型不能只学着生成“看起来像像素的画面”它必须处理好空间关系、遮挡变化和动作与结果的因果关系。强化学习研究里Doom 早就不是一个普通游戏了。它长期被用来测试智能体在视觉导航、对抗决策和部分可观测环境里的表现。因为它有明确的奖励信号击杀、生存、到达终点又有肉眼可见的复杂环境状态天然适合作为控制算法的试验场景。所以当一个项目说“我把 Doom 跟 LLM 结合了”这件事本身就带着强烈的实验味道它不是拿一个简单任务刷指标而是在挑战一个动态画面的因果推理问题。2.2 对 LLM 来说真正难的不是画得像而是“换一个动作画面必须相应地变”很多人误解视频生成模型的难点以为只要每一帧都清晰整体就成功了。但在游戏模拟里画面清晰只是底线模型必须做到“我按了左转视野右侧的东西必须移动过去我开枪敌人必须倒下我走过头地图必须符合空间结构”。这在机器学习里有个朴素的说法叫一致性但实现起来非常难。LLM 天生是自回归的它一帧一帧地预测下一个 token每一次预测都有出错的可能。游戏状态是有结构的如果模型只是把当前画面当作一张孤立图片没有利用过去若干帧和当前动作那它的输出很快会变得飘忽墙会变形敌人会瞬间瞬移玩家可能穿过本来不该穿过的障碍物。Doom 的价值就在于它把所有这些问题一次性暴露出来。连续动作、三维空间、实时反馈、看不见的角落几乎每一项都在考验模型的长期记忆和状态跟踪能力。这也是我认为它是绝佳试金石的原因——任何一点内部机制偷懒都会在画面里露出破绽。2.3 复古游戏在视觉上降低了门槛但没有降低因果维度选择老游戏还有一个现实原因Doom 的画面相对低分辨率调色板简单模型生成这样的画面比生成 4K 写实场景容易得多。它可以减少“画质不好”带来的干扰让讨论更集中于“游戏规则是否成立”。但不要因为这个就说它简单。画面可以模糊规则却不能逻辑不通。换句话说Doom 降低的是生成难度不是推理难度。3. 一个可以照做的拆解这类 Demo 最少需要哪几块组件如果你不是只想看别人表演而是想自己复现或改造一个类似项目那最少要准备四块东西。这是一个通用框架不一定严格和原始项目一一对应但足够帮助你理解问题边界。3.1 第一块能产生带动作标签的状态轨迹训练数据是整个方案的地基。你需要让某个“外部玩家”先玩很多把 Doom把每一时刻的游戏状态和玩家动作记录下来形成(state_t, action_t) - state_{t1}这样的样本。这个外部玩家可以是人也可以是一个简单的脚本甚至可以是一个预先训练好的强化学习代理。关键在于数据要有足够的动作覆盖面。如果数据里 90% 都只是往前走那模型就学不会“转身”“跳”“开枪”之后世界会发生什么。实际工程里数据多样性不足造成的影响往往比模型结构选择更大。记录下来的状态也有很多种形式直接记录屏幕帧也就是视觉状态提取隐藏的游戏变量比如玩家坐标、朝向、血量、弹药同时记录两者让模型既能看到画面也能知道真实逻辑状态。实践提示如果只是为了尽快验证想法不要一开始采集大量人类玩家数据。先让一个确定性脚本去推送各方向移动和攻击指令生成少量样本观察模型是否能在短序列里保持基本一致性再逐步加数据。这样可以先判断“这条路能不能通”再决定要不要烧训练成本。3.2 第二块把画面和动作变成模型能读的 tokenLLM 不是直接“看图片”的它处理的是离散 token。所以要做两件事一是把图像压缩成离散表示常见做法叫 tokenization也就是让视觉编码器把一帧图变成几十或几百个视觉 token。二是把动作文本化比如把“向左转、前进、开枪”表示成一个动作描述串拼到画面 token 前面。这里有个隐藏的设计选择到底把上一帧画面传进去还是把过去好几帧画面传进去如果只传当前帧模型没有运动信息画面很容易闪烁。如果传过去几十帧计算量会很大而且上下文窗口很快就满了。很多这类项目最终采用折中方案传最近几帧图像再叠加一些高层状态描述比如“玩家当前在走廊拐角面前有敌人”。模型输入不一定是像素。你也可以把地图信息表示成 token。这样做的好处是逻辑更稳定坏处是失去了“纯画面输入”的通用性。实际上不同项目做这种选择时已经决定了模型的定位是做体验生成器还是做逻辑仿真器。3.3 第三块让模型做“条件下一个状态”的预测训练完之后推理阶段是一个自回归循环。简化后的流程如下# 示例结构LLM 作为状态生成器的循环 state_t initial_state while running: action get_player_action() # 把上一段状态、动作、历史帧编码成输入 prompt make_prompt(state_history, action) # 模型输出下一状态的 token 表示 next_tokens llm.generate(prompt) # 解码成新一帧画面以及可选的语义状态 state_t decode(next_tokens) render(state_t) state_history.append(state_t)这段伪代码揭示了一个核心问题模型输出的下一状态会成为下一次预测的输入。一旦某一步预测错误错误不会停留在一帧而是会不断传播画面会越来越偏离真实游戏状态。在实际训练里很多人会增加一些防漂移手段比如让模型偶尔看到“带噪声的自己上一轮输出”逼它学会从错误状态里恢复。这和 NLP 里的暴露偏差问题本质是一样的。3.4 第四块一个不只看画面像不像的评估方法评测是这类项目里最容易偷懒的地方。很多演示做出来视频看着流畅观众会很兴奋。但如果拿“真实 Doom 引擎在同一操作序列下的输出”作为标准答案模型的输出很快就会跑偏。一个合格的评估不只要看下一帧的像素误差还要看玩家位置是否在空间上连续经过门后是否到了正确房间血量、弹药数字是否和画面里的状态对应连续跑 200 步后世界有没有变成一堆毫无结构的色块如果从第 50 帧起始接着跑场景是否和从第 1 帧完整跑过来一致。这些指标很难用一个最终数值概括。它更像一套健康检查每一项都在回答“模型是否真的理解了游戏状态”。4. 我看到的真正价值不是多了一个“会打游戏”的模型而是多了一种“运行时”4.1 从“执行二进制”到“生成下一步状态”传统游戏是一个严密的三层结构输入设备把操作送进游戏逻辑游戏逻辑更新内存里的状态渲染器把状态画成画面。整个过程每一步都在执行程序员写死的指令。而“把 Doom 编译进 LLM”这类尝试悄悄改变了最核心的那一层状态更新不靠指令执行靠模型预测。相当于把游戏从“可以被解释的确定性程序”变成“从数据里学出来的概率模型”。这个变化的意义不在游戏本身而在于它提供了一个思维模型我们并不一定非要为所有交互系统写复杂的状态机。如果有足够数据和算力一个模型可以学会状态转移的规律并在运行时以生成的方式重建交互体验。这就是世界模型思路的核心。它不只适用于游戏也适用于机器人、自动驾驶、仿真环境和内容生成工具。Doom 只是这个思路最简单也最直观的测试壳。4.2 新运行时带来新问题传统程序的好处是确定性和可调试性。你可以复现 bug可以查 memory可以单步执行。一旦逻辑被参数化之后这些都不再天然成立。模型运行游戏时最让人头疼的问题就是不可复现和不稳定。同样一段输入由于采样带有随机性模型可能生成两种截然不同的后续状态。你觉得是 bug但它只是模型的概率分布里自然而然出现的样本。这意味着我们对待“运行结果”的态度要改变。以前我们会说“游戏崩了”现在可能要区分“画面崩了”“状态崩了”和“因果崩了”——三个问题对应的修复方式完全不一样。4.3 模型的极限在哪里目前任何声称把游戏跑在 LLM 里的项目都无法回避三个硬约束速度。LLM 生成一帧需要大量前向计算和传统引擎每秒钟几十次的逻辑循环相比慢很多个数量级。上下文窗口。完整游戏状态无法全部塞进上下文。真实项目通常只保留最近若干帧这决定了模型不可能拥有真正完整的长期记忆。错误累积。自回归生成天然存在漂移。就算单步预测准确率是 99%误差叠加几百步后仍然可能面目全非。所以更现实的工程路径往往不是完全放弃传统代码而是混合传统代码负责高精度的碰撞和进度管理模型负责内容生成和体验补全。想要一步到位用模型替代整个引擎至少在目前还不现实。5. 验证清单不被演示视频带走要怎么判断这类 Demo 是否成立5.1 四条检查原则如果你以后再看到“某某游戏跑在模型里”的演示别只看前几秒画面有多流畅。我建议用四条原则来判断它是否真的成立。外观层画面是否清晰稳定但这只代表生成能力不表示游戏逻辑成立。逻辑层玩家的操作和画面变化是否符合真实游戏规则比如开枪后敌人是否会死推开门的动作是否导致新的空间出现。记忆层模型能否记住物品数量、血量、地图位置这类跨帧状态很多 Demo 在这一点上会露馅。边界层如果输入训练数据里没见过的新操作比如用特殊方式卡进墙角模型会怎么反应能不能给出合理反馈还是直接混乱这套检查原则可以帮你在五分钟内判断一个演示是真正的工程突破还是只是好看的视觉生成。5.2 一份最小可执行的检验流程如果项目可以自己运行我会建议你按下面的步骤验证而不是只看作者生成的视频先把所有随机种子固定住跑一条动作序列记录输出。重复多次相同实验看结果是否稳定。如果每次都不一样说明系统里存在较强的采样不确定性需要进一步确认是不是设计如此。加入训练分布之外的极端操作比如一直向后走、在墙角反复抖动、连续快速切换武器。好的世界模型就算做不到完全准确也要给出可理解的反应。观察画面上的数值类信息比如血量、弹药、关卡计时器是否与你的操作和战斗结果一致。从第 1 步和第 50 步分别作为起点执行完全相同的后续动作比较两种情况下输出的状态差异。差异越大说明模型的长期状态保持越弱。这套流程可以复用于大多数“用模型做世界模拟”的项目不需要作者提供任何内部代码。5.3 常见翻车点在猜测或复现这类项目时下面这几种情况我几乎一定会遇到。表层现象深层原因建议验证方式画面远处出现扭曲模型没有建立完整三维结构只做局部补全让视角快速旋转观察边缘是否有稳定几何结构血量减少但敌人没死模型把血量和敌人状态当作两个独立视觉属性对照击杀动作和数值变化之间的因果关系走过一扇门后场景跳变模型上下文窗口无法保存完整地图拓扑记录路径然后反向走回看能否回到同一场景长时间运行后画面越来越模糊自回归错误累积模型正在失去结构化记忆在长时间运行后重置观察条件对比前后差异短片段很流畅长片段很快崩演示视频只截取了状态漂移前的片段要求作者提供完整无剪辑 session或自己连续运行我不是在说每个项目都会翻车而是想强调从“几步生成很像”到“一个可以用状态机标准来验证的模拟器”之间还有很长一段路。大多数演示都处在这条路的中间某个点。6. 这类 Demo 真正值得长期关注的不只是游戏如果把 Doom 这个壳拿掉剩下的问题其实非常本质我们能不能把“对世界的模拟”从手写逻辑变成从数据中学习出来的生成过程如果答案是能那么同样方法可以用来生成高质量的虚拟仿真环境、用来做内容生产的交互体验也可以用在机器人训练里合成大量有反馈的场景。但我也会提醒一句不要把这类项目理解为“以后可以用 LLM 重写所有引擎”。那是因为传统引擎具备明确可控、高效稳定、可调试等特性目前模型很难同时提供这些能力。更合理的方向是二者共存——传统逻辑负责边界与规则模型负责开放内容和低成本仿真。另外一个值得长期关注的点是这类项目让“模型与环境的闭环”成为了一个可复现的研究对象。以前我们讨论 LLM多半是给它一段文本让它给出一段文本但当 LLM 需要持续接收上一轮输出、继续决定下一轮状态时它就进入了一个真正面向世界的交互范式。在这里错误、记忆、不确定性都不是附带现象而是核心问题。这个方向将来最难的大概率不是让一帧画面更逼真而是让模型具备“知道自己不知道什么”的能力。因为游戏世界是封闭的、状态有限的Doom 这类场景还能靠大量数据覆盖。一旦面对真实世界那种无限开放的状态空间模型如何在不确定的地方停下、求稳、更新才是真正的分水岭。下次再看到类似标题我的建议是不要先问“能不能跑”而是先问“它到底以什么方式跑”。是模型作为大脑在操控外部引擎还是模型作为世界模型在内部生成整个状态前者会让我们看到越来越多“会玩游戏”的对话模型后者才会把我们带向“可生成、可交互的世界模拟器”。Doom 只是这场变化里最显眼的一块试金石真正的演变还在后面。