1. 三款模型同台做3D游戏我为什么选这个题最近圈子里讨论度最高的三件事一个是 Step 5 Preview 的预览版放出来一个是 DeepSeek V4 Pro 在代码任务上的表现还有一个是 GLM5.3 配合 vLLM 部署的工程化玩法。单独看每一条都是常规更新但把这三个模型拉到同一个任务上——从零做一个能跑起来的 3D 游戏——就能看出很多纸面参数看不出的东西。我做这个实测的出发点很朴素平时接的活里游戏原型开发是最能暴露模型综合能力的场景。它不像写个爬虫或者做个后台接口只要逻辑对就行。3D 游戏同时牵扯到数学向量、矩阵、四元数、图形学渲染管线、光照、材质、物理碰撞检测、刚体运动、状态管理场景切换、资源加载、还有交互逻辑输入映射、相机控制。任何一个环节掉链子最后跑起来就是黑屏、穿模、或者帧率掉到个位数。所以拿它当试金石比刷 benchmark 靠谱得多。这篇文章适合三类人看一是正在选型、想知道这几个模型在真实项目里到底谁更能打的开发者二是想自己动手做 3D 小游戏但不知道从哪下手的独立开发者三是已经在用 WorkBuddy 这类工作台工具、想搞清楚怎么把模型能力接进自己工作流的人。我会把三个模型各自生成的代码结构、踩到的坑、以及最后跑起来的实际效果都摊开讲包括我用的提示词、参数配置、以及中途怎么调优的。你看完可以直接抄作业也可以根据自己项目的情况做取舍。需要先说明一点Step 5 Preview 目前还是预览阶段DeepSeek V4 Pro 和 GLM5.3 的版本迭代也比较快我测的时候用的是当时能拿到的最新权重和推理配置。具体版本号我会在对应章节标注你复现的时候注意对齐。2. 三个模型的选型逻辑与任务拆解2.1 为什么是这三个模型而不是别的选 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个不是随便凑的。它们分别代表了当前开源和半开源阵营里三种不同的技术路线。Step 5 Preview 的特点是上下文窗口给得足长代码生成时不容易丢前面的定义。我做 3D 游戏最怕的就是模型写着写着忘了前面定义的类名或者函数签名导致后面调用的地方全对不上。Step 5 Preview 在这方面的表现是我目前用下来比较稳的尤其是单文件超过 800 行之后它还能记住前面定义的Vector3结构体里有哪些字段。DeepSeek V4 Pro 强在代码的逻辑密度。它生成的代码往往比较紧凑不太会出现那种为了凑行数而写的废话。但紧凑也有代价就是可读性会差一些变量命名偏短注释少。如果你是要直接拿去做产品可能得自己再补一轮注释和重构。GLM5.3 我关注它主要是因为 vLLM 部署的成熟度。社区里关于 GLM5.3 用哪个版本的 vLLM 镜像讨论很多说明它的工程化配套做得比较到位。对于想私有化部署、把模型接进自己工作流的人来说这一点比单纯的生成质量更重要。你总不希望模型跑出来的代码很好但部署的时候卡在环境依赖上三天搞不定。2.2 3D 游戏这个任务到底难在哪很多人觉得 3D 游戏难在图形学其实对模型来说真正的难点在状态同步和资源生命周期管理。举个具体的例子玩家按下 W 键角色向前移动。这背后涉及输入事件捕获、速度向量计算、位置更新、碰撞检测、相机跟随、动画状态切换、可能还有音效触发。这些逻辑分散在多个模块里模型必须保证它们之间的数据流是一致的。如果模型在生成输入处理模块时假设速度是标量在生成物理模块时又假设速度是向量那最后拼起来就是编译错误或者运行时的诡异行为。另一个难点是渲染循环的时序。3D 游戏通常有一个主循环里面按固定顺序执行处理输入、更新物理、更新动画、渲染。这个顺序不能乱乱了就会出现角色先渲染再更新位置的闪烁问题。模型需要理解这个时序约束并且在生成代码时保持住。我给三个模型的提示词是同一套尽量保证公平。提示词大意是用 JavaScript 和 Three.js 做一个第三人称 3D 跑酷游戏包含角色移动、跳跃、障碍物生成、碰撞检测、分数统计、游戏结束重开。要求单文件 HTML可以直接在浏览器打开运行。这个任务不算特别复杂但覆盖了 3D 游戏的核心环节足够看出差异。2.3 评测维度怎么定我没有用那种很虚的“代码质量”打分而是定了几个能实际验证的硬指标。第一个是首次运行通过率。模型生成完代码我不做任何修改直接保存成 HTML 文件用浏览器打开看能不能跑起来。这一步会筛掉很多看起来漂亮但实际有语法错误或者 API 用错的代码。第二个是核心功能完整度。跑起来之后我逐项检查角色能不能动、跳跃有没有重力感、障碍物会不会生成、碰撞有没有判定、分数有没有累加、游戏结束后能不能重开。每项算一个点满分六分。第三个是代码可维护性。这个稍微主观一点但我尽量量化函数平均长度、是否有重复代码块、关键逻辑有没有注释、变量命名是否表意。我会把三个模型的代码并排看找出结构上的差异。第四个是修改成本。我故意提一个后续需求比如“把角色移动改成带惯性滑行的”看模型能不能在原有代码基础上做增量修改而不是把整个文件重写一遍。这个能力在实际开发中特别重要因为没人是一次性把游戏写完的。3. 三个模型的实际生成过程与代码对比3.1 Step 5 Preview 的生成记录Step 5 Preview 我用的配置是温度 0.7top_p 0.9最大输出长度设了 8192。提示词发过去之后它大概用了四十多秒生成了完整代码总共 620 行左右。它的代码结构很清晰开头先定义了配置常量const CONFIG { gravity: -30, jumpForce: 12, moveSpeed: 8, laneWidth: 3, spawnInterval: 1.2, gameSpeed: 15 };这个做法我很欣赏。把所有可调参数集中在一个对象里后面调手感的时候不用满文件找数字。而且它给每个参数都起了有意义的名字gravity是重力加速度jumpForce是起跳初速度laneWidth是跑道宽度。你一看就知道改哪个能调出什么效果。角色控制部分它用了状态机的方式const playerState { isJumping: false, isSliding: false, velocityY: 0, currentLane: 0, targetLane: 0 };然后每帧根据输入更新targetLane再用插值让角色平滑移动到目标跑道。这个细节很关键。很多模型生成的代码是直接瞬移角色从一条道跳到另一条道没有过渡看起来就很生硬。Step 5 Preview 主动加了插值说明它理解“手感”这个概念。碰撞检测它用的是轴对齐包围盒AABB没有用更复杂的包围球或者 OBB。对于跑酷游戏来说这个选择是对的因为障碍物都是方块AABB 足够用而且计算量小。它把碰撞检测单独抽成了一个函数function checkCollision(playerBox, obstacleBox) { return ( playerBox.minX obstacleBox.maxX playerBox.maxX obstacleBox.minX playerBox.minY obstacleBox.maxY playerBox.maxY obstacleBox.minY playerBox.minZ obstacleBox.maxZ playerBox.maxZ obstacleBox.minZ ); }这个函数写得没问题六个条件覆盖了三个轴上的重叠判断。但有个小问题它没有做提前退出优化。如果第一个条件就不满足后面五个条件其实不用算。对于障碍物数量不多的场景影响不大但如果障碍物上百个每帧都全量计算就会浪费性能。这个我在后面的优化章节会讲怎么改。3.2 DeepSeek V4 Pro 的生成记录DeepSeek V4 Pro 我用的配置是温度 0.5top_p 0.85最大输出长度 8192。它生成得比较快大概三十秒左右代码 580 行。它的风格明显更紧凑。同样的配置参数它没有单独抽一个 CONFIG 对象而是直接写在各个函数里。比如重力加速度直接写在物理更新函数里function updatePhysics(dt) { player.velocityY -30 * dt; player.position.y player.velocityY * dt; if (player.position.y 0) { player.position.y 0; player.velocityY 0; player.isJumping false; } }这样写不是不行但后面你想调重力的时候得先找到这个函数。而且如果多个地方用到重力就容易出现改了一处漏了另一处的问题。不过 DeepSeek V4 Pro 在算法层面有亮点。它的障碍物生成用了对象池const obstaclePool []; function getObstacle() { for (let i 0; i obstaclePool.length; i) { if (!obstaclePool[i].active) { obstaclePool[i].active true; return obstaclePool[i]; } } const obs createObstacle(); obstaclePool.push(obs); return obs; }对象池是个好习惯避免频繁创建和销毁对象导致垃圾回收卡顿。对于跑酷这种障碍物不断生成和消失的游戏对象池能明显提升帧率稳定性。Step 5 Preview 的代码里没有用对象池每次生成障碍物都是新建对象障碍物移除后直接置空等 GC 回收。短时间玩没问题但如果连续玩几分钟GC 压力会累积。但 DeepSeek V4 Pro 的代码有个致命问题它忘了处理窗口大小变化。Three.js 的渲染器需要监听resize事件来更新相机宽高比和渲染器尺寸否则用户调整浏览器窗口后画面会拉伸变形。这个遗漏导致它的首次运行通过率扣了分。3.3 GLM5.3 的生成记录GLM5.3 我是在本地用 vLLM 部署的镜像版本用的是社区里讨论比较多的那个稳定版。温度设了 0.6top_p 0.9最大输出长度 8192。生成时间受本地硬件影响大概一分多钟代码 650 行。GLM5.3 的代码在结构上最接近我心目中“可维护”的标准。它把游戏拆成了几个模块每个模块用注释分隔// 场景初始化 // 玩家控制 // 障碍物管理 // 碰撞检测 // 游戏状态 这种注释分隔看起来简单但在你后面改代码的时候特别有用。你打开文件一眼就能定位到要改的模块不用从头读到尾。它的相机控制写得最细致。跑酷游戏的相机需要跟随角色但又不能跟得太死否则角色一动画面就晃玩久了会晕。GLM5.3 用了阻尼跟随const cameraTarget new THREE.Vector3( player.position.x * 0.5, player.position.y * 0.3 5, player.position.z 10 ); camera.position.lerp(cameraTarget, 0.1);这个lerp插值系数 0.1 意味着相机每帧向目标位置移动 10% 的距离产生一种柔和的跟随感。系数越小跟随越慢越柔和越大越紧跟。0.1 是个比较舒服的值我实测下来角色急转弯时相机不会猛甩。但 GLM5.3 也有个问题它的游戏结束判定有 bug。角色碰撞后它设置了gameOver true但主循环里没有检查这个标志位导致角色碰撞后游戏还在继续跑只是分数不再增加。这个 bug 在首次运行时不会报错但玩到碰撞那一刻就会发现不对劲。3.4 三个模型的核心差异对照我把关键维度的对比整理成表格方便你快速定位差异维度Step 5 PreviewDeepSeek V4 ProGLM5.3生成代码行数620580650首次运行通过是否缺 resize是核心功能完整度6/65/65/6结束判定 bug配置集中管理是否部分对象池否是否相机阻尼有无有注释密度中低高增量修改能力强中强这个表格不是要给模型排名而是让你看到每个模型的倾向性。Step 5 Preview 均衡DeepSeek V4 Pro 算法意识强但工程细节容易漏GLM5.3 工程结构好但逻辑校验需要加强。4. 实操复现从零跑起一个 3D 跑酷游戏4.1 环境准备与依赖选择不管你用哪个模型生成的代码跑起来的环境是一样的。你只需要一个现代浏览器Chrome 或者 Edge 都行。Three.js 通过 CDN 引入不需要本地安装 Node.js 或者打包工具。我用的 Three.js 版本是 r160CDN 地址是script srchttps://cdn.jsdelivr.net/npm/three0.160.0/build/three.min.js/script选这个版本是因为它稳定API 没有大改。有些新版本把Geometry彻底移除了老代码跑不起来。r160 还保留了一些兼容性适合快速原型开发。如果你要离线运行可以把 Three.js 下载到本地用相对路径引入。但注意浏览器的同源策略直接双击 HTML 文件打开时本地文件加载可能会被拦截。解决办法是起一个简单的本地服务器python -m http.server 8000然后在浏览器访问http://localhost:8000。这个命令在 Python 3 里自带不需要额外安装。4.2 场景搭建的关键参数3D 场景搭建有几个参数直接决定观感我逐个说明怎么调。相机视野FOV跑酷游戏建议用 60 到 75 度。太小了视野窄看不到两侧的障碍物太大了边缘畸变明显角色看起来变形。我实测 70 度比较舒服。const camera new THREE.PerspectiveCamera( 70, window.innerWidth / window.innerHeight, 0.1, 1000 );相机位置第三人称视角相机在角色后上方。我用的初始位置是(0, 5, 10)看向角色前方一点的位置。这个距离下角色占屏幕高度大概四分之一既能看清角色动作又能看到前方障碍物。光照至少要有环境光和方向光。环境光提供基础亮度方向光产生阴影和立体感。const ambientLight new THREE.AmbientLight(0xffffff, 0.6); scene.add(ambientLight); const directionalLight new THREE.DirectionalLight(0xffffff, 0.8); directionalLight.position.set(5, 10, 7); scene.add(directionalLight);环境光强度 0.6 加方向光 0.8总亮度大概 1.4画面不会过曝也不会太暗。方向光的位置在右上前方这样角色左侧会有阴影立体感比较强。雾效跑酷游戏加一点雾效可以掩盖远处障碍物突然出现的突兀感。用FogExp2指数雾密度设 0.02 左右。scene.fog new THREE.FogExp2(0x87ceeb, 0.02);雾的颜色设成天蓝色和背景色一致远处障碍物会逐渐融入背景视觉上更自然。4.3 角色控制的手感调优手感是跑酷游戏的灵魂。同样的逻辑参数差一点玩起来就完全不一样。移动速度水平移动速度设 8 单位每秒。这个速度下角色从一条道切到相邻道大概需要 0.4 秒不会太快导致难以控制也不会太慢显得拖沓。跳跃参数跳跃初速度 12重力 -30。这两个值决定了跳跃高度和滞空时间。跳跃高度公式是v² / (2g)代入得144 / 60 2.4单位。滞空时间公式是2v / g代入得24 / 30 0.8秒。0.8 秒的滞空时间足够玩家反应并调整落点。跑道切换插值角色切换到相邻跑道时用线性插值平滑过渡。插值速度设 10意味着每秒向目标位置移动 10 倍距离差。实际效果是切换过程大概 0.1 秒很快但不瞬移。player.position.x (targetX - player.position.x) * Math.min(1, 10 * dt);这里用Math.min(1, 10 * dt)是为了防止帧率波动时插值过头。如果某一帧 dt 特别大10 乘 dt 可能超过 1导致角色冲过目标位置再弹回来。限制在 1 以内就安全了。4.4 障碍物生成与难度曲线障碍物生成不能完全随机否则可能出现连续三个障碍物堵死所有跑道的情况玩家必死。我的做法是每次生成时随机选一到两条跑道放障碍物至少留一条空道。function spawnObstacles() { const laneCount 3; const blockedCount Math.random() 0.3 ? 2 : 1; const lanes [0, 1, 2]; const blocked []; for (let i 0; i blockedCount; i) { const idx Math.floor(Math.random() * lanes.length); blocked.push(lanes.splice(idx, 1)[0]); } blocked.forEach(lane createObstacle(lane)); }这段逻辑先决定这次堵几条道30% 概率堵两条70% 概率堵一条。然后从可用跑道里随机抽取抽一条就从数组里移除一条保证不会重复堵同一条道。难度曲线通过生成间隔来控制。游戏开始时生成间隔 1.2 秒随着分数增加逐渐缩短最低到 0.6 秒。const interval Math.max(0.6, 1.2 - score * 0.001);分数每增加 100间隔缩短 0.1 秒。到 600 分时间隔降到 0.6 秒并保持不变。这个曲线我实测下来新手能撑到 300 分左右熟练后能到 800 分以上。4.5 碰撞检测的优化写法前面提到 Step 5 Preview 的碰撞检测没有提前退出。我把它改成了带提前退出的版本function checkCollision(a, b) { if (a.maxX b.minX || a.minX b.maxX) return false; if (a.maxY b.minY || a.minY b.maxY) return false; if (a.maxZ b.minZ || a.minZ b.maxZ) return false; return true; }三个轴依次判断任何一个轴不重叠就立即返回 false。对于跑酷游戏大部分障碍物在 Z 轴上就和玩家不重叠所以第一个 Z 轴判断就能筛掉大部分实际计算量比全量判断少很多。另外包围盒不需要每帧重新计算。角色的包围盒只在位置变化时更新障碍物的包围盒在创建时算一次就行。我见过有些代码每帧对每个障碍物重新计算包围盒那是纯浪费。5. 踩坑记录与常见问题排查5.1 模型生成代码的典型问题速查我把三个模型生成代码时暴露的问题整理成表格你复现的时候可以对照检查问题现象可能原因排查方法修复方式画面全黑相机位置在物体内部或朝向错误打印相机 position 和 lookAt调整相机位置到场景外角色穿模碰撞检测未生效或包围盒尺寸不对在碰撞函数里打日志检查包围盒 min/max 计算帧率骤降每帧创建新对象导致 GC 频繁用 Performance 面板看内存曲线引入对象池复用对象窗口拉伸变形未监听 resize 事件调整浏览器窗口观察添加 resize 监听更新相机跳跃后悬空重力未持续应用或落地判定缺失打印 velocityY 和 position.y确保每帧更新物理障碍物重叠生成时未检查已有障碍物位置打印每次生成的跑道号生成前查询该跑道是否占用5.2 我实际踩过的三个坑第一个坑是 Three.js 的坐标系。Three.js 默认 Y 轴向上Z 轴指向屏幕外。我一开始按某些引擎的习惯把 Z 轴当向上结果角色直接飞到屏幕外面去了。后来统一用 Y 轴做垂直方向Z 轴做前进方向才正常。这个坑不复杂但如果你同时用多个引擎很容易搞混。第二个坑是 delta time 的处理。游戏循环里必须用requestAnimationFrame提供的时间戳计算 delta time不能用固定值。我一开始图省事每帧固定减 0.016 秒结果在高刷新率屏幕上游戏速度翻倍在低帧率设备上又慢得像幻灯片。正确做法是let lastTime 0; function animate(time) { const dt Math.min((time - lastTime) / 1000, 0.1); lastTime time; update(dt); renderer.render(scene, camera); requestAnimationFrame(animate); }这里用Math.min限制 dt 最大 0.1 秒防止切后台再切回来时 dt 过大导致角色瞬移。第三个坑是 GLM5.3 的游戏结束 bug。它设置了gameOver标志但主循环没检查。我修复的方式是在 update 函数开头加判断function update(dt) { if (gameOver) return; // ... 正常更新逻辑 }这样游戏结束后所有更新都停止画面定格玩家只能点重开按钮。这个修复很简单但如果你没注意到测试的时候可能以为游戏还在正常运行。5.3 增量修改的实操演示我拿 Step 5 Preview 的代码做增量修改测试需求是“把角色移动改成带惯性滑行的”。它的处理方式是先定位到移动相关的代码段然后在速度计算里加入加速度和摩擦力// 原代码 player.position.x (targetX - player.position.x) * Math.min(1, 10 * dt); // 修改后 const accel 40; const friction 8; if (input.left) player.velocityX - accel * dt; if (input.right) player.velocityX accel * dt; player.velocityX - player.velocityX * friction * dt; player.position.x player.velocityX * dt;它没有重写整个文件只改了移动相关的几行其他部分保持不动。这个增量修改能力在实际开发中很关键因为游戏调手感往往要改几十次每次重写整个文件既浪费时间又容易引入新 bug。DeepSeek V4 Pro 在增量修改时倾向于重写整个移动函数虽然结果也对但改动范围大review 起来费劲。GLM5.3 的增量修改和 Step 5 Preview 差不多都能精准定位到需要改的代码段。6. WorkBuddy 工作流接入与私有化部署建议6.1 把模型接进 WorkBuddy 的实操步骤WorkBuddy 这类工作台工具的核心价值是把模型能力封装成可复用的技能skill。你不需要每次手动复制提示词而是把“生成 3D 游戏代码”这个任务定义成一个 skill以后直接调用。我配置的步骤大致是这样先在工作台里新建一个 skill名称填“3D游戏原型生成”描述写清楚输入输出。输入是游戏类型和核心玩法描述输出是单文件 HTML 代码。然后在 skill 的指令部分写清楚约束条件比如“使用 Three.js r160”、“单文件不超过 800 行”、“必须包含 resize 处理”。这里有个经验给 WorkBuddy 定规则的时候规则要具体可验证。不要写“代码质量要好”要写“每个函数不超过 50 行”、“关键逻辑必须有注释”、“必须处理窗口 resize”。具体的规则模型才能执行模糊的规则等于没写。如果你要给所有任务定通用规则可以在工作台的全局设置里加自定义指令。比如“所有生成的代码必须包含错误处理”、“所有输出必须用中文注释”。这些规则会对后续所有任务生效不用每个 skill 重复配置。6.2 私有化部署的镜像选择GLM5.3 用 vLLM 部署时镜像版本的选择直接影响推理速度和稳定性。社区里讨论比较多的几个版本我实测下来比较稳的是基于 CUDA 12.1 的那个。选镜像主要看三点CUDA 版本要和你的显卡驱动匹配vLLM 版本要支持模型架构Python 版本不要用太新的。部署命令大概是这样python -m vllm.entrypoints.openai.api_server \ --model /path/to/glm5.3 \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9tensor-parallel-size设成你的显卡数量两张卡就设 2。max-model-len设 8192 够用再大显存吃不消。gpu-memory-utilization设 0.9 留一点余量给系统。部署好之后WorkBuddy 里配置模型地址指向本地 API 端点就行。这样你的代码生成任务全部走本地推理不依赖外部服务数据也不出内网。6.3 缓存目录迁移与性能优化WorkBuddy 默认把系统缓存放在 C 盘用久了 C 盘空间会紧张。如果你想把缓存目录改到 D 盘可以在设置里找缓存路径配置项改成D:\workbuddy_cache之类的路径。改完之后重启工作台生效。另外跨对话记忆这个 skill 很实用。它能让模型记住你之前项目里用过的技术栈和代码风格后续生成时保持一致。比如你之前用 Three.js 做游戏下次再让它生成游戏代码它会自动沿用 Three.js 而不是换成别的引擎。这个功能对于长期维护一个项目特别有用。7. 我个人的选型建议三个模型我都实际跑过完整流程说点实在的选型建议。如果你是要快速出原型、代码一次跑通的概率要高Step 5 Preview 是我目前的首选。它的均衡性最好不会在某一个环节掉链子。尤其是长代码生成时的一致性保持目前我用下来是最稳的。如果你对性能优化有要求、项目里对象创建频繁DeepSeek V4 Pro 的对象池意识值得借鉴。但你要自己补上工程细节比如 resize 处理、配置集中管理这些。它适合有一定经验、能自己兜底的开发者。如果你要私有化部署、把模型接进自己的工作流GLM5.3 的工程化配套最成熟。vLLM 部署的坑社区里都踩过了你照着文档走基本能跑通。生成代码的结构也最规整适合团队协作场景。最后分享一个小技巧不管用哪个模型生成完代码后先别急着改直接跑一遍看报什么错。报错信息往往能告诉你模型在哪个环节理解偏了。根据报错去调提示词比盲目改代码效率高得多。我通常会把报错信息原样贴回给模型让它自己修大部分情况下它能修对。
