三大模型3D游戏开发实测：Step 5、DeepSeek V4 Pro、GLM5.3对比

1. 三款模型同台竞技这个对比测试到底在测什么三个大模型同一个3D游戏需求同样的对话式开发流程最后跑出来的东西到底差多少。这个测试的出发点其实很朴素——现在做AI辅助开发的人越来越多但大部分人只盯着“能不能生成代码”很少有人系统性地比较过不同模型在同一个完整项目里的表现差异。Step 5 Preview、DeepSeek V4 Pro、GLM5.3这三个模型分别代表了不同的技术路线和训练侧重把它们放在同一个3D游戏开发任务里跑一遍能看出来的东西比跑分榜单直观得多。我选择3D游戏作为测试载体原因有几个。第一3D游戏开发天然涉及多个技术栈的交叉——场景搭建、光照系统、物理碰撞、相机控制、交互逻辑、资源管理这些模块之间的耦合度高能充分暴露模型在复杂项目中的架构能力。第二3D游戏有明确的视觉反馈好不好一眼就能看出来不像后端接口那样需要反复调试才能感知差异。第三Three.js这个技术栈足够成熟文档丰富三个模型都有充分的训练数据覆盖不会因为某个模型没见过某个API而产生不公平的偏差。测试任务本身我设计得比较克制一个基于Three.js的3D跑酷类小游戏玩家控制一个方块在程序化生成的赛道上跳跃、躲避障碍、收集金币包含完整的计分系统和游戏结束判定。这个需求描述控制在200字以内不提供任何额外的技术细节或代码示例完全依赖模型自身的理解能力和代码生成能力。每个模型都通过对话式开发工具WorkBuddy来驱动保证交互方式一致排除工具差异带来的干扰。注意测试用的提示词完全一致不针对任何模型做特殊优化。这意味着如果某个模型对提示词的理解有偏差那也是它自身能力的一部分不做额外补偿。为什么要用WorkBuddy而不是直接调API因为对话式开发工具更接近真实开发者的使用场景。大部分人在实际工作中不会手写HTTP请求去调模型而是通过一个集成的开发环境来交互。WorkBuddy的工作台模式支持多轮对话、文件管理、实时预览这些功能会影响模型的输出质量——比如模型能不能看到自己上一轮生成的代码、能不能感知到运行时的报错信息这些都会显著影响最终结果。用统一的工具来跑测出来的差异才更有参考价值。三个模型的版本信息需要交代清楚Step 5 Preview是较新的预览版本DeepSeek V4 Pro是深度求索的旗舰模型GLM5.3来自智谱。这三个模型在代码生成领域都有不错的口碑但各自的训练数据分布、上下文窗口大小、推理策略都有差异。这些差异在简单任务上可能看不出来但在3D游戏这种需要多轮迭代、跨文件协调的场景里会被放大得很明显。2. 开发环境搭建与测试流程设计2.1 WorkBuddy工作台的配置要点WorkBuddy的工作台模式是我这次测试的主要操作界面。安装过程不复杂但有几个配置项直接影响后续的开发体验值得单独说一下。首次启动后建议先把系统缓存目录改到非系统盘因为3D游戏开发过程中会产生大量的临时文件和预览缓存默认放在C盘的话一个下午就能吃掉好几个G的空间。在设置里找到“缓存目录”选项改到一个空间充裕的盘符就行改完之后重启工作台生效。工作台的对话记录存储也值得关注。默认情况下所有对话历史都存在本地SQLite数据库里时间长了这个文件会变得很大。如果你打算长期用WorkBuddy做开发建议定期清理不需要的对话记录或者在设置里开启自动归档。我实测下来连续开发一周左右对话记录文件能到200MB以上虽然不影响功能但备份和迁移的时候会比较麻烦。另一个容易被忽略的点是WorkBuddy的Skill系统。工作台预装了一些常用的Skill比如代码格式化、依赖检查、预览服务等。做3D游戏开发的时候我建议把“实时预览”和“控制台输出捕获”这两个Skill打开。实时预览让你能直接在工具里看到游戏画面不用切到浏览器控制台输出捕获则能把运行时的报错信息自动喂给模型省去手动复制粘贴的步骤。这两个功能对多轮迭代的效率提升非常明显。提示WorkBuddy的SSH连接器功能在本地开发时用不上但如果你后续要把项目部署到远程服务器这个功能可以省去很多配置麻烦。本地测试阶段可以先不管它。2.2 三个模型的接入方式与参数设置三个模型都通过WorkBuddy的模型接入功能来调用。Step 5 Preview和GLM5.3可以直接在模型列表里选择DeepSeek V4 Pro需要手动配置一下API端点。接入的时候有几个参数需要留意温度值统一设为0.7这个值在代码生成任务里比较平衡既不会太死板也不会太随机最大输出长度设为8192个token3D游戏的单文件代码量比较大设太小会导致代码被截断上下文窗口根据各模型的实际能力来设Step 5 Preview和GLM5.3都支持较长的上下文DeepSeek V4 Pro的上下文窗口稍小一些但在这个项目里够用。接入完成后建议先跑一个简单的“Hello World”测试确认模型能正常响应。有时候API端点配置正确但网络策略有问题会导致请求超时。WorkBuddy的错误提示比较清晰如果连接失败先检查API密钥和端点地址再检查网络策略设置。2.3 测试任务的标准化描述为了保证公平性我给三个模型的任务描述完全一致。提示词是这样的用Three.js做一个3D跑酷小游戏要求 1. 玩家控制一个方块在程序化生成的赛道上自动向前跑 2. 按空格键跳跃可以躲避障碍物 3. 赛道上有金币可以收集收集后加分 4. 撞到障碍物游戏结束显示最终得分 5. 包含基本的场景光照和相机跟随 6. 所有代码放在一个HTML文件里用CDN引入Three.js这个描述刻意保持模糊没有指定具体的实现方式。比如“程序化生成赛道”可以有很多种做法——无限循环的赛道段、随机生成的障碍物布局、基于噪声的地形生成等等。模型选择哪种方案能反映出它的架构偏好和代码组织能力。“相机跟随”也没有指定是固定偏移还是平滑插值这些细节的取舍能看出模型对游戏开发惯例的理解程度。每个模型都进行最多5轮对话迭代。第一轮生成完整代码后续轮次根据实际运行效果进行修正和优化。如果某个模型在第一轮就生成了可运行的代码后续轮次用来增加细节如果第一轮有问题后续轮次用来排查和修复。5轮之后无论是否完美都停止迭代记录最终状态。3. 三个模型的实际表现对比3.1 Step 5 Preview架构清晰但细节粗糙Step 5 Preview在第一轮就生成了一个结构相当完整的代码框架。它把游戏逻辑分成了几个清晰的模块场景初始化、赛道生成器、玩家控制器、碰撞检测、计分系统。每个模块都有独立的函数封装变量命名也比较规范。这种架构意识在代码生成模型里不算常见大部分模型倾向于把所有逻辑塞在一个大函数里。但细节上问题不少。赛道生成用的是最简单的“随机放置障碍物”方案没有做赛道段的循环复用导致跑了一段距离之后场景里的物体数量持续增长帧率明显下降。跳跃的物理模拟也有问题——它用了一个固定的跳跃高度没有考虑重力加速度的累积效应导致连续跳跃时手感很怪。金币的碰撞检测用的是包围盒相交但包围盒的尺寸设置偏大经常出现“看起来没碰到但判定为收集”的情况。第二轮迭代我让它修复帧率问题它给出了一个对象池的方案把超出视野的障碍物回收复用。这个思路是对的但实现的时候有个bug——回收的物体没有重置位置和状态导致复用后的障碍物出现在奇怪的位置。第三轮修复了这个bug但对象池的容量设得太小高速奔跑时还是会出现物体突然消失的情况。Step 5 Preview的代码风格比较“教科书”注释写得很详细但有些注释是废话比如“// 设置变量x为10”这种。它在处理Three.js的API时偶尔会用一些已经废弃的方法比如Geometry而不是BufferGeometry虽然Three.js做了兼容处理但控制台会报警告。3.2 DeepSeek V4 Pro物理模拟最扎实DeepSeek V4 Pro第一轮生成的代码在架构上不如Step 5 Preview那么工整所有逻辑都写在一个大的init函数和animate循环里函数拆分不够细致。但它的物理模拟明显更扎实。跳跃用了基于速度的积分方式重力加速度、初速度、跳跃高度之间的关系处理得很自然连续跳跃的手感接近商业游戏的水平。赛道生成方面DeepSeek V4 Pro用了一个基于种子的伪随机算法虽然也是随机放置障碍物但通过种子控制保证了每次运行的赛道布局一致方便调试。这个细节说明它在生成代码时考虑了开发者的实际使用场景。金币的碰撞检测用了球体检测而不是包围盒判定更精确很少出现误判。不过DeepSeek V4 Pro在代码组织上有个问题它倾向于把所有东西都塞进一个文件里而且变量命名比较随意a、b、temp这种命名到处都是。第一轮生成的代码有将近800行全部在一个script标签里找特定逻辑的时候需要滚动很久。第二轮我让它按功能拆分模块它拆是拆了但模块之间的依赖关系处理得不太好出现了几个循环引用的问题。第三轮修复循环引用之后代码质量明显提升。DeepSeek V4 Pro在后续迭代中表现出了很强的“理解意图”能力——我说“跳跃手感有点飘”它能准确理解是重力参数需要调整而不是去改跳跃的触发逻辑。这种对模糊反馈的准确解读在实际开发中非常省时间。3.3 GLM5.3迭代响应最快但稳定性一般GLM5.3的响应速度是三个模型里最快的第一轮生成完整代码只用了不到30秒。代码风格介于前两者之间有一定的模块化意识但不如Step 5 Preview那么系统。它的赛道生成方案比较有意思——用了预制的赛道段模板每个模板包含固定的障碍物和金币布局然后随机拼接这些模板。这个方案在性能上比纯随机放置要好但模板的多样性有限跑久了会发现赛道重复。GLM5.3最大的问题是稳定性。第一轮生成的代码里有一个明显的语法错误——一个函数定义缺少了闭合的大括号导致整个脚本无法运行。WorkBuddy的控制台捕获到了这个错误并反馈给模型第二轮修复了。但第三轮我让它增加一个“加速道具”功能时它引入了一个新的bug道具的碰撞检测和金币的碰撞检测用了同一个变量名导致收集金币时也会触发加速效果。第四轮修复了这个变量冲突但代码里又出现了几个未定义的变量引用。GLM5.3在快速迭代时似乎容易“顾此失彼”每次修改都可能引入新的问题。不过它的优势在于响应快如果你愿意多花几轮对话来打磨最终也能得到一个可用的版本。第五轮之后游戏基本能正常运行但代码里还有一些冗余的逻辑和未使用的变量。3.4 三模型关键指标对比对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3首轮可运行是有警告是否语法错误代码架构模块化清晰初期混乱后期改善中等物理模拟一般优秀中等迭代响应速度中等中等快模糊反馈理解良好优秀一般最终代码质量良好优秀可用引入新bug频率低低较高注释质量详细但冗余简洁适中从表格能看出来DeepSeek V4 Pro在物理模拟和意图理解上优势明显适合对游戏手感有要求的场景。Step 5 Preview的代码架构最规范适合需要后续维护和扩展的项目。GLM5.3的响应速度最快适合快速原型验证但需要预留更多轮次来修复问题。4. 实操过程中的关键细节与避坑经验4.1 对话式开发工具的缓存管理用WorkBuddy做3D游戏开发缓存目录的管理是个容易被忽视但影响很大的问题。Three.js的项目在预览时会生成大量的着色器编译缓存、纹理缓存和几何体缓存。默认情况下这些缓存都存在系统盘的用户目录下一个中等复杂度的3D场景跑上几十次预览缓存就能到1-2GB。如果你的系统盘空间紧张很快就会收到磁盘空间不足的警告。把缓存目录改到D盘或者其他数据盘是个好习惯。在WorkBuddy的设置里找到“系统缓存目录”选项改完之后需要重启工作台。改完之后建议手动清理一次旧缓存不然旧的缓存文件还会占着空间。清理的时候注意不要删掉正在使用的项目的缓存否则下次预览会重新编译着色器第一次加载会明显变慢。另外WorkBuddy的对话记录文件也值得定期清理。每次和模型对话都会在本地数据库里存一份完整的对话历史包括代码片段和运行日志。做3D游戏开发时一轮对话可能就包含几百行代码数据库膨胀得很快。我一般每周清理一次把已经完成的项目对话归档或者删除。WorkBuddy支持按项目筛选对话记录清理起来还算方便。4.2 模型切换时的上下文处理在WorkBuddy里切换模型时有一个细节需要注意默认情况下切换模型后新的模型看不到之前的对话历史。这意味着如果你用Step 5 Preview生成了第一版代码然后切换到DeepSeek V4 Pro想让它继续优化DeepSeek V4 Pro是不知道之前发生了什么。你需要手动把之前的代码和问题描述复制到新的对话里。WorkBuddy有个“跨对话记忆”的Skill可以解决这个问题但需要手动开启。开启之后切换模型时可以选择“继承上下文”把之前的对话摘要传递给新模型。不过这个功能不是完美的——摘要会丢失一些细节特别是代码的具体实现。我的做法是切换模型时直接把当前代码文件作为附件上传然后在提示词里简要说明之前遇到的问题和已经尝试过的方案。这样虽然多花一点时间但能保证新模型有足够的上下文来做出合理的修改。注意不同模型的上下文窗口大小不一样。Step 5 Preview和GLM5.3的上下文窗口较大可以一次性传入较长的代码文件。DeepSeek V4 Pro的上下文窗口稍小如果代码超过一定长度需要分段传入或者只传入关键部分。4.3 3D游戏开发中的常见性能陷阱三个模型在生成3D游戏代码时都或多或少踩了一些性能陷阱。这些陷阱在代码审查时不容易发现但实际运行起来会明显影响体验。我整理了几个最常见的陷阱一每帧创建新对象。在animate循环里用new THREE.Vector3()或者new THREE.Color()创建临时对象会导致垃圾回收频繁触发帧率波动明显。正确的做法是在循环外面创建好临时对象循环里复用。Step 5 Preview和GLM5.3都犯过这个错误DeepSeek V4 Pro在第一轮就避免了。陷阱二碰撞检测的复杂度。如果场景里有N个障碍物和M个金币朴素的碰撞检测是O(N*M)的复杂度。当N和M都比较大时每帧的计算量会很大。正确的做法是用空间分割或者简单的距离预筛选来减少检测次数。三个模型都没有主动做这个优化需要手动提醒。陷阱三材质和几何体的复用。每个障碍物都创建独立的材质和几何体会导致显存占用飙升。正确的做法是共享材质和几何体实例只改变位置和旋转。DeepSeek V4 Pro在第二轮迭代时主动做了这个优化另外两个模型需要明确要求才会做。陷阱四阴影贴图的分辨率。默认的阴影贴图分辨率可能过高导致渲染开销大。对于小游戏来说1024x1024的分辨率通常就够了不需要用到2048x2048。这个参数在Three.js的DirectionalLight里设置三个模型默认用的都是2048需要手动调低。4.4 提示词工程的实战技巧经过这次对比测试我总结了几条在WorkBuddy里驱动模型做3D游戏开发的提示词技巧第一第一轮提示词要“留白”。不要把所有细节都写死给模型留出架构决策的空间。比如“程序化生成赛道”比“用预制的赛道段模板随机拼接”更好因为前者能看出模型的方案选择能力后者只是执行指令。第二反馈要具体但不要过于技术化。说“跳跃手感有点飘”比说“重力加速度参数需要从-9.8调整到-20”更好。前者测试的是模型对游戏体验的理解后者只是让它改一个数字。DeepSeek V4 Pro在理解“手感”这类模糊反馈上表现最好。第三每轮只聚焦一个问题。不要在一轮对话里同时要求修复bug、增加功能、优化性能。模型在多任务并行时容易顾此失彼GLM5.3尤其明显。一轮解决一个问题虽然总轮次多了但每轮的质量更高。第四善用WorkBuddy的控制台捕获功能。运行时报错信息直接喂给模型比手动描述错误现象要准确得多。WorkBuddy的控制台捕获Skill能自动把错误堆栈和日志附加到对话里模型看到原始错误信息后修复的准确率明显提升。5. 常见问题与排查技巧实录5.1 模型生成的代码无法运行怎么办这是最常见的问题三个模型都出现过。排查思路按优先级排列第一步看控制台报错。WorkBuddy的控制台捕获功能会显示具体的错误信息和行号。大部分情况下错误信息足够定位问题。常见的错误类型包括语法错误缺少括号、分号、API使用错误调用了不存在的方法、变量未定义拼写错误或作用域问题。第二步检查Three.js的版本兼容性。三个模型在生成代码时有时会混用不同版本的Three.js API。比如Geometry是旧版APIBufferGeometry是新版API混用会导致运行时错误。在HTML文件里明确指定Three.js的版本号比如https://cdn.jsdelivr.net/npm/three0.160.0/build/three.min.js可以减少这类问题。第三步逐段注释排查。如果错误信息不够明确把代码分成几段逐段注释掉看哪一段注释后错误消失。这个方法比较笨但很有效特别是对于逻辑错误而不是语法错误的情况。第四步让模型自己排查。把完整的错误信息和相关代码片段发给模型让它分析原因。DeepSeek V4 Pro在这方面的准确率最高Step 5 Preview次之GLM5.3有时会给出错误的诊断。5.2 游戏运行卡顿的优化方向3D游戏卡顿的原因很多按影响程度从大到小排列卡顿原因排查方法优化方案每帧创建新对象看控制台是否有频繁的GC日志在循环外创建临时对象循环内复用碰撞检测复杂度过高减少障碍物数量看是否改善用空间分割或距离预筛选材质几何体未复用看显存占用是否持续增长共享材质和几何体实例阴影贴图分辨率过高关闭阴影看是否改善降低阴影贴图分辨率渲染调用次数过多看渲染统计信息合并网格或使用实例化渲染我实测下来最常见的卡顿原因是每帧创建新对象和碰撞检测复杂度过高。前者通过代码审查就能发现后者需要实际运行才能感知。建议在开发阶段就打开浏览器的性能分析工具定期检查帧率和GC情况。5.3 模型“忘记”之前的要求怎么处理多轮对话中模型有时会“忘记”之前的要求。比如第一轮要求“按空格键跳跃”到第三轮修改其他功能时跳跃功能被意外删除了。这种情况在GLM5.3上出现的频率最高Step 5 Preview和DeepSeek V4 Pro相对较少。处理方法是在每轮对话的开头用一两句话重申核心要求。比如“保持之前的跳跃和金币收集功能不变现在增加一个加速道具”。这样模型在修改时会有意识地保留已有功能。另外WorkBuddy的“自定义指令”功能可以设置一些全局规则比如“每次修改代码时保留所有已有功能”这个规则会对后续所有任务生效减少功能丢失的情况。如果功能已经被删除了最直接的恢复方法是让模型对比修改前后的代码差异找出被删除的部分并恢复。WorkBuddy的对话历史里保留了每一轮的代码版本可以手动对比。DeepSeek V4 Pro在对比代码差异方面表现最好能准确指出哪些行被删除了。5.4 不同模型间的代码迁移问题有时候你会想用模型A生成的代码让模型B来继续优化。这种跨模型迁移有几个坑需要注意第一代码风格差异。不同模型的代码风格不一样模型B在修改模型A的代码时可能会把风格改得面目全非。如果你在意代码风格的一致性建议在迁移时明确要求“保持现有代码风格”。第二API使用习惯差异。比如Step 5 Preview喜欢用requestAnimationFrame做游戏循环DeepSeek V4 Pro喜欢用setInterval。迁移时如果不统一可能会出现两个循环同时运行的问题。第三变量命名冲突。模型B在添加新功能时可能会使用和模型A已有变量相同的名字导致冲突。迁移时建议先让模型B通读一遍现有代码了解已有的变量和函数命名。我的做法是跨模型迁移时先让新模型“阅读并总结”现有代码的结构和关键变量然后再提出修改要求。这样虽然多一轮对话但能避免很多低级错误。6. 三模型选型建议与后续扩展方向6.1 什么场景选什么模型基于这次实测我给三个模型画一个适用场景的画像Step 5 Preview适合需要长期维护和扩展的项目。它的代码架构最规范模块划分清晰变量命名合理后续接手的人能比较快地理解代码结构。如果你打算把一个原型发展成正式项目用Step 5 Preview打底会比较省心。但它在物理模拟和性能优化上需要更多手动干预。DeepSeek V4 Pro适合对游戏体验有要求的项目。它的物理模拟最扎实对模糊反馈的理解最准确迭代过程中引入新bug的频率最低。如果你做的是动作类、跑酷类游戏手感很重要DeepSeek V4 Pro是首选。它的代码风格比较随意但后期可以手动整理。GLM5.3适合快速原型验证。它的响应速度最快能在短时间内生成大量代码适合在项目初期快速试错。但它的稳定性一般需要预留更多轮次来修复问题。如果你只是想快速验证一个玩法想法GLM5.3的效率最高。6.2 用WorkBuddy做3D游戏开发的进阶技巧WorkBuddy的工作台模式还有一些进阶用法能进一步提升3D游戏开发的效率自定义Skill的组合使用。WorkBuddy支持把多个Skill组合成一个工作流。比如“代码生成→语法检查→预览启动→控制台捕获”可以串成一个自动化流程每次模型生成代码后自动执行后续步骤。这个功能在设置里的“Skill编排”里配置配置一次之后后续所有项目都能用。对话记录的导出与复用。WorkBuddy支持把对话记录导出为Markdown或JSON格式。如果你在某个项目里调出了一组好用的提示词可以导出保存下次做类似项目时直接导入复用。我一般会把“3D游戏开发”相关的对话记录单独归档积累了一套提示词模板。本地部署的考虑。如果你对数据隐私有要求WorkBuddy支持本地化部署。本地部署的版本功能上略有精简但核心的对话和代码生成功能都在。本地部署对硬件有一定要求建议至少16GB内存和一块支持CUDA的显卡。本地部署的模型响应速度取决于你的硬件配置高端显卡上能接近云端版本的速度。6.3 这个测试后续可以怎么扩展这次测试只覆盖了3D跑酷这一个品类后续可以从几个方向扩展品类扩展。试试塔防、解谜、射击等不同类型的3D游戏看模型在不同玩法下的表现差异。不同品类对物理模拟、AI行为、关卡设计的要求不一样能更全面地评估模型能力。复杂度扩展。增加多人联机、存档系统、排行榜等功能测试模型在更复杂系统下的架构能力。多人联机涉及网络同步和状态管理对模型的系统设计能力要求更高。技术栈扩展。除了Three.js还可以试试Babylon.js、PlayCanvas等其他的3D引擎。不同引擎的API设计差异很大能看出模型的泛化能力。评估维度扩展。除了代码质量和运行效果还可以加入代码可读性、注释质量、安全性等维度的评估。特别是安全性游戏代码里如果有注入风险或者资源泄露问题在实际项目中会很麻烦。我个人在实际操作中的体会是模型之间的差异在简单任务上不明显但在3D游戏这种多模块、多轮迭代的场景里差异会被显著放大。选模型不是选“最好的”而是选“最适合当前项目阶段和需求的”。原型阶段用GLM5.3快速试错核心玩法确定后用DeepSeek V4 Pro打磨手感最后用Step 5 Preview整理架构准备长期维护这个组合策略在实际项目中比较实用。