如果你手头同时有几个大模型的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 评分维度怎么定为了避免“我觉得好玩”这种主观偏差我定了一个可量化的评分表维度说明权重首跑成功率首次生成的HTML能否直接打开并操作20%3D数学正确性相机旋转、移动方向、碰撞是否物理合理30%游戏完整性胜利判定、重新开始、状态反馈是否齐全20%工程习惯代码结构、注释、是否有模块拆分意识15%性能表现帧率、渲染循环里是否干了一堆不该干的活15%后四项是决定性因素。因为我见过不少模型生成的代码能跑但没法玩穿墙穿得毫无灵魂视角转两圈人就晕了。这类问题就是数学直觉不过关跑分测试根本测不出来实际做3D项目时就是灾难。2. 接入与部署Step 5 Preview走APIGLM5.3硬刚vLLM本地推理三个模型的接入方式差别很大这部分本身就值得记录一下。尤其是GLM5.3的本地部署网上关于vLLM镜像版本怎么选的讨论挺多我这次踩了一遍有些结论可以直接用。2.1 Step 5 PreviewAPI接入最省心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 ProChrome浏览器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 首轮对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3首轮耗时54秒42秒67秒代码行数7811023892首跑是否可玩否黑屏部分可玩穿墙可玩但视角异常最大缺陷依赖加载失败碰撞检测失效相机翻滚这个结果有点反直觉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除了看能不能修好还要看有没有引入新问题。我特意在每个模型修复后跑了一遍完整流程开始游戏、走完迷宫、触发胜利、点击重新开始。结果如下指标Step 5 PreviewDeepSeek V4 ProGLM5.3目标bug是否修复第二版修好第一版修好第一版修好是否引入新问题出口坐标错乱帧率暴跌无修复解释质量一般较好最好这股“拆东墙补西墙”的劲头其实跟初级工程师很像。DeepSeek V4 Pro属于那种脑子转得快但全局意识差的Step 5 Preview是细心但空间感偶尔掉线GLM5.3是最接近“老手改代码”的体验。6. 最终成绩单和我的选型建议所有测试跑完三个模型修完bug后的最终版本都在浏览器里稳定运行了一遍。我整理了完整数据也聊聊在什么场景下我会优先选谁。6.1 综合对比表指标Step 5 PreviewDeepSeek V4 ProGLM5.3最终可玩性完整可玩完整可玩完整可玩总调试轮次3轮2轮1轮最终帧率20x20迷宫约50fps约30fps约45fps代码总行数9201180950代码维护性好中等好速度生成耗时54秒42秒67秒三个模型最终都做出来了能玩的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项目的验收一定要实际玩不能只看代码能不能运行。穿墙、翻滚、判定延迟这些问题全都是在真实操作里暴露出来的。代码能编译通过离能交付之间还有很长的距离。模型跑分再高都不如让玩家实际走一遍迷宫的反馈来得真实。
如果你手头同时有几个大模型的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 评分维度怎么定为了避免“我觉得好玩”这种主观偏差我定了一个可量化的评分表维度说明权重首跑成功率首次生成的HTML能否直接打开并操作20%3D数学正确性相机旋转、移动方向、碰撞是否物理合理30%游戏完整性胜利判定、重新开始、状态反馈是否齐全20%工程习惯代码结构、注释、是否有模块拆分意识15%性能表现帧率、渲染循环里是否干了一堆不该干的活15%后四项是决定性因素。因为我见过不少模型生成的代码能跑但没法玩穿墙穿得毫无灵魂视角转两圈人就晕了。这类问题就是数学直觉不过关跑分测试根本测不出来实际做3D项目时就是灾难。2. 接入与部署Step 5 Preview走APIGLM5.3硬刚vLLM本地推理三个模型的接入方式差别很大这部分本身就值得记录一下。尤其是GLM5.3的本地部署网上关于vLLM镜像版本怎么选的讨论挺多我这次踩了一遍有些结论可以直接用。2.1 Step 5 PreviewAPI接入最省心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 ProChrome浏览器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 首轮对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3首轮耗时54秒42秒67秒代码行数7811023892首跑是否可玩否黑屏部分可玩穿墙可玩但视角异常最大缺陷依赖加载失败碰撞检测失效相机翻滚这个结果有点反直觉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除了看能不能修好还要看有没有引入新问题。我特意在每个模型修复后跑了一遍完整流程开始游戏、走完迷宫、触发胜利、点击重新开始。结果如下指标Step 5 PreviewDeepSeek V4 ProGLM5.3目标bug是否修复第二版修好第一版修好第一版修好是否引入新问题出口坐标错乱帧率暴跌无修复解释质量一般较好最好这股“拆东墙补西墙”的劲头其实跟初级工程师很像。DeepSeek V4 Pro属于那种脑子转得快但全局意识差的Step 5 Preview是细心但空间感偶尔掉线GLM5.3是最接近“老手改代码”的体验。6. 最终成绩单和我的选型建议所有测试跑完三个模型修完bug后的最终版本都在浏览器里稳定运行了一遍。我整理了完整数据也聊聊在什么场景下我会优先选谁。6.1 综合对比表指标Step 5 PreviewDeepSeek V4 ProGLM5.3最终可玩性完整可玩完整可玩完整可玩总调试轮次3轮2轮1轮最终帧率20x20迷宫约50fps约30fps约45fps代码总行数9201180950代码维护性好中等好速度生成耗时54秒42秒67秒三个模型最终都做出来了能玩的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项目的验收一定要实际玩不能只看代码能不能运行。穿墙、翻滚、判定延迟这些问题全都是在真实操作里暴露出来的。代码能编译通过离能交付之间还有很长的距离。模型跑分再高都不如让玩家实际走一遍迷宫的反馈来得真实。
)
