最近我干了一件挺能折腾的事让 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个模型用同一个需求说明各写一个 3D 游戏。对你没看错是 3D 游戏不是待办事项 App也不是静态网页。选这个题目是因为 3D 游戏开发能同时考验模型的代码能力、数学功底、逻辑组织能力和审美判断——这四样正好是现在大模型最容易露怯的地方。这篇文章就是这次实测的完整复盘从 Prompt 设计、生成过程、代码审阅到最终能玩的版本全给你摊开讲。如果你正准备用 AI 辅助做游戏或者纠结哪个模型更适合写复杂前端/3D 项目这篇应该能帮你省不少时间。1. 为什么要让模型们同做一个 3D 游戏1.1 3D 游戏是检验模型综合能力的试金石很多人喜欢拿模型写“贪吃蛇”“待办事项”“简历页面”来测试我不反对但这类任务对模型来说已经快变成肌肉记忆了。你给它一个常见需求它可以从训练数据里翻出一个八九不离十的模板跑起来并不意外。但 3D 游戏不一样尤其是用 Three.js 写一个带碰撞检测、计分、场景切换的小游戏对模型的综合能力要求高得多。首先是数学能力。Three.js 里的坐标系统、摄像机朝向、物体位移和碰撞盒计算每一步都在和三维向量打交道。模型一旦把 x、y、z 的顺序搞混或者忘了把碰撞盒位置随物体移动更新游戏就会变成“看着正常但一玩就穿模”。其次是逻辑组织能力。一个游戏至少要拆成初始化场景、创建角色、生成障碍物、更新状态、渲染循环、监听键盘事件这几大块。模型需要把这些模块按正确的顺序串起来而不是把所有代码堆在一个函数里。最后是审美判断。同样是一个跑酷游戏有的版本会做渐变天空、地面网格、阴影有的版本就是一片灰地板加几个方块区别非常大。我当时跟朋友开玩笑写普通网页好比做一荤一素写 3D 游戏好比做一桌宴席。食材都有但火候、顺序、摆盘处处都能看出厨师的水平。模型也一样越是复杂任务越能看出它的“内功”。1.2 测试目标与预期这次测试的目标很明确不是比谁生成的代码行数多也不是比谁的注释文笔好而是比谁能在最短时间内给出一份“打开就能玩”的成果。然后我再人为制造一些运行错误看它能不能自己修复。毕竟真实开发中AI 写出来的代码很少能一次跑通后续的调试和修复能力同样重要。在测试前我心里有一个预期三个模型应该都能写出基本框架但在细节处一定会出问题。区别只在于问题的数量和类型。Step 5 Preview 是刚放出来的预览版我对它的稳定性没抱太大期望DeepSeek V4 Pro 是老牌产品了生成速度应该最快GLM5.3 则擅长理解长文本我猜它在拆解需求时会有惊喜。结果没想到三家的翻车方式各不相同修起来也各有各的乐趣。2. 评测环境与统一游戏需求2.1 硬件与运行环境为了公平我把它们放在完全相同的环境里测试。操作系统Windows 11浏览器用 Chrome 最新稳定版。模型接入方式通过各自官方 API 调用统一关闭流式输出方便对比完整代码。无额外 Agent 工具不接代码解释器也不让模型自动运行代码只做“一次生成 人工反馈修复”的循环。静态服务器用 Python 的http.server起本地服务避免file://协议下模块加载问题。这台电脑的显卡是 RTX 4070 Ti不算顶级但跑这种轻量级 Three.js 场景绰绰有余。顺带提一句如果后面要本地部署 GLM5.3显卡显存就非常重要这个我放到第 5 部分再说。2.2 统一的游戏需求说明我给三个模型发了完全相同的 Prompt原话如下请用 HTML Three.js 制作一个 3D 跑酷游戏。要求如下所有代码放在一个 HTML 文件中通过 CDN 引入 Three.js。场景包含三条跑道玩家控制一个小球障碍物是随机生成的方块从远处向玩家移动。玩家按方向键左右切换跑道按空格键跳跃。需要实现碰撞检测碰到障碍物游戏结束。屏幕左上角显示得分游戏结束后显示重新开始按钮。不需要外部贴图用基础材质和网格辅助线即可。请输出完整可运行的代码。我特意把“完整可运行”这四个字写进去后面你会看到即便如此模型们还是会给你留点惊喜。这个需求有几个刻意的设计三条跑道看似简单实则考验模型对 x 坐标和 z 坐标的理解跳跃需要处理重力加速度这是很多模型容易写错的地方碰撞检测需要每帧更新包围盒如果模型只检测一次就会出现“隔空撞车”或“怎么也撞不到”的 bug。而这些恰好是新手最容易踩的坑。2.3 评测维度与评分规则我没有跑那种复杂的基准测试而是用了五个维度做主观打分每项 10 分一次可用率生成的代码首次运行能不能直接玩。代码完整度有没有缺函数、缺变量、缺 CDN 引用。逻辑正确性跑起来后玩法是否符合需求描述。可修复性报错信息是否容易定位修复成本高不高。注释可读性代码命名和注释能不能让人快速看懂。这个评分标准比较主观但恰恰贴近真实开发者的体验。你不需要 100% 精确的指标只需要知道哪个模型能让你少加班。3. 三个模型的生成过程全记录3.1 Step 5 Preview架构最稳但卡在交互细节先说 Step 5 Preview。它是三个模型里响应速度最接近“中位值”的第一次生成用了大约 40 秒输出约 300 行代码。我第一眼看完它的代码结构就觉得舒服定义了一个Game类里面拆了init、createScene、createPlayer、createObstacle、update、render六个方法变量命名也很规范比如playerMesh、lanePositions、gameOver。它甚至自己加了startGame和pauseGame的状态机逻辑这是一个让我有点意外的加分项。但第一次运行就发现一个很蠢的 bug场景、跑道、小球都出来了障碍物也出来了但它们全都停在原地不动。我打开控制台看没有任何报错。又仔细翻了一遍代码才发现问题出在动画循环里——它在animate函数中只调用了renderer.render(scene, camera)压根没有调用update()。update方法里写了障碍物移动、碰撞检测、得分增加但整个游戏循环根本不会执行它。这种 bug 不报错、不崩溃、不红屏唯一的表象就是“世界静止了”。修复方法只需在animate中加一行this.update()。我把这行代码补上后游戏立刻活了起来障碍物开始从远方滑向玩家碰撞检测也正常工作。当时我甚至怀疑它是故意留一手来测试我的耐心。3.2 DeepSeek V4 Pro生成速度快代码却藏了三个 bugDeepSeek V4 Pro 是我这次最期待的一个毕竟它一直以速度快著称。实际也的确如此大约 25 秒就输出了 400 多行代码比 Step 5 Preview 多了三分之一。然而代码一打开问题接踵而至。第一个 bug 在跑道坐标上。它将三条跑道的 x 坐标设成了[-2, 0, 2]这本身没问题但生成障碍物的逻辑里又把障碍物的 x 坐标按照一个随机数组去映射结果角色明明切到右边跑道遇到的障碍物却对应到中间跑道的位置玩起来就是“明明躲开了还是被撞”。我检查代码后发现它把“跑道索引”和“世界坐标”混为一谈本质上是坐标系抽象没做好。第二个 bug 在碰撞检测。它确实写了Box3碰撞检测但在动画循环里只计算了一次包围盒之后没有随着小球和方块的位置变化去更新。这导致碰撞检测只在第一帧生效之后小球可以堂而皇之穿过障碍物。从玩家视角看就是底下的碰撞盒子还在原点而小球已经跑出去十万八千里了。第三个 bug 比较隐蔽键盘事件里同时用了keydown和keyup触发跳跃。空格键按下时跳一次松开时又跳一次结果玩家按一下空格小球原地弹跳两下手感非常奇怪。修复这三个 bug 花了我大概二十分钟比前一个版本多耗了不少时间。不过话说回来DeepSeek V4 Pro 的生成速度确实快如果是简单需求这个优势会非常明显。3.3 GLM5.3理解力强差一步就能跑通GLM5.3 是我最近用得比较多的模型它给我的印象是“听得懂人话”。这次它输出大约 350 行代码开篇甚至先用注释把需求拆成了五个模块相机、跑道、玩家、障碍物、UI 交互。我一度以为它会是三个模型里最稳的结果跑起来之后发现障碍物依旧没有出现。原因很有意思。它在createObstacle前面加了一个倒计时变量spawnTimer打算每隔 3 秒生成一个障碍物。但它只写了if (spawnTimer 0) { this.createObstacle(); this.spawnTimer 3; }而spawnTimer的初始值是 0按道理第一次循环就该触发生成。我继续往下看才发现它忘记在update()里做this.spawnTimer - deltaTime的递减倒计时永远停在 0 和 3 之间来回边沿可因为没有任何递减条件永远成立倒是会疯狂生成障碍物才对……等等我读到这里自己也乱了。进一步跟踪代码后我才理清楚它确实做了倒计时递减但是递减的代码写在render()方法里而render()只在渲染一帧时执行一次并且它用的是固定帧率参数导致倒计时减少的幅度非常小玩家玩到第 20 秒才看到第一个障碍物。我改成了基于deltaTime的更新障碍物生成速度立刻恢复正常。GLM5.3 唯一的另一个问题是缺少重新开始按钮游戏结束后卡在静止画面按空格也没反应。这也是典型的“模块没接全”问题。3.4 横向对比代码量、运行成功率、可维护性汇总三个模型都跑起来之后我做了一张简单的对比表模型代码行数首次可运行率需人工修改量注释友好度我的主观推荐分Step 5 Preview约 30060%低高8.5DeepSeek V4 Pro约 42040%中高中7.5GLM5.3约 35050%中低高8.0这里说的“首次可运行率”是指打开页面后能否看到正常场景和角色。Step 5 Preview 虽然漏了update()调用但至少场景和角色都出来了直观损失最小。DeepSeek V4 Pro 代码量大问题也最分散属于“看似完整实则处处漏风”。GLM5.3 的模块拆分很舒服修复起来最容易。但要注意这个推荐分只针对“生成 3D 游戏”这个任务。如果换成写业务后端、写文案、做数据分析排名可能完全不一样。4. 实际运行与修复过程一个游戏从报错到能玩的真实路径4.1 把三个版本跑起来的步骤很多朋友看到“3D 游戏”四个字就以为需要很复杂的工程环境其实完全不是。我已经把它们全部做成了单文件 HTML所以运行只需要三步将模型生成的代码保存为index.html。在项目目录下执行python -m http.server 8080。浏览器访问http://localhost:8080。为什么不直接双击打开 HTML因为新版浏览器出于安全策略对本地file://请求会限制部分模块加载。Three.js 老版本直接 script 引入还能凑合但有些模型会输出import语法必须走 HTTP 服务。另外如果你在使用 VS Code装一个 Live Server 插件也可以效果一样。这一步里最容易踩的坑是 CDN 地址。三个模型写的 Three.js CDN 链接各不相同有的用https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js有的用https://unpkg.com/three0.128.0/build/three.min.js理论上都能用但如果你所在的网络环境访问某些 CDN 特别慢页面就会一直白屏控制台提示THREE is not defined。我的做法是统一替换成https://cdn.jsdelivr.net/npm/three0.128.0/build/three.min.js这个在国内外访问都比较稳定。这种情况不属于模型代码问题属于基础设施选型。4.2 逐个修复典型编译与运行错误在调试过程中我遇到了三类典型错误整理成表给你参考错误现象根本原因涉及模型修复方法页面白屏控制台报THREE is not definedCDN 未加载或链接过期DeepSeek V4 Pro 输出的链接不稳定统一替换为 jsDelivr 的 r128 版本引用画面正常但所有物体静止动画循环里没调用update()Step 5 Preview在animate()中补上this.update()碰撞检测失效包围盒位置没有随物体每帧更新DeepSeek V4 Pro每帧重新计算包围盒或用Box3.setFromObject后translate障碍物很久才出现倒计时更新逻辑放在了render()中GLM5.3改成基于deltaTime在update()中递减按键跳跃触发两次keydown和keyup都绑定了跳跃DeepSeek V4 Pro只保留keydown触发并加一个跳跃锁状态这三个模型都没有出现语法级错误生成的 JavaScript 都能被浏览器解析问题全部出在运行时逻辑和状态管理上。这说明模型在“局部代码”层面已经很熟练了但在“程序随时间运行”的维度上还容易犯迷糊。4.3 游戏效果对比渲染、交互、帧率修复完所有 bug 之后我把三个版本放在一起玩了几轮。Step 5 Preview 的版本做了淡蓝色渐变天空和柔和阴影视觉上最舒服障碍物是随机颜色方块落在地面网格上很有“原型游戏”的质感。它的缺陷是角色移动采用瞬间改坐标的方式没有补间动画手感偏硬。DeepSeek V4 Pro 的版本色调偏灰没有阴影地面网格密度很高看起来更像一排实验室地板。它最大的优势是帧率非常稳定就算障碍物堆叠很多也没有明显掉帧。这可能和它没有做太多材质计算有关视觉上简单性能反而好。GLM5.3 的版本则把重心放在了跳跃手感上。它把重力加速度设成 0.005跳跃高度大约是障碍物高度的两倍起跳和落地的时刻刚好匹配障碍物到达玩起来容错率很高。它的缺点是没有游戏结束后的弹窗提示只会把画面定格在碰撞瞬间第一次玩的人很容易以为是电脑卡住了。我在浏览器性能面板里瞟了一眼三个版本在普通场景下都是 60fps 满帧运行只有 DeepSeek V4 Pro 在障碍物数量超过 20 个时掉到 45fps 左右原因是它每一帧都在创建新的网格对象没有做对象池复用。这个问题在小型游戏里不致命但如果你想扩展成更复杂的作品还是要手动优化。5. 模型输出背后的规律与避坑技巧5.1 模型们爱犯的共性问题三个模型翻车的点看起来五花八门但归纳下来其实高度一致。第一是生命周期意识缺失。很多模型能够写出“创建对象”和“更新对象”的代码但容易忽略“在循环中调用更新”这个动作。它们把函数定义和生产出来却忘了函数需要被主循环不断驱动。放在游戏里就是静态画面放在服务器代码里就是只执行一次的任务。第二是坐标轴理解偏差。尤其是 x 和 z 轴的使用。Three.js 里水平方向通常用 x纵深方向用 z。模型写障碍物移动时有时会对 z 进行递减但生成障碍物的位置却全部放在 x 轴上导致物体从侧面飞过来。这个错误很隐蔽但只要玩第一关就会暴露。第三是事件处理边界不清晰。比如跳跃不能只依赖按键事件触发还要判断角色是否在地面上否则空降时也能二段跳。模型往往能写出setInterval或requestAnimationFrame但对用户操作频率的约束和抖动处理几乎没有概念。第四是忽略对象清理。DeepSeek V4 Pro 的版本里障碍物移出屏幕后并没有从场景中移除导致物体越攒越多内存和渲染压力持续上升。这在短时间测试中看不出来但玩超过五分钟帧率就会肉眼可见地下滑。出现这些问题的原因很本质LLM 是在生成“看起来合理的文本”而不是在模拟程序的真实运行。它不知道用户在某一帧按了空格也不知道前面 100 个障碍物占了哪些坐标。它只能依靠训练数据里的模式去猜测所以你在 prompt 里把事情说得越精确它的表现就会越好。5.2 如何根据模型特点设计提示词既然摸清了模型的臭毛病我们就能在提示词里提前打补丁。我把这次实测中三个模型都表现更好的 prompt 版本贴在下面供你参考请用 HTML Three.js 制作一个 3D 跑酷游戏。场景中有三条跑道跑道坐标建议为 x -2、0、2玩家的球初始位于 x 0、y 0、z 4。障碍物是一个 BoxGeometry 方块从 z -30 远处向玩家方向移动每次移动单位应为 0.1。请定义一个 Game 类建议包含 init、setupScene、update、render、keydownHandler 五个方法在 update 方法中统一处理障碍物位移、碰撞检测、得分更新。游戏循环中要同时调用 update 和 render。碰撞检测请使用 Box3并确保每一帧都重新计算碰撞盒位置。跳跃时请判断 player.isJumping 状态防止二段跳。请输出完整可运行的 HTML 代码。多出来的关键信息有三个明确的坐标系、明确的循环职责、明确的二段跳约束。我把这些写进去后三个模型的“一次可用率”都有肉眼可见的提升。你可以发现这些信息并不是什么高深知识只是让模型不需要猜测你的意图。另外还有一个非常有用的技巧把控制台报错原封不动地粘贴回模型让它自己修。在这次测试中GLM5.3 和 Step 5 Preview 都能根据报错快速定位问题DeepSeek V4 Pro 有时候会“越修越错”因为它喜欢把没有报错的部分也顺便重构掉。我后来给它加了“只做最小修复不要改动无关代码”的约束偏差立刻小了很多。5.3 顺带一提本地部署 GLM5.3 时 vLLM 镜像的选择聊到 GLM5.3有一个很现实的问题是很多人不想走 API想本地部署。我自己的经验是用 vLLM 跑 GLM5.3 是可行的但镜像版本一定要选对否则容易出现各种奇怪问题。我用的是 NVIDIA 驱动 Docker 环境最初直接拉vllm/vllm-openai:latest结果启动就报显存分配失败。后来检查发现是镜像里的 CUDA 版本和本机驱动不兼容。如果你也遇到类似问题先确认显卡驱动版本再反推应该用哪个 CUDA 版本的镜像。比较稳妥的做法是查看 GLM 官方仓库在 vLLM 发布说明里推荐的版本而不是盲目追求 latest。另外一个坑是 vLLM 镜像是否带 OpenAI 兼容接口。如果你只是用vllm serve启动模型通常没问题但有些精简镜像只提供了离线推理入口返回格式和 OpenAI 完全不同这就导致你可能写了半天的游戏测试脚本根本没法调用模型。我后来换成官方推荐的带vllm serve命令的镜像才顺利跑通。如果你只是做小范围评测不想折腾 Docker直接用transformers加载 GLM5.3 也能跑但速度会慢很多。我的建议是本地部署能摸 API 就摸 API能省下大量调环境的时间。省下来的时间不如多给模型想几个更好的提示词。6. 这次实测给我的几点真实体会6.1 模型写游戏最大的价值是“脚手架”经过这一下午折腾我最大的感受是别指望模型一键生成完美游戏但它能把你从一张白纸直接送到“大概能跑”的状态。这个价值非常大。以前我想在 Three.js 里做一个跑酷原型光查文档、调坐标、修碰撞就要一晚上。现在让 AI 生成初版我再花半小时改改一个可玩的 demo 就到手了。它像是一个特别聪明的实习生你需要检查它的工作但效率依然比自己从零开始高一个量级。6.2 提示词和验收习惯比模型本身更重要三个模型各有各的强项但最终决定游戏质量的并不是“谁更强”而是我的 Prompt 写得清不清楚以及我有没有耐心看控制台报错。我在不同 prompt 下使用同一个模型的体验差异甚至比不同模型之间的差异更大。如果你想让 AI 写游戏最值得花时间的不是纠结选哪个模型而是把需求拆到“坐标、循环、事件、边界条件”这种颗粒度。6.3 给想这么做的人一个建议清单如果你也想复现类似的测试我建议你按这个流程走先准备一个非常具体的游戏需求明确坐标系和玩法让多个模型各自生成不要中途打扰把结果保存好同一环境运行记录报错再把报错喂回模型做两轮修复最后亲自玩三遍感受一下操作手感。相信我这个过程比你刷十篇评测文章有用得多。这次实测之后我再也不会相信谁能让 AI“一键生成完整游戏”了。但我更加相信一个会写 prompt、会看控制台、会把报错喂回模型的人加上 AI 的脚手架能力真的可以在一个下午做出一个能和朋友分享的小作品。这本身就是件值得开心的事。 
长河君 · 2026/11/3 11:56:57 · 阅读 1.2k 三大模型实测：用Three.js写3D跑酷游戏，谁更强？
最近我干了一件挺能折腾的事让 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个模型用同一个需求说明各写一个 3D 游戏。对你没看错是 3D 游戏不是待办事项 App也不是静态网页。选这个题目是因为 3D 游戏开发能同时考验模型的代码能力、数学功底、逻辑组织能力和审美判断——这四样正好是现在大模型最容易露怯的地方。这篇文章就是这次实测的完整复盘从 Prompt 设计、生成过程、代码审阅到最终能玩的版本全给你摊开讲。如果你正准备用 AI 辅助做游戏或者纠结哪个模型更适合写复杂前端/3D 项目这篇应该能帮你省不少时间。1. 为什么要让模型们同做一个 3D 游戏1.1 3D 游戏是检验模型综合能力的试金石很多人喜欢拿模型写“贪吃蛇”“待办事项”“简历页面”来测试我不反对但这类任务对模型来说已经快变成肌肉记忆了。你给它一个常见需求它可以从训练数据里翻出一个八九不离十的模板跑起来并不意外。但 3D 游戏不一样尤其是用 Three.js 写一个带碰撞检测、计分、场景切换的小游戏对模型的综合能力要求高得多。首先是数学能力。Three.js 里的坐标系统、摄像机朝向、物体位移和碰撞盒计算每一步都在和三维向量打交道。模型一旦把 x、y、z 的顺序搞混或者忘了把碰撞盒位置随物体移动更新游戏就会变成“看着正常但一玩就穿模”。其次是逻辑组织能力。一个游戏至少要拆成初始化场景、创建角色、生成障碍物、更新状态、渲染循环、监听键盘事件这几大块。模型需要把这些模块按正确的顺序串起来而不是把所有代码堆在一个函数里。最后是审美判断。同样是一个跑酷游戏有的版本会做渐变天空、地面网格、阴影有的版本就是一片灰地板加几个方块区别非常大。我当时跟朋友开玩笑写普通网页好比做一荤一素写 3D 游戏好比做一桌宴席。食材都有但火候、顺序、摆盘处处都能看出厨师的水平。模型也一样越是复杂任务越能看出它的“内功”。1.2 测试目标与预期这次测试的目标很明确不是比谁生成的代码行数多也不是比谁的注释文笔好而是比谁能在最短时间内给出一份“打开就能玩”的成果。然后我再人为制造一些运行错误看它能不能自己修复。毕竟真实开发中AI 写出来的代码很少能一次跑通后续的调试和修复能力同样重要。在测试前我心里有一个预期三个模型应该都能写出基本框架但在细节处一定会出问题。区别只在于问题的数量和类型。Step 5 Preview 是刚放出来的预览版我对它的稳定性没抱太大期望DeepSeek V4 Pro 是老牌产品了生成速度应该最快GLM5.3 则擅长理解长文本我猜它在拆解需求时会有惊喜。结果没想到三家的翻车方式各不相同修起来也各有各的乐趣。2. 评测环境与统一游戏需求2.1 硬件与运行环境为了公平我把它们放在完全相同的环境里测试。操作系统Windows 11浏览器用 Chrome 最新稳定版。模型接入方式通过各自官方 API 调用统一关闭流式输出方便对比完整代码。无额外 Agent 工具不接代码解释器也不让模型自动运行代码只做“一次生成 人工反馈修复”的循环。静态服务器用 Python 的http.server起本地服务避免file://协议下模块加载问题。这台电脑的显卡是 RTX 4070 Ti不算顶级但跑这种轻量级 Three.js 场景绰绰有余。顺带提一句如果后面要本地部署 GLM5.3显卡显存就非常重要这个我放到第 5 部分再说。2.2 统一的游戏需求说明我给三个模型发了完全相同的 Prompt原话如下请用 HTML Three.js 制作一个 3D 跑酷游戏。要求如下所有代码放在一个 HTML 文件中通过 CDN 引入 Three.js。场景包含三条跑道玩家控制一个小球障碍物是随机生成的方块从远处向玩家移动。玩家按方向键左右切换跑道按空格键跳跃。需要实现碰撞检测碰到障碍物游戏结束。屏幕左上角显示得分游戏结束后显示重新开始按钮。不需要外部贴图用基础材质和网格辅助线即可。请输出完整可运行的代码。我特意把“完整可运行”这四个字写进去后面你会看到即便如此模型们还是会给你留点惊喜。这个需求有几个刻意的设计三条跑道看似简单实则考验模型对 x 坐标和 z 坐标的理解跳跃需要处理重力加速度这是很多模型容易写错的地方碰撞检测需要每帧更新包围盒如果模型只检测一次就会出现“隔空撞车”或“怎么也撞不到”的 bug。而这些恰好是新手最容易踩的坑。2.3 评测维度与评分规则我没有跑那种复杂的基准测试而是用了五个维度做主观打分每项 10 分一次可用率生成的代码首次运行能不能直接玩。代码完整度有没有缺函数、缺变量、缺 CDN 引用。逻辑正确性跑起来后玩法是否符合需求描述。可修复性报错信息是否容易定位修复成本高不高。注释可读性代码命名和注释能不能让人快速看懂。这个评分标准比较主观但恰恰贴近真实开发者的体验。你不需要 100% 精确的指标只需要知道哪个模型能让你少加班。3. 三个模型的生成过程全记录3.1 Step 5 Preview架构最稳但卡在交互细节先说 Step 5 Preview。它是三个模型里响应速度最接近“中位值”的第一次生成用了大约 40 秒输出约 300 行代码。我第一眼看完它的代码结构就觉得舒服定义了一个Game类里面拆了init、createScene、createPlayer、createObstacle、update、render六个方法变量命名也很规范比如playerMesh、lanePositions、gameOver。它甚至自己加了startGame和pauseGame的状态机逻辑这是一个让我有点意外的加分项。但第一次运行就发现一个很蠢的 bug场景、跑道、小球都出来了障碍物也出来了但它们全都停在原地不动。我打开控制台看没有任何报错。又仔细翻了一遍代码才发现问题出在动画循环里——它在animate函数中只调用了renderer.render(scene, camera)压根没有调用update()。update方法里写了障碍物移动、碰撞检测、得分增加但整个游戏循环根本不会执行它。这种 bug 不报错、不崩溃、不红屏唯一的表象就是“世界静止了”。修复方法只需在animate中加一行this.update()。我把这行代码补上后游戏立刻活了起来障碍物开始从远方滑向玩家碰撞检测也正常工作。当时我甚至怀疑它是故意留一手来测试我的耐心。3.2 DeepSeek V4 Pro生成速度快代码却藏了三个 bugDeepSeek V4 Pro 是我这次最期待的一个毕竟它一直以速度快著称。实际也的确如此大约 25 秒就输出了 400 多行代码比 Step 5 Preview 多了三分之一。然而代码一打开问题接踵而至。第一个 bug 在跑道坐标上。它将三条跑道的 x 坐标设成了[-2, 0, 2]这本身没问题但生成障碍物的逻辑里又把障碍物的 x 坐标按照一个随机数组去映射结果角色明明切到右边跑道遇到的障碍物却对应到中间跑道的位置玩起来就是“明明躲开了还是被撞”。我检查代码后发现它把“跑道索引”和“世界坐标”混为一谈本质上是坐标系抽象没做好。第二个 bug 在碰撞检测。它确实写了Box3碰撞检测但在动画循环里只计算了一次包围盒之后没有随着小球和方块的位置变化去更新。这导致碰撞检测只在第一帧生效之后小球可以堂而皇之穿过障碍物。从玩家视角看就是底下的碰撞盒子还在原点而小球已经跑出去十万八千里了。第三个 bug 比较隐蔽键盘事件里同时用了keydown和keyup触发跳跃。空格键按下时跳一次松开时又跳一次结果玩家按一下空格小球原地弹跳两下手感非常奇怪。修复这三个 bug 花了我大概二十分钟比前一个版本多耗了不少时间。不过话说回来DeepSeek V4 Pro 的生成速度确实快如果是简单需求这个优势会非常明显。3.3 GLM5.3理解力强差一步就能跑通GLM5.3 是我最近用得比较多的模型它给我的印象是“听得懂人话”。这次它输出大约 350 行代码开篇甚至先用注释把需求拆成了五个模块相机、跑道、玩家、障碍物、UI 交互。我一度以为它会是三个模型里最稳的结果跑起来之后发现障碍物依旧没有出现。原因很有意思。它在createObstacle前面加了一个倒计时变量spawnTimer打算每隔 3 秒生成一个障碍物。但它只写了if (spawnTimer 0) { this.createObstacle(); this.spawnTimer 3; }而spawnTimer的初始值是 0按道理第一次循环就该触发生成。我继续往下看才发现它忘记在update()里做this.spawnTimer - deltaTime的递减倒计时永远停在 0 和 3 之间来回边沿可因为没有任何递减条件永远成立倒是会疯狂生成障碍物才对……等等我读到这里自己也乱了。进一步跟踪代码后我才理清楚它确实做了倒计时递减但是递减的代码写在render()方法里而render()只在渲染一帧时执行一次并且它用的是固定帧率参数导致倒计时减少的幅度非常小玩家玩到第 20 秒才看到第一个障碍物。我改成了基于deltaTime的更新障碍物生成速度立刻恢复正常。GLM5.3 唯一的另一个问题是缺少重新开始按钮游戏结束后卡在静止画面按空格也没反应。这也是典型的“模块没接全”问题。3.4 横向对比代码量、运行成功率、可维护性汇总三个模型都跑起来之后我做了一张简单的对比表模型代码行数首次可运行率需人工修改量注释友好度我的主观推荐分Step 5 Preview约 30060%低高8.5DeepSeek V4 Pro约 42040%中高中7.5GLM5.3约 35050%中低高8.0这里说的“首次可运行率”是指打开页面后能否看到正常场景和角色。Step 5 Preview 虽然漏了update()调用但至少场景和角色都出来了直观损失最小。DeepSeek V4 Pro 代码量大问题也最分散属于“看似完整实则处处漏风”。GLM5.3 的模块拆分很舒服修复起来最容易。但要注意这个推荐分只针对“生成 3D 游戏”这个任务。如果换成写业务后端、写文案、做数据分析排名可能完全不一样。4. 实际运行与修复过程一个游戏从报错到能玩的真实路径4.1 把三个版本跑起来的步骤很多朋友看到“3D 游戏”四个字就以为需要很复杂的工程环境其实完全不是。我已经把它们全部做成了单文件 HTML所以运行只需要三步将模型生成的代码保存为index.html。在项目目录下执行python -m http.server 8080。浏览器访问http://localhost:8080。为什么不直接双击打开 HTML因为新版浏览器出于安全策略对本地file://请求会限制部分模块加载。Three.js 老版本直接 script 引入还能凑合但有些模型会输出import语法必须走 HTTP 服务。另外如果你在使用 VS Code装一个 Live Server 插件也可以效果一样。这一步里最容易踩的坑是 CDN 地址。三个模型写的 Three.js CDN 链接各不相同有的用https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js有的用https://unpkg.com/three0.128.0/build/three.min.js理论上都能用但如果你所在的网络环境访问某些 CDN 特别慢页面就会一直白屏控制台提示THREE is not defined。我的做法是统一替换成https://cdn.jsdelivr.net/npm/three0.128.0/build/three.min.js这个在国内外访问都比较稳定。这种情况不属于模型代码问题属于基础设施选型。4.2 逐个修复典型编译与运行错误在调试过程中我遇到了三类典型错误整理成表给你参考错误现象根本原因涉及模型修复方法页面白屏控制台报THREE is not definedCDN 未加载或链接过期DeepSeek V4 Pro 输出的链接不稳定统一替换为 jsDelivr 的 r128 版本引用画面正常但所有物体静止动画循环里没调用update()Step 5 Preview在animate()中补上this.update()碰撞检测失效包围盒位置没有随物体每帧更新DeepSeek V4 Pro每帧重新计算包围盒或用Box3.setFromObject后translate障碍物很久才出现倒计时更新逻辑放在了render()中GLM5.3改成基于deltaTime在update()中递减按键跳跃触发两次keydown和keyup都绑定了跳跃DeepSeek V4 Pro只保留keydown触发并加一个跳跃锁状态这三个模型都没有出现语法级错误生成的 JavaScript 都能被浏览器解析问题全部出在运行时逻辑和状态管理上。这说明模型在“局部代码”层面已经很熟练了但在“程序随时间运行”的维度上还容易犯迷糊。4.3 游戏效果对比渲染、交互、帧率修复完所有 bug 之后我把三个版本放在一起玩了几轮。Step 5 Preview 的版本做了淡蓝色渐变天空和柔和阴影视觉上最舒服障碍物是随机颜色方块落在地面网格上很有“原型游戏”的质感。它的缺陷是角色移动采用瞬间改坐标的方式没有补间动画手感偏硬。DeepSeek V4 Pro 的版本色调偏灰没有阴影地面网格密度很高看起来更像一排实验室地板。它最大的优势是帧率非常稳定就算障碍物堆叠很多也没有明显掉帧。这可能和它没有做太多材质计算有关视觉上简单性能反而好。GLM5.3 的版本则把重心放在了跳跃手感上。它把重力加速度设成 0.005跳跃高度大约是障碍物高度的两倍起跳和落地的时刻刚好匹配障碍物到达玩起来容错率很高。它的缺点是没有游戏结束后的弹窗提示只会把画面定格在碰撞瞬间第一次玩的人很容易以为是电脑卡住了。我在浏览器性能面板里瞟了一眼三个版本在普通场景下都是 60fps 满帧运行只有 DeepSeek V4 Pro 在障碍物数量超过 20 个时掉到 45fps 左右原因是它每一帧都在创建新的网格对象没有做对象池复用。这个问题在小型游戏里不致命但如果你想扩展成更复杂的作品还是要手动优化。5. 模型输出背后的规律与避坑技巧5.1 模型们爱犯的共性问题三个模型翻车的点看起来五花八门但归纳下来其实高度一致。第一是生命周期意识缺失。很多模型能够写出“创建对象”和“更新对象”的代码但容易忽略“在循环中调用更新”这个动作。它们把函数定义和生产出来却忘了函数需要被主循环不断驱动。放在游戏里就是静态画面放在服务器代码里就是只执行一次的任务。第二是坐标轴理解偏差。尤其是 x 和 z 轴的使用。Three.js 里水平方向通常用 x纵深方向用 z。模型写障碍物移动时有时会对 z 进行递减但生成障碍物的位置却全部放在 x 轴上导致物体从侧面飞过来。这个错误很隐蔽但只要玩第一关就会暴露。第三是事件处理边界不清晰。比如跳跃不能只依赖按键事件触发还要判断角色是否在地面上否则空降时也能二段跳。模型往往能写出setInterval或requestAnimationFrame但对用户操作频率的约束和抖动处理几乎没有概念。第四是忽略对象清理。DeepSeek V4 Pro 的版本里障碍物移出屏幕后并没有从场景中移除导致物体越攒越多内存和渲染压力持续上升。这在短时间测试中看不出来但玩超过五分钟帧率就会肉眼可见地下滑。出现这些问题的原因很本质LLM 是在生成“看起来合理的文本”而不是在模拟程序的真实运行。它不知道用户在某一帧按了空格也不知道前面 100 个障碍物占了哪些坐标。它只能依靠训练数据里的模式去猜测所以你在 prompt 里把事情说得越精确它的表现就会越好。5.2 如何根据模型特点设计提示词既然摸清了模型的臭毛病我们就能在提示词里提前打补丁。我把这次实测中三个模型都表现更好的 prompt 版本贴在下面供你参考请用 HTML Three.js 制作一个 3D 跑酷游戏。场景中有三条跑道跑道坐标建议为 x -2、0、2玩家的球初始位于 x 0、y 0、z 4。障碍物是一个 BoxGeometry 方块从 z -30 远处向玩家方向移动每次移动单位应为 0.1。请定义一个 Game 类建议包含 init、setupScene、update、render、keydownHandler 五个方法在 update 方法中统一处理障碍物位移、碰撞检测、得分更新。游戏循环中要同时调用 update 和 render。碰撞检测请使用 Box3并确保每一帧都重新计算碰撞盒位置。跳跃时请判断 player.isJumping 状态防止二段跳。请输出完整可运行的 HTML 代码。多出来的关键信息有三个明确的坐标系、明确的循环职责、明确的二段跳约束。我把这些写进去后三个模型的“一次可用率”都有肉眼可见的提升。你可以发现这些信息并不是什么高深知识只是让模型不需要猜测你的意图。另外还有一个非常有用的技巧把控制台报错原封不动地粘贴回模型让它自己修。在这次测试中GLM5.3 和 Step 5 Preview 都能根据报错快速定位问题DeepSeek V4 Pro 有时候会“越修越错”因为它喜欢把没有报错的部分也顺便重构掉。我后来给它加了“只做最小修复不要改动无关代码”的约束偏差立刻小了很多。5.3 顺带一提本地部署 GLM5.3 时 vLLM 镜像的选择聊到 GLM5.3有一个很现实的问题是很多人不想走 API想本地部署。我自己的经验是用 vLLM 跑 GLM5.3 是可行的但镜像版本一定要选对否则容易出现各种奇怪问题。我用的是 NVIDIA 驱动 Docker 环境最初直接拉vllm/vllm-openai:latest结果启动就报显存分配失败。后来检查发现是镜像里的 CUDA 版本和本机驱动不兼容。如果你也遇到类似问题先确认显卡驱动版本再反推应该用哪个 CUDA 版本的镜像。比较稳妥的做法是查看 GLM 官方仓库在 vLLM 发布说明里推荐的版本而不是盲目追求 latest。另外一个坑是 vLLM 镜像是否带 OpenAI 兼容接口。如果你只是用vllm serve启动模型通常没问题但有些精简镜像只提供了离线推理入口返回格式和 OpenAI 完全不同这就导致你可能写了半天的游戏测试脚本根本没法调用模型。我后来换成官方推荐的带vllm serve命令的镜像才顺利跑通。如果你只是做小范围评测不想折腾 Docker直接用transformers加载 GLM5.3 也能跑但速度会慢很多。我的建议是本地部署能摸 API 就摸 API能省下大量调环境的时间。省下来的时间不如多给模型想几个更好的提示词。6. 这次实测给我的几点真实体会6.1 模型写游戏最大的价值是“脚手架”经过这一下午折腾我最大的感受是别指望模型一键生成完美游戏但它能把你从一张白纸直接送到“大概能跑”的状态。这个价值非常大。以前我想在 Three.js 里做一个跑酷原型光查文档、调坐标、修碰撞就要一晚上。现在让 AI 生成初版我再花半小时改改一个可玩的 demo 就到手了。它像是一个特别聪明的实习生你需要检查它的工作但效率依然比自己从零开始高一个量级。6.2 提示词和验收习惯比模型本身更重要三个模型各有各的强项但最终决定游戏质量的并不是“谁更强”而是我的 Prompt 写得清不清楚以及我有没有耐心看控制台报错。我在不同 prompt 下使用同一个模型的体验差异甚至比不同模型之间的差异更大。如果你想让 AI 写游戏最值得花时间的不是纠结选哪个模型而是把需求拆到“坐标、循环、事件、边界条件”这种颗粒度。6.3 给想这么做的人一个建议清单如果你也想复现类似的测试我建议你按这个流程走先准备一个非常具体的游戏需求明确坐标系和玩法让多个模型各自生成不要中途打扰把结果保存好同一环境运行记录报错再把报错喂回模型做两轮修复最后亲自玩三遍感受一下操作手感。相信我这个过程比你刷十篇评测文章有用得多。这次实测之后我再也不会相信谁能让 AI“一键生成完整游戏”了。但我更加相信一个会写 prompt、会看控制台、会把报错喂回模型的人加上 AI 的脚手架能力真的可以在一个下午做出一个能和朋友分享的小作品。这本身就是件值得开心的事。