三大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 ProDeepSeek 家的旗舰迭代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 跑酷游戏要求如下画面中有三条跑道玩家控制一个立方体角色在跑道间左右切换A/D 或方向键控制障碍物从远处生成并朝玩家方向移动碰到障碍物游戏结束玩家成功躲避一个障碍物分数 10 分游戏速度随时间逐渐加快需要完整的开始界面、游戏结束界面和分数显示全部代码放在单个 HTML 文件中通过 CDN 引入 Three.js双击即可运行干净的代码风格注释用中文三个模型拿到的都是这一份一字不差。2. 首轮同题答卷能不能自己跑起来2.1 三份代码的能不能跑直接对比首轮结果出来第一件事就是分别双击打开三个 HTML 文件。这一步就淘汰掉了一批隐形问题。下面这张表是我当时记录的实测状态对比项Step 5 PreviewDeepSeek V4 ProGLM5.3页面是否白屏正常显示正常显示正常显示障碍物数量与频率合理略密后期偏多合理碰撞判定准确度偶尔误判准确准确速度递增逻辑正常代码写了但首轮不生效正常游戏重开功能可用可用可用代码行数约 420 行约 510 行约 560 行中文注释完整性有偏少有中等有非常完整注意一个关键差异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 结构最好但有一个明显的小 bugGLM5.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 环境下的表现数据仅供参考指标Step 5 PreviewDeepSeek V4 ProGLM5.3桌面端平均帧率60fps60fps58fps安卓 WebView 平均帧率58fps60fps43fps首帧可交互时间0.2s0.2s0.3s任务内存占用约 85MB约 75MB约 110MBGLM5.3 那段粒子动画在移动端的开销比另外两家高出近一倍这一点在选型时必须考虑进去。5. 本地部署与 vLLM 镜像选型避坑5.1 为什么还有那么多人坚持本地跑虽然三家都有 API 可以用但社区里自部署的需求一直居高不下。原因不外乎两类一类是数据敏感代码片段不能出内网另一类是长对话的成本控制重度使用的时候 API 费用太不可控。再加上这次测试的热词里有 GLM5.3 搭配 vLLM 跑本地推理这类话题说明大家都很关心开源模型的本地落地。但本地部署这件事最大的坑往往不是模型本身而是推理框架的版本匹配问题。5.2 vLLM 镜像版本选择指南很多人在 GLM5.3 上用 vLLM 跑推理时最常遇到的坑就是版本不匹配。有人说 glm5.3 使用 vllm 哪个版本的镜像这个问题的答案其实没有定数核心原则是镜像版本必须匹配模型的 model_type 和对应的算子上限。判断逻辑其实很简单按下面这个流程走就行先打开模型目录下的 config.json搜索model_type字段看它属于哪个体系在 vLLM 官方文档或 GitHub Release Notes 里搜索对应的架构关键词看哪个版本开始支持如果你用的是量化版GPTQ/AWQ还要确认镜像里是否预编译了对应的量化算子这一项经常被忽略拿不准的时候直接用最新 stable 版本永远比用旧版稳我按这个思路整理了一个关于 GLM5.3 搭配 vLLM 的常见问题表同样适用于其它新模型报错信息原因解决办法KeyError: xxx_attn模型用了新的注意力实现当前 vLLM 不认识升级到支持该架构的版本AttributeError: module vllm has no attribute xxxvLLM 版本太旧缺少新接口升级或换官方镜像RuntimeError: CUDA out of memory上下文长度设置过长调低 max-model-len或开启 enable_chunked_prefillTypeError: forward() got an unexpected keyword argument模型结构和版本不匹配回退模型版本或换对应的 vLLM 镜像坦白说哪个版本的镜像从来都没有标准答案。我个人的习惯是先查模型在 apirelease 时官方有没有推荐过对应框架版本如果没有直接上最新版稳定镜像然后跑一个几百 token 的冒烟测试验证吞吐量再把 max-model-len 调到适合作业的长度基本就稳了。5.3 三款模型本地部署难度对比如果要从本地部署的难度给三个模型打分DeepSeek V4 Pro 是最省心的因为它的架构在 vLLM 生态里兼容性最成熟社区镜像最丰富基本上拉下来就能跑。GLM5.3 属于中等偏上如果恰好用了新结构就需要确认一下镜像版本。Step 5 Preview 的情况取决于它是否开放完整权重。给一个实用建议线上调试用 API稳定跑批用本地。API 的优势是零部署、不占本地显存适合交互式开发本地部署的优势是隐私可控、长 token 成本低适合批量生成代码。两份协同使用效率最高。6. 综合评分与选型建议6.1 六个维度打分整个实测跑完我根据亲身感受给三个模型打了一个综合分每个维度满分 10 分维度Step 5 PreviewDeepSeek V4 ProGLM5.3首轮生成可用性987.5迭代修改能力7.59.57.5代码结构工程化79.57.5移动端适配意识88.57中文注释与可读性77.59.5本地部署友好度7.597这三个模型都不是全能选手优点是能帮你在不同场景里做出最顺手的选择。6.2 按场景选模型我的个人建议如果你想要一个快速验证想法的工具优先选 Step 5 Preview。它的首轮生成完成度高几乎没有明显硬伤适合做原型验证甚至直接生成一个能玩的 Demo 发给产品经理看效果。如果你在做一个需要长期维护的正式项目DeepSeek V4 Pro 更值得信赖。它的代码组织方式最接近资深工程师的习惯三次迭代结束之后我还能轻松读懂它的代码结构这种可维护性在 AI 生成代码里太稀缺了。如果你的需求是中文文档和代码讲解密集的场景比如教学、团队内部封装GLM5.3 会更贴心——它的注释详细程度和学习友好性是另外两家比不了的前提是你能容忍它偶尔的过度设计。最后再分享一个我自己实测后的体会任何一个模型的首轮生成结果都不应该被直接用于生产环境。真正有价值的用法是先让模型生成完整框架然后由人类工程师做一次 code review把碰撞边界、状态流转、事件监听这类的关键点单独提出来检查一遍再进入迭代循环。毕竟模型写代码的水平在快速上升但对代码全权负责这件事现阶段还是得靠人自己。