实测三大AI编程模型：从零开发Three.js 3D游戏谁更强？

最近AI编程圈的新模型一个接一个，光看各家发的评测已经分不清谁在裸泳了。我索性把最近热度最高的三个——Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3 拉到同一个考场里，让它们从零做一个 3D 游戏，看看谁真能顶上一个初级程序员的活儿。

选 3D 游戏当考题，我是刻意为之的。写 CRUD 接口这种任务早就不具备区分度了，模型只要训练语料里见过足够多相似代码，都能写得有模有样。但一个 3D 游戏不一样，它牵扯到场景管理、渲染循环、碰撞检测、资源加载、输入控制这些跨模块的协同问题，需要模型在动手前先想清楚整体架构。这篇实测记录会把我的测试设计、三家模型的生成过程、最后跑出来的成品质量、以及我在调试过程中踩到的各种坑完整写下来，给想用 AI 做小游戏、或者正在纠结选哪个模型当编程搭子的人一个可复现的参考答案。

1. 为什么拿 3D 游戏当考题：测试设计背后的心思

1.1 一个"非教科书"的测试任务

我定下的任务是这样的：使用 Three.js 和 Vite，在浏览器里实现一个第一人称的 3D 迷宫寻宝游戏，具体要求：

• 迷宫用算法动态生成，不能手写地图数据，每次刷新布局不同
• 第一人称视角，鼠标控制转向，键盘 WASD 控制移动
• 迷宫里随机分布金币，吃到后加分并刷新位置
• HUD 界面显示分数和计时，游戏循环走 requestAnimationFrame，目标 60fps
• 不引入额外游戏引擎，只用 Three.js 核心库

这个题目看起来不复杂，但里面埋了好几个"陷阱"。首先是迷宫生成，如果模型只是背过某个经典项目，大概率会甩出一个硬编码的二维数组，而不是写真正的随机迷宫算法；其次是碰撞检测，Three.js 官方示例里最简单的方式是 Raycaster，但 Raycaster 逐帧调用在复杂场景里性能会很差，这就要看模型有没有性能意识；再就是第一人称控制器，鼠标指针锁定、摄像机跟随、碰撞回退，这些细节任何一个处理不到位，游戏手感都会稀烂。

我在三个模型里使用的是同一个提示词模板，只额外补充了一句"完成后请给出运行方式说明"，其余一律不给，目的就是看它们在零引导情况下的自然发挥。

1.2 为什么不用现成的游戏模板

有人会说，你扔一个"写一个 Three.js 游戏"的提示词，模型脑子里跳出来的大概率是 GitHub 上见过几百遍的仓库结构，写出来的东西当然好看。这话没错，所以我在任务里专门加了两个约束把模板堵死。

第一，明确禁止使用现成的游戏脚手架和示例项目代码，要求模型自行设计迷宫生成器。第二，要求模块按职责拆分成多个文件，不能全部塞进一个文件里。这两个约束一加，模型要么老老实实自己设计架构，要么暴露"背模板"的本质。

我实测下来发现，真正理解了渲染和逻辑关系的模型，会主动在文件之间做好接口约定；只会复读示例代码的模型，则会在迷宫生成器这个环节露出马脚——不是写了个死循环，就是生成出来的迷宫根本走不通。所以这个考题的区分度比跑一堆基准测试直观得多。

2. 三家模型的首次会审：解题思路从第一句就分岔

2.1 Step 5 Preview：先交架构图，再动手写代码

先说 Step 5 Preview。我输入提示词后，它没有立刻开始写代码，而是先列了一个文件规划：

src/ main.js # 入口，初始化渲染器，启动游戏循环 maze.js # 迷宫生成算法与碰撞数据导出 player.js # 第一人称控制器，鼠标指针锁定与移动 scene.js # 场景构建、光照、金币生成 ui.js # HUD 界面和状态更新 styles.css

这个特点给我的印象是最深的。大部分模型一上来就喜欢把所有逻辑塞进一个 main.js，跑通了再说；Step 5 Preview 则会先交代每个模块的职责，甚至写清楚 maze.js 和 player.js 之间的接口约定——maze.js 导出一个二维数组，player.js 根据这个数组做碰撞判定。这是在模拟一个老工程师的做事方式：先画好模块边界，再往里面填代码。

我追加了一句"请按照这个文件结构逐文件生成完整代码"，它按顺序输出，最后主动补了 package.json 依赖清单和启动说明。整个交互过程非常接近一个真人队友。

2.2 DeepSeek V4 Pro：单文件跑通，再谈优化

DeepSeek V4 Pro 的第一版答案完全反过来。它直接甩给我一个几百行的单文件，HTML、CSS、JavaScript 全部内联，复制到浏览器双击就能跑。这种做法的好处毋庸置疑——零依赖、零配置，拉起来就能玩。

但工程化角度看，这个方案后续扩展会很痛苦。我在提示词里明确要求"拆分文件结构并解耦模块"，它才重构成了多文件项目，而且重构质量相当不错。这说明 DeepSeek V4 Pro 不是写不出好结构，而是默认选择最低摩擦路径——你要一个能跑的东西，它就给你一个能跑的东西，潜台词是"等你提了要重构再说"。

这背后其实是一种产品思维的差异。对快速验证想法的场景来说，这个特性是优点；对想认真维护一个项目的人来说，就显得不够主动了。

2.3 GLM5.3：代码最周到，但会过度设计

GLM5.3 是我最后测的。它的第一个特点是"非常周到"——在迷宫生成器旁边额外写了一个可视化调试图工具函数，可以把迷宫地图直接渲染成 canvas 图片，方便检查生成结果。这个功能我完全没要求，是它顺手加的。还包括碰撞检测里的地面摩擦系数、跳跃落地缓冲等参数预留，对一个 demo 型 3D 游戏来说，设计深度已经接近正经游戏项目。

但"周到"的另一面是"过度设计"。它输出的文件结构比 Step 5 Preview 还要多出三个文件，其中两个抽象类在实际调用里根本没有被实例化。这种"为了架构而架构"的倾向，遇到不懂代码的玩家可能要折腾一阵子才能跑起来。不过单独看每一个类，代码质量确实没得挑。

3. 逐轮实测：从空文件夹到三个可玩原型

3.1 统一的环境和验收标准

为了公平起见，我建了一个统一环境：Node.js 18.16 + Vite 5.0 + three@0.160.0，分别在 Chrome 126 和 Safari 17 上跑，安卓手机 Chrome 也额外测了一轮。验收硬指标只有三条：打开页面能进入游戏、鼠标加键盘能完成移动和转向、吃到金币后分数正确变化。

打分维度我定了五个，每项十分：可运行性、操控体验、代码可读性、模块解耦度、扩展友好度。最后的结果我放到第六节统一呈现，这里先讲过程。

3.2 Step 5 Preview：第一次运行就没改代码

Step 5 Preview 生成的代码，一次通过编译，运行时也没有报错。入口、迷宫生成器、玩家控制器、UI 模块之间的引用关系全都能对上，没有出现"引用了函数但没导出"这类低级错误。我本来做好了要调半天的心理准备，结果意外顺利。

有个小细节值得单独拿出来说：它在玩家控制器里处理了 Pointer Lock 的异步锁定边界情况。了解浏览器 API 的人应该知道，鼠标指针锁定不是立刻生效的，Chrome 里需要等一个用户交互事件再挂监听，如果急着一帧内去读鼠标位移，很容易读到零值。这种细节一般模型根本注意不到，它写了。

缺点也有。它初始化光照参数偏保守，环境光强度太低，整个迷宫场景偏暗，金币在阴影里不容易看见。我手动把 ambient light 的强度从 0.3 调到了 0.8 才算顺眼。这类主观视觉偏好的问题，模型很难一下子猜中，需要人类参与微调。

3.3 DeepSeek V4 Pro：修了一个 bug，但逻辑非常利落

DeepSeek V4 Pro 的单文件版本，我塞进 Vite 项目里第一次运行，金币拾取不生效——监听器挂在一个不可见的替代物体上，而实际加载的是另一个对象。这类"改名为重构但忘记同步事件"的 bug，是模型写长代码时的典型失误。

我让它自己定位，它 20 秒内指出问题所在，只改了两行代码就修好了。这个修复过程干净利落，没有绕圈子。

修完后整体游戏体验非常利落。它的碰撞检测用的是简化球体包围盒，没有用 Three.js 内置的 Raycaster，性能非常干净，在手机浏览器上也能稳定保持 30fps 以上。操作手感干脆，没有花哨的高级 feature，但作为游戏 demo，它是三个里最让人愿意继续玩下去的。

3.4 GLM5.3：代码很好看，卡在两个继承关系的坑上

GLM5.3 的代码单独看非常漂亮——类设计清晰，注释完整，甚至写了一个简易的资源加载器。但第一次运行的时候直接报错：一个继承THREE.Mesh的子类构造函数里没有调用super()，导致纹理参数初始化顺序错乱，整个迷宫渲染出来全是默认黑色。

这个 bug 很有意思，模型自己写的时候没注意到，更关键的是，我让 GLM5.3 自己修复时报了一个更隐蔽的坑：它前两次给的补丁都没修干净，第三次才彻底解决。这个现象说明 GLM5.3 生成独立模块的能力很强，但一旦需要跨模块追踪状态——bug 出在 A 类，锅却要 B 类的初始化时机来背——它的定位能力就不如 Step 5 Preview 和 DeepSeek V4 Pro。

不过这跟它的过度设计是一体两面。正是因为它喜欢把职责拆得特别细，类与类之间的调用链变得很长，一旦出问题，排查路径也变长。

4. 深挖代码细节：三个模型的工程习惯差在哪

4.1 从注释风格看"队友"属性

三个模型的代码我都逐行读过，工程习惯差异非常明显。Step 5 Preview 的注释量最少，但命名非常精准，函数体基本控制在 20 行以内，读它的代码像在读一本结构清晰的工具书。DeepSeek V4 Pro 喜欢在关键逻辑处加解释性注释，风格接近一个在团队里带过新人的老员工——注释的点位都很准，不多一句废话。GLM5.3 的注释最"满"，几乎每个函数都有 docstring，但注释内容偶尔和实际行为对不上。这种"注释幻觉"是 LLM 在代码注释里的典型表现，它写出了一段听起来完全合理的解释，但代码实际跑的不是那个逻辑。

我个人的偏好是 DeepSeek V4 Pro 那种风格，注释是给下一个维护者看的，不是写给代码审查机器看的。如果你拿到 GLM5.3 生成的代码，记得抽查几个函数，把注释和实际逻辑对齐一遍。

4.2 顺手验证了"开源安卓 3D 游戏"的场景

第五个维度我在三个 demo 里额外测了移动端兼容性，因为最近社区里很多人讨论"开源安卓 3D 游戏"，用 AI 生成游戏已经成了新趋势，但移动端适配往往被忽略。

结果很意外：三个版本的迷宫游戏在安卓手机浏览器上帧率都能跑到 30fps 以上，但 Step 5 Preview 和 DeepSeek V4 Pro 的 HUD 布局在窄屏上出现明显溢出，按钮叠在一起。GLM5.3 因为用了 flex 布局，表现得最好。一个可行的方法：如果你打算用 AI 生成游戏再打包成安卓应用，提示词里直接加一句"UI 必须适配 375px 宽度的手机屏幕"，就能省掉后续改布局的麻烦。

5. 避坑清单：AI 生成 3D 游戏的高频坑与解法

5.1 高频坑第一名：资源路径谜之失效

实测三个模型过程中，遇到最多的问题是纹理贴图和模型资源加载不到。原因千奇百怪：有的路径写死为/assets/texture.jpg，有的用相对路径但大小写不一致，在 Windows 上正常，到 Linux 服务器就 404。一个通用的解法：提示词里明确要求"加载资源使用基于import.meta.url计算的相对路径，不使用硬编码绝对路径"，这类问题基本可以杜绝。

5.2 高频坑第二名：渲染性能"日抛"

AI 生成的游戏 demo 最常见的问题就是一帧里重复创建对象。迷宫生成器如果写得不够干净，几何体在渲染循环里反复重建，帧率直接崩到个位数。建议实测时开着性能面板盯一下 draw call 数量和对象创建频率。如果发现这种问题，让模型把几何体初始化挪到构造函数或初始化函数里，一次性创建，通常能解决。

5.3 高频坑第三名：全局变量满天飞

三个模型里有两个在代码里大量使用全局变量管理游戏状态，比如把score、isLocked、timeLeft直接挂在window上。这在 demo 阶段无害，但想继续开发下去，迟早会被某个全局变量被意外覆盖而折磨疯。我的习惯是拿到 AI 代码后第一件事就是重构状态管理，把全局状态收拢到一个GameState类里，后面加功能才敢动手。

5.4 让 AI 自己修 bug 的正确姿势

最后分享实测中最有价值的经验：让 AI 修 bug 时，不要只扔一句"帮我修一下"，必须给它足够的上下文。我实测时的标准提示词是：

请定位这个问题：[贴上报错信息或现象描述]。以下是相关代码：[贴出核心类或函数]。请先说明你判断的根本原因，再给出修改方案。

这个提示词的作用是逼着模型先输出推理过程。它倾向于在上下文不完整时猜测一个最常见的修复方式，而猜错概率在游戏这种多模块耦合的场景里非常高。先让它说清楚原因，你既能确认它的推理方向对不对，也能快速决定要不要换一种问法。

6. 最终评分和选型建议

6.1 横向评分表

根据这一整轮实测，我把三个模型的得分汇总如下（纯主观评分，供参考）：

可运行性这一项最能说明问题：Step 5 Preview 一次跑通，DeepSeek V4 Pro 修了两行代码，GLM5.3 让我来回折腾了三次。但需要注意的是，可运行性反映的是"第一次交手"的体验，不代表 GLM5.3 的代码上限低——它只是把复杂度前置了。

6.2 什么场景选哪个模型

如果你想用一个小时把脑子里的想法变成可玩 prototype，DeepSeek V4 Pro 的开局最快，单文件方案真的省事，少走了很多配置弯路。如果你想把这个 demo 继续做成一个像样的产品，Step 5 Preview 的结构化设计优势明显，模块边界干净，后续加新功能几乎不需要大改。如果你在意代码的讲解性——比如你想借 AI 生成的代码学 Three.js，GLM5.3 的注释和文档风格最适合当学习材料，只要注意别被它的过度设计带着跑。

GLM5.3 还有个社区里常被问到的部署细节：如果你想在本地用 vLLM 跑 GLM5.3，记得先确认当前权重文件对应的 vLLM 镜像版本，这个月已经看到好几个朋友因为镜像版本和权重不匹配，导致服务起不来。这类兼容性问题在跑 Web 推理服务时尤其明显，值得留意。

7. 额外彩蛋：给提示词加"角色约束"会改变结果

实测到这我忍不住多测了一轮，因为前面三个模型的风格差异实在太大了，我想知道这是模型能力决定的，还是提示词措辞造成的。于是我用同一道题，分别给 Step 5 Preview 加了两句不同的开头提示词。

第一种："你是一个资深游戏主程，正在带一个初级开发做项目。"——这个版本显著增加了代码里的防御性判断，比如碰撞检测多了"物体越界回退"逻辑，摄像机多了视角遮挡检测，都是老程序员才有的肌肉记忆。

第二种："你是一个快速原型开发，目标是 10 分钟内跑通。"——这个版本直接把迷宫算法从 DFS 换成了更简单的随机剔除法，代码量少了三分之一，但可玩性明显下降。

结论是：模型的能力上限是一个固定值，但提示词的角色约束会把它在某个维度上的能力拉到不同水平。如果你想让 AI 输出的代码更稳健，就给它"资深主程"的人设；如果想快速验证玩法，就明确告诉它"不要过度设计"。这个技巧跟用哪个模型无关，适用于所有三个。

我也顺手把第二步的方法用在了一个跟豆包 Seed 2.0 代码模型对比的讨论里——社区里有人拿 doubao-seed-2.0-code 和 GLM5.3 比代码能力，其实这种对比很容易被提示词措辞干扰。同一个模型，换一套角色设定，分数可能从 7 分涨到 9 分。所以下次再看到各种模型对比榜单，先看清楚它的提示词模板是怎么写的，再决定要不要信。

最后说一个实测中让我有点感慨的细节。测试前我特意没有给任何参考代码，就是想知道它们各自的"自然发挥"水平。结果三个模型生成的迷宫，居然都保证了一条从起点到终点的可行路径，没有一个生成走不通的死局。这说明当前这批模型对"迷宫"这个概念的理解，已经不只是从语料里背代码片段，而是真正掌握了图论里最基本的连通性约束。作为常年和代码打交道的人，看到这个层面的进步还是值得高兴的。如果你也在用 AI 做小游戏，我的建议很朴素——别急着指望一次生成一个 3A 大作，先从小而完整的任务开始，把模型当做一个思路很快、但需要你当技术总监的成员，这样你才能真正用好它。