1. 三款模型同台竞技这个对比测试到底在测什么三个大模型同一个3D游戏需求同时开跑。这个测试思路本身就很有意思——它不是跑分不是刷榜而是把三个模型扔进同一个项目现场看谁能在真实开发场景里把活干得最漂亮。我拿到这个测试任务的时候第一反应是3D游戏开发这个选题选得好。为什么因为它天然覆盖了多个维度的能力——数学计算向量、矩阵、坐标系变换、图形学基础光照、材质、渲染管线、物理模拟碰撞检测、重力、惯性、交互逻辑输入响应、状态管理、以及代码组织能力模块拆分、类设计。一个模型如果只能写CRUD在这个任务里会原形毕露。这次参与对比的三个模型分别是Step 5 Preview、DeepSeek V4 Pro和GLM5.3。测试用的开发环境是WorkBuddy工作台这是一个支持多模型切换的AI编程辅助工具可以把它理解成一个模型调度中心——你在里面配置好不同的模型端点然后针对同一个任务分别调用不同的模型来生成代码最后对比输出质量。注意WorkBuddy本身不训练模型它是一个编排层。你可以把它看作一个AI开发团队的管理者负责把任务分发给不同的AI员工然后收集结果。它的价值在于统一了交互界面和上下文管理让你不用在多个网页之间来回切换。测试的具体任务是用Three.js做一个可交互的3D游戏场景要求包含以下要素一个可移动的玩家角色WASD控制至少3种不同类型的障碍物/敌人碰撞检测与生命值系统得分机制与游戏结束逻辑基础的粒子特效比如击中时的爆炸效果完整的UI覆盖层开始界面、游戏进行中HUD、结束界面这个需求不算特别复杂但也绝对不简单。它要求模型不仅懂Three.js的API还要理解游戏开发的基本架构模式——比如游戏循环Game Loop、实体组件系统ECS的简化版、状态机管理等等。我选择这个测试方案的原因很简单3D游戏是一个无法作弊的领域。你没法靠堆砌漂亮的文字描述来蒙混过关代码跑不起来就是跑不起来画面出不来就是出不来。这比让模型写一篇技术博客或者回答一道算法题要直观得多。另外Three.js这个技术选型也有讲究。它是一个成熟且文档丰富的WebGL库模型在训练数据中肯定见过大量相关代码。这意味着测试的不是模型知不知道Three.js而是模型能不能把知道的碎片知识组装成一个能跑的项目。这恰恰是实际开发中最需要的能力——不是背诵API而是架构设计。2. 三个模型的代码生成策略对比2.1 Step 5 Preview结构化最强的项目经理Step 5 Preview给我的第一印象是组织能力极强。它没有一上来就写代码而是先输出了一个完整的项目结构规划/game /src main.js -- 入口初始化场景和游戏循环 /core GameLoop.js -- 游戏主循环管理update和render InputManager.js -- 键盘输入统一管理 /entities Player.js -- 玩家角色类 Enemy.js -- 敌人基类 EnemyFactory.js -- 敌人创建工厂 /systems CollisionSystem.js -- 碰撞检测 ScoreSystem.js -- 得分与生命值 ParticleSystem.js -- 粒子特效 /ui HUD.js -- 游戏内界面 MenuScreen.js -- 开始/结束界面 /utils MathUtils.js -- 向量计算辅助这个结构让我有点意外——它用的是接近ECS架构的组织方式把实体Entity、系统System和核心逻辑分离得很清楚。对于一个小型3D游戏来说这个架构甚至有点过度设计但好处是扩展性极强。如果你想加一个新的敌人类型只需要在EnemyFactory里注册然后在CollisionSystem里加上对应的碰撞规则就行不用动其他代码。Step 5 Preview生成的代码有一个显著特点注释密度非常高。几乎每个函数上面都有JSDoc风格的注释说明了参数类型和返回值。比如它的碰撞检测函数/** * AABB碰撞检测 * param {THREE.Box3} boxA - 第一个物体的包围盒 * param {THREE.Box3} boxB - 第二个物体的包围盒 * returns {boolean} 是否发生碰撞 */ function checkCollision(boxA, boxB) { return boxA.intersectsBox(boxB); }这种风格对于团队协作非常友好但对于快速原型开发来说可能略显啰嗦。不过考虑到这是生成一个完整项目的场景这种严谨性反而是加分项。2.2 DeepSeek V4 Pro代码最紧凑的极简主义者DeepSeek V4 Pro走的是完全不同的路线。它把所有代码塞进了两个文件index.html和game.js。没有模块拆分没有类继承体系所有逻辑都在一个巨大的game.js里用函数和对象字面量来组织。它的代码风格非常实用主义。比如玩家移动逻辑Step 5 Preview写了一个完整的Player类包含速度、加速度、摩擦力等物理属性而DeepSeek V4 Pro直接这样写// 玩家移动 const speed 0.1; if (keys[w]) player.position.z - speed; if (keys[s]) player.position.z speed; if (keys[a]) player.position.x - speed; if (keys[d]) player.position.x speed;简单粗暴但确实能用。没有加速度没有摩擦力按下按键就瞬间移动松开就立刻停止。对于一个小型Demo来说这种街机式的移动手感其实完全够用甚至更符合某些游戏类型的设计需求。DeepSeek V4 Pro的强项在于代码密度。它用最少的行数实现了最多的功能。整个游戏逻辑压缩在约800行代码里而Step 5 Preview的版本超过了1500行。如果你需要快速验证一个想法DeepSeek V4 Pro的输出可以让你在5分钟内就看到画面。但代价也很明显可维护性差。所有东西耦合在一起想改一个参数可能要翻遍整个文件。而且它的注释非常少基本只在不明显的地方加一两句说明。2.3 GLM5.3平衡感最好的务实派GLM5.3的选择介于两者之间。它做了适度的模块拆分——把游戏拆成了scene.js、player.js、enemies.js、ui.js四个文件但没有像Step 5 Preview那样细到每个系统一个文件。它的代码风格也很有特点偏向函数式编程。比如粒子效果的实现Step 5 Preview用了一个ParticleSystem类来管理粒子池DeepSeek V4 Pro直接在碰撞回调里创建粒子然后定时销毁而GLM5.3写了一个纯函数function createExplosion(position, color, count 20) { const particles []; for (let i 0; i count; i) { const particle new THREE.Mesh( new THREE.SphereGeometry(0.05), new THREE.MeshBasicMaterial({ color }) ); particle.position.copy(position); particle.userData.velocity new THREE.Vector3( (Math.random() - 0.5) * 0.3, Math.random() * 0.3, (Math.random() - 0.5) * 0.3 ); particles.push(particle); } return particles; }这个函数只负责创建粒子不负责更新和销毁。更新逻辑在游戏主循环里统一处理。这种关注点分离的做法让代码更容易测试和复用。GLM5.3的另一个亮点是对边界情况的处理更细致。比如在碰撞检测中它考虑了高速移动穿透的问题——如果玩家移动速度很快可能会在一帧内穿过一个薄墙而不触发碰撞。它的解决方案是做射线检测而不是简单的包围盒重叠检测// 用射线检测防止高速穿透 const ray new THREE.Raycaster(player.position, moveDirection, 0, moveDistance); const hits ray.intersectObjects(walls); if (hits.length 0) { // 碰撞阻止移动 return; }这个细节说明GLM5.3在生成代码时想得更多不只是实现功能还考虑了实际运行中可能出现的bug。3. 实操过程从零到可玩Demo的完整记录3.1 环境搭建与WorkBuddy配置先说环境。我用的是一台普通的开发机配置如下项目配置CPUAMD Ryzen 7 5800X内存32GB DDR4显卡NVIDIA RTX 3060 12GB系统Ubuntu 22.04浏览器Chrome 120WorkBuddy的安装很简单官方提供了Linux的AppImage包下载后直接赋予执行权限就能运行。首次启动会让你配置模型端点——这里需要填入各个模型的API地址和密钥。如果你用的是云端API直接填官方提供的地址就行如果想本地部署也可以用vLLM之类的推理框架自己搭。提示WorkBuddy的系统缓存目录默认在~/.workbuddy/cache如果你的系统盘空间紧张可以在设置里改到其他分区。我把它改到了/data/workbuddy-cache因为模型生成的代码缓存和对话历史会越积越多放在系统盘容易把根分区撑满。配置好之后我创建了一个新的项目工作区命名为3d-game-comparison。WorkBuddy的工作区概念很重要——它会把同一个项目的所有对话、文件、上下文都隔离在一个独立的空间里不同项目之间不会互相干扰。接下来是关键步骤给WorkBuddy设定规则。这个功能相当于给AI助手一个系统提示词告诉它在这个项目里应该遵循什么规范。我设定的规则如下1. 所有代码使用ES6语法模块化组织 2. 使用Three.js r160版本不依赖其他第三方库 3. 代码必须包含中文注释解释关键逻辑 4. 每个文件不超过300行超过则拆分 5. 优先考虑代码可读性其次才是性能优化 6. 所有用户输入必须做边界检查这几条规则会在后续所有对话中生效不需要每次重复说明。这个功能在实际使用中非常省心——你不需要在每次提问时都粘贴一遍要求WorkBuddy会自动把规则注入到上下文里。3.2 第一轮让三个模型分别生成项目骨架我在WorkBuddy里创建了三个独立的对话线程分别对应三个模型。每个线程里发送了完全相同的提示词请用Three.js创建一个3D游戏要求 1. 玩家角色可以用WASD控制移动 2. 场景中有3种不同的敌人每种敌人的行为和外观不同 3. 玩家碰到敌人会扣血血量归零游戏结束 4. 击败敌人可以得分 5. 有开始界面、游戏HUD和结束界面 6. 击中敌人时有粒子爆炸效果 请先输出完整的项目文件结构和每个文件的职责说明然后再输出代码。Step 5 Preview的响应时间大约是12秒输出了完整的项目结构前面已经展示过和约1500行代码。它的输出是分文件给出的每个文件都有清晰的头部注释说明文件用途。DeepSeek V4 Pro响应最快大约8秒就完成了输出。它直接给了一个完整的index.html包含Three.js的CDN引入和一个game.js总共约800行。代码紧凑但可读性一般。GLM5.3响应时间约15秒输出了4个文件约1100行代码。它的特点是每个文件的开头都有一段设计思路说明解释为什么这样组织代码。第一轮下来三个模型都成功生成了可运行的代码。我把三份代码分别放到三个目录里用npx serve启动本地服务器都能正常打开并看到画面。3.3 第二轮功能迭代与Bug修复第一轮生成的代码虽然能跑但都有一些小问题。我针对每个模型的表现进行了第二轮对话要求修复具体问题。Step 5 Preview的问题敌人AI太简单只会直线朝玩家移动没有任何躲避或巡逻行为。我要求它给敌人加上巡逻状态和追击状态当玩家进入一定范围后才开始追击。它的响应很专业不仅修改了Enemy.js还新增了一个StateMachine.js来管理敌人的状态切换。代码质量很高但引入了一个新问题状态机的转换条件写得太复杂导致敌人在边界处会反复切换状态出现抖动现象。我反馈了这个问题后Step 5 Preview很快定位到了原因状态转换的阈值没有做迟滞处理。它解释说如果进入追击的范围是5米退出追击的范围也是5米那么玩家在5米边界来回移动时敌人就会疯狂切换状态。解决方案是设置两个阈值——进入追击用5米退出追击用7米中间留2米的缓冲带。这个细节让我对Step 5 Preview的评价提高了一个档次。它不仅会写代码还理解游戏开发中的常见陷阱。DeepSeek V4 Pro的问题粒子效果在敌人被击败后不会消失会一直留在场景里越积越多最终导致帧率下降。我要求它修复粒子不销毁的问题。它的修复方案很直接在粒子创建时记录一个life属性然后在游戏循环里遍历所有粒子减少life当life 0时从场景中移除。代码只有几行改动但确实解决了问题。不过我发现它的粒子池没有做上限控制。如果玩家疯狂击杀敌人粒子数量还是会暴涨。我再次反馈后DeepSeek V4 Pro加了一个简单的数量上限——当粒子数超过200时移除最旧的粒子。这个方案不算优雅但够用。GLM5.3的问题UI界面的文字在不同屏幕尺寸下会错位。我要求它让UI适配不同分辨率。GLM5.3的修复方案最完善。它没有简单地用CSS的vw/vh单位而是写了一个UIScaler函数根据屏幕宽高比动态计算UI元素的位置和大小。它还考虑了移动端的触摸操作把WASD键盘控制扩展成了键盘触摸摇杆双模式。这个扩展超出了我的要求但确实很实用。GLM5.3在回复中解释说考虑到3D游戏可能在移动设备上运行我顺便加了触摸支持。这种主动补全需求的能力在实际开发中很有价值。3.4 第三轮性能优化与最终对比经过两轮迭代三个版本的功能都基本完整了。最后一轮我要求它们做性能优化目标是在保持60FPS的前提下尽可能多地渲染敌人。Step 5 Preview的优化策略是空间分区。它引入了一个简单的网格系统把场景划分成10x10的格子碰撞检测时只检查同一格子内的物体。这个优化在敌人数量多的时候效果显著——从原来的O(n²)复杂度降到了接近O(n)。DeepSeek V4 Pro的优化策略是对象池。它预创建了100个敌人对象循环使用避免了频繁的创建和销毁开销。这个方案对于敌人不断生成和死亡的场景很有效但如果敌人类型多样对象池的管理会变得复杂。GLM5.3的优化策略是LODLevel of Detail。远处的敌人用低面数模型近处的用高面数模型。这个方案在视觉上几乎看不出差别但渲染开销降低了不少。不过实现起来最复杂需要为每种敌人准备两套模型。最终的性能测试结果模型100个敌人FPS200个敌人FPS500个敌人FPSStep 5 Preview605845DeepSeek V4 Pro605538GLM5.3606052GLM5.3在极限情况下的表现最好这得益于LOD策略。Step 5 Preview次之空间分区在中高负载下很稳定。DeepSeek V4 Pro在500敌人时掉帧明显因为对象池虽然减少了GC压力但渲染开销没有降低。4. 常见问题与排查技巧实录4.1 模型生成代码的典型问题速查在实际测试过程中我遇到了不少问题。这里整理成一张速查表方便你遇到类似情况时快速定位问题现象可能原因排查方法解决方案画面全黑控制台无报错Three.js版本不匹配某些API已废弃检查THREE.REVISION和代码中使用的API锁定Three.js版本或按新版API修改代码模型生成的代码无法运行缺少依赖或CDN链接失效打开浏览器控制台看Network面板手动补全依赖或换用本地npm包敌人不移动游戏循环没有调用敌人的update方法在游戏循环里打日志确认检查主循环是否遍历了所有实体碰撞检测不触发包围盒没有更新每帧打印包围盒的min/max值在移动后调用computeBoundingBox()粒子效果卡顿粒子数量过多每帧创建新对象用Performance面板看内存和帧率引入对象池限制最大粒子数UI文字模糊Canvas分辨率与CSS尺寸不匹配检查renderer.setPixelRatio设置为window.devicePixelRatio模型忘记处理窗口resize没有监听resize事件手动改变窗口大小观察添加resize监听更新相机和渲染器4.2 三个模型各自的坑Step 5 Preview的坑它倾向于过度设计。一个小游戏被它拆成了十几个文件每个文件都有完整的类结构和接口定义。这在团队协作中是好事但如果你只是想快速做个Demo会觉得很累赘。而且它的代码有时候会想太多——比如给一个简单的得分功能加上了观察者模式引入了不必要的复杂度。实操心得用Step 5 Preview的时候可以在提示词里明确说不要过度设计保持简单。这样它会收敛一些输出更务实的代码。DeepSeek V4 Pro的坑它太喜欢用全局变量。在它的代码里scene、camera、renderer、player这些都是全局的任何函数都可以直接访问和修改。这在小型项目里没问题但一旦代码量上去调试会非常痛苦——你永远不知道是哪个函数改了player.position。实操心得用DeepSeek V4 Pro的时候可以在规则里加一条禁止使用全局变量所有状态必须封装在模块或类里。虽然它不一定完全遵守但至少会收敛一些。GLM5.3的坑它的代码风格偏函数式大量使用map、filter、reduce。这在处理数组时很优雅但在游戏循环这种性能敏感的场景里频繁创建新数组会导致GC压力。我在测试中发现GLM5.3的版本在敌人数量多时GC暂停比另外两个版本更频繁。实操心得用GLM5.3的时候可以在规则里加一条游戏循环内的代码避免创建新数组或对象使用for循环代替高阶函数。这样它会生成更接地气的性能友好代码。4.3 WorkBuddy使用中的几个实用技巧既然这次测试是在WorkBuddy里完成的顺便分享几个我摸索出来的使用技巧技巧一用规则功能统一代码风格。前面提到过WorkBuddy允许你给项目设定全局规则。我建议把代码风格、命名规范、注释要求都写进去。这样不管切换哪个模型输出都会遵循同一套标准对比起来更公平。技巧二善用跨对话记忆。WorkBuddy有一个跨对话记忆的skill可以让不同对话线程之间共享上下文。比如我在测试Step 5 Preview的时候把DeepSeek V4 Pro生成的某个工具函数复制过来WorkBuddy会自动识别并记住这个函数的用途后续对话中可以直接引用。技巧三缓存目录一定要改。前面提过默认的缓存目录在用户主目录下。如果你同时跑多个项目缓存会迅速膨胀。我建议在WorkBuddy的设置里把缓存目录改到一个大容量分区并且定期清理。技巧四给模型定规矩要具体。不要写代码要规范这种模糊的要求要写函数名用驼峰命名类名用帕斯卡命名常量用全大写加下划线。越具体模型的输出越符合预期。5. 最终评价三个模型分别适合什么场景经过三轮迭代和性能测试我对三个模型有了比较清晰的认识。它们没有绝对的优劣而是各有擅长的场景。Step 5 Preview适合中大型项目和团队协作。它的架构设计能力最强代码组织最规范注释最完善。如果你要做一个需要长期维护的项目或者需要多人协作Step 5 Preview的输出可以直接作为项目骨架。但如果你只是做个快速原型它的过度设计可能会拖慢你的速度。DeepSeek V4 Pro适合快速验证和个人小项目。它的输出最紧凑上手最快代码量最少。如果你有一个想法需要快速验证或者做一个一次性使用的小工具DeepSeek V4 Pro可以在最短时间内给你一个能跑的东西。但如果你后续要扩展功能可能需要花时间重构它的面条式代码。GLM5.3适合需要平衡的场景。它在代码质量和开发效率之间找到了一个不错的平衡点既不像Step 5 Preview那样重也不像DeepSeek V4 Pro那样糙。它的边界情况处理最细致主动补全需求的能力最强。如果你不确定项目会发展到什么规模GLM5.3是一个比较稳妥的选择。最后说一个我在测试中发现的细节三个模型在处理中文提示词时的表现差异不大都能准确理解需求。但在生成中文注释时Step 5 Preview的注释最自然GLM5.3次之DeepSeek V4 Pro的中文注释偶尔会有翻译腔——比如把check collision直译成检查碰撞而不是更自然的碰撞检测。这个细节不影响代码运行但影响阅读体验。如果你对代码可读性有要求可以在WorkBuddy的规则里加一条注释使用自然的中文表达避免直译英文术语。另外关于模型选择我的个人建议是不要只用一个模型。在WorkBuddy里配置多个模型端点针对不同的任务类型切换使用。比如架构设计用Step 5 Preview快速原型用DeepSeek V4 Pro细节打磨用GLM5.3。这种组合拳的方式比死磕一个模型效率高得多。我在实际项目里就是这么干的——先用Step 5 Preview生成项目骨架和核心类然后用DeepSeek V4 Pro快速填充一些工具函数最后用GLM5.3做代码审查和边界情况补全。三个模型各司其职整体效率比单用一个模型提升了至少40%。这个3D游戏的完整代码我已经整理好了三个版本分别放在step5-version、deepseek-version和glm-version三个目录里。如果你也想复现这个测试建议从DeepSeek V4 Pro的版本开始——它最容易跑起来能让你在5分钟内看到效果然后再去研究另外两个版本的架构设计。
