1. 三个模型同台做3D游戏我为什么选了这个题目最近Step 5 Preview放出来圈子里讨论度不低。加上DeepSeek V4 Pro和GLM5.3这两个老面孔三个模型凑一块儿能聊的角度很多。但我没选写代码题、没选做算法题偏偏选了一个看起来最重的方向——让它们各自独立做一个3D游戏。原因很直接3D游戏这个任务几乎把模型的所有能力短板都暴露出来了。它不像写一个排序算法输入输出明确、边界清晰也不像做一个网页DemoHTML加CSS就能糊弄过去。一个能跑的3D游戏至少涉及场景搭建、相机控制、光照系统、物理碰撞、输入响应、资源加载、性能优化这几大块任何一块掉链子最终跑起来就是黑屏、穿模、卡顿或者直接报错。我拿到的测试条件很朴素同一个需求描述分别丢给Step 5 Preview、DeepSeek V4 Pro和GLM5.3让它们各自生成一个可运行的3D游戏项目。需求我控制得比较克制——一个第三人称视角的收集类小游戏玩家控制角色在场景里移动收集散落的物品有基本的碰撞检测和计分逻辑。不要求联网、不要求复杂动画、不要求美术资源能用基础几何体搭出来就行。这个设定是有意为之的。需求越简单越能看出模型在从零搭建工程结构这件事上的真实水平。很多模型在单文件脚本里表现不错一旦要求它组织多文件、管理依赖、处理模块间的引用关系问题就全冒出来了。三个模型我都跑了完整流程从生成代码到本地跑起来中间踩的坑、修的问题、最后的效果差异下面一点点拆开讲。如果你也在纠结这几个模型在实际项目里怎么选或者想拿它们做游戏原型开发这篇应该能给你一些参考。2. 需求拆解一个最小可玩3D游戏到底包含什么2.1 我为什么把需求压到这么低一开始我想过让它们做一个带地形、带敌人AI、带背包系统的完整小游戏。后来放弃了这个念头。原因很简单需求越复杂模型越容易在某个环节编造不存在的API或者库最后你花在修错上的时间远超写代码本身。而且三个模型如果都在复杂需求上翻车你根本分不清是模型能力问题还是需求本身太离谱。所以我把需求砍到了最小可玩集。所谓最小可玩集就是去掉一切非必要元素之后仍然能被称为游戏的那部分。具体来说一个3D场景有地面和若干可交互物体一个玩家角色能用键盘控制前后左右移动相机跟随角色保持第三人称视角角色碰到收集物时物体消失、分数增加屏幕上显示当前分数就这五条。没有跳跃、没有动画、没有音效、没有菜单。听起来简单但每一条背后都对应着具体的技术实现。2.2 技术选型的约束条件我在需求里没有指定技术栈这是故意的。我想看看三个模型在没有约束的情况下会怎么选。但为了后续对比公平我加了一个隐性约束必须能在浏览器里直接跑不依赖本地安装额外运行环境。这个约束其实排除了不少方案。比如用Unity或者Unreal虽然做3D游戏更专业但需要安装编辑器、配置项目、导出构建整个流程太重而且模型生成的代码很难直接验证。浏览器方案里Three.js是最主流的选择Babylon.js次之原生WebGL对模型来说难度太高。实际跑下来三个模型都选了Three.js。这个结果不意外Three.js的生态成熟、文档丰富、社区示例多模型在训练数据里见过大量相关代码生成起来自然更顺手。但选同一个库不代表实现质量一样后面的差异主要出在工程组织和细节处理上。2.3 验收标准怎么定验收标准我定了三条按优先级排列第一能跑起来。打开浏览器不报错能看到场景和角色。这条是底线跑不起来后面都不用谈。第二操作跟手。按方向键角色能移动相机能跟随没有明显延迟或抖动。这条考验的是输入处理和相机逻辑。第三碰撞有效。角色碰到收集物能触发计分不会穿模或者误触发。这条考验的是碰撞检测的实现方式。三条标准里第一条淘汰率最高。我实测下来三个模型初次生成的代码只有一个能直接跑起来另外两个都需要修。具体是谁、修了什么下一节详细说。3. 三个模型的初次生成谁一把过谁需要返工3.1 Step 5 Preview结构最完整但有一个隐蔽的初始化顺序问题Step 5 Preview给我的第一印象是工程结构最像样。它没有把所有代码塞进一个HTML文件而是拆成了几个模块场景初始化、角色控制、碰撞检测、UI更新各占一块。入口文件里用ES模块的方式组织引用整体读起来层次清晰。但跑起来的时候遇到了问题。页面加载后场景是黑的控制台报了一个关于纹理加载的错误。我查了一下问题出在初始化顺序上。Step 5 Preview把场景渲染循环的启动放在了资源加载完成之前导致第一帧渲染时某些对象还没准备好。这个错误不算严重把渲染循环的启动挪到加载回调里就好了但它反映出一个问题模型对异步加载的时序理解不够扎实。修好之后跑起来效果是三个里面最稳的。角色移动平滑相机跟随没有明显延迟碰撞检测用的是包围盒方案精度够用。分数UI更新也正常。整体完成度最高。3.2 DeepSeek V4 Pro代码最简洁但碰撞逻辑有缺陷DeepSeek V4 Pro生成的代码量最少整个项目压缩在一个HTML文件里Three.js通过CDN引入。这种写法好处是简单直接坏处是工程扩展性差。不过对于这个测试需求来说单文件方案其实够用。它的问题出在碰撞检测上。DeepSeek V4 Pro用的是距离判断——计算角色和收集物之间的直线距离小于某个阈值就判定为碰撞。这个方案在二维平面上没问题但在三维空间里如果角色和收集物在Y轴上有高度差距离判断就会失准。我实测的时候角色明明从收集物上方跳过去虽然我没做跳跃但场景里收集物有高低差结果还是触发了计分。这个问题不算致命把距离判断改成包围盒相交检测就能解决。但它说明模型在空间几何的理解上存在盲区默认用了二维思维去处理三维问题。3.3 GLM5.3功能最全但性能有隐患GLM5.3生成的代码功能最丰富。它额外加了阴影、环境光遮蔽、以及一个简单的粒子效果。视觉上确实是三个里面最好看的。但跑起来之后帧率明显低于另外两个。我用浏览器的性能面板看了一下问题出在渲染循环里。GLM5.3在每一帧都重新计算了阴影贴图而这个场景里光源和物体都是静态的阴影贴图只需要计算一次。这个优化点模型没有考虑到导致GPU做了大量重复计算。另外GLM5.3的代码里有一个潜在的内存泄漏风险。它在每次碰撞检测时都创建了新的向量对象但没有复用。短时间跑没问题长时间运行可能会触发垃圾回收频繁执行造成卡顿。3.4 初次生成结果对比对比项Step 5 PreviewDeepSeek V4 ProGLM5.3工程结构多模块清晰单文件简洁多模块较清晰能否直接运行否需修初始化顺序是是碰撞检测方案包围盒距离判断包围盒视觉表现基础基础丰富有阴影和粒子性能表现良好良好一般有重复计算代码可读性高中中高这张表只是初次生成的结果。实际上三个模型都可以通过追加提示词来修复问题后面的章节我会讲怎么修、修完之后效果如何。4. 把三个项目跑起来之后我发现的共性问题4.1 相机控制三个模型都没处理好边界情况第三人称相机看起来简单实际上有不少边界情况要处理。比如角色移动到场景边缘时相机应该怎么响应角色快速转向时相机是瞬间跟上还是平滑过渡相机和角色之间如果有障碍物要不要做遮挡处理三个模型在这块的表现都不算好。Step 5 Preview的相机是硬跟随角色转向时相机瞬间旋转视觉上有点晕。DeepSeek V4 Pro加了平滑过渡但过渡参数是写死的角色慢速移动时相机反应迟钝。GLM5.3的相机逻辑最复杂但引入了一个新问题当角色靠近场景边界时相机会穿到地面以下。这些问题的根源是一样的模型在处理相机逻辑时只考虑了正常情况没有考虑边界情况。而实际项目中边界情况往往才是决定体验好坏的关键。我的修复方案是给相机加一个位置约束限制它在Y轴上的最小值同时把平滑过渡的参数改成根据角色速度动态调整。这部分代码不复杂但需要你理解相机和角色之间的空间关系。4.2 输入处理键盘事件的监听方式有差异三个模型都用了键盘事件来监听输入但实现方式有差异。Step 5 Preview用的是keydown和keyup组合维护了一个按键状态表在渲染循环里根据状态表来更新角色位置。这个方案最标准能正确处理同时按多个键的情况。DeepSeek V4 Pro直接在keydown事件里更新角色位置。这个方案的问题在于按键重复触发会导致角色移动速度不稳定。操作系统对按键重复的处理方式不一样有的系统重复延迟短有的长最终表现出来就是角色移动时快时慢。GLM5.3用了和Step 5 Preview类似的方案但它没有处理按键失去焦点的情况。比如你按着方向键的时候切换到另一个标签页再切回来角色会一直朝那个方向移动因为keyup事件没有被触发。提示键盘输入处理看起来是小事但它是玩家和游戏之间最直接的交互通道。输入处理没做好后面画面再好看也留不住人。4.3 资源管理CDN引入的隐患三个模型都通过CDN引入了Three.js。这个选择本身没问题但有一个隐患CDN的可用性和版本稳定性不受你控制。我测试的时候其中一个CDN节点响应特别慢导致页面加载时间超过十秒。更稳妥的做法是把Three.js下载到本地通过相对路径引入。这样不依赖外部网络加载速度也更快。如果项目要部署到线上这一步是必须做的。另外三个模型都没有处理加载失败的情况。如果CDN挂了页面就是一片空白用户不知道发生了什么。加一个简单的加载失败提示体验会好很多。5. 修复与调优让三个项目都达到可玩状态5.1 Step 5 Preview的初始化顺序修复Step 5 Preview的问题出在渲染循环的启动时机。原始代码里渲染循环在场景对象创建之后立即启动但纹理加载是异步的导致第一帧渲染时纹理还没准备好。修复方法很简单把渲染循环的启动放到资源加载的回调里。具体来说用Three.js的LoadingManager来管理资源加载在onLoad回调里启动渲染循环。这样能保证所有资源就绪后再开始渲染。改完之后Step 5 Preview的项目跑起来最稳。角色移动、相机跟随、碰撞检测都没有明显问题。我额外加了一个帧率显示实测在普通笔记本上能稳定在60帧。5.2 DeepSeek V4 Pro的碰撞检测升级DeepSeek V4 Pro的距离判断方案需要改成包围盒检测。Three.js提供了Box3类可以方便地计算物体的包围盒。具体做法是给角色和收集物各创建一个Box3对象在每一帧里用intersectsBox方法判断是否相交。这个改动会稍微增加计算量但在这个场景规模下完全可以接受。改完之后碰撞检测的准确度明显提升不会再出现高度差导致的误触发。另外DeepSeek V4 Pro的代码里没有做碰撞后的处理。收集物被碰到之后应该消失同时分数增加。这部分逻辑需要补上。我的做法是给收集物加一个visible属性碰撞后设为false同时更新分数变量和UI显示。5.3 GLM5.3的性能优化GLM5.3的性能问题主要出在阴影贴图的重复计算上。Three.js的平行光默认每帧都会重新计算阴影贴图但对于静态场景这个计算只需要做一次。修复方法是在光源对象上设置shadow.autoUpdate false然后手动调用一次shadow.needsUpdate true。粒子效果那块也有优化空间。GLM5.3用了大量的独立粒子对象每个对象都有自己的更新逻辑。改成使用Points对象配合BufferGeometry可以把所有粒子合并成一个绘制调用性能提升很明显。内存泄漏的问题需要修改碰撞检测的代码把每次新建的向量对象提到循环外面复用同一个对象。这个改动很小但能避免长时间运行后的卡顿。5.4 三个项目修复后的对比对比项Step 5 PreviewDeepSeek V4 ProGLM5.3修复难度低中中高修复后帧率60fps60fps55-60fps碰撞准确度高高高视觉表现基础基础丰富代码可维护性高中中修复之后三个项目都能正常游玩。Step 5 Preview的综合表现最好DeepSeek V4 Pro次之GLM5.3在视觉上仍然领先但性能优化需要多花点心思。6. 从这三个项目里我总结出的模型选型经验6.1 什么场景选Step 5 PreviewStep 5 Preview在工程结构组织上明显强于另外两个。它生成的代码模块划分清晰变量命名规范注释也写得比较到位。如果你的项目需要多人协作或者后续要持续迭代Step 5 Preview的代码基础更好。它的短板在于异步处理。初始化顺序的问题不是个例我在另一个测试里也遇到了类似的时序问题。如果你用Step 5 Preview建议在涉及异步加载的地方多留个心眼手动检查一下执行顺序。6.2 什么场景选DeepSeek V4 ProDeepSeek V4 Pro的优势是简洁。它生成的代码量少逻辑直接适合快速验证想法。如果你只是想做一个原型看看某个玩法能不能跑通DeepSeek V4 Pro的效率最高。但它的空间几何理解需要加强。距离判断代替包围盒检测这个问题本质上是对三维空间的理解不够深入。如果你的项目涉及复杂的空间关系用DeepSeek V4 Pro的时候要仔细检查碰撞相关的代码。6.3 什么场景选GLM5.3GLM5.3在视觉效果上最有追求。它主动加了阴影、粒子这些提升观感的元素说明模型对好看这件事有感知。如果你的项目对视觉表现要求高GLM5.3能帮你省不少事。代价是性能。GLM5.3生成的代码往往需要额外的优化才能达到流畅运行的标准。你需要对渲染管线有一定了解知道哪些计算可以缓存、哪些可以合并。如果你对性能优化不熟悉用GLM5.3可能会比较吃力。6.4 一个容易被忽略的点模型对可运行的理解这次测试让我意识到一个问题模型对代码能跑和项目能跑的理解是有差距的。代码能跑指的是语法正确、没有报错。项目能跑指的是所有模块协同工作、资源正确加载、边界情况有处理。三个模型在代码能跑这个层面都做得不错但在项目能跑这个层面各有短板。Step 5 Preview卡在异步时序DeepSeek V4 Pro卡在空间几何GLM5.3卡在性能优化。这些问题都不是语法错误而是工程经验不足的体现。所以你在用这些模型做实际项目的时候不能只看它生成的代码有没有报错还要从工程角度去审视模块之间的依赖关系对不对、资源加载的时机对不对、边界情况有没有考虑。这些是模型目前还做不好的地方也是你作为开发者需要补位的地方。7. 如果你想自己复现这个测试几个实操建议7.1 需求描述怎么写才能让模型少犯错我这次用的需求描述比较简短模型自由发挥的空间大问题也暴露得多。如果你想让模型生成更靠谱的代码需求描述可以写得更具体一些。比如明确指定用Three.js的哪个版本、明确要求用包围盒做碰撞检测、明确说明相机跟随的平滑参数范围。但要注意需求写得太细也有坏处。模型可能会机械地按照你的描述去写而忽略了一些你没提到但实际需要处理的情况。我的建议是核心约束写清楚细节留给模型发挥然后你自己去补边界情况。7.2 本地跑Three.js项目的环境准备Three.js项目不需要复杂的构建工具一个简单的HTTP服务器就能跑。我常用的是Python自带的http.server模块在项目目录下执行一行命令就能启动。如果你装了Node.js用npx serve也可以。需要注意的是Three.js的ES模块版本需要通过HTTP协议加载直接双击HTML文件用file协议打开会报跨域错误。这个问题新手经常遇到提前说一声。7.3 怎么快速定位模型生成代码里的问题模型生成的代码出问题时第一步永远是看控制台。浏览器开发者工具的控制台会告诉你哪个文件、哪一行出了什么错。大部分问题看报错信息就能定位。如果控制台没有报错但画面不对下一步是加日志。在关键位置打印变量值看看数据流是否符合预期。比如相机位置不对就打印相机和角色的坐标看看两者之间的关系是不是你想要的。如果日志也看不出问题那就用二分法。把代码分成几块逐块注释掉看问题出在哪一块。这个方法笨但有效尤其是处理渲染相关的问题时。7.4 关于WorkBuddy这类工具在游戏开发中的定位最近WorkBuddy讨论度很高很多人问它在游戏开发里能不能用。我的看法是WorkBuddy这类工具擅长的是任务编排和流程自动化它可以把生成代码、运行测试、收集反馈这个流程串起来但它本身不生成3D游戏的渲染逻辑。你可以把WorkBuddy理解成一个调度中心。它负责把任务分发给不同的模型收集结果然后根据结果决定下一步做什么。比如你可以配置一个流程先用Step 5 Preview生成项目骨架跑起来之后如果帧率不达标自动把性能优化任务转给GLM5.3。这种用法能发挥各个模型的长处比单独用一个模型效果更好。但前提是你得先把每个模型的能力边界摸清楚知道什么任务该派给谁。这也是我做这次测试的目的之一。8. 最后聊几句实际感受三个模型跑下来我最大的感受是它们都能写出看起来对的代码但离真正能用还有一段距离。这段距离不是靠模型自己迭代能填上的需要你在中间做很多判断和修补。Step 5 Preview的工程结构最好但异步时序要自己盯。DeepSeek V4 Pro的代码最简洁但空间几何要自己补。GLM5.3的视觉效果最好但性能优化要自己做。没有哪个模型能一把梭哈选哪个取决于你的项目更看重什么以及你自己更擅长补哪块短板。另外说一个细节。我在测试过程中发现给模型追加提示词让它修复问题时Step 5 Preview的修复准确率最高。你告诉它渲染循环启动时机不对它能准确理解并改对地方。DeepSeek V4 Pro有时候会改错文件GLM5.3的修复方案有时会引入新问题。这个差异在长期项目里影响很大因为你需要反复和模型交互来迭代代码。如果你也在用这几个模型做开发建议先拿一个小项目跑通全流程摸清楚每个模型的脾气再决定在正式项目里怎么分工。直接上大项目大概率会在某个环节卡住而且很难判断是模型的问题还是你自己的问题。