1. 三款模型同台竞技：这个对比测试到底在测什么

1.1 为什么选"3D游戏"作为统一考题

拿三个不同的大模型去做同一个3D游戏，这个思路本身就很有意思。3D游戏开发是一个典型的"复合型任务"——它不像写一个排序算法那样边界清晰，也不像生成一段文案那样可以靠语感糊弄过去。一个能跑起来的3D游戏，至少同时考验模型的这几项能力：

• 空间想象力：三维坐标系、相机视角、光照方向、物体变换，这些东西在文字描述里是抽象的，模型必须在"脑子里"构建出一个可运行的空间结构。
• 代码组织能力：3D游戏通常涉及场景初始化、渲染循环、输入处理、碰撞检测、状态管理等多个模块，代码量不小，模型得有全局架构意识。
• API记忆精度：不管是Three.js、Babylon.js还是其他3D库，函数名、参数顺序、坐标系约定都不能记错，错一个参数可能整个场景就是黑的。
• 调试推理能力：第一版代码几乎不可能一次跑通，模型能不能根据报错信息定位问题、给出修复方案，这才是真正的分水岭。

所以用3D游戏做横向对比，比让三个模型写"Hello World"或者做个待办清单要有说服力得多。它把模型的综合工程能力压缩到了一个可直观验证的产物上——游戏能不能跑、画面对不对、操作顺不顺，一眼便知。

1.2 三个选手的定位差异

Step 5 Preview、DeepSeek V4 Pro、GLM5.3这三个名字放在一起，其实代表了当前大模型赛道里几种不同的技术路线取向。Step 5 Preview从命名看是一个预览版本，通常意味着它在某些能力上做了前瞻性尝试，可能在多模态或者长上下文处理上有独特设计。DeepSeek V4 Pro走的是深度推理路线，在复杂逻辑链条和数学推理方面积累了不少口碑，代码生成时倾向于"想清楚再写"。GLM5.3则是国产模型里迭代比较快的一支，在中文语境理解和工程实用性上打磨得比较细。

这三个模型做同一个3D游戏，差异不会只体现在"谁写得更快"上，更关键的是代码风格、架构选择、以及对3D开发范式的理解深度。有的模型可能倾向于把所有逻辑塞进一个文件里快速出活，有的可能会主动拆分模块、加注释、做错误处理。这些差异在简单任务里看不出来，但在3D游戏这种中等复杂度项目上会暴露得很明显。

1.3 测试的边界与合理预期

需要提前说清楚的是，这类对比测试不是严谨的学术评测。同一个提示词在不同时间、不同温度参数下，模型输出都会有波动。而且"3D游戏"这个范围太宽了——是做一个旋转的立方体，还是一个有角色移动、碰撞、计分的完整小游戏，难度差了好几个数量级。

所以我在实际测试时，会把任务定义得尽量具体：一个基于Web的3D场景，包含可移动的角色、固定的障碍物、简单的碰撞反馈和计分逻辑。这样三个模型面对的是同一道题，产出的代码才有可比性。至于最终谁赢谁输，其实没那么重要，重要的是通过这个过程看清楚每个模型在3D开发场景下的真实工作方式和能力边界。

2. 实测环境搭建与提示词设计

2.1 运行环境与依赖准备

为了让三个模型的产出能在同一套环境下公平对比，我把运行环境统一成了浏览器端。原因很简单：Web 3D方案不需要编译工具链，打开浏览器就能跑，排除了环境差异带来的干扰。具体配置如下：

• 渲染库：Three.js（r160以上版本），通过CDN引入，避免本地打包的复杂性。
• 浏览器：Chrome最新稳定版，开启硬件加速。
• 本地服务：用一个简单的静态文件服务器托管HTML和JS文件，避免直接打开文件时的跨域限制。
• 辅助工具：浏览器开发者工具的控制台和性能面板，用来观察报错和帧率。

提示：如果你也想复现这个测试，建议用npx serve或者Python自带的http.server起一个本地服务，直接双击HTML文件在某些浏览器下会因为模块加载策略而报错。

2.2 统一提示词的设计思路

提示词的设计直接决定了对比的有效性。我试过几版之后，最终定下来的提示词结构是这样的：

请用Three.js编写一个完整的3D小游戏，要求： 1. 场景中包含一个地面平面和一个可控制的主角方块 2. 使用方向键控制主角在地面上移动 3. 场景中随机分布若干障碍物，主角碰到障碍物时计分减一 4. 场景中随机分布若干收集物，主角碰到时计分加一 5. 相机跟随主角移动，保持第三人称视角 6. 页面显示当前分数 7. 所有代码放在一个HTML文件中，可直接在浏览器运行

这个提示词的好处是：需求足够具体，减少了模型自由发挥带来的不可比性；同时又留了一定的实现空间，能看出模型在架构和细节处理上的差异。比如"相机跟随"这个需求，有的模型会用简单的偏移量跟随，有的会做平滑插值，有的甚至会加阻尼效果，这些差异很能说明问题。

2.3 评测维度的确定

光看"能不能跑"太粗糙了。我给自己定了一套打分维度，每个维度按1到5分评估：

权重设置上，我把"一次通过率"和"功能完整度"放得最高，因为这两个直接决定了模型产出的可用性。视觉表现权重最低，因为3D游戏的画面精细度更多取决于美术资源，而不是模型能力。

3. 三个模型的实战表现拆解

3.1 Step 5 Preview：架构意识最强但细节有瑕疵

Step 5 Preview给我的第一印象是"想得比较多"。它生成的代码没有把所有逻辑堆在一个init()函数里，而是主动拆成了几个模块：场景初始化、角色控制、碰撞检测、UI更新各自独立。这种架构意识在三个模型里是最突出的。

它的角色控制用了Vector3做速度累加，而不是直接修改位置，这意味着它考虑了加速度和摩擦力的概念。实际跑起来，角色的移动确实有一点惯性感，松开方向键后会滑行一小段距离，手感比"按下即动、松开即停"要自然。

但问题也出在这里。它的碰撞检测用的是简单的包围盒判断，但没有考虑角色移动速度较快时可能"穿透"障碍物的情况。我在测试时把移动速度调高，角色就直接穿过了障碍物，计分逻辑也没触发。这是一个典型的"想对了方向但没做完整"的问题。

另外，Step 5 Preview生成的代码里有一个变量作用域的问题——它在碰撞检测函数里引用了一个在另一个函数内部定义的变量，导致运行时报undefined。这个错误不算严重，控制台会直接指出行号，改起来很快，但确实影响了它的一次通过率。

3.2 DeepSeek V4 Pro：逻辑最严谨，代码最"教科书"

DeepSeek V4 Pro的产出明显带着一种"工程严谨"的气质。它的代码注释写得非常规范，每个函数上面都有说明用途和参数的注释块。变量命名也很讲究，比如playerVelocity、obstacleList、scoreDisplay，一看就知道是什么。

它的碰撞检测做得最扎实。不仅用了包围盒，还加了基于时间的步进检测，把每一帧的移动拆成多个小步来检测碰撞，有效避免了高速穿透问题。这个细节说明它在生成代码时确实"想过"实际运行中可能遇到的问题。

相机跟随部分，DeepSeek V4 Pro用了lerp插值，让相机平滑地追向目标位置，而不是硬邦邦地直接赋值。实际体验下来，镜头移动最舒服，没有突兀的跳动感。

但它也有一个明显的短板：代码量偏大，结构偏保守。整个HTML文件超过了600行，其中有不少是为了"完整性"而加的防御性代码，比如对每个DOM元素都做了存在性检查。这些代码在理论上没错，但在一个自包含的演示页面里显得有些冗余。而且它的场景视觉表现比较朴素，就是基本的几何体和默认材质，没有主动加光照优化或者阴影效果。

3.3 GLM5.3：实用主义，出活最快

GLM5.3的风格和前两个都不一样。它的代码最"接地气"——没有复杂的架构分层，也没有大段的注释，就是把功能实现出来，代码紧凑，能跑就行。

它的优势在于一次通过率最高。三个模型里，只有GLM5.3的首次生成代码我直接打开浏览器就能跑，没有任何报错。它的碰撞检测用的是最简单的距离判断，虽然没有DeepSeek那么精细，但在正常移动速度下完全够用，不会出现穿透。

GLM5.3在交互上做了一个小细节：它给角色移动加了边界限制，角色不会跑出地面平面的范围。这个需求提示词里没写，但它主动加了，说明它在生成代码时考虑了"用户实际玩的时候会遇到什么"。

视觉方面，GLM5.3是唯一一个主动加了环境光和方向光的模型，场景看起来有明暗层次，不是一片死平。它还用了MeshStandardMaterial而不是默认的MeshBasicMaterial，让物体对光照有反应。

但它的代码结构确实比较"扁平"，所有逻辑都在一个大的animate()循环里，变量也都是全局的。如果后续要扩展功能，改起来会比较麻烦。另外它的注释几乎没有，对于想学习代码的人来说不太友好。

3.4 三家横向对比速查

把三个模型的表现整理成一张表，看得更清楚：

从这张表能看出来，三个模型其实代表了三种不同的"性格"：Step 5 Preview像个有想法但偶尔粗心的架构师，DeepSeek V4 Pro像个严谨到有点啰嗦的老工程师，GLM5.3像个手脚麻利、先跑起来再说的实干派。

4. 关键代码环节的深度剖析

4.1 角色移动控制的三种实现路径

角色移动是3D游戏里最基础也最能看出功力的部分。三个模型在这块的处理方式差异很大，值得单独拎出来说。

Step 5 Preview用的是速度累加模型：

// Step 5 Preview 风格 const acceleration = 0.02; const friction = 0.92; let velocity = new THREE.Vector3(0, 0, 0); function updatePlayer() { if (keys.ArrowUp) velocity.z -= acceleration; if (keys.ArrowDown) velocity.z += acceleration; if (keys.ArrowLeft) velocity.x -= acceleration; if (keys.ArrowRight) velocity.x += acceleration; velocity.multiplyScalar(friction); player.position.add(velocity); }

这种写法的好处是移动有"重量感"，角色不会瞬间启停。但friction和acceleration这两个参数需要调，调不好要么滑得像在冰上，要么迟钝得像在泥里。Step 5 Preview给的默认值还算合理，但不同帧率下表现会不一致，因为它没有做deltaTime归一化。

DeepSeek V4 Pro用的是基于deltaTime的位移模型：

// DeepSeek V4 Pro 风格 const moveSpeed = 5.0; // 单位：单位/秒 const clock = new THREE.Clock(); function updatePlayer(deltaTime) { const direction = new THREE.Vector3(0, 0, 0); if (keys.ArrowUp) direction.z -= 1; if (keys.ArrowDown) direction.z += 1; if (keys.ArrowLeft) direction.x -= 1; if (keys.ArrowRight) direction.x += 1; if (direction.length() > 0) { direction.normalize(); player.position.addScaledVector(direction, moveSpeed * deltaTime); } }

这个写法是3D游戏开发的标准做法。deltaTime保证了不同帧率下移动速度一致，normalize()保证了斜向移动不会比直线移动快。DeepSeek V4 Pro在这里展现了对游戏循环的正确理解。

GLM5.3用的是直接位移模型：

// GLM5.3 风格 const speed = 0.1; function updatePlayer() { if (keys.ArrowUp) player.position.z -= speed; if (keys.ArrowDown) player.position.z += speed; if (keys.ArrowLeft) player.position.x -= speed; if (keys.ArrowRight) player.position.x += speed; }

最简单直接，没有deltaTime，没有归一化。在60帧的显示器上跑没问题，但如果帧率波动，移动速度就会跟着变。斜向移动也会比直线快约41%。不过对于一个小演示来说，这些瑕疵用户基本感知不到。

实操心得：如果你自己要写3D游戏，移动控制这块直接抄DeepSeek V4 Pro的deltaTime方案。它是唯一一个在帧率变化时还能保持手感一致的写法，而且代码量并不大。

4.2 碰撞检测的精度与性能权衡

碰撞检测是三个模型拉开差距最明显的地方。

Step 5 Preview和GLM5.3都用了简单的距离判断：

// 距离判断 const distance = player.position.distanceTo(obstacle.position); if (distance < collisionRadius) { // 触发碰撞 }

这种写法把角色和障碍物都当成球体来处理，计算量极小，在物体数量不多的时候完全够用。但它的问题是"手感"不够精确——玩家明明看着还没碰到，计分就已经触发了，因为球体半径比视觉上的方块要大。

DeepSeek V4 Pro用了AABB包围盒检测：

// AABB包围盒 function checkCollision(playerBox, obstacleBox) { return playerBox.min.x <= obstacleBox.max.x && playerBox.max.x >= obstacleBox.min.x && playerBox.min.z <= obstacleBox.max.z && playerBox.max.z >= obstacleBox.min.z; }

AABB检测比距离判断精确得多，尤其适合方块形状的物体。DeepSeek V4 Pro还额外做了分步检测，把每帧的位移拆成若干小段，逐段检测碰撞，彻底杜绝了高速穿透。

但AABB也有局限：它只能处理轴对齐的盒子，如果物体旋转了，包围盒就不准了。不过在这个测试场景里，所有物体都是轴对齐的，所以AABB是最优解。

4.3 相机跟随的平滑度处理

相机跟随看起来简单，但做得好不好直接影响游戏体验。三个模型在这块的处理也分出了层次。

GLM5.3是硬跟随：

camera.position.x = player.position.x; camera.position.z = player.position.z + 10; camera.lookAt(player.position);

相机每帧直接跳到角色位置，没有任何过渡。角色移动时，相机跟着一起"抖"，因为角色的位置是离散变化的。玩久了会有点晕。

Step 5 Preview用了固定偏移跟随，本质上和GLM5.3一样，只是把偏移量抽成了一个常量。体验上没有本质区别。

DeepSeek V4 Pro用了插值跟随：

const cameraOffset = new THREE.Vector3(0, 8, 12); const lerpFactor = 0.1; function updateCamera() { const targetPosition = player.position.clone().add(cameraOffset); camera.position.lerp(targetPosition, lerpFactor); camera.lookAt(player.position); }

lerp是线性插值，每帧让相机向目标位置移动10%的距离。这样相机永远在"追"角色，但永远追不上，形成一种柔和的跟随效果。角色急停时，相机会缓缓滑过去，视觉上舒服很多。

lerpFactor这个参数很关键：太小了相机跟不上角色，太大了就退化成硬跟随。0.1是一个比较通用的值，但如果你想让相机更"紧"一点，可以调到0.15；想更"松"，调到0.05。

注意：用lerp做相机跟随时，如果角色移动速度很快，相机会被甩得比较远。这时候可以给lerpFactor加一个基于距离的动态调整，距离越远插值越快。不过对于小场景来说，固定值就够了。

5. 实操中踩到的坑与排查记录

5.1 三个模型各自的典型问题

Step 5 Preview的变量作用域问题是最典型的。它在checkCollisions()函数里引用了一个在createObstacles()函数内部用const声明的数组，导致运行时报ReferenceError。这个问题的根源是模型在生成代码时"局部思维"和"全局思维"没有切换好——它在写碰撞检测时脑子里想的是"障碍物列表"，但忘了这个列表在另一个函数作用域里。

修复方法很简单，把障碍物数组提升到全局作用域就行。但这个错误说明Step 5 Preview在生成跨函数代码时，对作用域链的追踪还不够严谨。

DeepSeek V4 Pro的API调用问题出在光照设置上。它用了THREE.RectAreaLight，但这个光照类型在Three.js的核心库里有，却需要额外的RectAreaLightUniformsLib初始化才能正常工作。模型知道这个光照类型，但忘了配套的初始化步骤。控制台会报一个关于uniforms的警告，场景虽然能跑，但光照效果不对。

修复方法是换成DirectionalLight或者补上初始化代码。这个问题说明DeepSeek V4 Pro的知识面很广，但偶尔会"知道一半"。

GLM5.3的问题最少，唯一算得上问题的是它没有处理窗口大小变化。浏览器窗口缩放后，画面会被拉伸变形。补一个resize事件监听就能解决：

window.addEventListener('resize', () => { camera.aspect = window.innerWidth / window.innerHeight; camera.updateProjectionMatrix(); renderer.setSize(window.innerWidth, window.innerHeight); });

这个遗漏不算严重，但说明GLM5.3在"完整性"上确实不如DeepSeek V4 Pro考虑得周全。

5.2 常见问题速查表

5.3 我个人的调试流程

踩过这些坑之后，我总结了一套固定的调试流程，每次跑模型生成的3D代码都按这个顺序来：

1. 先看控制台。打开浏览器开发者工具，刷新页面，看有没有红色报错。大部分问题控制台会直接告诉你行号和原因。
2. 确认场景可见。如果画面全黑，先检查相机位置和光源。把相机放到(0, 5, 10)看向原点，加一个AmbientLight，基本能解决大部分"黑屏"问题。
3. 测试核心交互。按方向键看角色动不动。不动的话检查键盘事件监听有没有绑定到正确的元素上。
4. 测试碰撞逻辑。故意撞障碍物和收集物，看计分有没有变化。没变化就在碰撞检测函数里加console.log，看函数有没有被调用。
5. 测试边界情况。快速移动、斜向移动、窗口缩放，看有没有异常。

这套流程走下来，基本能在几分钟内定位到问题所在。比盲目读代码效率高得多。

6. 从测试结果看模型选型与工作流建议

6.1 什么场景选什么模型

经过这轮实测，我对三个模型的适用场景有了比较清晰的判断：

Step 5 Preview适合那些需要"架构设计"的任务。它在模块划分和代码组织上有主动意识，如果你要做一个需要后续扩展的项目，它的产出更容易维护。但你需要接受它偶尔会在细节上翻车，得留出调试时间。

DeepSeek V4 Pro适合对"正确性"要求极高的场景。它的代码最严谨，边界情况考虑最全，适合做那种"跑一次就不能出错"的任务。代价是代码量偏大，有时候会为了完整性牺牲简洁性。

GLM5.3适合"快速验证想法"的场景。它的出活速度最快，一次通过率最高，适合做原型、demo、或者你只是想看看某个效果长什么样。但它的代码结构比较随意，不适合直接用在正式项目里。

6.2 组合使用的思路

其实这三个模型不一定非要二选一。我试过一个组合工作流，效果不错：

先用GLM5.3快速生成一个能跑的版本，验证核心玩法是否可行。确认方向没问题后，把GLM5.3的代码丢给DeepSeek V4 Pro，让它"重构并补全边界处理"。最后如果项目需要长期维护，再让Step 5 Preview做一次架构梳理，把代码拆成合理的模块。

这个流程的好处是各取所长：GLM5.3负责"从0到1"，DeepSeek V4 Pro负责"从1到稳"，Step 5 Preview负责"从稳到可维护"。当然，这个流程比较费时间，适合对代码质量有要求的项目。如果只是做个demo玩玩，直接用GLM5.3就够了。

6.3 关于WorkBuddy这类工具的使用体会

测试过程中我也顺带用WorkBuddy做了一些辅助工作。这类工具的核心价值在于把重复性的操作自动化——比如批量运行测试、自动截图对比、整理测试记录。对于需要反复跑同一个提示词、对比不同模型输出的场景，它能省不少手工操作的时间。

我个人的用法是：把三个模型的输出分别保存成独立的HTML文件，用WorkBuddy配置一个简单的任务流，自动打开每个文件、截图、记录控制台报错。这样一轮测试下来，对比材料就自动整理好了，不用手动一个个打开看。

实操心得：用这类工具的时候，建议先手动跑通一遍完整流程，确认每个环节都没问题，再交给工具自动化。否则工具跑出来的结果你可能不知道怎么解读，反而浪费时间。

6.4 给想复现这个测试的人的建议

如果你想自己复现这个三模型对比测试，有几个点需要注意：

• 提示词要固定。同一个提示词分别喂给三个模型，不要因为某个模型第一次输出不好就改提示词重试，那样对比就不公平了。
• 环境要统一。三个模型的产出都在同一个浏览器、同一个Three.js版本下运行，排除环境差异。
• 记录要完整。每个模型的输出代码、控制台报错、截图都保存下来，方便后续对比。
• 心态要开放。不要预设哪个模型一定更好，实测结果有时候会出乎意料。比如我原本以为DeepSeek V4 Pro会一次通过，结果它反而在光照API上翻了车。

最后再分享一个小技巧：如果你想让模型生成的3D代码更容易一次跑通，可以在提示词里明确指定"使用Three.js核心库中不需要额外初始化的API"，这样能避免类似RectAreaLight这种需要配套初始化的坑。这个约束对三个模型都有效，能明显提高一次通过率。