1. 这次实测的来龙去脉

先说清楚我为什么要做这个对比测试。最近各家大模型密集发布新版本，Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三款模型在代码生成能力上都打出了各自的招牌。尤其有意思的是，它们几乎同时出现在开发者社区的讨论里，而且都被点名说能搞定复杂的游戏开发任务。

我自己的情况是：平时用 AI 辅助做前端和游戏原型比较多，之前用 DeepSeek 和 GLM 的老版本写过不少小游戏，对它们的脾气算是比较熟悉了。这次拿到 Step 5 Preview 的体验资格之后，我第一时间想到的就是做个横向对比，而且直接用"3D 游戏"这种对代码生成要求极高的项目来压测——毕竟 3D 游戏涉及坐标计算、相机控制、物理碰撞、场景管理、性能优化，任何一个环节拉胯都藏不住。

我还特意看了下网上的讨论趋势，发现一个有趣的现象：很多人问 GLM5.3 配合 vLLM 部署该用哪个版本的镜像。这其实暴露了一个需求——大家不只是想聊模型有多强，而是真的想跑起来、用起来。所以这次实测我不打算只报参数和分数，而是把完整的给三个模型下需求、收代码、修 bug、对比结果的流程记录下来，方便你在本地或者云端复现。

这场测试的核心思路很简单：同一个需求，原样发给三个模型，不做任何提示词技巧，看它们在理解意图、生成完整工程、自我纠错这三关里的真实表现。3D 游戏是一座很好的"照妖镜"，因为它天然要求高密度的数学运算、清晰的对象抽象、以及能把两者串起来的工程组织能力。模型如果只是记忆了一堆代码片段，在这个任务里会迅速露馅。

2. 测试环境与任务设计

2.1 硬件与部署环境

先说我的实测环境。我是在一台 4090 的机器上跑推理的，本地方案部署，三个模型都坐在同一个 HTTP 服务后面，用 OpenAI 兼容接口统一调用。这样做的目的是消除接口差异带来的干扰——我不希望 DeepSeek 是因为 SDK 封装好所以显得强，或者 GLM 是因为官方 demo 写得好所以显得强。统一接口之后，差异就只剩模型本身了。

模型版本上我做了确认：Step 5 Preview 是网页端体验版跑的标准 Preview 分支；DeepSeek V4 Pro 用的 API 通道；GLM5.3 我一开始是打算用 vLLM 部署本地权重，结果折腾镜像版本折腾了一会儿。这里先提个醒：GLM5.3 的需求图和 vllm 源码仓库里的 release 列表有对不上的情况，我后来是直接用官方文档指定的 image tag 才跑通的。具体的镜像选择问题我在后面的常见问题章节会展开聊。

2.2 为什么用 3D 游戏当考题

我见过很多人用 LeetCode 题、用 CRUD 系统、用正则表达式来测模型，这些当然有意义，但都不够"立体"。我选 3D 游戏的逻辑是这样的：

• 它天然是长上下文任务，不是一两百行就完事的那种。你要生成地形、天空盒、角色控制器、碰撞体、交互逻辑，随便一凑就好几千行。
• 它需要多文件工程能力。独立的 HTML 文件或者单文件 Python 脚本那是入门级，3D 游戏需要把模块拆开，模型得自己决定哪些东西放一起、哪些东西拆出去。
• 它涉及数学直觉。3D 坐标系、欧拉角、四元数、相机视线、重力、弹跳，任何一个角度算错，画面就直接崩了。
• 它要求"可运行优先"的思维。模型不能只写看起来对的代码，还要考虑浏览器 API、渲染循环、资源加载时序这些实际问题。

所以我想得很清楚：不管最后哪个模型赢了，这轮测试都能真实反映出一款模型做"完整工程"而不是"代码片段"的能力。

2.3 给三个模型出的同款题目

我给三个模型发送的是完全一样的自然语言需求，原封不动，没有任何增强提示。题目是这样的：

用 Three.js 写一个 3D 驾驶小游戏。场景是一个海岛，玩家控制一辆吉普车在岛上自由驾驶，可以切换第一人称视角和第三人称视角，车辆可以加速、刹车、倒车，遇到障碍物会碰撞并减速，场景里至少要有 10 棵树、3 块岩石、一片水面，背景要有天空盒，HUD 要显示速度和方向。代码放在一个 HTML 文件里即可。

我选择 Three.js 是因为它是 3D Web 领域的事实标准，浏览器直接跑，方便验证。要求所有代码放在一个 HTML 文件里，是为了降低部署门槛，也方便我看清楚模型对"完整可运行程序"的理解——真正的单文件工程和随便堆一坨能跑的代码，差别是非常明显的。

3. 三款模型的实际表现对比

3.1 Step 5 Preview：架构完整，但小坑不断

先说 Step 5 Preview。它的输出给我的第一印象是"工程感"很强——注意，是 Engineering 的工程感，不是 Demo 的演示感。它生成的 HTML 文件头一次就跑出了完整画面，岛的地形、车辆模型、树木分布、水面反射都齐了，第一人称和第三人称切换也有——这是三个模型里唯一一个第一次跑就交出完整交互的。

但我很快就发现了两个问题。第一个是车辆碰撞用的只是简单的距离判断，也就是每棵树和岩石被当作一个球形碰撞体，用"车辆位置到物体中心点距离是否小于某个阈值"来做碰撞。这种方式在演示层面能凑合，但车撞到树的时候会直接穿模，因为没有把碰撞后的速度衰减做得细腻。第二个问题是它的第三人称相机逻辑有点抖，车速高的时候相机跟随有轻微滞后感，这在游戏里会表现为视角眩晕。

不过话说回来，Step 5 Preview 在代码组织上是真的强。它把场景初始化、车辆类、环境物体类、输入处理、UI 更新分成了清晰的段落，这种分层思维对后续改需求非常友好。我后来尝试把水面改成动态波动效果，它只改了十几行代码就做到了，这种"可维护性"是硬实力。

3.2 DeepSeek V4 Pro：老练，但偏保守

DeepSeek V4 Pro 的表现极其稳定，稳定到有点"老练"的感觉。它的生成结果第一眼没有 Step 5 Preview 那么炫，水面是简单的贴图而不是实时反射，树的模型也是简单的几何体组合，但关键是——所有的东西都是按照我需求文档里的要求来的，一个条件都没漏。

我特别留意了它在碰撞处理上的做法：它的碰撞响应边界做得更扎实，车撞到树之后不是简单地停下，而是根据撞击方向产生轻微反弹，运动状态的变化更有真实感。这种细节说不上高级，但是明显能感觉到模型作者在训练数据里对"物理真实感"是有偏好的。

DeepSeek V4 Pro 的另一个优势是代码注释特别到位。它不是那种敷衍的"// 初始化相机"这种废话注释，而是会在关键算法段落前面解释为什么这么写。比如它的水面波动算法，注释里说明了用的是 sin 函数叠加而不是噪声，是因为性能开销考虑。这种"解释为什么"的注释，说明模型对自己的代码是有"理解"的。

3.3 GLM5.3：爆改狂魔，惊喜与惊吓并存

GLM5.3 是这次测试里最让我意外的一个。它的初始输出质量只能说中规中矩——树的数量刚好满 10 棵，岩石刚好 3 块，水面有了但反射效果一般，跑起来倒是稳当。但真正让我改观的是后续改需求的环节。

我提了一个需求：加上跳跃功能，按空格键让车跳起来，跳过矮小障碍物应该可以直接过去而不是碰撞减速。这个需求对大部分模型来说是考验，因为它要求临时在物理系统里加一个"垂直速度"的概念，并且要处理好落地瞬间的碰撞。GLM5.3 给出的实现非常惊艳：它不仅加了跳跃，还额外处理了"跳跃中碰撞减弱""落地缓冲"和"跳跃后如果撞到树则强制回位"三个边缘情况——这种对边界情况的主动覆盖，说明它对需求的理解不是字面的，而是语义层面的。

当然，GLM5.3 也有翻车的时候。它的初始代码里，天空盒用的贴图加载方式存在跨域问题，直接跑起来背景是纯黑，只有调试了几分钟之后才发现是资源加载失败而不是渲染逻辑错误。这一项在"开箱即用的稳定性"得分上是被扣了分的。

3.4 横评：三份答卷的拆解对比

我把三个模型的输出从几个维度做了打分，分数是主观的，但代表了我在同一标准下的真实感受：

这张表基本能够反映我的整体感受：Step 5 Preview 适合"从零搭框架"，因为它的架构品味很好，修修补补的时候你心里有谱；DeepSeek V4 Pro 适合"要稳稳交付"，它的输出不会让你半夜被 bug 弹醒；GLM5.3 适合"越玩越觉得它有上限"，因为它对模糊需求的扩展能力真的太强了。

4. 实操过程：从提示到可运行游戏的全流程记录

4.1 第一步：确认模型接口正常

测试的第一步不是写代码，而是确认三个模型都通了。我写了一个轻量的 Python 验证脚本，作用是把同样的需求轮流发给三个模型，并把返回的 HTML 内容保存为不同文件名。这一步的意义在于：确保后面的对比不是因为我接口配错了而出现偏差。

import requests import json models = { "step5": "http://localhost:8001/v1/chat/completions", "deepseek_v4pro": "http://localhost:8002/v1/chat/completions", "glm53": "http://localhost:8003/v1/chat/completions" } prompt = open("prompt.txt", encoding="utf-8").read() for name, url in models.items(): resp = requests.post(url, json={ "model": name, "messages": [{"role": "user", "content": prompt}], "temperature": 0.2, "max_tokens": 8000 }, timeout=600) data = resp.json() content = data["choices"][0]["message"]["content"] with open(f"output_{name}.html", "w", encoding="utf-8") as f: f.write(content) print(f"{name}: {len(content)} chars")

这里有个细节要说明：max_tokens 我设到了 8000。这个数字是有讲究的——如果设得太小，模型可能在生成到一半的时候被迫截断，整个 HTML 文件不完整；设得太大则没必要，因为生成超过 8000 token 的 HTML 说明它大概率在写重复代码。我在实测中发现，Step 5 Preview 的输出大约在 5200 token 左右，DeepSeek V4 Pro 在 4600 左右，GLM5.3 则到了 6100 左右——注意 GLM5.3 的输出长度明显更长，因为它做了更多的注释和额外的功能封装。

4.2 第二步：运行 HTML 的标准化操作

三个模型生成的 HTML 文件我都是用同一套方法来跑的，确保没有引入人为差异。先把文件放到一个本地静态服务器里——注意这里不能直接双击用 file:// 协议打开，因为 Three.js 加载纹理贴图时会有跨域问题，大部分模型都不会帮你把这个坑绕过去，所以我们测试时就不把这个当成模型的错，但实际部署时必须处理好。

cd output_dir python -m http.server 8090

然后在浏览器里打开 http://localhost:8090/output_step5.html，依次切换 F5 刷新、移动 WASD 键、调整视角按键（一般是 C 键切视角）、试碰撞。我把每辆车的表现都录成了短视频片段，方便后面做细节对比。

这里有一个非常重要的实操经验：跑 AI 生成的 3D 游戏代码，浏览器控制台必须开着。很多模型生成的代码在首屏渲染上是好的，但只要一互动，控制台就会刷出各种报错——常见的有：undefined 变量、纹理加载失败、requestAnimationFrame 没有初始化。如果你的浏览器控制台是关着的，很多错误信息你根本看不到，你会觉得"怎么车撞到树之后直接消失了"——实际上控制台早就在告诉你"collision object is null"了。

4.3 第三步：交互操作的完整验证清单

我给自己列了一张交互操作清单，逐项验证，而不是只凭肉眼看看画面好不好看：

• 车辆是否可以在 W 键下前进，S 键后退，A/D 左右转向
• 加速是否逐级提升，还是突然从 0 跳到 100
• 踩刹车之后车辆滑行距离是否合理
• 第一人称视角下，相机是否绑定在车辆位置上方
• 第三人称视角下，相机是否平滑跟随而不是生硬跳跃
• 碰撞之后车辆速度是否有衰减，还是直接穿模
• 跳跃功能（后续添加的）是否在落地瞬间有缓冲
• 水面区域是否有明显边界，车辆开进去会怎样
• HUD 的速度表是否实时更新，方向显示是否准确

这张清单帮我筛掉了大量"看起来不错但一碰就坏"的生成结果。我可以告诉你：三个模型在前 4 项都表现很好，但在第 5 项之后差异开始拉开。GLM5.3 在第一人称视角下的处理是最自然的，因为它的相机位置计算考虑了人体高度，而不是简单地贴住车顶。Step 5 Preview 在碰撞衰减上做得不够细，会导致车辆撞到树后仍然保持较高速度，这在操控手感上非常出戏。DeepSeek V4 Pro 只能在"车辆开到水面上会不会掉进去"——它把水面也当成了碰撞体，车会直接停在半空中，这个虽然没有完全合理的物理逻辑（毕竟水应该淹过去而不是挡住），但至少比穿模要稳。

4.4 第四步：修改需求的响应质量对比

完成基础运行后，我给每个模型都追加了同一个新需求：在场景里加一种"加速道具"，车碰到之后获得持续 5 秒的 1.5 倍速度加成，HUD 上要显示剩余加速时间。

这个需求看起来简单，实际上非常考验模型对已有代码的理解程度。Step 5 Preview 在原有架构上添加道具对象时做得非常干净，但生成的道具是静态悬浮的，没有旋转动画；DeepSeek V4 Pro 生成的道具会绕 Y 轴匀速旋转，和整体风格非常统一，但它把 1.5 倍速度写成了 1.5（直接数值），导致修改倍率必须去代码里找；GLM5.3 则是最夸张的——它额外增加了道具刷新逻辑（每 10 秒在随机位置生成新的道具），并且把"剩余加速时间"在 HUD 上用了一个进度条来显示，而不是单纯数字。

这轮下来我基本上确认了一个判断：这三款模型的能力上限都不低，但侧重点不同。Step 5 Preview 是"架构师思维"，DeepSeek V4 Pro 是"交付者思维"，GLM5.3 是"创造者思维"。对于游戏开发者来说，你选哪款取决于你缺什么。

5. 常见问题与排查技巧实录

5.1 GLM5.3 部署时的 vLLM 镜像版本问题

这一节我想重点说一个这两天社区里被反复问到的实际问题：GLM5.3 用 vLLM 部署时该用哪个版本的镜像。我实测的结论是：不建议直接拉最新 tag，因为 GLM5.3 发布时引入了一些新的算子要求，vllm 主干代码还没有完全跟上。我试过 vllm/vllm-openai:latest，启动时报错提示缺少某个 attention 实现，后来换成官方文档指定的镜像版本（比如 vllm/vllm-openai:v0.8.x 系列中的对应版本）就正常了。

我的建议是：不管你是用 Docker 还是裸机部署，先去 GLM 官方 GitHub 仓库的 README 里查它明确标注的 vLLM 版本号，再来决定镜像 tag。不要盲目用 latest，因为 latest 有时候遥遥领先，但 GLM5.3 的权重未必兼容。这个问题在 DeepSeek 和 Step 5 的部署上没有碰到，算是 GLM 特有的小坑，但也不是无解。

5.2 3D 资源加载失败导致黑屏或纯色背景

三款模型生成的代码里，第一个容易踩的坑都是"纹理加载失败导致背景黑屏或者其他异常画面"。表现是：你能看到树木和车辆，但背景是纯色或乌黑一片，然后控制台报 CORS 错误。这在本地用 file:// 协议打开时尤其常见，正确做法是起一个本地 http 服务，或者用 Python 的 http.server，或者在 VS Code 里用 Live Server 插件。

如果你跑模型生成的 HTML 时发现画面不完整，第一步永远是看控制台报错，而不是去猜代码哪错了。80% 的 3D 场景问题都是资源加载问题，不是渲染逻辑问题。

5.3 车速表不更新或者方向显示不对

这个问题比较隐蔽。模型生成的 HUD 逻辑里，车速表通常通过每帧读取车辆的当前速度向量来计算。但有些模型会错误地把速度向量一直取成初始值，导致车速表永远显示 0 或者固定值。排查思路很简单：在控制台打印车辆的 velocity 属性，看它是否持续变化。如果 velocity 变了但 HUD 不变，那就是 UI 更新逻辑的引用问题；如果 velocity 本身没变，那就是车辆物理更新的代码根本没执行——这种情况通常是 requestAnimationFrame 循环写错了，把更新语句写在循环外了。

5.4 碰撞体不生效与穿模问题速查表

我把这次测试遇到的碰撞问题整理成了一张排查表，也分享给你：

5.5 镜头跟随抖动与视角眩晕

第三人称相机抖动是 3D 游戏生成中特别常见的问题。我测试下来，Step 5 Preview 的初始版本存在这个问题，原因是相机的位置直接设置成了车辆位置加上固定偏移，没有做平滑插值。解决办法是用 lerp 插值让相机缓慢跟随，而不是每帧直接跳到位。

// 第三视角相机跟随的改进写法 const targetPos = vehicle.position.clone().add(cameraOffset); camera.position.lerp(targetPos, 0.08); camera.lookAt(vehicle.position);

这个 0.08 是 lerp 的插值系数，系数越小跟随越平滑但延迟越大，实际使用时建议在 0.05 到 0.12 之间调节。这个技巧同样适用于 AI 生成的代码——我改完 Step 5 Preview 的相机逻辑之后，之前差点让人晕车的视角问题直接消失了。

6. 针对不同需求的模型选择建议

6.1 从零到一搭原型：选 Step 5 Preview

如果你拿到一个全新的游戏创意，脑子里还没有清晰的工程蓝图，需要模型帮你把框架搭建出来，我推荐 Step 5 Preview。它的强项在于架构分层清晰，生成的代码像是一份不错的样板工程。你在它生成的代码上做修改，就像给毛坯房装修，砸墙的地方少，布线的地方也明白。

我自己在测试过程中就有这种感觉：当你想增加一个功能，你能立刻知道去代码的哪个部分改，而不是在一堆 2000 行的面条代码里大海捞针。这种"可定位性"对于长期演进的项目价值极高。

6.2 追求稳定交付和生产复用：选 DeepSeek V4 Pro

如果你的需求描述非常明确，而且你要的是一个"能直接上线跑"的东西，DeepSeek V4 Pro 是我更稳的选择。它的输出可能不会给你惊喜，但它的出错率低，边界处理更严谨，你能省去大量的调试时间。特别是对于商用或者半商用项目，稳定性的价值比炫技高得多。

实测中，DeepSeek V4 Pro 生成的碰撞逻辑、水面边界判断、相机过渡逻辑都是最接近"可用"水平的。它的注释也写得恰到好处，团队协作时不会看不懂。

6.3 做实验、改需求、深度迭代：选 GLM5.3

GLM5.3 更适合愿意和模型打交道的开发者，尤其是你在已有代码上不停地叠加需求的时候。它的"理解语义"能力是三者里最强的——一个模糊的"加个跳跃功能"，它能帮你想到跳跃后的各种连带事件；一个"加速道具"，它能顺手把道具刷新和 HUD 显示一起做完。这种主动补齐边界的能力，能显著放大你的开发效率。

不过你要做好心理准备：GLM5.3 生成的代码稳定性没有前两者好，初始版本大概率需要你手动修几处资源加载或初始化的问题。但修完之后，你会发现它的潜力上限确实高。

6.4 开源安卓 3D 游戏场景的补充建议

这几天有人问到一个相关问题：能不能用这些模型直接生成开源安卓 3D 游戏？我的回答是可以，但要换一套生成思路。不要直接让模型写安卓原生代码，而是让它生成 WebGL 版本，然后用 Capacitor 或 WebView 包装成安卓应用。这样三个模型的能力都能发挥出来，且部署和调试门槛大幅降低。

如果你用这个方案，模型的选择策略和上面的结论一致：先用 Step 5 Preview 生成 WebGL 工程框架，再用 GLM5.3 做玩法迭代和功能扩展，最后用 DeepSeek V4 Pro 做一轮稳定性修正和代码审查——三款模型各司其职，效果比单打独斗强很多。

7. 我踩过的坑和总结建议

最后说说我这一整轮测试下来最大的感受。三款模型都不是万能的，但把它们当作一个组合拳来用，效率是真的恐怖。我在测试期间，从部署三个模型到完成三轮需求迭代，一共只花了不到一个下午。放在两年前，这种"给一段自然语言需求就拿到一个可运行的 3D 游戏"的工作流，想都不敢想。

不过我也必须泼一盆冷水：AI 生成的代码离"生产级"还有不小的距离。尤其是 3D 游戏这种对性能和细节要求极高的领域，自动生成的代码在帧率优化、内存管理、多平台适配这些方面仍然非常薄弱。好处是，AI 真正把开发者从"怎么写"里解放了出来，让大家能把精力放在"写什么"和"怎么改更好"上。

我个人后续的实践方向是：把 Step 5 Preview 当作我的"架构师"，把 GLM5.3 当作"玩法策划"，把 DeepSeek V4 Pro 当作"代码审查员"。如果你手里也有这三款模型，我强烈建议你也试一下这个分工组合——你可能会发现，它们加在一起产生的价值，比单独任何一款都高出好几个量级。