你们有没有过这种体验用大模型写代码写出来的东西看起来很强一跑起来全是坑。我最近把 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 拉到同一张考桌前让它们用完全相同的提示词各自写一个基于 Three.js 的3D跑酷游戏然后我一个个在浏览器里试玩、改bug、加功能。这篇文章就是完整的实测记录。它不是一个哪个模型更聪明的排行榜而是一篇关于用大模型做3D小游戏时哪些地方会让你血压升高哪些地方又能让你真香的经验贴。如果你想复现准备一个本地静态服务器、一个浏览器、三个模型的API额度就够了不用搭复杂的工程环境。1. 为什么拿3D小游戏当考题跑分之外的硬核测试1.1 跑分高不等于成品能跑先说明我这个测试的思路。AI模型的评测经常是拿几道算法题或者一段代码补全任务来打分这些题能测出模型的单点能力但测不出把一个东西做完的能力。真实项目里代码不是孤立的一段函数它包含模块怎么拆、状态怎么管理、资源怎么回收、边界情况怎么兜底、UI交互怎么接。这些能力在算法题里几乎完全看不出来。3D小游戏刚好把这些问题全压在一个HTML文件里。用户的需求可以一句话说完但背后有太多隐性工作物理模拟、碰撞检测、事件循环、相机控制、移动端触屏、性能优化。一个模型如果只是代码能力强写出来的大概率是能运行但不好玩的东西如果它有产品意识它会主动把难度曲线、反馈手感、结束重开流程都补齐。这就是我选这个题目的核心原因。1.2 为什么选Three.js而不是Unity或Godot有人可能会问现在做3D游戏不都用Unity吗确实Unity的C#生成也是热门方向但这次我刻意选了Three.js加原生JavaScript原因有三第一Three.js是开源生态模型训练数据足够多不容易翻车第二一个HTML文件直接可以在浏览器里跑复现成本最低不需要装编辑器第三WebGL的性能敏感度能顺便测出模型对性能优化的理解。至于开源安卓3D游戏那个方向我后面单独用一整节来写因为从网页小游戏到安卓APK之间那段路恰恰是AI最容易迷路的地方。1.3 我在测试里固定的环境和评分维度测试环境说清楚方便大家复现对比MacBook Pro M116G内存Chrome保持最新稳定版Three.js统一用CDN上的 r158 版本本地静态服务器托管。三个模型我都用Web端或者API手动提交同一份提示词不额外调temperature之类的参数尽量减少变量。评分维度我固定了六个首版能否直接运行、代码结构是否清晰、玩起来手感如何、边界逻辑是否健壮比如重开、连续跳跃、性能能否稳定60帧、迭代修改时能不能准确改对地方。下面每一章都会围绕其中几项展开。2. 题目和提示词怎么设计一份能测出差距的考题2.1 我最终使用的提示词全文先把我用的提示词放出来这是整个实验最核心的复现依据请用Three.js版本r158写一个3D跑酷游戏全部代码放在一个HTML文件里通过本地静态服务器运行即可。1. 玩家是一个彩色方块在无限延伸的跑道上自动向前跑。2. 跑道上随机生成障碍物玩家通过左右移动键盘A/D或左右方向键和跳跃空格键躲避。3. 跑道上随机出现金色小方块收集后得分得分显示在左上角。4. 碰到障碍物游戏结束显示最终得分和重新开始按钮。5. 支持手机浏览器触屏操作左右滑动控制移动上滑跳跃。6. 使用低多边形/简洁几何风格颜色和光影要舒服。7. 代码要有清晰注释把重力、移动速度、障碍物生成间隔等参数集中到文件头部配置区。我刻意没说要销毁跑道块碰撞箱要缩小二段跳后要重置垂直速度这些细节因为我想看模型自己能不能想到工程化的问题。用户给需求的时候通常不会说得那么细这才是真实的使用场景。2.2 提示词里藏着的隐性考点顺着这份提示词说几个模型容易忽略的点这也是后面差距拉开的真正原因无限延伸的跑道这个词很模糊。有经验的开发者会想到动态创建和销毁跑道的分段否则跑几分钟后内存就会爆掉。三个模型里只有 Step 5 Preview 和 DeepSeek V4 Pro 真的做了分段回收GLM5.3 直接把所有跑道块一次性铺满可视区域再用一个看起来像无限的伪循环前后挪动整体位置。视觉效果能骗过眼睛代码上却给后期加功能埋了大雷。随机出现障碍物好的做法是生成时检查玩家正前方的可通行空档避免连续堵死。这一项 DeepSeek V4 Pro 做得最好它在生成间隔上加了随机余量GLM5.3 的随机是每隔固定时间随机摆一个障碍物有时会连续两三个堆在一起形成无法通过的死局。重新开始按钮这是状态管理的照妖镜。很多模型只在UI上加了按钮但忘记把分数、障碍物列表、动画循环整体重置。实测里 Step 5 Preview 重开之后跑道和障碍物没有清干净DeepSeek V4 Pro 做得最完整GLM5.3 直接把按钮写成一个不绑事件的装饰。支持触屏如果模型只顾着加事件监听不考虑 touchmove 与 click 冲突手机上一玩就一卡一卡。DeepSeek V4 Pro 用了 touchstart 记录坐标、在 touchmove 里取位移差GLM5.3 只是简单绑了 touchstart 执行一次跳跃导致上滑动作偶尔不触发。2.3 从需求清单能看出三个模型的产品人格首轮写代码之前我先让每个模型输出一份需求拆解清单这一段很能看出思维习惯。Step 5 Preview 给了一份特别工整的清单分成核心对象游戏循环输入处理渲染优化异常边界五类每条需求都对应一个方向甚至写上了需考虑移动端触摸事件兼容。这种结构化输出的风格后来在它的代码里也延续了变量命名和函数拆分都相当规范。DeepSeek V4 Pro 没有输出清单直接给代码但在代码开头注释写了实现说明把主循环、碰撞、计分、触屏的职责标注清楚。它属于目标感特别强的类型不喜欢中间过程直接给你能跑的结果。GLM5.3 的输出最天马行空它在代码前先写了一段设计思路提到想加入夜晚赛博朋克风格和光柱特效。最后真的加了但只在视觉上加逻辑没跟上这一点后面会反复出现。3. 首轮生成对比谁的代码像一个游戏3.1 Step 5 Preview标准答案式的代码手感却输了Step 5 Preview 第一版代码的结构是最像标准答案的。打开HTML文件一眼就能看到它的 CONFIG 配置区重力、跳跃初速度、移动加速度、障碍间隔时间全部以对象形式集中在一起。代码里还有清晰的段落注释一个函数只干一件事比如 createPlayer、createObstacle、updatePhysics、checkGameOver。这确实符合提示词里参数集中和注释清晰的要求。但一上手玩问题就出来了。它的跳跃高度太高、下落时间长方块跳起来像在月球上需要非常精确地算准落地窗口才能躲过障碍。我看了参数gravity 是 -9.8jumpVelocity 是 8。按物理公式算滞空时间大约 1.6 秒对一个跑酷游戏来说太长了。模型选择了符合现实物理的常数却没有选择符合游戏手感的数据。这是一个典型的代码正确但体验不对的例子。另一个小问题是障碍物生成时间被固定为每两秒一次非常规律玩家玩十秒就能背板后面无脑按节奏跳就能过关。3.2 DeepSeek V4 Pro完成度最高代码却最一锅粥DeepSeek V4 Pro 的第一版完成度最高。它有完整的碰撞检测Box3 相交检测、分数计算、游戏结束界面还自己加了一个速度随分数增加的机制——跑得越久跑道和障碍物的移动越快这是三个版本里独一份的。可以说它一开始就想到了游戏需要难度曲线这是真正的产品思维。不过它的代码风格非常一次性。整个 update 函数从相机更新写到障碍物生成、碰撞检测、UI刷新密密麻麻两百多行。变量名也比较随意有的叫 a有的叫 playerBox混在一起。我要加二段跳时第一反应是从哪里下手。它属于功能没问题、后续维护想打人的类型。3.3 GLM5.3画面最有氛围逻辑却漏了最关键的一环GLM5.3 这一版打开之后是最抢眼的背景是深蓝到紫的渐变天空一条黄色跑道灯带在两旁延伸还飘着几个自转的光球。它甚至给角色做了发射尾焰的粒子效果虽然代码只是每秒生成一堆半透明平面但在首轮里已经足够让另外两个版本显得有点素。可问题恰恰出在这套华丽效果里。它的游戏结束逻辑只改了 state.gameover 这个标志位但主循环的 update 函数开头没有判断这个标志导致画面显示 Game Over 后游戏角色还在继续往前跑、分数还在继续涨。代码里游戏状态分散在好几个回调函数中没有统一的状态机。视觉效果再华丽这个致命伤也让它的首版体验垫了底。3.4 首轮横向记录四个维度的速览表维度Step 5 PreviewDeepSeek V4 ProGLM5.3首版可直接运行是是是功能完整度7/10缺重开细节9/10含难度曲线8/10特效多但状态混乱代码可维护性9/10模块化最好5/10主函数过长6/10状态分散实际可玩性跳跃太飘节奏单调手感均衡有渐进难度特效惊喜逻辑卡顿画面表现常规朴素最佳4. 玩起来才是真差距手感、性能和反馈的细节账4.1 物理参数背后的手感秘密首轮试玩时我重点看三个模型的物理参数。把三组数据放一起Step 5 Preview 的 gravity 是 -9.8、jumpVelocity 是 8滞空约 1.63 秒偏月球跳跃DeepSeek V4 Pro 的 gravity 是 -14、jumpVelocity 是 6.5滞空约 0.93 秒节奏偏快接近主流跑酷游戏的手感GLM5.3 的 gravity 是 -12、jumpVelocity 是 7滞空约 1.17 秒看起来合理但它把移动加速度设成了固定值没有乘时间增量 delta导致帧率波动时玩家左右移动速度忽快忽慢。这个细节特别能说明模型对游戏的理解深度。重力、跳跃初速度、帧无关的移动逻辑只要有一个偏离游戏手感的直觉玩家一上手就能感觉到。三个模型里 DeepSeek V4 Pro 的数值最接近主流平台跳跃游戏Step 5 Preview 老实套了经典物理公式GLM5.3 是参数选对了一半但实现方式错了。要调这些参数只能靠人来试玩模型很难推理出-9.8 是牛顿世界的地球重力不是游戏世界的手感重力。4.2 帧率实测GLM5.3 的画面是拿性能换的我用一个简单的帧率统计脚本在 M1 上测了三个版本的 FPS方式是在 requestAnimationFrame 里记录每秒帧数跑 5 分钟取平均let frames 0, lastTime performance.now(); function loop() { frames; const now performance.now(); if (now - lastTime 1000) { console.log(frames); frames 0; lastTime now; } requestAnimationFrame(loop); } requestAnimationFrame(loop);结果很直观。Step 5 Preview 长期稳定在 60fps因为它的障碍物和跑道段数非常少且定时回收。DeepSeek V4 Pro 也在 60fps 附近但运行三分钟后偶有掉帧原因是每段跑道会新建一个 Mesh量不大累积到几十个后垃圾回收压力上升。GLM5.3 平均只有 30fps 左右运行五分钟后风扇已经明显工作。它在场景里放了 4 个点光源和几十个带独立材质的装饰物体收益是画面好看代价是 WebGL 的 draw call 数量暴涨。从性能优化意识来看Step 5 Preview 最有自觉性它主动把相同外观的障碍物做成共享材质DeepSeek V4 Pro 没有优化但代码量小所以问题不致命GLM5.3 几乎没有性能意识注意力全在视觉效果上。4.3 从能玩到可玩开始、结束和重开之间的细节首轮对比里我特意留意了三个版本的游戏界面细节开始画面、结束弹窗、重新开始。Step 5 Preview 是唯一没有开始画面的版本。页面一加载角色就开始跑玩家要立刻反应。Game Over 后也没有重开按钮只能刷新页面。作为代码最工整的版本这个体验反而最原始说明模型把重心放在了内部结构忽略了玩家进入游戏的第一个入口。DeepSeek V4 Pro 把开始、结束、计分、最高分一条龙做全了重开按钮能正常清理障碍物和分数是唯一一个我不用刷新页面就能连续玩三轮的版本。GLM5.3 也有重开按钮但点击之后分数清零了之前的障碍物和装饰物全留在场景里新跑道又叠一层连续玩三轮后画面里挤满了重叠的方块。根源和游戏结束没取消循环一样都是状态没有彻底重置。5. 三轮BattleDebug和迭代功能才是试金石5.1 第一回合我故意把碰撞检测改成永远不死在三个首版基础上我做了个控制变量的实验。拿 DeepSeek V4 Pro 的版本把碰撞检测函数 checkCollision 改成固定返回 false角色永远死不了然后分别让三个模型看这段代码并修复。我想测试的是它们面对一份不是自己写的、还被明显破坏过的代码时能否快速定位。Step 5 Preview 的表现最像代码审查员。它直接复述出碰撞检测被改成了无条件返回 false给出正确修正还额外提醒我障碍物移除逻辑也要一起检查。这个回答说明它对代码库的阅读是全面的能抓住症状和连带影响。DeepSeek V4 Pro 的回答让我有点意外它先列了三个可能原因事件监听没绑定、碰撞函数没被调用、障碍物没加入场景。在我追问先看 checkCollision 函数本身之后它才指出那里返回了 false。它在 Debug 时倾向于从全局发散而不是先走近路看局部嫌疑点。GLM5.3 给出的修复方式是把碰撞检测从事件回调挪到 render 循环里每帧执行。它能检测到碰撞没生效但没意识到问题不在这段代码的执行位置而是函数返回值被改了。它属于能发现问题、归因跑偏的类型。这个测试略微反常识因为真实 Debug 更多是面对未知 bug不是面对被人故意改坏的代码。但它能说明模型有没有耐心一行行读代码非常影响排查效率。5.2 第二回合给三个版本加二段跳这次需求是在跳跃中再按一次空格或手机上滑可执行二段跳二段跳只允许一次落地后重置。Step 5 Preview 交出的实现是标准答案级别的。它把角色状态拆成 GROUND、JUMP、DOUBLE_JUMP 三个枚举在每次跳跃时修正 velocity.y落地检测里把二段跳机会重置。代码没有多余修改加个注释就能合并进原工程。DeepSeek V4 Pro 用了一个布尔变量 isDoubleJumped第一次测试出现了一个 bug二段跳后角色不会下落因为它在执行二段跳时把 velocity.y 设成正的大值而重力计算那行用的还是旧值叠加后垂直速度一直为正。让我重试后它自己修正了。它的特点是方向对细节容易打架。GLM5.3 的实现最简单但效果也最奇怪。它在每次跳段跳时都直接给一个固定高度不管角色当前下落速度导致刚起跳就二段跳和掉到半空再二段跳的滞空高度一模一样物理上很不自然。它忽略了当前垂直速度作为二段跳初始条件这层叠加关系。5.3 第三回合让三个模型把首版优化到稳定60帧指令是请优化首版代码让它在常规浏览器里稳定达到或接近60fps。Step 5 Preview 的方案不是简单改参数而是给出一套性能预算思路把多个相同障碍物合并成单个 BufferGeometry 批量绘制减少 draw call把原来的点光源改成半球光加平行光的组合减少光照计算加对象池复用跑道分段。这已经接近专业前端性能优化的方法论。DeepSeek V4 Pro 的优化更务实一眼看出原版跑道块不会回收的内存问题建议把碰撞检测从 Box3 改成基于距离的判断因为两个近似正方体的碰撞可以用中心距离近似。它没给完整代码但建议都落在关键点上。GLM5.3 的方案最简单粗暴把粒子效果关掉阴影贴图尺寸从 2048 降到 1024。它对自己代码里的视觉负担很清楚但解决方式属于功能开关没有触及根本的渲染优化。5.4 三个回合之后的模型画像三轮测下来我给三个模型画了像Step 5 Preview 是典型的代码审查员适合让它看完整代码、找问题、出结构优化方案DeepSeek V4 Pro 是产品经理型程序员适合从零搭一个完整可玩的东西但代码要接受它偶尔打架的细节GLM5.3 是视觉设计师型选手负责把画面做好看但你要给它配一个靠谱的逻辑接口人。还有一个很关键的观察当 HTML 文件超过 600 行后三个模型都出现了读不到后面变量的迹象。最直接的表现是我让它们修改文件末尾的 UI 逻辑时它们会先说几个早已不存在的变量名。遇到这种情况我的处理习惯是把相关代码块截出来单独喂给模型而不是整份丢进去。长上下文的极限不管宣传参数多大实际用起来都要小心。6. 从网页小游戏到安卓APK打包和部署的真实门槛6.1 为什么我不让AI直接写安卓原生3D游戏前阵子开源安卓3D游戏这个方向很热我也顺手试了一轮。结论是让任何模型直接生成 Android 原生 OpenGL ES 游戏目前都不太现实。因为那需要跨 Java、XML、Gradle、资源文件等多个文件协同模型生成单文件网页的能力没法迁移到多文件工程里。最可靠的路径仍然是让 AI 先生成网页版 Three.js 游戏再通过 Capacitor 之类方案包一层原生壳变成 APK。这个过程中最让我意外的是模型对 Capacitor 配置的生成能力非常弱。DeepSeek V4 Pro 生成的配置少了一个允许明文流量的字段导致 APK 里加载本地资源时白屏我看到控制台报 Cleartext HTTP traffic not permitted 才反应过来。GLM5.3 更绝生成的配置里的版本号写得比项目中实际 SDK 版本还高Gradle 直接报依赖冲突。Step 5 Preview 在打包配置上的表现也不够好它更擅长前端代码移动端工程文件属于知识盲区。所以AI 可以用来生成安卓3D游戏的核心玩法代码但 AndroidManifest、Gradle、证书、签名这些工序自己动手过的坑比 AI 更可靠。6.2 GLM5.3 本地部署时 vLLM 镜像版本怎么选顺带说一个和 GLM5.3 这个模型相关的实操问题不少人在问GLM5.3 使用 vLLM 哪个版本的镜像。我最近自己搭过一次离线环境把经验放在这里。如果要本地起一个 GLM5.3 服务来跑生成任务推荐用 vllm/vllm-openai 这个官方 Docker 镜像并且优先选较新的稳定版 tag。从实测看版本太老会在加载模型时直接报 Unsupported model 类型。选型时注意三点第一镜像版本和 CUDA 驱动版本要匹配镜像会自带依赖但宿主机的 nvidia-driver 必须足够新否则容器里报 CUDA init failed第二如果要同时支持文本和视觉输入选带 multimodal 支持的镜像 tag不要选精简版第三显存方面量化后的中等规模模型在 24GB 显卡上可以跑非量化的大参数版本建议上更大显存的卡。启动命令大致是vllm serve THUDM/glm-5.3-chat --dtype auto --served-model-name glm5.3如果加载阶段出现算子不支持的报错第一优先检查镜像版本而不是权重八成是版本差半代的问题。模型权重从官方渠道下载之后记得把路径和模型文件名写成 vLLM 能识别的格式大小写不对也会直接报文件不存在。6.3 模型组合使用的一个建议实测完这三家我现在的习惯是组合使用先用 DeepSeek V4 Pro 把功能骨架快速搭起来再交一份请帮我做视觉增强的任务给 GLM5.3最后由 Step 5 Preview 通读代码做一轮结构审查和注释补全。这样三个模型的优势都能用上也把各自的短板互相补掉。如果你的目标就是做一个能放进手机里的 3D 小游戏同样建议把生成游戏逻辑和生成打包配置分开对待打包部分自己控制最稳。还有人问过 doubao-seed-2.0-code 这类代码模型怎么选我的看法是它的代码补全效率和整项目生成能力是两个维度前者代表单点速度后者才决定你能不能把一个小游戏真正做完。7. 最终结论赢家不是某个模型而是一套分工方式7.1 这次实测里各家的真实名次严格按不同标准来三个模型各有第一名按首版打开就能玩得挺开心DeepSeek V4 Pro 赢它在功能完整度、难度曲线、重开流程这些最影响体验的点上都做得最全虽然代码丑但不是玩家关心的问题按代码结构最像正经工程Step 5 Preview 赢它是唯一一个我能直接拿去写单元测试、加功能不加出毛病的版本按画面一眼惊艳GLM5.3 赢氛围、光照、小特效都很到位但它也是唯一一个首版就出现游戏结束界面还在动这种逻辑硬伤的模型。如果把标准换成谁能长期陪我把一个小作品打磨到能分发出去我目前的答案是主程用 DeepSeek V4 Proreview 用 Step 5 Preview视觉外援找 GLM5.3。这个组合不完美但胜在稳定。7.2 我实操之后最想分享的四条经验写到最后把这次踩出来的经验直接列出来第一提示词里的工程细节越具体模型的下限越高。第一版我只给了无限跑道三个模型对无限的处理完全不同。第二次把分段生成、回收、坐标复用写进提示词后连 GLM5.3 都能给出正确的跑道管理代码。第二分步生成比一次性生成整个游戏成功率高太多。同一款 3D 游戏一次性让模型写完整 HTML三家里有两家出了明显问题改成先写场景和角色再写移动逻辑再写碰撞和 UI之后即使 GLM5.3 也没有出现状态混乱。第三报错信息一定要单独摘出来问不要整份代码丢给模型。超过 600 行后模型对文件后部的变量和函数经常失忆把报错行和附近几十行贴上去定位准确率会高非常多。第四不要相信模型首版就是成品。三个首版都有明显问题但每一家在我给出具体反馈后都能修正到可玩程度。做 3D 小游戏也好做别的工程也好至少预留两轮迭代的时间和预算才能真正发挥大模型的生产力。这次测试做完我对大模型写 3D 游戏这件事的态度是它能降低起步门槛但做不出设计感。真正的游戏手感、难度曲线、状态管理还是需要人来一点点调。这篇文章的结论基于我这次实测如果你也拿同一份提示词去跑结果可能会随版本更新略有不同但测试方法可以反复用。建议你也试试把三个模型生成的代码截图放一起对比一定很有意思。