我平时主要做游戏工程化和 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 按运行结果打分，而不是按行数打分

我整理了一张首轮生成对比表，维度只有六个：工程结构完整度、首屏是否正常渲染、核心玩法是否可操作、触控适配程度、报错修复成本、代码可读性。我不会按代码行数打分，因为体现工程能力的不是行数，而是“能不能一打开就能玩”。

从表里能看出，三款模型的差异不在于“会不会写 Three.js”，而在于工程化的完成度。DeepSeek V4 Pro 的代码长得漂亮，但玩法覆盖不足；Step 5 Preview 有很强的“想得很周全”的感觉，却容易在细节上翻车；GLM5.3 首轮综合表现最稳，但它生成的代码量最少，很多资源是靠算法现场生成，改动时需要理解它的生成逻辑。

3. 光是能跑还不够：Step 5 Preview 实测里的构建与修 Bug

3.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 生成 diff，DeepSeek 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 游戏质量，比我单独用任何一款模型都要稳。