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

三个大模型，同一个需求，都是做一个3D游戏。这个测试思路本身就很有意思——它不是跑分，不是刷榜，而是把Step 5 Preview、DeepSeek V4 Pro和GLM5.3拉到同一个起跑线上，用同一个真实项目来检验它们的实际编码能力。我拿到这个对比任务的时候，第一反应是：终于有人做这种"真刀真枪"的横向对比了，而不是拿一堆benchmark分数在那排列组合。

先说清楚这个测试的核心变量。三个模型面对的是完全相同的输入：一个3D游戏的完整需求描述。输出目标也一致：能跑起来的、有基本可玩性的3D游戏代码。评判维度包括代码能不能直接运行、3D场景搭建是否合理、交互逻辑是否完整、代码结构是否清晰、以及最关键的——遇到问题时模型的自我修正能力。

为什么选3D游戏作为测试载体？因为3D游戏开发天然是一个"多约束优化问题"。它同时涉及数学（向量运算、矩阵变换、碰撞检测）、图形学（渲染管线、光照模型、材质系统）、物理（重力、碰撞响应）、交互设计（输入处理、相机控制）和工程架构（场景管理、资源加载、状态机）。一个模型如果只能写CRUD或者算法题，在3D游戏这个场景下会立刻暴露短板。这就像让一个只会做家常菜的厨师去掌勺婚宴——刀工、火候、摆盘、出菜节奏，哪一项拉胯都藏不住。

我实际跑完三组测试之后，最大的感受是：三个模型的"性格"差异非常明显。Step 5 Preview像是一个经验丰富但话不多的老工程师，代码结构干净，该有的都有，不太爱写注释但逻辑自洽；DeepSeek V4 Pro像是一个学院派选手，喜欢把架构设计得很完整，但有时候会过度设计；GLM5.3则像是一个反应很快的实战派，能快速给出可运行的版本，但在复杂场景下偶尔会偷懒。

这个测试适合谁看？如果你正在选型一个模型来辅助游戏开发或者3D应用开发，这篇实测能给你一手参考。如果你只是好奇当前大模型在复杂工程任务上的真实水平，这里没有跑分滤镜，只有实际跑起来的代码和踩过的坑。如果你自己也想复现这个测试，我会把完整的测试方法、提示词设计和评判标准都摊开来讲。

注意：模型版本迭代很快，我测试时使用的具体版本号以实际调用为准。不同时间点的模型表现可能有差异，建议以你自己的实测结果为准。

2. 测试方案设计与环境搭建

2.1 为什么选Three.js作为统一技术栈

三个模型做3D游戏，如果技术栈不统一，对比就失去了意义。我选择Three.js作为统一输出目标，原因有三：第一，它是Web端最成熟的3D库，模型训练数据里肯定有大量Three.js代码，能最大程度反映模型的真实水平；第二，它不需要复杂的构建工具链，一个HTML文件加CDN引入就能跑，降低了环境变量对测试结果的干扰；第三，Three.js的API设计比较直观，模型如果理解不了Three.js的坐标系和场景图概念，那基本可以判定它在3D空间思维上有问题。

测试环境我固定为：Chrome 120+浏览器，Three.js r160版本通过CDN引入，所有代码在同一个HTML文件内完成，不依赖任何构建工具。这样做的目的是让"能不能跑"这个判断变得极其简单——打开浏览器就知道。

2.2 统一的提示词设计

给三个模型的提示词完全一致，内容如下：

请用Three.js写一个3D游戏，要求： 1. 一个玩家控制的角色（用几何体组合表示即可），支持WASD移动和鼠标视角旋转 2. 一个地面平面，上面随机分布一些障碍物 3. 玩家碰到障碍物时游戏结束，显示得分 4. 得分随时间递增 5. 所有代码放在一个HTML文件里，通过CDN引入Three.js 6. 代码要有基本注释

这个提示词的设计逻辑是：需求足够具体，避免模型自由发挥导致对比维度发散；同时留有一定的实现空间，能看出模型在架构选择上的偏好。比如"用几何体组合表示即可"这句话，就是故意降低美术门槛，把测试焦点集中在逻辑和交互上。

2.3 评判标准与记录方法

我设定了五个评判维度，每个维度按1-5分打分：

记录方法：每个模型跑三次，取最好的一次结果。每次运行后截图记录初始画面、操作过程和游戏结束画面。代码保存下来做逐行对比分析。

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

3.1 Step 5 Preview：干净利落的工程派

Step 5 Preview给出的代码第一眼看上去就让人舒服。它把代码分成了几个清晰的模块：场景初始化、玩家创建、障碍物生成、输入处理、游戏循环、碰撞检测。每个模块之间的边界很清楚，没有出现那种所有逻辑堆在animate函数里的情况。

它的玩家角色实现很有意思，用了一个CapsuleGeometry作为身体，加上两个小球作为"眼睛"来指示朝向。这个设计很聪明——用最少的几何体表达了角色的朝向信息，比单纯用一个立方体要直观得多。相机控制方面，它实现了一个简单的第三人称跟随相机，鼠标移动时相机围绕玩家旋转，这个逻辑写得很标准。

碰撞检测用的是最简单的距离检测，没有引入物理引擎。对于这个需求来说，距离检测完全够用，而且性能更好。障碍物生成用了随机位置加边界检查，确保不会生成在玩家初始位置附近。得分系统用了一个简单的累加器，每帧增加分数。

让我印象最深的是它的代码注释。不是那种"// 初始化场景"的废话注释，而是会在关键逻辑处解释为什么这么做。比如在相机控制那段，它注释了"使用球坐标计算相机位置，避免万向节锁问题"。这说明模型不只是知道怎么写，还知道为什么这么写。

不过Step 5 Preview也有一个明显的问题：它没有处理窗口大小变化的事件。如果用户调整浏览器窗口大小，画面会被拉伸。这是一个小疏忽，但在实际项目中是需要修复的。

3.2 DeepSeek V4 Pro：架构完整的学院派

DeepSeek V4 Pro的代码量是三个模型里最大的，它构建了一个相当完整的游戏架构。它定义了一个Game类，把所有逻辑封装在类里面，然后定义了Player类、Obstacle类、InputManager类。这种面向对象的设计在大型项目中是合理的，但对于一个单文件的小游戏来说，有点杀鸡用牛刀的感觉。

它的3D场景搭建是三组里最精致的。地面用了GridHelper加一个半透明平面，障碍物用了不同颜色的立方体并加了随机旋转，玩家角色用了组合几何体并且加了一个简单的阴影。光照方面用了环境光加方向光，还加了雾效来增强空间感。这些细节说明DeepSeek V4 Pro在3D场景的"氛围感"上是有审美的。

交互方面，它实现了一个平滑的相机跟随，相机位置用lerp插值过渡，操作手感是三组里最顺滑的。碰撞检测用了Box3的intersectsBox方法，比距离检测更精确。得分系统除了时间累加，还加了连击奖励机制——连续躲避障碍物会获得额外分数。

但问题也出在这里。DeepSeek V4 Pro的代码在浏览器里跑起来之后，我发现它的障碍物生成逻辑有一个bug：当障碍物数量超过一定值后，新生成的障碍物会重叠在已有障碍物上，导致视觉上看起来像一个大障碍物。排查后发现是随机位置生成时没有做去重检查。这个bug不算严重，但说明模型在生成大量随机对象时，对边界条件的考虑不够周全。

另外，它的代码注释虽然多，但质量参差不齐。有些注释是重复代码本身的内容，比如"// 设置相机位置"下面就是camera.position.set()，这种注释没有增加信息量。

3.3 GLM5.3：快速出活的实战派

GLM5.3的代码是三组里最"紧凑"的。它没有定义任何类，所有逻辑都写在几个函数里，代码行数大约只有DeepSeek V4 Pro的三分之二。但神奇的是，它把所有需求都实现了，而且跑起来没有任何报错。

它的玩家移动逻辑写得很直接：监听keydown和keyup事件，维护一个按键状态对象，在animate循环里根据按键状态计算移动向量。相机控制用了PointerLockControls，这是Three.js官方提供的鼠标锁定控制器，实现第一人称视角非常方便。碰撞检测用了简单的球体距离检测，障碍物用随机位置的立方体表示。

GLM5.3最让我惊喜的是它的"游戏结束"处理。当玩家碰到障碍物时，它不仅显示了得分，还做了一个简单的屏幕震动效果和红色闪烁提示，然后弹出一个重新开始按钮。这个细节在提示词里并没有要求，是模型自己加的。这说明GLM5.3在"游戏感"上有一定的理解。

但GLM5.3的代码质量是三组里最不稳定的。它的变量命名比较随意，有些地方用了单字母变量名，可读性一般。注释也比较少，只在关键函数上方有一行说明。另外，它的障碍物生成逻辑有一个潜在问题：如果随机位置恰好生成在玩家移动路径上，玩家可能来不及反应就撞上了，游戏难度曲线不够平滑。

3.4 三组表现横向对比

4. 实操过程与关键环节复现

4.1 测试环境的完整搭建步骤

如果你想复现这个测试，下面是完整的操作流程。首先准备一个干净的目录，创建三个子文件夹分别命名为step5、deepseek、glm。每个文件夹里放一个index.html文件。然后准备一个本地HTTP服务器，用Python自带的就行：

# 在测试目录下执行 python -m http.server 8080

为什么需要HTTP服务器而不是直接双击打开HTML文件？因为Three.js的CDN加载和某些浏览器的安全策略，直接file://协议打开可能会遇到跨域问题。用本地服务器是最稳妥的方式。

然后打开浏览器访问localhost:8080/step5/，打开开发者工具的控制台面板。这一步很关键——很多3D游戏的报错不会显示在页面上，只会出现在控制台里。我测试时就是通过控制台才发现DeepSeek V4 Pro的障碍物重叠问题的。

4.2 提示词的实际投喂与记录

把前面设计的提示词分别投喂给三个模型。这里有一个实操细节：不要一次性把提示词发过去就完事，要观察模型的输出过程。Step 5 Preview和GLM5.3都是直接输出完整代码，DeepSeek V4 Pro则是先输出了一段架构说明，然后再输出代码。这个行为差异本身就反映了模型的"性格"。

拿到代码后，直接复制到对应的index.html文件里。注意要检查代码是否被Markdown代码块包裹，如果是，要去掉html和标记。这个步骤看起来简单，但我第一次测试时就因为没去掉标记导致页面白屏，排查了十分钟才发现问题。

4.3 运行测试与问题记录

三个模型的第一版代码都能直接运行，这一点值得肯定。但运行之后的表现差异就出来了。

Step 5 Preview的版本跑起来最"稳"，帧率稳定在60fps，操作响应及时，没有明显的卡顿或延迟。我测试了五分钟，没有遇到任何报错。

DeepSeek V4 Pro的版本在运行约两分钟后开始出现帧率下降，从60fps掉到45fps左右。打开控制台发现是障碍物数量不断增加导致的——它的障碍物生成逻辑没有上限控制，时间越长障碍物越多，最终会导致性能问题。这是一个典型的"功能实现了但没考虑边界"的问题。

GLM5.3的版本运行最流畅，帧率一直稳定在60fps。但它的游戏难度确实有问题——我玩了三次，有两次都是在开局十秒内就撞上了障碍物，因为障碍物生成位置太靠近玩家出生点。这个体验问题在代码层面很容易修复，但模型没有主动考虑到。

4.4 代码修复与二次测试

为了公平对比，我对三个版本都做了最小化修复：Step 5 Preview加上窗口resize处理，DeepSeek V4 Pro加上障碍物数量上限和去重，GLM5.3加上出生点安全距离。修复之后重新测试，三个版本都能稳定运行。

这个修复过程本身也很有意思。Step 5 Preview的代码修复起来最轻松，因为它的模块化结构让定位问题变得很容易。DeepSeek V4 Pro的修复需要理解它的类结构，稍微费点时间。GLM5.3的修复最快，因为代码扁平，直接找到生成函数加一行判断就行。

5. 常见问题与排查技巧实录

5.1 模型生成3D代码的高频问题

在多次测试中，我总结了一些模型生成Three.js代码时经常出现的问题，整理成速查表：

5.2 我踩过的三个坑

第一个坑：模型生成的代码里用了THREE.CapsuleGeometry，但我测试时用的Three.js版本比较老，没有这个几何体。控制台报错THREE.CapsuleGeometry is not a constructor。解决办法是升级Three.js版本，或者让模型改用CylinderGeometry加SphereGeometry组合。这个坑提醒我，模型训练数据里的API版本可能和你的实际环境不一致，拿到代码后要先检查API兼容性。

第二个坑：DeepSeek V4 Pro的代码里用了Box3.intersectsBox做碰撞检测，但它的障碍物是旋转过的立方体，而Box3是轴对齐包围盒，旋转后的包围盒不准确。这导致玩家明明看起来没碰到障碍物，但游戏却结束了。解决办法是改用Box3.setFromObject来动态计算包围盒，或者直接用球体距离检测。这个坑说明模型在选择碰撞检测方案时，没有充分考虑物体的旋转状态。

第三个坑：GLM5.3的代码里用了PointerLockControls，这个控制器需要用户点击页面才能锁定鼠标。但模型没有在页面上加提示文字，导致我一开始以为鼠标控制坏了。后来点击了一下页面才发现需要先锁定。这个坑提醒我，模型生成的交互逻辑可能缺少必要的用户引导。

5.3 提升模型输出质量的提示词技巧

经过这次测试，我总结了几条让模型生成更好3D代码的提示词技巧：

第一，明确指定Three.js的版本号。比如"使用Three.js r160版本"，这样模型会避免使用过新或过旧的API。

第二，要求模型先输出架构说明再输出代码。这个技巧对DeepSeek V4 Pro特别有效，它会先规划好类结构再写代码，减少后期修改成本。

第三，明确要求处理边界情况。比如"考虑窗口大小变化、障碍物数量上限、玩家出生点安全距离"，把这些要求写进提示词，模型就会主动处理。

第四，要求代码分模块并加注释。虽然注释质量参差不齐，但至少能让你快速理解代码结构。

第五，如果第一版有问题，不要重新生成，而是把报错信息贴给模型让它修复。三个模型都有不错的错误修复能力，Step 5 Preview在这方面表现最好，能准确定位问题所在。

6. 三款模型的选型建议与适用场景

6.1 什么场景选Step 5 Preview

如果你需要的是"一次成型"的代码，不想花太多时间调试和修改，Step 5 Preview是最稳妥的选择。它的代码结构清晰，逻辑自洽，很少出现低级错误。特别适合快速原型开发——你有一个想法，想让模型快速给你一个能跑的版本，然后你在这个基础上迭代。

Step 5 Preview的另一个优势是它的"工程直觉"很好。它知道什么时候该用类，什么时候该用函数，不会过度设计也不会偷懒。这种判断力在复杂项目中非常宝贵。

6.2 什么场景选DeepSeek V4 Pro

如果你需要的是一个"完整度高"的代码基础，愿意花时间理解和调整架构，DeepSeek V4 Pro是更好的选择。它的面向对象设计在项目规模变大时优势明显，类之间的边界清晰，扩展起来很方便。

DeepSeek V4 Pro在3D场景的视觉表现上也更用心，光照、雾效、材质这些细节都考虑到了。如果你做的项目对视觉效果有要求，它会给你一个更好的起点。

但要注意它的"过度设计"倾向。对于小项目，它的代码量可能让你觉得冗余。你需要有选择地精简。

6.3 什么场景选GLM5.3

如果你追求的是"快速验证"和"最小可行产品"，GLM5.3是最快的。它的代码量最少，跑起来最轻量，适合快速验证一个玩法想法是否可行。

GLM5.3在"游戏感"上也有自己的理解，会主动加一些提升体验的小细节，比如屏幕震动、重开按钮。这些细节虽然小，但能看出模型对"游戏"这个品类有感知。

但它的代码质量不稳定，变量命名和注释都比较随意。如果你打算在它的代码基础上做长期开发，可能需要先做一轮代码整理。

6.4 一个实用的组合策略

我实际用下来的体会是：不要只用一个模型。我的做法是先用GLM5.3快速出一个可运行的版本，验证玩法可行性；然后用Step 5 Preview重构代码，得到一个结构清晰的版本；最后如果需要更复杂的架构，再参考DeepSeek V4 Pro的设计思路。这个组合策略能兼顾速度、质量和扩展性。

7. 从3D游戏测试看模型编码能力的边界

这次测试让我对大模型在3D游戏开发上的能力有了更具体的认知。三个模型都能完成"从零到可运行"这一步，这说明当前主流模型在基础3D编程上已经跨过了及格线。但在"从可运行到好用"这一步上，三个模型都还有明显的提升空间。

具体来说，模型在"空间思维"上的表现差异最大。Step 5 Preview和DeepSeek V4 Pro能正确理解三维空间中的位置、旋转、缩放关系，生成的代码在空间逻辑上是自洽的。GLM5.3在简单场景下没问题，但在需要精确空间计算的场景下（比如旋转物体的碰撞检测）就容易出问题。

另一个观察是，模型对"性能"的感知普遍较弱。三个模型都没有主动考虑对象池、LOD、视锥剔除这些性能优化手段。对于小场景没问题，但如果要做稍微复杂一点的3D应用，就需要人工介入优化。

还有一个有意思的发现：模型在"游戏设计"层面的理解比"游戏编程"层面要弱。三个模型都能写出符合提示词要求的代码，但很少有模型会主动思考"这个玩法好不好玩"、"难度曲线是否合理"、"玩家体验是否流畅"。GLM5.3加的那个屏幕震动效果算是难得的亮点，但整体来看，模型还是更擅长执行明确的需求，而不是主动做设计决策。

如果你也在用大模型辅助3D开发，我的建议是：把模型当成一个执行力很强但缺乏产品思维的初级工程师。你需要把需求拆解得足够细，把边界条件考虑得足够全，然后让模型去实现。模型能帮你省掉大量写样板代码的时间，但核心的设计决策和体验打磨，还是得你自己来。

最后分享一个我在测试中发现的实用技巧：当你让模型生成3D代码时，在提示词里加上"请确保代码在Three.js r160版本下可以直接运行，不要使用已废弃的API"，能显著降低代码跑不起来的概率。这个技巧对三个模型都有效，尤其是对GLM5.3，能减少它使用过时API的情况。