最近两个月我养成一个习惯：任何新模型出来，第一件事不是跑排行榜，而是让它给我写一个3D游戏。原因很朴素——3D游戏代码里藏着图形学、空间几何、事件系统、状态管理、性能优化一大堆内容，任何一个环节掉链子，页面就是一团黑或者一屏报错。相比网上那些被训练数据覆盖了无数遍的算法题，这种综合性任务更能看出一个模型的真实代码水平。
这次我一次性拿了三个模型做横评：Step 5 Preview、DeepSeek V4 Pro、GLM5.3。题目完全一致：用 Three.js 写一个3D跑酷小游戏，包含障碍物生成、碰撞检测、计分、失败重开，所有代码塞进一个 HTML 文件里，浏览器打开就能玩。我把整个测试过程原原本本记录下来，包括每个模型生成的代码长什么样、跑起来有没有翻车、以及后来我怎么让它们互相审查对方的代码挖出一堆有意思的问题。
1. 为什么拿3D游戏当"考卷"
1.1 3D游戏是AI编程能力的试金石
先说结论：让模型写一个2D贪吃蛇或者待办事项列表，已经很难区分出水平高下了。这些东西在训练集里出现过太多次，几乎每个模型都能默写出来。但3D游戏不一样，它强制要求模型同时处理好几层问题。
首先是环境搭建。我不能要求用户去安装 Node.js、下载依赖，必须要让模型自己选一条最省事的路径。实测下来大部分模型会主动选择 Three.js 的 CDN 引入方式，几行代码就搞定。但这个选择本身就考验模型对"用户真实场景"的理解——不是所有人都在工程目录里跑 npm，更多人是想拿一个 HTML 文件直接双击打开。
其次是数学能力。三维场景里的移动不是简单 x++，而是向量运算、速度与时间的乘法、相机位置的插值。一个模型如果空间想象力不足，生成的代码会莫名奇妙地"抖动""沉入地面""穿模"。
然后是渲染循环。为了让画面动起来，需要 requestAnimationFrame 驱动更新逻辑，这里面又涉及 deltaTime 的计算方式、帧率波动的处理、对象销毁。
最后还有工程层面的要求：函数拆得是否合理、命名是否可读、有没有考虑重新开始的资源清理。这些点任何一处崩了，游戏就没法玩。所以我说，一次3D游戏生成测试，等于把模型的理解力、代码能力、工程意识全都考了一遍。
1.2 评测约定：同一个需求，同一套环境
为了保证公平，我先定了几条评测规则，后面不管测试谁，都严格遵守。
统一提示词。我把需求文档写好之后，复制粘贴到三个模型的对话框里，不根据模型风格做任何修改。提示词里固定了 Three.js 版本，这一点很关键，后面我会解释为什么。
统一运行环境。生成完的代码各自存成独立 HTML，放在同一个目录下，用本地 HTTP 服务打开。这里有个小经验：虽然 Three.js 走 CDN 之后，用 file:// 协议双击打开大部分时候也能跑，但偶尔会触发浏览器对本地模块加载的限制，所以稳妥起见我用了python -m http.server起一个静态服务，三个页面保持完全一致的加载条件。
统一验收标准。我按五个维度评分：首轮可运行率、玩法完整性、代码可读性、运行性能、修复成本。每一项都是我在真实使用中真正关心的，而不是论文里那种花哨指标。
为什么锁定 Three.js r152？因为我发现大多数模型的训练数据里，Three.js 的版本停留在了 r120、r128 这种老版本上。那会儿的 API 写法跟现在差异很大。如果不锁版本，模型会凭记忆写出CylinderBufferGeometry这种已经被移除的类名，或者用旧的事件绑定方式。既然锁定了版本，就能把变量控制住，比较的是"在同样约束下的解决能力"，而不是"谁运气好见过新版本"。
1.3 三个参赛选手的赛前印象
这三个人风格差异挺明显。
Step 5 Preview 是一个预览版模型，主打推理能力和指令跟随能力。我提前拿写正则、解几何题简单试了一下，感觉它的"思考过程"比较细致，遇到问题会先拆解再动手。
DeepSeek V4 Pro 在工程代码上的口碑一直不错。它特别擅长写结构清晰的类、模块，上下文的保持能力也强，处理长代码的时候不容易写着写着忘了前面的约定。不过有个小问题：有时候会过度设计，明明30行能搞定的事，非要给你抽象的父类子类。
GLM5.3 是最近社区热度很高的一款模型，中文理解能力好，而且我在不少群里看到有人在讨论怎么本地部署它、该配哪个版本的推理框架，说明用户基础已经很大了。它生成的代码风格我总结为"快但是野"，速度快、篇幅短，但经常留下一些小坑。
带着这些印象，我把同样的题目发给了它们三个。
2. 从需求到首个可运行版本
2.1 统一提示词的设计
先放出这次测试用的完整提示词，给想要复测的朋友直接抄：
请用 Three.js r152 写一个完整的3D跑酷小游戏。 具体要求： - 玩家是一个立方体，可以在三条跑道之间左右切换，躲避迎面而来的障碍物 - 障碍物为随机高度和随机颜色的长方体，从远处朝玩家移动 - 使用键盘左右方向键控制，A/D 也可以 - 按上方向键跳跃，按下方向键下蹲 - 碰撞后游戏结束，显示得分和"按空格键重新开始"的提示 - 得分随时间自动增加，障碍物越近得分越快 - 代码要完整，所有代码放在一个HTML文件中，使用CDN引入Three.js r152 - 给出必要的注释这个提示词不算极端详细，但有三个小心思：
第一，把"三条跑道""随机颜色""越近越快"这些核心玩法钉死，避免模型自由发挥成别的东西。第二，没有指定画面风格和UI细节，留出空间观察模型的审美倾向。第三，明确要求注释，因为我想看它在解释自己代码时的表达是否清晰。
提示词越界的地方也有，插入一句声明——"请勿修改任何需求描述，直接按照上述要求生成完整代码"。这句话是我踩了多次坑之后加上的，因为有些模型会自作主张把跳跃改成二段跳，把三条跑道改成开放地图，虽然看起来更酷，但没法横向对比了。
2.2 Step 5 Preview 首轮表现
我点下生成按钮的同时掐了一个秒表。Step 5 Preview 大约 20 秒开始出码，速度中规中矩，最终输出了一个约 230 行的 HTML 文件。
打开文件第一感觉是整洁。结构非常"教学范儿"：顶部是场景、相机、光源初始化；中间是地面和玩家的创建；然后是障碍物管理函数；再往下是动画循环；最后是事件监听。每个区块都有注释，甚至在页面下方加了一行字：如果按空格键没反应，请先点击游戏区域获取键盘焦点。
我直接双击打开。运行第一秒，画面正常，棋盘格地面铺开，玩家立方体站在中间，障碍物开始从远处飞来。第二秒，镜头开始跟着玩家的跳跃做上下运动。第三秒，我发现了第一个问题：障碍物的移动速度忽快忽慢。
查了一下代码，原因是它用了一个固定间隔生成障碍物，但是每一帧让障碍物移动的距离是用 delta 时间算的。设计思路没错，问题出在了它同时用 time-based 和 frame-based 两种方式驱动同一个障碍物，导致帧率一波动，感官上速度就会抖。更明显的一个问题出现在相机跟随上：它用"玩家位置的 y 值与当前速度的线性插值"来平滑相机高度，听上去合理，但实际落地瞬间会出现一帧的顿挫。
这属于典型的"单看代码没毛病，跑起来才难受"的问题。语法全对，逻辑能走通，但细节和经验层面的东西还差点意思。
2.3 DeepSeek V4 Pro 首轮表现
DeepSeek V4 Pro 生成的代码体量明显更大，接近 420 行。它开局就分了三类：Player类负责玩家控制，ObstacleManager类负责障碍物生成与移动，GameState类负责计分和游戏状态切换。一眼就能看出这个模型对面向对象的偏好非常强。
跑起来之后，主流程没出幺蛾子。左右切换手感不错，跳跃重力也调得相对自然，计分器的更新逻辑没有问题。但我玩到第 5 秒左右发现一个很恼火的碰撞判定：玩家立方体在视觉上被设置成绕 Y 轴旋转了45度，像一个钻石形，但碰撞检测用的却是原始立方体的轴对齐包围盒。结果是玩家实际碰不到障碍物的边角，却被判定撞上了空气。
这个 bug 很能说明问题。模型理解了"碰撞检测要做"，但没有理解游戏开发里一个基本要求——视觉模型和物理模型必须保持一致。说白了就是"懂语法，缺常识"。
另一个问题是重开机制。按空格键重新开始之后，新的游戏循环没有重置场景中环境光的强度。我连续试了三次，画面一次比一次灰暗，最后几乎看不清障碍物，只能刷新整个页面才能恢复。这种状态残留问题在 2D 游戏生成中很少见，因为 2D 不需要管理灯光等额外资源，一上 3D 就露馅了。
2.4 GLM5.3 首轮表现
GLM5.3 是三个模型里生成最快的，代码也最短，只有 180 行左右。极简风格，几乎没有任何多余的抽象，函数就三四个：createObstacle、moveObstacles、checkCollision、restartGame。一眼扫过去，功能覆盖完整，左右切换、跳跃、下蹲、计分、重开全都有。
实际试玩同样顺利跑起来了。但是十几秒之后，我碰到了一个严重到足以推翻整局的判定问题。
GLM5.3 判断碰撞时，它在每帧遍历障碍物数组，然后直接取出数组里的第一个对象计算距离，并不是取出离玩家最近的那个。平时屏幕上只有一个障碍物的时候毫无感知，一旦同时存在两个或三个障碍物，问题就来了：玩家明明躲开了最近的一个，但数组中靠前的另一个障碍物可能还没飞到面前，系统就误判撞上了。换句话说，它把"有没有障碍物在附近"写成了"数组第一个障碍物在不在附近"。
这个 bug 藏得够深。如果评测只跑十秒钟，根本发现不了，我是在玩到第 17 秒，眼看着障碍物从我身边擦过去，屏幕上却弹出 Game Over 的时候才意识到不对劲。也正是这个案例让我更坚定了一点：AI 编程模型的评测，必须有足够长的运行观察期。
3. 运行调试与细节打磨
3.1 一跑就炸的典型问题
首轮跑完之后，我把三个模型生成的代码在浏览器控制台里过了一遍，发现有几个共性问题反复出现，值得拿出来单独说说。
第一个是版本类 API 错误。虽然我已经在提示词里锁定了 r152，但 Step 5 Preview 早期输出里还是出现了CylinderBufferGeometry。这个类名在 r125 之后就被统一成CylinderGeometry了。理论上提示词里都写了版本号，模型应该查找对应文档，但实际结果是它更依赖训练记忆。这说明当前大模型对于"指定版本库"的指令遵循能力还有明显天花板。
第二个是键盘事件绑错对象。DeepSeek V4 Pro 把addEventListener绑定到了 canvas 元素上，导致我一开始用鼠标点了一下画面、焦点还在页面其他位置的时候，方向键完全没反应。必须点一下游戏画面，焦点切回 canvas，操作才生效。虽然它加了一行"点击画面获取焦点"的提示，但体验上还是多了一步。
第三个是动画循环资源泄漏。不只是某一个模型的问题，三个模型都不同程度地踩了这条。它们在重新开始时，从场景里移除了旧的障碍物、恢复了玩家位置，但requestAnimationFrame生成的循环 id 没有取消，旧的渲染循环和新循环一起跑，控制台直接报THREE.WebGLRenderer: Context Lost警告，帧率肉眼可见掉一半。
这些问题的共同根源是：模型把"写出可运行的代码"理解为"写出符合语法的代码"，而不是"写出在真实页面里经过完整生命周期考验的代码"。生成完代码之后，它没有机会自己跑一圈、观察行为，所以那些只有运行时才会暴露的问题它通常都看不见。
3.2 碰撞检测、相机跟随这些"必考知识点"
如果把三个模型的代码并排看，会发现它们在碰撞检测上的策略分成了三条路线。
Step 5 Preview 用的是 AABB 包围盒，也就是比较两个物体在 x、y、z 三个轴上的重叠区间。这是最传统也最稳妥的方案，适合不旋转的立方体，计算量小，误差可控。
DeepSeek V4 Pro 用了球体距离法，每次计算玩家中心点到障碍物中心点的距离，和两者半径之和做比较。这套逻辑在视觉上比较宽松，即使两个物体边缘没有真正接触，只要距离足够近就算碰撞。对于快速移动的障碍物，这种判定帧与帧之间可能漏掉碰撞，出现"穿过去没死"的错觉。
GLM5.3 其实也想用 AABB 思路，但它的实现栽在了"最近对象筛选"上，也就是前面说的那个 bug。它不是先算出所有障碍物里哪个离玩家最近，再判断碰没碰，而是默认数组第一个就是最近，直接把判断条件写歪了。
相机跟随同样是重灾区。Step 5 Preview 的相机放在玩家正后方，跟随 x 和 z 轴，只在 y 轴上做了插值平滑，优点是画面稳定，缺点是落地瞬间会顿。DeepSeek V4 Pro 的相机直接固定在了一个略高于玩家的位置，不跟随 y 轴，跳跃时画面完全不动，虽然稳定却少了很多动感。GLM5.3 最激进，让相机完全跟着玩家旋转，玩家一碰到视角转动，整个画面就开始晃，玩久了非常晕。
这些空间关系问题的共同点是，它们根本不会出现在 2D 任务里。2D 只需要关注 x 和 y，3D 多了一个 z 轴之后，模型的"空间直觉"差异立刻被拉开。
3.3 让它们自己改自己的bug
跑完首轮，我开始第二轮交互：把控制台里的报错信息原样复制，粘贴给对应模型，让它自己修。
这个环节的差异非常有意思。
Step 5 Preview 的响应速度最快，基本上不用我进一步解释，它就能定位到问题是"障碍物速度应该统一由 delta 驱动"或者"相机插值应该使用目标位置的阻尼而不是线性平滑"。而且它会主动多做一件事：把修改之后的完整代码重新输出一次，而不是只给出 diff。更重要的是，它在修改说明里主动加了移动端触控事件处理的建议，考虑到我只是桌面端测试，这个延伸能力让我有点惊讶。
DeepSeek V4 Pro 在收到报错后，先写了一大段分析，解释为什么会出现这个问题，然后再给修复代码。从教学角度看是非常好的老师，但实际效率偏低。我贴了一段很常见的requestAnimationFrame重复调用警告，它先跟我聊了三行"该问题通常源于渲染循环没有被正确清除"，然后才给出修改。它的修复代码质量没问题，但"废话比率"有点高。
GLM5.3 的修复风格完全不同：它不太乐意在小修小补上花时间，倾向于直接换一套实现方案。比如修碰撞判定时，它直接把障碍物生成机制从 requestAnimationFrame 驱动改成 setTimeout 驱动。功能上确实修好了，但新方案和原来的计分逻辑衔接处又出现了新的状态错乱。它是三个模型里唯一让我在修复阶段反复来回的。
这里我总结出一个通用经验：给模型贴报错时，不要只贴一行Uncaught TypeError，把完整报错堆栈和"我预期应该发生什么、实际发生了什么"一起发给它，修复成功率会直线上升。但如果模型在初版就暴露出"边界情况考虑不周"的毛病，后续对话中需要你帮它把边界条件一条条列出来，它才会认真处理。
4. 同题复测与局部能力横向对比
4.1 代码质量与可维护性
首轮跑通之后，我又加了一个需求微调实验：让每个模型在已有代码基础上，增加"游戏速度随分数提升而逐渐加快"的机制。同时要求它先写一句说明自己准备怎么实现，再动手改。
Step 5 Preview 的改法属于最小侵入式。它加了一个speedScale变量，在计分回调里每增加一定分数就让speedScale上浮一个固定值，然后把障碍物所有移动速度都乘以这个系数。改动只有三处，风险最低，一眼能看懂。
DeepSeek V4 Pro 又来了它那套工程化思路。这次它引入了一个GameSpeedManager类，专门管理速度曲线、封顶值和增长步长。代码数量多了不少，但后续想改"达到某个分数突然加速"这种玩法，只需要动一个类，不用大范围搜索魔数。
GLM5.3 的改法最粗暴：它直接把初始速度改成了 0.5，然后在每次计分回调里加 0.01。我第一眼看过去觉得没什么问题，但再一细想就发现了隐患——如果游戏玩得足够久，速度值会变成 0.5 + 0.01 * 分数，没有上限约束。到后期障碍物快得像瞬移，根本没法玩。更夸张的是，当分数超过一定范围后，浮点数精度问题会让速度产生跳变。
从可维护性角度，我的排序是 DeepSeek V4 Pro 最好、Step 5 Preview 次之、GLM5.3 垫底。但从"用户最关心的跑起来是否稳定"角度看，Step 5 Preview 的最小改动反而最可靠。这其实也是个很有意思的取舍：过度抽象虽然扩展性好，但引入的新代码量本身也是新的风险面。
4.2 游戏性与画面表现
需求文档里没有规定画面风格，所以这一项是模型自由发挥的舞台。
Step 5 Preview 明显在"看起来像游戏"这件事上花的功夫最多。它给地面加了棋盘格纹理，障碍物用随机颜色生成，跳跃落地时甚至加了简单的粒子效果。虽然粒子代码只有几行，使用时机也算不上精准，但这种主动增加视觉反馈的意识，已经超出了"完成功能"的范畴。
DeepSeek V4 Pro 走的是另一个方向。画面极其朴素，没有纹理，没有粒子效果，但它做了一件特别专业的事情：障碍物对象池。它会预先创建固定数量的障碍物，循环使用而不是反复创建销毁。这种优化在网页小游戏里属于"看不见但能感觉到"的东西，我跑了三分钟性能面板，它的帧率最平稳。
GLM5.3 的画面居中，没有明显的视觉亮点，但镜头晃动幅度最大。我发现它在玩家移动时会给相机添加一个震动偏移量，本意是增加沉浸感，但偏移参数给得太大，导致我玩了不到一分钟就有眩晕感。如果它把这些参数除以三，可能整个游戏体验会上一个台阶。
如果只做一个小体量3D游戏 Demo，我的理想方案是用 Step 5 Preview 的画面能力，配合 DeepSeek V4 Pro 的性能优化意识，最后用 GLM5.3 生成一个短小精悍的"快速原型版"用来验证游戏机制。
4.3 模型之间的互相审查
评测到后半段，我决定整点不一样的：把 A 模型的代码丢给 B 模型审查，把 B 模型的代码丢给 C 模型审查。
第一轮，我把 Step 5 Preview 生成的代码发给 GLM5.3，请它找问题。GLM5.3 表现得相当敏锐，它一眼指出相机跟随的线性插值在落地瞬间会产生一帧延迟，还主动给出了用THREE.MathUtils.damp替代手写线性插值的方案。说实话，这个意见比我自己去定位问题还快。
第二轮，把 GLM5.3 的代码发给 DeepSeek V4 Pro。它一开始确实找出了"最近障碍物判断逻辑错误"这个核心 bug，解释得清清楚楚，甚至画了一个简单的流程说明。但让我意外的是，它只提了这一个问题，其他例如没有速度上限、相机晃动过度这些隐患，它全都放过去了。
第三轮，把 DeepSeek V4 Pro 的代码发给 Step 5 Preview。结果让我大跌眼镜：它提的全是代码风格意见，比如"建议把 Player 类改名为 PlayerController""private 方法应该放在类的前半部分"。核心的"视觉旋转与物理碰撞不一致"问题和"灯光状态残留"问题，一个都没提到。
这组实验给了我一个非常重要的启示：一个模型的"生成能力"和"审查能力"完全不是一回事。写得好的模型未必看得准别人的代码，而写得一般的模型反而可能有一双"审代码的眼睛"。在日常工作流里，如果你手里有多个模型，可以交替使用它们做代码评审，比单一模型自己检查自己有效得多。
5. 综合结论与选择建议
5.1 三维度评分
把整个测试过程跑完以后，我按照五个维度给三个模型打了一个相对主观的分数，5 分制，仅供参考。
| 维度 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 首轮可运行率 | 4.5 | 4 | 3.5 |
| 细节完整度 | 4 | 4.5 | 3 |
| 修复成本 | 4 | 3.5 | 4 |
| 运行性能 | 4 | 5 | 3.5 |
| 综合体验 | 4.2 | 4 | 3.6 |
解释一下 GLM5.3 的首轮可运行率为什么只给 3.5。它的代码确实能跑，没有语法错误，但"最近障碍物筛选"那个 bug 属于玩法层的硬伤，比语法错误严重得多。一个看起来能跑但规则上随时可能判错的游戏，不能算作真可运行。
Step 5 Preview 的优势在于"出问题之后最好沟通"。它自己能清晰地解释 bug 成因，也能在后续对话里记住之前的修改方案，这种对话体验对实际开发效率加分非常明显。
DeepSeek V4 Pro 的性能优化意识和代码组织能力最强，如果目标是做一个可以长期维护的项目，它的底子最稳。
5.2 按使用场景推荐
我不打算说" XX 模型更好"这种一刀切的话，因为不同场景下最优选择不一样。
如果你是刚接触 3D 游戏开发的新手，想读一段能跑的代码来理解基本逻辑，我推荐 GLM5.3。它代码短、没有花哨抽象，每一行都是直白的 Three.js API 调用，核心机制一览无余。
如果你在做游戏原型，或者半天之内要验证一个玩法能不能成立，我推荐 Step 5 Preview。它生成的代码完成度高、注释清晰、加上它那套不错的解释能力，能让你的迭代周期缩短很多。
如果你是在正经项目里引入 AI 辅助编码，而且这个项目会持续迭代几个月，我会选 DeepSeek V4 Pro。它的类结构、对象池、性能优化意识，能帮你避免很多只有项目后期才会爆发的维护问题。
如果只能选一个，我的答案还是 Step 5 Preview。原因很实在：它生成的代码错误之处最容易理解和修复，而且它自己能把原理讲明白，这对使用者来说就是最高的效率。
5.3 本地部署GLM5.3的一个提醒
虽然这次测评我用的都是官方线上 API，但最近几乎每条关于 GLM5.3 的帖子下面都有人在问本地部署的事。我顺着这个热词测试的时候也踩过坑，简单提醒一句。
如果用 vLLM 来跑 GLM5.3，请务必去官方文档查清楚它推荐哪个版本的推理框架。你用当前最新版的 vLLM 大概率没问题，但如果你手里的环境是某个预览版或开发版镜像，很可能会报算子不兼容，比如flash attention不支持之类。这个和模型本身的代码生成能力没关系，但会直接耽误你的测试进度。提前把版本对齐这一步做了，能省掉半天折腾时间。
结尾：我自己的固定工作流
测试做完之后，我把自己平时依赖单一模型写代码的习惯彻底改了。现在我的标准流程是：先用 Step 5 Preview 搭主干，它的整体完成度和后续沟通成本最低；再用 DeepSeek V4 Pro 做一轮代码审查和性能优化，它的对象池、类结构方案比较稳；最后把产出丢给 GLM5.3 挑刺，它那种"换个思路重写"的风格，反而能帮我发现很多原方案里没人想到的坑。
三个模型都不是完美的，但放在一条流水线上，效果比我以前跟一个模型死磕一下午好太多。你也可以拿这个3D跑酷的提示词去试试自己手上的模型，尤其是"让它审查别人代码"那一环，我保证你会有惊喜。
