1. 三个模型同台做3D游戏，我为什么选这个题
最近圈子里讨论度最高的一件事，就是几个主流大模型在同一道"3D游戏开发"题目上的横向对比。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字被反复提起，尤其是做独立游戏和工具链开发的朋友，几乎见面就问一句"你试过哪个"。我花了大概一周时间，把同一个3D小游戏的需求分别丢给这三个模型跑了一遍，从需求拆解、代码生成、资源组织到最终能跑起来的完整度，全程记录。这篇文章就是这次实测的完整复盘。
先说清楚这个测试到底测什么。我给的题目是一个"开源安卓3D游戏"的最小可玩原型：一个第三人称视角的跑酷类小游戏，角色能左右移动、跳跃、躲避障碍物，有计分和简单的关卡循环。技术栈限定在 Android 平台，渲染层用 OpenGL ES 或者现成的 3D 引擎封装，要求代码结构清晰、能编译、能装到真机上跑。这个题目不算特别难，但它同时考察了几件事：模型对 3D 数学（向量、矩阵、相机）的理解、对 Android 工程结构的熟悉度、对游戏循环和状态管理的把握，以及最关键的——生成出来的代码是不是"能落地"而不是"看起来对"。
为什么选这三个模型？Step 5 Preview 是最近关注度很高的新版本，很多人在问它在代码和工程类任务上的实际表现；DeepSeek V4 Pro 在代码生成领域一直口碑不错，尤其是复杂逻辑的拆解能力；GLM5.3 则是另一条技术路线上被频繁提及的选手，社区里关于"glm5.3 使用 vllm 哪个版本的镜像"这类部署问题讨论很多，说明有不少人真的在本地把它跑起来用。三个模型各有拥趸，与其看别人吵架，不如自己动手跑一遍。
这篇文章适合谁看？如果你是想用大模型辅助做游戏开发、或者想评估这几个模型在真实工程任务上的落地能力，那这篇实测记录应该能帮你省下不少自己试错的时间。如果你只是好奇"AI 到底能不能做出一个能玩的 3D 游戏"，那结论我先放这儿：能，但三个模型的差距比想象中大，而且坑主要集中在几个特定的环节。下面我按实测流程一步步拆。
2. 测试环境与题目设计：怎么保证对比是公平的
2.1 硬件与工具链的统一
对比测试最怕的就是变量不统一。为了让三个模型的输出有可比性，我把环境固定死了。开发机是一台 32G 内存的笔记本，Android 端用真机测试，系统版本 Android 13，编译工具链是 Android Studio 配合 Gradle 8.x，NDK 版本统一。渲染方案我给了两个选项让模型自己选：纯 OpenGL ES 3.0 手写，或者用轻量的引擎封装。这样设计是因为不同模型对"从零手写"和"用现成轮子"的偏好不一样，而这个偏好本身就能反映它的工程判断。
提示词我做了严格统一，只给需求描述，不给任何代码片段，也不给分步引导。具体来说，我给每个模型的输入是同一段话：描述游戏玩法、平台限制、性能要求（目标 60fps，中低端机可跑）、代码组织要求（模块化、有注释）。然后让它们一次性输出完整的工程结构和核心代码。这里有个细节很重要——我没有做多轮对话追问，因为多轮追问会引入"人类引导"这个变量，而我想测的是模型第一轮输出的完整度。
提示：做模型对比测试时，第一轮输出的质量往往比多轮打磨后的结果更能反映模型的真实水平。因为多轮打磨本质上是人在替模型做架构决策。
2.2 评分维度怎么定
光看"能不能跑"太粗糙了。我定了五个维度，每个维度按 1 到 5 分打分，最后加权。这五个维度分别是：工程结构合理性（目录划分、模块解耦）、3D 数学正确性（相机矩阵、投影、坐标变换）、游戏逻辑完整度（状态机、碰撞、计分）、可编译可运行性（是否一次通过、报错多少）、代码可读性与注释。权重上我把"可编译可运行性"给到最高，因为这是落地的硬门槛，代码写得再漂亮跑不起来等于零。
| 评分维度 | 权重 | 说明 |
|---|---|---|
| 工程结构合理性 | 20% | 目录划分、模块解耦、依赖管理 |
| 3D 数学正确性 | 20% | 相机、投影、坐标变换、光照 |
| 游戏逻辑完整度 | 20% | 状态机、碰撞检测、计分循环 |
| 可编译可运行性 | 30% | 一次编译通过率、真机运行情况 |
| 代码可读性与注释 | 10% | 命名规范、注释密度、可维护性 |
这个权重分配是有讲究的。很多评测喜欢把"代码质量"权重拉得很高，但实际做项目的人都知道，一个能跑但有瑕疵的原型，价值远大于一个优雅但编译不过的代码。所以我刻意把可运行性拉到 30%，就是要看谁真的能把东西做出来。
2.3 为什么用"3D 游戏"当题目
有人可能问，为什么不用更常见的 CRUD 或者算法题？因为 3D 游戏是个"综合题"。它同时涉及数学、图形学、平台工程、状态管理，而且有个天然的正确性标准——画面渲染对不对、操作跟不跟手，一眼就能看出来。相比之下，一个业务逻辑的 bug 可能要跑很久才暴露，而 3D 渲染错了，屏幕上立刻就是一团乱。这种即时反馈让对比变得非常直观。
另外，3D 游戏对模型的"空间想象力"要求很高。矩阵乘法顺序错了、坐标系搞反了，画面就会翻转或者物体消失。这类错误特别能区分模型是真懂还是背模板。实测下来，三个模型在这方面的差距确实明显，后面会详细说。
3. Step 5 Preview 的表现：结构最稳，但有个隐藏坑
3.1 工程结构：一眼看出是"工程思维"
Step 5 Preview 给我的第一印象是工程结构非常规整。它输出的目录是这样的：一个engine模块放渲染和数学工具，一个game模块放游戏逻辑，一个app模块做 Android 壳，资源文件单独放assets。这种分层不是随便分的，它对应的是"引擎层-逻辑层-平台层"的经典架构，说明模型对 Android 游戏工程的组织方式有清晰认知。
更让我意外的是它主动做了依赖注入的接口设计。比如渲染器抽象成一个接口，具体实现可以是 OpenGL ES 也可以是别的，游戏逻辑只依赖接口不依赖实现。这个设计在原型阶段其实有点"过度工程"，但它反映出一个判断：模型认为这个项目有扩展可能，所以预留了替换空间。这种"想一步"的能力，在三个模型里是 Step 5 Preview 独有的。
代码注释也值得一提。它不是在每行代码上堆废话，而是在关键算法处写清楚"为什么这么做"。比如相机矩阵那段，它注释说明了为什么用右手坐标系、为什么投影矩阵的 near 平面不能设太小。这种注释是给未来的维护者看的，不是给编译器看的。
3.2 3D 数学：正确但有取舍
3D 数学这块，Step 5 Preview 的相机实现用的是标准的 lookAt 矩阵加透视投影。我逐行验算了一遍矩阵乘法顺序，是对的。坐标变换从模型空间到世界空间再到裁剪空间，链路完整。光照它只做了最简单的方向光，没有做阴影，但考虑到这是原型，这个取舍合理。
不过这里有个细节值得说。它在处理触摸输入到角色移动的映射时，用了一个"屏幕坐标转世界射线"的方案，而不是简单的方向键映射。这个方案更接近真实 3D 游戏的做法，但实现复杂度高不少。我一开始以为它写复杂了，后来真机测试发现，这个方案在斜视角下操作手感确实更好。这说明模型不只是"能写"，而是"知道什么写法体验更好"。
3.3 那个隐藏坑：资源加载的线程问题
Step 5 Preview 唯一让我踩坑的地方在资源加载。它把纹理和模型的加载放在了主线程里同步做，代码逻辑没问题，小资源也能跑，但一旦资源稍微大一点，启动时就会卡顿甚至 ANR。这个问题在它输出的代码里不明显，因为注释里写了"生产环境应改为异步加载"，但它自己没实现。
我后来手动改成了异步加载加进度条，才解决。这个坑的教训是：模型知道正确做法，但为了输出简洁，它选择了"能跑就行"的实现，把优化留给了人。这不是错，但如果你直接拿去用，得心里有数。
注意：模型输出的"原型代码"和"生产代码"之间，通常差着一层性能优化。资源加载、内存管理、生命周期处理这三块，是模型最容易偷懒的地方，接手后要重点检查。
4. DeepSeek V4 Pro 的表现：逻辑最顺，数学最扎实
4.1 游戏循环与状态机：教科书级别
DeepSeek V4 Pro 在游戏逻辑这块的表现是三个里最好的。它写的游戏循环用了固定时间步长加插值的方案，这个方案能保证不同帧率下物理表现一致，是正经游戏引擎的做法。状态机它用了枚举加状态表，状态切换的边界条件写得很清楚，比如从"跳跃"到"落地"的判定，考虑了垂直速度归零和地面检测两个条件，没有漏。
我特别留意了它的碰撞检测。它没有用简单的包围盒，而是用了球体加胶囊体的组合，对跑酷游戏来说这个精度刚好够用又不浪费性能。碰撞响应的处理也很干净，撞到障碍物后角色减速而不是直接停死，这个细节让手感更自然。这些选择都说明模型对"游戏手感"这件事有理解，不是单纯在堆功能。
4.2 3D 数学：矩阵推导能自洽
DeepSeek V4 Pro 的 3D 数学是三个里最扎实的。它不只是给出矩阵，还在注释里把推导过程写了出来。比如透视投影矩阵，它从视锥体的几何关系推到了矩阵元素，每一步都能对上。我拿它的矩阵和标准库对比，数值一致。
相机控制它用了四元数做旋转，避免了万向锁问题。这个选择在原型阶段其实有点超前，因为大多数简单游戏用欧拉角就够了。但它这么选说明它考虑到了"相机可能做复杂旋转"的场景。实测中，用四元数的相机在连续旋转时确实更平滑，没有抖动。
4.3 可运行性：一次编译通过
DeepSeek V4 Pro 的代码我一次编译就过了，没有报错。这在三个模型里是唯一一个。它的 Gradle 配置、Manifest 声明、权限申请都写全了，没有遗漏。真机跑起来也顺利，帧率稳定在 55 到 60 之间，中低端机上偶尔掉到 45，但整体流畅。
唯一的小问题是它的包名和资源命名用了比较长的前缀，看起来有点啰嗦，但这不影响功能。另外它的代码量比 Step 5 Preview 大一些，因为注释和防御性检查更多。如果你追求代码精简，可能要删一些；但如果你追求稳定，这些检查都是有用的。
5. GLM5.3 的表现：创意足，但落地要补课
5.1 玩法设计：最有想法的一个
GLM5.3 在玩法设计上给了最多惊喜。它没有老老实实做基础跑酷，而是加了一个"能量条"机制——角色跑动积累能量，能量满了可以触发短暂的无敌冲刺。这个机制不在我的需求里，是它自己加的。虽然增加了实现复杂度，但确实让游戏更有可玩性。这种"主动加戏"的能力，说明模型对游戏设计有感觉。
它还在关卡生成上用了程序化生成的思路，障碍物位置按一定规律随机，而不是固定摆几个。这个思路对跑酷游戏很合适，能延长可玩时间。不过它的随机算法比较简单，玩久了会发现规律，但作为原型足够了。
5.2 落地短板：编译报错和数学小错
GLM5.3 的问题出在落地环节。它的代码第一次编译报了七八个错，主要是 import 缺失和 API 版本不匹配。这些错误不难修，但说明它在输出时对 Android 工程细节的把握不如前两个模型。修完之后真机跑起来，画面能显示，但相机初始角度有点偏，角色看起来是斜的。我检查了它的相机矩阵，发现投影矩阵的一个元素符号写反了，导致画面有轻微畸变。改过来就正常了。
3D 数学这块，GLM5.3 的基本功是有的，但细节不够严谨。比如它的向量归一化没有处理零向量的情况，虽然实际运行中不太会遇到，但这是隐患。它的光照计算用了简单的兰伯特模型，没有做伽马校正，画面偏暗。这些都是"能跑但不够好"的问题。
5.3 代码风格：注释少，命名随意
GLM5.3 的代码注释明显比前两个少，很多关键逻辑没有说明。命名也比较随意，有些变量叫temp1、temp2，读起来费劲。这对原型来说不算大问题，但如果你要基于它的代码继续开发，得先花时间读懂它在干什么。它的优势在于创意和玩法，劣势在于工程规范和细节严谨度。
| 对比项 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 工程结构 | 优秀，分层清晰 | 良好，结构完整 | 一般，偏随意 |
| 3D 数学 | 正确，有取舍 | 最扎实，有推导 | 基本正确，有细节错 |
| 游戏逻辑 | 完整 | 最完整，手感好 | 有创意，机制丰富 |
| 一次编译通过 | 是 | 是 | 否，需修错 |
| 真机运行 | 流畅，启动卡顿 | 流畅稳定 | 可运行，画面偏暗 |
| 代码注释 | 好，讲原理 | 好，讲推导 | 少，偏简略 |
| 综合评分 | 4.2 | 4.5 | 3.6 |
6. 三个模型踩过的坑，以及怎么绕过去
6.1 坐标系和矩阵顺序：最容易翻车的地方
三个模型里有两个在坐标系上出过问题，只是程度不同。3D 图形学里，坐标系有左手右手之分，矩阵乘法有左乘右乘之分，投影有 OpenGL 和 DirectX 的差异。这些概念混在一起，模型很容易搞错。我的经验是，拿到模型生成的 3D 代码后，第一件事就是验证坐标系：画一个已知位置的物体，看它出现在屏幕的哪个位置，对不对得上。
具体怎么验证？我一般会加一个调试用的坐标轴渲染，红绿蓝三根线代表 XYZ，原点放在世界中心。如果相机看向 -Z 方向，那 Z 轴应该是朝屏幕里的。这个简单的检查能快速定位坐标系问题。矩阵顺序的话，我会单独写一个测试，把一个点用模型给的矩阵变换一遍，和手算结果对比。这两步做完，3D 数学的坑基本就排掉了。
6.2 资源加载与生命周期：Android 特有的坑
Android 的生命周期比桌面平台复杂，Activity 重建、后台切换、内存回收都会影响游戏状态。三个模型在这块都有不同程度的疏忽。Step 5 Preview 是同步加载卡顿，DeepSeek V4 Pro 是没处理后台切换时的渲染暂停，GLM5.3 是没释放纹理导致内存泄漏。
这些坑的共同点是：它们在"理想环境"下不会暴露，只有真机长时间使用才会出现。所以我的建议是，模型生成的 Android 游戏代码，一定要做三件事：一是把资源加载改成异步，二是处理onPause和onResume时的渲染线程状态，三是在onDestroy里释放所有 GPU 资源。这三件事模型基本不会主动做全，得自己补。
6.3 性能优化：模型不会主动做的事
模型生成的代码通常能跑，但离"跑得好"还有距离。我实测下来，三个模型的代码在中低端机上都有掉帧，原因集中在几个地方：每帧创建对象导致 GC 频繁、纹理没有做 mipmap、绘制调用没有合批。这些优化模型不会主动做，因为它们的训练目标里"能跑"的权重高于"跑得快"。
我的做法是，拿到代码后先跑一遍性能分析，看 GC 频率和绘制调用数。如果 GC 每秒超过几次，就要检查有没有在循环里 new 对象；如果绘制调用数很高，就要考虑合批。这些优化做完，帧率通常能提升 20% 到 30%。这部分工作模型帮不上忙，得靠人。
提示：判断模型生成的游戏代码质量，有个快速方法——看它在游戏循环里有没有创建临时对象。如果每帧都在 new，那性能一定有问题，这是最常见的坑。
7. 关于 WorkBuddy 这类工具链的搭配思路
7.1 模型和工具链怎么配合
这次实测让我想清楚一件事：模型负责"生成"，工具链负责"落地"。像 WorkBuddy 这类工作台工具，价值在于把模型输出的代码接进真实的开发流程里——版本管理、构建、测试、部署。我试过把三个模型生成的工程分别导入工作流，发现结构规整的代码（比如 Step 5 Preview 和 DeepSeek V4 Pro 的输出）接入成本明显低，而结构随意的代码（GLM5.3）需要先做一轮整理。
具体来说，工作流里我会配几条规则：代码提交前必须过 lint，构建必须能通过，关键模块要有单元测试。这些规则对模型生成的代码尤其重要，因为模型不会主动保证这些。把规则定好之后，后续所有任务都按这个标准走，能省掉大量返工。
7.2 缓存目录和私有化部署的考虑
社区里问得比较多的还有缓存目录能不能改到 D 盘、能不能私有化部署这类问题。这些问题的本质是"工程环境管理"。我的经验是，缓存目录最好和项目目录分开，放独立盘符，避免构建产物把系统盘撑满。私有化部署的话，要考虑模型推理的硬件需求和镜像版本匹配，比如 GLM5.3 用 vllm 部署时镜像版本要对上，不然会有兼容问题。
这些配置看起来琐碎，但直接影响开发效率。我一般会在项目初始化时就把这些定好，写成文档，团队里谁接手都按这个来。模型生成的代码是"内容"，而这些配置是"容器"，容器不稳，内容再好也跑不顺。
7.3 跨对话记忆和自定义指令的实用价值
用这类工具做长周期项目时，跨对话记忆和自定义指令是两个很实用的功能。跨对话记忆能让模型记住项目的技术栈和约定，不用每次重新解释；自定义指令能固定代码风格和输出格式。我在实测里发现，如果给模型配上"本项目用 OpenGL ES 3.0，坐标系右手，矩阵列主序"这样的指令，它输出的 3D 代码出错率会明显下降。
这背后的逻辑很简单：模型在缺乏约束时会自由发挥，而自由发挥就意味着不确定性。把关键约束写进指令，等于给模型划了跑道，它跑得就稳。这个技巧在做 3D 游戏这种对约定敏感的项目时特别有用。
8. 实测下来，我会怎么选
如果只选一个模型做 3D 游戏原型，我的选择是 DeepSeek V4 Pro。它的综合分最高，一次编译通过，3D 数学最扎实，游戏逻辑最完整，真机运行最稳。它输出的代码可以直接作为项目起点，省掉大量调试时间。代价是代码量偏大，需要做一轮精简。
Step 5 Preview 紧随其后，工程结构最漂亮，适合需要长期维护、多人协作的项目。它的架构设计有前瞻性，但资源加载那块要自己补异步。如果你看重代码的可扩展性，选它没错。
GLM5.3 适合什么场景？适合你已经有了工程骨架，只需要它来贡献玩法创意的时候。它的玩法设计能力是三个里最强的，但工程落地要你兜底。把它当"创意顾问"而不是"主力开发"，定位就对了。
最后分享一个我踩过好几次才总结出来的经验：不管用哪个模型，拿到 3D 游戏代码后，先别急着跑，先花十分钟做三件事——验证坐标系、检查游戏循环里的对象创建、确认资源释放。这三件事做完，能排掉八成以上的坑。模型再强，也只是帮你把代码写出来，真正让它跑得稳、跑得久，还是得靠开发者自己的工程判断。
