1. 三款模型同台竞技这个对比测试到底在测什么1.1 为什么选“做一个3D游戏”作为统一考题拿三个不同的大模型去做同一件事最容易踩的坑就是“题目太水”——你让它写个冒泡排序三家都能秒出看不出差距你让它写篇散文评价标准又太主观谁都能说自己写得好。所以挑一个既有明确工程边界、又能拉开能力差距的任务是这类横向实测能不能出有效结论的前提。“做一个3D游戏”恰好卡在这个位置上。它不像纯算法题那样有唯一解也不像开放创作那样没法打分。一个能跑起来的3D小游戏至少同时压测了模型的这几层能力空间想象力3D场景里的坐标、旋转、相机朝向这些不是背模板能解决的模型得真的“在脑子里转起来”。长上下文一致性游戏逻辑往往要跨几百行代码保持变量命名、坐标系约定、状态机流转的一致性写着写着把player.position.y写成player.y这种错误就是一致性崩了。工程结构感是甩一个两千行的单文件还是合理拆成场景、实体、输入、渲染几个模块直接反映模型的架构意识。调试自省能力3D代码第一次跑几乎不可能全对模型能不能在报错后定位到是矩阵乘法顺序错了还是坐标系手性搞反了这才是真本事。我这次选的是一个第三人称视角的收集类小游戏玩家控制一个角色在平面上移动场景里散落若干可收集物碰到就计数收集完弹出胜利提示。听起来简单但它把3D的核心难点都覆盖了——相机跟随、角色朝向与移动方向解耦、碰撞检测、UI叠加。这套需求我原封不动地喂给三个模型谁行谁不行跑一遍就知道。1.2 三个选手的定位差异先摆清楚在动手之前得先说明白这三个模型各自的“人设”不然对比就失去了参照系。Step 5 Preview是这次实测的主角。从命名看它处在预览阶段通常意味着能力已经成型但还在打磨细节。这类模型的特点往往是综合能力强、指令跟随好但在一些极端工程场景下可能还有毛刺。我这次重点观察它在3D这种“需要持续保持空间一致性”的任务上表现如何。DeepSeek V4 Pro是推理向的老牌选手长链条逻辑推理是它的强项。3D游戏里那些“相机应该绕哪个轴转”“移动向量怎么投影到相机平面”的问题本质上是几何推理题理论上应该对它有利。但它有时候会“想太多”在需要快速产出可运行代码的场景里过度推理反而可能拖慢节奏。GLM5.3是另一条路线工程实用性和中文语境理解通常做得比较扎实。它在代码生成上的风格偏向“稳”不太会给你惊喜但也不太会给你惊吓。这次我想看看它在3D这种相对“硬核”的场景里稳字诀还灵不灵。提示做这类横向实测最忌讳的就是“凭印象打分”。我的做法是全程录屏加代码留档每个模型的产出都单独建目录跑通跑不通、改了几轮、每轮改了什么全部记下来。后面复盘的时候这些记录比记忆可靠得多。1.3 统一考题的具体规格说明为了保证公平我把需求写成了一份冻结的规格文档三个模型拿到的输入完全一致包括技术栈约束和验收标准。技术栈我锁定在Three.js 原生JavaScript不引入任何游戏引擎。原因很简单引擎会替模型做掉大量脏活比如物理、相机管理那样测出来的就不是模型能力而是引擎能力了。用裸的Three.js所有几何计算、矩阵变换都得模型自己写差距才明显。验收标准我列了五条硬指标页面打开后能看到一个3D场景有地面和至少一个角色模型用几何体拼即可。WASD能控制角色在平面上移动移动方向要跟相机朝向对齐。相机以第三人称视角跟随角色不能穿模、不能抖动。场景里散布至少5个收集物角色碰到后消失并计数。收集完所有物品后屏幕显示胜利文字。这五条里第2条和第3条是重灾区。移动方向跟相机对齐涉及向量投影相机跟随涉及插值和平滑这两块最能看出模型对3D数学的理解深度。我特意在规格里没有给出任何实现提示就看模型自己怎么拆解。2. 第一轮产出对比谁先跑起来谁先翻车2.1 Step 5 Preview 的首版表现Step 5 Preview 给我的第一版代码结构上是三个模型里最清爽的。它主动把代码拆成了几个逻辑块场景初始化、角色创建、输入处理、相机更新、碰撞检测、主循环每块之间用注释分隔变量命名也统一player、camera、collectibles这些关键对象从头到尾没换过名字。移动逻辑它用的是相机朝向投影法先取相机的forward向量投影到水平面并归一化再取right向量然后用WASD的输入组合出移动方向。这个思路是对的说明它理解“移动要跟视角对齐”的本质。代码大概长这样const forward new THREE.Vector3(); camera.getWorldDirection(forward); forward.y 0; forward.normalize(); const right new THREE.Vector3(); right.crossVectors(forward, new THREE.Vector3(0, 1, 0)).normalize(); const moveDir new THREE.Vector3(); 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);这段代码我一眼看过去就知道能跑。forward.y 0这一步是关键很多人会忘导致角色往天上飞。Step 5 Preview 没忘这是加分项。但它的首版也有问题。相机跟随它用的是硬跟随直接把相机位置设成角色位置加一个固定偏移没有任何插值。结果就是角色一动相机就跟着瞬移画面晃得厉害。这个问题在规格里其实隐含了“不能抖动”但模型没有主动去处理平滑说明它在“体验细节”上的敏感度还不够。2.2 DeepSeek V4 Pro 的首版表现DeepSeek V4 Pro 的首版代码推理痕迹非常重。它在注释里写了大量的推导过程比如“因为相机朝向与角色移动方向需要解耦所以这里采用世界坐标系下的投影……”这种注释在工程上其实有点啰嗦但能看出它确实在“想”。它的移动逻辑跟 Step 5 Preview 殊途同归也是投影法但实现上多了一层封装写了个getMoveDirection()函数。这个封装本身是好事但它的函数里有个小bugright向量的计算用了crossVectors(forward, up)而正确的顺序应该是crossVectors(up, forward)或者取反。结果就是按D角色往左走按A往右走方向反了。这个bug很典型。叉乘的顺序决定了结果向量的方向forward × up和up × forward差一个负号。DeepSeek V4 Pro 在推导时显然知道这个道理但落到代码上还是写反了。这说明推理能力强不等于代码细节不出错有时候想得越多反而在最后一步手滑。相机跟随它倒是做了平滑用了lerp插值但插值系数写成了0.1而且没有乘以delta。这意味着帧率越高相机跟随越快在不同刷新率的屏幕上表现不一致。这是个隐蔽的坑不跑起来对比很难发现。2.3 GLM5.3 的首版表现GLM5.3 的首版代码是三个里最“保守”的。它没有做相机朝向投影而是直接用世界坐标系控制移动W就是往-Z走S往ZA往-XD往X。这在相机固定朝向的场景下没问题但我的规格要求是第三人称跟随相机是会转的所以这个实现直接不满足第2条验收标准。不过它的其他部分做得挺稳。场景搭建、收集物生成、碰撞检测用的简单的距离判断都没问题代码风格也规整。相机跟随它用了固定偏移加lookAt没有平滑但至少没穿模。GLM5.3 的问题在于对需求的理解偏保守。它可能觉得“第三人称跟随”就是相机跟在后面没意识到“移动方向要跟相机对齐”这一层。这不是能力问题更像是它在需求解读上不够激进选择了最稳妥但不够完整的方案。2.4 首轮跑分速览验收项Step 5 PreviewDeepSeek V4 ProGLM5.3场景可运行通过通过通过移动方向对齐相机通过方向反了未实现相机跟随不抖动抖动基本平滑无平滑但不抖收集物碰撞通过通过通过胜利提示通过通过通过首版可直接运行是否需改方向是但功能不全首轮下来Step 5 Preview 是唯一一个“功能完整且基本可跑”的虽然相机抖动但至少逻辑对了。DeepSeek V4 Pro 栽在了一个符号错误上GLM5.3 则是需求理解不到位。这个结果挺有意思预览版模型反而在工程落地上最均衡。3. 逐轮迭代修bug的过程比首版更能看出功力3.1 相机平滑三种不同的修法首版跑完我把相机抖动的问题反馈给三个模型让它们各自修。这一轮最能看出它们对“平滑”这件事的理解。Step 5 Preview 的修法是引入阻尼插值用camera.position.lerp(targetPosition, 1 - Math.pow(0.001, delta))。这个公式比简单的lerp(target, 0.1)高级因为它把插值系数跟delta绑定了帧率无关。Math.pow(0.001, delta)这个写法是经典的帧率无关阻尼0.001意味着每秒衰减到千分之一手感偏快但跟手。它还在注释里解释了为什么不用固定系数说明它知道帧率无关性的重要性。DeepSeek V4 Pro 的修法更“数学”。它推导了一个临界阻尼弹簧模型用角色位置和相机当前位置算相对速度然后积分更新。代码写出来一长串效果确实好相机跟随非常顺滑但复杂度也上去了。对于一个小游戏来说这个方案有点杀鸡用牛刀而且它引入了一个velocity状态变量增加了出错面。GLM5.3 的修法最朴素就是把lerp系数从固定值改成Math.min(1, 10 * delta)。这个写法也能做到帧率无关效果中规中矩比硬跟随好比阻尼插值差一点。但它至少改对了方向。实操心得相机平滑这块我实测下来最推荐的还是1 - Math.pow(decay, delta)这种阻尼插值。decay取0.001到0.01之间数值越小跟得越紧。这个公式的好处是参数直观、帧率无关、不需要额外状态比弹簧模型省心得多。弹簧模型适合需要物理真实感的场景小游戏没必要。3.2 移动方向修正一个符号引发的连锁反应DeepSeek V4 Pro 的方向反了这个问题修起来其实就一行把crossVectors(forward, up)改成crossVectors(up, forward)。但它修完之后又冒出来一个新问题斜向移动时速度变快了。原因是它把WASD四个方向的向量直接相加后没有归一化。按WD时forward right的长度是√2所以斜着走比直着走快。这个问题在首版里其实也存在但因为方向反了我没注意到。修了方向之后才暴露出来。Step 5 Preview 的首版就有moveDir.normalize()所以没这个问题。GLM5.3 因为用的是世界坐标直接赋值也没有叠加问题。只有 DeepSeek V4 Pro 在“修一个bug引入另一个bug”的循环里多转了一圈。这件事给我的启发是3D游戏里的向量操作归一化是肌肉记忆。任何方向向量在用于位移之前只要它是多个向量叠加出来的就必须归一化。模型如果没这个意识就会在斜向移动上翻车。3.3 收集物碰撞距离判断 vs 包围盒碰撞检测这块三个模型的实现差异也值得说。Step 5 Preview 和 GLM5.3 都用了球体距离判断算角色和收集物的中心距离小于阈值就算碰到。这个方案简单有效对于收集类游戏完全够用。阈值它们都取了1.0左右考虑到角色和收集物的尺寸这个值合理。DeepSeek V4 Pro 用了AABB包围盒判断分别比较x、y、z三个轴上的距离。这个方案更精确但对于球形的收集物来说没必要而且它把y轴也纳入了判断导致角色跳起来的时候可能碰不到地上的收集物。这是个过度设计的典型例子。我后来让 DeepSeek V4 Pro 简化成距离判断它照做了但注释里还留了一句“虽然AABB更精确但距离判断在此场景下足够”。这种“我知道更好的方案但我妥协了”的态度在工程上其实是对的但放在实测里就显得有点嘴硬。3.4 迭代轮次统计模型修相机修方向修碰撞总迭代轮次最终可玩性Step 5 Preview1轮无需无需1轮高DeepSeek V4 Pro1轮2轮1轮4轮中高GLM5.31轮1轮无需2轮中Step 5 Preview 一轮就收敛这个效率是三个里最高的。DeepSeek V4 Pro 迭代最多但最终质量也上来了。GLM5.3 迭代少但它的“少”是因为首版功能就不全补功能的那一轮其实工作量不小。4. 3D游戏开发中模型最容易翻车的五个点4.1 坐标系手性搞混Three.js 用的是右手坐标系x向右、y向上、z向屏幕外。但很多模型在推导时会不自觉地用左手坐标系导致旋转方向、叉乘结果全反。DeepSeek V4 Pro 的方向反了根子上就是叉乘顺序对应的手性搞混了。判断模型有没有这个问题看它写crossVectors时的参数顺序就行。up × forward得到的是右方向forward × up得到的是左方向。这个没有捷径只能靠对坐标系的清晰记忆。4.2 相机朝向与移动方向的对齐这是第三人称游戏的核心难点。很多模型知道要“投影到水平面”但忘了归一化或者忘了处理相机俯仰角导致forward向量有y分量。Step 5 Preview 在这块做得最干净forward.y 0加normalize()两步到位。注意如果相机可以上下俯仰getWorldDirection拿到的forward向量会带y分量。直接用它做移动方向角色会往天上或地下走。必须先清零y再归一化。这个坑我见过太多人踩。4.3 帧率无关的平滑与移动所有跟时间相关的更新都必须乘以delta。移动速度要乘插值系数要跟delta绑定动画也要乘。DeepSeek V4 Pro 首版的相机插值没乘delta导致高刷屏上相机跟得太紧、低刷屏上又太松。这个问题在60Hz显示器上不明显一到144Hz就露馅。4.4 碰撞检测的维度选择3D碰撞比2D多一个维度但不是说三个维度都要用。对于地面上的收集物只判断x和z轴距离就够了y轴应该忽略或者给一个宽松的阈值。DeepSeek V4 Pro 把y轴也严格判断导致角色稍微离地就碰不到东西。这个细节说明它对“游戏手感”的考虑还不够。4.5 状态管理与主循环三个模型都用了requestAnimationFrame做主循环但状态管理上差异很大。Step 5 Preview 把keys对象、collectibles数组、score变量都放在模块顶层清晰但不够封装。DeepSeek V4 Pro 尝试用类来组织但类之间的依赖关系没理清改一处要动三处。GLM5.3 最扁平所有东西都在全局小项目能跑但扩展性差。对于这种一次性小游戏扁平结构其实够用。但如果要扩展成多关卡、多角色就得考虑状态管理了。模型在这块的架构意识普遍不如它在算法题上的表现。5. 关于 WorkBuddy 这类工具在实测流程中的角色5.1 实测流程里哪些环节可以交给工具这次实测我全程用了一个工作台工具来管理三个模型的产出类似 WorkBuddy 这类工具的核心价值在于把重复性的流程固化下来。具体来说这几个环节它帮了大忙代码留档每个模型每轮产出的代码自动按“模型名/轮次”归档不用我手动建文件夹。运行环境隔离三个模型的代码分别跑在独立的预览环境里互不干扰避免端口冲突。差异对比同一功能的不同实现可以并排看改了什么一目了然。这类工具的使用逻辑其实很简单把“每次都要手动做且容易忘”的事情交给它。比如我给自己定了几条规则——每次模型产出后自动跑一遍语法检查、每轮迭代后自动截图存档、所有对话记录按模型分类保存。这些规则设一次后面所有任务都生效省下的精力可以放在真正需要判断的地方。5.2 自定义指令怎么设才不添乱给工作台设规则最容易犯的错是“设太多”。我一开始恨不得把所有想到的规则都加上结果工具每次执行前要过一遍长长的检查清单反而变慢了。后来我精简到三条核心规则所有代码产出必须带完整文件路径方便直接落盘。每轮对话结束自动生成一份变更摘要记录改了什么、为什么改。运行报错时自动抓取控制台输出附在下一轮对话的开头。这三条覆盖了实测流程里最耗神的三个环节落盘、复盘、调试。其他的比如“自动格式化代码”“自动跑单元测试”在这个场景下优先级不高我就没加。实操心得工作台类工具的规则宁少勿多。每条规则都会增加执行开销规则太多反而拖慢节奏。我的经验是先跑一遍完整流程把“每次都要手动做”的事情记下来然后只把出现频率最高的前三条固化成规则。剩下的等真的烦了再加。5.3 缓存目录和私有化部署的取舍这类工具默认会把缓存和日志放在系统盘跑久了容易把C盘撑满。我一般会在安装后第一件事就是把缓存目录改到数据盘。具体路径在设置里找“存储”或“缓存”相关的选项改成一个空间充足的目录就行。至于私有化部署对于个人实测来说没必要。私有化部署适合团队协作或者对数据隔离有要求的场景个人用云端版足够了。部署和维护的成本远大于它带来的那点便利。6. 最终结论三个模型各自适合什么场景6.1 按任务类型选模型跑完这一轮我对三个模型的适用场景有了比较清晰的判断。Step 5 Preview适合需要快速产出可运行原型的场景。它的首版完成度最高迭代轮次最少指令跟随准确。如果你要快速验证一个想法不想在调试上耗太久它是首选。缺点是它在体验细节上还不够敏感相机抖动这种问题需要你主动提出来它才会修。DeepSeek V4 Pro适合需要深度推理和精确计算的场景。它的几何推导能力确实强弹簧阻尼相机模型这种方案另外两个模型根本想不到。但它的工程落地需要更多轮打磨符号错误、归一化遗漏这类问题会拖慢节奏。适合你不赶时间、追求最终质量的场景。GLM5.3适合需求明确、边界清晰的常规开发。它不会给你惊喜但也不会给你惊吓。代码风格稳出错率低但遇到需要“多想一层”的需求时它容易理解不到位。适合那些规格书写得很细、不需要模型自己发挥的场景。6.2 3D游戏这个考题的局限性得承认“做一个3D小游戏”这个考题有它的局限。它主要压测的是空间推理和工程一致性对模型的创意能力、叙事能力、复杂系统设计能力覆盖不足。一个模型在这个考题上表现好不代表它在所有任务上都强。而且3D游戏的代码量毕竟有限几百行而已。真正的大型项目动辄上万行跨文件、跨模块的一致性挑战要大得多。这次实测只能说明这三个模型在“中小规模3D交互程序”上的表现不能外推到所有场景。6.3 我个人的选型建议如果非要选一个日常主力我现在的倾向是Step 5 Preview 打底DeepSeek V4 Pro 补刀。具体来说用 Step 5 Preview 快速出第一版可运行代码把框架搭起来遇到需要精确几何计算或者复杂逻辑的地方把那段单独拎出来问 DeepSeek V4 Pro让它给方案再手动合进去。GLM5.3 我一般用在需求特别明确、不需要动脑的重复性代码上图它稳。这个组合不是拍脑袋定的是这一轮实测跑下来根据它们各自翻车的位置反推出来的。Step 5 Preview 翻车在体验细节DeepSeek V4 Pro 翻车在代码细节GLM5.3 翻车在需求理解。把它们的强项拼起来弱项互相补位整体效率比单用一个高不少。最后再分享一个小技巧不管用哪个模型做3D第一版跑起来之后先别急着加功能先把相机和移动的手感调顺。这两个是玩家每秒钟都在感受的东西手感不对后面加再多内容都白搭。我见过太多人一上来就堆场景、堆特效结果角色走起来像在冰上滑相机转起来像在坐过山车最后返工的成本比一开始就调好高得多。
