三大AI模型3D游戏开发实测：Step 5、DeepSeek V4 Pro、GLM5.3谁更强？

1. 三款模型同台做3D游戏我为什么选这个题最近圈子里讨论度最高的几件事一个是 Step 5 Preview 的实测表现一个是 DeepSeek V4 Pro 在代码任务上的稳定性还有一个是 GLM5.3 在长上下文和工具调用上的进步。单独测某一个模型写个贪吃蛇、做个待办清单说实话已经没什么参考价值了——这类任务早就被各家模型刷烂了。真正能拉开差距的是那种需要同时处理空间坐标、渲染循环、物理碰撞、状态机、资源加载的复合型任务而3D游戏恰好就是这么一个照妖镜。我这次做的事情很直接给三个模型同一份需求文档让它们各自从零搭一个可运行的3D小游戏然后我把三份产物都跑起来逐项对比。需求不复杂但也不放水——一个第三人称视角的收集类小游戏玩家控制角色在场景里移动收集散落的物品有计分、有计时、有简单的碰撞检测场景里要有光照和阴影镜头要跟随角色。技术栈我限定用浏览器端能直接跑的方案避免环境差异干扰对比。为什么这么设计因为3D游戏开发天然会把模型的短板暴露出来。2D任务里模型只要把逻辑写对就行但3D任务里坐标系是三维的、渲染是有帧循环的、相机和物体是分离的、光照和材质是相互影响的任何一个环节理解偏差产物要么跑不起来要么跑起来是黑屏要么角色穿墙。这些都不是靠背代码模板能糊弄过去的必须真正理解空间关系和渲染管线。这篇文章适合谁看如果你正在纠结这几个模型到底哪个适合做前端/游戏/图形类开发或者你自己想用AI辅助做一个3D小项目但不知道从哪下手那这篇实测的过程和结论应该能帮你省不少试错时间。我会把每个模型的产物结构、踩到的坑、修复思路都摊开讲不吹不黑只讲我实际跑出来的结果。提示本文所有测试都在同一台机器、同一浏览器版本下完成排除环境变量干扰。模型版本以我测试时的可用版本为准后续版本可能有变化结论仅供参考。2. 测试任务的设计为什么是第三人称收集游戏2.1 需求文档的颗粒度控制给AI写需求文档颗粒度是个技术活。写太细等于我自己把代码结构都设计好了模型只是填空测不出真实能力写太粗模型自由发挥三个产物差异太大没法横向对比。我最后定的颗粒度是说清楚要什么体验不说怎么实现。具体需求是这样的一个3D场景地面是平面上面随机散布20个可收集的金色方块。玩家用一个胶囊体代表WASD控制前后左右移动鼠标控制视角旋转。角色走到方块附近自动收集收集后方块消失右上角计分加一。场景里有一个平行光模拟太阳投射阴影。相机在角色身后上方平滑跟随。收集完所有方块弹出完成提示并显示总用时。这份需求里我刻意留了几个坑点相机跟随的平滑处理不是硬绑定要有插值、碰撞检测的触发范围不是精确碰撞是距离判定、阴影的开启方式涉及渲染器配置。这几个点最能看出模型对3D开发的理解深度。2.2 技术栈的限定逻辑我限定用 Three.js 作为渲染库原因有三。第一它是浏览器端3D开发的事实标准三个模型对它的训练数据都足够多公平。第二它把WebGL的复杂度封装得比较好模型不需要处理底层着色器能把精力放在场景逻辑上。第三它的API设计比较直观模型如果理解到位写出来的代码可读性会很高如果理解不到位错误也会很典型。构建工具我允许模型自己选可以用CDN直接引入也可以用Vite打包。这个自由度是为了观察模型的工程化意识——有的模型会直接甩一个HTML文件让你双击打开有的会搭一个完整的项目结构。两种都能跑但反映出的工程思维不一样。2.3 评判标准的设定我不只看能不能跑。跑起来只是及格线我按四个维度打分首次运行成功率不做任何修改直接跑、代码结构合理性模块划分、命名、注释、3D特性实现完整度光照、阴影、相机、碰撞是否都到位、可扩展性想加个新功能好不好改。这四个维度基本覆盖了一个3D项目从能用到好用的全过程。3. Step 5 Preview 的产物结构最完整但有个隐蔽的坐标坑3.1 项目结构和首次运行表现Step 5 Preview 给我的第一印象是工程感很强。它没有甩一个单文件HTML而是搭了一个标准的Vite项目结构index.html、src/main.js、src/scene.js、src/player.js、src/collectibles.js还配了package.json和vite.config.js。模块划分清晰每个文件职责单一scene.js管场景和光照player.js管角色和输入collectibles.js管收集物生成和判定。我按它给的步骤npm install npm run dev一次就跑起来了。场景渲染正常光照和阴影都在角色能移动方块能收集计分正常。首次运行成功率这一项Step 5 Preview 直接满分。但跑起来之后我发现了问题角色的移动方向和相机视角是脱节的。我按W角色往世界坐标的Z轴负方向走但我如果先把鼠标转到侧面再按W角色还是往原来的方向走而不是往我面朝的方向走。这在第三人称游戏里是致命的——玩家的直觉是W就是往前走而不是W就是往北走。3.2 坐标转换的根因分析这个问题的根因在于输入方向没有经过相机空间的转换。在第三人称游戏里玩家的输入是相对于相机的按W应该是沿着相机朝向的前方移动。正确做法是取出相机的朝向向量投影到水平面归一化然后作为移动的基准方向。Step 5 Preview 的代码里移动逻辑直接用了世界坐标的固定向量// Step 5 Preview 的原始写法简化 const moveDirection new THREE.Vector3(); if (keys.w) moveDirection.z - 1; if (keys.s) moveDirection.z 1; if (keys.a) moveDirection.x - 1; if (keys.d) moveDirection.x 1;这段代码逻辑上没错但它假设相机永远在角色正后方且朝向固定。一旦相机旋转输入方向就和视觉方向对不上了。修复方法也不复杂用相机的朝向向量来构造移动基准// 修复后的写法 const cameraForward new THREE.Vector3(); camera.getWorldDirection(cameraForward); cameraForward.y 0; cameraForward.normalize(); const cameraRight new THREE.Vector3(); cameraRight.crossVectors(cameraForward, new THREE.Vector3(0, 1, 0)).normalize(); const moveDirection new THREE.Vector3(); if (keys.w) moveDirection.add(cameraForward); if (keys.s) moveDirection.sub(cameraForward); if (keys.d) moveDirection.add(cameraRight); if (keys.a) moveDirection.sub(cameraRight); moveDirection.normalize();改完之后移动就跟手了。这个坑很典型——模型知道要处理输入但没意识到输入是相对于相机的。这说明它对第三人称游戏的空间关系理解还停留在能跑就行的层面没有真正站在玩家视角思考。3.3 相机平滑跟随的实现质量相机跟随这块Step 5 Preview 做得不错。它用了插值lerp来实现平滑而不是硬绑定。代码里能看到它每帧计算目标位置然后用一个系数向目标位置逼近const targetPosition player.position.clone().add(cameraOffset); camera.position.lerp(targetPosition, 0.1); camera.lookAt(player.position);这个0.1的系数是经验值太小会跟得慢有延迟感太大就失去平滑意义。Step 5 Preview 选0.1实测下来跟随手感比较自然没有明显的拖影也没有生硬感。这一点说明它对平滑这个概念是有理解的不是随便填个数。3.4 阴影和光照的配置细节光照部分Step 5 Preview 配了一个DirectionalLight加一个AmbientLight平行光开了castShadow地面开了receiveShadow方块开了castShadow。阴影贴图的尺寸设了2048这个值在保证质量的同时不会太吃性能是个合理的默认值。它还顺手配了shadow.camera的边界范围避免了阴影边缘裁剪的问题——这个细节很多模型会漏漏了之后阴影只在一小块区域显示远处就没有了。整体来看Step 5 Preview 的产物是三个里工程完成度最高的结构清晰、注释到位、首次运行无障碍。唯一的硬伤就是那个坐标转换的坑但修复成本很低改十几行代码就解决了。4. DeepSeek V4 Pro 的产物逻辑最扎实但工程结构偏简陋4.1 单文件方案的两面性DeepSeek V4 Pro 走的是另一条路一个单文件HTMLThree.js 用CDN引入所有逻辑写在一个script标签里。这种方案的好处是零配置、双击即开对新手极其友好坏处是代码一长就难维护而且没有模块化想扩展功能得在几百行里找位置。我数了一下它的单文件大概四百多行逻辑分块还算清楚用注释隔开了场景初始化玩家控制收集物游戏循环几个区域。虽然没有物理分文件但阅读起来不费劲。这说明 DeepSeek V4 Pro 在代码组织上有意识只是选择了更轻量的表达方式。4.2 移动逻辑的正确处理让我意外的是DeepSeek V4 Pro 的移动逻辑直接就是对的。它没有踩 Step 5 Preview 那个坐标坑而是从一开始就用相机朝向作为移动基准。代码里能看到它先取相机的前向和右向再根据按键组合出移动向量// DeepSeek V4 Pro 的写法 const forward new THREE.Vector3(); camera.getWorldDirection(forward); forward.y 0; forward.normalize(); const right new THREE.Vector3().crossVectors(forward, up).normalize(); const move new THREE.Vector3(); if (keys[w]) move.add(forward); if (keys[s]) move.sub(forward); if (keys[a]) move.sub(right); if (keys[d]) move.add(right);这段代码和我在3.2节给出的修复方案几乎一致。说明 DeepSeek V4 Pro 对第三人称游戏的空间关系理解是到位的它知道输入必须经过相机空间转换。这一点上它比 Step 5 Preview 更靠谱。4.3 碰撞检测的实现方式收集判定这块DeepSeek V4 Pro 用的是距离检测每帧遍历所有方块算角色和方块的距离小于阈值就判定收集。这是最直接的做法性能上对于20个方块完全够用。它把阈值设成了1.2考虑到角色胶囊体半径和方块尺寸这个值实测下来手感合适——不会隔老远就吸走也不会贴着还收不到。有个小细节值得说它在收集后没有直接remove方块而是先把方块标记为collected然后在渲染循环里跳过已收集的方块。这样做的好处是避免了在遍历过程中修改数组导致的索引错乱。虽然Three.js的remove本身是安全的但这个习惯说明它对遍历时修改集合这类经典陷阱有防范意识。4.4 缺失的阴影配置DeepSeek V4 Pro 的产物有一个明显短板阴影没开全。它配了平行光但忘了设castShadow地面也没设receiveShadow。结果就是场景有光照但没有投影方块和角色都是飘在地上的缺乏立体感。这不是逻辑错误是配置遗漏补上三行代码就能解决directionalLight.castShadow true; ground.receiveShadow true; box.castShadow true;这个遗漏反映出一个问题DeepSeek V4 Pro 在逻辑正确性上很强但在视觉完整性上不够细致。它把游戏能玩这件事做对了但好看这件事没顾上。对于3D项目来说视觉表现是体验的一半这个短板不能忽视。4.5 代码可读性和注释质量DeepSeek V4 Pro 的注释写得比较克制关键逻辑处有说明但不啰嗦。比如相机跟随那段它注释了使用lerp实现平滑跟随系数0.08控制跟随速度把意图和参数含义都点到了。这种注释风格我个人比较喜欢——不解释显而易见的代码只解释为什么这么选。5. GLM5.3 的产物功能最全但有个运行时的性能隐患5.1 功能覆盖度最高GLM5.3 的产物是三个里功能最全的。除了基础需求它还额外加了几个东西角色移动时的朝向旋转角色会面朝移动方向、收集时的缩放动画方块被收集时先放大再消失、计时器的格式化显示显示成分:秒而不是纯秒数。这些都不是我要求的是它自己加的。从产品思维角度看这些补充让体验更完整。项目结构上GLM5.3 用的是半模块化——一个HTML文件加一个单独的game.js逻辑量大的部分拆出去了但没到Vite项目的程度。这个折中方案对于中小型3D项目其实挺实用既不用配构建工具又不会让单文件膨胀到难以维护。5.2 性能隐患每帧创建对象跑起来之后我打开性能面板看了一眼发现帧率比另外两个低一些而且GC垃圾回收活动频繁。排查下来问题出在渲染循环里每帧都在创建新的Vector3对象// GLM5.3 的问题写法 function animate() { const direction new THREE.Vector3(); // 每帧新建 const cameraPos new THREE.Vector3(); // 每帧新建 // ... 使用这些对象 }在60帧的循环里每秒创建上百个临时对象虽然现代JS引擎的GC能处理但会造成周期性的卡顿。正确做法是把这些向量提到循环外面复用同一个对象// 修复后 const direction new THREE.Vector3(); const cameraPos new THREE.Vector3(); function animate() { direction.set(0, 0, 0); // 复用重置 // ... 使用 }这个坑很典型——模型知道要用向量计算但没意识到渲染循环是高频执行的对象创建要克制。这是从能跑到跑得稳之间的差距也是很多AI生成代码的通病。5.3 角色朝向旋转的实现角色朝向这块GLM5.3 处理得不错。它用Math.atan2根据移动方向算出目标角度然后用角度插值让角色平滑转向而不是瞬间翻转。代码里能看到它对角度做了归一化处理避免了从359度转到1度时绕远路的问题。这个细节说明它对角度运算的边界情况有考虑。const targetAngle Math.atan2(moveDirection.x, moveDirection.z); // 角度插值处理跨0度的情况 let angleDiff targetAngle - currentAngle; while (angleDiff Math.PI) angleDiff - Math.PI * 2; while (angleDiff -Math.PI) angleDiff Math.PI * 2; currentAngle angleDiff * 0.15;这段代码是三个产物里唯一正确处理了角度环绕问题的。Step 5 Preview 和 DeepSeek V4 Pro 都没做角色转向所以没暴露这个问题但如果要加GLM5.3 的写法可以直接抄。5.4 收集动画的取舍收集动画这块GLM5.3 用了一个简单的缩放透明度渐变。实现上它没有引入动画库而是手动在渲染循环里根据时间戳算缩放系数。这个做法轻量但有个小问题动画期间方块还在参与碰撞检测理论上玩家可能在动画播放时重复触发收集。虽然它用了一个isCollecting标志位来防重但标志位的清理时机和动画结束时机是分开的极端情况下可能不同步。更稳妥的做法是把方块从可收集列表里移除动画单独用一个列表管理。不过对于这个规模的项目GLM5.3 的处理已经够用了属于知道有风险但影响可控的取舍。6. 三个产物的横向对比一张表看清差异6.1 核心维度对比对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3项目结构Vite多文件模块化单文件HTMLHTML独立JS首次运行一次成功一次成功一次成功移动逻辑有坐标坑需修复直接正确直接正确相机跟随lerp平滑系数合理lerp平滑系数合理lerp平滑系数合理阴影配置完整缺失需补完整碰撞检测距离判定距离判定防重距离判定防重额外功能无无角色转向收集动画计时格式化性能表现稳定稳定有GC压力代码可读性高注释到位中注释克制中高注释适中6.2 各自的能力画像从这张表能看出三个模型的能力侧重明显不同。Step 5 Preview 是工程派它擅长搭结构、配环境、写规范代码产物最接近一个真实项目的雏形但在具体的游戏逻辑细节上会犯一些想当然的错误。DeepSeek V4 Pro 是逻辑派它对空间关系、算法正确性的把握最准核心逻辑几乎不用改但工程化和视觉细节上偏保守属于能跑就行的风格。GLM5.3 是产品派它最懂用户想要什么体验会主动加功能、做动画、优化显示但性能意识稍弱需要人工把关。6.3 修复成本对比如果以能直接用于生产为标准三个产物的修复成本大概是Step 5 Preview 改十几行坐标转换代码DeepSeek V4 Pro 补三行阴影配置GLM5.3 把渲染循环里的对象创建提到外面。三个的修复量都不大但问题的性质不同——Step 5 Preview 是逻辑理解偏差DeepSeek V4 Pro 是配置遗漏GLM5.3 是性能习惯问题。从修复后代码质量看Step 5 Preview 的底子最好因为它的结构最规范后续扩展最省心。7. 实测中踩到的共性坑和修复思路7.1 坐标系混乱世界坐标 vs 局部坐标三个模型都不同程度地在坐标系上栽过跟头。最典型的是把世界坐标当成局部坐标用。比如给方块设位置时如果方块是某个父对象的子节点position.set(1, 0, 1)设的是相对于父节点的局部坐标不是世界坐标。Step 5 Preview 在生成收集物时把方块直接加到了场景根节点所以没暴露这个问题但如果它把方块加到一个旋转过的容器里位置就会全乱。修复思路很简单明确每个对象的父节点是谁位置是相对谁的。如果拿不准用getWorldPosition()取世界坐标用worldToLocal()做转换。这个坑在2D项目里不明显因为2D的层级通常很浅但3D项目里嵌套层级一多就容易出问题。7.2 渲染循环里的对象创建前面提过GLM5.3的GC问题其实Step 5 Preview 和 DeepSeek V4 Pro 也有类似倾向只是没GLM5.3那么频繁。渲染循环是每秒执行60次的高频代码里面任何new操作都要警惕。我的经验是能在循环外创建的绝不在循环内创建必须动态创建的用对象池复用。具体到Three.js常用的Vector3、Quaternion、Matrix4都应该提前创建好在循环里用.set()、.copy()、.add()这些方法复用。这个习惯养成之后帧率会稳定很多尤其是在低端设备上。7.3 阴影不显示的三类原因阴影不显示是3D项目的高频问题三个模型里有两个踩过。总结下来无非三类原因光源没开castShadow、物体没开castShadow或receiveShadow、阴影相机的范围没覆盖到物体。排查顺序就按这个来先看光源再看物体最后看阴影相机边界。阴影相机这块特别容易被忽略。平行光的阴影相机是个正交相机默认范围可能只有几十个单位如果场景很大远处的物体就不在阴影范围内自然没有阴影。解决办法是调整shadow.camera.left/right/top/bottom让它覆盖整个场景。7.4 相机跟随的抖动问题相机跟随如果处理不好会出现抖动。常见原因是相机位置和角色位置在同一帧里更新但更新顺序不对。正确顺序是先更新角色位置再更新相机位置最后渲染。如果反过来相机会基于上一帧的角色位置计算产生一帧的延迟快速移动时就会抖。另一个抖动来源是lerp系数和帧率不匹配。如果游戏跑在120Hz的屏幕上同样的lerp系数会让相机跟得更快手感就和60Hz不一样。严谨的做法是把系数乘以deltaTime做帧率补偿但大多数小项目直接用固定系数也能接受。8. 从这次实测里我总结的选型建议8.1 按项目类型选模型如果你要做的是一个需要长期维护、会不断加功能的3D项目我建议优先考虑 Step 5 Preview 的产物作为起点。它的模块化结构让后续扩展最省力加个新角色、新道具、新关卡都能找到对应的文件去改不会牵一发动全身。那个坐标坑改一次就永久解决了不影响后续。如果你要做的是快速验证一个玩法原型DeepSeek V4 Pro 的单文件方案最合适。双击就能跑改起来也直观适合头脑风暴阶段。等玩法验证通过了再考虑重构成模块化项目。如果你要做的是面向用户的成品小游戏GLM5.3 的产物最接近可交付状态它的额外功能省了你不少事。但上线前一定要做性能优化把渲染循环里的对象创建清理一遍否则在低端手机上会卡。8.2 给AI写3D项目需求的技巧这次实测让我对怎么给AI写3D需求有了新认识。坐标系的约定一定要写清楚——是Y轴向上还是Z轴向上相机是透视还是正交移动是相对世界还是相对相机。这些不写清楚模型就会按自己的默认理解来结果可能和你的预期不符。渲染相关的配置要单独列出来——阴影开不开、用什么光照、需不需要后处理。这些配置项模型很容易漏列出来能显著提高首次运行的成功率。性能约束要提前说——目标帧率是多少、运行在什么设备上、场景规模大概多大。说了之后模型会有意识地避免高频对象创建产物质量会高一截。8.3 人工把关的重点不管用哪个模型AI生成的3D代码都需要人工过一遍。我自己的检查清单是先跑起来看有没有黑屏再动一动看操作跟不跟手然后看阴影和光照对不对最后开性能面板看帧率稳不稳。这四步走完基本能覆盖80%的问题。特别要盯的是渲染循环这是3D项目的心脏也是AI最容易写出性能问题的地方。循环里每多一个new每多一次console.log都会在长时间运行后累积成卡顿。养成循环内零分配的习惯产物质量会有质的提升。注意AI生成的3D代码在数学计算上通常没问题但在空间直觉上经常出偏差。移动方向、相机朝向、物体旋转这些涉及空间关系的逻辑一定要亲手测一遍不要只看代码觉得对就放过。9. 几个可以直接抄的实用代码片段9.1 相机空间移动通用这段代码适配任何第三人称3D项目直接抄const forward new THREE.Vector3(); const right new THREE.Vector3(); const moveDir new THREE.Vector3(); const UP new THREE.Vector3(0, 1, 0); function updateMovement(delta) { camera.getWorldDirection(forward); forward.y 0; forward.normalize(); right.crossVectors(forward, UP).normalize(); moveDir.set(0, 0, 0); if (keys.w) moveDir.add(forward); if (keys.s) moveDir.sub(forward); if (keys.d) moveDir.add(right); if (keys.a) moveDir.sub(right); if (moveDir.lengthSq() 0) { moveDir.normalize(); player.position.addScaledVector(moveDir, speed * delta); } }注意这里用了delta做帧率补偿移动速度不会因为帧率变化而改变。addScaledVector比先乘再加更简洁也少一次临时对象创建。9.2 平滑相机跟随带帧率补偿const cameraTarget new THREE.Vector3(); const cameraOffset new THREE.Vector3(0, 5, 8); function updateCamera(delta) { cameraTarget.copy(player.position).add(cameraOffset); const t 1 - Math.pow(0.001, delta); // 帧率无关的插值系数 camera.position.lerp(cameraTarget, t); camera.lookAt(player.position); }这里的1 - Math.pow(0.001, delta)是个技巧它让插值速度在不同帧率下保持一致。0.001是每秒衰减到千分之一的意思数值越小跟随越快。这个写法比固定系数更专业值得记住。9.3 距离碰撞检测带防重const collectDistance 1.2; const tempVec new THREE.Vector3(); function checkCollectibles() { for (let i collectibles.length - 1; i 0; i--) { const item collectibles[i]; if (item.userData.collected) continue; tempVec.copy(item.position).sub(player.position); if (tempVec.lengthSq() collectDistance * collectDistance) { item.userData.collected true; score; // 触发收集动画动画结束后再真正移除 playCollectAnimation(item, () { scene.remove(item); collectibles.splice(i, 1); }); } } }用lengthSq()代替length()省一次开方运算虽然对20个物体来说无所谓但习惯养成了对大规模场景有好处。倒序遍历是为了在splice时不影响未处理的索引。10. 最后聊几句实际用下来的感受这三个模型我都用了一段时间最大的感受是它们不是互相替代的关系而是各有各的适用场景。Step 5 Preview 适合打地基DeepSeek V4 Pro 适合攻逻辑难点GLM5.3 适合做体验优化。真要做项目完全可以先用 Step 5 Preview 搭结构遇到核心算法让 DeepSeek V4 Pro 把关最后用 GLM5.3 补交互细节。这种组合拳打法比死磕一个模型效率高得多。另外提醒一句3D项目的调试成本比2D高很多因为问题往往不是报错而是看起来不对。角色穿墙、阴影错位、相机抖动这些都不会抛异常只能靠肉眼观察和逻辑推理。所以用AI生成3D代码时一定要把测试环节做扎实每个功能都亲手操作验证不要因为代码看起来对就跳过测试。我这次实测里发现的几个坑全都是跑起来之后才暴露的光看代码根本看不出来。如果你也在用这几个模型做3D相关的东西欢迎交流你踩到的坑。这个领域变化太快今天的最佳实践可能下个月就过时了保持实测、保持记录比什么都重要。