1. 三个模型同台做3D游戏我为什么选这个题最近圈子里讨论度最高的一件事就是几个主流代码大模型在同一类任务上的横向对比。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字频繁出现在各种实测帖里但大多数对比都停留在写个贪吃蛇做个待办清单这种二维层面。二维任务有个问题逻辑分支有限UI 布局套路化模型之间的差距很容易被能跑就行掩盖过去。3D 游戏不一样。它同时压测模型的空间数学能力、渲染管线理解、状态管理、资源组织、性能取舍甚至包括对物理引擎 API 的准确记忆。一个向量叉乘写反了整个相机就是黑的四元数顺序搞错了角色会像陀螺一样乱转。这些错误在二维任务里根本不会暴露。所以我把同一个需求——做一个可玩的 3D 小游戏——分别丢给这三个模型记录它们从零到可运行的全过程。这篇文章不是跑分榜而是把每个模型在真实工程场景下的表现、踩到的坑、以及我作为使用者需要补位的部分完整摊开讲。如果你正在纠结用哪个模型做图形类项目或者想了解 3D 游戏开发里哪些环节最容易被模型搞砸这篇应该能帮你省下不少试错时间。需要先说明三个模型我用的都是各自较新的版本提示词尽量保持一致测试环境统一在一台普通开发机上浏览器用 Chromium 内核。所有代码最终都跑在 Web 端技术栈锁定 Three.js因为它是目前生态最成熟、模型训练语料最丰富的 Web 3D 库对三个模型来说起跑线相对公平。2. 测试任务的设计为什么是3D 收集类小游戏2.1 任务规格的刻意约束我没有让模型自由发挥而是给了一个明确到近乎苛刻的规格。原因很简单开放式需求下模型会各自选择不同的技术路线最后根本没法比。约束条件如下场景一个封闭的方形平台四周有围栏防止角色掉出去角色一个胶囊体WASD 控制移动空格跳跃鼠标拖拽旋转视角目标物随机生成 10 个旋转的金色方块碰到即收集计数加一反馈收集全部后屏幕中央显示完成并给出用时相机第三人称跟随带平滑插值物理需要重力、地面碰撞、跳跃落地检测这个规格覆盖了 3D 游戏的核心闭环输入、相机、物理、碰撞、状态、UI。任何一个环节出问题游戏都玩不起来。2.2 为什么锁定 Three.js 而不是原生 WebGL有人会问为什么不直接测原生 WebGL 或者更底层的方案。我的判断是原生 WebGL 的样板代码太多模型很容易在着色器编译、缓冲区绑定这些地方翻车最后测出来的差异其实是谁更会抄模板而不是谁更懂 3D。Three.js 把渲染管线封装好了模型只需要处理场景图和游戏逻辑这样对比的才是真正的空间思维和工程组织能力。另外Three.js 的 API 在训练语料里出现频率极高三个模型对它都不陌生这保证了测试的公平性。如果换成某个冷门引擎可能三个模型都写不对那就失去对比意义了。2.3 评分维度怎么定我没有用单一的能不能跑来打分而是拆成五个维度每个维度都有明确的观察点维度观察点权重首次可运行率复制代码后能否直接跑起来高空间数学正确性向量、四元数、相机朝向是否正确高物理与碰撞重力、跳跃、落地、收集判定是否合理高代码组织模块划分、状态管理是否清晰中交互手感移动速度、相机平滑、跳跃力度是否舒适中权重不是拍脑袋定的。首次可运行率排最高是因为对大多数使用者来说改一个跑不起来的项目比从零写还累。空间数学和物理并列是因为这两个是 3D 的命门错了就是黑屏或穿模。代码组织和交互手感属于锦上添花但决定了这个项目能不能继续迭代。3. Step 5 Preview 的首轮输出结构最完整但有个隐蔽的数学错误3.1 它一次给全了所有模块Step 5 Preview 的第一轮输出让我有点意外。它没有像很多模型那样只给一个 HTML 文件塞满所有代码而是主动拆成了几个模块场景初始化、角色控制、相机跟随、收集物管理、UI 层。虽然最终我还是把它们合并到一个文件里方便测试但这个组织意识说明它对工程结构有概念。它给出的技术选型也很合理用CapsuleGeometry做角色用Raycaster做地面检测用Vector3做移动方向计算。这些都是 Three.js 里的标准做法没有剑走偏锋。3.2 相机跟随里的四元数陷阱问题出在相机跟随。Step 5 Preview 用了一种相机始终看向角色的实现代码大致是这样的逻辑每帧计算相机到角色的方向向量然后用lookAt让相机朝向角色。听起来没问题但它同时又在鼠标拖拽时直接修改相机的rotation。这两套逻辑打架了。具体表现是鼠标拖拽旋转视角时相机会先转过去然后下一帧lookAt又把它拽回来导致视角抖动严重时相机直接翻转。这个 bug 很隐蔽因为静态看代码逻辑是通的只有实际拖拽才会暴露。我判断它犯这个错的原因是它把相机朝向和相机位置两个概念混在一起处理了。正确的做法应该是鼠标控制的是相机相对于角色的球面坐标方位角 俯仰角相机位置由这个球面坐标算出来然后lookAt角色。这样旋转和跟随就是同一套逻辑不会打架。修复其实不难我把它那段相机代码换成了球面坐标方案// 球面坐标控制相机 let theta 0; // 水平角 let phi Math.PI / 3; // 俯仰角 const radius 8; function updateCamera() { const target player.position.clone().add(new THREE.Vector3(0, 1, 0)); const offset new THREE.Vector3( radius * Math.sin(phi) * Math.sin(theta), radius * Math.cos(phi), radius * Math.sin(phi) * Math.cos(theta) ); camera.position.copy(target).add(offset); camera.lookAt(target); }改完之后视角就稳了。这个坑值得单独记一笔凡是相机同时要跟随又要被鼠标控制的场景一定要用球面坐标统一管理不要让两套旋转逻辑并存。3.3 物理部分它偷了懒Step 5 Preview 的跳跃实现是直接给 Y 轴速度赋值然后每帧减一个固定值模拟重力。这在简单场景下能用但它没有做落地检测的边界处理。角色落地后速度没有清零导致会有一帧的抖动而且如果帧率波动跳跃高度会不一致。我补了一个简单的速度归零和地面吸附逻辑if (player.position.y groundY) { player.position.y groundY; velocityY 0; isGrounded true; }这个补充不算复杂但说明 Step 5 Preview 在物理细节上偏向能跑就行需要使用者自己补边界条件。4. DeepSeek V4 Pro 的表现数学最稳但代码组织偏散4.1 空间数学几乎零错误DeepSeek V4 Pro 在空间数学上的表现是三个里最扎实的。它的移动方向计算直接用了相机的前向量和右向量做叉乘没有出现轴向搞反的问题。角色移动时按 W 永远是朝着屏幕里走按 A 永远是往左这个直觉正确性其实很多模型做不到。它的相机方案一开始就用了球面坐标没有踩 Step 5 Preview 那个坑。跳跃物理也做了落地检测和速度清零甚至加了简单的摩擦衰减。从纯技术正确性看它的首轮输出质量最高。4.2 但它的代码是一整坨问题在于组织。DeepSeek V4 Pro 把所有逻辑塞进了一个巨大的animate函数里输入处理、物理更新、碰撞检测、UI 刷新全混在一起。功能是通的但你想改任何一个环节都得在几百行里翻找。我实测下来这种写法在项目初期没问题但一旦要加新功能——比如加个敌人、加个计时器——就会非常痛苦。我后来手动把它拆成了几个更新函数function updateInput() { /* 处理键盘鼠标 */ } function updatePhysics() { /* 重力、碰撞 */ } function updateCollectibles() { /* 旋转、收集判定 */ } function updateUI() { /* 计数、计时 */ } function animate() { requestAnimationFrame(animate); updateInput(); updatePhysics(); updateCollectibles(); updateUI(); renderer.render(scene, camera); }拆完之后逻辑清晰多了。这说明 DeepSeek V4 Pro 是技术强但工程习惯一般的类型适合你已经有架构思路、只需要它帮你实现具体算法。4.3 收集判定它用了距离检测DeepSeek V4 Pro 判断角色是否碰到收集物用的是两个物体中心点的距离小于某个阈值。这个方案简单有效但有个小问题如果收集物做大一点或者角色移动速度快一点可能会穿过去而没触发。更稳妥的做法是用包围盒相交检测或者做连续碰撞检测。不过对于这个规格的小游戏距离检测够用了。我提这一点是想说明模型给的方案往往是够用而不是最优你得知道它的边界在哪什么时候需要升级方案。5. GLM5.3 的路线交互手感最好但首轮跑不起来5.1 它在手感调校上有想法GLM5.3 的输出有个明显特点它在移动速度、跳跃力度、相机平滑这些手感参数上花了心思。它给移动加了一个加速度和减速度的过渡而不是瞬间启停角色动起来更顺滑。相机跟随也做了插值不会硬邦邦地贴着角色。这些细节说明 GLM5.3 对游戏体验有感知不只是把功能堆出来。如果你做的是需要手感的产品这一点很加分。5.2 但它首轮代码有引用错误可惜的是GLM5.3 的首轮代码跑不起来。问题出在它引用了一个没有定义的变量——它在相机更新函数里用了一个cameraTarget但这个变量在初始化部分根本没声明。这种错误属于典型的生成时上下文丢失模型写着写着忘了前面有没有定义。我补上声明之后就能跑了。但这个体验提醒我GLM5.3 的输出需要更仔细地过一遍变量引用尤其是跨函数使用的变量。它不像 DeepSeek V4 Pro 那样数学严谨也不像 Step 5 Preview 那样结构完整它的优势在体验层但基础层需要你把关。5.3 它的收集反馈做得最细跑起来之后我发现GLM5.3 在收集反馈上做得最细。收集物被碰到时它会做一个缩放消失的动画而不是瞬间消失。UI 计数也有一个数字跳动的效果。这些都不影响功能但让游戏感觉更完整。这让我重新思考评分维度如果只看能不能跑GLM5.3 首轮是失败的但如果看跑起来之后的体验它反而是最好的。所以模型选型真的要看你的优先级——是要快速拿到能跑的骨架还是要一个体验打磨过的半成品。6. 三个模型的横向对比一张表看清差异把三个模型的表现整理成表差异就很直观了对比项Step 5 PreviewDeepSeek V4 ProGLM5.3首次可运行可运行相机有bug可运行需修改变量后运行空间数学相机逻辑有冲突几乎零错误基本正确物理细节落地处理偷懒较完整较完整代码组织模块化意识强单函数堆砌中等交互手感一般一般最好主要短板相机双逻辑打架代码结构散变量引用错误从这张表能看出一个规律三个模型各有所长没有全能选手。Step 5 Preview 强在结构DeepSeek V4 Pro 强在数学GLM5.3 强在体验。你选哪个取决于你项目里最不能妥协的是什么。如果你的项目对正确性要求极高比如涉及复杂物理或精密空间计算DeepSeek V4 Pro 的数学稳定性最省心。如果你要快速搭一个可扩展的骨架Step 5 Preview 的组织方式更好接手。如果你做的是面向用户的体验型产品GLM5.3 的手感调校能帮你省下不少打磨时间。7. 实测中暴露的共性问题与我的补位经验7.1 三个模型都不擅长帧率无关的物理这是最值得说的一点。三个模型的物理更新都是直接按帧减速度没有乘以 deltaTime。这意味着在 144Hz 屏幕上角色跳跃高度会比 60Hz 屏幕上低因为帧数多了每帧减的速度累积起来更快。正确做法是把所有物理量都乘以帧间隔const delta clock.getDelta(); velocityY - gravity * delta; player.position.y velocityY * delta;这个坑在二维游戏里也存在但 3D 里因为相机和物理耦合更紧表现更明显。我实测下来三个模型都需要手动补这个 deltaTime。这不是模型能力问题而是训练语料里大量示例代码本身就是简化版模型学到了这些简化写法。7.2 收集物的旋转它们都用了欧拉角三个模型让收集物旋转用的都是rotation.y speed这种欧拉角累加。对于单个轴旋转没问题但如果以后要加多轴旋转或者朝向某个目标欧拉角会出现万向节死锁。更稳妥的是用四元数或者rotateOnAxis。不过对于这个规格欧拉角够用。我提这一点是想说模型倾向于用最简单能实现的方案你得知道什么时候该升级。如果收集物只是原地转欧拉角没问题如果它要追踪玩家或者做复杂运动就得换方案。7.3 输入处理都没做按键状态管理三个模型的键盘输入都是监听keydown和keyup事件用一个对象记录按键状态。这个方案本身没问题但它们都没有处理窗口失焦的情况。如果你按着 W 键切到别的窗口再切回来角色会一直往前走因为keyup事件没触发。修复方法是监听blur事件清空所有按键状态window.addEventListener(blur, () { keys {}; });这个细节很小但实际使用中很影响体验。三个模型都没主动加需要使用者自己补。7.4 我的补位清单基于这次实测我整理了一份模型输出后必查清单不管你用哪个模型这几项都建议过一遍相机是否有双重旋转逻辑跟随 鼠标控制是否打架物理更新是否乘以 deltaTime落地检测是否做了速度清零和位置吸附窗口失焦时按键状态是否清理收集判定是否考虑了高速穿透变量引用是否完整尤其跨函数使用的这份清单帮我省了很多调试时间。模型能给你 80% 的骨架剩下 20% 的边界处理才是决定项目能不能真正跑起来的关键。8. 如果让我重新做一次我会怎么组织提示词8.1 把约束写进提示词而不是事后修这次实测最大的收获是模型的输出质量很大程度上取决于你提示词里的约束密度。我第一轮给的提示词只描述了功能没有描述技术约束所以三个模型都用了各自的默认写法导致我需要事后补 deltaTime、补失焦处理。如果重来一次我会在提示词里直接写明所有物理更新必须乘以 deltaTime相机使用球面坐标统一管理不要混用 lookAt 和直接改 rotation监听 window blur 事件清空按键状态收集判定使用包围盒而非中心点距离把这些写进去模型的首轮输出质量会高很多。这不是模型变强了而是你帮它排除了它容易犯的错。8.2 分阶段要代码而不是一次要全另一个经验是一次性要完整项目模型容易在后期丢失上下文出现变量未定义这类错误。更好的做法是分阶段先要场景和相机跑通后再要角色控制再要物理最后要收集和 UI。每个阶段都验证通过再进入下一阶段。这样虽然交互轮次多了但每轮的输出都更可靠调试成本反而更低。GLM5.3 那个变量未定义的错误如果分阶段要很可能就不会出现。8.3 让模型解释它的选择我还会加一条让模型在给代码的同时说明关键选择的原因。比如为什么相机用球面坐标为什么物理要乘 deltaTime。这样你能快速判断它的方案是否合理而不是等跑起来才发现问题。模型解释得清楚说明它真的理解解释得含糊往往就是它抄了个模板但没想明白。9. 关于 WorkBuddy 这类工具在 3D 项目里的实际用法热词里出现了不少 WorkBuddy 相关的搜索我顺带说说这类工具在 3D 游戏开发里的定位。WorkBuddy 本质上是一个任务编排和工作流管理工具它不直接写 3D 代码但可以帮你把模型生成、代码验证、问题记录这几步串起来。我的用法是这样的把 3D 游戏的开发拆成若干任务卡每张卡对应一个模块场景、相机、物理、收集、UI每张卡里记录提示词、模型输出、验证结果、修复记录。这样当你要换模型重做某个模块时历史记录都在不用从头回忆。WorkBuddy 的自定义指令功能在这里特别有用。你可以给它定几条规则比如所有代码输出必须包含 deltaTime 处理相机相关代码必须说明旋转方案然后这些规则对所有任务生效。这相当于把你的补位经验固化成了流程下次不管用哪个模型输出都会自动带上这些约束。至于 WorkBuddy 的安装、缓存目录修改、私有化部署这些操作层面的问题属于工具本身的配置和 3D 开发关系不大这里就不展开了。核心思路是把模型当成生产力把 WorkBuddy 这类工具当成生产流程的管理层两者配合才能稳定产出。10. 最后分享几个我踩出来的实操技巧第一个技巧测试 3D 代码时先把相机固定住。相机是 3D 项目里最容易出问题的部分如果相机在动你很难判断是角色移动错了还是相机跟错了。我的做法是先把相机写死在一个固定位置验证角色移动和物理正确后再打开相机跟随。这样能把问题隔离调试效率高很多。第二个技巧用坐标轴辅助对象定位问题。Three.js 有AxesHelper加一行scene.add(new THREE.AxesHelper(5))就能看到红绿蓝三个轴。当角色移动方向不对时看一眼轴就知道是哪个方向反了。这个比盯着代码猜快得多。第三个技巧收集物的判定阈值要略大于视觉尺寸。模型给的距离检测阈值往往等于收集物的半径但实际玩的时候玩家会觉得明明碰到了却没收集到。把阈值放大 10% 到 20%手感会好很多。这是纯体验层面的调整模型不会主动做但玩家能明显感知。第四个技巧跳跃力度和重力要一起调。很多人只调跳跃初速度结果角色要么跳得太高滞空太久要么跳得太矮。正确的做法是同时调重力和初速度让跳跃高度和滞空时间都符合预期。经验值是重力设为 -20 到 -30初速度设为 8 到 12具体看你的场景尺度。这几个技巧都是我在反复调试里攒下来的模型不会告诉你但实际做项目时能帮你省下大量时间。3D 游戏开发的门槛不在写代码而在这些手感细节的打磨上。模型能帮你跨过代码门槛但手感这道坎还是得自己过。