三大AI编程模型实测：谁最能生成3D跑酷游戏？

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.7top_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 PreviewDeepSeek V4 ProGLM5.3初始可用性一次通过需修 1 轮需修 2 轮三维空间正确性987异常处理能力998代码可读性878迭代修改顺畅度987最终可玩性高中高中高综合下来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 用了vy2.5、g5跳跃持续时间约 0.5 秒最大高度约 0.31 个单位节奏偏轻快。DeepSeek V4 Pro 用了vy3.2、g6跳跃时间约 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 写提示词时把“视觉风格简洁现代”这类抽象形容换成“使用白色背景和圆角边框按钮用渐变色”这类具体描述生成的代码会更容易符合预期。模型对形容词的理解能力依然有限但对参数和样式的理解已经有了长足进步。下次再测我打算换一个带物理引擎和多人交互的项目试试看看模型在复杂依赖和实时同步场景下的表现到时候再整理成一篇完整的对比报告。