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 PreviewDeepSeek V4 ProGLM5.3首次可运行率90%80%60%需求覆盖完整度高极高中代码组织与可维护性极高高中高物理与交互真实感中高高边界情况处理能力中高极高后续修改的响应质量高中高极高这张表基本能够反映我的整体感受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, encodingutf-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 }, timeout600) data resp.json() content data[choices][0][message][content] with open(foutput_{name}.html, w, encodingutf-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 碰撞体不生效与穿模问题速查表我把这次测试遇到的碰撞问题整理成了一张排查表也分享给你现象可能原因解决方向车辆直接穿过树木没有定义碰撞检测Two.js 中使用 Raycaster 或距离检测碰撞后卡死在原地碰撞后速度直接设为 0改为按碰撞方向反弹并设置一个最小阈值碰撞检测时灵时不灵使用了 AABB 盒子但忘记了坐标基准点确认碰撞体的中心点和物体的世界坐标一致跳跃后掉落时被树卡住垂直方向没有做碰撞把碰撞检测扩展到 Y 轴或使用多层物理引擎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.3GLM5.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 当作代码审查员。如果你手里也有这三款模型我强烈建议你也试一下这个分工组合——你可能会发现它们加在一起产生的价值比单独任何一款都高出好几个量级。
