AI写3D游戏实测：三大代码模型生成Three.js寻宝迷宫对比

最近我把 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3 拉到同一条起跑线上，让它们分别写同一个 3D 游戏。任务很简单粗暴：一个基于 Three.js 的浏览器 3D 寻宝迷宫，第一人称视角，有碰撞、有胜利判定、还要求能塞进手机浏览器里跑得动。跑完这一轮，我对“AI 写游戏到底能不能落地”这件事有了非常具体的判断。这篇文章会把我的实测过程、三个模型的表现差异、调试时踩过的坑，以及最后跑通的方案完整记录下来，给同样想用 AI 辅助做 3D 小游戏的朋友一个参考。

先说清楚，这里的 Step 5 Preview 不是某个操作步骤，而是最近一个主打“分步推理 + 代码预览”的代码模型预览版。它和 DeepSeek V4 Pro、GLM5.3 一样，都能直接生成完整项目代码。这次实测不玩花活，不测 LeetCode，只测一件事：给同一个 3D 游戏需求，谁的产出最接近“打开就能玩”。

1. 为什么拿同一个 3D 游戏当试金石

1.1 三个模型的定位差异

做这个对比之前，我先理了一下三个模型的调性。Step 5 Preview 的卖点是“把复杂任务拆成步骤，再一步步预览生成”，听起来很适合做迷宫寻宝这种逻辑明确、状态多的项目。DeepSeek V4 Pro 走的是全能路线，代码能力和推理能力都强，而且上下文窗口大，适合一次喂大量需求。GLM5.3 则更偏实用主义，本地部署生态比较活跃，很多人拿它做私有化代码助手。

三个模型给我的感觉是：一个注重推演过程，一个注重综合能力，一个注重部署落地。要给它们找一个公平的考题，3D 游戏恰好合适。因为 3D 游戏项目既有数学算法（碰撞检测、坐标变换），又有工程结构（场景管理、资源加载、UI 状态），还有体验细节（视角控制、节奏反馈），三个模型的侧重点会分别体现在不同环节上。

1.2 游戏需求规格和测评维度

需求定义得越清楚，对比才越公平。我这次给出的需求一共八条：

• 使用 Three.js 实现，单个 HTML 文件可运行
• 第一人称视角，WASD 控制移动
• 迷宫墙体带碰撞，人物不能穿墙
• 场景内随机放置 5 个宝藏，全部收集后触发胜利界面
• 右上角显示计时器，记录通关耗时
• 支持触屏设备，显示虚拟摇杆
• 使用低多边形风格，配简单光照和阴影
• 整体代码需带注释，方便阅读

评分维度我定了五个：首次运行可用性、明显缺陷数量、代码可读性、性能基线、移动端适配程度。每个维度打分尽量客观，能跑就绝不吹，跑不了就记失败原因。这样一轮下来，模型之间的差距就不是体感了，而是能直接对比的数据。

2. 首轮生成：三份代码的“第一印象”

2.1 首轮结果对比表

三份代码都要求一次性生成，不允许中途交流，完全模拟“甩一个需求给模型”的场景。首轮结果如下：

首轮跑下来，没有一个是直接满分交付的。这个结果本身就很说明问题：AI 生成 3D 游戏，距离“零调试直接上线”还有不小的距离。但三个模型的失败模式各有不同，这才是最值得分析的部分。

2.2 Step 5 Preview：思路完整但“想得太多”

Step 5 Preview 生成的第一版代码，打开后直接白屏，控制台报了一个找不到 THREE.FPControls 的错误。原因很典型：它在生成代码时“创造”了一个不存在的 Three.js 控制器类。这说明它的推理过程确实做了规划，试图把第一人称控制封装成一个独立模块，但知识库里没有对应的真实 API，幻觉就这样产生了。

不过有意思的是，解决这个报错之后，它的代码质量是三个模型里最高的。整个文件分了 init、createMaze、setupControls、updateHUD、onWin 五个函数，每一个都有详细注释，甚至标注了“这里使用 AABB 碰撞而不是射线检测，因为更适合迷宫场景”。这种“先解释再写代码”的风格，在后期维护时确实舒服。缺点是代码量偏大，一个迷宫游戏足足写了 700 多行，部分逻辑存在重复封装，比如 move 函数里做了两次 if 分支去处理同一个速度标志。

2.3 DeepSeek V4 Pro：效率优先，细节偷懒

DeepSeek V4 Pro 的首版代码是三个模型里唯一能直接跑的。打开页面就能看到迷宫和人物，WASD 也能动，宝藏收集和计时器一次到位。但它的实现方式是“能用就行”：碰撞检测用的是简化版射线法，只做了水平方向的碰撞，人物走到墙体边缘时会出现半个身子嵌进墙壁的效果；宝藏的摆放逻辑则是纯随机，有两个宝藏直接刷在了迷宫外部的空地上，玩家绕一圈就能捡到，完全不需要走迷宫。

代码结构走的是“单文件全塞”风格，把场景初始化、事件监听、动画循环全写在了一个大 function 里。虽然可读性比 Step 5 差一些，但改起来反而方便，因为所有变量都是全局的，调试时直接在控制台就能操作。用大白话说，DeepSeek 这版代码是“先跑起来再优化”的典型代表。

2.4 GLM5.3：中规中矩的“稳定型选手”

GLM5.3 的首版表现和它的定位一致：不高不低。代码能跑，迷宫能显示，移动也正常，但视觉效果偏粗糙。它选择了最简单的颜色材质，场景没有光照，墙体是纯灰色，地面是深灰色，整体看起来像上世纪的教学 Demo。触屏支持倒是有，但只做了基础的点击移动，没有虚拟摇杆。

有个细节让我印象很深：GLM5.3 生成的代码里有不少函数风格非常传统，例如用 var 声明变量、用 for 循环代替 ES6 的扩展运算符。这倒不影响运行，但说明它的训练数据里可能包含了较早期的 Web 开发内容。对于追求兼容性的老项目来说这是优点，但做新游戏时就会显得不够现代。

3. 从一次性代码到能玩的游戏：完整调试链路

3.1 环境搭建：一个 HTML 文件起步

我把三个模型生成的代码统一收敛到同一个工程里，基础方案是单 HTML 文件 + Three.js CDN 引入。这里有一个特别重要的点：引入时要锁定版本号，不要在 CDN 链接里写默认可变路径。三个模型生成的代码里，有两个用了不带版本号的链接，结果浏览器解析到了不同构建版本，很多 API 差异导致的兼容问题就是这么来的。

我实测后固定使用 Three.js r158 版本。这个版本比较稳定，ESModule 和 UMD 双模式都能用，WebGLRenderer 的默认行为也符合 WebGL2 规范。如果你的目标设备是老手机，可以考虑降到 r150 以下，但那样阴影效果会差一些。需求是“能玩”，所以我优先保证兼容和帧率，而不是画质上限。

3.2 第一人称移动与碰撞检测的修复

三个模型在碰撞检测上都有问题，这是整个 3D 游戏里最容易翻车的环节。Three.js 原本没有内置针对胶囊体（人物模型）的碰撞系统，常规做法是用射线或包围盒做简化。DeepSeek 的射线法只检测了水平方向的墙，Step 5 倒是做了 AABB，但碰撞体的尺寸比墙体的实际尺寸小了一圈，还是会穿模。

我的修复方案是统一使用 AABB 碰撞，并给墙体生成一个碰撞半尺寸偏移量。核心逻辑如下：

function canMove(position, walls) { for (const wall of walls) { const box = wall.geometry.boundingBox.clone(); box.applyMatrix4(wall.matrixWorld); // 加一个收缩余量，避免视觉上"蹭墙"时被算作碰撞 box.min.x += 0.2; box.max.x -= 0.2; box.min.z += 0.2; box.max.z -= 0.2; if (position.x > box.min.x && position.x < box.max.x && position.z > box.min.z && position.z < box.max.z) { return false; } } return true; }

注意这里只检测了 x 和 z 轴，因为人物在 y 轴上不做垂直移动，省掉一条碰撞判断能减少一半以上的计算量。鼠标转向时相机跟着转，但人物的碰撞体始终保持固定朝向，这也是一个容易忽视的细节。用这种方法修复之后，实测人物在迷宫里走一圈不会再出现穿墙卡位。

3.3 玩法闭环：结算、重开、节奏

首版代码的最大通病是“能走但不好玩”。三个模型都实现了“收集 5 个宝藏后弹出胜利面板”的基本逻辑，但缺少两个关键体验：一是胜利面板出现后没有重新开始的按钮，二是计时器数字跳得太快，没有做到毫秒级稳步推进。

我的做法是把游戏状态机分为 PLAYING、WIN、RESET 三个阶段。计时器在 requestAnimationFrame 中累加，每秒刷新一次 UI，避免每帧都操作 DOM；胜利后冻结动画循环，并显示一个自定义按钮，点击后重置所有宝藏实例和玩家位置。这里还有一个细节：重置时要把相机朝向也恢复到初始方向，否则玩家重开后视角是歪的，非常容易晕。

function resetGame() { player.position.set(spawnPoint); camera.rotation.set(0, 0, 0); collectedCount.value = 0; elapsedTime = 0; gameState = 'PLAYING'; scoringPanel.classList.add('hidden'); spawnTreasures(); }

3.4 移动端兼容与性能优化

移动端适配是这次实测里被三个模型集体忽略的部分。DeepSeek 和 Step 5 完全没写触屏代码，GLM5.3 写了但只是“点击目的地自动寻路”，操作手感很差。最终的可行方案是在左下角和右下角各放一个虚拟摇杆，前一个控制位移，后一个控制视角旋转。触摸事件用 touchstart 和 touchmove 记录坐标增量，每帧把增量转换为相机的欧拉角变化。

性能优化上，最大的收益来自两点。第一是把 renderer 的 pixelRatio 控制在 1.0 而不是默认的屏幕 DPR，中端手机上帧率能翻一倍。第二是对墙体进行合并，迷宫里的几十面墙体如果能用 BufferGeometryUtils.mergeGeometries 合成一个几何体，Draw Call 会从几十次降到一次。移动端 WebGL 的 Draw Call 非常敏感，这个优化比阴影、后处理都管用。

4. 踩坑实录：三个模型都翻过的车

4.1 摄像机“穿墙”与碰撞体不一致

这个坑其实在 3.2 里提过，但值得单独讲。Three.js 的默认相机没有碰撞体，它就是一个“眼睛”的坐标。如果不做处理，相机运动范围只是被限制在了代码层面的“伪碰撞”里。三个模型里至少有两个忘了把相机挂在人物胶囊体上，而是直接控制相机自身，结果就是人物的模型没动，视角自己穿墙了。

修复思路是先建一个空的 player Object3D，把相机作为它的子节点。移动时只操作 player 的 position，相机的本地坐标固定在 (0, 1.6, 0)。这样碰撞检测只需要检测 player 一个对象就够了。用这个结构后，不管相机怎么旋转，玩家始终站在正确的位置。

4.2 资源加载路径和异步时序问题

有一个试了很多次才发现的 Bug：胜利面板有时不出现，有时出现后场景变黑。排查到最后，问题出在宝藏模型纹理的加载时序上。Three.js 加载纹理默认是异步的，如果你在纹理加载完之前就启动动画循环，场景会在某一帧开始显示错误的结果。

修复方法是使用 LoadingManager，在 onLoad 回调中才启动游戏，或者在启动逻辑前强制 await。类似的问题也出现在谷歌字体、外链音频上。AI 生成的代码普遍不处理这类时序，因为它们“认为”所有资源都是同步可用的。这里我自己加了一个“预加载屏障”，实测稳定复现后，这类问题彻底消失。

4.3 生成代码的“幻觉 API”和过时写法

3D 游戏是 Three.js 这种功能迭代较快的框架的重灾区。Step 5 Preview 幻想的 FPControls 是一个典型，但 DeepSeek 和 GLM 也有类似问题。DeepSeek 引用了一个 THREE.MeshFaceMaterial，这个 API 早就在旧版本里被移除了；GLM 用的是 THREE.Geometry，但 Three.js 在 r125 之后已经全面改用 BufferGeometry。这种错误不报红，运行也能跑，直到某一步操作触发了不兼容分支，游戏就莫名崩溃。

应对方法就是我在 3.1 里提到的版本锁定。只要把 Three.js 固定到某个确认过的版本，再让模型全部基于该版本的 API 编写，幻觉 API 的出现频率就会锐减。模型训练数据里的代码版本时差是它们共有的弱点，目前没有模型能完美避开，只能靠工程手段兜底。

4.4 修复过程本身也是对模型的第二种考验

三个模型首版代码都有问题，我原以为直接让它们自己修会更好，结果发现差异很大。把报错信息原文粘回去，Step 5 能给出比较合理的修复思路，但有时会为了修一个 bug 引入另一个 bug；DeepSeek 修复速度快，但给出的代码片段经常依赖它自己首版里的全局变量；GLM 的修复过程更接近“搜索引擎式”，不停翻文档，不过最终能修得比较稳。

整体来看，这几个模型都更适合“我提供修复方向，它提供具体补丁”的协作模式，而不是完全撒手让它们自我纠错。做一个 3D 游戏，AI 是把效率放大器，但需求拆解和最终校验，还是得靠人来把关。

5. 部署环节：本地跑和安卓端跑有哪些差异

5.1 本地部署 GLM5.3 的镜像踩坑

实测过程中，我把 GLM5.3 接到本地跑了几轮生成任务。这里牵扯到一个很实际的问题：GLM5.3 在 vllm 推理框架下，到底该用哪个版本镜像才能稳定跑起来。不同显卡架构、不同 CUDA 版本、不同 vllm 版本之间的组合差异很大。我的经验是优先选用官方针对 GLM 系列发布的 release 镜像，并匹配当前 GPU 的 CUDA 版本；如果自建镜像，vllm 的动态形状推理、量化插件和 torch 版本经常会因为不一致而反复报 OOM 或算子不兼容错误。

一个比较稳妥的组合是：CUDA 12.2 镜像 + vllm 对应 GLM 系列优化分支 + 模型采用半精度加载。这个组合在 A 系列显卡上能稳定跑到 40 到 60 token/s 的生成速度，对代码生成这种中长文本任务足够了。如果切到旧版本镜像，生成速度会掉到 15 token/s 以下，而且长上下文的衰减明显，生成代码时经常后半段逻辑走形。部署这种事，版本对齐永远是最优先的。

5.2 安卓端加载 3D 游戏的两种路径

游戏最终要往手机上跑，这就涉及“开源安卓 3D 游戏”常见的技术路线选择。第一种是 WebView 包壳：把 Three.js 的 HTML 文件打包进 Assets，在原生 WebView 里加载。这种方案交付体积小，开发速度快，但要求打开硬件加速开关，并且 Android 系统 WebView 的 WebGL 版本要够新，安卓 10 以下的老设备支持度参差不齐。

第二种是把游戏逻辑迁移到 Godot 或 Unity，原生渲染后导出 APK。这种方式渲染性能更强，也能拿到底层 API 控制权，但 AI 生成的代码没法直接用，重写成本高。我的实测结论是：如果项目定位是“小游戏开源作品”，WebView 包壳是性价比最高的。浏览器里的 Three.js 游戏，稍微优化后在中端安卓机上能稳定 30 fps，已经能满足大部分玩法了。

6. 选型建议：这三个模型分别适合什么需求

6.1 什么时候选 Step 5 Preview

如果你的项目逻辑复杂、状态多，而且你愿意花时间做后期整合，Step 5 Preview 的输出结构是最舒服的。它写出来的代码有清晰分层，注释也细致，适合“我给它一个明确需求，它给我一个可理解架构”的协作方式。代价是它的输出量偏大，代码里有不少过度设计的痕迹，需要你花时间裁剪。

我个人的感受是，Step 5 不太适合“快速试错”场景。如果你今天就想搭一个能跑的 demo，它会给你一整套架构，但很多地方你根本用不到，反而容易绕晕。它更适合中大型游戏模块的骨架生成，比如状态机、任务系统、物品栏这类有内在逻辑的子系统。

6.2 什么时候选 DeepSeek V4 Pro

DeepSeek V4 Pro 是典型的“少废话直接干”。如果你要做原型、验证玩法、临时凑一个可交互页面，它的效率非常高。首轮能跑这一点，就省掉了大量排查环境问题的时间。加上全局变量风格的代码，非常适合调试时在控制台里直接改参数。

代价是代码结构和命名都偏随意，后期如果要做工程化维护，大概率需要重写一部分。我的建议是：用 DeepSeek 做“第一版”，用 Step 5 或自己重构做“第二版”，这是个很实用的组合策略。先让 DeepSeek 提供一个能跑的基线，再用其他工具或人手去打磨架构。

6.3 什么时候选 GLM5.3

GLM5.3 是在私有化部署场景里最舒服的选择。它可以下载权重本地跑，配合 vllm 在可控环境里提供稳定的代码生成服务。对于企业内部开发，不想把源码上传到云端，GLM5.3 是三个模型里最适合搭私有代码助手的。代码风格偏传统，兼容性较好，但生成效果的上限不如前两者出彩。

如果你要跑一个开源安卓 3D 游戏项目，同时又有自部署需求，GLM5.3 作为后端生成服务配合前端 Three.js 手动优化，是一个比较稳的组合。你不会拿到惊艳的代码，但它很少给你惊喜——项目交付里，“稳定”有时候比“惊艳”重要得多。

6.4 一点个人体会

这次实测做下来，我最大的感受是：AI 模型之间的差距，其实没有版本号差距那么明显。真正决定项目能不能交付的，还是你有没有能力看懂它生成的代码、找出坏味道、补上边界条件。三个模型各自的优点，在我拆解需求之后才能被真正发挥出来；我喂的需求越清晰，它们的表现差距就越小。

所以我现在的做法是，把需求拆成明确的小任务，分给不同的模型去执行：Step 5 做架构、DeepSeek 做原型、GLM5.3 做私有部署的生成服务。这个分工持续实测下来很稳。以后你要是也想让 AI 帮你做 3D 游戏，别指望单一模型一步到位，多花点时间在模型组合和需求拆解上，投入产出比会高很多。