三大AI模型实测：用Three.js开发3D迷宫游戏哪家强？

上个周末我干了一件在别人看来挺无聊的事把 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个模型拉进同一间考场用同一个 Prompt各自从零写一个基于 Three.js 的 3D 迷宫逃脱小游戏。之所以选这种项目是因为 3D 游戏几乎是 AI 代码生成能力最好的照妖镜——它同时考验模型的空间计算、坐标系理解、事件交互、碰撞检测和 UI 装配任何一个环节掉链子成果都立不住。这篇文章就是这次实测的完整记录从题目设计、生成过程到产物逐个拆解最后给你一份真正能参考的选型结论。1. 为什么我拿3D 迷宫逃脱当三个模型的统考题1.1 3D 游戏比 2D 更能压出模型的底牌很多人测 AI 写代码还停留在生成一个贪吃蛇或者写一个 TodoList的阶段。说实话这种需求在 2024 年以后基本没有区分度了是个模型都能过。但 3D 游戏不一样它有一个 2D 项目完全没有的难度阶梯空间想象力。写 2D 游戏时模型只需要处理平面上的坐标x 和 y 两个轴逻辑再复杂也就是数组遍历和碰撞判断。但到了 3D事情一下子变成在三维空间里描述一个迷宫墙体的高度、摄像机的位置、视角旋转的欧拉角、射线检测的方向向量……这些概念全部需要模型在生成代码前先在内部建立一个虚拟的空间模型。如果模型没有真正理解三维坐标生成的代码跑起来就会出现特别奇怪的现象墙是透明的、视角穿模、碰撞检测只在一个轴向上生效。我选迷宫逃脱而不是跑酷或者射击也是有心机的。跑酷游戏本质上是一条直线上的操作3D 只是伪需求射击游戏则把大量代码量耗在模型资源和武器系统上容易让模型用堆资源蒙混过关。迷宫逃脱必须用算法生成墙体必须做第一人称碰撞必须判断出口位置——这三件事环环相扣模型没有一处可以偷懒。1.2 评分维度在发题前先定好裁判标准我见过太多测评文章跑完三个模型最后来一句各有千秋难分高下。这种结论对读者毫无价值。我的做法相反发题之前就把裁判标准写成一张表后面所有环节都按表打分首次运行成功率拷贝代码直接打开浏览器能不能跑起来需要不需要二次修改。核心机制完成度迷宫生成、碰撞检测、出口判断、重新开始这四件事缺一不可。可玩性与手感移动速度是否舒服、视角转动是否跟手、地图规模是否合理。代码工程质量注释、模块划分、是否有死代码、依赖管理是否清晰。运行性能在固定场景下用同一台机器测试帧率观察有没有掉帧或者卡顿。这五条不是随口定的。它们分别对应一个实际开发者的日常痛点拿到手能不能用、功能全不全、体验好不好、后续好不好维护、上线跑不跑得动。你如果只是想看谁生成的画面好看那这篇文章可能不适合你如果你想找一个能帮你干活、而不是制造新工作的模型这套标准就是为你准备的。2. 测试配置与 Prompt 的一次性锁死2.1 硬件、浏览器与生成入口先交代测试环境避免有人说我偏袒某个模型。机器Mac miniM2 芯片、16GB 内存浏览器Chrome 131开启硬件加速运行方式所有代码都以单 HTML 文件形式保存双击后用 file:// 协议直接打开生成入口三个模型各自的官方对话页面统一使用 Web 端温度/采样参数对话框不支持自定义统一默认生成时间记录从点击发送 Prompt 到页面完整输出代码为止中途不打断、不追加补充这里要说一个很多人忽略的细节我在测试前把一切环境变量都固定了但唯独是否需要联网加载依赖这一点没有提前统一。当时我的想法是允许模型使用 CDN 引入 Three.js因为绝大多数网页游戏项目都是这么做的强行要求离线反而偏离真实开发场景。事实证明这个决定是对的后面果然有模型在依赖版本上出了问题这成了很有价值的踩坑素材。2.2 统一 Prompt 原文与题干设计思路下面是我给三个模型发的完全相同的 Prompt一字未改原文贴上你是一名资深 WebGL 游戏开发工程师。请用单个 HTML 文件实现一个 3D 迷宫逃脱游戏要求如下 1. 使用 Three.js通过 CDN 引入最新稳定版并确保依赖库可用实现完整的第一人称 3D 视角。 2. 迷宫由随机生成的墙体组成网格规模至少 10x10每次刷新地图时布局随机变化。 3. 玩家使用 WASD 控制前后左右移动使用鼠标拖拽控制视角旋转。 4. 必须实现精确的碰撞检测玩家不能穿墙、不能走出迷宫边界。 5. 在迷宫中布置至少 3 个可收集的金币金币带有旋转动画。 6. 游戏界面显示计时器和金币收集数量收集全部金币后找到出口触发胜利弹窗。 7. 代码需要包含必要的注释并在文件末尾附加运行方式说明。 8. 所有代码放在一个 HTML 文件里不要拆分文件不要使用 React/Vue 等框架。设计这个 Prompt 时我做了几个关键取舍。第一条我明确指定 Three.js 作为技术栈。为什么不给模型自由选择因为 AI 模型对不同框架的熟练程度差异很大如果允许自由选择A 模型用 Three.js、B 模型用 Babylon.js、C 模型直接用 Canvas 手写光栅化那最后根本没法横向对比。锁定统一技术栈才能把变量控制在模型本身的能力差距上。第二条我故意加了使用 React 等框架则不合格的限制。因为我推测会有模型出于代码组织习惯下意识选择 React 组件化方案。在真实开发中这当然没问题但对这个单 HTML 文件的项目来说引入 React 等于引入额外的编译层和依赖链会让双击打开就能跑这个基本要求变得复杂。第三条我要求至少 3 个可收集金币 旋转动画。这是一个典型的细节陷阱专门考验模型会不会在完成核心逻辑后就疏忽视觉细节。后面果然有模型在这个地方表现出了明显的差别。2.3 为什么锁死 Prompt比让模型自由发挥更公平有一个测试观点我很反对让 AI 自由发挥才能看出真实水平。这话听起来有道理实际会让测试结果变成一团乱麻。真实水平只有在同一道考题下才能比较。就好比高考作文题目一样考生才能分出高下如果一个写记叙文、一个写议论文、一个写诗歌最后你说各有特色那分数的意义就没了。锁死 Prompt 还能保证复现性。我在测试结束后拿同一个 Prompt 又各跑了一次发现三个模型两次生成的结果在结构上高度一致说明这确实是模型的稳定能力而不是赌博式的运气。这对读者来说才是可参考的你拿这个 Prompt 去跑得到的结果大概率和我观察到的一致。如果你也想复现这套测试我建议你连不要使用 React/Vue这种看起来有点任性的限制也一起保留。它在很大程度上决定了最终代码的可运行性删掉之后模型可能给出结构完全不同、但并不能证明更强的方案。3. 三份答卷逐个拆解从生成到运行的全程细节3.1 Step 5 Preview一次成型但手感还有毛刺Step 5 Preview 是这次测试的第一个出场选手。我原以为Preview版本会比较毛糙但它的产出速度相当惊人从发送 Prompt 到完整代码出现只用了 43 秒。代码量约 450 行结构很紧凑一个迷宫生成函数、一个碰撞检测函数、一个主循环、一个 UI 更新函数。明显能看出它有意识地控制体积没有堆砌无关功能。先说亮点。迷宫生成用的是 DFS 递归回溯算法生成出来的地图几乎没有死胡同死区路径自然且分支丰富。碰撞检测用的是基于射线投射的方案具体来说是从玩家位置向移动方向发射一条射线检测射线是否与墙体相交以此判断是否允许移动。这个方案的优点是判定精准即便玩家身体部分贴近墙壁也不会出现卡进墙里或者被墙弹飞的问题。但它的手感有明显毛刺。鼠标拖拽视角时可以感受到轻微的黏滞感——原因是视角旋转增量直接被写死为 0.002 弧度没有和鼠标实际移动量做插值平滑。高帧率下这个问题还能忍一旦帧率掉到 45fps 以下转动起来就会非常颗粒感。移动速度同样写死没有跑步键也没有加速度。这让角色在迷宫里走起来像一个匀速移动的机器人少了那种人在移动的感觉。最终它拿到了 87 分主要丢分在手感和代码注释上。注释确实存在但都是初始化摄像机更新计时器这种描述型注释完全没有解释这个碰撞函数为什么用射线而不是 AABB对后来维护的人帮助有限。3.2 DeepSeek V4 Pro最像团队老手写的代码第二个出场的是 DeepSeek V4 Pro生成耗时 51 秒代码量约 580 行是三份答卷中最长的。它的最大优势在我看是工程性。打开代码第一眼是文件头部大段的模块说明和修改记录注释这种写法在企业级项目里非常常见而在 AI 生成代码里极其罕见。往下看碰撞检测用的是 AABB轴对齐包围盒方案即把玩家和墙体都抽象成一个个长方体盒通过判断盒子之间是否重叠来决定是否阻挡。这个方案的优点是对后续扩展非常友好——如果你想在迷宫里加入会移动的守卫或者可以推动的箱子AABB 不需要重写只需要给物体加一个碰撞盒就行。游戏手感上DeepSeek V4 Pro 明显下了功夫。移动速度写成了常量配置并且特意加了加速度衰减起跑时速度从零快速攀升松开按键后不会立刻停下而是有一个自然的减速过程。视角旋转做了帧率无关处理用 deltaTime 做了插值。在 60fps 和 120fps 两种环境下转动平滑度几乎没有差别。这种细节说明它对游戏引擎里怎么做帧率无关的移动是有概念的不是只会套模板。它的迷宫生成算法选的是 Prim 算法生成的地图风格和 DFS 明显不同路径更开阔但也更容易出现长直的走廊。金币的旋转动画做得很扎实每个金币都是独立的对象有各自的旋转速度和浮动偏移收集后还有一个上浮 缩小的反馈动画。这一份答卷最后拿了 94 分。扣分点主要在依赖管理上它通过 CDN 引入了 three.min.js 和 OrbitControls但版本锁得比较死如果 CDN 上那个精确版本有更新或者失效代码就会直接白屏。对于单文件 Demo 这不算大问题但如果想包装成长期产品这就是隐患。3.3 GLM5.3功能最花哨代价是功耗和开场失败GLM5.3 是测试中最有意思的一位因为它是唯一一个第一版没跑起来的模型。GLM5.3 第一版生成的代码让我有点意外它采用了Three.js React的混合方案用 React 管理 UI 层Three.js 负责 3D 渲染。逻辑上这个方案没什么问题但前提是项目必须经过打包工具构建。我们测试的要求是单 HTML 文件双击直接打开而 React JSX 语法在浏览器里根本没法直接解析导致控制台报了一连串 JSX 编译错误。也就是说光看结构很专业但放到这个题目环境下就直接不合格了。好在 GLM5.3 没有一条路走到黑。我让它重新生成一个不依赖任何构建工具的单文件版本第二次生成的代码约 620 行顺利跑通了。这一版功能确实最花哨迷宫地图画了小地图预览硬币收集数带徽章动画出口位置有一个半透明的光柱特效连提示文案都有淡入淡出效果。可问题也出在这里——功能叠加过多运行性能被拖累了。我用同一台机器测试帧率Step 5 Preview 的版本稳定在 58 帧DeepSeek V4 Pro 稳定在 60 帧GLM5.3 只有 45 到 55 帧之间波动。造成掉帧的原因是迷宫的墙体网格没有做合并每一面墙都是一个独立的 Mesh 对象100 多面墙就得执行 100 多次绘制调用。在移动设备上这个性能问题会被进一步放大。碰撞检测虽然也是 AABB 方案但没有处理连续碰撞。当玩家高速撞向墙角时有几率被挤进墙体内部卡住约两秒后才会被外力推出来。这个 Bug 在测试里触发了三次属于比较影响体验的问题。综合下来 GLM5.3 拿了 81 分。视觉表现和功能丰富度能拿很高分但开场失败 掉帧 卡墙三个硬伤同时出现分数就被拉了下来。4. 横向对比复盘谁赢了指标谁赢了体验4.1 核心指标对比表先看一张汇总表方便快速定位差异对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3首次运行成功率一次通过一次通过第二版通过代码行数约 450 行约 580 行约 620 行迷宫生成算法DFS 递归回溯Prim 算法DFS 连通路补洞碰撞检测方案射线投射AABB 盒AABB 盒无连续修正视角平滑处理无固定增量帧率无关插值简单 lerp帧率同一场景58-60 fps60 fps45-55 fps额外功能无金币收集动画小地图、光柱特效最终评分879481看这张表你可能觉得 DeepSeek V4 Pro 全面碾压但其实没那么简单。它在 4.1 中的三项关键指标上确实领先但在首次生成用时上Step 5 Preview 比它快了 8 秒在功能丰富度上GLM5.3 比它多了三个额外功能。也就是说如果你只看排名DeepSeek V4 Pro 胜如果你看的是单位时间内的产出Step 5 Preview 的效率反而是最高的。4.2 从代码结构看三个模型的工程性格每次做模型对比测试我都会额外关注代码结构因为结构最能反映模型背后的训练数据倾向——它见过的优质项目代码越多生成代码的工程风格就越成熟。Step 5 Preview 的代码风格是典型的极客原型一个文件、一堆函数、全局状态管理能用局部变量就不用对象能少写一行绝不多写。这种代码的优点是阅读路径极短从上往下五分钟就能读完缺点是到了项目中期功能一旦膨胀重构成本会很高。DeepSeek V4 Pro 的代码风格是最接近商业项目的配置常量聚集在顶部、函数按职责分包、注释里甚至写了当速度超过阈值时启用冲刺动画这样前瞻性的逻辑。考虑到它生成代码不超过一分钟这种结构化程度确实让人印象深刻。我在看它的代码时感觉自己在 review 一位有三年游戏开发经验工程师的代码而不是一个对话机器人的输出。GLM5.3 的代码风格像一个创意总监功能点和小效果非常密集但底层工程组织比较随性甚至有 20 行重复片段没有抽取成函数。这种风格做概念验证很爽做需要长期维护的项目会让人崩溃。所以我建议你别只看总分先想清楚自己的使用场景你要是想快速验证一个玩法原型Step 5 Preview 的效率值得用你要是想把代码交给团队后续迭代开发DeepSeek V4 Pro 的工程性会让你少掉很多头发你要是想把效果做花哨拿去演示GLM5.3 能帮你在短时间内攒一波视觉亮点。5. 实测里绕不开的坑从 Three.js 版本到本地部署5.1 GLM5.3 本地复测时 vLLM 镜像版本踩坑在跑完网页测试后我有个习惯如果把模型分数拉回本地再跑一遍看看生产环境下的数据。这次 GLM5.3 的本地部署就给我上了一课。具体问题是这样的我在本地用 vLLM 加载 GLM5.3 的权重启动推理服务时报了个算子不支持的错误报错信息直指某一个融合算子只在更新的 CUDA 版本里可用。折腾了大半个小时最后发现是 vLLM 镜像版本的问题。GLM5.3 的权重里用了一些比较新的张量并行策略老版本的 vLLM 镜像0.6.x 以下没有同步更新对应的算子实现导致加载失败。我当时换成了支持较新 CUDA 12.x 的 vLLM 镜像版本重新安装依赖后才跑通。这里要特别提醒如果你是照着网上教程选镜像务必先看一眼自己显卡的驱动版本再决定用哪个 tag不要盲从教程里的最新版。实测下来驱动版本老卡的机器反而适合稍微旧一个版本的镜像算子支持和驱动版本要一起看缺一个都不行。如果你不打算本地部署只想用官方 API这段可以跳过。但如果你要在自己机器上跑 GLM5.3建议先把这些环境依赖列成清单逐项核对不然那个烧脑的报错绝对会让你怀疑人生。5.2 Three.js CDN 版本差异引发的 OrbitControls 报错还有一个坑几乎没人提过Three.js 版本更新后OrbitControls 的引用方式变了。之前很多教程里的写法是THREE.OrbitControls直接在全局 THREE 对象上取。但从 r148 开始Three.js 的示例模块不再挂载到全局需要从模块路径里单独引入。如果模型生成的代码沿用了旧版写法CDN 加载的又是新版 Three.js运行时会直接抛出 THREE.OrbitControls is not a constructor。这次测试里三个模型都踩了这个坑的一半——它们都引用了最新版 Three.js但其中 Step 5 Preview 的处理方式最讨巧它干脆没在代码里用过 OrbitControls只靠原生的鼠标事件手动控制视角反而规避了这个兼容性问题。GLM5.3 第一版报 JSX 错误之外还有一个隐藏错误就来自 OrbitControls 引用方式只是被 JSX 报错盖住了。以后你们用模型生成 Three.js 项目如果碰到白屏或者控制台报错第一反应别慌张。可以先检查一下引入的 Three.js 版本和模型代码里三个关键 API 是否匹配OrbitControls 的引入方式、Light 的构造函数、以及渲染器的输出编码。这三个地方是版本升级最容易破坏的雷区。5.3 如果把游戏移植到安卓开源项目里还要注意什么测试过程中我还想到了一个延伸场景如果把这些单 HTML 游戏包装成安卓应用会遇到什么新问题我在本地把三个版本的代码分别塞进一个 WebView 容器做简单测试发现性能排名完全变化了。DeepSeek V4 Pro 的版本在手机 WebView 上仍然流畅因为它每帧计算量较小、绘制调用少而 GLM5.3 的版本在手机上直接掉到了 25fps 以下小地图每帧重绘的开销在低端机上是致命的。如果要往安卓方向走我建议优先关注三件事第一确保 WebGL 上下文版本为 2.0部分低端安卓机的默认设置是 1.0性能差距明显第二把墙体网格合并成单个 BufferGeometry这是提升移动端帧率最有效的手段第三触摸控制需要单独适配WASD 键位在手机上没有对应物得增加虚拟摇杆。这三个问题在桌面浏览器里几乎不存在但一迁移到安卓开源游戏项目里就立刻变成主要矛盾。另外一个容易被忽略的点是加载方式。WebView 加载远程 CDN 资源在弱网环境下极易白屏正确的做法是把 Three.js 库和游戏代码一起打包进 assets 目录用本地资源加载。如果你准备用 Capacitor 或者 Cordova 做封装这个打包方案几乎可以无缝迁移。6. 重测会怎么改评分规则与使用建议6.1 我会把离线可用和移动端帧率加入评分表回到开头定的裁判标准原封不动地复盘之后我承认这套标准有一个明显漏洞它太偏向桌面浏览器 在线环境了对一个真实游戏的开发场景覆盖不足。如果让我重新做一遍测试我会在评分表里加入两个新维度。第一个是离线可用性。现在的 CDN 依赖确实方便但游戏项目一旦要部署到正式环境离线资源包几乎是硬性要求。我会把 DeepSeek V4 Pro 那个锁死 CDN 精确版本导致离线失败的问题从扣分里拿出来单独看如果它不能通过离线可用性测试分数会再降。第二个是移动端帧率基线。桌面帧率只是下限移动端才是当前游戏的主战场。三个模型生成的代码在移动端全部掉帧但掉帧幅度差别很大。我建议所有做 AI 游戏生成测评的人都把小屏 触控 低端芯片作为第二个运行场景跑出来的数据才更接近真实用户。第三个改动是增加第二轮修复能力测试。AI 生成代码很难一次完美真正有价值的是模型能不能在收到 Bug 反馈后有针对性地修复。这轮测试里我没做但以我的经验DeepSeek V4 Pro 的修复能力大概率比 GLM5.3 更强因为它生成代码时的错误处理逻辑更系统化。6.2 三个模型分别适合干什么我的个人意见综合这轮实测和过去几十次类似测试的经验我不喜欢给模型排冠亚季军我更愿意说它们各自适合什么活儿。Step 5 Preview 适合做原型验证和快速试错。它的代码生成速度快、体积小、依赖少特别适合上午有个 idea下午就要看到手势的场景。代价是后续扩展潜力有限你要做好推倒重来的心理准备。DeepSeek V4 Pro 适合做需要长期维护的产品代码。它会考虑配置抽取、碰撞扩展、动画状态管理这些问题虽然多写了一些代码但从长期看返工成本远低于另两个模型。如果你的团队是新手程序员为主用它的产出做底子接手的人学习成本也最低。GLM5.3 适合做演示和概念可视化。它的强项是把效果做得丰富、抓眼球小地图、光柱、徽章动画这些功能在 Demo 汇报时非常加分。但你最好只把它当视觉参考不要直接作为项目基座否则后期那些性能优化和代码重构的工作量会淹没你。最后分享一个个人体会这一轮测试花费的周末时间比我自己动手写同一个游戏还要长但收获的东西完全不同。三个模型不是要取代谁而是在不同场景下帮你砍掉无效时间。选择合适的模型就像选择合适的工具——你不一定要用最贵的一把但一定要知道每把工具的脾气和毛病。