三大模型3D游戏开发实测：DeepSeek V4 Pro、Step 5 Preview、GLM5.3谁更强？

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.xNDK 版本统一。渲染方案我给了两个选项让模型自己选纯 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 PreviewDeepSeek V4 ProGLM5.3工程结构优秀分层清晰良好结构完整一般偏随意3D 数学正确有取舍最扎实有推导基本正确有细节错游戏逻辑完整最完整手感好有创意机制丰富一次编译通过是是否需修错真机运行流畅启动卡顿流畅稳定可运行画面偏暗代码注释好讲原理好讲推导少偏简略综合评分4.24.53.66. 三个模型踩过的坑以及怎么绕过去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 游戏代码后先别急着跑先花十分钟做三件事——验证坐标系、检查游戏循环里的对象创建、确认资源释放。这三件事做完能排掉八成以上的坑。模型再强也只是帮你把代码写出来真正让它跑得稳、跑得久还是得靠开发者自己的工程判断。