我平时主要做游戏工程化和 AI 应用落地日常免不了拿各种模型写代码。最近看到新一代模型讨论很多有人问 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这种模型到底能不能真的“做游戏”。我干脆做了一次横评同一份 3D 游戏需求分别丢给这三款模型要求它们从零到一实现一个开源安卓 3D 游戏。这篇文章是我完整实测记录覆盖需求设计、首轮生成、代码构建、真机调试、加需求迭代甚至还有 GLM5.3 私有化部署时 vLLM 镜像版本的选择问题。如果你也在琢磨“AI 是不是能替我写完一个 3D 游戏”这篇文章能给你一个比较冷清的答案能但边界很明显。这次对比我不想把它写成“谁更厉害”的排行榜因为 3D 游戏的完成度受太多因素影响。我更关心的是同一道题面前三款模型各自怎么理解需求生成代码之后能不能跑起来跑起来之后能不能继续改。我从真实工程角度记录所有过程尽量把时间、报错、修法都写清楚方便你复制测试方法。1. 为什么突然拉三款模型来“同做一个 3D 游戏”1.1 这道题的输入和评审标准我先说一下题目长什么样。很多人测试 AI 写代码会直接说“用 Three.js 做个 3D 游戏”这个太宽泛了。真正的项目需求至少要有以下约束平台是安卓手机同时能在浏览器预览技术栈用 Three.js WebGL必须适配移动端触控游戏类型是简单的 3D 跑酷包含第一人称视角、跳跃、碰撞检测、计分与游戏结束界面所有素材用程序化生成不依赖外部美术资源。我刻意把范围缩小到“可运行的开源安卓 3D 游戏”因为这才贴近真实工程。如果只让模型生成一堆 index.html 代码发到浏览器里转一圈那和写一个网页没什么区别也测不出真实能力。这次评审标准只有三个维度第一生成的项目能不能在电脑浏览器上直接跑第二能不能用 WebView 封装成安卓应用并在真机上玩第三后续追加需求时模型能不能在已有代码基础上做增量修改而不是每次推倒重来。评审时我按每个模型单独开一个项目目录用同一个需求模板只是对三款模型分别提问。这期间我不会给它们看互相的答案也不会在首轮生成时做任何人工提示。模型输出的所有内容哪怕有明显的 bug我都先原样保存作为后续对比的基线。1.2 测试环境和约定测试环境也要交代一下。我的电脑是 Ubuntu 22.04内存 32GB显卡是 RTX 4090跑大模型推理或本地部署都能应付。手机用的是一台安卓原生机型系统是 Android 14。开发工具是 VSCode Node 20 Vite游戏运行时用浏览器调试安卓端我会用 WebView 容器封装。我用的提示词模板如下第一段描述游戏目标和玩法第二段限定技术栈和平台第三段明确要求输出完整工程结构包含 package.json、入口文件、游戏脚本、UI 界面以及一键启动命令第四段要求先给出实现方案再写代码方便我看它思考路径。这个模板对三款模型完全一致只是把模型名换掉。有个细节要提醒同样一句话在不同模型下的“理解颗粒度”差别很大。有的模型会默认你懂 Three.js直接甩一堆核心类有的模型会先解释整个渲染管线再给代码。为了公平起见我在首轮以后追加的所有需求都使用同一句话继续对话不再补上下文解释。这样才能看出长对话中的记忆和代码续写能力。2. 首轮生成三款模型交出的“作业”差异2.1 三个模型各自的理解路径先看 Step 5 Preview。它能先搭出整个方案从场景初始化、相机控制到碰撞体都列得比较清楚然后生成的代码文件也基本对应这些模块。它的特点是“预判需求”的意识比较强比如我要求“移动端触控”它主动写了 swipe 滑动跳跃和左侧虚拟摇杆但首轮代码运行起来后却有一个比较突兀的问题场景加载顺序和动画帧初始化耦合在一起导致在某些浏览器里首屏黑屏需要人工刷新一次才能显示。这属于典型的“方案完整但运行期细节不够稳”。DeepSeek V4 Pro 首轮生成的工程结构是最常规的几乎就是我期待中的“标准答案”。package.json、vite 配置、src/main.js、src/game 目录、UI 层的 html/cs界面全部齐全。它的代码风格偏保守用到的 Three.js API 都比较老好处是兼容性好坏处是有些 API 在最新 Three.js 版本里已经被标记为废弃需要额外注意。真机上跑完以后我发现它写入的 WebGL context 参数和安卓 WebView 里的 GPU 配置有冲突后面会专门讲。GLM5.3 第一轮给我最多的反而是文字分析。它在生成代码之前先输出了一篇很详细的实现方案包括“用 Raycaster 做跳跃碰撞还是用 AABB 碰撞检测”“纹理是否需要用程序化生成”“安卓端如何处理触摸事件穿透”这类问题。它生成的代码结构不算花哨但可读性很好关键位置都有注释。它第一版跑起来最顺利浏览器与安卓 WebView 上的表现几乎一致这让我对它的印象加了分。2.2 按运行结果打分而不是按行数打分我整理了一张首轮生成对比表维度只有六个工程结构完整度、首屏是否正常渲染、核心玩法是否可操作、触控适配程度、报错修复成本、代码可读性。我不会按代码行数打分因为体现工程能力的不是行数而是“能不能一打开就能玩”。维度Step 5 PreviewDeepSeek V4 ProGLM5.3工程结构完整度高模块划分清楚高目录最标准中高文件偏少但够用首屏渲染偶发黑屏需刷新稳定渲染稳定渲染核心玩法跳跃、碰撞、计分都有只有基础移动与碰撞玩法最完整含障碍生成触控适配写了虚拟摇杆但事件监听有遗漏基础点击跳跃触控较简单滑动与点击都做了事件处理较完善报错修复成本中需查初始化顺序低报错直接可定位低首轮没有致命错误代码可读性中上注释偏少好变量命名规范最好注释说明清晰从表里能看出三款模型的差异不在于“会不会写 Three.js”而在于工程化的完成度。DeepSeek V4 Pro 的代码长得漂亮但玩法覆盖不足Step 5 Preview 有很强的“想得很周全”的感觉却容易在细节上翻车GLM5.3 首轮综合表现最稳但它生成的代码量最少很多资源是靠算法现场生成改动时需要理解它的生成逻辑。3. 光是能跑还不够Step 5 Preview 实测里的构建与修 Bug3.1 首次构建失败的完整排查链路Step 5 Preview 虽然首轮方案完整我实际跑 npm install 和 npm run dev 时才真正进入“被 bug 反复折磨”的阶段。第一个报错是启动后浏览器直接白屏按 F12 看到控制台输出Uncaught TypeError: Cannot read properties of undefined (reading add) at initGame (game.js:127:18)这个报错很容易误判。乍一看是场景里某个对象没初始化实际上问题在initGame里调用了scene.add(this.player)但this.player是在另一个异步函数里创建的执行顺序晚于initGame。也就是说Step 5 Preview 生成的代码把“创建玩家”写在了异步资源加载之后但初始化流程没有等待这个异步函数完成。我先把报错信息原样喂回给 Step 5 Preview它给出的修复方案是“在 initGame 中给资源加载加 await”。这个方向是对的但真正麻烦的是后面又冒出第二个报错球体和障碍物的材质引用同一个纹理对象释放时被重复 dispose。这个报错发生时Step 5 Preview 给出的方案是“为每个材质克隆纹理”虽然能解决重复释放却让 GPU 内存占用涨了不少。我最后手动改用共享材质并只释放一次才把内存稳下来。这段经历让我意识到一个重要问题模型能修单个报错但缺乏对全局生命周期的控制。它会把当前错误修好却不检查这个修复会不会引出下一个错误。在 3D 项目里最常见的后果就是纹理、几何体、渲染器被重复创建或释放最终只在真机高负载时才暴露问题。3.2 从 Chrome 到安卓 WebView 的真机补丁浏览器里看着正常只是第一步我把它封装到安卓 WebView 时又踩了几个坑。最典型的例子是 WebView 的 GPU 渲染默认不一定开启Three.js 的 WebGL 渲染会异常退出。需要在安卓工程的 WebView 设置里显式配置webView.setWebContentsDebuggingEnabled(true); webView.setLayerType(View.LAYER_TYPE_HARDWARE, null); webView.getSettings().setJavaScriptEnabled(true); webView.getSettings().setMediaPlaybackRequiresUserGesture(false); webView.getSettings().setMixedContentMode(WebSettings.MIXED_CONTENT_ALWAYS_ALLOW);另外设置 WebView 背景透明时如果不把setBackgroundColor(Color.TRANSPARENT)和硬件加速配合Three.js 的 alpha 透明背景在部分安卓手机上会变成黑色。这些细节模型几乎不可能替你提前考虑因为它们没有真实设备验证环节。真正痛苦的是触控。浏览器端鼠标点击和移动端触摸事件在代码里可以共用一部分逻辑但安卓 WebView 默认对 300ms 点击延迟、触摸区域大小、多点触控的处理方式和 Chrome 不同。Step 5 Preview 第一版写的是document.addEventListener(click, jump)这在电脑上没问题在手机上必须改成touchstart并且阻止默认事件。我把报错现象描述给它后它补上了preventDefault()但又漏了passive: false导致安卓原生侧滚动时事件被吞掉。最后还是我手动给 touch 监听加了{ passive: false }才解决。这一章的核心经验是从代码到可玩中间隔着一座真机兼容性的山。AI 能帮你填大部分代码但 WebView 和触摸事件这种系统集成问题必须靠人的工程经验去兜底。4. 加需求压测DeepSeek V4 Pro 与 GLM5.3 谁更懂“增量修改”4.1 连续加五个需求首轮跑通以后我开始真正的压力测试同一个对话里连续追加五个需求观察三款模型谁能在已有代码上做增量修改。五个需求分别是增加背景音乐增加障碍物滑动动画增加计分板 UI增加游戏结束画面增加重新开始按钮和倒计时逻辑。这里最有意思的现象出现了。DeepSeek V4 Pro 每次追加需求时都会先输出一份“本次改动涉及文件”的列表然后告诉你哪些代码需要新增哪些代码需要替换。这种写法对工程开发非常友好但它的实现方式偏向“帮你修改文件片段”而不是完整输出整个文件所以如果你直接复制粘贴容易漏掉中间部分。我实测下来的印象是如果你习惯让 AI 生成 diffDeepSeek V4 Pro 是最省心的。GLM5.3 则相反它倾向于直接输出整份新代码但会确保旧代码的逻辑不被破坏。比如我让它加“重新开始按钮”它能保留原有计分重置逻辑只是新增一个 reset 函数。不过它有一个比较明显的问题五次迭代以后生成的 index.html 文件体积越来越大因为它倾向于在同一个文件里堆内容而不是拆分模块。到了第五个需求之后这个文件已经从原来的 300 多行膨胀到接近 1000 行代码可维护性下降很快。Step 5 Preview 在这轮的表现比较两极。前三轮需求它都处理得很好尤其是“障碍物滑动动画”和“背景音乐”这两个需求它能准确找到音效文件的加载位置还会给出资源格式建议。但到了第四个和第五个需求时它开始表现出“记忆漂移”——它忘了第二次需求里已经加过obstacle.speed这个属性在第三次改计时器时又引入了一个新的变量moveSpeed导致后续逻辑要用两个变量才能控制同一个障碍物。这类问题在长对话里特别容易发生需要人工在提示词里不断强调“沿用已有变量名”。4.2 上下文记忆与代码保留度对比我专门统计了五次需求后各模型的改动比例。所谓改动比例是看新增代码和重写代码的比例。如果每次需求都把之前代码大面积重写说明模型没有真正理解“增量”的含义。从这次测试看GLM5.3 的旧代码保留度最高约 80%DeepSeek V4 Pro 约 70%但它的重写通常是局部的不太会误伤无关逻辑Step 5 Preview 只有约 60%而且有两次重写都触碰了无关组件。上下文记忆这方面GLM5.3 确实更强。第五个需求要求“倒计时结束后跳到游戏结束画面”它还能记得第一个需求里设定的初始计分规则并用同一个变量做结算。相比之下Step 5 Preview 在第四轮时已经开始“客气地重新确认需求”虽然这不一定算缺点但实际测试时会增加人工沟通成本。顺带提一句最近社区里也经常讨论 doubao-seed-2.0-code 与 GLM5.3 在代码生成上的对比。我的感觉是它们在单轮代码生成上都很接近真正的差异点其实在长对话的代码保留度。如果你只是写一次性脚本哪个都行但如果你在做一个要长期迭代的 3D 游戏项目长上下文能力几乎决定了你能不能把它当协作者。5. GLM5.3 私有化部署实践vLLM 镜像版本到底选哪个5.1 为什么这轮测试要碰私有化说回题目标题里的另一个热搜问题GLM5.3 使用 vLLM 哪个版本的镜像。这个问题不是我凭空加的而是来自很多团队的本地部署需求。游戏项目组在开发阶段如果频繁把代码和美术素材发给云端模型会有资产外泄的顾虑还有一些团队把 AI 生成能力集成到自己的编辑器中希望推理链路完全内网化这就需要私有化部署。我测试的 GLM5.3 权重来自内部渠道结构上属于 MoE 架构实际规模比较大单张 4090 只能跑量化或小参数版本。推理框架我选的是 vLLM因为它的吞吐量高OpenAI 兼容接口接起来比较方便适合接到游戏开发工具链里。5.2 镜像版本验证和启动参数如果你准备拿 GLM5.3 跑 vLLM最容易踩的坑就是镜像版本选错。我用 Docker 试了三个镜像vllm/vllm-openai:latest、vllm/vllm-openai:v0.8.3、以及一个较老的 v0.6.x 版本。老版本会直接报错错误信息类似ValueError: ... is not supported by your vLLM version.原因是老版本的内核表里还没有 GLM 新结构的支持。0.8.x 版本则能正常识别并加载权重。所以我的建议是如果官网没有特别标注优先使用vllm/vllm-openai:latest或官方文档指定版本不要用太久远的镜像。启动命令可以参考下面这段注意--trust-remote-code这个参数很关键。GLM 系列很多自定义模型结构需要加载远程配置代码不加这个参数会直接拒绝启动。docker run --gpus all -d \ --name glm53-vllm \ -v /models/glm5-3b:/models/glm5-3b \ -p 8000:8000 \ vllm/vllm-openai:v0.8.3 \ --model /models/glm5-3b \ --trust-remote-code \ --dtype bfloat16 \ --max-model-len 32768 \ --quantization awq如果显存有限可以把--quantization awq去掉用--dtype half强行加载但推理质量会受一点影响。我用 4090 跑小尺寸版本max-model-len设成 32768 已经能覆盖大多数代码生成场景。想要更高的并发吞吐还可以加--tensor-parallel-size 2前提是你有多张卡。5.3 把私有推理接到开发工具链的效果部署完成以后我直接把本地服务接到一个内部脚本里用 OpenAI 兼容格式调用curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/glm5-3b, messages: [ {role: user, content: 用 Three.js 生成一个带碰撞和计分的 3D 跑酷场景输出完整代码} ], max_tokens: 4096 }本地私有部署的 GLM5.3 和官方 API 版本相比代码生成质量没有明显差距但响应速度和推理吞吐会受显卡性能限制。实际开发过程中我更常用的方式不是让它整个文件输出而是把报错信息直接发给它让它在完整代码基础上定位错误。因为私有部署的数据不会出内网我可以放心把包含业务逻辑的代码片段传过去。关于 vLLM 镜像最后补一个经验即使你的模型能正常加载也建议先跑一个短请求确认输出稳定再接入正式流程。我之前遇到过一个新版镜像能加载模型但并发一高就出现中文乱码的情况后来排查发现是镜像里的 tokenizer 配置和模型权重不匹配。这类问题往往比版本不兼容更隐蔽需要你在日志里重点看Slow tokens或vocab相关的 warning。6. 我看下来的真实结论和选择建议6.1 三款模型适合做什么到这里三款模型的整体画像已经比较清晰了。Step 5 Preview 适合做“从零到一”的探索阶段。它能快速生成一个结构完整的游戏原型并且会主动补充很多你可能没想到的模块比如计分板、资源加载管理器、音效控制接口。前提是你愿意接受它偶尔在生命周期和初始化顺序上翻车并有一定能力帮它兜底。DeepSeek V4 Pro 是我的日常首选它在“代码解释、报错修复、重构”这三个场景下的表现最稳定。它不会给你太多创意惊喜但生成的代码可读性高命名规范适合团队协作。如果你不是一个人闷头做项目而是要把 AI 生成的代码交给同事评审选 DeepSeek V4 Pro 会减少很多沟通成本。GLM5.3 的强项是长对话和私有化部署。它是三款模型里唯一让我在五个追加需求之后还能不用重写项目结构的模型。它的上下文一致性明显更强并且在本地部署时没有额外限制适合对数据安全性有要求的团队。代价是它首轮输出往往更偏“分析型”你需要等它把方案讲完再动手写代码略微影响效率。6.2 实际建议从提示词到验收流程如果你也想拉着一款模型做 3D 游戏我建议不要直接说“做游戏”而是把问题拆成五个阶段需求描述、方案评审、代码生成、报错修复、性能优化。每阶段用一段独立对话或提示词不要混在一起。至少在我这次实测里混在一起的长对话虽然 GLM5.3 能处理但前两个模型都会出现上下文丢失。验收流程比模型选择更重要。我建议先把“能否运行”作为第一关再谈玩法完整度。AI 生成的 3D 游戏代码大概率会出现某些装饰性功能写得很好但核心玩法不能跑的问题。我的策略是让模型先写最小可运行版本玩起来之后再逐步加内容且每个新版本都用真机跑一次。最后说点个人体会AI 做 3D 游戏这件事真正的瓶颈不是模型能力而是“你会不会把需求拆到位”。这次实测里三款模型都用了不到半小时就生成了 3D 游戏初版但把游戏推上安卓真机、让它连续追加五个需求、再完成私有化部署我花了两天。一个相对可靠的协作方式是让模型负责高频执行的部分比如生成碰撞检测、动画控制、UI 布局把玩法设计、资源规划、性能调优这些需要全局视野的工作留给自己。我在实际测试过程里最意外的一个发现是三款模型对“同一个报错”的修复思路差别很大。Step 5 Preview 倾向于重构模块DeepSeek V4 Pro 倾向于精准替换GLM5.3 倾向于直接在报错位置补逻辑。没有谁绝对好用关键看你习惯什么样的代码维护方式。如果你想省事最好的办法其实是同一时间让两个模型互相 review 对方的代码——这种“AI 交叉验证”出的 3D 游戏质量比我单独用任何一款模型都要稳。