三大AI模型同题实测：同一需求各写一个3D游戏，结果出乎意料

平时看模型对比，最烦的就是那种贴一堆榜单分数、跑几个数学题的评测，跟实际开发完全是两回事。代码能力行不行，扔一个具体需求过去，让它自己写，跑起来看效果，比什么都直观。这几天 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个模型热度都不低，我把它们拉到同一个考场，用完全相同的 prompt 各做了一款 3D 游戏，实测一轮下来还真有不少值得聊的东西。

这篇文章不聊理论，就记录一下我的完整测试过程。包括同一份需求下三款模型的首轮生成质量、三轮迭代改需求的能力、从单 HTML 到工程化再到安卓打包踩的坑，最后再聊一下本地部署时 vLLM 镜像版本选择的问题。不管你是想选型、想抄 prompt，还是单纯好奇这几个模型哪个更靠谱，这篇应该都能给你一些参考。

1. 为什么要拿 3D 游戏当考题

1.1 三个模型一台戏：先弄清楚各自的身份

先说 Step 5 Preview。它是阶跃星辰 Step 系列的最新预览版，这个系列一直走的是多模态路线，但代码能力在预览版里被明显加强了。再就是 DeepSeek V4 Pro，DeepSeek 家的旗舰迭代，V3 时代 DeepSeek 的代码能力是什么水平大家心里都有数，V4 Pro 在我看来主要是在长上下文和复杂工程理解上做了强化。GLM5.3 则是智谱的新一代开源模型，之前 GLM-4 系列在中文场景的代码生成口碑一直不错，到 5.3 这代在工具调用和结构化输出上有明显变化。

这三个放在一起很有意思：一个做多模态的、一个做推理深度的、一个做中文场景优化的。它们的代码能力到底怎么排，榜单说了不算，上手写个完整项目才见真章。

1.2 为什么偏偏选 3D 游戏当考题

选游戏而不是选 CRUD 后台，原因其实很直接。3D 游戏本质上是一个综合工程，它同时考验模型以下几个维度：

• 数学能力：三维坐标、向量运动、碰撞检测的边界条件，稍微算错一点，物体就直接穿模或者飞出画面
• 渲染链路：场景、相机、光源、材质、网格对象这五个要素必须全部到位，少一个画面就是黑的
• 交互设计：键盘监听、鼠标操作、触控事件，要处理输入层和游戏循环之间的衔接
• 状态管理：游戏状态、角色状态、障碍物状态、计分逻辑，这四类状态需要清晰分离又互相联动
• UI 呈现：开始界面、分数统计、结束界面，这些能否和游戏主循环正确串起来

一个 CRUD 页面模型只需要套模板，但一个 3D 游戏没有模板可套。模型的代码能力有没有水分，在这个任务面前藏不住。

1.3 控制变量的方式：同一份需求，谁都不许追加解释

实测必须公平，我用的方式是：给三个模型完全相同的 prompt，不允许追加任何额外说明，首轮生成就是纯"裸考"。为了尽量还原真实开发场景，我特意在需求里埋了几个隐含要求：三跑道切换、速度递增、碰撞判定的具体规则，还要求代码必须在单 HTML 文件里直接运行。

完整 prompt 如下：

请用 Three.js 制作一款 3D 跑酷游戏，要求如下：

1. 画面中有三条跑道，玩家控制一个立方体角色在跑道间左右切换（A/D 或方向键控制）
2. 障碍物从远处生成并朝玩家方向移动，碰到障碍物游戏结束
3. 玩家成功躲避一个障碍物，分数 +10 分
4. 游戏速度随时间逐渐加快
5. 需要完整的开始界面、游戏结束界面和分数显示
6. 全部代码放在单个 HTML 文件中，通过 CDN 引入 Three.js，双击即可运行
7. 干净的代码风格，注释用中文

三个模型拿到的都是这一份，一字不差。

2. 首轮同题答卷：能不能自己跑起来

2.1 三份代码的"能不能跑"直接对比

首轮结果出来，第一件事就是分别双击打开三个 HTML 文件。这一步就淘汰掉了一批隐形问题。下面这张表是我当时记录的实测状态：

注意一个关键差异：DeepSeek V4 Pro 首轮的代码里，速度递增逻辑虽然在注释里明确写了"随时间增加障碍物速度"，但实际运行中速度一直保持不变。后来我看了眼源码，发现它把 speed 变量定义在了游戏循环外部，且循环内部始终没有引用这个变量。换句话说，它的代码结构非常接近"工程标准"，但细节处有一行赋值写错了位置。GLM5.3 则是明显的"过度设计"倾向，光是 UI 层的动画就写了三套，第一版跑起来居然没毛病，我觉得少见。而 Step 5 Preview 的表现则比较均衡，功能该有的都有，就是碰撞盒的判定用的是简化距离法，导致障碍物从侧面擦过去的时候偶尔也算碰撞。

2.2 代码风格与实现思路的差异

三家模型面对同一个需求，实现思路上的分化挺明显的。展开源码之后，能看出它们各自的思维习惯。

Step 5 Preview 的代码是一个非常典型的"面向结果"写法。全局变量挂了好几个，游戏循环用 requestAnimationFrame 一把梭，碰撞直接比较两个物体的 x 和 z 轴距离差。这种写法胜在直白，所有逻辑都在一个平面里铺开，调试的时候顺着函数往下读就行。但坏处也很明显，一旦游戏机制复杂化，这种写法会迅速变成一团乱线。

DeepSeek V4 Pro 在第一轮就拿出了 class 分层的结构：Game 负责主循环，Player 负责移动和输入，ObstacleManager 负责障碍物生成。这种结构乍一看很专业，但你要知道，单 HTML 文件里写 class 结构其实有点杀鸡用牛刀。而且结构越复杂，越容易在某个不起眼的地方出现逻辑断层，前面提到的 speed 不递增就是例子。说到底，模型的工程意识上来了，但执行精度还差那么一点火候。

GLM5.3 的实现则显得非常"贴心"：每个方法上面都有详细的中文注释，连参数范围都给标注了，UI 样式也明显精致一些。它的第一版动画里带了一个轻微的相机震动效果，这是另外两家完全没做的。但反过来，这种过度丰富也拖长了代码行数，560 行放在单 HTML 里已经有点难以阅读。

2.3 首轮结论：完成度不等于可用性

首轮最核心的结论是：三个模型都能在一轮之内写出一份"打开就能玩"的游戏，这个及格线过了。但距离"好用"的差距各不相同。如果按我个人的评价口径，首轮完成度 Step 5 Preview 最高，因为它功能闭环完整、bug 最少；DeepSeek V4 Pro 结构最好但有一个明显的小 bug；GLM5.3 完成度不差，可是过度设计让代码量偏大，这为后续迭代埋下了隐患。

说实话，这样的结果和我对这三个模型的预设印象基本一致。Step 系列的亮点本来就是"一步到位"，DeepSeek 则擅长做结构，GLM 在细节体验上更用心。首轮测完，我对它们的定位已经有了大致判断，接下来进入真正拉开差距的环节——迭代改需求。

3. 三轮迭代：从"能跑"到"能玩"的差距在这里

3.1 迭代任务的设计思路

实际开发中，需求变更是常态，一个模型能不能在已有代码上继续迭代，比首轮生成能力重要得多。我设计了三次迭代，每次都有明确的变更目标：

• 第一次迭代：在现有代码上加入"移动端触控支持"和"音效反馈"
• 第二次迭代：改进视觉表现，加入"粒子特效"和"障碍物闪烁预警"
• 第三次迭代：调整玩法，把三跑道改成四跑道，同时要求"手感不能变差"

这三次迭代从简到繁，分别考验模型在已有代码上的增量修改能力、对新需求理解后不影响原逻辑的能力，以及对整份代码上下文一致性的把握。

3.2 迭代翻车实录：模型是怎么把问题搞复杂的

第一次迭代，移动端触控支持，这是个相对常规的需求。但三家表现出了完全不同的处理方式。Step 5 Preview 直接给窗口加了 touchstart 事件监听，利用 touch.clientX 和当前屏幕宽度做左右判断，代码干净利落，一次验证通过。GLM5.3 的做法也类似，但它额外给 Canvas 加了 touch-action: none 样式，这算是专业玩家的操作，避免了移动端浏览器的手势干扰，说明它对 WebView 环境是了解的。DeepSeek V4 Pro 在这里出了状况：它在原有的键盘监听函数里追加了一段 touch 分支，但监听器绑定了两次，导致每次触碰屏幕都会触发两次跑道切换。这个 bug 的本质，是它对"新增逻辑和原有逻辑之间的幂等性"考虑不足。

第二次迭代，粒子特效和预警闪烁。这一步开始出现更深的坑。Step 5 Preview 按部就班地用 THREE.Points 实现了粒子系统，闪烁则是通过修改材质透明度完成，逻辑正常。GLM5.3 这次终于露出了它的阿喀琉斯之踵——它在原有的 requestAnimationFrame 主循环里又添加了一个独立的 requestAnimationFrame 循环来驱动粒子动画。写代码的人应该都懂这意味着什么：两个循环分别跑，帧率直接不稳定，而且第二个循环里的更新函数抛异常时，主游戏逻辑完全感知不到。我当时调试时发现游戏画面忽快忽慢，一查源码才发现问题所在。DeepSeek V4 Pro 这一轮表现不错，粒子系统被抽象成独立的 ParticleSystem 类，非常顺手。

第三次迭代是最能看出水平的：把三条跑道改成四条。这个需求听起来简单，但涉及的改动点包括跑道坐标数组、障碍物生成区间、玩家切换逻辑和碰撞边界计算，一个点漏掉就会出问题。Step 5 Preview 在这里翻了车，它把跑道坐标更新得很完美，四条跑道均匀分布，但碰撞边界仍然沿用了三跑道时代的数值——这意味着原本应该在跑道外侧才算碰撞的位置，现在提前到了第三条跑道和第四条跑道的交界处。这正是"局部正确但全局不自洽"的典型表现。DeepSeek V4 Pro 则展现了对代码结构的理解能力，它把跑道坐标抽象成了一个 layerConfig 数组，改四条跑道时只需要调整数组长度和生成区域，手感保持得很稳。GLM5.3 在这次修改中引入了一个 regression：切跑道动画的 deltaTime 被重置，导致切换过程偶尔加速。好在一个模型的水平不在于完全不犯错，而在于能不能稳定收敛。

3.3 上下文一致性：谁还记得之前做过什么

这轮迭代让我观察到一件事：三个模型对整份代码上下文的记忆能力有明显的差别。基于已有的 HTML 文件内容做增量修改时，DeepSeek V4 Pro 的"全局意识"最强，它在改第四条跑道时，会自己去检查所有牵扯到跑道索引的代码段，将法官判案式的严谨贯彻到底。Step 5 Preview 则是典型的"你说什么我改什么"，局部完成度很高，但要靠它自己发现隐藏的耦合条件，目前还不太现实。GLM5.3 的优势在于它每次修改都会顺带更新对应的中文注释，代码可读性始终在线，这对团队协作来说是有实际价值的。

一个有意思的细节是，在第三次迭代里，我要求"手感不能变差"。三个模型对这个模糊约束的理解各不相同。Step 5 Preview 把加速曲线的增幅调小了一点，DeepSeek V4 Pro 把障碍物间距按照跑道数量做了等比缩放，GLM5.3 则是增加了一个缓冲判定——碰撞发生后预留 8 帧的容错时间。三种思路都说得通，但明显 DeepSeek 的处理更接近游戏设计的常规做法。

4. 工程化与安卓打包：代码跑起来只是开始

4.1 从单文件到 Vite 工程的三处硬伤

现在假设你选定了一个模型生成的代码，想把它变成正式项目，问题很快就来了。我用三份代码分别搭建了 Vite + Three.js 工程，过程中暴露了几处硬伤。

第一，依赖引入方式。三份代码首轮全部用了 CDN 的全局 THREE 对象。这在单 HTML 里没问题，但挪到工程化环境里必须改成 ES Module 的 import 方式。Step 5 Preview 的代码中把 THREE 当作全局变量用了差不多三十多处，逐个替换不是难事，但很烦。DeepSeek V4 Pro 和 GLM5.3 的代码相对集中，改动成本低一些。

第二，路径处理。GLM5.3 的代码里有几处相对引用了纹理路径，但在 Vite 构建后路径失效。这个问题虽然不是模型本身的锅，但至少说明它对构建工具的常识认知还有欠缺。

第三，代码拆分。DeepSeek V4 Pro 的 class 结构天然适合拆成模块文件，我花了十分钟就拆出了 Game、Player、ObstacleManager 三个文件。Step 5 Preview 的函数式写法拆起来就费劲一点，得先把全局状态对象梳理清楚才有办法下手。

4.2 开源安卓 3D 游戏适配实测

工程化只是第一步，接下来我把游戏打包到安卓端跑了一遍。这里就直接回答榜单之外真实玩家关心的问题：生成的三维游戏能否移植到移动端。

我选了一个轻量方案，用 Capacitor 打包成 Android WebView 应用。实测下来三份代码在移动端的表现差异真的很悬殊。GLM5.3 的代码在桌面 Chrome 上非常流畅，但我跑安卓 WebView 时手机整体帧率只能稳定在 40-50fps 左右，而且出现轻微的触控延迟。它的 3D 场景内容太丰富，粒子、动画、阴影叠加下，移动端 GPU 压力一下就上来了。Step 5 Preview 的代码在移动端表现反而不错，稳定的 60fps，只是操纵手感偏硬，切换跑道时缺少缓冲动画。DeepSeek V4 Pro 的工程结构在移动端发挥了优势，帧率稳定，Responsive 布局也处理得最到位，适配逻辑是它自己写的。

还有一个好玩的点：打包时移动端 WebView 默认是没有键盘的，触控支持必须依赖模型主动实现。三家里只有 GLM5.3 在首轮代码里就加入了 touch-action 样式，其它两家虽说在第二轮也补齐了，但第一版在真机上根本无法操作。这个细节相当能说明模型对移动端开发场景的理解程度。

4.3 性能与资源占用的直观数据

用 DevTools 做了简单的性能录制，取的是三份代码在同一个桌面 Chrome 环境下的表现，数据仅供参考：

GLM5.3 那段粒子动画在移动端的开销比另外两家高出近一倍，这一点在选型时必须考虑进去。

5. 本地部署与 vLLM 镜像选型避坑

5.1 为什么还有那么多人坚持本地跑

虽然三家都有 API 可以用，但社区里自部署的需求一直居高不下。原因不外乎两类，一类是数据敏感，代码片段不能出内网；另一类是长对话的成本控制，重度使用的时候 API 费用太不可控。再加上这次测试的热词里有 GLM5.3 搭配 vLLM 跑本地推理这类话题，说明大家都很关心开源模型的本地落地。但本地部署这件事，最大的坑往往不是模型本身，而是推理框架的版本匹配问题。

5.2 vLLM 镜像版本选择指南

很多人在 GLM5.3 上用 vLLM 跑推理时，最常遇到的坑就是版本不匹配。有人说 "glm5.3 使用 vllm 哪个版本的镜像"，这个问题的答案其实没有定数，核心原则是：镜像版本必须匹配模型的 model_type 和对应的算子上限。

判断逻辑其实很简单，按下面这个流程走就行：

1. 先打开模型目录下的 config.json，搜索"model_type"字段，看它属于哪个体系
2. 在 vLLM 官方文档或 GitHub Release Notes 里搜索对应的架构关键词，看哪个版本开始支持
3. 如果你用的是量化版（GPTQ/AWQ），还要确认镜像里是否预编译了对应的量化算子，这一项经常被忽略
4. 拿不准的时候，直接用最新 stable 版本永远比用旧版稳

我按这个思路整理了一个关于 GLM5.3 搭配 vLLM 的常见问题表，同样适用于其它新模型：

坦白说，"哪个版本的镜像"从来都没有标准答案。我个人的习惯是先查模型在 apirelease 时官方有没有推荐过对应框架版本，如果没有，直接上最新版稳定镜像，然后跑一个几百 token 的冒烟测试验证吞吐量，再把 max-model-len 调到适合作业的长度，基本就稳了。

5.3 三款模型本地部署难度对比

如果要从本地部署的难度给三个模型打分，DeepSeek V4 Pro 是最省心的，因为它的架构在 vLLM 生态里兼容性最成熟，社区镜像最丰富，基本上拉下来就能跑。GLM5.3 属于中等偏上，如果恰好用了新结构，就需要确认一下镜像版本。Step 5 Preview 的情况取决于它是否开放完整权重。

给一个实用建议：线上调试用 API，稳定跑批用本地。API 的优势是零部署、不占本地显存，适合交互式开发；本地部署的优势是隐私可控、长 token 成本低，适合批量生成代码。两份协同使用，效率最高。

6. 综合评分与选型建议

6.1 六个维度打分

整个实测跑完，我根据亲身感受给三个模型打了一个综合分，每个维度满分 10 分：

这三个模型都不是全能选手，优点是能帮你在不同场景里做出最顺手的选择。

6.2 按场景选模型：我的个人建议

如果你想要一个"快速验证想法"的工具，优先选 Step 5 Preview。它的首轮生成完成度高，几乎没有明显硬伤，适合做原型验证，甚至直接生成一个能玩的 Demo 发给产品经理看效果。

如果你在做一个需要长期维护的正式项目，DeepSeek V4 Pro 更值得信赖。它的代码组织方式最接近资深工程师的习惯，三次迭代结束之后，我还能轻松读懂它的代码结构，这种可维护性在 AI 生成代码里太稀缺了。

如果你的需求是中文文档和代码讲解密集的场景，比如教学、团队内部封装，GLM5.3 会更贴心——它的注释详细程度和学习友好性是另外两家比不了的，前提是你能容忍它偶尔的"过度设计"。

最后再分享一个我自己实测后的体会：任何一个模型的首轮生成结果都不应该被直接用于生产环境。真正有价值的用法是，先让模型生成完整框架，然后由人类工程师做一次 code review，把碰撞边界、状态流转、事件监听这类的关键点单独提出来检查一遍，再进入迭代循环。毕竟模型写代码的水平在快速上升，但"对代码全权负责"这件事，现阶段还是得靠人自己。