前阵子群里又吵起来了有人说新模型写代码“又快又稳”有人说“跑个demo行上个真项目还是拉”。吵不出结果我干脆做了一件笨事——把三款热度很高的模型拉到同一考场Step 5 Preview、DeepSeek V4 Pro、GLM5.3命令只有一个让它们各自开发一款3D跑酷游戏。整个实测从晚上九点搞到凌晨一点过程里踩了不少坑也看到了三个模型完全不同的“性格”。这篇文章就是把这次实录整理出来三款模型分别写出了什么样的3D游戏、哪里有亮点哪里翻车、我为了公平对比做了哪些设置以及总结出的几条提示词经验。对还在观望选型或者正在用AI做小游戏原型的朋友值得花几分钟看看。1. 我为什么拿3D游戏当三款模型的统一考卷1.1 为什么是这三款模型Step 5 Preview 名字后面挂着 Preview说明它还是个预览版本。挑它不是因为名气而是想看看预览版在真实干活时的稳定度。之前我用过不少预览版模型往往在宣传里很强、上手就露馅这次正好借3D游戏这种完整任务验证一下。DeepSeek V4 Pro是近期讨论度很高的代码模型主打推理和代码生成社区里有人说“补个函数很顺做整个项目未必”我想验证这句话到底公不公平。GLM5.3走的是通用加中文优化路线这段时间经常和 doubao-seed-2.0-code 这类新代码模型放在一起比较中文需求理解是它的卖点那咱就专门用中文写需求喂给它看反应。这三款模型各有侧重其实代表了三种典型选手预览版黑马、代码专长选手、中文泛用型。用同一个任务去比比的不是“谁参数多谁更强”而是“谁更懂人话、更能交付能跑的东西”。毕竟我们在真实开发里要的就是后者。1.2 3D游戏为什么比算法题更难混3D游戏是一个端到端工程不只是返回一行答案。三维数学、状态机、场景组织、用户交互、性能优化全都要一次到位任何一个环节出了岔子画面立刻给你脸色看。空间几何角色移动要处理三维向量障碍物旋转要处理欧拉角模型一旦把x/y/z搞混角色下一秒就可能飞出屏幕外。状态流转等待、奔跑、跳跃、坠落、结束好几个状态之间不能乱跳跳跃中按切换跑道、坠落时按重开这些边界情况不处理好游戏一玩就穿帮。场景资源几何体、材质、光照、相机、动画循环如果组织得乱想在哪个环节加点需求都容易翻车。完成度它不是一个能算出结果的函数而是要求双击打开就能玩键盘和触摸都要响应死了能重开分数不能乱跳。所以拿3D游戏当考卷其实就是让模型完成一个真实可交付的小产品。中间任何一个环节出问题都能立刻看到不会给你“评分标准模糊”的空间。2. 同样的提示词才能公平比测评设计与指标2.1 任务需求一段提示词写清楚所有验收条件这次实测我用的提示词是固定的三款模型拿到的原文一模一样不存在“给A写小作文、给B只甩半句话”的偏袒情况。完整提示词如下用 Three.js 写一个 3D 跑酷游戏要求 1. 玩家是一个白色方块沿三条跑道前进按 A/D 或左/右箭头切换跑道 2. 按空格/上箭头/屏幕点击跳跃跳过红色障碍方块 3. 障碍物从远处随机生成速度随时间逐渐加快 4. 碰到障碍物游戏结束显示分数分数等于存活距离 5. 点击“重新开始”按钮可以重新游戏 6. 全部代码放在一个 HTML 文件中使用 CDN 引入 Three.js 7. 适配桌面键盘与移动端触摸 8. 代码中加中文注释。这个提示词看起来简单其实每个条件都在堵漏洞。写清键位是避免模型自由发挥出一套谁都看不懂的操作写清计分方式是避免出现“分数只是装饰跟距离无关”的情况写清单文件是方便我统一在浏览器里跑加中文注释是为了考察模型在可读性上的表现。我没有在第一轮提示词里写“不要用模块化引入”结果有一款模型真的用了 import map本地打开直接报错这个后面细说。第一轮测试的目的就是要看模型面对不完整约束时能不能自己做出合理假设。2.2 评价维度不只看跑不跑得起来三款模型最终大概率都能把游戏做出来但“能玩”和“好玩”是两回事“一次跑通”和“改五轮才跑通”也完全不是一个体验。所以我设计了五个维度来记录每一轮的产出维度说明评分方式首轮可运行率拿到代码后能不能直接跑起来而不是一打开就是白屏是/否需求符合度首轮生成是否真正理解了“跑酷动态生成”的核心玩法百分比主观估计调试轮次从我提出修改意见到最终达到理想体验一共需要几轮数值记录代码结构模块划分、命名规范、注释质量主观评分性能与兼容桌面和手机端的帧率、触摸支持、画面稳定性主观评分每轮对话的统计口径也做了约定三款模型都是冷启动不给示例代码不提供任何参考实现完全凭模型自己的记忆和推理来完成。中途我提修改意见时也只描述现象和目标不告诉它具体改哪个函数这样测出来的才是模型的真实调试能力而不是“你按我的指引改就一定能成”。2.3 测试环境同一浏览器、同一脚本、同一起跑线环境统一也很重要。我用的是一台 Windows 11 台式机Chrome 126i5-13490F 处理器RTX 4060Ti 显卡16GB 内存。手机是 Windows 电脑旁边的安卓中端机屏幕1080P用来验证移动端兼容。所有项目文件都放在本地目录里用python -m http.server 8000起了一个静态服务再通过浏览器访问。这一步很关键因为有很多模型生成的HTML不是纯script标签引入的而是用了ES Module如果直接用file://协议双击打开浏览器会因为跨域问题拒绝加载Three.js页面看起来就是白屏。为了公平起见我先在本地缓存了Three.js r160版本避免某个模型依赖的CDN意外抽风。测试时间都放在同一时段网络波动的影响几乎可以忽略。每轮生成的结果我都单独保存下来方便后面回看代码差异。3. 轮番实测三款模型各自生成游戏的全程记录3.1 Step 5 Preview首轮可玩碰撞判定“虚胖”Step 5 Preview 第一轮生成耗时大约30秒输出约400行HTML。打开页面那一刻我的评价是“干净”浅灰天空、网格地面、白色方块角色、红色障碍物角色跑动、跳跃、切道都有分数在右上角稳定跳动。这个完成度比我预想的预览版水平要高。但是玩了大概三分钟问题来了——好几个障碍物看起来明明从身边擦过去了却突然弹出“游戏结束”。这说明碰撞判定出了问题。打开代码检查发现它没有用Three.js自带的Box3来做碰撞而是手写了一个包围盒判断碰撞区域是一个硬编码的矩形范围障碍物视觉尺寸是0.8碰撞范围却按1.2算等于视觉上躲开了20厘米判定上还属于“撞上”。这就是传说中的“虚胖碰撞体”看着能玩一细玩就露馅。我提了第一轮修改意见“碰撞体尺寸与障碍物视觉尺寸不对等请先获取障碍物自身的boundingBox再做AABB相交判断。”它很快改完这次手感准了。后续我又让它把跳跃改为物理抛物线加了屏幕自适应总共三轮调试后最终版本桌面稳60FPS手机上约45FPS算中规中矩。Step 5 Preview给我留下的印象是首轮交付能力确实强但细节bug属于“跑起来才知道坏”的类型。如果你不实际玩一下光看代码很难发现问题。3.2 DeepSeek V4 Pro结构最工程化却把跑酷做成了跳格子DeepSeek V4 Pro 生成的代码大约500行打开第一眼我就愣了——它把逻辑拆成 GameMain、Player、ObstacleManager、UI 四个类还有人机交互模块。这个工程结构可以直接拿去做代码评审比很多开发者自己写的还规整。初次运行没有任何报错角色跑动、跳跃、切道全正常。但玩了几局以后我发现了不对劲所谓“随机生成障碍物”是开局时把所有障碍块的Z轴坐标一次性排好玩家不是迎面躲避而是像玩跳格子一样一格一格跳过去。速度加快也只是把排布间距缩短并没有做“前方动态生成、后方销毁”的逻辑。这跟我要求的跑酷核心玩法有本质差别。我第二轮提示词专门追加了一句“请改为按玩家位置动态生成前方障碍物并回收已过期的障碍物”。它接受得很爽快把整个 ObstacleManager 重写了一遍新版本的障碍物会在前方15个单位外随机出现越过玩家后自动销毁跑酷感一下就出来了。第三轮它补上了移动端触摸支持第四轮解决了低端手机上的阴影渲染卡顿。DeepSeek V4 Pro的问题在于它更擅长“重新组织一个模块”而不是“第一次就完全理解你的中文口语长句”。它的输出工程化程度最高但你需要有点代码能力能自己发现问题并给它明确方向。3.3 GLM5.3中文注释最全跳跃手感很一言难尽GLM5.3生成的HTML有480行开头部分有一段非常完整的说明注释把操作方式、计分逻辑、未来扩展方向全写在里面。变量名是英文注释是中文夹在一起读起来非常轻松这一点对中文开发者是真友好。但它有个明显的“性格差异”默认使用的是 import map ES Module 方式加载Three.js本地双击HTML打不开必须起HTTP服务才能跑。我试跑的时候差点以为它生成失败了后来才发现卡在模块加载上。这也提醒我第一轮测试的提示词里确实应该提前说清“请一律使用 script 标签引入 CDN”。跑起来之后动作表现又出了状况跳跃的滞空时间明显偏短角色像被重力死死拽住一样下落速度很快跳跃按键连打也连不起来。查代码发现它设的是重力20、跳跃速度8算下来滞空只有0.8秒对1个单位见方的方块来说手感太“重”了。我让它改成重力12、跳跃速度9再把触摸事件绑定到canvas并阻止默认缩放之后手感立刻正常跑酷那种“轻快”的感觉才算出来。GLM5.3的代码可读性和注释水平三款里最好但对游戏物理参数的默认值拿捏不住需要做一轮“手感校准”。说白了它更像一个“认真但缺游戏经验”的开发新手代码写得很规矩一到手感调优就露怯。4. 横向复盘同一款3D游戏三款模型差在哪4.1 先看一张纵向对比表三款模型完整测试下来数据放在一起看比较直观对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3首轮可运行是直接可玩是直接可玩需起HTTP服务首轮需求符合度约80%约65%约75%达到理想体验的调试轮次3轮4轮4轮代码结构单文件流程式类拆分清晰函数模块化注释全中文注释较好一般最好移动端适配基本可用需补触摸逻辑原生较好桌面帧率60FPS稳定60FPS稳定60FPS稳定中端机帧率约45FPS偶发掉帧中规中矩最终三款模型都能做出可玩的游戏这点首先要肯定。差异主要体现在“首轮理解偏差”和“调试成本”上。Step 5 Preview 赢在直给DeepSeek V4 Pro 赢在工程组织GLM5.3 赢在可读性。4.2 结构完整度类拆得越细不等于越好看DeepSeek V4 Pro 和 GLM5.3 的代码结构都比 Step 5 Preview 更工整但工整对“又长又宽”的项目有好处对单次生成的500行小游戏来说四五个类之间的引用关系反而增加了第一轮出bug的几率。Step 5 Preview 把东西全部写在一个流程里虽然代码Review起来没那么舒服胜在直观、状态逻辑不容易串线。这里我想说句公道话如果你打算拿AI生成的原型继续迭代到上线那么 DeepSeek V4 Pro 的工程结构会省后面的事如果只是三分钟要看到可玩的demoStep 5 Preview 的“一把梭”反而体验更好。代码结构是“好”还是“坏”完全取决于交付阶段。4.3 3D视觉表现画面不只拼能不能跑三款模型都做了环境光加平行光但视觉氛围有差异。Step 5 Preview 只给地面加了一个网格纹理没有天空盒画面显得干。DeepSeek V4 Pro 加了背景雾效和深色渐变天空跑动时的速度感最强。GLM5.3 默认开启了抗锯齿antialias方块边缘更平滑但物体材质上选了偏卡通的风格和另外两款风格区分明显。移动端操作上GLM5.3 体验最好因为它把 touch 事件绑定在 canvas 上还顺带阻止了页面滚动缩放。Step 5 Preview 能用但偶尔会误触DeepSeek V4 Pro 第一版根本没有触摸事件是我单独提出来才补上的。画面表现这一块最终效果 DeepSeek V4 Pro 的最有氛围感但那是建立在多两轮调试的基础上。如果是零调试直接看首轮GLM5.3 的观感反而最完整。5. 实测中踩过的坑碰撞体、重力与移动端适配5.1 碰撞检测的尺寸幻觉这次测试里三款模型有一个通病视觉上的物体大小和碰撞判定的尺寸对不上。原因很典型——模型生成静态代码时“看见”的是代码里的数字而不是画面里实际渲染的效果。当障碍物用 scale 参数整体放大或缩小时手写碰撞范围往往仍然按原始几何体尺寸来算结果就是玩家“明明躲过了”却被判定为撞上。这个坑在Three.js项目里非常高频。我的解决办法是直接在提示词里声明一条硬性规定所有物体不要使用scale缩放要改大小就直接改几何体参数碰撞检测请基于场景中真实物体的boundingBox计算禁止手写碰撞矩形。加了这句话之后再让模型重写碰撞逻辑基本不会再出现“虚胖碰撞体”。这算是我实测下来性价比最高的一条提示词经验。5.2 重力与跳跃手感计算GLM5.3 那个手感问题让我意识到模型对游戏物理参数的默认值往往来自“教科书”而不是真实玩游戏的感受。重力加速度设成20、跳跃速度8数值看着正常实际跳起来又沉又短。跳跃手感可以套一个简单的物理公式来算滞空时间 T 2 × v0 / g最高点 H v0² / (2 × g)。其中 v0 是起跳初速度g 是重力加速度。我整理了一个参数表方便你直接抄目标手感重力 g起跳速度 v0滞空时间 T最高点 H轻快882.0秒4.0标准10.781.5秒3.0沉重2080.8秒1.6对1个单位见方的3D方块角色我建议从“标准”档起步。如果做的是体型更大的角色再把最高点整体放大。实测下来给模型一个“滞空约1.5秒、最高点约3个单位”的明确数字比让它自己调重力靠谱得多。5.3 触摸响应与移动端优化三款模型在移动端的表现参差不齐核心问题有两个。第一个是事件绑定位置有的模型把 touch 事件绑定到了 window 上导致手机浏览器滑动页面也会触发游戏跳跃正确做法是绑定到 canvas 上并且调用e.preventDefault()阻止默认行为。第二个是渲染分辨率很多模型会直接写renderer.setPixelRatio(window.devicePixelRatio)在像素比是3的旗舰手机上这个写法会把渲染压力拉满中端机直接卡成幻灯片。我后来干脆把移动端要求也写进了提示词模板移动端要求touch事件绑定canvas并阻止缩放renderer.setPixelRatio( Math.min(window.devicePixelRatio, 2) )。加上这句之后三款模型生成的游戏在中端手机上都能稳定跑在40FPS以上。这个优化思路不限于跑酷游戏所有Three.js移动端项目都适用。5.4 单文件还是模块化这次实测为了公平我统一要求单文件HTML。但如果你真的打算把一个AI生成的小游戏放到线上我建议反过来先让它生成单文件跑通核心玩法再让它把代码拆成 ES Module 的多个文件。因为单文件调试方便、分享方便但变量作用域和状态管理一复杂起来就够呛而模块化代码更适合长期维护、加新功能。我自己在项目里的流程是第一步追求“能玩”第二步追求“能维护”。这两个目标适合用两轮独立对话来完成而不是在一轮里混着说。6. 本地部署GLM5.3再实测vLLM镜像选择有讲究6.1 同一模型不同量化版本表现不同首测用的 GLM5.3 是云端API整体表现稳定。但我一直好奇一件事同样一个模型如果自己部署会不会因为量化方式不同导致生成效果有差异。于是我在本地又跑了一轮用同一份提示词分别测了不同版本。结果确实有差异FP8版本的生成结果保留了完整的中文注释和跳跃函数AWQ版本在部分轮次会出现中文注释漏写偶尔把跳跃逻辑简化残缺。这种差异一方面来自量化对参数空间的损耗另一方面也可能和推理框架的算子实现有关。不能简单说“AWQ一定会变笨”因为换一个提示词可能结果又不一样。但如果你对输出质量要求高尤其是代码生成这种长周期任务量化等级的影响值得重视。6.2 vLLM版本跟着模型卡走别追新很多人在部署GLM5.3时都会纠结一个问题vLLM到底该用哪个版本我自己实测的经验是先看模型卡。主流模型发布时都会标注“tested with vLLM x.x.x”照着这个版本装最省事。你装最新版vLLM遇到的往往不是“跑不起来”而是算子和模型权重不匹配导致生成结果异常但不报错这种软故障最难排查。镜像选择也一样。优先用模型发布方提供的官方Docker镜像社区镜像虽然新但也容易踩FlashAttention版本不兼容、CUDA算子对不上的坑。如果你只是API用户完全不用关心这些但如果你是本地部署给团队用的人这个决定会直接影响输出质量。6.3 显存与量化FP8、AWQ、GGUF怎么选部署GLM5.3这类模型时量化方式无非就那几种我按实际效果排了个优先级量化方式显存占用代码生成质量部署难度FP8较高接近原版低AWQ中较好中GGUF低中文注释偶有遗漏低如果显存允许做代码生成场景我优先建议FP8别为了省显存牺牲长文本输出的稳定性。如果必须在8到12GB的显卡上跑AWQ能用但一定要用同一份提示词多跑几轮验证输出是否稳定而不是看一两次结果就下结论。最后说点自己的体会。这几轮测试跑下来最深的感觉是拿“谁更强”这种问题去问模型没有意义关键还是看你要交付什么。Step 5 Preview胜在直接DeepSeek V4 Pro胜在工程结构GLM5.3胜在可读性与中文体验。可真正影响交付体验的往往不是模型本身而是提示词里的验收标准是否写全。我下一轮再测会把碰撞尺寸、重力参数、单文件CDN这些约束全部写进第一段提示词省下的调试轮次比换一个“更强”的模型更实在。这也是我这次实测最重要的收获。
