Step5/DeepSeek/GLM5.3代码生成实测：3D迷宫游戏谁最强？

最近圈子里讨论最多的莫过于 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3 这三个模型同时在代码生成赛道发力。不少人问我光看跑分和榜单没用到底哪个模型真的能接手一个稍微复杂点的项目我干脆把三个模型拉到同一个 3D 游戏开发任务里做了一次横向实测。这篇文章就是这个测试的完整记录包括任务设计、运行环境、生成代码对比、修复过程以及最后我总结出来的避坑清单。如果你正打算用 AI 辅助做小游戏或 Web 3D 场景或者只是想看看这几个模型谁更顺手这篇内容应该能帮你节省不少试错时间。1. 测试设计为什么拿 3D 游戏当试金石1.1 3D 游戏对模型的要求比普通脚本高得多很多人测试代码模型还在用“写一个冒泡排序”或者“写个计算器”这种题根本拉不开差距。现在的模型都能写。真正能拉开差距的是那种需要在同一个项目里同时处理多个子问题的任务随机算法、用户交互、坐标系换算、动画循环、碰撞检测、性能控制、异常兜底。3D 游戏恰好把所有这些东西揉在了一起。我选的载体是浏览器端的 Three.js 项目。原因很简单不需要装 Unity 或 Unreal一个浏览器就能跑三个模型生成的代码可以直接放到本地预览。而且 Three.js 的 API 一直在更新如果模型训练数据里混入了过时的用法就会立刻暴雷。这一步相当于做了“真实环境兼容性测试”比单纯看代码风格靠谱得多。任务我定为一个“第一人称迷宫逃脱”游戏核心功能包括随机迷宫生成、WASD 移动、鼠标拖拽视角、碰撞检测、计时器、胜利画面。听起来不复杂但真让模型一次性写出来需要它同时吃透三维空间、射线检测和事件系统。1.2 统一任务与评测口径为了让三个模型死磕同一个问题我把提示词写死不做任何倾向性引导。提示词长这样请用 Three.jsr160 以上版本实现一个 3D 迷宫逃脱游戏要求 1. 随机生成迷宫地图使用深度优先搜索算法 2. 玩家以第一人称视角在迷宫内移动WASD 控制方向 3. 鼠标拖拽旋转视角视角要平滑 4. 墙壁要有碰撞检测不能穿墙 5. 界面左上角显示计时器到达出口后显示胜利画面 6. 最终交付为一个完整的 HTML 文件使用 importmap 方式引入 three 模块。这个提示词里我故意埋了几个细节版本号、碰撞检测、完整单文件。目的就是看模型有没有真正理解现代 Three.js 的模块体系以及它愿不愿意给出一份开箱即用的东西而不是丢一堆半成品片段。评测维度我最后定了四项首次运行成功率、代码可读性、修复成本、资源开销。后面对比表格里会用同一套标准。2. 环境准备与模型接入vLLM 镜像版本怎么选2.1 运行环境说明先把测试环境说清楚免得大家说结果不可复现。我本地用的是一台 Linux 服务器显卡是单张 A100 80G内存 128G浏览器端用的是 Chrome 最新版本地通过 Vite 起服务避免文件协议带来的跨域问题。三个模型的接入方式不一样Step 5 Preview 和 DeepSeek V4 Pro 我走的是官方云 APIGLM5.3 则用了本地部署的方式主要是想顺便看看 glm5.3-flashx 在 vLLM 上的实际表现。需要注意的是云 API 版本是闭源黑盒你没法知道背后用了多少算力本地部署则受 vLLM 版本、量化格式和显卡影响很大。所以严格来说这次测试不是实验室级公平对比而是“用户最容易遇到的默认情况”对比。我想大多数读者关心的也是这个。2.2 Step 5 Preview 和 DeepSeek V4 Pro 的接入Step 5 Preview 接入比较标准OpenAI 兼容的/chat/completions接口设置temperature0.2保证输出稳定max_tokens拉到 8000避免长代码中途截断。DeepSeek V4 Pro 同样走的兼容接口但它的响应流式输出做得更细我在脚本里直接接的streamTrue等第一次遇到[DONE]再拿完整结果。两个模型都没遇到鉴权或配额问题整体接入体验差别不大。这里补充一个小经验如果你准备让 AI 写完整的 HTML 游戏max_tokens一定要留够。迷宫生成算法、Three.js 场景初始化、事件绑定、纹理和 UI这些加起来很容易超过 3000 token。如果你只留默认的 2048模型会在代码中途“挤牙膏”最后给你一个残缺版本。2.3 GLM5.3 本地部署别在 vLLM 镜像版本上翻车GLM5.3 我选择了本地部署主要原因是想验证它在 910B 或者 A100 环境下能不能顺利跑起来。这里要重点聊一下 vLLM 镜像版本的选择因为这是我在整个测试中踩得最狠的坑。一开始我图省事直接拉了一个 vLLM 0.4.x 的老镜像起来结果加载 glm5.3-flashx 权重后的前向传播一步都跑不动直接报Unsupported operation。翻了一下日志才发现FlashX 的某些注意力算子需要较新的 vLLM 内核。后来我换成了 vLLM 0.7.2 的官方镜像配 Python 3.11 和 CUDA 12.4才顺利跑通。注意如果你打算本地部署 GLM5.3 系列不要盲选最新版本也不要选太老的版本。建议先看模型仓库里给出的requirements.txt里锁定的 vLLM 版本区间一般来说 0.7.x 是比较稳妥的。选好镜像后先用--load-format safetensors试跑一个极短请求再上完整任务。镜像起来之后我用--max-model-len 16384限制上下文长度避免显存溢出。GLM5.3 FlashX 在 A100 上生成速度确实快后面细说。3. 实操过程让三个模型写同一个 3D 游戏3.1 提示词已经统一接下来看模型怎么出招同一份提示词三个模型的反应差异非常明显。Step 5 Preview 在生成前居然先回了一段“实现思路”说明它处理的是深度推理类请求倾向于先规划再写码。DeepSeek V4 Pro 则没什么废话直接开写但中途输出过长触发了我的脚本自动分段拼接。GLM5.3 FlashX 响应速度快得惊人第一段代码几乎瞬间弹出但后面开始出现一些奇怪的“补全”。我没有干预模型输出只做记录的旁观者。生成结束后我把三个文件夹分别丢到 Vite 服务里跑用浏览器打开一遍记录报错再手动修复。整个过程就像在测试三个不同水平的开发协作对象。3.2 Step 5 Preview 的生成结果Step 5 Preview 给到的是一个完整的单 HTML 文件代码结构清晰甚至自动写了注释。迷宫生成用的是标准的递归回溯算法我摘一段它生成的核心部分function generateMaze(cols, rows) { const grid Array.from({ length: rows }, () Array(cols).fill(1)); const stack [[1, 1]]; grid[1][1] 0; while (stack.length) { const [x, y] stack[stack.length - 1]; const neighbors [ [x 2, y], [x - 2, y], [x, y 2], [x, y - 2] ].filter(([nx, ny]) nx 0 nx cols - 1 ny 0 ny rows - 1 grid[ny][nx] 1 ); if (!neighbors.length) { stack.pop(); continue; } const [nx, ny] neighbors[Math.floor(Math.random() * neighbors.length)]; grid[ny][nx] 0; grid[ny (y - ny) / 2][nx (x - nx) / 2] 0; stack.push([nx, ny]); } return grid; }这段代码我在浏览器里跑了一下生成的迷宫路径正确没有孤岛。它对手部逻辑的细节把握很到位拆墙的时候用的是grid[ny (y - ny) / 2]这行保证拆的是相邻两格之间的中间墙而不是随机拆了一个无关位置。但 Step 5 Preview 也有一个让我皱眉的地方它把鼠标交互做成了 PointerLockControls点击画面后鼠标会被锁定。这种交互在 FPS 里没问题但在迷宫游戏里玩家可能希望自由拖拽视角而不是被锁住鼠标。这不是 bug而是“设计倾向”问题。我后来手动改成了拖拽式 OrbitControls 变体。3.3 DeepSeek V4 Pro 的生成结果DeepSeek V4 Pro 的代码风格和 Step 5 Preview 完全不同。它没有给我单文件而是拆出了MazeGenerator.js、PlayerController.js、GameScene.js三个模块然后给了一个入口文件。逻辑分层做得很漂亮如果这是一个长期维护的项目这套架构明显更合理。但问题在于它没有完全遵守“单 HTML 文件”的要求。我手动把三个模块合并回一个文件的过程中发现它的PlayerController.js里有一处变量作用域问题导致合并后player对象在初始化阶段是undefined浏览器直接报错TypeError: Cannot read properties of undefined (reading position)仔细排查后发现DeepSeek V4 Pro 在构造函数里用了this.player new THREE.Mesh(...)但初始化顺序里把this.scene.add(this.player)放到了this.player赋值之前。这种问题在模块化拆分时不会暴露一旦合并回单文件顺序就会被打乱。这也是我这次测试里体会最深的一点AI 生成的模块化代码看起来很规范但合并时特别容易出现“上下文割裂”的隐性 bug。DeepSeek V4 Pro 的射线碰撞检测写得不错它没有用简单的距离判断而是对每个墙块做Raycaster检测能处理拐角卡住的问题。不过它生成的迷宫尺寸是按照窗口宽度动态算的在小屏幕下迷宫只有 7x7玩起来太简单我不得不手动调大。3.4 GLM5.3 FlashX 的生成结果GLM5.3 在我本地 vLLM 上跑的版本是 flashx 变体。生成速度是真的快几乎是另外两个模型的一半时间但代码质量就有点“过山车”了。它给出的 HTML 骨架很完整但 I 在检查 Three.js 版本兼容性时发现它居然用了THREE.BoxBufferGeometry——这个 API 在 r125 之后就被移除了r160 下使用会直接报错。我把报错贴出来TypeError: THREE.BoxBufferGeometry is not a constructor这说明 GLM5.3 FlashX 的训练数据里可能混入了较多 2021 年前后的 Three.js 示例。不过它也不是全无优点它生成的迷宫寻路算法加了一个小的可视化步骤可以把生成过程用动画展示出来这是三个模型里唯一一个主动想到“让玩家看到迷宫生成过程”的。虽然我最后没把这个功能保留但不得不承认这个细节很有产品意识。另一个问题是它没有做纹理加载失败的错误处理。我本地放了一张地板贴图路径写错了大小写浏览器直接黑屏。Step 5 Preview 生成的代码里会监听onError回调并 fallback 到纯色材质GLM5.3 FlashX 则是一副“你路径错是你的事”的态度黑屏就黑屏。对不熟悉前端调试的人来说这种问题很劝退。3.5 运行调试与代码修补三个模型生成的代码都跑起来了但代价不同。Step 5 Preview 首次打开就能进迷宫只是鼠标交互需要修改DeepSeek V4 Pro 我合并模块之后修了两个错误又调整了迷宫尺寸GLM5.3 FlashX 我改了废 API、补了纹理加载兜底又加了帧率无关的移动速度计算才算能正常玩。修补移动速度这块值得单独说一说。三个模型初期都用了position.x speed * direction.x这种写法这会导致游戏在高刷新率显示器上跑得比低刷新率快。我最后全部统一改成了基于delta时间的速度控制const delta clock.getDelta(); player.position.x velocity.x * delta; player.position.z velocity.z * delta;这一步不是模型不会而是提示词里没有明确要求“帧率无关”。所以做 AI 辅助开发时不能指望模型自动考虑你运行时的硬件环境越是底层的细节越要在需求里写好。4. 结果量化对比与体验分析4.1 核心指标对比我把三个模型这次测试的数据整理成了表格。先声明一下这个数据只代表我这一轮测试环境和提示词下的表现模型版本也在快速迭代别把它当成永恒结论。对比项Step 5 PreviewDeepSeek V4 ProGLM5.3 FlashX生成耗时42 秒65 秒28 秒首次运行成功率1 次通过2 次修复后通过3 次修复后通过交付形式单 HTML开箱即用多模块需手动整合单 HTML但 API 过旧代码行数312468257迷宫生成正确性正确正确正确碰撞检测质量良好优秀一般交互体验鼠标锁定需修改拖拽视角较自然拖拽视角较自然显存/内存占用低纯前端渲染低纯前端渲染低纯前端渲染生成耗时这里有个前提GLM5.3 FlashX 是本地部署走的是 vLLM 推理另外两个走的是云 API。网络延迟和模型参数量级都不一样所以这个数据只能看个大概趋势。4.2 三个模型的优势和短板Step 5 Preview 给我留下的印象是“稳重”。它对现代 API 的掌握很准确生成代码的边界条件处理很细极少出现明显的幻觉 API。它的短板是代码风格偏保守一些交互设计不够大胆很少主动给你做加分项。DeepSeek V4 Pro 的强项是工程结构感。它写出来的代码像一位有架构洁癖的工程师写的模块划分合理注释完整。但这次测试也暴露了它的问题模型过于关注“怎么组织代码”反而忽略了“用户要的是立刻能跑的最简版本”。我需要的是单文件 Demo它却给了我一个可扩展项目这种“过度设计”在快速原型阶段有时候反而是负担。GLM5.3 FlashX 的速度优势明显适合需要快速出结果的脑暴场景。但它对 API 的更新较不敏感会写出一些已经被废弃的调用因此使用者必须具备一定的代码审查能力。如果你是纯新手指望它一次性生成完美代码风险稍高。4.3 从这次测试看 3D 游戏开发工具链顺着这次测试我也想把“3D 游戏开发工具”这个热搜话题聊透。现在 AI 模型写 3D 游戏基本集中在 Web 技术栈因为 Three.js、Babylon.js 这类库的示例数量多、训练语料丰富模型不容易写偏。如果你让 AI 直接帮你写一个 Unity 里的 C# 脚本它也能写但整个项目的配置、场景资源管理、序列化字段这些 Unity 特有的复杂结构AI 往往力不从心。所以我的建议是做快速 Demo 用 Three.js AI 是当前性价比最高的组合做中大型项目还是得用 Unity 或 UnrealAI 可以当脚本助手但别指望它从零给你生成整个工程。另外一个经常被忽略的工具是 PlayCanvas它自带资源管道和编辑器AI 生成代码后可以直接在 PlayCanvas 的脚本组件里跑比 Three.js 更适合多人协作。5. 常见问题与排查技巧实录5.1 部署和运行时的典型问题我把这次测试中遇到的高频问题做成一张速查表先给结论再展开解释。问题现象排查思路vLLM 镜像版本过旧权重加载后报 Unsupported operation检查模型仓库的 requirements.txt优先用 0.7.x/chat/completions返回截断代码后半段缺失调大max_tokens开启流式输出浏览器黑屏贴图加载失败未走错误回调给纹理加载加onError兜底移动速度不稳同一游戏在不同刷新率下快慢不一改用delta时间控制位移模型生成废弃 API如BoxBufferGeometry报错搜一下当前版本文档手动替换为新 API关于 vLLM 版本我前面已经说了不少。这里再补充一个点如果你手头只有 910B 或者消费级显卡别硬上 GLM5.3 满血版选 FlashX 这类轻量变体会省一大半心。部署好后先用vllm serve --host 0.0.0.0 --port 8000起服务再配合curl发一个短请求验证不要一上来就跑完整游戏代码生成不然报错日志能把你淹没。关于max_tokens云 API 默认值往往不够用。我测试时给 Step 5 Preview 传输过一次 4000 token 的代码它在中间直接切断补全出来的代码直接跳过了一个函数。后来我统一把max_tokens设为 8000才算稳了。5.2 提示词和调试的独家心得这次测试给我最大的感受是提示词里必须写清楚“版本约束”和“交付形态”。同样是“写一个 3D 游戏”不限定 Three.js 版本的话模型可能会给你一个用 r100 之前语法写的代码不限定“单文件”的话DeepSeek V4 Pro 就会给你拆出一堆模块。你越早把约束写在需求里后面手动修补的成本越低。还有一个技巧是让模型“先给方案再写代码”。Step 5 Preview 在生成前主动回了一段实现思路那段思路对我判断它是否会走弯路非常有帮助。如果你用的是 DeepSeek V4 Pro 或 GLM5.3也可以在提示词里直接加一句“先说明实现步骤再输出代码”。这种提示词通常能降低大模型的出错率尤其是遇到迷宫生成这类有算法结构的任务时。另外本地起一个 Vite 服务是非常有必要的。直开 HTML 文件时Three.js 的纹理加载会因为 CORS 策略报跨域错误很多初学者以为是代码问题其实是文件协议问题。只需要在项目目录跑一句npm create vitelatest然后选择 vanilla再把模型生成的代码放进index.html就好很多。6. 最后说点我的个人体会如果你也打算用这几个模型搞 3D 游戏我的建议是先用 Step 5 Preview 快速验证玩法和算法因为它出活最稳到需要正式工程化的时候再让 DeepSeek V4 Pro 帮你整理模块结构至于 GLM5.3 FlashX适合在脑暴阶段大量生成可选方案但要带着“审查者思维”去用别直接全盘接受。我自己平时做 AI 辅助开发已经习惯了保留一套“代码审查清单”检查废弃 API、检查资源加载失败兜底、检查时间步长、检查模块边界。这次三个模型的实测本质上就是把这份清单完整跑了一遍。相比谁强谁弱我更想说的是AI 代码生成工具正在实打实地改变做游戏原型的方式——过去需要一整天从零搭场景、调相机、写碰撞现在一个小时就能做出一个能跑的迷宫。但工具越强对使用者判断力的要求就越高。你能不能在模型写出的几百行代码里找到那一个隐藏的 Bug将直接决定你的项目能不能顺利上线。最后再分享一个小技巧无论用哪个模型生成完代码后先在浏览器控制台里按报错顺序逐个修不要跳着修。因为 Three.js 的初始化是链式的前面报错会导致后面的场景对象为undefined你修完第一个错误后后面的错误很可能自动消失。我这次测试里有三处看起来互不相干的报错其实根源就是同一个初始化顺序问题。先把运行日志发完整顺一遍比盲目改代码高效得多。