1. 为什么拿 3D 游戏当“模型照妖镜”测试基准与统一 prompt 设计最近几款新模型几乎前后脚放出来Step 5 Preview、DeepSeek V4 Pro、GLM5.3 都打出了“代码能力强”的旗号。评测榜上的分数是死的但实际写项目什么手感没人替你去试。我决定不跑标准 benchmark直接让它们仨做同一个东西——一个能玩、能跑、能拿出手的 3D 网页游戏。这个测试思路贯穿了我整个实测过程先说清楚我为什么这么选以及怎么设计才能让对比尽量公平。1.1 3D 游戏为什么最能暴露模型短板很多人测代码模型喜欢让 AI 写算法题或者 JSON 接口说实话那东西糊弄空间很大。题解背得熟、模板套得牢就能拿高分但真实工程不是背题。3D 游戏是极少数能把“编码综合能力”一次性全考光的场景原因非常具体。首先是三维数学。摄像机跟随、角色移动、碰撞检测、旋转插值任何一个环节出错画面表现立刻就是歪的或者穿模的装不了。其次是异步逻辑游戏循环里要处理按键状态、动画帧更新、对象销毁这考验模型对事件驱动代码的组织能力。第三是资源管理加载模型贴图、处理纹理格式、管理监听器防泄漏不做干净就会越跑越卡。最后是容错——浏览器控制台不会给面子一行Cannot read properties of undefined就能让整个页面白屏。算法题只考一个点3D 游戏考的是整个面。而且它能直接看到效果模型写得好不好跑起来三秒钟就有直觉判断。这个测试维度是论文指标绝对给不了的。1.2 统一的测试用例我让三个模型做的到底是什么游戏为了对比公平我给三个模型发了完全一致的 prompt一个字都没改。需求定义如下使用 Three.js 和原生 JavaScript实现一个浏览器端 3D 收集游戏。地面为 20x20 的网格平面玩家控制一个小球在平面上移动WASD 控制方向鼠标拖拽旋转摄像机。场景中随机生成 10 个金币金色旋转立方体小球碰到金币后金币消失、计分加一、播放简单反馈。游戏界面显示当前得分和总金币数左上角显示操作提示。要求代码在一个 HTML 文件中完整实现可复制直接运行不依赖本地资源所有素材用 Three.js 内置几何体。选这个需求我有几个刻意的考虑。限定单文件是为了避免模型生成一堆分散的模块最后串不起来这最能考验整体编排能力。不用外部贴图是为了防止网络加载问题掩盖真实水平。小球收集金币这个玩法看起来简单但它覆盖了输入处理、碰撞检测、坐标变换、HUD 更新、对象生命周期管理这些最核心的游戏开发环节麻雀虽小五脏俱全。1.3 测试环境的硬性约束跑不起来等于零分我对评判标准做了非常严格的硬性规定模拟真实工程交付不讲人情代码复制到本地 HTML 文件双击用 Chrome 打开不允许任何修改能跑才算过第一关第一关过了之后再看功能完成度移动是否流畅、碰撞是否有误差、计数是否准确、摄像机跟随是否自然最后看代码质量命名、结构、注释、内存管理意识之所以把“零修改能跑”放在第一位是因为生成代码最常见的毛病就是“看起来对但跑不起来”。有些人喜欢晒那些修修补补之后的成品但真实开发没人有时间给你当保姆。我觉得这个标准同样适用于读者自己评估模型——你拿到手能不能直接用才是真正的生产力。三个模型同一份 prompt同一套评分标准接下来就是逐个拉出来遛遛的时候了。2. Step 5 Preview 实测从惊艳到翻车的完整记录Step 5 Preview 是我第一个测试的对象毕竟这次实测标题里它排在前面。坦白说第一轮生成结果给我的初始印象相当好速度快生成内容完整但这趟实测远不是一路顺风的中途翻了两个实打实的车细节很有参考价值。2.1 从零生成首版输出速度与代码结构的初印象我的测试方式是让 Step 5 Preview 在对话框里直接生成完整 HTML。它思考了约二十秒输出的代码量比预期多一点大约六百行。这里有个细节值得留意它把 Three.js 从 CDN 引入用到了three0.160.0版本铺了一个相当标准的场景初始化——渲染器、透视摄像机、轨道控制器、环境光加方向光一个没少。命名风格统一用的是camelCase函数拆得也比较干净比如createCoin、handlePlayerMovement、checkCollisions是分开定义的没有把所有逻辑塞进一个大函数里。我复制代码、保存为step5_test.html、双击打开页面里出现了一个浅灰色网格地面中间立着一个蓝紫色的小球右上角显示“金币 0 / 10”。第一关过了零修改能跑这已经比相当一部分宣称“精通代码”的模型要强了。当时我以为这可能是我见过的模型生成 3D 游戏里最顺利的一次但接下来移动测试马上让我冷静下来。2.2 核心玩法测试移动、碰撞与计分的真实表现用 WASD 控制小球前后左右移动手感比我想象中好很多。它用keydown和keyup维护了一个keys状态对象在动画循环里根据按下的键去更新小球位置加速度带了简单的线性递增松开按键后速度不是瞬间归零而是慢慢衰减这算是一个成熟的细节小球动起来有惯性而非机器人式的跳变。碰撞检测用的是经典的“距离判断”——遍历所有金币计算小球与金币中心的水平距离小于阈值就判定为收集成功。这一步它写得中规中矩但有个处理让我比较意外收集之后不是直接scene.remove(coin)而是先把金币从数组里过滤掉再设置visible false隐藏最后把它从全局数组里剔除。这种“先隐藏后移除”的做法在复杂场景里能避免动画循环中引用空对象导致报错说明它对异步生命周期有基本意识。计分部分用了一个 DOM 元素实时刷新每次收集成功分数加一并且把collectedCount累加。十个金币全部收集完会弹出操作提示“恭喜完成全部收集”。到这里功能层面它拿到了一个相当不错的分数。连续玩了三局没有出现计数错乱或者金币消失但分数不加的情况。2.3 一个让人意外的渲染级 Bug方向光的硬伤正当我准备给 Step 5 Preview 打出高分的时候我注意到一个视觉上无法忽略的问题——整个场景的光影非常不自然。地面面向摄像机的那一面永远亮堂堂的但小球朝向光照方向的那一面却是暗的怎么看怎么别扭。我打开控制台逐条检查光源参数发现问题出在方向光的target设置上。Step 5 Preview 创建了一个DirectionalLight光源位置设在(10, 20, 10)本应指向场景中心但它没有为光源显式设置target.position。Three.js 里方向光的默认target是(0, 0, 0)方向光会从position指向target。看起来没问题但实际上它把target.addToScene的关联做错了——它把光源的target对象又单独加进了场景导致 Three.js 内部在更新光源矩阵时出现坐标错位光照方向整体偏掉。修复方法就一行代码light.target.position.set(0, 0, 0)并确保light.target已通过scene.add(light.target)加入场景但因为它重复 add出现了内部状态冲突。这个 bug 不算致命功能完全能玩但视觉效果打了折扣。我记录下这个问题心里对 Step 5 Preview 的评分从“优秀”降到了“良好”。模型能跑通功能流已经不容易可光影这类渲染细节是最体现“是否真正理解 Three.js 内部机制”的地方这一步它栽了跟头。3. DeepSeek V4 Pro 实测代码架构与调试体验测完 Step 5 Preview我紧接着把同样的 prompt 扔给了 DeepSeek V4 Pro。如果说 Step 5 Preview 是一个跑起来没问题但细节欠打磨的选手那 DeepSeek V4 Pro 的表现就像另一个完全不同风格的工程师——它写代码的方式更“资深”但代价是交互体验上留下了一些让我皱眉的决定。3.1 首先注意到的差异代码组织方式的代际差距DeepSeek V4 Pro 输出的代码结构让我第一眼就感觉到了不同。它没有把全部逻辑平铺在全局作用域里而是用一个Game类把所有东西装了起来。constructor里初始化场景、摄像机、渲染器、光源和玩家对象然后按生命周期拆成init、animate、updatePlayer、updateCoins几个方法。这种组织方式意味着它默认你有一定的代码阅读能力不是把答案喂到你嘴边而是像一个项目负责人一样把筋骨搭好。初始化部分它用了一个比较新的 Three.js 写法renderer.outputColorSpace THREE.SRGBColorSpace这个 API 在较新版本中替代了旧的outputEncoding设置。说明它的训练数据里有足够新的 Three.js 文档。整体代码量比 Step 5 Preview 少了约三成但可读性强了不少——注释不多可函数名本身就是文档读起来不需要猜。第一关零修改能跑这是通过的。页面打开后我看到的是一个偏暗色系的场景地面用了深灰色小球是亮橙色的视觉对比很舒服。它没有像前一个模型那样放太多说明文字HUD 只有左下角一个小巧的计分显示右下角有一行半透明的小字提示操作方式。这种审美取向上的克制让我对它的好感度又加了一点。3.2 物理手感的处理平滑移动与阻尼系数的调教实际把小球跑起来之后我意识到 DeepSeek V4 Pro 在“手感”这件事上明显下了更多功夫。它给小球加了一个速度阻尼系统每次更新位置之后速度向量乘以一个0.92的阻尼系数让松手之后小球会继续滑行一小段距离但逐渐减速停下来。这个参数选得很讲究太大则小球像溜冰鞋抹了油根本停不住太小则顿挫感明显。更让我意外的是它实现了基于平面法线的斜坡重力分量计算。虽然这是一个完全平的地面没有坡但它的代码里预留了通过raycaster获取地面法线、根据法线与小球速度向量的夹角计算投影速度的逻辑。简而言之它的移动代码在架构上支持斜坡地形换一个带起伏的地图直接能用。这种前瞻性设计从一个生成模型嘴里吐出来确实有点东西。碰撞检测也做得比前一个模型更聪明。Step 5 Preview 是简单的二维距离判断DeepSeek V4 Pro 则用了真实的三维包围球碰撞检测把金币和小球的半径都纳入计算碰撞容差更精确。实测感受非常明显小球“擦着边”经过金币时不会像前一个模型那样提前触发收集而是视觉真正接触了才消失。这个差别可以量化描述边界误差大概差了约二成玩起来精度高不少。3.3 调试中的发现摄像机跟随逻辑的过度设计不过DeepSeek V4 Pro 有一个让我觉得很矛盾的地方摄像机跟随逻辑明显过度设计了效果反而变差。它实现了一个带阻尼插值的第三人称跟随——摄像机不是硬邦邦地锁定在小球后方而是每一帧朝目标位置做lerp插值再有延迟地平滑跟随。听起来很高级可实际玩起来问题立刻暴露因为小球移动很快而摄像机插值系数被设成了0.08导致摄像机的响应速度跟不上小球转身的速度。小球向右转 90 度之后摄像机还在缓缓往右摆动产生了一种非常不舒服的“镜头甩尾感”。玩了不到三十秒我就感到有点晕。这是个典型的“参数意识”问题——思路是对的但参数没有经过实际体验调优。我尝试手动把 lerp 系数从0.08调到0.15画面立刻稳了很多。这引出一个值得注意的结论DeepSeek V4 Pro 在架构设计上的能力明显强于 Step 5 Preview但它对“玩家实际体验”的敏感度差一些它更关心“机制是否正确”而不是“感受是否良好”。4. GLM5.3 实测生成思路、vLLM 镜像选择与本地部署第三个上场的是 GLM5.3。测完前两个我本来对这个顺序有点审美疲劳但 GLM5.3 的实测过程却是三个模型中最波折的因为它不只是生成代码让我跑我还在本地把它部署起来做了一次完整推理服务测试。这里面的 vLLM 镜像选择问题我翻了半天文档才搞定值得单独写一段分享。4.1 GLM5.3 生成代码的做题思路从内到外的完整实现GLM5.3 的生成速度介于前两个之间输出代码量也是三个中最多的约七百行。它的实现思路与 DeepSeek V4 Pro 不同没有用类封装而是把整个游戏拆成了八个职责清晰的函数setupScene、createGround、createPlayer、spawnCoins、handleInput、updateGame、renderHUD、initGame。每个函数都有一段比较完整的 JSDoc 注释解释了参数和返回值含义。这个模型在“完整性”上的强迫症很有意思。它花了额外的代码去处理页面resize事件窗口尺寸变化时重置渲染器大小和摄像机宽高比。前两个模型都忽略了这个细节虽然手动把窗口拉大拉小会变形但多数人不会第一时间察觉。GLM5.3 是唯一注意到这个问题的。此外它还处理了visibilitychange事件页面从后台切换回前台时重置时钟增量防止小球在后台挂机期间卡出地图边界。零修改跑通第一关表现稳定毫无悬念过了。场景配色用了暖黄加墨绿视觉氛围三个里最舒服。我特别注意了下碰撞检测它用的是比较稳妥的“先遍历、再过滤、后移除”三段式逻辑结果显示一切正常连续收集十个金币后计数器停在 10没有溢出。4.2 与 doubao-seed-2.0-code 的联动场景一个意外的分工机会我原本没打算把其他模型引入这次实测但 GLM5.3 的一次报错让我改变了主意。它在生成的代码里使用了一个较新的 Three.js 实例方法renderer.setAnimationLoop要求 Three.js 版本在 0.100 以上没问题但它引入的 CDN 地址却是three0.91.0的版本老版本里根本没有这个 API控制台直接报setAnimationLoop is not a function。我起初想手动修后来转念一想不如试试搜热词里提到的 doubao-seed-2.0-code——它和 GLM5.3 都是当下热门代码模型。我把 GLM5.3 生成的完整代码粘贴给 doubao-seed-2.0-code让它修复这个版本兼容问题。它的处理干净利落把 CDN 地址改为0.160.0顺手把THREE.OrbitControls的引入方式换成了新版本的标准写法还额外加了一句controls.enableDamping true来避免旧版本控制器的抖动问题。这个联动对我来说是一个启发。不同模型各有所长GLM5.3 的工程思维强doubao-seed-2.0-code 对新版本 API 的熟悉程度高把它们组合起来用能省掉不少排查版本兼容问题的时间。如果只在单一模型里死磕你得自己去翻 Three.js 的变更日志那真的没有必要。4.3 GLM5.3 使用 vLLM 部署镜像版本选择的完整记录因为注意到热搜词里频繁出现“glm5.3 使用 vllm 哪个版本的镜像”这个问题我在本地 GPU 服务器上复现了一遍部署过程。先说结论GLM5.3 对 vLLM 的版本有硬性要求用错镜像会直接启动失败。我最初用的是vllm/vllm-openai:latest官方最新稳定版拉下来启动时立刻报错提示KeyError: glm5。进容器看日志发现是 vLLM 的模型注册表里没有 glm5.3 对应的模型架构。GLM5.3 的模型结构相对较新官方把新架构的兼容 patch 合入 vLLM 主分支之前旧镜像底层的注册表不可能认识它。换镜像到vllm/vllm-openai:nightly启动成功。实测跑通了一个推理请求延迟和吞吐表现都在正常水平。最终的启动命令大概这样docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:nightly \ --model /models/glm5-3b \ --served-model-name glm5.3 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9这里有个细节served-model-name最好显式指定别名否则客户端那边调 OpenAI 兼容接口时容易因为模型名不一致报 404。另外热词里还提到了开源安卓 3D 游戏其实用这种方式部署 GLM5.3 之后安卓端就不用调云端 API 了本地局域网内通过 vLLM 的 OpenAI 兼容服务直接生成代码——对普通玩家来说这就是一个“私有代码助手”的实践。4.4 本地部署推理服务的稳定性观察部署完成之后我没有立刻关掉服务而是让它持续跑了一天。期间用同一个 prompt 做了多次推理观察输出稳定性。GLM5.3 在重复输入相同指令时输出内容并不完全一致——这在生成式模型里正常但代码模型用户通常希望“同样需求得到稳定结果”。实测前三次生成的代码结构差异不大核心逻辑一致第四次换了一种地面纹理实现方式说明模型内部有一定随机性。如果你想让 GLM5.3 的代码生成行为更稳定有两个方法实测有效。第一是调低temperature官方推荐的代码场景默认值通常是0.2到0.4之间我最终用0.1跑出来的三轮结果几乎完全一致但过于低的温度会让输出变得机械少了一些创意性写法。第二是固定seedvLLM 提供--seed参数固定后同样的输入基本走同一条采样路径。这两个参数配合起来才能把模型从“灵感型选手”调成“稳定输出型选手”。5. 同题三轮对比功能完成度、代码质量、交互体验与性能表现三个模型全部测完之后我把三份代码放在同一个浏览器里逐项对比。没有对比就没有伤害很多单项表现单独看都觉得不错放在一起排开差距就非常具体了。我从四个维度做了记录每一个都有可量化的观察依据不是泛泛的“感觉”。5.1 核心功能完成度谁能一次通关功能完成度的对比最直接我把三个模型的第一版输出做了一个表格按我事先定好的标准逐项打勾功能项Step 5 PreviewDeepSeek V4 ProGLM5.3零修改直接运行通过通过通过WASD 移动控制正常正常正常鼠标拖拽旋转摄像机正常正常正常金币碰撞收集正常正常正常得分实时更新正常正常正常全部收集完成提示正常正常正常页面自适应缩放未处理未处理已处理后台切回防位移跳变未处理未处理已处理光照方向正确性有 Bug方向光 target 冲突正常正常单从功能上说三个模型都做到了基础可玩但 GLM5.3 在细节功能的完整性上明显高一个段位它主动处理了前两个模型忽略的边缘场景。这一步我给出的结论是如果只是“能跑能玩”三者没有本质区别如果要“各种环境下都不出幺蛾子”GLM5.3 领先。5.2 代码质量与工程思维不同风格的上限与下限代码质量这个维度看的是架构能力和可维护性。DeepSeek V4 Pro 的类封装结构是三个中最好的它把游戏逻辑完全收拢在一个Game实例里没有污染全局作用域。Step 5 Preview 和 GLM5.3 都是函数式组织但 GLM5.3 的职责切分更均匀每个函数都控制在五十行以内比 Step 5 Preview 那种大函数套小函数的写法清爽得多。命名上各有各的风格。Step 5 Preview 的变量名偏语义化但有点啰嗦比如playerMovementSpeedFrame这种超长变量名出现多次DeepSeek V4 Pro 的命名简短但准确属于“懂的人自然懂”的类型GLM5.3 的命名在三者中最标准化基本符合常见 JavaScript 风格指南的推荐。代码量上没有意义关键是每行代码是否对最终体验产生价值。DeepSeek V4 Pro 用最短的代码达到了和另外两者持平的功能完成度在工程效率上胜出但它的摄像机插值参数问题是三个中最需要实际调优的。工程思维不能只看结构漂亮参数调不好照样是返工。5.3 交互体验与人机手感玩起来才是硬道理交互体验的差异用一个词语概括就是“手感”。我从一个玩家的主观感受出发做了记录Step 5 Preview 的移动手感偏“飘”因为它没有阻尼系统球体移动速度恒定松手瞬间停住虽然定位精准但没有实感。DeepSeek V4 Pro 是三者中最接近真实物理引擎表现的那一个滑动、减速、碰撞都很有存在感但摄像机甩尾问题让它输在了晕眩感上。GLM5.3 的手感介于两者之间它给了小球适度的惯性摄像机跟随也加了一个很小的阻尼刚好能让画面柔和又不会甩尾。个人体验排序是 GLM5.3 最舒服DeepSeek V4 Pro 次之Step 5 Preview 最“轻”。GLM5.3 那种恰好到位的阻尼系数让我意识到AI 生成代码的“参数直觉”其实是训练数据里大量真实项目经验的统计平均哪个模型的训练数据里优秀游戏源码占比更高它给出的手感数值就越合理。5.4 性能与资源占用长跑之后的稳定性差距我用 Chrome 开发者工具的性能面板做了三轮连续五分钟的性能采样观察平均帧率和内存占用趋势。三者都维持在 60 帧左右的满帧率差距在内存占用趋势上开始显现。Step 5 Preview 的内存曲线在五分钟内缓慢爬升主要是它收集金币后执行了scene.remove却没有调用geometry.dispose()和material.dispose()GPU 资源没有得到及时释放。DeepSeek V4 Pro 的内存曲线最平稳它所有几何体都在初始化时创建一次、游戏结束前统一回收。GLM5.3 的内存占用略高于 DeepSeek V4 Pro但没有任何泄漏迹象每一轮金币收集之后它都主动调用了一次资源清理。短时间玩看不出差距连续挂着跑半小时Step 5 Preview 的内存增长会明显影响页面流畅度。从资源管理的意识来看这一步 DeepSeek V4 Pro 做得最干净。6. 把三份代码缝合起来的惨痛教训以及安卓端移植试水测完对比之后我做了一件额外的事——尝试把三个模型各自最擅长的部分拼成一个“最强版本”。这个缝合理念本身没问题实际操作过程给我上了一课。与此同时我还围绕热词里的“开源安卓 3D 游戏”做了初步移植试水过程和结果都很值得记录。6.1 缝合实验为什么 111 最后小于 1我的缝合计划是这样的保留 DeepSeek V4 Pro 的整体类架构替换 Step 5 Preview 的移动手感逻辑再加上 GLM5.3 的资源清理和 resize 处理。看起来是取三家之长实际操作时问题接踵而至。首先是命名冲突。DeepSeek V4 Pro 里负责位置更新的私有方法叫_updatePositionStep 5 Preview 里同名函数返回的是归一化方向向量两个模型的函数名一样但返回值类型和内部实现完全对不上。我在合并时没有逐一核对函数签名直接导致合并后第一帧就报错。然后是状态管理不一致。DeepSeek V4 Pro 用class的方式把状态锁在实例属性里Step 5 Preview 的移动逻辑依赖一堆全局变量。硬把它们缝在一起相当于同时维护两套状态源小球的位置和速度出现了两处写入放出去的代码像精神分裂一样左右横跳。这个实验最后以失败告终花了一个半小时最终成果比最差的那一份还不如。核心教训是不同模型生成代码的“生态体系”不同互相缝合的成本远超从头让一个模型重写。如果以后还有类似的跨模型协作需求我会把分工边界划在“独立模块”级别比如让 A 写游戏逻辑、B 写渲染管线、C 写 UI接口定义清楚之后再拼而不是在同一段紧耦合逻辑里强行混血。6.2 安卓端 3D 游戏的移植思路从 Web 到原生壳的可行性验证热词里反复出现“开源安卓 3D 游戏”我结合这次生成的三份代码做了个验证把浏览器端 Three.js 游戏跑进安卓 WebView是最快捷的迁移路径还是纯粹耍流氓实测下来这条路完全可行。我用 GLM5.3 生成的那一版代码包进一个安卓项目的assets目录用WebView加载本地 HTML 文件打开页面后 Three.js 可以正常工作。要注意的坑有三个第一必须开启硬件加速在AndroidManifest.xml的application标签里加android:hardwareAcceleratedtrue否则 3D 渲染的帧率会惨不忍睹第二WebView 的settings要调用setJavaScriptEnabled(true)和setDomStorageEnabled(true)前者不用解释后者是因为 Three.js 某些资源加载路径会用到 DOM 存储第三文件访问权限要配置setAllowFileAccess(true)和setAllowFileAccessFromFileURLs(true)否则本地 HTML 里的 CDN 资源无法加载。跑通之后我顺手测了性能表现中端安卓手机上能稳定在 55 到 60 帧左右角落里的一个 Chrome 并发任务会偶尔掉帧但整体可玩。如果要进一步优化把 Three.js 的 CDN 引用换成本地打包的 min 文件能减少首次加载延迟约半秒。6.3 三份代码之外的思考模型评测到底该看什么这次实测跑完之后关于“哪个模型最强”这个问题的答案其实比我预想中复杂。按单次生成结果的成功率来看Step 5 Preview 能跑但渲染细节有伤DeepSeek V4 Pro 工程结构最漂亮但上手体验需要调参GLM5.3 细节最完整但输出随机性稍大。我自己的评判维度排序是先看零修改能不能跑再看玩起来舒不舒服最后才看代码内部结构如何。按这个顺序对我来说 GLM5.3 是综合体验最好的一次测试DeepSeek V4 Pro 紧随其后。但如果你要做的是一个复杂的长线项目代码架构的重要性会提高那时候 DeepSeek V4 Pro 的类结构方案可能反而更有优势。模型评测从来不是“谁强谁弱”一句话能说清的关键是你拿它做什么。这次的 3D 游戏测试让我看到了三个模型各自的性格Step 5 Preview 像一个执行命令干脆的初级开发DeepSeek V4 Pro 像一个资深架构师但容易过度设计GLM5.3 像一个大包大揽的细节控。真要说谁最适合现在入坑我建议你跟我一样拿同一个需求自己跑一遍感受一下哪种风格跟你的工作方式最合拍。