如果你手头同时有几个大模型的API额度，多半也想干同一件事：让它们做同一个需求，看谁更像一个正经工程师。我上周就把Step 5 Preview、DeepSeek V4 Pro和GLM5.3拉到同一张考场上，题目统一——做一个能直接在浏览器里跑的3D迷宫逃脱游戏。这篇实测记录不聊跑分、不比基准测试，只讲它们各自的临场表现、代码习惯、3D数学处理能力，以及翻车点。

原本我还想把doubao-seed-2.0-code也拉进来一起测，但时间有限，先把这三个摸透。这个题目看起来不大，其实特别考验模型的综合能力：程序化生成迷宫考验数据结构，第一人称相机和碰撞检测考验3D数学，后期修bug又考验模型对运行时状态的理解。三个模型在相同提示词、相同浏览器环境下的表现差距，比我想象中大得多。

1. 为什么选3D迷宫当考卷：测试方案和评分规则

先说说为什么挑3D迷宫而不是写个倒计时器或者Todo List。那种小需求模型间的差距基本被磨平了，谁都能答得很好，体现不出水平差异。3D游戏不一样，它同时牵扯到几个最容易让模型露馅的点。

1.1 3D游戏踩了哪些AI模型最容易翻车的坑

第一个是程序化内容生成。迷宫不能手摆每一个墙块，必须用递归回溯这类算法去生成二维网格，再转成三维墙体。这个转化过程要求模型能在“逻辑数据结构”和“3D场景表现”之间做映射，一不留神就会行列写反。

第二个是第一人称控制。WASD移动看的是当前视角方向，不是世界坐标方向。这要求模型理解向量旋转、欧拉角顺序和四元数的基本关系。很多模型在这道题上会直接写死成“按世界坐标移动”，看起来能跑，玩起来方向完全错乱。

第三个是碰撞检测。3D场景里的碰撞不是给角色加个边界框就行，得考虑角色半径、墙体的包围盒、射线检测的方向，还要避免“卡在墙里”和“穿墙”。这一块三个模型的表现差异最为明显。

这三个点叠加在一起，基本就是一个小型3D游戏的核心难度。一个能把3D迷宫做顺的模型，应付大部分工程编码任务不会太差。反过来，如果连迷宫都做不顺，说明对运行时空间的理解还停留在“能编译”的水平。

1.2 统一考题：不加提示词的“裸考”

我给三个模型发的提示词完全一致，而且刻意不做任何二次追问，让它们裸考第一次就直接输出方案。中途无论出什么bug，都不追加解释，只看初始结果。完整提示词如下，你们可以自己复现：

生成一个可运行的3D迷宫逃脱游戏，使用Three.js和原生JavaScript，全部代码放在单个HTML文件中。要求： 1. 程序化生成迷宫，使用递归回溯算法，迷宫尺寸不小于10x10 2. 第一人称视角，支持WASD移动，鼠标拖拽旋转视角 3. 玩家与墙体之间有碰撞检测，不能穿墙 4. 场景中有出口标记，走到出口时弹出胜利提示，并支持重新开始 5. 加入光源、地面网格线、墙体材质，保证画面可读 6. 给关键代码添加简洁注释 请直接输出完整HTML代码

1.3 评分维度怎么定

为了避免“我觉得好玩”这种主观偏差，我定了一个可量化的评分表：

后四项是决定性因素。因为我见过不少模型生成的代码能跑但没法玩，穿墙穿得毫无灵魂，视角转两圈人就晕了。这类问题就是数学直觉不过关，跑分测试根本测不出来，实际做3D项目时就是灾难。

2. 接入与部署：Step 5 Preview走API，GLM5.3硬刚vLLM本地推理

三个模型的接入方式差别很大，这部分本身就值得记录一下。尤其是GLM5.3的本地部署，网上关于vLLM镜像版本怎么选的讨论挺多，我这次踩了一遍，有些结论可以直接用。

2.1 Step 5 Preview：API接入最省心

Step 5 Preview走的是官方API，跟常规大模型接口一样，POST一个JSON过去拿流式返回。我拿到的是预览权限，上下文支持得比较长，单次生成800多行代码没问题，不会写一半就截断。响应速度体感在三个里居中，生成那段781行的HTML大约花了54秒，属于正常水平。

接口风格是OpenAI兼容格式，这意味着已有的脚本基本不用改，把base_url换成Step 5 Preview的地址就能跑。对日常开发来说这是挺舒服的一点——不需要为每个模型写一套新的调用链。

2.2 DeepSeek V4 Pro：响应最快，代码量最大

DeepSeek V4 Pro也是走API，整体响应速度是最快的，首轮生成1023行代码只花了42秒。它给我的第一感觉是“手速快”，代码刷屏速度肉眼可见地快，上下文也足够长。输出风格偏工程化，喜欢把功能拆成一个个函数，而不是塞在一坨里。

不过响应快不等于质量高。它的首版代码里有一些对Three.js版本的假设问题，后面会详细说。

2.3 GLM5.3的vLLM本地部署：镜像版本选择实测

GLM5.3这次我用的是本地部署，这就涉及vLLM镜像版本的选择。网上不少人问“glm5.3用vllm哪个版本的镜像”，我实测下来的结论是：不建议直接拉最新标签，反而应该选发布时间超过两周的稳定版。

原因很简单，GLM系列在vLLM里有不少自定义算子，这些算子在不同版本之间变动很频繁。拉太新或者太旧的镜像都会遇到奇奇怪怪的报错，要么是算子不在编译列表里，要么是算子的参数不兼容。我最后选了一个相对保守的稳定版镜像，一次就起来了。

启动命令供参考：

vllm serve glm-5.3-local \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --max-num-batched-tokens 8192

显存方面，单卡4090 24G用低比特量化版本跑得很稳，长上下文下显存占用大概在18G左右。加大--max-num-batched-tokens对首token延迟有明显帮助，但显存也会涨上去，建议根据自己的显存慢慢调。GLM5.3单机单卡实测生成速度在25-35 token/s之间，比前面两个API慢不少，67秒才生成892行代码。

2.4 统一评测环境

为了公平，三个模型跑出来的HTML都在同一台机器上运行。配置是MacBook Pro M1 Pro，Chrome浏览器，WebGL硬件加速打开，三份代码都没有再做任何手工修改。这一步很重要，否则某个模型生成的代码依赖了特定机器特性，对比就不公平了。

3. 首轮同题作文：谁的迷宫从零到能跑

首轮生成结果最能反映模型“一次性成稿”的能力。我不看后续修复，就按最终交付的标准去验收。三个模型的表现，刚好踩了三种不同的坑。

3.1 Step 5 Preview：黑屏，但代码结构最清醒

Step 5 Preview生成的781行代码结构挺清楚，入口函数、初始化场景、生成迷宫、更新循环分得明明白白，注释也写到了“给未来维护者看”的水平。递归回溯算法用的是经典的栈迭代法，没写递归，避免了迷宫太深导致调用栈爆掉，这点很专业。

但它在引入Three.js时用了CDN在线链接，而这条链接的MIME类型在浏览器里被拦了，控制台直接报跨域错误。我检查了一遍代码逻辑，发现除了资源路径问题，其他部分其实是可以正常跑的。手动换了个本地引用后，场景能加载，第一人称移动也是对的。不过按“裸考”原则，首轮它该算不合格。

3.2 DeepSeek V4 Pro：能跑，迷宫和移动都正常，但能穿墙

DeepSeek V4 Pro第一版直接打开就能看到迷宫，网格线、光照、墙体渲染都没问题。WASD移动也很顺手，方向键跟随视角，说明它对向量旋转的理解是到位的。

问题是碰撞检测。它当时的实现是把所有墙体对象丢到一个数组里，每帧遍历每个墙做距离判断。听起来没问题，但它判断的是“角色中心点是否进入墙体”，而没有把角色半径和墙体的包围盒做扩张。结果就是角色走到墙边，中心点还差半个身位才触发碰撞，看起来就是人嵌在墙里一半才能停住，再走两步干脆穿过去了。

这个问题在代码里很隐蔽，不实际玩根本看不出来。跑分模型测试永远测不出这种问题，只有上手才知道。

3.3 GLM5.3：唯一一次全通，但视角转起来像坐过山车

GLM5.3的892行代码首跑成功率最高，迷宫生成、碰撞检测、出口判定全部可用。它用了经典的AABB包围盒做碰撞，角色半径也考虑了，移动手感虽然不算丝滑，但至少人不会穿墙。这一项确实拉开了差距。

但它的相机控制有明显问题：鼠标上下拖动时，相机的y轴会跟着翻滚。原因是它同时修改了camera.rotation.x和camera.rotation.z，直接导致万向节死锁。只要视角往下拉一点，整个世界就开始歪着转，玩不了一会儿就晕。这就是欧拉角顺序处理不对的表现。

3.4 首轮对比

这个结果有点反直觉：API响应最慢的GLM5.3反而首轮最完整，响应最快的DeepSeek V4 Pro反而藏着大问题。Step 5 Preview介于两者之间，代码底子最好，但外部的资源引用方式给它拖了后腿。

4. 3D数学专项摸底：相机、碰撞、传送门哪个模型没翻车

首轮之后，我把三个模型拉过来做第二轮专项测试。这次不看整活代码，只看它们对3D数学细节的处理是否扎实。

4.1 相机控制：最有代表性的送分题

第一人称相机最常见的坑就是把欧拉角顺序搞错。Three.js的相机默认旋转顺序是XYZ，但对第一人称游戏来说，应该锁住滚转轴，通常把顺序改成YXZ，也就是先绕Y轴左右转，再绕X轴上下看。如果保留了默认的XYZ，上下看的时候就会诱发Z轴旋转，出现翻滚现象。

GLM5.3首轮的翻滚问题就是典型。我后来把问题单独提给它：“为什么视角上下移动时世界会歪？”它的第二次回答很精准，直接指出欧拉角顺序需要改为YXZ，并建议在鼠标移动时不要直接改rotation.z。这说明它的数学知识库里有这个常识，只是第一版没主动用上。

DeepSeek V4 Pro首轮倒是没犯这个错，它直接用四元数存旋转角，来源是对鼠标位移做累积再转成四元数。方向正确度高，但代码稍显冗余，四元数在这种场景下有点杀鸡用牛刀。

Step 5 Preview黑屏修好后，相机这块从来没出过问题，说明它的基础3D数学储备比较扎实。

4.2 碰撞检测：三种不同层次的理解

碰撞检测是这次实测最精彩的对比点。三个模型给出了三种不同思路：

Step 5 Preview用的是射线检测。它从角色中心沿移动方向发出一条短射线，射中墙体就取消位移。这种做法的好处是性能稳定，不会因为墙体数量多而变慢，坏处是对角色半径的模拟不太准，容易在墙角处卡顿。整体属于“够用但需要调参”的级别。

DeepSeek V4 Pro首版是遍历所有墙体做距离判断，三角网格全部参与计算。逻辑倒是简单，但是每帧都做全量遍历，迷宫一大帧率就往下掉。我测下来20x20的迷宫帧率就只有20多帧了。它的修复版本才改成AABB判断，性能才恢复正常。

GLM5.3则是规规矩矩的AABB包围盒碰撞，扩张了角色半径，移动时做水平和垂直方向分开的位移检测，避免斜向卡墙。这个方案是三个里最稳的，逻辑也最清晰。它在这方面给我的感觉就是“懂行”。

4.3 出口判定和胜利逻辑：状态管理见真章

出口判定在3D游戏里属于典型的阈值判断问题，看起来简单，但做不好会有两种极端：一种是判定范围太小，玩家明明踩上去了却没反应；另一种是判定范围太大，离出口还有两米就胜利了。

Step 5 Preview用的是固定距离阈值：角色位置和出口标记点的欧氏距离小于1.5就触发胜利。DeepSeek V4 Pro用Box3求交，把出口视为一个三维盒子，角色包围盒和出口盒子相交就触发。GLM5.3介于两者之间，用了距离阈值加状态锁，胜利之后停止移动并弹出遮罩。

实际体验下来，DeepSeek V4 Pro的Box3方案最跟手，站在出口边缘就能触发，不会有“还差一步”的挫败感。Step 5 Preview的固定阈值方案需要调参，如果玩家出口前加速冲过去，容易冲出判定范围。GLM5.3虽然触发了，但胜利弹窗没有把控制权完全锁死，键盘还能操作，会有一瞬间角色在胜利界面后面继续走。

4.4 专项结论

这一轮3D数学专项，按我的评分权重换算，GLM5.3整体最稳，Step 5 Preview基础最扎实但需要调参，DeepSeek V4 Pro思路最发散且性能意识较差。这个排序和首轮正好相反，更说明单看生成速度没有意义，得把专项能力拆开看。

5. Debug大战：把穿墙、视角翻滚、出口失灵三个bug原样喂回给模型

第二轮专项之后，我进入最折磨人的环节：把实际运行中遇到的bug原样反馈给每个模型，让它们自己修。这里的核心问题是“修复质量”——修好目标bug的同时有没有把别的功能改崩。

5.1 故意给每个模型分配它最应该背的锅

我按首轮翻车点分配了bug修复任务：让DeepSeek V4 Pro修穿墙问题，让GLM5.3修视角翻滚问题，让Step 5 Preview修黑屏之后暴露出来的出口判定问题。反馈提示词统一用这个模板：

当前游戏存在一个bug：玩家可以在墙体中穿行，应该被墙体阻挡。请检查碰撞检测逻辑并修复，解释原因，只输出需要改动的代码段。

三个模型的修复过程都很有代表性。

5.2 DeepSeek V4 Pro：思路正确，但性能被它自己搞砸了

DeepSeek V4 Pro对穿墙问题的修复很直接：给每个墙体生成一个AABB包围盒，移动前先做包围盒相交检查，如果相交则把位移分量清零。它甚至考虑了斜向移动时按轴分离处理，把x轴和z轴的位移分开判断。这个修复本身是合格的，玩家会被墙体挡住了。

但它在修复过程中顺手把原来的墙体数组改成了动态遍历，而且每帧都生成新的盒对象。这意味着每次移动要重新计算几百个Box3实例，帧率从能玩直接掉到卡顿，20x20迷宫下只剩十五六帧。等于修好了穿墙，又亲手毁了性能。这类问题说明模型在给出修复方案时，并没有意识到渲染循环里不能干重活。

5.3 GLM5.3：一次修复到位，连手感一起优化

GLM5.3的修复过程是三个里最舒服的。它对视角翻滚问题的回答直接改了两处：一是在构造函数中把相机的旋转顺序改成YXZ，二是在鼠标移动处理里屏蔽了对rotation.z的写入。它还顺手把鼠标灵敏度系数单独拎出来做成变量，方便手动调节。

实测修复后，视角上下左右拖动都很正常，不再翻滚。而且它的修复没有侵入其他功能模块，移动、碰撞、出口判定都保持原样。这种“手术式修复”的能力，在三个模型里独一档。

5.4 Step 5 Preview：修出口判定，却把出口位置算错了

Step 5 Preview的修复过程有点曲折。第一轮修复它给出的代码逻辑表面看是对的，距离阈值判断、触发事件、弹窗样式都有，但把出口标记重新定位时，坐标系搞反了，出口被放进了迷宫墙体内部，玩家走到原位置根本找不到出口。

我把运行结果再次反馈给它之后，第二轮它才意识到是行列坐标映射问题，修正了grid[x][y]和scene.position之间的对应关系。这说明它对“程序化生成时的二维数组坐标”与“三维世界坐标”之间的转换理解还不稳定。建模能力够，空间映射能力欠点火候。

5.5 修复阶段的隐藏考点：会不会殃及池鱼

修复bug除了看能不能修好，还要看有没有引入新问题。我特意在每个模型修复后跑了一遍完整流程：开始游戏、走完迷宫、触发胜利、点击重新开始。结果如下：

这股“拆东墙补西墙”的劲头，其实跟初级工程师很像。DeepSeek V4 Pro属于那种脑子转得快但全局意识差的，Step 5 Preview是细心但空间感偶尔掉线，GLM5.3是最接近“老手改代码”的体验。

6. 最终成绩单和我的选型建议

所有测试跑完，三个模型修完bug后的最终版本都在浏览器里稳定运行了一遍。我整理了完整数据，也聊聊在什么场景下我会优先选谁。

6.1 综合对比表

三个模型最终都做出来了能玩的3D迷宫，这本身就说明现在的AI编码能力已经跨过了“能做3D游戏”的门槛。差距不在于能不能做，而在于做到什么程度服务的效率。

6.2 各自的真实定位

Step 5 Preview给我的感觉是“架构师型”。它的代码拆分思路清楚，模块边界明确，复杂项目让它来搭框架会很稳。但它的外部依赖处理偏理想化，容易在真实环境里翻车，适合用它出整体方案，再人工检查资源引用和边界条件。

DeepSeek V4 Pro是“快手型”。响应快、代码量大、脑洞多，适合早期快速试错和功能验证。它的问题是没有性能意识，生成的代码跑起来容易埋雷。用它写原型可以，写生产代码前必须人工做一轮性能Review。

GLM5.3是“保守型选手”。生成慢一点，但代码风格稳，首跑概率高，修复精准。本地部署能离线跑是它独有的优势。在需要保证“不会因为模型自身的原因给项目折腾半天”的时候，我这轮实测里最放心的是它。

6.3 如果目标是安卓端的3D游戏

顺便回应一个最近很多人问的方向：开源安卓3D游戏。如果要把迷宫游戏搬上安卓，通常是用Unity导出一套工程，再调触控输入。这种情况下我的实测体会是，GLM5.3的代码更好迁移：它的注释够清楚，函数边界明确，能直接对应到Unity里的Update循环和碰撞组件。DeepSeek V4 Pro生成的WebGL原生代码和Three.js深度绑定，迁移到Unity时重写成本反而更高。Step 5 Preview因为结构清晰也能迁，但要处理的坑比GLM5.3多一些。

如果你打算跑“提示词生成一个安卓3D游戏”这种路线，我建议把GLM5.3生成的逻辑代码作为主干，再用Step 5 Preview搭UI框架，最后让DeepSeek V4 Pro快速补功能模块，三个配合着用比单个模型硬刚要舒服得多。

6.4 给也想做同题测试的人一个建议

最后说个测试方法论上的心得：做这种横向对比，提示词一定要冻结，不能中途给某个模型“加餐”。我见过很多人测着测着看某个模型卡住了，就追加一句“请参考某某模型的思路”，这一下对比就失效了。你要测的是模型的独立真实水平，不是测谁更会抄作业。我自己这轮也手痒过几次，硬忍住了，才换来这份还算干净的数据。

另外，3D项目的验收一定要实际玩，不能只看代码能不能运行。穿墙、翻滚、判定延迟这些问题，全都是在真实操作里暴露出来的。代码能编译通过，离能交付之间还有很长的距离。模型跑分再高，都不如让玩家实际走一遍迷宫的反馈来得真实。