最近我把几个新模型拉到同一个考场里做了一件挺有意思的事用完全相同的需求让 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3 分别从零做一个 3D 小游戏然后对比它们从出方案到跑通、再到改需求的全过程。先说结论三个模型都能写而且都写出了能玩的程度但写出来的东西完全是三种性格——一个像先搭骨架再填肉的工程师一个像什么都想加的功能狂一个像话不多但活很细的老实人。这篇实战记录不聊参数对比只聊真实上手时的体验、翻车点和值得借鉴的用法。这个选题其实有很强的现实意义。AI 编程工具现在不缺“能写代码”的模型缺的是“能接手一个小项目并推进到可交付状态”的模型。3D 游戏恰好是个非常好的压力测试场它涉及三维数学、物理模拟、渲染管线、交互设计还要考虑性能和兼容性任何一个环节出问题都会让整个项目卡死。如果你也在纠结该把哪个模型放进自己的工作流或者想看看这些模型在复杂任务下到底什么水平这篇文章应该能给你一个直观的参考。1. 测试环境与任务设计为什么偏要用 3D 游戏做考题1.1 考核任务并不是“随便做个游戏”那么简单给 AI 下达的原始需求我尽量写得像一个真实产品经理的需求文档而不是一句“帮我做个游戏”就完事。需求是这样的做一个网页 3D 小游戏第三人称视角玩家在一个箱庭场景里自由移动可以跳跃场景里散落着宝石收集满 10 颗后触发胜利界面同时有简单的计分 UI 和重置按钮。运行环境锁定浏览器技术栈不限定但必须是纯前端实现。之所以卡这么死是因为我想看三件事。第一模型能不能把模糊需求转化成明确的技术方案第二模型写代码时有没有考虑“跑不跑得起来”这件事而不是只输出一段看起来很美的代码第三模型在处理三维数学和物理交互这种容易出错的地方时会不会自己给自己埋雷。事实证明这三个维度拉开的差距比我预想的大得多。散热问题我先放一边聊聊更关键的测试环境。三套测试我都跑在同一台开发机上保证不因为硬件差异影响判断。GPU 是 RTX 4070 级别浏览器用 Chrome 稳定版。Step 5 Preview 我用的官方 Web 端交互DeepSeek V4 Pro 和 GLM5.3 则是通过 API 接入本地调试面板方便记录完整生成过程和每一轮修复对话。三个模型的上下文窗口都足够大首轮生成的代码量完全装得下所以不存在“生成一半被截断”的问题。1.2 打分维度和方法说明为了让对比不是纯粹的感觉党我预设了五个打分项首轮可运行性、核心体验还原度、代码可维护性、修复问题所需轮次、性能与兼容性。每项满分 10 分总分 50。这三个模型的测试流程完全一致先给初始需求记录首轮输出然后本地运行记录报错和执行现象再把报错信息原样回传观察模型修复能力最后追加同一个改需求指令看模型在既有代码上做增量修改的表现。这里要强调一个容易忽略的前提我没有给任何模型喂示例代码也没有给“Three.js 项目结构”之类的提示。纯粹看它们自己的知识储备和代码组织能力。另外我也没有中途给模型截图反馈因为实际开发中大多数人的工作流还是以文本交互为主能通过文字描述定位问题才是更通用的能力。如果未来有人在做多模态版本测试把截图回传功能加进来结论可能会变化但那个不在今天的讨论范围内。2. 三家首轮交付的现场记录谁一次跑通谁改了八轮2.1 Step 5 Preview稳到不像预览版Step 5 Preview 首轮给出的代码让我有点意外。它用了 Three.js 作为渲染核心目录结构非常清晰分了 main.js、player.js、level.js、collectible.js 四个模块每个文件的职责边界很清楚甚至还带了一个简易的 README 说明运行方式。这套结构放在一个人类工程师手上也得花点时间才能理出来更别说模型一次性生成。实际运行起来首轮代码在 Chrome 里就能直接跑控制台零报错。第一次进入场景能看到一个方正的低多边形箱庭里面有台阶、柱子和斜坡宝石是旋转的金色八面体人物是个灰色胶囊体虽谈不上好看但基础的感觉已经出来了。唯一让人皱眉的问题是摄像机初始位置太贴近地面视角几乎贴着角色的后脑勺视野被角色的胶囊体挡掉一大块。我把这个现象描述给模型它第二次回复就把摄像机拉高并加了第三人称跟随逻辑顺带还处理了视角被遮挡时的射线检测——这个细节放在后面专门讲。首轮给分可运行性 9 分核心体验还原度 8 分可维护性 9 分。丢掉的分数主要在美术观感上它默认配色偏灰暗没有做任何后期处理显得有点“程序员审美”。不过这本来也不是模型的核心能力后面看它在逻辑上的表现更关键。2.2 DeepSeek V4 Pro功能太多第一次跑直接黑屏DeepSeek V4 Pro 首轮生成代码的量非常大大到什么程度呢整个项目解压后有 3000 多行里面不仅有游戏本体还有一套简单的关卡编辑器、一个调试面板、一组随机地图生成函数甚至预留了多语言 UI 的接口。看到这个我都愣住了因为需求里根本没提这些。这种“过度设计”在 AI 生成代码里其实挺常见的模型会不自觉地把所有关联知识都塞进来结果就是核心游戏逻辑被淹没在大量边缘功能里。跑起来的体验更是戏剧化。首轮代码在浏览器里打开页面是黑的控制台报了一个错GLSL shader 里变量名冲突。问题出在它同时引入了后期处理库和自定义着色器两个库之间的 uniform 命名发生了覆盖导致渲染管线挂掉。我把报错信息完整回传DeepSeek 第二轮的修复是把后期处理库的引入顺序调整了一下同时删掉了自定义着色器里的冗余声明。第二轮确实跑通了但帧率只有 30 出头因为它默认开了抗锯齿、屏幕空间环境光遮蔽和软阴影三者的开销叠加在一起对这个场景来说严重过剩。首轮给分可运行性 5 分核心体验还原度 7 分可维护性 5 分。功能丰富是把双刃剑在需要快速出活的项目里它是加分项但在需要精确定制的小场景里多余的东西只会拖慢节奏。2.3 GLM5.3下限极高但创意基本没有GLM5.3 的输出风格和另外两个完全不是一个路子。它给出的代码同样基于 Three.js但结构上是典型的“单文件流”HTML、CSS、JS 全塞在一个文件里总共 700 多行。优点是打开即用没有任何依赖配置缺点是后续维护会有点痛苦所有逻辑揉在一起改一处可能牵连别处。运行结果倒是出乎意料地稳首轮直接跑通控制台干干净净。场景布局很规整一个对称的矩形平台四角放宝石中心放一个高台跳跃上去可以拿到额外奖励宝石。它甚至做了宝石闪烁的动画效果虽然只是材质自发光强度的正弦波动但看起来确实比 Step 5 的静态旋转宝石舒服一些。手感方面移动和跳跃响应都很灵敏没有出现粘滞感。不过它也有很明显的短板对“游戏性”的理解非常机械化。整个场景就是一个平面加几个障碍物没有任何探索层次收集满 10 颗宝石后弹出的是浏览器原生 alert 弹窗而不是游戏内的 UI 面板。功能上都满足需求但体验上像是给需求文档交作业缺少那种“设计过”的感觉。首轮给分可运行性 9 分核心体验还原度 6 分可维护性 6 分。它是最让人省心的也是最不会给人惊喜的。这个性格在产品研发里其实有独特价值后面增量修改环节会体现出来。3. 最容易让 AI 翻车的 4 个 3D 技术点横向对比3.1 碰撞检测从“穿模地狱”到“靠谱边界”3D 游戏里碰撞检测是最容易出幺蛾子的环节也是三个模型差距最大的地方。Step 5 Preview 采用的是最简单也最可靠的 AABB 轴对齐包围盒方案移动时先做水平方向的碰撞判定再做垂直方向的分帧处理避免了一次移动里同时撞墙和撞地导致的位置回弹。实际跑起来手感合格不会穿模也没有明显的粘墙感。DeepSeek V4 Pro 在这块明显好高骛远。它用的是 BVH 加速结构和射线检测组合方案听起来很高级但首轮代码里的包围盒更新逻辑有个致命 bug物体旋转后包围盒的 min 和 max 值没有重新计算导致碰撞区域和实际模型严重错位。角色走到柱子旁边时明明肉眼看着还有半米远却被空气墙挡住了。我把这个问题反馈给它它前三次修复都是往 BVH 里加节点更新逻辑一直没解决根本问题。第四次换了个思路把碰撞体简化成几个固定球体叠加才算稳住了局面。这轮反复折腾最大的教训是模型在遇到复杂算法问题时容易在原有错误思路上越修越深而不是跳出来换一个更简单的方案。GLM5.3 用的方案最朴素——胶囊体近似碰撞。它把角色抽象成一个竖直胶囊体碰撞检测时用圆柱体的二维包围盒加上高度方向的区间判断。这个方案没有 BVH 那么炫但在这个场景规模下效率极高而且几乎不会出 bug。实测下来三个模型里 GLM5.3 的碰撞手感最扎实角色贴墙滑动很顺畅没有卡顿和抖动。3.2 跳跃手感可变跳跃高度是分水岭跳跃手感是另一个拉开差距的点。很多 AI 生成的游戏代码里跳跃就是给个向上的初速度重力加速度恒定跳多高完全写死。三个模型里只有 Step 5 Preview 实现了可变跳跃高度玩家按下跳跃键后角色上升松开键则提前进入下落阶段按住不放才能跳到最大高度。这个机制看起来简单但实现需要把“按键持续时间”这个变量接入物理计算代码量比固定跳跃多不少。DeepSeek 给的跳跃是参数化设计所有物理常数都暴露成可配置变量理论上可以通过调参实现可变跳跃但它默认配置写死了需要手动改代码。这在实际体验中就是“按一下跳一下固定高度”手感很死板。GLM5.3 则是在首版需求里压根没做跳跃高度参数化它的跳跃只是给 y 轴速度设了个定值配合固定重力常数落点永远一致。不过它加了一个很多人没注意到的细节落地时做了短暂的速度衰减缓冲角色落地不会像踩到弹簧一样立刻停住而是有轻微的下蹲压缩动画。这个细节让它的跳跃体验反而是三者中最自然的。我特别想强调跳跃手感这个东西对 AI 代码生成的意义。它是典型的“需求里没有明说但玩家一上手就能感觉到”的隐性需求。模型能不能主动补齐这种隐性需求很大程度上代表了它对游戏开发的理解深度。在这点上 Step 5 做的最到位GLM 则体现了另一种智慧——它虽然没做可变跳跃但用落地缓冲掩盖了手感缺陷说明它对用户体验有感知。3.3 摄像机跟随遮挡处理和阻尼系数决定舒适度第三人称视角的摄像机问题可以说是 AI 写 3D 游戏时最容易懵圈的领域。我见过太多直接用固定相机位置或者简单跟随的代码角色走到墙后就变成幽灵视角。三个模型里处理这个问题最标准的是 Step 5 Preview它在摄像机和角色之间做射线检测如果射线碰到障碍物就把摄像机沿向量拉近到碰撞发生点之前避免视角穿墙。这是正经第三人称游戏的标准做法能一次性写对说明它对游戏开发体系是有系统认知的。DeepSeek 在这块的表现让人哭笑不得。它给摄像机加了一套完整的平滑阻尼系统代码逻辑非常优雅Sprite 跟随算法有了阻尼系数也有了但初始的阻尼值设得过大导致摄像机像拖着个橡皮筋一样在角色后面甩来甩去角色停下后摄像机还要晃好几秒才稳定。反馈问题后它调整了阻尼系数到合理范围但因为这个调整是在它的调试面板里改的参数而不是在代码里写的导致我把代码存下来重新打开时参数又回到了初始值——模型完全没有意识到配置和代码之间的持久化关系。GLM5.3 的摄像机是最简单的固定偏移式跟随没有阻尼没有碰撞检测。角色往左转镜头跟着平移角色靠近墙镜头直接穿模。在开阔场景玩没什么问题但一进入狭窄通道就非常出戏。它这个方案倒也好修但修改过程让我意识到一个问题GLM 在很多细节上选择“够用就行”的路径导致它在简单场景下变现很好但扩展性受限。3.4 渲染性能光影开满和低配优化是两个极端性能方面的测试我把浏览器降级到了普通笔记本也能跑的集成显卡环境这样才能看出渲染开销的影响。Step 5 的代码对移动端有自觉的优化意识它把阴影贴图的分辨率调低了抗锯齿用了 FXAA 而不是 MSAA场景里的几何体做了合并处理Draw Call 数量压缩得比较低。实测帧率稳定在 60 左右很流畅。DeepSeek 是最大的性能吞金兽。首轮代码默认开启屏幕空间环境光遮蔽SSAO和软阴影这两个效果在 3A 大作里都是吃资源的选项放进一个只有几个简单几何体的网页游戏里帧率能被压到 30 属实离谱。而且它没有做任何移动端降级方案手机浏览器打开大概率直接卡成幻灯片。我需要手动注释掉相关代码才算把帧率拉回来。GLM5.3 的做法最“聪明”它压根没有开任何高级渲染功能。阴影用的是最基本的平面投射阴影光源数量只有一个材质全部是 MeshLambertMaterial 这种廉价材质整个渲染开销低到可以忽略。后期如果想要更好的光影效果需要自己往里加但也正因为它的基础够干净往上加东西反而很顺手。4. 代码质量与二次修改真实项目里最关键的能力4.1 代码可读性、命名规范与模块化程度如果只是把游戏做出来能跑那三个模型都合格但放到真实项目里代码可维护性才是决定能不能用的问题。Step 5 Preview 的代码风格最接近职业工程师的产出命名规范统一函数拆得细每个函数的职责不超过一个屏幕能看全的范围。它还用了一个小技巧把游戏状态机写成一个独立的类所有交互通过事件驱动这让后续加功能变得非常容易。DeepSeek 的代码工程能力其实也不差但被它的“功能堆砌”习惯拖累了。它的文件里充斥着大量暂时用不到的辅助函数和未激活的特性开关阅读时必须不停跳过去确认哪些是有效代码、哪些是预留代码。这种习惯在大型项目里非常致命因为任何人接手都会陷入“这段代码到底跑不跑”的疑惑。GLM5.3 的单文件风格在初期体验有优势但后续修改时问题就暴露了。它的事件绑定分散在文件各处的回调函数里修改一个按钮的交互逻辑需要在三个位置同步改动很容易漏改。不过它的注释质量非常高每个函数都有清晰的使用说明读起来像是一份带注解的需求文档这对联调阶段的帮助很大。4.2 追加改需求的实测给三个模型加“倒计时”功能为了测试增量修改能力我给三个模型追加了同一个需求在现有游戏里增加倒计时功能5 分钟内未收集满 10 颗宝石则触发失败界面。这个需求涉及 UI 层、逻辑层、状态监听三个层面的改动非常适合检验模型对既有代码的理解能力。Step 5 返回的修改方案非常干净在状态机里新增一个 timer 管理器UI 层通过事件监听刷新数字游戏结束时调用统一的结算逻辑。它只新增了不到 80 行代码并且没有动到任何原有功能。改完后我连续玩了三局发现计时器重置逻辑很严谨重新开始游戏时会正确地清掉上一局的定时器不会出现叠加计时的问题。DeepSeek 的修改过程就比较有意思了。它因为代码里已经有调试面板和状态管理器的底子理论上加个倒计时很容易但问题就出在它的状态管理器太复杂了倒计时更新触发了它预设的自动保存逻辑导致页面每隔几秒就弹出一个调试日志浮窗干扰正常游戏。我反馈后它花了一轮才找到日志浮窗的触发源头。实际看到的效果是功能完成了但过程伴随着一些噪音。GLM5.3 让我最意外。它在单文件结构下修改起来反而很快直接把倒计时逻辑写进了游戏主循环同时用闭包管理定时器。它的代码量虽然多了但改完后行为非常正确失败界面是嵌入游戏画布里的不像首轮那样用浏览器弹窗。这说明它在理解“游戏内 UI 到底是什么”这件事上确实有进步。4.3 部署与移动端适配从 Web 到安卓壳这里要插一个开发中绕不开的话题很多人做网页 3D 游戏不满足于只在浏览器里玩还想打包成移动端应用。我在测试时也顺便观察了几个模型对部署方案的敏感度。三家的代码都是纯前端实现理论上都能通过 Capacitor 或 Cordova 这类工具套壳打包安卓应用但实际操作差别很大。Step 5 的代码因为模块划分清晰打包时只需要把静态文件放进 WebView 就能跑几乎没有适配成本。DeepSeek 的代码里有一处对 window.innerWidth 的即时调用没有做 resize 监听在安卓 WebView 中屏幕旋转时会拿错宽高游戏画面会错位。GLM5.3 的单文件结构在打包时最粗暴直接把所有内容粘进一个 HTML实践证明反而最不容易出问题。所以如果你打算做开源安卓 3D 游戏这类项目我个人的建议是首轮生成时让模型输出“单文件模式”后面再来考虑拆模块这样可以避免很多移动端适配的坑。顺带说一个部署相关的细节。社区里有人讨论 GLM5.3 本地私有化部署时用哪个版本的 vLLM 镜像我自己的实测经验是这类模型的部署兼容性高度依赖推理框架版本没必要追新追快用官方文档推荐的稳定版本镜像最省心。如果出现 attention 后端报错或者显存分配异常不要急着换模型先检查一下 vllm 和 CUDA 的版本组合很多问题其实是框架版本和算子库不匹配导致的。这条经验同样适用于其他开源模型的本地部署踩过坑的人应该懂我说的是什么意思。考虑到当前实时移动端的 Web 渲染性能路径已经比较成熟如果你是把项目推到真实安卓设备上优先保证 WebView 启用硬件加速开关同时避免在高密度屏幕上开超采样抗锯齿这个优化能省下一大半 GPU 开销。我在测试三个模型时都手动确认了这两个硬件开关排除了环境因素对性能结论的干扰。5. 常见问题速查与避坑手册5.1 首轮代码常见的 5 个典型故障第一类故障是“渲染黑屏”。三个模型里有两个都遇到过区别在于原因不同。Step 5 第一次黑屏是因为纹理贴图的加载路径用了相对路径本地文件协议下浏览器拦截了资源请求DeepSeek 的则是 shader 变量冲突。排查思路很简单看到黑屏先打开控制台看有没有红色报错有报错就按错误定位没有报错就挨个检查场景、相机、渲染器的初始化顺序以及循环渲染函数有没有被调用。第二类故障是“角色穿模”。前面说过通常是碰撞检测的碰撞体尺寸小于模型可视尺寸或者是物体旋转后包围盒没更新。快速修复方式是把碰撞体放大到模型视觉尺寸的 80% 到 90%宁大勿小。第三类故障是“帧率暴跌”。优先怀疑阴影贴图分辨率和抗锯齿级别是不是开太高其次检查是否有不必要的材质变化导致 shader 重新编译。把渲染器参数往下调一档大概率能解决。第四类故障是“点击没反应”。这类问题最隐蔽因为控制台没有报错界面也正常但交互事件不触发。我排查后发现三个模型里有两个把点击事件的监听器绑定到了 renderer.domElement 上而实际需要监听的应该是 canvas 容器两者在坐标换算时差了偏移量导致点击判定区域不准。直接把监听器绑定到 document 上可以规避这个问题。第五类故障是“重新加载后状态错乱”。这个问题在 GLM5.3 和 DeepSeek 身上都出现过原因是它们把游戏状态变量初始化放在了模块顶层页面重新加载时会复用旧的状态值。可靠做法是把整个游戏初始化包装成一个 reset() 函数所有状态变量在函数内部声明刷新时一切重来。5.2 给 AI 下达 3D 任务时建议遵循的 3 条原则基于这次测试我总结了三条给 AI 下达 3D 任务时需要特别注意的原则。第一条把需求分层表述。不要只给一句“做个 3D 游戏”或者“生成个场景”而是拆成场景结构、玩家控制、物体交互、界面逻辑四个层面每个层面用两到三句话说明这样模型生成的结构不会失衡。我在测试中对三个模型都用了这套分层描述效果明显好于直接给笼统需求。第二条明确技术边界。如果你不希望模型引入额外的库或者不希望它默认开启某些高级渲染特性一定要在初始指令里写清楚。DeepSeek 私自引入 SSAO 和后期处理库就是吃了没给技术边界的亏。但要注意技术边界也不用卡得太死最好不要指定具体的 Three.js 版本除非你有特殊兼容性需求因为模型对旧版本的 API 记忆可能已经和最新版脱节反而容易生成过时代码。第三条准备好“诊断式反馈”而非“你认为式反馈”。当模型给出的代码报错时直接把控制台的错误信息原样复制给模型同时附上出错的文件和行号而不是说“好像有点问题”。在测试里最明显的一个例子是 DeepSeek 在 BVH 碰撞问题上的反复挣扎直到我在反馈里附上了“碰撞检测函数返回的碰撞距离一直是 NaN”这段错误现象它才意识到问题出在数据更新顺序上。你给出的诊断信息越精确模型修复得越快。注意向 AI 要代码和向 AI 要解决方案是两回事。如果你只给它说“帮我改一改让它不乱穿”它多半只能基于猜测去调整参数运气好碰对了就修好了运气不好就陷入瞎试循环。把“现象 报错 复现路径”描述清楚是对双方都负责的协作方式。5.3 一个被低估的辅助技巧让模型先输出“技术选型说明”我在测试里留了一个隐藏考察点首轮输出之前我要求三个模型先用 5 句话说明它计划用什么技术栈、每个模块怎么分工、运行时会遇到什么风险。结果非常有意思Step 5 给出的选型说明和最终代码高度一致说明它的代码生成是“先想后做”的GLM5.3 的说明简练但精准每个判断都对DeepSeek 的说明最详细但它说“将使用后期处理提升视觉体验”这句话后来被证明就是它性能拖垮的根源。这个技巧真正好用的地方在于它逼着模型在动手前把设计意图说清楚你可以提前拦截掉不合理的方案而不是等代码写完再返工。我自己在实际项目中已经把这一条固化成了流程任何 AI 帮我生成超过 200 行代码之前我都会先让它输出一份简短的实现方案审一遍再放行。这个流程成本极低收益却非常大。6. 这次实测给我的最终体会三个模型跑完这个 3D 游戏任务我的直观感受是它们像三种不同性格的协作者。Step 5 Preview 是最接近“经验丰富的前端工程师”的那一个它结构意识强能主动补齐摄像机遮挡检测这类隐性需求而且修复 bug 的效率很高适合用来搭建有后续迭代计划的项目骨架。DeepSeek V4 Pro 像那种想法很多、动手很猛的同事它会在你只想要一个三明治的时候给你上一桌满汉全席里面有好多你暂时用不上的菜但其中确实藏着几个有用的思路需要有人帮它做减法。GLM5.3 则像沟通成本极低的老实人它不会给你惊喜但给你的东西质量稳定、很少跑偏特别适合用在边界明确、需求清晰的生产环节。就单次任务综合得分看Step 5 Preview 是这次实测的优胜者但我并不建议所有人无脑选它。如果你的使用场景是快速验证一个想法或者临时解决一个问题那 GLM5.3 的单文件输出和低出错率反而更合适。如果你在做创意原型希望 AI 给你带来超出预期的功能参考DeepSeek 的过度设计也许能给你一些启发。关键在于你要清楚自己需要什么然后把预期值设置对。我还想多说一句关于提示词工程之外的东西。这次测试让我重新审视了“AI 编程到底是在考验谁”这个问题。表面上是在考验模型的代码能力实际上也在考验使用者的需求拆解能力和诊断能力。同一份需求拆得越清晰模型的表现就越好同一个报错给出的信息越准确修复就越快。换句话说一个会用 AI 的工程师价值不在于能输写多少 prompt而在于能准确描述问题、判断方案的合理性、并在模型给出错误路径时及时拉回来。这个能力短期看是效率工具长期看是职业护城河。最后再分享一个从这次测试里总结的小经验如果你想让 AI 生成的项目保持长期可维护性那就在每个模块的文件头部让模型加一段注释说明这个文件的职责、被谁引用、修改影响的连锁范围。这一步在纯人写代码时很难持续执行但 AI 做起来毫不费力。我在这三个功能的迭代过程中发现加上这些注释之后不管是我自己还是模型后续做增量修改定位问题的速度都提升了一大截。养成这个习惯你会回来感谢我的。
最近我把几个新模型拉到同一个考场里做了一件挺有意思的事用完全相同的需求让 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3 分别从零做一个 3D 小游戏然后对比它们从出方案到跑通、再到改需求的全过程。先说结论三个模型都能写而且都写出了能玩的程度但写出来的东西完全是三种性格——一个像先搭骨架再填肉的工程师一个像什么都想加的功能狂一个像话不多但活很细的老实人。这篇实战记录不聊参数对比只聊真实上手时的体验、翻车点和值得借鉴的用法。这个选题其实有很强的现实意义。AI 编程工具现在不缺“能写代码”的模型缺的是“能接手一个小项目并推进到可交付状态”的模型。3D 游戏恰好是个非常好的压力测试场它涉及三维数学、物理模拟、渲染管线、交互设计还要考虑性能和兼容性任何一个环节出问题都会让整个项目卡死。如果你也在纠结该把哪个模型放进自己的工作流或者想看看这些模型在复杂任务下到底什么水平这篇文章应该能给你一个直观的参考。1. 测试环境与任务设计为什么偏要用 3D 游戏做考题1.1 考核任务并不是“随便做个游戏”那么简单给 AI 下达的原始需求我尽量写得像一个真实产品经理的需求文档而不是一句“帮我做个游戏”就完事。需求是这样的做一个网页 3D 小游戏第三人称视角玩家在一个箱庭场景里自由移动可以跳跃场景里散落着宝石收集满 10 颗后触发胜利界面同时有简单的计分 UI 和重置按钮。运行环境锁定浏览器技术栈不限定但必须是纯前端实现。之所以卡这么死是因为我想看三件事。第一模型能不能把模糊需求转化成明确的技术方案第二模型写代码时有没有考虑“跑不跑得起来”这件事而不是只输出一段看起来很美的代码第三模型在处理三维数学和物理交互这种容易出错的地方时会不会自己给自己埋雷。事实证明这三个维度拉开的差距比我预想的大得多。散热问题我先放一边聊聊更关键的测试环境。三套测试我都跑在同一台开发机上保证不因为硬件差异影响判断。GPU 是 RTX 4070 级别浏览器用 Chrome 稳定版。Step 5 Preview 我用的官方 Web 端交互DeepSeek V4 Pro 和 GLM5.3 则是通过 API 接入本地调试面板方便记录完整生成过程和每一轮修复对话。三个模型的上下文窗口都足够大首轮生成的代码量完全装得下所以不存在“生成一半被截断”的问题。1.2 打分维度和方法说明为了让对比不是纯粹的感觉党我预设了五个打分项首轮可运行性、核心体验还原度、代码可维护性、修复问题所需轮次、性能与兼容性。每项满分 10 分总分 50。这三个模型的测试流程完全一致先给初始需求记录首轮输出然后本地运行记录报错和执行现象再把报错信息原样回传观察模型修复能力最后追加同一个改需求指令看模型在既有代码上做增量修改的表现。这里要强调一个容易忽略的前提我没有给任何模型喂示例代码也没有给“Three.js 项目结构”之类的提示。纯粹看它们自己的知识储备和代码组织能力。另外我也没有中途给模型截图反馈因为实际开发中大多数人的工作流还是以文本交互为主能通过文字描述定位问题才是更通用的能力。如果未来有人在做多模态版本测试把截图回传功能加进来结论可能会变化但那个不在今天的讨论范围内。2. 三家首轮交付的现场记录谁一次跑通谁改了八轮2.1 Step 5 Preview稳到不像预览版Step 5 Preview 首轮给出的代码让我有点意外。它用了 Three.js 作为渲染核心目录结构非常清晰分了 main.js、player.js、level.js、collectible.js 四个模块每个文件的职责边界很清楚甚至还带了一个简易的 README 说明运行方式。这套结构放在一个人类工程师手上也得花点时间才能理出来更别说模型一次性生成。实际运行起来首轮代码在 Chrome 里就能直接跑控制台零报错。第一次进入场景能看到一个方正的低多边形箱庭里面有台阶、柱子和斜坡宝石是旋转的金色八面体人物是个灰色胶囊体虽谈不上好看但基础的感觉已经出来了。唯一让人皱眉的问题是摄像机初始位置太贴近地面视角几乎贴着角色的后脑勺视野被角色的胶囊体挡掉一大块。我把这个现象描述给模型它第二次回复就把摄像机拉高并加了第三人称跟随逻辑顺带还处理了视角被遮挡时的射线检测——这个细节放在后面专门讲。首轮给分可运行性 9 分核心体验还原度 8 分可维护性 9 分。丢掉的分数主要在美术观感上它默认配色偏灰暗没有做任何后期处理显得有点“程序员审美”。不过这本来也不是模型的核心能力后面看它在逻辑上的表现更关键。2.2 DeepSeek V4 Pro功能太多第一次跑直接黑屏DeepSeek V4 Pro 首轮生成代码的量非常大大到什么程度呢整个项目解压后有 3000 多行里面不仅有游戏本体还有一套简单的关卡编辑器、一个调试面板、一组随机地图生成函数甚至预留了多语言 UI 的接口。看到这个我都愣住了因为需求里根本没提这些。这种“过度设计”在 AI 生成代码里其实挺常见的模型会不自觉地把所有关联知识都塞进来结果就是核心游戏逻辑被淹没在大量边缘功能里。跑起来的体验更是戏剧化。首轮代码在浏览器里打开页面是黑的控制台报了一个错GLSL shader 里变量名冲突。问题出在它同时引入了后期处理库和自定义着色器两个库之间的 uniform 命名发生了覆盖导致渲染管线挂掉。我把报错信息完整回传DeepSeek 第二轮的修复是把后期处理库的引入顺序调整了一下同时删掉了自定义着色器里的冗余声明。第二轮确实跑通了但帧率只有 30 出头因为它默认开了抗锯齿、屏幕空间环境光遮蔽和软阴影三者的开销叠加在一起对这个场景来说严重过剩。首轮给分可运行性 5 分核心体验还原度 7 分可维护性 5 分。功能丰富是把双刃剑在需要快速出活的项目里它是加分项但在需要精确定制的小场景里多余的东西只会拖慢节奏。2.3 GLM5.3下限极高但创意基本没有GLM5.3 的输出风格和另外两个完全不是一个路子。它给出的代码同样基于 Three.js但结构上是典型的“单文件流”HTML、CSS、JS 全塞在一个文件里总共 700 多行。优点是打开即用没有任何依赖配置缺点是后续维护会有点痛苦所有逻辑揉在一起改一处可能牵连别处。运行结果倒是出乎意料地稳首轮直接跑通控制台干干净净。场景布局很规整一个对称的矩形平台四角放宝石中心放一个高台跳跃上去可以拿到额外奖励宝石。它甚至做了宝石闪烁的动画效果虽然只是材质自发光强度的正弦波动但看起来确实比 Step 5 的静态旋转宝石舒服一些。手感方面移动和跳跃响应都很灵敏没有出现粘滞感。不过它也有很明显的短板对“游戏性”的理解非常机械化。整个场景就是一个平面加几个障碍物没有任何探索层次收集满 10 颗宝石后弹出的是浏览器原生 alert 弹窗而不是游戏内的 UI 面板。功能上都满足需求但体验上像是给需求文档交作业缺少那种“设计过”的感觉。首轮给分可运行性 9 分核心体验还原度 6 分可维护性 6 分。它是最让人省心的也是最不会给人惊喜的。这个性格在产品研发里其实有独特价值后面增量修改环节会体现出来。3. 最容易让 AI 翻车的 4 个 3D 技术点横向对比3.1 碰撞检测从“穿模地狱”到“靠谱边界”3D 游戏里碰撞检测是最容易出幺蛾子的环节也是三个模型差距最大的地方。Step 5 Preview 采用的是最简单也最可靠的 AABB 轴对齐包围盒方案移动时先做水平方向的碰撞判定再做垂直方向的分帧处理避免了一次移动里同时撞墙和撞地导致的位置回弹。实际跑起来手感合格不会穿模也没有明显的粘墙感。DeepSeek V4 Pro 在这块明显好高骛远。它用的是 BVH 加速结构和射线检测组合方案听起来很高级但首轮代码里的包围盒更新逻辑有个致命 bug物体旋转后包围盒的 min 和 max 值没有重新计算导致碰撞区域和实际模型严重错位。角色走到柱子旁边时明明肉眼看着还有半米远却被空气墙挡住了。我把这个问题反馈给它它前三次修复都是往 BVH 里加节点更新逻辑一直没解决根本问题。第四次换了个思路把碰撞体简化成几个固定球体叠加才算稳住了局面。这轮反复折腾最大的教训是模型在遇到复杂算法问题时容易在原有错误思路上越修越深而不是跳出来换一个更简单的方案。GLM5.3 用的方案最朴素——胶囊体近似碰撞。它把角色抽象成一个竖直胶囊体碰撞检测时用圆柱体的二维包围盒加上高度方向的区间判断。这个方案没有 BVH 那么炫但在这个场景规模下效率极高而且几乎不会出 bug。实测下来三个模型里 GLM5.3 的碰撞手感最扎实角色贴墙滑动很顺畅没有卡顿和抖动。3.2 跳跃手感可变跳跃高度是分水岭跳跃手感是另一个拉开差距的点。很多 AI 生成的游戏代码里跳跃就是给个向上的初速度重力加速度恒定跳多高完全写死。三个模型里只有 Step 5 Preview 实现了可变跳跃高度玩家按下跳跃键后角色上升松开键则提前进入下落阶段按住不放才能跳到最大高度。这个机制看起来简单但实现需要把“按键持续时间”这个变量接入物理计算代码量比固定跳跃多不少。DeepSeek 给的跳跃是参数化设计所有物理常数都暴露成可配置变量理论上可以通过调参实现可变跳跃但它默认配置写死了需要手动改代码。这在实际体验中就是“按一下跳一下固定高度”手感很死板。GLM5.3 则是在首版需求里压根没做跳跃高度参数化它的跳跃只是给 y 轴速度设了个定值配合固定重力常数落点永远一致。不过它加了一个很多人没注意到的细节落地时做了短暂的速度衰减缓冲角色落地不会像踩到弹簧一样立刻停住而是有轻微的下蹲压缩动画。这个细节让它的跳跃体验反而是三者中最自然的。我特别想强调跳跃手感这个东西对 AI 代码生成的意义。它是典型的“需求里没有明说但玩家一上手就能感觉到”的隐性需求。模型能不能主动补齐这种隐性需求很大程度上代表了它对游戏开发的理解深度。在这点上 Step 5 做的最到位GLM 则体现了另一种智慧——它虽然没做可变跳跃但用落地缓冲掩盖了手感缺陷说明它对用户体验有感知。3.3 摄像机跟随遮挡处理和阻尼系数决定舒适度第三人称视角的摄像机问题可以说是 AI 写 3D 游戏时最容易懵圈的领域。我见过太多直接用固定相机位置或者简单跟随的代码角色走到墙后就变成幽灵视角。三个模型里处理这个问题最标准的是 Step 5 Preview它在摄像机和角色之间做射线检测如果射线碰到障碍物就把摄像机沿向量拉近到碰撞发生点之前避免视角穿墙。这是正经第三人称游戏的标准做法能一次性写对说明它对游戏开发体系是有系统认知的。DeepSeek 在这块的表现让人哭笑不得。它给摄像机加了一套完整的平滑阻尼系统代码逻辑非常优雅Sprite 跟随算法有了阻尼系数也有了但初始的阻尼值设得过大导致摄像机像拖着个橡皮筋一样在角色后面甩来甩去角色停下后摄像机还要晃好几秒才稳定。反馈问题后它调整了阻尼系数到合理范围但因为这个调整是在它的调试面板里改的参数而不是在代码里写的导致我把代码存下来重新打开时参数又回到了初始值——模型完全没有意识到配置和代码之间的持久化关系。GLM5.3 的摄像机是最简单的固定偏移式跟随没有阻尼没有碰撞检测。角色往左转镜头跟着平移角色靠近墙镜头直接穿模。在开阔场景玩没什么问题但一进入狭窄通道就非常出戏。它这个方案倒也好修但修改过程让我意识到一个问题GLM 在很多细节上选择“够用就行”的路径导致它在简单场景下变现很好但扩展性受限。3.4 渲染性能光影开满和低配优化是两个极端性能方面的测试我把浏览器降级到了普通笔记本也能跑的集成显卡环境这样才能看出渲染开销的影响。Step 5 的代码对移动端有自觉的优化意识它把阴影贴图的分辨率调低了抗锯齿用了 FXAA 而不是 MSAA场景里的几何体做了合并处理Draw Call 数量压缩得比较低。实测帧率稳定在 60 左右很流畅。DeepSeek 是最大的性能吞金兽。首轮代码默认开启屏幕空间环境光遮蔽SSAO和软阴影这两个效果在 3A 大作里都是吃资源的选项放进一个只有几个简单几何体的网页游戏里帧率能被压到 30 属实离谱。而且它没有做任何移动端降级方案手机浏览器打开大概率直接卡成幻灯片。我需要手动注释掉相关代码才算把帧率拉回来。GLM5.3 的做法最“聪明”它压根没有开任何高级渲染功能。阴影用的是最基本的平面投射阴影光源数量只有一个材质全部是 MeshLambertMaterial 这种廉价材质整个渲染开销低到可以忽略。后期如果想要更好的光影效果需要自己往里加但也正因为它的基础够干净往上加东西反而很顺手。4. 代码质量与二次修改真实项目里最关键的能力4.1 代码可读性、命名规范与模块化程度如果只是把游戏做出来能跑那三个模型都合格但放到真实项目里代码可维护性才是决定能不能用的问题。Step 5 Preview 的代码风格最接近职业工程师的产出命名规范统一函数拆得细每个函数的职责不超过一个屏幕能看全的范围。它还用了一个小技巧把游戏状态机写成一个独立的类所有交互通过事件驱动这让后续加功能变得非常容易。DeepSeek 的代码工程能力其实也不差但被它的“功能堆砌”习惯拖累了。它的文件里充斥着大量暂时用不到的辅助函数和未激活的特性开关阅读时必须不停跳过去确认哪些是有效代码、哪些是预留代码。这种习惯在大型项目里非常致命因为任何人接手都会陷入“这段代码到底跑不跑”的疑惑。GLM5.3 的单文件风格在初期体验有优势但后续修改时问题就暴露了。它的事件绑定分散在文件各处的回调函数里修改一个按钮的交互逻辑需要在三个位置同步改动很容易漏改。不过它的注释质量非常高每个函数都有清晰的使用说明读起来像是一份带注解的需求文档这对联调阶段的帮助很大。4.2 追加改需求的实测给三个模型加“倒计时”功能为了测试增量修改能力我给三个模型追加了同一个需求在现有游戏里增加倒计时功能5 分钟内未收集满 10 颗宝石则触发失败界面。这个需求涉及 UI 层、逻辑层、状态监听三个层面的改动非常适合检验模型对既有代码的理解能力。Step 5 返回的修改方案非常干净在状态机里新增一个 timer 管理器UI 层通过事件监听刷新数字游戏结束时调用统一的结算逻辑。它只新增了不到 80 行代码并且没有动到任何原有功能。改完后我连续玩了三局发现计时器重置逻辑很严谨重新开始游戏时会正确地清掉上一局的定时器不会出现叠加计时的问题。DeepSeek 的修改过程就比较有意思了。它因为代码里已经有调试面板和状态管理器的底子理论上加个倒计时很容易但问题就出在它的状态管理器太复杂了倒计时更新触发了它预设的自动保存逻辑导致页面每隔几秒就弹出一个调试日志浮窗干扰正常游戏。我反馈后它花了一轮才找到日志浮窗的触发源头。实际看到的效果是功能完成了但过程伴随着一些噪音。GLM5.3 让我最意外。它在单文件结构下修改起来反而很快直接把倒计时逻辑写进了游戏主循环同时用闭包管理定时器。它的代码量虽然多了但改完后行为非常正确失败界面是嵌入游戏画布里的不像首轮那样用浏览器弹窗。这说明它在理解“游戏内 UI 到底是什么”这件事上确实有进步。4.3 部署与移动端适配从 Web 到安卓壳这里要插一个开发中绕不开的话题很多人做网页 3D 游戏不满足于只在浏览器里玩还想打包成移动端应用。我在测试时也顺便观察了几个模型对部署方案的敏感度。三家的代码都是纯前端实现理论上都能通过 Capacitor 或 Cordova 这类工具套壳打包安卓应用但实际操作差别很大。Step 5 的代码因为模块划分清晰打包时只需要把静态文件放进 WebView 就能跑几乎没有适配成本。DeepSeek 的代码里有一处对 window.innerWidth 的即时调用没有做 resize 监听在安卓 WebView 中屏幕旋转时会拿错宽高游戏画面会错位。GLM5.3 的单文件结构在打包时最粗暴直接把所有内容粘进一个 HTML实践证明反而最不容易出问题。所以如果你打算做开源安卓 3D 游戏这类项目我个人的建议是首轮生成时让模型输出“单文件模式”后面再来考虑拆模块这样可以避免很多移动端适配的坑。顺带说一个部署相关的细节。社区里有人讨论 GLM5.3 本地私有化部署时用哪个版本的 vLLM 镜像我自己的实测经验是这类模型的部署兼容性高度依赖推理框架版本没必要追新追快用官方文档推荐的稳定版本镜像最省心。如果出现 attention 后端报错或者显存分配异常不要急着换模型先检查一下 vllm 和 CUDA 的版本组合很多问题其实是框架版本和算子库不匹配导致的。这条经验同样适用于其他开源模型的本地部署踩过坑的人应该懂我说的是什么意思。考虑到当前实时移动端的 Web 渲染性能路径已经比较成熟如果你是把项目推到真实安卓设备上优先保证 WebView 启用硬件加速开关同时避免在高密度屏幕上开超采样抗锯齿这个优化能省下一大半 GPU 开销。我在测试三个模型时都手动确认了这两个硬件开关排除了环境因素对性能结论的干扰。5. 常见问题速查与避坑手册5.1 首轮代码常见的 5 个典型故障第一类故障是“渲染黑屏”。三个模型里有两个都遇到过区别在于原因不同。Step 5 第一次黑屏是因为纹理贴图的加载路径用了相对路径本地文件协议下浏览器拦截了资源请求DeepSeek 的则是 shader 变量冲突。排查思路很简单看到黑屏先打开控制台看有没有红色报错有报错就按错误定位没有报错就挨个检查场景、相机、渲染器的初始化顺序以及循环渲染函数有没有被调用。第二类故障是“角色穿模”。前面说过通常是碰撞检测的碰撞体尺寸小于模型可视尺寸或者是物体旋转后包围盒没更新。快速修复方式是把碰撞体放大到模型视觉尺寸的 80% 到 90%宁大勿小。第三类故障是“帧率暴跌”。优先怀疑阴影贴图分辨率和抗锯齿级别是不是开太高其次检查是否有不必要的材质变化导致 shader 重新编译。把渲染器参数往下调一档大概率能解决。第四类故障是“点击没反应”。这类问题最隐蔽因为控制台没有报错界面也正常但交互事件不触发。我排查后发现三个模型里有两个把点击事件的监听器绑定到了 renderer.domElement 上而实际需要监听的应该是 canvas 容器两者在坐标换算时差了偏移量导致点击判定区域不准。直接把监听器绑定到 document 上可以规避这个问题。第五类故障是“重新加载后状态错乱”。这个问题在 GLM5.3 和 DeepSeek 身上都出现过原因是它们把游戏状态变量初始化放在了模块顶层页面重新加载时会复用旧的状态值。可靠做法是把整个游戏初始化包装成一个 reset() 函数所有状态变量在函数内部声明刷新时一切重来。5.2 给 AI 下达 3D 任务时建议遵循的 3 条原则基于这次测试我总结了三条给 AI 下达 3D 任务时需要特别注意的原则。第一条把需求分层表述。不要只给一句“做个 3D 游戏”或者“生成个场景”而是拆成场景结构、玩家控制、物体交互、界面逻辑四个层面每个层面用两到三句话说明这样模型生成的结构不会失衡。我在测试中对三个模型都用了这套分层描述效果明显好于直接给笼统需求。第二条明确技术边界。如果你不希望模型引入额外的库或者不希望它默认开启某些高级渲染特性一定要在初始指令里写清楚。DeepSeek 私自引入 SSAO 和后期处理库就是吃了没给技术边界的亏。但要注意技术边界也不用卡得太死最好不要指定具体的 Three.js 版本除非你有特殊兼容性需求因为模型对旧版本的 API 记忆可能已经和最新版脱节反而容易生成过时代码。第三条准备好“诊断式反馈”而非“你认为式反馈”。当模型给出的代码报错时直接把控制台的错误信息原样复制给模型同时附上出错的文件和行号而不是说“好像有点问题”。在测试里最明显的一个例子是 DeepSeek 在 BVH 碰撞问题上的反复挣扎直到我在反馈里附上了“碰撞检测函数返回的碰撞距离一直是 NaN”这段错误现象它才意识到问题出在数据更新顺序上。你给出的诊断信息越精确模型修复得越快。注意向 AI 要代码和向 AI 要解决方案是两回事。如果你只给它说“帮我改一改让它不乱穿”它多半只能基于猜测去调整参数运气好碰对了就修好了运气不好就陷入瞎试循环。把“现象 报错 复现路径”描述清楚是对双方都负责的协作方式。5.3 一个被低估的辅助技巧让模型先输出“技术选型说明”我在测试里留了一个隐藏考察点首轮输出之前我要求三个模型先用 5 句话说明它计划用什么技术栈、每个模块怎么分工、运行时会遇到什么风险。结果非常有意思Step 5 给出的选型说明和最终代码高度一致说明它的代码生成是“先想后做”的GLM5.3 的说明简练但精准每个判断都对DeepSeek 的说明最详细但它说“将使用后期处理提升视觉体验”这句话后来被证明就是它性能拖垮的根源。这个技巧真正好用的地方在于它逼着模型在动手前把设计意图说清楚你可以提前拦截掉不合理的方案而不是等代码写完再返工。我自己在实际项目中已经把这一条固化成了流程任何 AI 帮我生成超过 200 行代码之前我都会先让它输出一份简短的实现方案审一遍再放行。这个流程成本极低收益却非常大。6. 这次实测给我的最终体会三个模型跑完这个 3D 游戏任务我的直观感受是它们像三种不同性格的协作者。Step 5 Preview 是最接近“经验丰富的前端工程师”的那一个它结构意识强能主动补齐摄像机遮挡检测这类隐性需求而且修复 bug 的效率很高适合用来搭建有后续迭代计划的项目骨架。DeepSeek V4 Pro 像那种想法很多、动手很猛的同事它会在你只想要一个三明治的时候给你上一桌满汉全席里面有好多你暂时用不上的菜但其中确实藏着几个有用的思路需要有人帮它做减法。GLM5.3 则像沟通成本极低的老实人它不会给你惊喜但给你的东西质量稳定、很少跑偏特别适合用在边界明确、需求清晰的生产环节。就单次任务综合得分看Step 5 Preview 是这次实测的优胜者但我并不建议所有人无脑选它。如果你的使用场景是快速验证一个想法或者临时解决一个问题那 GLM5.3 的单文件输出和低出错率反而更合适。如果你在做创意原型希望 AI 给你带来超出预期的功能参考DeepSeek 的过度设计也许能给你一些启发。关键在于你要清楚自己需要什么然后把预期值设置对。我还想多说一句关于提示词工程之外的东西。这次测试让我重新审视了“AI 编程到底是在考验谁”这个问题。表面上是在考验模型的代码能力实际上也在考验使用者的需求拆解能力和诊断能力。同一份需求拆得越清晰模型的表现就越好同一个报错给出的信息越准确修复就越快。换句话说一个会用 AI 的工程师价值不在于能输写多少 prompt而在于能准确描述问题、判断方案的合理性、并在模型给出错误路径时及时拉回来。这个能力短期看是效率工具长期看是职业护城河。最后再分享一个从这次测试里总结的小经验如果你想让 AI 生成的项目保持长期可维护性那就在每个模块的文件头部让模型加一段注释说明这个文件的职责、被谁引用、修改影响的连锁范围。这一步在纯人写代码时很难持续执行但 AI 做起来毫不费力。我在这三个功能的迭代过程中发现加上这些注释之后不管是我自己还是模型后续做增量修改定位问题的速度都提升了一大截。养成这个习惯你会回来感谢我的。
