给 AI 装上四肢：Jev 如何 120 毫秒实时玩 Doom

中文旁白 · 720p · 字幕轨道 · MP4

文章：AI 打 Doom 不看画面——Jev 每秒做十次选择题

TypeSafe 团队发布过一段演示视频：一个 AI 在实时玩经典射击游戏 Doom，躲怪、捡东西、找路。乍看像是又一个“AI 看着屏幕玩游戏”的例子，但这个 AI 其实不看画面，也不读任何像素。它每次拿到的，是程序用文字写好的一份状态报告。

负责做判断的模型叫 Jev，是 TypeSafe 在 2026 年 9 月发布的模型。官方称它为“系统一模型”，指的是人脑里那种不假思索的快速直觉。Jev 的用法和 ChatGPT 这类会写文章的大语言模型很不一样：程序先给它一段状态描述，再问它几道选择题，每道题的选项都是事先写好的。Jev 不生成文字，只给每个选项打一个概率，也就是它认为这个选项是正确答案的可能性。它有点像考试用的答题卡，只能在给定的格子里作答，不会输出选项以外的东西。因为不用逐字生成，它响应快，成本也低。

对做 AI 应用、后端或自动化的人来说，这个演示的看点不在于“AI 会打游戏”，而在于它展示了一种系统拆法，适合需要一秒做很多次小决定的场景。本文按视频的顺序，看看这套系统每一步在做什么：状态报告里写了什么，Jev 被问了哪些题，哪些事交给模型、哪些交给普通代码，以及这个演示证明不了什么。

演示里的几个数字

先看速度和成本。这里要分清两类来源：官方介绍文章给出的数字，和演示界面上读到的数字。

根据官方介绍文章，这套系统在游戏中每秒大约向 Jev 提问 10 次；如果一直运行下去，官方估算每小时大约花 7 美元。演示界面的顶栏则显示，每次判断平均约 118 毫秒，也就是一百二十毫秒上下；同一局里 Jev 一共被调用了两千七百多次，底栏显示的累计费用是 0.64 美元。

能做到又快又便宜，一个重要原因是它不需要运行笨重的视觉模型。识别画面要处理大量像素，而读一份文字报告轻得多。这是这套设计的出发点，下面就从这份报告看起。

状态报告：把 3D 战场写成文字

演示录像第 30 到 44 秒，屏幕上滚动着一大段 JSON 文本（JSON 是程序之间常用的结构化数据格式）。这就是程序写给 Jev 看的状态报告。

报告开头是一段写给模型的规则说明。距离用 Doom 地图的单位来量，玩家的身体大约 32 个单位宽。距离分成四档：贴脸（contact）是 64 以内，近（close）是 64 到 256，中（medium）是 256 到 768，远（far）是 768 以上。角度以玩家的视线为基准，正数在左、负数在右，正负 180 度就是正后方。游戏里计时的最小单位叫 tick，一个 tick 是 35 分之一秒；规则写明每 4 个 tick，也就是大约每 0.1 秒做一次决定，两次决定之间按键保持不变。连武器都附了一句白话点评，比如霰弹枪写的是近距离威力很大、距离远了弹丸会散开。

规则之后是玩家这一刻的情况。血量 55，满血是 100，说明已经受了伤；护甲 39，上限 200。手里拿的是霰弹枪，但已经没有子弹，身上另有一把手枪，还剩 60 发子弹。

再往下是敌人列表，每个怪物一条记录。一只叫 imp F 的小恶魔距离 57，属于贴脸档，角度是负 92 度，也就是在玩家正右边。另一只 imp G 距离 293，属于中距离，角度正 49 度，在左前方；它的状态写着 out of view，意思是虽然就在附近，但现在看不见。地上的物品同样记着距离和方向，比如一个弹夹在 814，已经算远了。

也就是说，程序先把立体的战场翻译成一份模型读得懂的文字情报，Jev 只根据这份情报做判断。

一层层的选择题：先定目标，再问怎么做

在血量 55 的同一时刻，演示界面右侧列出了 Jev 正在回答的四道题，题目都是英文问句。界面上每个答案旁边标着置信度，指 Jev 对自己选中的答案有多大把握。

第一道是开火题，问现在要不要扣扳机，选项只有开火（fire）和不开火（hold fire）。Jev 选了不开火，置信度 0.99。开火的概率低并不代表模型犹豫，反而说明它非常确定现在不该开枪。

第二道是目标题，问综合玩家、敌人和物品的情况，现在最该优先做什么。这一刻有 6 个选项：升级武器、侦察（scout）、杀敌、补弹药、加护甲和回血（restore health）。Jev 选了回血，置信度 0.95。

第三道是闪避题。它的题目里直接写着上一题的答案，大意是：玩家现在最优先的是用急救包回血，这一刻该怎么办。选项有继续（carry on）、向左闪、向右闪和向后闪。Jev 选了继续，但置信度只有 0.54，这一次它拿不太准。第四道是移动题，题目里同样带着回血这个目标，问现在该怎么走。

从这几道题可以看出，提问是分层的：先选出大目标，后面的题再带着这个目标去问具体动作。

选项本身也不是固定的。录像第 81 秒时玩家是满血，目标题只剩 5 个选项，回血这一项根本没有出现。可见哪些选项上桌，是程序根据局面决定的。同一时刻，人类玩家在命令框里输入了“不要开火，只闪避”，开火题的答案是不开火，置信度 0.97。界面上还有一个刷怪的“导演”程序，一直在往地图里放怪物。

司令官和手脚：让模型决定哪一层

演示界面下方有一张流程图，画的也是第 81 秒这一刻。左边是已知的敌人、急救包、弹药、武器和护甲；中间先选目标，这时 Jev 选的是侦察；接着选具体对象，比如对着哪一个怪物；最后落成四个输出：朝向（FACE）是 76 度，移动（MOVE）是一个目的地坐标，扳机（TRIGGER）是不开火，武器（WEAPON）是不换。

我的理解是，角度和坐标都由代码根据状态报告算出来，Jev 只负责在选项里做选择。可以把这种分工想成司令官和手脚：Jev 是司令官，决定“现在去回血”；控制器代码是手脚，负责一步一步走到急救包旁边，也就是算路线、转视角、按键。按键保持约 0.1 秒，然后进入下一轮判断，如此循环。

为什么要这样分？因为模型能做什么决定，取决于程序给它什么选项。如果选项只有前后左右，Jev 就只能选前后左右；把回血、侦察这样的目标放进选项，才真正把决定权交给了它。但这不是说目标越抽象越好。目标一旦交给模型，控制器就必须能把它可靠地执行出来。这套演示巧妙的地方，正是让模型负责决断，让传统代码负责执行。

把整条链路串起来是四步：底层代码读取游戏内部数据，写成文字状态报告；按层级向 Jev 提问，拿到每个选项的概率；控制器把胜出的选项翻译成转向、前进、开火或开门等真实按键；按键保持到下一轮判断，再从头开始。

社区复刻版：一次交一张四道题的答题卡

官方演示的代码没有公开，但 GitHub 上有一个社区复刻版 jev-doom-agent，建于 2026 年 9 月 17 日。它把真正的 Doom 引擎编译成 WebAssembly（一种能在浏览器里运行的程序格式），从引擎中导出血量、护甲、弹药、坐标、击杀数，以及看得见的怪物和物品。它的说明里同样写着：Jev 收到的是结构化的游戏状态，而不是像素。

社区版每次向 Jev 发一个请求，相当于交一张有四道题的答题卡。第一道是移动，有 6 个选项，比如原地不动、探索、靠近敌人和后撤；第二道是视角，有 3 个选项；第三道是扳机，第四道是使用门和开关，各有 2 个选项。四道题的答案同时执行，整体置信度取四道中最低的那个。如果请求失败或置信度太低，界面会明确标出 FALLBACK，表示这一步没有采用 Jev 的答案，而是走保守的备用操作。

官方版和社区版的细节不同，但工作重心是一样的：状态怎么写、选项怎么设计、控制器靠不靠得住。模型本身只是其中一环。

这个演示证明不了什么

第一，演示喂给 Jev 的是文字状态，不是游戏画面。这说明文字这条路可以做得又快又便宜，但不能说明看画面的方案不可行。

第二，Jev 能选出回血或侦察，不等于它具备长期规划能力。选项是程序根据局面给的，路线是控制器算的，探索过的地图区域也由外围代码记录下来，再作为输入交给模型。

第三，官方代码没有公开，我们不知道它一次请求问几道题。社区版是一次请求问四道题，但官方不一定也这样做。

第四，每秒 10 次、每小时 7 美元、平均 118 毫秒，都只是这一个演示的数字。换一个游戏，或者换一套状态写法，结果都可能不同。

小结

这套演示可以概括成一个模式：把状态写成文字，把决定写成选择题，再配一个靠得住的控制器当手脚。模型快固然重要，但更关键的设计是让模型决定哪一层的事。给它什么选项，决定了它能做什么决定；控制器的能力，决定了这些决定能不能落地。

这个模式不只适用于游戏，界面自动化、机器人控制这类需要一秒做很多次小决定的场景都可以试。需要说明的是，本文的分析基于官方演示画面和社区版代码，官方实现的内部细节仍然未知；搬到别的场景时，速度、成本和判断准确率都需要重新测量。演示原帖见 X 上的官方演示。

系列：Jev01 · Jev02 · Jev03。