大模型写Three.js 3D网页游戏：Step 5、DeepSeek、GLM三强实测

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开始写，第一版必须能直接双击打开就见到一个可交互的场景，而不是一段“仅供参考”的伪代码。

在正式开始之前，我把这次评测的基础条件列在下面，方便你自己复现时校准环境：

顺便说一句：我刻意没有让三个模型互相参考对方的输出，整个评测过程是隔离的。这样才能比较公平地看到“同一个初始问题，三个模型各自会走哪条路”。

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直接拖进浏览器试跑。这里说句实话，没有直接翻车的只有一家。另外两家多多少少都出现了点问题，具体坑放在后面专门讲。先说整体方案上的差异。

这里得单独表扬一下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 能显示场景但碰撞判定有明显Bug；DeepSeek 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之后，针对不同维度的评分总结。分值仅代表我个人在本次测试条件下的体验，不代表模型在其他任务上的表现。

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的工程化程度最高。这三者之间其实不是简单的好坏关系，而是选择哪个“菜刀”跟你的“砧板”更搭配。