资讯详情

三款大模型生成Three.js 3D游戏实测:谁更可靠?

📅 2026/11/2 8:56:16 | 华诺云谱 👁 阅读
三款大模型生成Three.js 3D游戏实测:谁更可靠?
说实话最近这波大模型迭代让我最受不了的就是榜单通胀。今天某个模型在某个跑分项登顶明天另一个模型又说刷新了纪录但真要让它帮你把一个 3D 游戏从零写到能玩很多模型的体验会瞬间打回原形。所以我把 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三款当下热度最高的模型拉到同一条起跑线上让它们用完全相同的需求文档各自做一个 Three.js 3D 小游戏。这篇文章就是这次实测的完整复盘谁最先交卷谁交出来的东西能直接玩谁是你遇到 Bug 时真正能指望得上的队友。我提前说明一下这篇文章不是跑分软文我也不会说谁更强这种绝对结论。游戏开发是个系统工程模型生成的代码只是起点能不能跑、好不好玩、出问题时能不能修才是真正决定项目高度的东西。我按一个外包甲方的验收标准来打分下面全部是实际跑过的结果。1. 这次擂台赛是被榜单逼出来的1.1 为什么拿 3D 游戏当考题而不是继续刷跑分先说动机。过去一个月我拿这批新模型做了不少代码测试包括单页应用、图表组件、数据爬虫工具合规的公开数据但 3D 游戏这类综合题我一直没碰过。原因很简单3D 游戏同时压榨模型好几项能力缺一块短板就会立刻暴露。架构能力场景图怎么管理、渲染循环放哪、游戏状态机和 UI 状态怎么切。数学能力向量移动、碰撞检测、相机跟随插值这些不是背 API能糊弄过去的。资源策略不能依赖外部 CDN 和现成模型文件时几何体、材质、贴图都得用代码生成。抗压能力用户乱按键盘、窗口缩放、游戏重开、设备性能波动代码必须兜得住。拿这种题去考模型比任何排行榜都有说服力。跑分榜就像高考模拟卷成绩而这个实测更像是入职后的第一个真实项目两回事。1.2 开跑前我对三款模型的偏见我这人习惯先给选手画个像再验证。开跑前我对它们的预判是这样的Step 5 Preview顶着一股冲刺新版本的劲头宣传上强调创意类代码生成我预期它会写出一些花活但对工程严谨性没那么放心。DeepSeek V4 Pro一贯的结构化输出狂魔写大项目时模块切分很漂亮但有时过度设计小游戏容易被写成企业级框架。GLM5.3生态和工具链最成熟多轮对话稳定我预期它是最稳的六边形战士但可能缺少惊喜。结果证明我的偏见一半被验证一半被彻底打脸。细节后面逐个说。1.3 考题的设计思路同一条需求三条硬约束很多对比测试不严谨是因为给每个模型的提示词不一样或者中途人为加了思路引导。我在这次实验里给自己定了几条规矩三份 Prompt 严格一致一个字都不改。不提供任何思路提示考察模型自己拆解需求的能力。不允许使用外部 CDN、图片、音频模型文件所有资源必须代码生成。每轮都开独立的无痕窗口、清空缓存避免上下文污染。需求文档里我明确要求做一个低多边形风格的 3D 收集冒险游戏包含开始界面、得分与生命值、游戏结束、重新开始、程序化生成资源等核心模块。这套要求同时测试完整度和克制力——需求里写加分项的地方恰恰能看出模型愿不愿意多做一步。2. 同一条需求、同一杆秤环境和评分标准2.1 运行环境这次我用的是一台 Mac mini M2 Pro16GB 统一内存浏览器是 Chrome 138 稳定版桌面端独立无痕窗口移动端后面单独用安卓真机测了 WebView 兼容。每轮测试前都清空 Service Worker 和缓存保证每个模型都是从零加载状态。2.2 需求文档全文一字未改先把 Prompt 贴出来方便你复现用 Three.js 在浏览器里实现一个低多边形风格的 3D 收集冒险小游戏。 要求 1. 玩家控制一个小机器人在漂浮于半空的多个小岛上移动收集随机散布的能量水晶 同时避开在岛间巡逻的障碍机器人。 2. 操作方式WASD 控制移动方向空格键跳跃镜头使用第三人称自动跟随。 3. 资源约束不使用任何外部 CDN、图片、模型文件所有几何体和材质全部用 Three.js 代码生成贴图如果必须使用请用 Canvas 程序化生成。 4. 游戏完整性需要开始界面、得分与生命值显示、游戏结束界面、重新开始按钮。 5. 技术约束代码需结构清晰附必要注释。产物必须能在离线浏览器环境中运行。 6. 加分项动态光照、粒子效果、镜头平滑、移动端触控支持。注意第六行加分项是故意留的陷阱。谁会在完成基础需求后还主动做这些直接反映了模型的产品思维而不是代码能力。2.3 我自己的四维评分表跑分榜单看多了一维指标我自己做了一个偏实战的验收表四个维度加权维度权重考察内容完整性30%需求里的硬性项是否全部覆盖能不能直接运行可玩性/创意25%玩起来的体感、节奏、视觉反馈、有没有想多做一步的细节工程化25%代码组织、状态管理、内存释放、浏览器兼容处理可救性20%出 Bug 后能不能靠多轮对话修好是否引入新问题这套标准约等于我作为外包甲方拿到货之后的验收清单。不是学术论文是我真实项目里会用的判断方式。3. GLM5.3交卷最快但玩法像个模板房3.1 产物形态单文件 741 行双击即用GLM5.3 是第一个交卷的生成耗时大概 4 分半。产物是单个 index.html所有 JS 和样式内联741 行。这里我先给个好评它把离线可运行理解得很到位直接双击文件就能玩不需要起本地服务。单文件方案的好处是分发和测试都方便坏处是代码不可避免会变成大泥球。但如果你只是想要一个能快速验证想法的原型这个选择非常合理。3.2 生成思路拆解用距离判断搞定碰撞GLM5.3 的代码走的是能跑就行的务实路线。碰撞检测没有引入复杂的三维网格判定而是直接用球心距离// 收集物碰撞直接算球心距离 const dist player.position.distanceTo(crystal.position); if (dist playerRadius crystalRadius) { score 1; crystal.position.y -10; // 移出场景稍后重新随机布置 pendingRespawn.push(crystal); }这种做法在原型阶段没什么问题性能上也省事。玩家模型用 SphereGeometry收集物也是小球球心距离估算已经够用。但问题也藏在这里当玩家高速移动时它的位置是靠每帧 update 里手动积分更新的如果这一帧恰好跨过了障碍物半径范围就会直接穿模。这个我在 3.3 里会细说。3.3 运行实录三处可复现的问题我的验收方式是先跑 15 分钟基础流程再做破坏性操作比如反复重开游戏、高速跑图、窗口缩放。GLM5.3 版本稳定暴露了三个问题阴影痤疮。默认平行光阴影参数没调地面在特定视角下会出现明显的条纹闪烁。这个属于 Three.js 新手最容易踩的坑通过把 shadow.bias 设为 -0.0005 能解决。重开游戏后相机位置残留。重新开始时得分和生命值都重置了但相机初始位置没有复位导致追尾镜头从上一局的结束位置继续工作画面有一瞬间的跳变。高速反弹穿透。上面提到的距离判定在低速时没问题但玩家带着助跑冲入障碍物时偶尔会直接穿到另一边。这三个问题都不是致命伤但说明 GLM5.3 在把游戏玩一遍再交卷这件事上做得不够。它更像一个需求翻译器你说了什么它做什么但它不会主动把自己摆到玩家的位置去体验一遍。3.4 给 GLM5.3 的验收分完整性给满所有硬性需求都有可玩性中等节奏设计比较平没有明显的爽点工程化基础尚可但有上面几个可复现的隐患可救性不错我把三个 Bug 丢回去之后前两个都在两轮对话内修对了第三个只调整了碰撞半径属于治标不治本。总体是一个靠谱的中等外包交付。能用但不惊艳。4. DeepSeek V4 Pro工程味最浓却最不敢做花样4.1 模块划分像正经前端项目的产物DeepSeek V4 Pro 的产物一出来文件结构就和前面两个完全不是一个画风index.html src/ main.js // 入口和渲染循环 Game.js // 状态机与全局流程 Player.js // 玩家控制与物理 Level.js // 岛块、平台和障碍布置 AssetFactory.js // 所有几何体、材质、贴图的程序化工厂860 多行代码分到五个文件里。它默认你是要长期维护这个项目的。Game.js 里甚至做了一个完整的枚举状态机BOOT / PLAYING / PAUSED / GAME_OVER每个状态的切换都有明确的进入和退出逻辑。这是我见过 AI 生成代码里少有的可扩展架构。物理更新也做得像模像样用了固定步长累积update(dt) { const fixedStep 1 / 60; this.acc dt; while (this.acc fixedStep) { this.integrate(fixedStep); this.acc - fixedStep; } }这样物理不会因为设备帧率波动而变速比 GLM5.3 的每帧直接积分严谨一个档次。4.2 工程化细节对象池和合并几何体更让我意外的是它在 Level.js 里主动做了两件很多前端老手才会做的事所有障碍物和收集物都是预创建的反复重开游戏只是移动位置而不是重新 new 一遍。这避免了反复创建和销毁对象带来的 GC 抖动。部分静态几何体用 BufferGeometryUtils.mergeGeometries 合并减少了 draw call。这是正儿八经的游戏性能优化手法。截图对比下同一台机器上GLM5.3 版本的 JS 堆内存峰值大概在 95MBDeepSeek V4 Pro 只有 72MB差距就来自这些细节。4.3 运行实录能玩但过于规整然后说问题。我遇到的问题不是 Bug而是没意思。它把岛块的布局做成了完全对称的棋盘格四个方向路径一模一样跑一圈就没有探索欲望。收集物没有任何反馈特效拿到水晶只是右上角数字 1没有粒子、没有音效、没有镜头微震。障碍机器人只会匀速直线巡逻不会追玩家碰撞惩罚也只是一格血压力极低。还有一个实操上的坑因为它用了 ES Module 拆分文件直接双击 index.html 会触发浏览器的跨域限制根本跑不起来。必须本地起一个静态服务比如python -m http.server 8080才能玩。从工程师角度我理解它的选择但在拿一个原型随时发给别人看的场景下这一步很劝退。4.4 给 DeepSeek V4 Pro 的验收分完整性一项几乎满分工程化是三个里最高分可救性也很好——因为架构清晰我后来让它加功能、改特效都非常顺利。但可玩性/创意这一项我打了低分因为它把需求理解成了一个行政区划图所有东西各就各位但没有任何超出需求文档的情感设计。这就像一个工程能力 90 分的开发者被产品经理说你写的东西好用但不好玩。5. Step 5 Preview第一版翻车三次修完最上头5.1 第一版就给我来了个下马威Step 5 Preview 交卷最慢生成用了接近 7 分钟产出 890 行代码分成两个文件index.html game.js。我满怀期待地打开页面控制台一片红。三个错误全是能稳定复现的半透明对象渲染成纯黑块。它给水晶粒子系统用了自定义的混合材质但 shader 里 depthWrite 没关透明物体被遮挡的部分直接变成黑块。跳跃高度和帧率绑定。物理更新直接写在 requestAnimationFrame 回调里60Hz 和 120Hz 屏上的跳跃手感完全不同。粒子系统内存泄漏。每次收集水晶就scene.add(particleSystem)但从不 dispose 老对象。玩 5 分钟内存肉眼可见地往上爬。第一反应我是有点失望的毕竟前面两个模型至少第一版能跑。但既然是要评测可救性我决定把这三个问题原封不动地丢回去看它怎么修。5.2 修完之后游戏感的来源结果第二轮对话它全修对了而且修复质量比另外两个模型更到位。粒子泄漏那块它给出的修复逻辑是// 修复前直接追加新粒子系统旧的不释放 // scene.add(particleSystem); // 修复后先移除并释放旧的再重建 if (this.activeParticles) { this.activeParticles.geometry.dispose(); this.activeParticles.material.dispose(); scene.remove(this.activeParticles); } scene.add(particleSystem);修完之后这个版本成了三个里最有游戏感的。几个让我眼前一亮的细节天空色调会随时间缓慢变化从暖橙色渐变到冷紫色模拟日夜循环。水晶有脉冲发光动画通过 emissive 强度做正弦波动从远处就能被吸引过去。收集到水晶时不仅有粒子迸发镜头还会做一个极轻微的冲击感偏移手感立刻不一样了。玩家在空中按二段跳时脚下的残影粒子会留在原地短暂闪烁。这些细节没有一条写在需求文档里全是模型自己做出来的加法。这就是我说的产品思维——不是把需求翻译完就算了而是真的在思考玩家拿到这个东西会有什么感受。5.3 代码层面的差异化细节我看了一眼它的发光脉冲实现其实很简单const pulse Math.sin(elapsed * 0.15 this.seed) * 0.4 0.6; crystal.material.emissive.setHSL( (elapsed * 0.05 this.seed) % 1, 0.8, pulse * 0.4 );整个游戏没有用什么高级后处理就是这些十几行的小函数叠加起来产生了完全不同的观感。说白了AI 写代码到了这个阶段拼的不再是会不会调用 API而是有没有审美和场景想象力。5.4 给 Step 5 Preview 的验收分完整性一项略差在首版不可直接运行但修复后补回来可玩性/创意是三个里最高分工程化中等修完 Bug 后结构能接受但和 DeepSeek V4 Pro 的花园式架构还有距离可救性是这一轮给我的最大惊喜它不仅能修对还会顺手把关联的边界情况处理掉。总体是上限最高的选手但需要你愿意多聊两轮。6. 硬指标不会说谎三份产物的横向对照前面说了太多主观感受这节把数据摆出来。同一台 Mac mini M2 Pro、同一个 Chrome 无痕窗口、同样的测试脚本指标GLM5.3DeepSeek V4 ProStep 5 Preview生成耗时约 4.5 分钟约 5 分钟约 7 分钟代码行数741 行860 行890 行文件结构单 HTML5 个 JS 模块2 个文件双击打开即玩支持不支持需本地服务支持首帧加载耗时约 1.4 秒约 0.8 秒约 1.2 秒平均 FPS575558峰值内存约 95MB约 72MB约 90MB首版可玩程度直接可玩直接可玩需修复 3 处 Bug15 分钟后体感平稳但平淡平稳且规整有惊喜但小卡顿修复轮结束后体感中上中上最佳注意 FPS 和内存这一组DeepSeek V4 Pro 占了架构的便宜预创建对象加合并几何体内存就是低一截。但帧率差距没有明显拉开说明这种小场景对 WebGL 的压力本就有限架构优势更多体现在长时间运行和物品种类增多之后。首帧加载耗时上单文件内联的 GLM5.3 和 Step 5 Preview 反而比模块化方案更吃亏因为所有代码一把梭解析时间更长。不过差距不到 1 秒用户基本无感。这张表说明一个道理首版干不干净、架构好不好、玩法有没有趣是三件独立的事最少有两个模型在这三项上表现完全不同。7. 第二轮考核把 Bug 甩回给模型看谁改得对7.1 我构造的三个 Bug 用例以前测 AI 写代码大家只看生成质量但我一直觉得更关键的指标是遇到问题后能不能靠对话修好。所以游戏跑完第一轮之后我把实测中遇到的共性问题整理成三个 Bug 单轮流发给三个模型Bug A阴影痤疮。地面在特定视角下出现条纹闪烁请定位并修复。Bug B高速穿越障碍。冲刺状态下偶尔穿过大障碍物侧面如何修正判定。Bug C重启后状态残留。重新开始游戏后镜头初始位置偏移旧粒子未完全清除。7.2 各模型修复表现修复情况GLM5.3DeepSeek V4 ProStep 5 PreviewBug A 阴影痤疮2 轮修对改 bias原版无此问题1 轮修对并加接触阴影配置Bug B 高速穿透只放大碰撞半径治标原版用固定步长物理基本无此问题1 轮用 raycast 扫掠检测修得彻底Bug C 重启残留1 轮修对原版状态机重置完整1 轮修对但粒子清理多了一帧延迟是否引入新 Bug否否引入一个小延迟但可接受这个表的信息量很大。DeepSeek V4 Pro 因为架构扎实很多 Bug 在源头上就不存在但它不会主动告诉你这些你得自己发现原来它没有这个问题。GLM5.3 和 Step 5 Preview 则完全不同它们更像和你并肩作战的队友你会经历从报 Bug、看它修、再验证的完整协作过程。7.3 对可救性的领悟做完这轮修复我对选模型这件事的理解变了。以前我觉得生成质量是第一位现在我觉得可救性的权重被低估了——因为没有任何模型能一次写对大型项目真正决定项目命脉的是你丢 Bug 给它之后它能否在几轮对话内正确定位根因并且不引入新问题。这三个模型都具备基础的可救性但修复思路上有区别GLM5.3 偏向最小改动DeepSeek V4 Pro 偏向架构兜底Step 5 Preview 偏向把边界情况一起处理干净。没有谁绝对更好取决于你是哪种开发者。8. 从擂台回到日常选型我的一些备忘8.1 什么场景选谁这三场跑完不是去争谁最强而是沉淀了一套选型法则分享给你们快速原型、需要马上发给别人双击即玩的GLM5.3 最省心单文件方案天然适合分享。正经项目、后续要长期维护的DeepSeek V4 Pro 的模块化和状态机会帮你少踩很多管理上的坑。做游戏、做创意类 demo、在意手感和情绪反馈的Step 5 Preview 值得你先接受第一版的 Bug再通过两三轮对话把它打磨成上限最高的产物。如果你在团队里负责技术选型我的建议是不要只看一两次生成结果一定预留 30 分钟做一轮Bug 修复压力测试用你们项目的真实报错去试它。8.2 GLM5.3 本地部署vllm 镜像版本怎么选最近社区里很多人问 GLM5.3 本地部署该用 vllm 哪个版本的镜像我这次也顺手测了一轮。结论是优先用 vllm 官方仓库最新 release 分支对应的镜像以官方模型注册表里 GLM5.3 的配置文件为准不要擅自套用 GLM 旧版的 config。老版本的 vllm 镜像0.6、0.7 系列在跑新版模型时最容易爆的是 KV cache 兼容性报错和 tokenizer 的 stop token 列表不匹配。如果坚持用 Docker 部署推荐vllm/vllm-openai镜像并锁到一个明确支持新架构的 release tag别用 latest 裸标签图省事。8.3 捎带跑的 doubao-seed-2.0-code 代码填空写这篇实测期间正好看到热搜上把 doubao-seed-2.0-code 和 GLM5.3 放在一起比我也在一个补全游戏主循环缺失物理更新的填空任务上试了它一下。doubao-seed-2.0-code 在代码补全/填充中间FIM这类场景表现很亮眼尤其适合你在已有代码骨架里让它补一个函数它给出来的实现几乎不用改。但让它从零独立规划整个 3D 项目架构感和 GLM5.3 这类通用对话模型比还是有一定差距。这其实也是各模型的定位差异代码补全模型和全栈对话模型不是同一个工种。8.4 安卓壳让三份产物都变成可安装的 APK最后聊聊很多人关心的开源安卓 3D 游戏落地方案。三份产物都是纯 WebGL 页面理论上随便套个 WebView 就能打包成安卓应用。我实测用的是 Capacitor 做壳流程很简单把 HTML/CSS/JS 放进项目的 www 目录跑npx cap add android然后用 Android Studio 出包。有几个坑提前提醒你们Android 的 WebView 必须开硬件加速AndroidManifest.xml里给 activity 加android:hardwareAcceleratedtrue否则 Three.js 的帧率会掉到没法玩。桌面版的 Pointer Lock用鼠标控制视角在触屏上基本失效做好手感适配让 Step 5 Preview 版本的水晶收集逻辑里把 WASD 换成虚拟摇杆或点击移动。不同厂家的安卓 WebView 内核版本差异很大建议先锁定android.webkit.WebView的最低版本 API 级别不然低端机上 Shader 编译可能崩。打包之后GLM5.3 版本体积约 1.4MBDeepSeek V4 Pro 约 2.1MB因为拆了多个文件Step 5 Preview 约 1.8MB都不算大。如果你想要一个开源可复制的模板用 Capacitor 套任意 Three.js 页面这套路子是走得通的。最后说一点个人体会。这次实测跑完之后我再也不迷信任何单一维度的榜单了。模型选择这件事本质上是场景匹配不是排名崇拜。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 各有各的脾气你在不同阶段、不同需求下需要的是不同的队友。我会把这轮测试沉淀成一套固定动作先让模型生成再花半小时喂 Bug最后才决定要不要录用它。这个过程本身比任何跑分都能告诉你谁值得信任。
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑