三大模型3D游戏实测：Step 5、DeepSeek V4 Pro、GLM5.3谁更强

1. 三款模型同台做3D游戏，我为什么选这个题

最近圈子里聊得最多的，除了各家模型又发了什么新版本，就是"到底哪个模型能真正把一个小游戏从头写到尾"。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字被反复提起，但大多数讨论都停留在跑分和对话体验上，真正拿同一个3D游戏需求去横向实测的内容少得可怜。我自己平时用 WorkBuddy 做工作台调度，也踩过不少"模型说能写、实际跑不起来"的坑，所以干脆花了两天时间，把这三个模型拉到同一个任务上，用同一套提示词、同一个验收标准，看看到底谁能把3D游戏真正做出来。

这篇内容适合三类人看：一是想用大模型辅助做3D小游戏但不知道选哪个的独立开发者；二是已经在用 WorkBuddy 或类似工作台、想搞清楚模型能力边界的效率工具用户；三是单纯好奇"现在的大模型写3D游戏到底到什么水平"的技术爱好者。我会把整个实测过程、每个模型的表现、踩到的坑、以及最后怎么把能跑的东西真正跑起来，全部摊开讲清楚。核心不是比谁分数高，而是比谁交付的东西能玩。

先说结论方向：三个模型都能生成可运行的3D场景代码，但差距体现在"能不能一次跑通""物理和交互是否合理""代码结构是否可维护"这三个维度上。下面我按实测流程一步步拆。

2. 实测前的准备：任务定义、环境与验收标准

2.1 为什么要把任务卡死在"3D游戏"这个范围

大模型写代码的能力，在2D小游戏上早就被验证得差不多了，贪吃蛇、打砖块这类需求，基本都能一次生成。但3D游戏是另一个量级：它涉及场景图管理、相机投影、光照、物理碰撞、渲染循环，任何一个环节出错，画面就是黑的或者直接报错。我选3D游戏作为测试任务，就是因为它能同时压测模型的空间理解能力、库选型能力、以及跨文件组织代码的能力，这三点恰好是区分模型实用性的关键。

具体任务我定得很明确：做一个"3D 收集类小游戏"，玩家控制一个方块在平面上移动，场景里随机分布若干可收集的金色小球，碰到就加分，全部收集完显示胜利。要求有相机跟随、有基础光照、有分数UI、能用键盘WASD控制。这个需求不大不小，既不会因为太简单而看不出差距，也不会因为太复杂导致三个模型都翻车。

2.2 环境准备与 WorkBuddy 工作台配置

我用的运行环境是本地一台 Ubuntu 机器，Node.js 20 版本，浏览器用 Chrome。三个模型的调用都通过 WorkBuddy 工作台统一调度，这样能保证提示词、上下文长度、温度参数尽量一致。WorkBuddy 的工作台模式很适合这种横向对比，因为它可以把同一个任务分发给不同模型，还能保留每个模型的完整对话记录，方便我事后逐行对比代码差异。

提示：做模型横向实测时，一定要固定温度参数和最大输出长度。我这次统一用温度 0.3、最大输出 8192 token，避免因为随机性导致结果不可比。

WorkBuddy 里我提前配好了三条自定义指令，分别对应三个模型，指令内容完全一致，只改模型名。这里有个小技巧：把"输出完整可运行代码，不要省略任何部分，不要用省略号代替代码"这句话写进系统指令里，能显著减少模型偷懒输出伪代码的情况。我试过不加这句，三个模型都有不同程度的"此处省略若干行"，加了之后明显改善。

2.3 验收标准：什么叫"做出来了"

我给自己定了四条硬标准，缺一不可：

1. 代码能直接运行：复制到本地，起一个静态服务器，打开浏览器能看到3D画面，不报错。
2. 交互正常：WASD能控制方块移动，相机跟随不穿模。
3. 游戏逻辑完整：小球能被收集，分数能增加，收集完有胜利提示。
4. 代码可读：结构清晰，变量命名合理，没有大段复制粘贴的冗余。

这四条里，第一条是生死线。很多模型生成的代码看着漂亮，一跑就报错，这种直接判不合格。下面进入正题，逐个看三个模型的表现。

3. 三个模型的实际表现逐项拆解

3.1 Step 5 Preview：一次跑通，但细节偏保守

Step 5 Preview 给我的第一印象是"稳"。它选的技术栈是 Three.js，这是3D网页游戏最主流的选择，说明它对生态有基本判断。生成的代码结构是单文件 HTML，把场景初始化、游戏逻辑、渲染循环都放在一个 script 标签里，虽然不够模块化，但对于这种小游戏来说完全够用。

我把它生成的代码直接存成step5.html，用python3 -m http.server起服务，打开浏览器——画面直接出来了。一个灰色平面，上面一个蓝色方块，散落着几个金色小球，相机在斜上方跟随。WASD 按下去，方块动了，相机跟着走，碰到小球分数从0变1。整个过程零报错，一次跑通。

但细看代码，Step 5 Preview 有几个保守的地方。第一，它没用任何物理引擎，碰撞检测是自己写的简单距离判断，这在平面上够用，但如果需求变成"方块会掉落"就不行了。第二，光照用的是最基础的AmbientLight加一个DirectionalLight，没有阴影，画面偏平。第三，它把移动速度写死成常量，没有做帧率补偿，在高刷新率屏幕上移动会偏快。

// Step 5 Preview 生成的移动逻辑（简化） const speed = 0.1; if (keys['w']) cube.position.z -= speed; if (keys['s']) cube.position.z += speed; if (keys['a']) cube.position.x -= speed; if (keys['d']) cube.position.x += speed;

这段代码能跑，但speed是每帧固定值，没有乘以deltaTime。我在144Hz屏幕上测，方块移动速度明显比60Hz快一倍多。这是个典型的"能跑但不严谨"的问题，新手容易忽略，实际做游戏必须修。

3.2 DeepSeek V4 Pro：结构最专业，但首次运行报错

DeepSeek V4 Pro 的表现是三个里最"工程化"的。它没有用单文件，而是主动拆成了index.html、main.js、game.js三个文件，还写了一个简单的模块导入结构。技术栈同样是 Three.js，但它额外引入了cannon-es做物理，说明它考虑到了后续扩展性。

问题出在首次运行。我按它给的目录结构放好文件，起服务打开，控制台直接报错：Failed to resolve module specifier "three"。原因是它用了 ES Module 的import语法，但没有提供 importmap 或者打包配置。这是很多模型生成前端代码的通病——它们知道要用模块化，但忽略了浏览器原生 ES Module 需要明确的路径映射。

我手动加了一段 importmap 才跑起来：

<script type="importmap"> { "imports": { "three": "https://unpkg.com/three@0.160.0/build/three.module.js", "cannon-es": "https://unpkg.com/cannon-es@0.20.0/dist/cannon-es.js" } } </script>

加上之后，画面出来了，而且效果是三个里最好的：有阴影、有物理碰撞、方块移动带惯性。但代价是首次运行失败，对新手不友好。DeepSeek V4 Pro 的代码质量最高，但它默认使用者具备一定前端工程能力，这个假设在实际使用中会劝退一部分人。

3.3 GLM5.3：逻辑完整，但渲染细节有硬伤

GLM5.3 走的是另一条路。它没有用 Three.js，而是选了babylon.js。这个选择本身没问题，Babylon 在3D游戏方面甚至更专业。代码结构是单文件，逻辑写得很完整，分数UI、胜利判定、甚至重新开始按钮都做了。

但渲染上有个硬伤：它把相机初始位置设在了方块正上方垂直向下看，导致整个场景看起来是2D俯视，完全没有3D纵深感。我翻代码发现它camera.position.set(0, 10, 0)然后camera.lookAt(0, 0, 0)，这是典型的"能显示但没理解3D"的问题。我手动把相机改成(0, 8, 12)斜视角，画面立刻正常了。

另外 GLM5.3 的碰撞检测用的是包围盒，但它在每帧都重新计算所有小球的包围盒，没有做空间优化。小球数量少的时候没问题，我手动加到200个小球，帧率从60掉到20左右。这个性能问题在小场景里不暴露，但说明它的代码没有考虑扩展性。

3.4 三个模型横向对比表

这张表是我实测后的主观打分，但每一项都有具体的代码和运行结果支撑。下面讲怎么把这些代码真正用起来。

4. 从生成代码到可玩游戏的关键改造

4.1 帧率补偿：让移动速度不再依赖刷新率

三个模型里只有 DeepSeek V4 Pro 主动做了帧率补偿，另外两个都需要手动改。原理很简单：把"每帧移动固定距离"改成"每秒移动固定距离乘以帧间隔时间"。Three.js 的渲染循环里有个clock对象，可以拿到deltaTime。

const clock = new THREE.Clock(); function animate() { requestAnimationFrame(animate); const delta = clock.getDelta(); const speed = 5; // 每秒移动5个单位 if (keys['w']) cube.position.z -= speed * delta; if (keys['s']) cube.position.z += speed * delta; if (keys['a']) cube.position.x -= speed * delta; if (keys['d']) cube.position.x += speed * delta; renderer.render(scene, camera); }

改完之后，不管屏幕是60Hz还是144Hz，方块移动速度都一致。这个改动看着小，但它是"玩具代码"和"能用的游戏代码"之间的分界线。我建议所有用大模型生成游戏代码的人，第一件事就是检查有没有帧率补偿。

4.2 相机跟随的平滑处理

Step 5 Preview 和 GLM5.3 的相机都是硬跟随，方块一动相机瞬间跟过去，视觉上很生硬。DeepSeek V4 Pro 用了插值，手感明显好。插值的原理是让相机位置每帧向目标位置靠近一部分，而不是直接跳过去。

// 相机平滑跟随 const cameraOffset = new THREE.Vector3(0, 8, 12); const targetPos = cube.position.clone().add(cameraOffset); camera.position.lerp(targetPos, 0.1); // 0.1是插值系数 camera.lookAt(cube.position);

lerp的第二个参数是插值速度，0.1 表示每帧靠近目标10%，数值越大跟随越紧，越小越飘。我实测 0.1 到 0.15 之间手感最好，太小会有延迟感，太大又变回硬跟随。这个参数没有标准答案，得根据游戏节奏调。

4.3 碰撞检测的优化思路

GLM5.3 的性能问题出在每帧遍历所有小球算距离。优化方法是用空间换时间，把场景划分成网格，只检测方块所在网格及相邻网格里的小球。不过对于这种小游戏，更简单的做法是给小球加一个"已收集"标记，收集后直接从场景移除，减少遍历数量。

// 收集检测优化 for (let i = balls.length - 1; i >= 0; i--) { const ball = balls[i]; if (cube.position.distanceTo(ball.position) < 1.2) { scene.remove(ball); balls.splice(i, 1); score++; updateScoreUI(); } }

注意这里用了倒序遍历，因为splice会改变数组长度，正序遍历会漏掉元素。这是个经典坑，我见过不少模型生成的代码在这里出错。另外距离阈值 1.2 是根据方块和小球的尺寸算出来的，方块边长1、小球半径0.3，加起来约1.3，取1.2稍微紧一点，手感更准。

4.4 用 WorkBuddy 做多模型协作的实操

这次实测我其实用了一个 WorkBuddy 的进阶玩法：把三个模型的输出汇总到同一个工作台会话里，让它们互相"评审"。具体做法是新建一个会话，把 Step 5 Preview 的代码贴进去，然后问"这段代码有什么问题"，再拿 DeepSeek V4 Pro 的回答去问 GLM5.3。这样能快速定位单个模型看不到的盲区。

WorkBuddy 的跨对话记忆功能在这里很有用，它能记住我之前设定的验收标准，不用每次重复。我配了一条自定义指令："所有代码评审必须对照四条验收标准逐条检查"，这样每个模型的评审输出都结构化，方便对比。这个用法比单纯让一个模型写代码效率高得多，相当于用三个模型的视角互相补位。

注意：多模型协作时，上下文会迅速膨胀。WorkBuddy 默认的上下文窗口有限，建议每轮评审后手动清理无关历史，只保留核心代码和结论，否则后面的回答质量会下降。

5. 实测中踩到的坑与排查速查表

5.1 那些让我卡了半小时以上的问题

第一个坑是 Three.js 版本问题。Step 5 Preview 生成的代码用的是旧版 API，比如THREE.Geometry，这个类在新版里已经被移除了。我一开始直接跑报错，查了半天才发现是版本不匹配。解决办法是锁定 Three.js 版本，或者让模型明确用新版 API。我后来在提示词里加了"使用 Three.js r160 及以上版本的 API"，就没再出过这个问题。

第二个坑是 GLM5.3 的 Babylon.js 场景默认没有开抗锯齿，方块边缘锯齿很明显。加上new BABYLON.Engine(canvas, true)第二个参数设为 true 就开了。这种细节模型不会主动提，得自己知道。

第三个坑最隐蔽：DeepSeek V4 Pro 生成的物理代码里，方块的质量设成了0，导致碰撞时方块纹丝不动，小球直接被弹飞。物理引擎里质量0意味着无限大质量，这个设定在静态物体上没问题，但玩家控制的方块必须是动态的。我把它改成1才正常。

5.2 常见问题速查表

这张表里的每一条都是我实际遇到并解决过的，不是从文档里抄的。新手照着排查，能省下大量试错时间。

5.3 三个模型各自的"脾气"与应对策略

用久了会发现每个模型有自己的偏好。Step 5 Preview 偏保守，生成的代码安全但不够出彩，适合要快速拿到能跑的东西、不追求效果的场景。DeepSeek V4 Pro 偏工程化，代码质量高但假设你有一定基础，适合有一定前端经验的人。GLM5.3 偏功能完整，逻辑写得多但渲染细节容易翻车，适合需要快速搭出功能框架、后续自己调优的场景。

我的策略是：先用 Step 5 Preview 拿到一个能跑的基础版本，再用 DeepSeek V4 Pro 的代码做结构参考，最后用 GLM5.3 补功能细节。三个模型各取所长，比死磕一个效率高。这个组合用法我在 WorkBuddy 里配成了一套工作流，新建任务时直接调用，省得每次重新组织提示词。

6. 把游戏真正发布出去的收尾工作

代码跑通只是第一步，要真正分享给别人玩，还得处理几件事。首先是资源路径问题，如果用了 CDN 引入 Three.js，要确保 CDN 稳定，或者把库文件下载到本地。我一般把 Three.js 下载到libs目录，用相对路径引入，这样离线也能跑。

其次是性能适配。移动端浏览器对 WebGL 的支持参差不齐，我加了一个简单的降级判断：如果检测不到 WebGL 上下文，就显示提示文字而不是白屏。这个判断代码很短，但能避免用户打开一片空白不知道发生了什么。

if (!renderer.capabilities.isWebGL2 && !renderer.capabilities.isWebGL) { document.body.innerHTML = '<p>当前浏览器不支持3D渲染，请更换浏览器</p>'; }

最后是操作提示。三个模型生成的代码都没有在页面上显示操作说明，玩家打开不知道按什么键。我加了一行固定的 UI 文字"WASD 移动，收集所有金球获胜"，放在左上角。这种小细节模型不会主动做，但它是"能玩"和"好玩"之间的差距。

发布的话，WorkBuddy 工作台可以直接把生成的静态文件打包，我试过用它生成一个简单的分享页面，把 HTML 和 JS 打包成一个压缩包，解压后起个静态服务就能访问。如果要放到公网，任何静态托管服务都行，因为整个游戏就是纯前端，没有后端依赖。

7. 我个人的几点实测体会

折腾完这一轮，最大的感受是：现在的大模型做3D游戏，已经过了"能不能做"的阶段，进入了"做得好不好、要不要返工"的阶段。三个模型都能在几分钟内给出可运行的3D场景，这个能力放在两年前是不可想象的。但它们的差距也很明显，而且差距不在"会不会写代码"，而在"懂不懂游戏开发的常识"——帧率补偿、相机插值、碰撞优化这些，都是经验性的东西，模型还在学。

如果你也想做类似的实测，我的建议是别只看模型输出的代码漂不漂亮，一定要跑起来。我见过太多"看起来完美、一跑就崩"的生成代码。跑起来之后，重点看三件事：移动手感顺不顺、画面有没有立体感、小球多了会不会卡。这三件事过关了，代码基本就能用。

另外，WorkBuddy 这类工作台在横向对比时的价值，比单模型使用大得多。它能把多个模型的输出放在一起对比，还能用自定义指令统一约束输出格式，省去了大量手动整理的工作。我现在的习惯是，任何稍微复杂点的生成任务，都至少跑两个模型，取长补短。这个习惯帮我避开了不少单模型的盲区。

最后分享一个小技巧：让模型生成代码时，明确要求它"在代码注释里标注每个关键参数的作用和取值范围"。这样拿到代码后，调参不用猜，直接看注释就知道哪个数值控制什么。我试过加这条要求，三个模型的输出可读性都提升了一个档次，尤其是 DeepSeek V4 Pro，注释写得比我自己写的还清楚。