1. 评测基准为什么把“3D网页游戏”当成三个模型的试金石先交代一下背景。我最近在琢磨一件事到底该怎么衡量一个大模型写代码的真实水平LeetCode题、CRUD接口、工具函数这些常规题模型的分数已经非常接近拉不开差距。真正能让模型露馅的是那种需要同时调度图形学知识、交互设计、资源管理和运行性能的综合性需求——“3D网页游戏”恰好就是这类需求的典型代表。我这里说的3D游戏不是让模型去写一个庞大的商业引擎而是用Three.js做一个能在浏览器里直接跑的3D小游戏比如第三人称跑酷、障碍躲避、金币收集。这类项目看起来很“小”但麻雀虽小五脏俱全场景搭建、光照阴影、碰撞检测、循环渲染、用户输入、得分机制、移动端适配哪一环缺了游戏都玩不顺。说白了你没法靠“背通答案”糊弄过去模型必须真正理解3D空间里一个运动对象应该怎么移动、怎么判定撞到障碍物、怎么在不同屏幕比例下保持可玩性。参与本次评测的三个对象一个是刚放出来的编程模型预览版下文统一叫它Step 5 Preview一个是DeepSeek V4 Pro一个是GLM5.3。我的测试方案很直接同一个题目、同一份提示词、同一台测试机分别让三个模型各自独立完成然后对比它们的初始生成结果、Bug修复能力、代码可维护性和最终的产品完整性。为了方便对照我把测试题目固定成这样一个需求使用Three.js从零实现一个第三人称3D跑酷游戏。角色沿一条直路自动奔跑玩家通过空格键跳跃按左右方向键切换三条跑道。路上随机生成障碍物和金币碰到障碍物游戏结束吃到金币加分。需要包含开始界面、游戏中的计分、游戏结束的重新开始功能最好能适配移动端触控并给出整体的渲染性能优化建议。为什么不用现成的模板项目因为模板项目本身已经是结果了测试不出模型的从零构建能力。我要求模型从index.html和main.js开始写第一版必须能直接双击打开就见到一个可交互的场景而不是一段“仅供参考”的伪代码。在正式开始之前我把这次评测的基础条件列在下面方便你自己复现时校准环境环境项配置测试机MacBook Pro M1 / 16GB 内存浏览器Chrome 最新稳定版Three.js 版本0.160.0CDN引入网络直连CDN不走代理生成轮次每模型最多3轮修正计时口径第一轮完整代码生成耗时顺便说一句我刻意没有让三个模型互相参考对方的输出整个评测过程是隔离的。这样才能比较公平地看到“同一个初始问题三个模型各自会走哪条路”。2. 同题开工三个模型第一版的方案差异三个模型拿到同一个提示词之后第一反应就能看出性格。GLM5.3上来就给了一套非常完整的技术方案说明先解释“我会用Three.js构建场景用BoxGeometry生成障碍物用CapsuleGeometry作为玩家角色”然后才开始写代码。DeepSeek V4 Pro则几乎不怎么解释直接怼了个四百多行的index.html单文件打开就是全量代码。Step 5 Preview是唯一一个把代码拆成了index.html、main.js、style.css三个文件的还主动给了npm install http-server这种本地预览命令。这个细节重要吗非常重要。因为单文件方案虽然方便“双击即用”但一旦项目复杂度上来代码全挤在一个文件里后面每修一个小问题上下文都会越来越长反而容易把模型自己绕晕。而模块化方案在一开始就更接近真实前端项目的组织方式后续改起来成本更低。当然站在“快速验证原型”的角度单文件方案也有它存在的意义所以不能一棒子打死。第一轮生成之后我先把三个版本的HTML直接拖进浏览器试跑。这里说句实话没有直接翻车的只有一家。另外两家多多少少都出现了点问题具体坑放在后面专门讲。先说整体方案上的差异。对比项Step 5 PreviewDeepSeek V4 ProGLM5.3文件组织分离为 index/main/style单 HTML 内联所有代码单 HTML 内联所有代码技术栈说明简述但完整几乎没有说明一段完整的技术思路场景美术偏简洁色块风偏丰富加了雾效和远山中等地面纹理清晰跑酷核心循环直接用状态机管理用布尔标志线写也用状态机但稍臃肿移动端适配同时支持键盘与触控仅键盘提示“移动端可后续扩展”同时支持触控与键盘这里得单独表扬一下GLM5.3的方案说明部分。它把“为什么用CapsuleGeometry而不是BoxGeometry做主角”“为什么障碍物用Mesh而不是直接用BoxGeometry加材质”讲得清清楚楚。虽然它在实际代码生成上不是最稳定的但这种先讲思路再落代码的习惯对开发者来说是真的有用。你拿到一段AI代码最怕的不是它有Bug而是你完全不知道它想干什么。反过来Step 5 Preview的第一版代码里有一个小亮点它用一个独立数组trackLanes来管理三条跑道而不是像另外两家那样用魔法数字-2、0、2硬编码位置。这意味着后续如果要改成五条跑道只需要改一个数组碰撞检测逻辑完全不用动。这种设计意识出现在AI生成代码里确实让我有点意外。DeepSeek V4 Pro的单文件方案里最省心的地方在于它把 Three.js 的引入、场景初始化、光照、地面、角色、动画循环全部一次写齐整个代码结构的完整度几乎是“教科书级”的。但问题是它在碰撞检测环节犯了一个很容易被忽略的错误——这个错误一直到第二版才暴露出来我放到下一节具体说。3. 使用VLLM镜像版本与部署环境的一些关联思考先岔开一句这次实测过程中我发现三款模型在“生成代码的运行环境假设”上差异极大这直接影响到它们在真实部署链路里的表现。这也是不少开发者最容易忽视的一个点。很多中文技术社区的朋友习惯用VLLM等方案来本地部署推理服务。网上最多的提问是“GLM5.3使用VLLM哪个版本的镜像”说实话这个问题背后反映的其实是模型权重对推理框架的隐性依赖。不同模型对VLLM、SGLang、TGI 的算子实现不一样即使同一个模型不同镜像是按照哪个commit构建的生成的数值对齐策略、采样参数默认值都可能带来绕来绕去的差异。比如你在某个老镜像上跑GLM5.3可能发现采样结果和官方API总是不一致换到新镜像之后一切又正常了。这和你平时正常行动路线的选择一样不是哪个框架才是“标准”而是你的目标环境匹配哪个版本。当然这件事和本次“3D网页游戏”的浏览器端生成评测没有直接的因果链路但如果你打算把这类生成能力包装成一个在线服务比如用户输入一句话就生成一个可玩3D小游戏那必然牵扯到模型服务的稳定性和输出一致性。而Step 5 Preview、DeepSeek V4 Pro、GLM5.3这三个模型在服务端推理时的硬件占用、batch策略、上下文窗口利用率都不一样。我的个人建议是在做服务级封装之前先在你的目标推理环境里把模型的generate接口输出做一遍回归测试而不是直接照搬官方API的参数。回到游戏生成本身。我第一轮的完整跑测结果大致是这样的排序Step 5 Preview 打开即可跑通核心循环GLM5.3 能显示场景但碰撞判定有明显BugDeepSeek V4 Pro 场景最漂亮但角色起跳手感有严重问题。有意思的是三家的翻车位置完全不同这也让我第二轮的“Bug修复能力”评测变得很有看点。4. 三个模型修Bug的能力谁能在被追问之后找到病根第二轮我开始定向提问了。不给模型完整错误日志只给现象描述让它自己定位问题。这一轮最见功底。先说Soft 5 Preview。它的第一版能跑起来但有一个非常大的体验问题角色在空中的时候依然可以按方向键切跑道导致玩家在跳跃中突然横移视觉上非常不自然而且极容易闪避失败。我给出的反馈是“空中切轨看起来很奇怪应该禁止”。让我比较满意的是它没有简单粗暴地加一个isJumping布尔值就完事而是询问式的确认“你希望空中保持当前轨道还是允许小幅度调整”之后就引入了一个laneTransition的状态机把切轨动画和跳跃动画分开管理。这个修复逻辑在底层是对的说明它对状态管理的理解不是表面的。再说GLM5.3。它的Bug在于地面碰撞检测写成了“只检测下表面是否接触到地面”——简单说角色从障碍物旁边擦过去判定没事但只要稍微碰到一点就会直接卡死在原地。我反馈“跑着跑着会突然卡住”它先怀疑是动画循环里帧率计算问题改了两次帧率相关代码没修好。直到我补充了“擦边不卡、正撞就卡”的信息它才意识到是Octree碰撞体的容差测距写得太低级第三轮才真正修对。这个现象说明GLM5.3的代码生成能力强于代码诊断能力它的排查过程是“先猜最热门的Bug类型再用反馈缩小范围”不是从代码路径倒推。最后是DeepSeek V4 Pro。它的起跳手感问题其实出在一个非常经典的位置delta时间戳处理。它把速度直接乘在位移上但没有做统一的帧率归一化。在高帧率屏幕比如MacBook Pro的120Hz ProMotion上角色跳跃高度是正常的但如果拿到一台60Hz的显示器上同样的代码会让角色跳得又矮又慢。我提了一句“换了一台屏幕之后手感不同”DeepSeek V4 Pro秒懂直接重写了整个运动循环把所有位移都统一成了“每秒前进X单位”还把金币的旋转速度也从“每帧旋转X度”改成了“每毫秒旋转Y度”。这一点我必须说DeepSeek V4 Pro的Bug定位能力和全局重构能力应该是最强的它对字段之间的因果关系把握得很准解释性也强。这一轮修完Bug之后我又做了一次更细致的代码评审挑出了几个三类模型都比较容易犯的共性问题。这块内容我会放到第五节聊。5. 逐行体检三个版本代码里最容易翻车的真实细节在第4节的基础之上我想把评测粒度再往下沉一层直接进入代码细节给大家看我实际跑测试时记录的几个典型案例。这些案例的价值在于它们并不仅仅是这一步里的Bug而是你在让任何大模型帮你写3D项目时都会反复遇到的共性问题很值得收藏对照。5.1 碰撞检测不只是“重叠就算撞”三个模型里面Step 5 Preview 和 DeepSeek V4 Pro 都用了AABB轴对齐包围盒去做碰撞检测思路是对的。但有一个细微差别Player角色是瘦高型的CapsuleGeometry障碍物是方盒子。如果直接用玩家的整体AABB去判定碰撞就会出现“明明看起来还没撞到但因为包围盒比较大游戏却已经判定GAME OVER”的现象——专业术语叫“碰撞体过严”玩家会觉得不公平。GLM5.3在修Bug之后把碰撞体改成了三个小包围盒的组合分别覆盖角色的下半身、中段、头部。更进一步的它的判定还加了容差只在角色前进方向上障碍物的下缘检测到交叠时才判断为碰撞落地。这就大大削减了“擦边误杀”的概率。当时看到这个修复我还专门回头翻了一遍Three.js的Box3.intersectsBox文档确认它的实现没有问题。相比之下DeepSeek V4 Pro的碰撞检测虽然也是AABB但它把玩家的碰撞盒尺寸直接设为角色几何体尺寸的0.5倍也就是只有“一半大小”相当于刻意缩小了判定范围。这样做的好处是手感宽容坏处是会出现视觉上明明撞上了却还能强行穿过去的情况。两个极端玩家体验都不会好。如果你的项目也依赖AI生成的碰撞逻辑我的建议是一定要把碰撞体的缩放因子单独提成一个常量方便反复调试。5.2 性能优化渲染循环里的隐形炸弹3D游戏里最容易被忽视的性能问题是渲染循环里每帧都做几何体创建。比如GLM5.3生成的金币旋转逻辑它为了让金币看起来更明显在每一帧里都调用了一次new THREE.Mesh()去生成一个发光效果的外圈这让FPS直接掉了将近20帧。这种问题在桌面端还勉强能看在手机端基本就是直接卡死。DeepSeek V4 Pro在第一版里倒是没有这个毛病但它的粒子特效收集金币时的闪亮效果用了THREE.Points并且每帧更新所有粒子的位置。这个逻辑在100个粒子范围内看不出问题但如果你把金币数量翻倍到500个会发现CPU占用线性上升。相比之下Step 5 Preview把金币做成了共享几何体和材质旋转时只更新mesh.rotation开销小得多。这一点上Step 5 Preview的表现更符合真实项目的性能实践能用变换矩阵解决的问题就不要重建几何体。5.3 生命周期管理事件监听的清理单页应用和游戏里事件监听器泄漏是一个经典到不能再经典的问题。三个模型里面只有Step 5 Preview在生成代码时主动写了window.removeEventListener并且在游戏结束重新开始时把旧的键盘监听和动画帧循环拆分开。这看起来是个小细节但对于“结束—重新开始”循环非常关键。如果在restartGame()方法里无脑再绑定一次keydown监听会导致每重开一次事件处理函数就多一倍。玩家按一次空格角色跳两次按两次跳四次——整个游戏直接崩掉。DeepSeek V4 Pro在这一轮的代码里没有主动清理键盘监听只是在画布上重建了渲染器。我自己手动加了一段移除监听的代码才好继续跑测试。所以如果你的生产环境里要用AI写游戏代码请务必审查“重新开始”逻辑里的资源清理这是一块AI的薄弱区。下表是我把三个模型第二轮修完Bug之后针对不同维度的评分总结。分值仅代表我个人在本次测试条件下的体验不代表模型在其他任务上的表现。维度Step 5 PreviewDeepSeek V4 ProGLM5.3首轮可运行性高中低代码结构质量高中中图形/场景表现中高中碰撞判定体验高中中Bug定位与修复中高中移动端适配高低中性能优化自觉性高中低6. 同场对比之外我对“把AI生成的3D游戏推到线上”的实际建议三个模型同台竞技的部分到这里基本有了结论但评测不是终点。我真正想聊的是拿到AI生成的3D小游戏代码之后你距离一个能上线的产品还差几步。这一步可能是很多人忽略的。先说一个最容易被低估的版本问题。Three.js迭代速度非常快我的测试统一锁定了0.160.0版本但AI模型的知识截止时间各自不同有的模型写出来的API是旧版的比如THREE.Geometry有的偏向新版比如THREE.BufferGeometry。如果你的项目直接用的是CDN最新版Three.js新旧API混用会导致运行时直接报错。所以当你选择让AI帮你生成Three.js项目时第一步应该是在提示词里明确标注“使用Three.js哪个版本”而不是直接说“用Three.js”。这个小动作能帮你省掉大量无意义的修Bug时间。第二个建议是只靠一次生成就指望得到完美游戏基本不可能。本次评测里三个模型的第一轮结果都只能算“原型”都不能直接谈“上线”。但是通过“跑起来——发现问题——描述现象——让模型修改”这样的循环迭代之后最终三个版本的可玩性都达到了能拿出手的程度。这个过程实际上非常接近真实开发者的工作流你不是请AI替你凭空造完一个产品而是请AI当你的结对程序员你负责判断产品走向它负责写具体实现。第三个建议关涉到代码托管和版本对比。不要嫌麻烦把每一轮AI生成的版本都用Git打一个tag。我在评测过程中随手建了一个仓库把Step 5 Preview、DeepSeek V4 Pro、GLM5.3三个版本放在三个分支里。当遇到“改了一轮之后反而更差”的情况时我能立刻切回上一个可用的版本进行比较。如果你不做版本管理AI反复横跳的时候你会非常难受。再补充一句关于3D性能的实测心得。我原本打算把三个版本的游戏都加上阴影映射和雾效做一个比较酷的渲染效果但在M1芯片上开了阴影之后帧率会有明显抖动。后来我把阴影范围调小、关闭了抗锯齿的MSAA换成了FXAA整体FrameTime终于稳定在16ms以下。如果你在手机上跑这类网页游戏建议把设备的Pixel Ratio手动设为Math.min(window.devicePixelRatio, 2)否则高密度屏幕会被渲染压力直接拖死。如果你打算把这几个AI生成的3D游戏原型继续往深了做可以参考我这个方向把状态机重构一下把跑道、障碍物、金币、玩家分别抽象成独立的类然后把碰撞检测从AABB升级成真正的胶囊体与盒体的分离轴测试最后再接入一个简单的背景音乐管理器。这样一步步演进最开始AI生成那个三百行的脚本最终会变成一个具备基本工程结构、可扩展的小型游戏项目。我在实际测试过程中还有一个体会值得分享让这三个模型各自独立运行之后再去人工把“它们的优点”合并成一个最终版本比依赖任何一个单一模型从头写到尾效果都要好得多。比如我最终跑的那一版游戏底层碰撞逻辑用的Step 5 Preview的状态机设计场景美术用的DeepSeek V4 Pro的雾效和颜色搭配移动端触控的热区处理则借鉴了GLM5.3的实现。这个“缝合”过程不仅趣味性强结果也远超任何一个模型的单独输出。所以如果你问我在AI写3D小游戏这个具体场景里到底推荐哪个模型我的答案是别追“最强模型”追“最适合你工作流的模型”。如果你擅长从现象描述问题DeepSeek V4 Pro很值得用如果你希望AI诚实表示哪些地方不适合用电线方案GLM5.3的说明能力最强如果你需要快速跑起来、后续自己主导设计Step 5 Preview的工程化程度最高。这三者之间其实不是简单的好坏关系而是选择哪个“菜刀”跟你的“砧板”更搭配。
)
