最近身边好些做独立游戏、做原型验证的朋友都在问同一个问题想让AI直接帮忙写一个能跑的3D小游戏到底用哪个模型合适。与其盯着厂商发的benchmark不如自己动手实测一次。于是我从当前热度最高的几个模型里挑了三个——Step 5 Preview、DeepSeek V4 Pro、GLM5.3给它们出了完全相同的一道题做一个基于浏览器的第三人称3D平台跳跃小游戏。这篇就是完整的实测记录包括需求Prompt怎么设计、三个模型各自生成的过程、最后跑起来的效果差异以及我自托管GLM5.3时踩到的vLLM镜像版本坑。想用AI做游戏原型或者只是想判断哪个模型更适合写复杂代码的朋友可以直接对号入座。1. 为什么拿“3D游戏”当考题评测思路与工具选型1.1 三个参赛者的基本盘我先说结论性的背景判断。Step 5 Preview是Preview版本主打的优势是长任务规划能力适合一次性生成大块代码DeepSeek V4 Pro在我之前的认知里属于“稳”的类型逻辑推理扎实代码生成偏工程化GLM5.3则在中英文混合语义理解上有明显特长给它中文需求基本不用二次解释。为了不把评测视野搞得太窄我同样拉了doubao-seed-2.0-code做场外对照但主标题只评前三家所以它不算正式参赛者后面提到它也就是顺带一句。之所以选这三家做横向对比是因为它们代表了三种不同的“性格”。Step 5 Preview像那个天分很高但有点毛躁的年轻同事第一次上手特别惊艳改到后面容易把地盘搞乱DeepSeek V4 Pro更像团队里的资深工程师写出来的东西不花哨但你敢在它基础上反复迭代GLM5.3的风格则更像开源项目维护者给出的是“带TODO的框架”对接真实工程很舒服。这些性格差异不跑一次复杂任务根本看不出来。1.2 技术栈选择为什么是 Three.js 而不是 Unity我不选Unity或Cocos最核心的原因是“可复现性”。Unity场景、材质、物理组件这些大量资产是存在编辑器里的AI生成的C#脚本没法脱离编辑器直接观测评测环境太重。而Three.js是纯代码驱动配Vite构建一个浏览器就能跑AI生成完我直接npm run dev就能看到结果。对评测模型的代码生成能力来说这种轻量闭环太重要了。另一个原因是3D游戏本身对代码质量非常敏感。坐标变换、相机控制、碰撞检测、状态切换、资源加载这些模块只要有一个环节出错游戏就会白屏、穿模或者物理塌陷。普通业务代码里很多bug能被框架兜住但3D游戏几乎没有兜底模型写错了就是写错了一眼就能暴露。这比用CRUD接口来评测模型要严苛得多也更能反映真实水平。1.3 我用来打分的四个维度正式开工之前我先定了一套自己的评分维度避免“凭感觉说谁好”。功能完成度游戏能不能跑核心玩法是否完整边界情况有没有处理。代码可维护性文件拆分是否合理模块边界是否清楚变量命名是否可读。迭代成本我提一个新的玩法修改意见它改动一次需要多久会不会引入新bug。运行表现帧率是否稳定场景复杂度与性能是否平衡。这四个维度里我最看重“迭代成本”。因为AI写代码不是一次交付就结束的真实项目里九成时间都在改需求。一个模型首仓代码写得再漂亮后续一改就崩那它在实际项目里就不及格。这个权重思路也贯穿了整篇实测。2. 一份能看出水平的题目Prompt 设计与统一约束2.1 需求描述里必须带上的六个要素很多人的AI写游戏失败问题不在模型而在需求描述太模糊。“帮我写个3D跑酷游戏”这种话神仙模型也只能自由发挥最后生成的结果跟你的预期完全对不上。我自己总结下来一份能看出模型真实水平的需求描述至少要包含六个要素目标场景、玩法规则、交互方式、技术栈、资源约束、兜底行为。缺了任何一个模型都会在对应环节自作主张。这次我出的题目是一个第三人称3D平台跳跃游戏玩家在高低错落的平台间跳跃前进到达终点旗帜获胜。交互是WASD移动、空格跳跃、Shift加速相机跟随且不能穿墙。所有资源都用几何体加材质现场生成不依赖外部模型文件确保无网络也能运行。技术栈限定为原生Three.js加Vite并且明确不用外部物理引擎碰撞检测用手动AABB或包围球实现。2.2 分阶段生成为什么不能一句话甩给模型这里是我踩过一次坑之后才改的习惯。早期我图省事把整套需求一次性丢给模型结果三家模型都倾向于生成一个五六百行的单页面文件场景、角色、碰撞、UI全堆在全局作用域里。后续任何一个小改动都会牵一发动全身比如想把跳跃力从8改成7它会把重力、碰撞容差、甚至相机跟随系数一起改掉相当头疼。所以这次我改用“分阶段生成”的策略先让模型把地基打好再一层层往上加需求。第一阶段只做静态场景加角色移动第二阶段加敌人和胜利条件第三阶段改手感优化和UI界面。每阶段生成完我都亲自跑一遍验收通过再进入下一阶段。这样做有三个好处一是每个阶段出bug能精确定位到是哪家模型哪一批代码的问题二是避免模型在长任务里出现“前面正常后面失忆”的状态失控三是能让三家的代码结构差异更清楚地暴露出来。2.3 我一字不改的统一输入长这样为了保证公平三个模型收到的Prompt完全一致一字不改请你用 Three.js 实现一个第三人称3D平台跳跃小游戏 1. 场景多个高低错落的平台散布障碍物背景使用渐变天空。 2. 玩法玩家控制角色在平台间跳跃前进到达终点旗帜触发胜利界面碰到障碍或掉落平台则扣1点生命生命归零触发失败界面。 3. 交互WASD移动空格跳跃Shift加速相机跟随角色保持第三人称视角不能穿墙。 4. 技术栈原生 Three.js Vite不使用外部物理引擎碰撞检测用手动AABB或包围球。 5. 资源地面、角色、障碍物全部用几何体加材质生成不依赖外部模型文件。 6. 约束角色速度5 m/s跳跃初速度8 m/s重力20 m/s²碰撞半径0.5跳跃缓冲0.15秒角色掉出世界后重置到出生点。这份需求里最关键的其实是最后一条“硬参数”。如果说玩法描述是出题那这些物理参数就是评分标准。参数定得越死三家模型发挥空间的差异就越小最后对比代码调试思路时才能看出真正的差距。实际生成过程中我也验证了这一点同一套参数下三家对“跳跃缓冲0.15秒”的实现方式完全不同这部分后面展开讲。3. 三台机器的现场实录从生成到跑通3.1 Step 5 Preview第一版惊艳第三版翻车Step 5 Preview第一轮输出的效率确实高。我的需求文本刚提交大约三十多秒后它就返回了一个完整的单文件实现里面包含了GameManager类、角色控制器、平台生成逻辑和一整套雾效粒子效果。我几乎没改任何东西就把它跑起来了画面观感是三家里最好的天空渐变细腻平台上有淡淡的粒子飘动角色落地还有轻微灰尘效果。这种“一眼惊艳”的体验确实很能打动人。但问题出现在后续迭代上。我在第二阶段要求加入跳跃缓冲它直接在update循环里连续替换了三处逻辑结果把条件判断写反了角色按空格就会原地无限腾空。我继续要求“相机平滑跟随”它又一次大范围重写相机模块把y轴方向补了个负号视角直接翻转。最麻烦的是因为它把整个游戏封装在一个巨大的状态闭包里我在调试器里根本没法快速定位是哪一段代码出了问题。整个排错过程耗了我二十分钟。这一步的教训非常明显Step 5 Preview适合从零到六十的快速开荒但不适合连续不断的大改。用它的正确姿势是高频提交每次只让它改一个函数改完立刻保存迭代结果不要给它一口气改三个需求的自由度。测试下来只要控制好修改粒度它的输出质量能稳定很多。3.2 DeepSeek V4 Pro不炫技但改起来最省心DeepSeek V4 Pro的流程体验从第一轮就不太一样。我提交需求之后它没有直接生成代码而是先反问了一个问题“视角是第三人称固定角度还是跟随旋转跳跃触发方式是按键还是可配置”这个问题问得相当专业说明它在动手之前会先做需求澄清。实际开发中很多返工就是因为需求歧义它愿意先问清楚再动手本身就帮我省了一轮沟通成本。它生成的代码结构也明显更工程化自动拆分了input.js、physics.js、renderer.js三个模块文件边界非常清楚。第一版跑起来之后画面观感比较朴素就是一个灰色平台、一个方块角色、一片背景色没有Step 5那种视觉冲击力但帧率极其稳定。我在Chrome的Performance面板里观察了五分钟几乎没有任何掉帧。后续迭代跟我预期的一样顺。要求加跳跃缓冲它只动了physics.js里的一个常量要求相机拉近防穿墙它没有粗暴地关闭碰撞而是改成相机靠近角色背后并增加插值平滑从视觉上规避了穿墙。这就是模块化的价值。唯一的问题是它对几何碰撞的精度处理太粗角色站在平台边缘会出现轻微抖动但这个病根在physics模块里我调了一下容差值就解决了。3.3 GLM5.3中文理解天花板工程链也最真实GLM5.3在三家里显得比较特别。它最强的点是中文描述到代码参数的转译能力。我在第三阶段追加需求时写了一句“跳跃要带一点惯性像马里奥那样”它直接给了一段大约三十行的摩擦力处理函数不需要我解释什么是惯性、怎么换算成帧率无关的加速度说明它对中文口语描述的语义抽取做得相当好。但它的首仓输出风格跟其他两家差异很大。它生成的代码里大量使用占位接口资源加载、粒子特效、胜利结算UI统统留好了函数签名但函数体里只有一个“TODO”注释。对习惯看完整效果的新手来说这个输出可能显得“不够炫”但从工程角度看这反而是最专业的做法——真实项目里本来就应该先把接口契约定清楚再填具体实现而不是把所有东西强行写成一大坨阻塞代码。还有一个绕不开的部署问题。我本来想用vLLM把GLM5.3拉起来跑后续的迭代提示词结果模型加载阶段直接报错崩溃。这个坑跟镜像版本强相关细节我会放到第5节专门展开。如果使用官方API则完全没有这个问题但自托管场景下版本兼容性必须提前确认。4. 成品对比代码结构、运行表现与可维护性4.1 跑起来之后的直接观感三个版本跑起来之后给人的第一印象差异非常大。Step 5 Preview的版本像是一个“演示片”雾效、粒子、渐变天空都有视觉上最接近商店里的Demo效果。DeepSeek V4 Pro的版本像是个“原型骨架”界面朴素到只有最基本的几何体和纯色背景但胜在运行最稳摄像头转动、角色跳跃都没有卡顿感。GLM5.3的版本则像“丢了美术资源的半成品”界面也比较简单但代码结构上留出了资源接入点后面塞模型贴图进去就能直接替换。如果在没有后续维护需求的前提下评“哪个最惊艳”那一定是Step 5 Preview。但放在真实开发流程里我大概率会选DeepSeek V4 Pro的版本继续往下迭代因为它暴露出来的问题都是可以通过改参数解决的而Step 5那个版本我甚至不敢轻易动它的闭包状态。4.2 几个可以量化的对比项以下数据来自我个人实测不是严谨benchmark但能反映相对水平对比项Step 5 PreviewDeepSeek V4 ProGLM5.3首仓代码规模约1200行单文件约950行6个文件约1100行8个文件首次跑通成功率首次直接跑通修一个方向轴常量后跑通直接跑通但多处TODO帧率稳定性偶发掉帧60fps稳定60fps稳定需要人工修复处3处1处4处迭代一次平均耗时约6分钟约2分钟约3分钟可维护性主观评分3/55/54/5这个表格里我最在意的是“迭代一次平均耗时”这一行。Step 5 Preview之所以慢不是它生成代码慢而是它每次大改后引入的新bug需要花时间排查而DeepSeek由于模块拆分合理改起来就是精准定位微调几乎不会引入边界外的错误。GLM5.3的速度也不差问题主要是TODO要手动补全这部分工作很难被省掉。4.3 代码结构差异大仓鼠、模块党和框架党三个模型在代码组织方式上的“性格”差异是这次对比中最好玩的部分。Step 5 Preview是典型的单文件大仓鼠风格所有逻辑都塞在一个大作用域里靠内部类名和注释维持秩序首仓观感流畅但后期维护成本高。DeepSeek是模块党一个文件只干一件事输入、物理、渲染严格分离基本符合“整洁架构”的直觉。GLM更接近框架党它不像DeepSeek那样把所有功能写完整而是先把一个开源项目该有的骨架、接口、资源路径都搭出来剩下由你填空。这三种风格没有绝对的好坏取决于使用场景。只想花五分钟做一个能发朋友圈的3D小DemoStep 5的最合适想认认真真把一个游戏原型迭代成一个能上架的作品DeepSeek的最合适如果团队本身有美术和策划需要AI先生成一个工程框架来对接资源GLM5.3的写法反而最顺手。5. 部署与迁移GLM5.3 本地推理镜像排查和安卓落地5.1 为什么要把 GLM5.3 拉到本地部署测试到第三轮的时候我就想把GLM5.3拉到本地核心原因是迭代效率。用官方API虽然有免运维的优势但我每一轮Prompt调试、每一个参数实验都要走网络请求在GLM5.3这种模型上单次推理就要几秒钟连续改十几个版本等待时间累积起来非常可观。另外考虑到后续要接入自己的数据管道本地部署还能避免把代码中间产物传到外部服务安全和成本上都更好控制。自托管GLM5.3的常规路径就是用vLLM把模型包装成兼容OpenAI接口的服务然后通过本地请求调用。vLLM是目前吞吐量最高的开源推理引擎之一支持动态批处理和PagedAttention对变长输入的适配很有优势。但问题也随之而来vLLM迭代快新模型适配往往滞后于版本发布镜像版本选不对就会在模型加载阶段直接翻车跟我这次遇到的情况完全一样。5.2 vLLM 镜像版本怎么选一次典型的兼容性排查我的排查过程很有代表性。第一次启动时拉的是vllm/vllm-openai的最新发布镜像命令是标准的docker run --runtime nvidia --gpus all \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ vllm serve /models/glm5.3-chat \ --tensor-parallel-size 1 \ --max-model-len 8192模型权重加载阶段直接报错日志里出现“CUDA graph execution failed”和“shape mismatch”相关异常看着像显存不足但换了大显存机器问题依旧。后来我逐层排查发现根因在vLLM的kernel实现上GLM5.3的自定义注意力结构依赖RMSNorm的一种特殊fused kernel这个kernel是在0.6.6.post2版本才被完整支持。最新rc镜像虽然版本号更高但对GLM这条适配链路的稳定性反而没有经过足够验证CUDA graph捕获阶段会不定期崩。最后我把镜像固定为vllm/vllm-openai:v0.6.6.post2同样的参数和启动命令一次通过。提示如果你要自托管GLM5.3这类新模型别盲目追最新镜像。先查Release Notes里有没有对这个模型系列的针对性适配优先选稳定发布版而不是rc版。5.3 从网页原型到开源安卓3D游戏第3节生成出来的Three.js版本虽然跑在浏览器里但离“开源安卓3D游戏”只有一步之遥。把WebGL内容打包进安卓壳子的关键是用Capacitor它是开源项目可以直接把构建产物封装成Android WebView应用。实际操作步骤不复杂。先构建前端产物然后初始化Capacitor添加安卓平台最后用Android Studio签名打包npm run build npm i capacitor/core capacitor/cli npx cap init My3DGame com.example.my3dgame --web-dirdist npx cap add android npx cap sync android这套流程跑通之后浏览器里的跑酷小游戏就变成一个可安装的安卓APK。它本质上是WebView渲染性能跟原生OpenGL应用有差距但对原型验证和中小型游戏来说完全够用。如果真要往原生方向深入开源引擎Godot是更好的选择不过Godot场景资产同样依赖编辑器不在本次AI直接生成代码的评测范围内。顺带说一句我拿doubao-seed-2.0-code跑了一下安卓原生小项目的改造它在代码注释和可读性上做得很好适合新手阅读学习但主项目的三个模型不排名场外信息仅供参考。6. 跑完这三台机器后我的一点私人体会测完整个流程我给自己的选型策略做了一个明确的分工快速验证创意看Step 5 Preview它能把一个脑洞迅速变成看得见摸得着的3D画面进入正经迭代阶段我选DeepSeek V4 Pro它那套干净的模块化代码让人改着舒心如果团队的需求全是中文描述并且需要私有化部署直接用GLM5.3但前提是先把vLLM镜像问题解决掉版本锁死再谈生产力。还要分享一个在几轮调试里验证过的小技巧不管用哪家模型先让它输出一份接口伪代码或者函数签名骨架再要求它填充具体实现最终结果的稳定性都会显著提升。本质原因是让模型先把“自己准备怎么组织代码”的契约定下来后面所有填充都围绕契约进行就减少了中途改主意的概率。这条经验对我来说比任何模型排名都值钱。另外给大家留个参考判断如果你只是图新鲜想看看AI写3D游戏的效果希望跑的越炫越好首选Step 5 Preview如果你的目的是在这个原型上继续开发至少一周那我个人还是更建议用DeepSeek V4 Pro少一点视觉冲击换来的是后续几天省心。GLM5.3则留给那些愿意在工程完整度上花功夫、并且有能力接管TODO接口的朋友。模型没有绝对优劣关键是你打算让它在你的流程里站哪个位置。