为什么新模型发布，都要先做一个游戏？

一款大作面世，人们早已习惯以「年」为单位计算时间。开发团队要搭建城市和关卡，设计战斗规则，让角色、武器、物理与画面在玩家按下每一个按钮时正确合作。

另一边，几乎每款新的 AI 模型发布后，互联网上都会迅速出现一批游戏，速度堪比 Steam 上新。模型发布后的传统节目原本是跑分，现在，越来越多人选择让它做一款游戏。

当 AI 公司需要证明一个新模型究竟强在哪里，它们为什么越来越喜欢让模型先做一款游戏？

一只怪鸟，如何变成了模型测试

这种展示方法有一个简单的前身。2024 年，独立开发者 Simon Willison 开始用同一句提示词测试不同模型：「生成一张鹈鹕骑自行车的 SVG」，而且是模型直接写出构成图像的 SVG 代码，不能只是给个图。

任务听起来近乎玩笑，但实际做起来并不容易：自行车需要两个对齐的轮子、相连的车架、车把与踏板；鹈鹕不仅要被画出来，还要坐在车座上，把脚放到踏板附近，身体与自行车保持合理比例。代码只要漏掉一个标签，图像便可能无法渲染；坐标关系稍有偏差，鹈鹕就会悬在车外，车轮和车架各过各的生活。

早期模型画出的结果通常只是两个圆、一个三角形和一只勉强能认出的鸟。到了 2026 年，新模型已经会给鹈鹕补上羽毛、长喙、脚蹬和车链，甚至主动增加鱼篮、帽子与沿途风景，景色要随着动作有所变化。

「鹈鹕测试」并不是严谨 benchmark，它只运行一次，没有统一控制推理档位、成本和工具，也不能证明哪一个模型综合能力最强，它流行的原因在于不需要解释。空间关系是否合理、代码有没有正确变成图像，一眼就能看见。

游戏延续了同一种逻辑，只是把静止的 SVG 变成了可以操作的系统。如果说鹈鹕测试的是模型能否把一组代码组织成连贯画面，游戏测试的是，当用户有所操作后，模型设计出来的框架和组件，还能不能继续运作。

游戏里藏着多少种能力

以近期常见的「单提示词制作 FPS」为例，玩家拿着武器移动，敌人从远处靠近，开枪后出现命中反馈，击败一波敌人后进入下一关。

看着只是十几秒之间的操作，模型实际需要同时搭起许多相互依赖的部分：它首先要建立三维场景和第一人称相机，让鼠标控制视角、键盘控制移动；还要生成武器、敌人与障碍物，并处理它们之间的距离和遮挡。扣下扳机后，程序需要计算射线或子弹轨迹，判断有没有命中敌人的碰撞区域，再扣除生命值、播放动画、更新得分。敌人还要知道怎样寻找玩家，关卡系统则要决定下一波在何时、何处出现。

这些功能单独写对了，游戏仍然可能没法玩：相机转动与角色方向没有同步，玩家会横着滑行；子弹击中模型却没有触发碰撞，枪便只是会发光的装饰；敌人、计分与关卡各自运行，却没有共享同一套状态，游戏就无法形成循环。

因此，一款简单游戏同时检查代码生成、空间理解、视觉设计、状态管理、物理规则、交互反馈和错误修复。它还要求模型完成最后那一点常被 Agent 忽略的工作：把零散功能接起来，交付一个用户真的可以操作的成品。

这正是游戏比「写一个登录页面」更适合展示模型力的地方。网页可以靠一张漂亮截图遮住按钮失效，游戏却会在玩家第一次移动、射击或撞墙时暴露问题。代码是否运行只是第一关，输入是否改变世界、世界是否及时回应，才决定它是不是真-游戏。

为什么是浏览器游戏

新模型演示里的游戏，大多不是需要安装的完整客户端，而是由 HTML、JavaScript、Three.js 或 Phaser 搭成的浏览器作品。

这类游戏对模型格外友好。前端库、教学代码和常见玩法在公开互联网中大量存在，模型熟悉怎样调用它们；浏览器又已经内置图形、声音、输入与网络能力，一份代码便能同时容纳画面和玩法。作品完成后只需放上静态网页，别人点开链接即可运行，不必配置引擎和下载文件。

游戏本身也提供了高度成熟的语言。看到第一人称镜头，模型知道鼠标通常控制方向；看到赛车，便可以调用加速、碰撞、计时和检查点；看到塔防，则能从射程、冷却、资源和波次开始组织系统。它不必从零发明「什么叫游戏」，而是把训练数据中积累的大量惯例重新拼装起来。

这让游戏成为一种非常高效的模型展示：技术上足够复杂，传播上又足够轻巧。几万行代码最终被折叠为一段人物奔跑、车辆转弯或子弹命中的视频。观众不需要理解代码，也能判断画面是否穿帮、操作是否流畅。

但这种优势同样会美化模型。熟悉的玩法拥有大量现成范式，浏览器原型也不必处理账号系统、多人并发、不同硬件、版本更新和数年维护。模型做出一款能跑的射击游戏，与一个团队交付真正的商业游戏，仍然是两种工作。

从「像游戏」到「真能玩」

最近的变化并不只是模型更会写代码，Simon Willison 认为，Claude Opus 5.5 开始表现出一点过去模型缺少的游戏设计能力。

他用普通 Claude 聊天界面，只输入一次提示词，做出了《Tree Appreciator》。画面会并排生成两棵略有差异的三维树，玩家可以旋转和放大场景，找出鸟、松鼠或叶片等细小差别；完成之后，这棵树还会被收入一册虚拟标本集。

从代码角度看，它仍然是一款很小的「找不同」游戏。真正让 Willison 意外的，是模型自行补齐了一套温和但完整的体验：如何告诉玩家目标，怎样逐渐增加难度，又如何用标本收集提供继续游玩的理由，组织出了开始、反馈与完成感。

另一个项目《Battle Drones》更能看出差异。早期版本由 Claude Fable 5 制作，已经拥有类似《命令与征服》的采集和战斗，但 Willison 觉得并不好玩。他只要求 Opus 5.5「让它变得有趣得多」，后来又让模型将游戏迁移到 Three.js。现在，它拥有两至四人对战、七张地图、勋章、录像、随机地图，以及能够改变规则的 mutator。

模型对于「乐趣」的理解，未必像人一样。模型主要是识别出一款即时战略游戏，通常需要怎样的反馈密度、推进节奏和局势变化，再把这些惯例组合起来。但从展示角度看，评价标准已经发生变化：之前模型能不能把游戏做出来，做得出来已经属于是颇有能力。现在，得能实际玩下去。

不过，「一条提示词做出游戏」很容易制造一种错觉，仿佛模型在几分钟内完成了游戏公司多年来的开发心血。

Claude Opus 5.5 制作的三维城市游戏《Neon Palms》，最初也来自一项游戏 benchmark。视频里，玩家可以在霓虹城市中驾驶和探索，所有画面都来自实际运行的程序，并非生成视频。

但它不是「一键直出」的结果，整个项目从 9 月 26 日持续到 28 日，Agent 分十一轮工作，共运行 69 次，最多六个 Agent 并行；按公开记录计算，模型处理了约 40.7 亿 Token，其中绝大部分是缓存上下文，输出约 320 万 Token。按 API 牌价估算，开发成本约为 1512 美元。展示视频还使用了之后加入小幅视觉修复和专门展示模式的版本，benchmark 本身仍记录着不少错误。

更系统的 GameCraft-Bench 也给出了相似结论，它要求代码 Agent 根据自然语言，在 Godot 中完成 140 个可游玩的游戏任务；评估不只检查代码，还会真正启动程序、回放操作并观看游戏表现。论文发布时，最强 Agent 的整体完成度仍只有 41.46%。模型很擅长迅速搭出让人惊艳的原型，却还不能稳定完成每一种规则、反馈和视觉要求。

模型「秀肌肉」的最佳方式

模型力内卷的下半场，任何新版本推出时都需要考虑，怎么给出一种大众能够看懂的证明方式。跑分、做题，都已经不足够直观，编程任务重，几十万行代码则很难浓缩易懂易传播的素材。

游戏却天然拥有画面、动作、声音与结果，它既是程序，也是成果；既能检查代码有没有运行，也允许观众亲自调试它。模型生成的每一个组件，都要在玩家按下按钮后与其他组件继续合作。

新模型纷纷开始「做游戏」，并不代表它们已经掌握了完整的游戏工业，模型厂商也未必有这种想法。它更像一种新的发布仪式，当模型的能力越来越难表现和说明，不如让它交出一个可以被观看、操作和传播的成品。