1. 实测背景：为什么拿 3D 游戏当试金石
最近 AI 编程模型密集发布新版本，从各家预热物料看，参数规模一个比一个大，跑分一个比一个吓人。但说真的，跑分这种东西看多了容易麻木，真正让我感兴趣的是：这些模型在真实项目里的表现到底能不能打？
这次我挑了三个测试对象：Step 5 Preview、DeepSeek V4 Pro、GLM5.3。测试题目是一个 4x4 跑酷游戏——就是玩家控制方块在一条由四个跑道组成的道路上跳跃躲障碍，屏幕上方实时更新分数。这个项目尺寸不大不小，单文件 HTML + Three.js 就能搞定，但对代码生成模型来说是个相当好的压力测试：它需要一次性输出完整可运行的代码，要正确处理三维坐标系、碰撞检测、游戏循环、输入事件、UI 更新这五个维度的问题，任何一个环节出错游戏就当场白屏。
选这个题目还有个现实原因：前阵子很多人用 AI 生成贪吃蛇、扫雷这类 2D 项目来比较模型，老实说区分度已经不够了。2D 游戏的主流框架逻辑烂熟于心，几个模型基本都能一次过。但 3D 游戏涉及立体坐标系和视角控制，模型如果没有真正理解 Three.js 的数学基础，生成的代码往往会出现“怪物”行为——比如障碍物在摄像机后方生成、跳跃后落地判定错误、方块跑到跑道外直接消失。这次就是想看看，新一代模型对空间关系的理解能力到底到了什么程度。
三个模型的部署方式也很有意思：DeepSeek V4 Pro 和 Step 5 Preview 走官方 API 接口，GLM5.3 我额外评测了 vLLM 框架下的本地部署。这里的 vLLM 版本选择有个讲究，后面单独讲，挺多人在这一步踩坑。
说了这么多，直接上结论：三个模型全部成功生成了可运行的 3D 游戏，但差距主要体现在代码质量、异常处理和迭代修改的顺畅度上。下面分段细说。
2. 测试方案设计：从提示词到评分标准
2.1 提示词怎么写才能拉平差距
跨模型对比最怕提示词不公平。模型擅长方向不同，如果给某个模型写了更详细的提示词，等于作弊。我做了一个很简单的标准化方案：每个模型收到的是同一份提示词模板，只替换模型名。
提示词正文是这么写的：
用 Three.js 和原生 JavaScript 开发一个 4x4 跑酷游戏，整个项目打包在一个 index.html 文件中。游戏规则：玩家从四个跑道中选择一条向前跑动，遇到障碍物需要跳跃躲避。要求包含以下功能：跑道使用四条不同颜色的长条形平面；障碍物为立方体，随机生成在四条跑道上；玩家可以左右切换跑道和跳跃，使用键盘控制；跳跃过程有抛物线轨迹；障碍物靠近玩家时触发碰撞检测，碰撞后游戏结束并显示得分；游戏有重新开始按钮；适配桌面浏览器窗口大小，视觉风格简洁现代。
一段话覆盖所有需求，没有细化文件结构，没有指定相机角度和光照参数。这些留给模型自己发挥。
我还给每个模型设置了相同的参数环境：temperature 浮 0.7，top_p 浮 0.9，最大输出 token 数统一放宽到 8000。跑过 AI 生成代码的人应该懂这个参数组合的含义——既不至于太保守导致代码平庸，也不至于太放飞导致生成一堆语法错误。
2.2 测试环境和验证流程
系统是 Ubuntu 22.04.3 LTS，内存 64GB，显卡是一张 RTX 4090 24GB，浏览器统一用 Chrome 122 稳定版，开启硬件加速。GLM5.3 的本地部署在这台机器上先做，其他两个模型走 API。
验证流程分了四步：
- 第一次生成的代码原样在浏览器打开，记录是否能直接跑起来
- 如果有报错，把报错信息原封不动喂给模型，让它自己修，最多允许三轮修复
- 记录每个模型修复到可玩状态需要的轮次
- 最后人工试玩五分钟，按体验打分
评分维度共五项，每项十分：初始可用性、三维空间正确性、异常处理能力、代码可读性、迭代修改顺畅度。初始可用性就是第一次生成能不能跑；三维空间正确性看相机、坐标、物理表现是否合理；异常处理能力看在输入过快、窗口变化等情况下是否崩溃；代码可读性看命名和注释；迭代修改顺畅度看要求小改时模型的响应速度。
给三维空间正确性权重最高，这是整个测试的核心。
3. 三个模型实测：代码、表现与细节差异
3.1 Step 5 Preview：第一印象的优等生
Step 5 Preview 是这次测试里唯一一个一次通过所有功能点的模型。
第一次生成的 index.html 共 412 行，我直接双击用浏览器打开，没报红。游戏画面里四条跑道从左到右依次是蓝、橙、绿、紫，障碍物每隔 1.2 秒从远处生成并加速推进，操作延迟约 30 毫秒，手感相当顺滑。
代码质量方面，它的结构非常规整：三个函数分别管初始化、游戏循环和 UI 更新。最让我意外的是碰撞检测的部分。大多数模型会简单地对两个物体做 bounding box 相交判断，但 Step 5 Preview 用了相对坐标计算，把玩家方块投影到跑道平面上，再跟障碍物做二维距离判定。这段代码逻辑上更精确，也避免了玩家在切换跑道瞬间被“隔空碰撞”的尴尬情况。
说个细节：生成的文件里有一段自适应窗口大小变化的代码，在 resize 事件里重新计算了相机 aspect ratio 和渲染器尺寸。这是很多模型容易漏掉的地方。多数模型生成的游戏固定视角后就再也不管了，窗口一拉窄，画面就拉伸变形。Step 5 Preview 在第一版就处理了这个问题。
不过它也有小瑕疵：视角高度设定偏高，方块在屏幕上显得比较小，压迫感不够。游戏确实是流畅的跑酷，但视觉冲击力不够。
3.2 DeepSeek V4 Pro：逻辑最强的多面手
DeepSeek V4 Pro 第一版代码有 387 行，打开后游戏能跑，但有一个问题：障碍物只在最左侧两条跑道生成。这会导致一个 4x4 游戏实际只玩到了“2x4”。我把这个 bug 反馈给模型，它第一轮就定位到问题在随机数生成范围写错了。
它用的是Math.floor(Math.random() * 2)而不是* 4，典型的低级错误。修复后障碍物四跑道全覆盖，游戏恢复正常。
DeepSeek V4 Pro 给我印象最深的是它生成的游戏逻辑框架非常完善。比如计分系统，其他两个模型的分值都是随游戏时间线性递增，而 V4 Pro 加入了速度加成：玩家跑动距离、跳跃次数和成功躲过的障碍数都会折算成额外分数。这个设计让游戏有了策略深度，跳跃时机本身就变成了得分优化的问题。
代码组织方面，DeepSeek V4 Pro 同样是函数化结构，但它把游戏状态管理做成了全局对象，比如playerState、obstaclePool这样的变量在逻辑上分层清晰。后续如果要把道具系统扩展进游戏，这个框架接得住。
它的小问题在于代码风格偏工程化，注释写得很密集。对直接拿来玩的场景不影响，但对想二次开发的人来说有时候反而觉得啰嗦。
3.3 GLM5.3：本地部署与优秀硬件兼容性
GLM5.3 的代码生成是在本地完成的。部署环境是 vLLM 0.6.6.post1，模型权重以 FP16 精度加载。为什么要特别强调这个版本？因为 GLM5.3 对 vLLM 的版本有兼容性要求，太老的版本不支持某些动态形状输入，太新的版本如果模型没有预先适配可能出现算子报错。我自己实测下来，0.6.6.post1 这个版本在 4090 上推理稳定，显存占用 16.8GB 左右，生成单文件代码耗时 26 秒，体感相当流畅。
GLM5.3 第一版的代码质量是三个模型里最让人纠结的：它能跑，但第一次打开时画面中央出现了一个不该出现的白色方块。
排查之后发现，GLM5.3 把玩家的初始位置放在了跑道之外——坐标系原点被设置到了四条跑道正中间，而不是某条跑道中心。虽然不影响游戏启动，但画面初看很别扭，显得像渲染 bug。
我把报错和现象截图贴给模型后，它很快定位到是camera.position.z和player.position.x的初始值没有对齐跑道坐标，修正后画面干净了。
GLM5.3 的亮点在于它对 Three.js 物理引擎的整合能力。它默认使用了简单但有效的重力加速度模拟，跳跃落地后的缓冲效果比其他两个模型做得更自然，角色落地时有一个约 120 毫秒的“按压”动画过渡，身体比例会略微收缩再恢复。这个细节让我比较满意，说明模型对游戏帧序列和角色状态机的理解比较深入。
3.4 横向评测：一句话总结三个模型的核心差异
| 评测维度 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 初始可用性 | 一次通过 | 需修 1 轮 | 需修 2 轮 |
| 三维空间正确性 | 9 | 8 | 7 |
| 异常处理能力 | 9 | 9 | 8 |
| 代码可读性 | 8 | 7 | 8 |
| 迭代修改顺畅度 | 9 | 8 | 7 |
| 最终可玩性 | 高 | 中高 | 中高 |
综合下来，Step 5 Preview 在开箱即用和代码整洁度上占优，DeepSeek V4 Pro 在逻辑深度上领先，GLM5.3 在物理表现上给人惊喜，但需要更多轮次的调优才能到最佳状态。
4. 关键代码解析：一个 3D 跑酷核心逻辑的拆解
4.1 场景搭建与跑道生成
跑酷游戏的地面是四条并排的长条形平面，从视角看分别是蓝、橙、绿、紫。跑道宽度占整个场景宽度的四分之一，跑道之间空隙 0.2 个单位。
Three.js 里创建平面的常规做法是THREE.PlaneGeometry，然后旋转 90 度横躺。模型们做得都不错，但 Step 5 Preview 的代码里有一个值得学习的细节——它给四条跑道分别设置了不同的receiveShadow属性，配合定向光使得阴影只落在跑道上而不是整个地面空间。这个小细节让画面看着更干净，也减少了无关光照计算。
跑道生成后，动态障碍物统一放在一个数组中管理。每帧循环遍历数组，检测障碍物与玩家的空间距离，一旦小于阈值就触发碰撞判定。
4.2 碰撞检测的三种实现方案
三个模型对碰撞检测的实现方案各不相同，这也是我这次对比里觉得最有信息量的一部分。
Step 5 Preview 使用相对坐标投影方案。它先把玩家的三维坐标降维到跑道平面（忽略 Y 轴，只看 X 和 Z），然后计算与障碍物中心点的二维距离，当距离小于两个物体半径之和时判定碰撞。这个方案的优点是判定精确，不会出现看似碰到实际没碰到的情况。
DeepSeek V4 Pro 用的是 AABB（轴对齐包围盒）方案。直接对玩家和障碍物的 bounding box 做相交检测。优点是实现简单、性能好，缺点是方块旋转时包围盒会跟着扩大，视觉上可能产生“空气碰撞”的错觉。
GLM5.3 写了自定义的像素级碰撞逻辑：它把玩家和障碍物分别抽象成两个矩阵，矩阵元素是模型实际占用的空间点，然后做逐点比较。这个方案最精确，但计算成本相对更高。考虑到游戏里同时存在角色和不超过 6 个障碍物，性能差距体现不太出来。
三个方案给了一个很好的启发：碰撞检测没有银弹，要根据游戏类型选择合适的精度策略。跑酷游戏里物体的运动方向固定，投影距离法其实是最中庸也最稳的选择。
4.3 跳跃运动的抛物线轨迹实现
跳跃功能的物理逻辑是 3D 游戏最容易翻车的地方。如果直接把方块往 Y 轴正方向平移固定距离再落回来，看起来会很生硬。
两个主要模型都正确使用了抛物线运动方程：y = y0 + vy * t - 0.5 * g * t^2，其中 vy 是初始速度，g 是重力加速度。区别在于参数选择。
Step 5 Preview 用了vy=2.5、g=5，跳跃持续时间约 0.5 秒，最大高度约 0.31 个单位，节奏偏轻快。DeepSeek V4 Pro 用了vy=3.2、g=6，跳跃时间约 0.53 秒，最大高度 0.43 个单位，跳跃中角色明显有更大腾空感。这两个参数差得不大，但手感完全不同——前者适合节奏偏快的休闲跑酷，后者适合看重操作反馈的动作游戏。
GLM5.3 则额外处理了跳跃时的角色状态：在上升阶段角色有轻微的缩放动画（scale 微增），下落阶段恢复。这个细节值得点名表扬，很多开发者自己写都想不到。
4.4 相机视角与跟随运动
3D 游戏的体验感有一半来自相机控制。三个模型都采用了第三人称背后视角，但初始位置有差异。
Step 5 Preview 的相机初始位置在(0, 15, 12)，视角朝下约 50 度，俯视感强，有利于玩家观察远处障碍物。DeepSeek V4 Pro 的相机在(0, 10, 8)，倾斜角更大，视角更贴近地面，沉浸感强但观察远方赛道的能力弱一些。GLM5.3 的相机在(0, 12, 10)，介于两者之间。
相机跟随的逻辑基本都是用camera.position.x = player.position.x加上一个固定偏移，深度方向保持稳定。GLM5.3 额外加了阻尼效果（lerp 插值），相机移动更平滑，没有其他两个模型那种瞬移的顿挫感。值得抄作业。
5. 常见问题与排查技巧：跑 3D AI 游戏最常踩的五个坑
5.1 问题一：生成后浏览器白屏，控制台报错
八成是模型生成的 Three.js 版本与 CDN 引入版本不匹配。我在测试 DeepSeek V4 Pro 时第一版就遇到过：它默认引用的是最新版 Three.js，但代码里用了旧版 API，比如geometry.attributes.position的赋值方式不一致。
排查方式很简单：打开控制台看具体报错行，把报错行复制给模型让它修正 API 调用。正常一轮就能解决。如果不想折腾，可以在提示词里明确写上“使用 Three.js 0.128.0 版本”，这个版本 API 稳定，模型们对它掌握得都不错。
5.2 问题二：障碍物只出现在部分跑道
这个概率相当高，尤其是模型第一版代码里随机数范围写错时几乎必然发生。看到这个现象先别急着怪模型，打开代码搜索Math.random()相关的行，检查生成的跑道编号索引是否越界。通常就是* 2写成了* 4这种低级的复制粘贴错误，模型自己修一轮基本都能定位。
5.3 问题三：GLM5.3 本地部署时 vLLM 不兼容
GLM5.3 建议使用 vLLM 0.6.6.post1 版本，我用下来的经验是：用 vLLM 0.6.x 全系都有兼容性风险，高版本 0.7.x 也不行。主要原因是 GLM5.3 的动态张量形状和 vLLM 的连续批处理机制在旧版本之间存在协作问题，跑起来后可能出现算子报错。
如果确实需要在更低配置机器上部署，可以尝试把权重用 AWQ 量化到 4bit，显存占用约 9.8GB，生成速度降幅大约 40%，但流畅度仍可接受。量化方式要注意，GLM5.3 的官方仓库推荐使用 AutoAWQ 做离线量化，而不是 vLLM 自带的量化，否则精度损失会偏大。
5.4 问题四：跳跃时角色穿过障碍物
这个坑主要出在碰撞检测的“离散检测”模式。如果你的游戏循环每帧检测一次碰撞，帧率变化时可能导致高速移动的障碍物“跳过”玩家所在的坐标区间。
解决思路是连续碰撞检测（CCD）：在上一帧和当前帧之间的位置区间内做分段检测。但我不建议普通测试者自己去改这个逻辑，直接让模型重写碰撞检测部分，提示词里写明“对高速物体使用分段碰撞检测”就行。三个模型对这个指令的理解都还不错。
5.5 问题五：移动端点击没反应
这个跟模型无关，是原生 JS 事件绑定的经典问题。Three.js 渲染的 canvas 元素默认不响应键盘事件，需要手动给 canvas 加tabindex属性和focus()方法。如果你把游戏打包成安卓 APK 在 WebView 里跑，还要额外处理触摸事件，把click事件换成touchstart。
这里顺便说一句“开源安卓 3D 游戏”热词相关的事：把这类 AI 生成的 Three.js 游戏包装成安卓应用其实非常顺，主流方案是用 WebView 加载本地 HTML 文件，或者用 Capacitor 打包成 APK。性能上 Three.js 的 WebGL 渲染在移动端 WebView 里的表现足够流畅，跑这种轻量级场景完没有压力。
6. 模型之外的思考：AI 生成 3D 游戏的真实现状
坊间一直有一种期待：AI 生成代码是不是很快就不再需要前端工程师了？这次实测下来我的判断是：在单文件小游戏这个层面，AI 的确已经能顶一个中级开发者的水平了。三个模型都能独立完成一个可玩、有细节、符合预期的 3D 游戏，没有模型摆烂到生成不可运行的代码。这在一年前是难以想象的水平。
但放到更大的项目里看，AI 的短板依然突出。比如代码复制粘贴带来的重复逻辑、不理解需求文档隐含的业务规则、对性能瓶颈缺少全局意识——这些都是当前 AIGC 编程工具的通用问题。我这次测试的模型三者在处理“修改需求”时表现出的差异很有意思：Step 5 Preview 能快速响应小改动要求，DeepSeek V4 Pro 在框架级重构上更强，GLM5.3 则更多依赖上下文累积后的准确率提升。
可能更现实的路径是：用 AI 做原型验证，让人类工程师介入核心逻辑的提炼和架构设计。拿这个 4x4 跑酷项目来说，模型生成了玩法框架，但要加道具系统、排行榜、音效联动，还是得手写大量代码和配置。AI 能把 80% 的重复劳动干掉，剩下的 20% 恰恰是项目灵魂所在。
最后分享一个小经验：给 AI 写提示词时，把“视觉风格简洁现代”这类抽象形容换成“使用白色背景和圆角边框，按钮用渐变色”这类具体描述，生成的代码会更容易符合预期。模型对形容词的理解能力依然有限，但对参数和样式的理解已经有了长足进步。
下次再测，我打算换一个带物理引擎和多人交互的项目试试，看看模型在复杂依赖和实时同步场景下的表现，到时候再整理成一篇完整的对比报告。
