三大AI模型实测：用Three.js生成3D迷宫游戏，谁更胜一筹？

如果你这两个月一直在关注 AI 编程动态大概率看到了不少关于 Step 5 Preview 的讨论连带着 DeepSeek V4 Pro 和 GLM5.3 也成了 3D 游戏生成的热门对比对象。嘴上说一千道一万不如实打实跑同一道题。我把这三个模型拉到同一起跑线让它们分别做一个 3D 游戏然后把整个实测过程摊开写出来。任务本身不算复杂但也不是那种一套模板能糊弄过去的用 Three.js 做一个 3D 迷宫网页游戏玩家以第一人称视角在迷宫里移动找到出口同时加上碰撞检测、计时和灯光效果。这基本覆盖了 3D 游戏开发里最常踩的几块硬骨头——场景搭建、碰撞检测、交互控制、HUD 更新。对任何一个代码生成模型来说既要懂 Three.js 的 API也得能组织出合理的游戏逻辑两者缺一不可。这篇文章适合两类人一类是想用 AI 快速搭 3D 游戏原型的独立开发者想知道到底选哪个模型最省力另一类是刚开始接触 AI 辅助编程的读者想看看同一个需求在不同的模型手里会变成什么样子。我把三份答案的差异、调试过程和踩到的坑都记录下来不粉饰不夸大尽量让看完的人能直接参考。1. 实测前的规格设定同一道题三份卷子1.1 为什么我不写需求文档而是严格统一提示词很多人第一次用 AI 做游戏上来就甩一句“帮我写一个 3D 游戏”。这时候三个模型大概率会给出三种完全不同的东西——可能其中一个做了个旋转魔方 demo另一个用原生 WebGL 硬写了一个旋转立方体还有一个给你做了个 2.5D 伪 3D 页面。这种对比没有意义因为任务本身没有被约束住。这次的提示词我统一成以下格式刻意把技术栈、玩法、交互和完成标准全部写死用 Three.js版本 r160写一个 3D 迷宫游戏网页满足以下要求包含一个指定尺寸的地板按标记好的网格边界生成迷宫墙壁碰撞盒使用 AABB。第一人称 WASD 移动鼠标拖拽旋转视角空格跳跃。迷宫地图通过二维数组定义1 代表墙0 代表通道。包含一个起点和一个终点方块到达终点后弹窗提示通关并显示用时。顶部显示 HUD包含“重新开始”按钮和计时器。使用 DirectionalLight AmbientLight 照明所有对象使用基础材质并设置颜色。代码必须是单独的 HTML 文件包含所有样式和逻辑。值得一提的是所谓“同题实测”任务相同只是基础。如果连迷宫数组、光照参数、摄像机位置都统一给死那实际上没法对比模型的代码组织能力。所以我在需求里只固定规则、固定玩法不固定具体数值模型的自由度在于“怎么把规则落地”而不是“做什么功能”。这样测出来的差异才真正来自模型本身的思路差异。1.2 五个维度对应五个真实痛点触动评测开始前我先定好了评分维度免得后面凭感觉打分。这套标准同样适合你在日常工作中评估一个 AI 生成的 3D 项目到底能不能用维度权重评分要点首轮可运行率20%打开页面能否直接跑有没有报错场景完成度25%迷宫、光照、摄像机、地面这些元素是否齐全交互表现20%WASD、鼠标视角、跳跃是否顺手碰撞会不会穿墙代码可维护性15%注释是否清晰逻辑分层是否合理多轮修复能力20%同样的报错喂回去谁改得快、改得准每个维度按 1-5 分打分加权后得出总分。实际跑下来前三个维度拉开的差距最大后两个维度暴露出更多模型“性格”上的差异。分维度的好处是即便某个模型总得分一样你也能根据自己的痛点做判断——比如你是个新手那“首轮可运行率”就比“代码可维护性”重要得多。2. 第一轮三个模型交出的第一份答卷2.1 Step 5 Preview空间感让人愣了一下先测 Step 5 Preview。坦白说我对“Preview”后缀的模型历来持保留态度——预览版往往首发惊艳、细节翻车或者反过来最开始很差、迭代几轮之后才勉强能用。但这次的第一版Step 5 Preview 在场景空间感上明显超出我的预期。它给出的迷宫是一个 10x8 的二维数组里面完整生成了围墙每面墙的高度是 2厚度是 0.5第一人称摄像机初始位置在起点正上方视线方向朝向迷宫内部画面的纵深感和层次感都有。PointerLockControls 用的是标准写法鼠标旋转灵敏度被调到了 0.002实测拖拽手感还算顺滑没有出现视角“发飘”的问题。问题出在两个稍小的地方一个是墙体碰撞直接采用 AABB但检测边界没有做半宽收缩滑过墙角的时候会被卡一下另一个是跳跃高度设到了 1.5而墙高是 2这个跳跃基本跳不过任何墙属于功能存在但实际派不上用场。从第一版代码完成度来看它已经可以做到打开页面直接跑不需要人工补任何东西。2.2 DeepSeek V4 Pro稳定但场景有点素DeepSeek V4 Pro 这一版的代码给我的第一印象是“稳”。它把整个游戏拆成了init、createMaze、createPlayer、animate四个函数划分非常清楚注释也很多读起来完全不费力。迷宫用了 8x8规模比第一个模型小一圈但该有的地板、墙壁、终点方块都没少。场景偏“素”主要体现在视觉效果上所有墙体都是一个颜色和地板的颜色对比度不够光照强度也给得很低导致迷宫边界在屏幕上看不太清楚。对于游戏体验来说这不算功能缺陷但视觉引导会差不少。换句话说它能给你一个能跑通、能通关的迷宫却没法给你那种“有点想玩下去”的感觉。很多刚入门的开发者可能会忽略这一点反正功能都有但实际给别人看 demo 的时候画面观感往往决定了对方的第一印象。2.3 GLM5.3最有游戏感也最激进GLM5.3 第一版是三者中我打开页面就觉得“有游戏那味儿”的。它把摄像机高度设为 1.6墙体用略带渐变的颜色系列并给每一面墙赋予随机色值视觉节奏明显更丰富。地板用灰白色墙面用偏冷的蓝绿系终点方块刷成醒目的橙色整体配色逻辑是成体系的。它做得最好的一点是迷宫采用 DFS 算法动态生成。传入一个 9x9 的种子参数墙壁由算法生成而不是硬编码二维数组。这意味着后续改关卡只是改一个参数的事扩展性明显更好。相比之下前两个模型都是写死数组想换一张地图就得改代码不太优雅。但 GLM5.3 也踩了一个坑它把跳跃绑定在一段基于 Raycaster 的落地检测逻辑上初次触发时视角会剧烈抖动有点像是角色在“抽搐”。另外两个模型完全没有抖动问题所以这部分交互分被扣了不少。功能它做得多bug 也更多这是它在第一轮给我留下的整体印象。2.4 第一轮结果汇总把三个模型的第一版结果拉成一张表对比就非常直观了对比项Step 5 PreviewDeepSeek V4 ProGLM5.3直接运行通过通过通过迷宫方式10x8 写死8x8 写死9x9 动态生成墙面碰撞有边界偏宽有中等有基本正常跳跃有高度不合理有合理有视角抖动视觉表现中等偏上偏素最好代码结构平铺直叙函数分块清晰较规范第一轮暂时稍占上风的是 GLM5.3它虽然有点小毛病但在“像游戏”这件事上领先不少。Step 5 Preview 和 DeepSeek V4 Pro 更接近“工具人”路线——功能齐全观感普通。不过这只是第一轮真正的差距要到多轮迭代和报错修复里才会暴露。3. 多轮打磨从刚能跑到像一个游戏3.1 碰撞边界优化这一轮暴露了模型的调试偏好在第一次迭代中我给三个模型发了一模一样的反馈当前游戏里靠墙走时视角会明显卡顿走到墙角时会被吸住。请优化碰撞检测。这里真正考验的是模型能不能自己判断问题出在 AABB 的半宽补偿上。一个合格的解决方案需要知道玩家的碰撞半径不能只用一个整数值必须考虑墙壁厚度对边界的影响。Step 5 Preview 的修复思路很直接把玩家碰撞半径从 0.5 降到 0.35并在检测 x 轴和 z 轴时减去墙厚的一半。改完之后墙角卡顿基本消失只在切角走位时还有一点轻微的拖拽但不影响正常操作。它给这段逻辑写的注释解释了每个数字的含义看得出来是有认真思考的。DeepSeek V4 Pro 的修复方式更保守。它在碰撞检测函数里加了一个isColliding状态人物只有在解除碰撞之后、且移动方向不朝向墙时才能继续前进。相当于在“粘连”逻辑上增加了一层门槛防止玩家紧贴墙面持续移动。这种修复没有直接解决半宽问题但如果你不是故意贴墙走基本感受不到吸墙。只不过代码变长了整体更加繁琐。GLM5.3 的修复最让我意外它直接把碰撞从数值估算换成了更精确的边界盒相交检测也就是让玩家对象的包围盒和墙体的包围盒做实际相交判定。这样做虽然需要额外计算但碰撞边界非常干净没有“卡墙”和“吸墙”的问题算是三个模型里效果最透的一个方案。迷宫规模不大的情况下性能代价可以忽略。这一轮GLM5.3 再次走技术激进路子但它的激进方向是对的——用精度换体验而不是单纯加判断逻辑。3.2 光照调优三个模型对“好看”的理解完全不同第二轮我统一要求当前场景边界不明显我想优化光照质感使用淡紫色环境光主光颜色偏冷蓝给墙体增加一点材质层次不需要阴影。Step 5 Preview 直接照做加了AmbientLight(0x404060)和一个DirectionalLight(0x88aaff)并把墙体材质换成了MeshStandardMaterial。但这里它踩了一个常见坑——MeshStandardMaterial在不设置roughness和metalness的情况下默认值会让物体呈现出一种偏塑料的质感反光很假整体看起来甚至比原来的基础材质更不协调。它理解了需求但没有把材质参数一起调好属于典型的“事情做了细节没跟上”。DeepSeek V4 Pro 走了另一条路。它没换材质而是调整了光照颜色和强度并把墙体换成MeshBasicMaterial同时额外注释了一句“如果需要更真实的物理材质可以把材质类型改为 MeshStandardMaterial”。它的默认结果视觉变化不大但确实没有翻车也给了后续扩展的入口。换个角度说它更擅长做减法保证下限。GLM5.3 则直接把光照拆成三组环境光负责整体色调主方向光负责轮廓副方向光负责暗部补光。然后墙体换成MeshPhongMaterial配合 HSL 色系生成算法让每一面墙在同一个蓝紫色系下产生细微差异。这个版本的迷宫在视觉上已经明显“高级”了不是功能堆出来的高级而是真正懂得用光制造氛围的高级。不过代码量也随之膨胀光光照相关初始化和更新逻辑就占了 80 多行。三个模型对比下来Step 5 Preview 有想法但落地粗糙DeepSeek V4 Pro 求稳但不出彩GLM5.3 在视觉工程上的人味最重。3.3 计时与通关系统细节差距从这里开始第三次迭代我要求加入计时器和通关系统顶部显示一个时间标签按每秒刷新到达终点时弹出“闯关成功用时 xx 秒”提供一键重开按钮。Step 5 Preview 的实现很教科书用全局变量存Date.now()每帧里算出差值然后输出到文本节点。重开逻辑放在一个resetGame函数里把计时器归零、玩家位置复位、提示弹窗关掉。这版功能完整没什么毛病但也没有惊喜。DeepSeek V4 Pro 给了一个意料之外的细节计时器不是从页面加载开始计而是从玩家第一次按下移动键才开始。它的注释是这样写的“避免用户加载页面后长时间观察场景导致计时失真。”这个细节相当聪明因为浏览器页面加载后用户可能不会立刻操作如果计时从加载开始算会对玩家的游戏成绩不公平。这属于需求里完全没提但模型自己考虑到的隐藏问题。GLM5.3 的计时器用了performance.now()精度更高同时把通关判定改成复用碰撞引擎——由于它在第一轮已经做了边界盒相交检测终点判定只需要判断玩家包围盒是否和终点包围盒重叠逻辑上可以复用同一套碰撞代码。这个思路很优雅但实际运行中出现了一个 bug到达终点时因为玩家还在按着移动键碰撞引擎在连续几帧内都检测到相交导致弹窗弹了三次。我反馈之后GLM5.3 在下一版里加了一个“仅触发一次”的布尔开关弹窗问题顺利解决。但这件事也反映出 GLM5.3 的特色——设计时想得很大边界条件往往要自己撞上才知道补。3.4 多轮迭代后的整体状态优化项Step 5 PreviewDeepSeek V4 ProGLM5.3碰撞优化缩小半径 减半宽增加碰撞状态锁包围盒精确检测光照调整换材质偏塑料感调整颜色保守三路光照 HSL 渐变计时逻辑全局时间简单从首次操作计时高精度计时通关判定正常正常重复弹窗后修复到这一步GLM5.3 在视觉效果上仍然领先Step 5 Preview 和 DeepSeek V4 Pro 的差距在缩小但都没有达到 GLM5.3 的观感水平。真正拉开体验差距的是下一轮报错调试。4. 报错调试把浏览器控制台原样丢给模型4.1 我的测试方法模拟真实开发中最常见的自救场景在实际开发中AI 生成的代码一次跑通只是理想状态更多时候你得把控制台的报错复制一遍丢回去让模型修。为了测这一项我从三个模型各自最容易出现的错误类型里挑了一个代表性报错并且不加任何额外提示直接复制控制台信息喂回去。这样能最大程度还原使用者最真实的操作路径。三个报错分别是Step 5 PreviewTypeError: Cannot read properties of undefined (reading position)原因是某个对象在初始化之前被访问了人眼 position 属性DeepSeek V4 ProReferenceError: controls is not defined原因是 PointerLockControls 在函数内部声明但 animation 循环外部引用了它GLM5.3TypeError: Cannot read properties of undefined (reading intersectObjects)原因是 Raycaster 的检查对象数组为空就调用了相交检测。这三类报错几乎是 Three.js 开发里最常见的问题用来测试它们的修复能力非常合适。4.2 第一轮报错修复对比Step 5 Preview 的响应速度很快。它先判断 null 大概率是某个 mesh 未初始化导致的然后把camera.position赋值逻辑放到initPlayer回调之后并用if (mesh) {}包了一层判断。我刷新页面后问题直接消失整个过程大概 7 秒就能完成替换。这种“找出未初始化对象 加保护”的方式很扎实。DeepSeek V4 Pro 处理controls is not defined的方式是把声明提到全局作用域同时保留一个plockControls变量防止重复初始化。它输出的修改后代码比原来多了大概 40 行注释也因此变长但也把问题解决得非常彻底——甚至考虑到了页面重开后需要重新初始化控制器的边界场景。代价是代码冗余偏多但如果你在意健壮性这个风格会更适合。GLM5.3 的修法更有工程思维它不仅给intersectObjects加了空数组判断还顺手把 raycaster 的调用频率从每帧改成每三帧一次。它对外的解释是“减少不必要的碰撞检测计算”这对移动端性能有实际意义。但代价是新引入了一个帧计数器变量如果只看注释不看全代码第一次接手的人可能会有点摸不着头脑。这一轮三者都顺利修复了报错。Step 5 Preview 最快DeepSeek V4 Pro 最稳GLM5.3 最会顺便优化。4.3 更难的问题出口被墙挡住了只测表面报错还不够我还加了一个逻辑陷阱迷宫地图中有一个格子设置错误导致终点区块被墙体覆盖玩家能走到终点位置但终点判定永远不会触发因为终点的碰撞盒和墙体重叠碰撞检测被墙体优先拦截。这不是报错信息能告诉模型的问题而是要模型自己去思考“为什么角色明明在终点旁边却触发不了通关”。三个模型的解法完全不一样Step 5 Preview 直接改动地图数据把终点位置周围三个格子的墙体全部改成 0从根源消除冲突。这个方案简单、直接、有效但缺点是只针对当前这张地图不是通用解法DeepSeek V4 Pro 没有改地图而是把终点碰撞盒的体积扩大了一倍。也就是说玩家距离终点还有半格时就能触发通关判定。优点是地图数据不被破坏缺点是游戏边界瞬间变得很“软”玩家离墙还有明显距离就判定成功体验上有一种莫名其妙的宽容感GLM5.3 把终点判定从碰撞盒改成了距离判定——只要玩家和终点中心点在 xz 平面上的距离小于 1.2 个单位即判定通关。这个方案不改地图、不扩大碰撞盒精度适中通用性也最好。从这个案例能看出来三个模型面对非直接报错的逻辑错误时展现出明显不同的思维方式Step 5 Preview 偏局部修补DeepSeek V4 Pro 偏规则调整GLM5.3 偏算法重构。5. 最终评分与选型建议5.1 加权评分结果把三个模型在五轮测试里的表现按之前的权重汇总结果如下评分维度Step 5 PreviewDeepSeek V4 ProGLM5.3首轮可运行率20%545场景完成度25%345交互表现20%334代码可维护性15%453多轮修复能力20%445加权总分3.754.04.45单看总分GLM5.3 领先优势明显。但这里我要强调一个很容易被忽略的事总分高不代表所有场景都适合用。评分权重是我按自己的偏好定的如果你把“代码可维护性”的权重调高到 30%DeepSeek V4 Pro 和 GLM5.3 的差距会迅速缩小如果你完全不在乎视觉效果那么 Step 5 Preview 的性价比也不错。5.2 按需求场景选择我的主观建议做完这一轮实测我自己已经形成了一套选择思路如果你只是想快速把想法变成能跑的原型不太在意视觉细节Step 5 Preview的效率确实高。它第一版就能跑通修复也快非常适合开发前期探索用可以帮助在最短时间内验证玩法的可行性。如果你希望代码整齐、后期维护省心适合团队协作场景的话DeepSeek V4 Pro更合适。它的代码结构最接近一个规范工程师的手笔注释完整边界考虑周全哪怕你三个月后回头再看代码也几乎不需要重新理解上下文。如果你对视觉质感有要求想把游戏做成一个有观感、能拿得出手的 demo并且愿意花一点时间处理逻辑层面的小坑那么GLM5.3最值得一试。它的迷宫生成、光照设计、碰撞方案都明显更有“产品感”前提是你能接受它偶尔会在边界条件上翻个小错然后自己知道把它纠正回来。作为一个从 2017 年就开始用各种代码生成工具搭原型的人我越来越觉得AI 模型之间真正的差异不在于谁能一次写对而在于当需求变复杂、迭代变多的时候谁还能保持代码的清晰度和可控性。这次 3D 迷宫实测里GLM5.3 靠视觉和算法创新拿了最高分但如果你让我在它和 DeepSeek V4 Pro 之间选一个长期维护我可能还是会偏向 DeepSeek V4 Pro——因为它的代码放在任何团队里都不会引发认知负担。最后分享一个小技巧无论你选哪个模型第一版生成之后一定要立刻跑起来测而且要多场景测试——站着不动走一圈、贴墙走的时候慢慢移动、狂奔着撞击墙角、反复横跳试图越过墙。这些看起来像是为难游戏的测试恰恰是 3D 游戏交互体验的试金石。模型能写出一个能玩的迷宫不稀奇能在这些刁钻操作下依然保持稳定的碰撞和视角反馈才是真正值得依赖的那一个。