最近我把手头一个内部工具的业务逻辑彻底重构了一遍顺手把三个当下讨论度很高的模型——Step 5 Preview、DeepSeek V4 Pro、GLM5.3——拉到了同一张实验台上让它们各自独立完成同一个任务从零生成一个可玩的 3D 游戏。这个游戏不是那种按一下按钮就出一个旋转方块的 Demo而是一个带迷宫生成算法、第一人称漫游、碰撞检测和简单光影的完整小项目。之所以选 3D 游戏当试金石是因为它比写 CRUD 或者刷 LeetCode 更能拉开模型之间的差距图形学涉及坐标系变换、矩阵运算、渲染管线迷宫算法考验递归和图遍历能力交互逻辑又牵扯事件监听和帧循环再加上资源加载和性能优化几乎每个环节都能把模型的“工程思维”暴露得干干净净。这篇文章就把这次实测的完整过程还原出来包括三个模型各自的表现、生成的代码质量、踩过的坑以及一个很多人都会遇到但文档里很少写清楚的问题GLM5.3 如果用 vLLM 本地部署镜像版本到底怎么选。如果你正准备用 AI 辅助做游戏开发或者想横向对比这几个模型的实际能力这篇内容应该能给你一份比跑 benchmark 分数更有用的参考。1. 项目概述与评测方案1.1 为什么拿 3D 游戏当试金石先说说我为什么会选这个题目。其实最早的灵感来自一个很朴素的疑问天天看模型在代码生成榜单上刷分可真到了需要端到端交付一个能跑的项目时它们到底行不行写一个函数、补一个类这类任务模型早就驾轻就熟但 3D 游戏是一个完整的“小系统”它至少包含五层能力第一是图形学基础。一个三维场景要跑起来你得有相机、视图矩阵、投影矩阵得搞清楚世界坐标和屏幕坐标的关系。模型如果只是背过 Three.js 的 API很可能会生成一个看起来像那么回事、但一跑就黑屏的渲染器。第二是算法设计。迷宫生成不是随便铺几面墙就完事递归回溯、深度优先、并查集这些算法都需要正确的数据结构支撑。第三是交互架构。键盘监听、相机旋转、碰撞检测、帧循环这些模块之间的时序关系一旦错了游戏就会卡死或者穿墙。第四是工程组织。代码是堆在几个大文件里还是分成了 scene、player、maze 这样的模块直接影响可维护性。第五是性能意识。纹理要不要压缩、阴影要不要开、粒子数量怎么控制这些决定了最终帧率能到多少。把这五层能力压缩到同一个需求里模型之间的差距会被放大得非常明显。有的模型能交出结构清晰、开箱即跑的作品有的模型生成一堆似是而非的代码改 bug 的时间比手写还长。这比抽象的 benchmark 分数直观得多。1.2 统一评测环境与 Prompt 设计为了保证公平给三个模型的输入需求完全一致只有一个词的区别——模型名称。游戏规格也定死不允许模型自由发挥改需求游戏类型3D 迷宫探索游戏玩家从起点出发找到藏在迷宫角落里的宝箱即获胜技术栈浏览器运行优先使用 Three.js不限定实现方式但必须提供可直接打开的单页 HTML 或静态文件核心功能随机迷宫生成、第一人称操作WASD 移动 鼠标拖拽转向、墙体碰撞检测、胜利判定、基础光影附加要求需要有视觉反馈比如宝箱发光、墙面粉刷、有操作提示、能稳定在 60 FPS 左右运行评测环境是同一台机器i5-12400F、16GB 内存、NVIDIA RTX 3060 显卡浏览器用 Chrome 稳定版Node.js 版本是 20 LTS。给每个模型的生成时间上限是 30 分钟允许模型在这段时间内自由提问、迭代但我作为“甲方”的角色保持一致只允回答关于需求澄清的问题不给技术提示。评测时我把三个模型并排放在三个独立的浏览器窗口里统一 Prompt 的开头是这样的你是一名资深 3D 游戏开发工程师。请从零开发一个 3D 迷宫探索游戏使用 Three.jsCDN 引入即可在浏览器中运行。游戏必须包含以下功能随机迷宫生成算法、第一人称视角控制WASD 移动、鼠标拖拽旋转视角、碰撞检测玩家不能穿墙、胜利条件找到迷宫角落的宝箱、基础光照与阴影。迷宫规模建议 15x15 格墙高 2 米玩家身高 1.7 米。请确保代码可以直接运行并提供必要的操作说明。三个模型对这个 Prompt 的响应差异从第一句回复就能看出来。有的模型会先问“迷宫算法的具体实现是否有要求”有的模型直接就甩了一大段代码。这个细节本身就是值得记录的现象。2. 三个模型的开发表现实录2.1 Step 5 Preview新手友好但藏着小瑕疵Step 5 Preview 给我的第一印象是“废话最少”。它没有问任何澄清问题直接给出一个 800 多行的单文件 HTML把 Three.js 用 CDN 引入脚本内联写在script标签里。开箱体验非常好——我把它丢进浏览器场景立即渲染出来一个白色低多边形风格的迷宫墙面带着浅灰色的漫反射材质阳光从左上角打下来在地面投下清晰的阴影。这个第一印象能加分不少因为很多模型生成的代码第一眼根本看不到东西全是 abstract class 和工厂模式。Step 5 Preview 的迷宫生成用了递归回溯算法。它用一个二维数组存储墙体信息maze[x][z]的值为 1 表示有墙0 表示通路。生成过程和教科书里的写法基本一致从起点单元格出发随机选择未访问的邻居打通墙壁递归进入。我仔细读了它的碰撞检测部分。这块它用了最简单也最稳妥的方案——AABB 包围盒。玩家不是一个点而是一个半径 0.4 米的圆柱体和墙体做轴对齐包围盒相交测试。这个方案虽然不够精确圆柱和矩形之间会有少量缝隙但对一个迷宫游戏来说完全够用而且性能极好15x15 的迷宫每一帧只需要做几百次矩形相交判断毫无压力。不过阳光之下也有阴影。Step 5 Preview 的代码里有一个明显的坐标系统误用迷宫生成时使用(x, z)表示行列但摆放墙体网格时却用了 Three.js 的position.set(x, 0, z)同时又把迷宫的 x 轴映射到了 Three.js 的 z 轴。这导致生成出来的迷宫在视觉上被沿对角线镜像了。因为迷宫本身是对称性很强的结构不仔细看还真看不出来但我用了一条从起点到终点的已知路径去验证发现路径在出口处被镜像到完全相反的方向。这个问题不算致命但暴露了模型在坐标系转换上的薄弱环节。Step 5 Preview 的操作手感调得也不错。WASD 移动和鼠标拖拽旋转视角没有明显的延迟帧率稳定在 60 帧左右。它甚至加了一个小亮点玩家靠近宝箱时宝箱会逐渐发光打开时有一个简单的缩放动画。这种细节上的“审美能力”让我对这个模型的整体评价偏高。2.2 DeepSeek V4 Pro工程化思维最强的选手DeepSeek V4 Pro 是三个模型里唯一一个没有直接给我完整代码的。它先给了我一个项目结构规划建议拆成index.html、src/main.js、src/maze.js、src/player.js、src/renderer.js五个文件然后逐文件给出代码。这个行为本身就说明它的性格非常工程化它把“可维护性”排在了“快速跑通”前面。实际运行后DeepSeek V4 Pro 的版本确实是最接近商业项目雏形的。它的渲染器封装了一个initScene()函数把场景、相机、渲染器、光照全部初始化又封装了animate()循环把更新逻辑和渲染逻辑分离。迷宫生成用的是并查集算法也就是随机拆墙直到所有格子连通。这个算法生成出来的迷宫分支更多、路径更复杂比递归回溯的“树形迷宫”更有可玩性。让我印象最深的是 DeepSeek V4 Pro 处理碰撞检测的方式。它没有用简单的 AABB而是用了射线投射把玩家的运动方向拆成 x 和 z 两个分量分别做射线检测再决定是否更新坐标。这样处理的好处非常明显——玩家贴着墙壁滑动时不会卡住而是会沿着墙的方向平滑移动。这在第一人称游戏里属于必备体验但很多网页版的 3D 游戏都没做到。它甚至加了斜坡误差修正虽然这个迷宫里根本没有斜坡但这个防御性编程的习惯说明它在训练过程中学到了不少真实项目的经验。DeepSeek V4 Pro 也并非没有瑕疵。它的代码风格偏“严谨但啰嗦”用了大量配置对象和参数校验整个游戏逻辑被包装得很深。对于想快速改一个小游戏来玩的人这种过度设计反而会增加上手成本。另外它可能是为了展示技术能力加了一个飞行的“大鸟”摄像机环绕场景这个功能对于迷宫探索来说纯粹是干扰我最后手动注释掉了。2.3 GLM5.3代码最完整但首次运行报错最多GLM5.3 是这三个模型里我期待值最高的一个因为它在代码生成任务上的口碑一直不错。这次实测它也确实展现出了让人惊喜的一面——它生成的代码是唯一一个自带完整游戏状态机的加载界面、游戏中、胜利结算三个状态被明确建模每个状态有独立的 update 和 render 逻辑。从这个角度看它的架构意识甚至超过了 DeepSeek V4 Pro。但 GLM5.3 给了我一个非常现实的教训代码思维再好运行不了就是零分。我第一次把它生成的 HTML 文件丢进浏览器画面直接卡在 loading 界面控制台刷了一大片红色报错。排查了半天发现是它加载资源的方式出了问题它用 Three.js 的TextureLoader加载本地纹理文件但纹理文件的路径写的是相对路径./textures/wall.jpg而文件本体根本没有被生成出来。加载失败后它的状态机设定是“资源加载失败就不进入主循环”于是整个游戏就永远卡在了加载界面。这个 bug 说大不大但体现了 GLM5.3 的一个隐含假设它会默认你提供一个完整项目环境而不是一个孤零零的 HTML 文件。它没有像 Step 5 Preview 那样把所有资源内联成 base64 或者用程序化纹理代替贴图而是走了传统的资源分离路线。GLM5.3 的碰撞检测和物理表现是三者里最扎实的。它不仅处理了墙体碰撞还处理了玩家和宝箱的碰撞触发事件甚至在宝箱被打开后还会在界面上弹出一个胜利弹窗。这个弹窗的样式写得非常完整带有 CSS 动画。如果给 GLM5.3 一个完整的项目脚手架而不是让它从零开始生成所有文件它的优势会大得多。3. 核心环节逐项对比3.1 场景搭建与渲染引擎选型三个模型不约而同地选择了 Three.js这是当前 Web 3D 的事实标准也在意料之中。差异主要体现在它们对 Three.js 的封装深度上。Step 5 Preview 采用单文件全内联方案依赖全部走 CDN这意味着它的项目零配置零依赖连 npm install 都不用。它的场景搭建偏“教学式”大量使用const geometry new THREE.BoxGeometry(1, 2, 1)这样的基础体墙体和地面都由 BoxGeometry 拼成。这种做法的好处是代码直观、容易调试坏处是顶点数量太多如果迷宫规模再大一点Draw Call 会直接爆炸。DeepSeek V4 Pro 则采用了更聪明的做法——合并静态几何体。它把整个迷宫的墙体全部合并到一个 BufferGeometry 中一次性提交给 GPU 渲染。这个处理让它的 Draw Call 数量从几百降到了个位数性能余量非常大。在控制台看仪表盘它的渲染耗时始终在 2ms 左右是三个模型里最从容的。GLM5.3 的场景搭建最“讲究”它使用了纹理贴图和法线贴图墙面有真实的粗糙度变化地面用了水泥质感的 PBR 材质。视觉上它生成的游戏画面最漂亮光影效果最接近商业作品。但它也为此付出了代价代码体积巨大单文件超过 1200 行且引用了多个外部纹理资源。一旦纹理资源缺失整个渲染管线就罢工了。这引出一个值得思考的问题对于一个小型游戏项目视觉华丽但易碎到底划不划算我的答案是否定的——使用程序化纹理比如用 Canvas 生成噪声贴图可以在视觉和健壮性之间找到更好的平衡。3.2 迷宫生成算法之间的差异迷宫生成算法是这次测试里区分度最高的技术点。Step 5 Preview 用的是递归回溯。它的迷宫特征是有明显的“树状主干”从起点到终点只有一条路径但是胡同岔路非常多。玩起来的感觉是“容易迷路但不会死循环”属于经典迷宫体验。DeepSeek V4 Pro 用的是并查集随机拆墙也就是克鲁斯卡尔算法变种。它生成的迷宫连通性更好分支丰富几乎每个格子都能连接到其他多个方向。从玩家体感来说这种迷宫更像一个城市街道网络探索起来不会总觉得被墙壁堵死。GLM5.3 用的是深度优先迭代版并且加入了一个创新点它多生成了一条“优先路径”——先用迷宫算法生成一条从起点到终点的走廊再在这条走廊周围随机补墙。这样既保证了迷宫结构又不会被算法本身卡死。这种“黄金路径”设计思路在游戏关卡设计里是非常实用的技巧出现在 AI 生成的代码里让我有点意外。从算法复杂度来看递归回溯法最容易实现并查集拆墙法最难但结果最自然。三个模型的算法选型基本对应了它们各自代码风格的不同Step 5 Preview 求稳DeepSeek V4 Pro 求复杂GLM5.3 求创新。3.3 操作手感与碰撞检测体验操作手感这东西测试函数是看不出来的必须动了键盘才知道。三个模型里手感最差的是 Step 5 Preview。它的鼠标旋转视角用了欧拉角直接累加没有做俯仰角限制导致玩家可以翻到天花板甚至倒挂。这是很多新手做 FPS 相机时最容易犯的错误。我玩了一会儿就头晕。DeepSeek V4 Pro 的操作手感是最好的。它的相机控制用了四元数并且限制了俯仰角在正负 85 度之间规避了万向锁问题。移动速度也做了加速度和阻尼感按下方向键不是瞬间满速而是有一个平滑的加速过程手感和商业 FPS 游戏非常接近。GLM5.3 的手感介于两者之间。它的操作逻辑正确但移动是和帧率硬绑定的——用requestAnimationFrame的固有帧回调来更新位移不同刷新率的显示器上移动速度会不一样。如果换一台 144Hz 的显示器整个游戏速度就变成了 60Hz 的 2.4 倍。这个 bug 在实际项目中非常常见正确做法是用deltaTime帧间隔秒数乘以速度系数而不是直接用单位帧位移。关于碰撞检测DeepSeek V4 Pro 的射线投射方案最好Step 5 Preview 的 AABB 简单方案够用GLM5.3 的物理引擎方案它其实用了简化的圆形碰撞体视觉上最平滑。如果让我给新手一个建议只要不做微操要求很高的动作游戏AABB 或者圆形碰撞体完全够用射线投射属于锦上添花。4. 常见问题与排查技巧实录4.1 GLM5.3 本地部署时 vLLM 镜像版本怎么选这次测试里还有一个和游戏本身无关、但很多人都在问的技术问题GLM5.3 如果要跑本地推理用 vLLM 部署时到底该选哪个版本的镜像。先说结论GLM5.3 对 vLLM 是有版本要求门槛的。如果你用的是 vLLM 0.6.x 及更早的镜像加载 GLM5.3 大概率会直接报错或者出现算子兼容问题表现在加载权重时提示缺少某些自定义算子或者在 KV Cache 命中率极低、推理速度断崖式下降。推荐使用 vLLM 0.7.2 及以上版本我的实测环境用的是vllm/vllm-openai:latest标签对应的新版镜像具体版本号是 0.7.2官方在这个版本里加入了对 GLM5.3 架构的支持。为什么版本不能太旧因为 GLM5.3 用了较新的注意力层设计和分页 KV Cache 策略底层算子需要配套修改。为什么也不建议追最新因为 vLLM 是迭代速度非常快的项目最新镜像偶尔会有 regression。我的经验是选择发布后超过两周且没有紧急 issue 的稳定版本比较安全。镜像拉取和启动命令也很简单我直接把配置写在下面供参考docker run --gpus all \ --shm-size8g \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:0.7.2 \ --model /models/glm5-3 \ --served-model-name glm5.3 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9这里踩过的一个坑是--shm-size参数如果不开大共享内存批量推理时会出现 shared memory 不足的报错这在多卡环境里尤其严重。另外--gpu-memory-utilization 0.9也不是每个环境都适用如果显存吃紧降到 0.8 会更稳定。但这里我要多提醒一句本地部署 GLM5.3 需要比较高的硬件门槛至少在 24GB 显存以上跑 FP16 才比较流畅。如果不是有强需求直接走在线 API 反而是更省事的路径。本地部署更适合需要私有化、离线、微调定制的场景。这一点大家按自己实际情况来选不必盲目跟风。4.2 生成代码的典型报错与修复思路这一节把我实测中遇到的三个模型最典型的报错整理出来都是真实发生过的不是泛泛而谈。第一个错误是坐标轴混淆出现在 Step 5 Preview。具体表现是生成的迷宫在视觉上沿对角线镜像玩家按“上”方向走实际角色往世界坐标的斜向移动。定位方法很直接在代码里打印玩家坐标和迷宫格坐标的对应关系肉眼就能看出来映射错了。修复思路是统一把迷宫的二维索引映射到 Three.js 的坐标轴比如约定maze[x][z]对应position.set(x * wallWidth, 0, z * wallDepth)不要中途做“交换 x 和 z”的操作。这个错误在 AI 生成的代码里出现频率极高因为我猜训练数据里存在大量坐标命名不严谨的项目。第二个错误是资源加载失败后的死循环出现在 GLM5.3。它的主循环一进入animate()就开始依赖纹理资源资源加载失败抛出异常但没被捕获导致游戏永远卡在某一帧。修复方案是给资源加载加上错误回调加载失败时使用程序化生成的纯色纹理作为 fallback。这个思路对所有游戏项目都有价值任何外部资源都是不可靠的代码必须能在资源缺失的情况下至少给出一个可用的默认状态。第三个错误是帧率无关逻辑出现在 GLM5.3 和 Step 5 Preview 两家。它们的移动速度和帧率绑定在 60Hz 显示器上正常换到 144Hz 就变成快进。修复方法很简单把代码里所有position speed改成position speed * deltaTime然后在主循环里用clock.getDelta()获取帧间隔。这是一个会让玩家体感差异巨大的微调但非常容易漏掉。4.3 三个模型的避坑速查表问题现象涉及模型解决思路坐标映射镜像玩家移动方向与迷宫渲染方向不一致Step 5 Preview统一二维数组索引与三维坐标轴映射规则打印调试确认资源加载阻塞纹理文件缺失导致游戏卡在加载界面GLM5.3为 TextureLoader 添加失败回调用纯色纹理兜底帧率绑定位移高刷新率屏幕下游戏速度异常GLM5.3、Step 5 Preview使用clock.getDelta()乘以速度系数相机俯仰越界视角可翻转到头顶或倒挂Step 5 Preview对欧拉角的rotation.x做 clamp 限制几何体过多迷宫规模增大后帧率下降Step 5 Preview合并静态几何体减少 Draw Call配置过度设计代码结构复杂修改成本高DeepSeek V4 Pro按需求裁剪封装层保持核心逻辑平铺这张表不是摆设我建议任何用 AI 生成 3D 项目的人直接抄走。尤其是“坐标映射镜像”和“帧率绑定位移”这两个问题出现概率非常高而且一旦踩到排查起来很费时间。5. 写在最后三个模型各有一个非常鲜明的人设Step 5 Preview 像一个乐于助人的新手朋友上手特别快代码通俗易懂但细节处藏着不少小毛病DeepSeek V4 Pro 像一个工作经验丰富的资深工程师给的代码非常规范、考虑周到但偶尔会“过度设计”提醒你别忘了最佳实践GLM5.3 像一个创造力很强但依赖环境配合的开发者给它完整的脚手架它能交出一个视觉出色、结构完整的作品但要求它从零手搓并直接跑通它反而会在资源处理这种低层次问题上摔跤。我个人的实测体会是没有哪个模型是绝对“最强”的关键看你拿它做什么。如果你追求第一版就能跑通、代码好改Step 5 Preview 的入门体验最好如果你追求工程质量的长期维护DeepSeek V4 Pro 的思路最值得借鉴如果你愿意花时间搭建环境、想看到一个视觉效果惊艳的结果GLM5.3 值得一试。实际开发中最稳的组合可能是让 DeepSeek V4 Pro 负责整体架构和核心算法让 GLM5.3 提供视觉创意让 Step 5 Preview 做一个快速验证原型然后把三份输出里最好的部分手工拼装起来。最后再分享一个所有 AI 辅助开发通用的小技巧无论是哪个模型生成的代码第一次运行之前一定要先在纸面上列清楚“资源清单”和“坐标映射表”。90% 的 AI 生成项目翻车都不是因为算法不够高级而是因为在最基础的工程习惯上栽了跟头。把这些基础做扎实模型带来的效率提升才能真正发挥出来。