前阵子群里又吵起来了：有人说新模型写代码“又快又稳”，有人说“跑个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 126，i5-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 Preview | DeepSeek V4 Pro | GLM5.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 的工程结构会省后面的事；如果只是三分钟要看到可玩的demo，Step 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 |
|---|---|---|---|---|
| 轻快 | 8 | 8 | 2.0秒 | 4.0 |
| 标准 | 10.7 | 8 | 1.5秒 | 3.0 |
| 沉重 | 20 | 8 | 0.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这些约束全部写进第一段提示词，省下的调试轮次，比换一个“更强”的模型更实在。这也是我这次实测最重要的收获。
