最近 AI 编程圈又打起来了。Step 5 Preview 刚放出来，DeepSeek V4 Pro 紧跟着刷榜，智谱那边的 GLM5.3 也带着 FlashX 版本到处跑分。铺天盖地的 benchmark 表格看得人眼花，但说实话，跑分跑不到真实需求里。我干脆把三个模型拉上同一个裁判席：给同一句需求，写同一个 3D 游戏，全部在浏览器里跑起来看效果。这轮实测折腾了整整两天，中间踩了资源幻觉、Three.js 版本差异、本地部署 vLLM 镜像不兼容这些坑，今天把过程完整写出来。
1. 为什么用“3D 小游戏”当考题
1.1 这份考题哪里难
先解释一下为什么选 3D 游戏而不是 LeetCode 或者 TODO 应用。现在的大模型写单点算法已经卷到头了，树、图、动态规划都能背得滚瓜烂熟。但“3D 游戏”是一个完整的工程项目：要处理场景初始化、随机地图生成、角色控制、碰撞检测、UI 交互、胜负条件，甚至还要考虑性能。任何一个环节掉链子，游戏就跑不起来。
更重要的是，3D 游戏对“空间理解”的要求特别高。模型不仅要写出合法的 Three.js API 调用，还要想清楚坐标系怎么摆、相机放在哪里、玩家移动时碰撞体怎么更新。这些能力是传统代码评测测不出来的。我在设计考题时故意没有给模型拆分模块，就让它们从零开始写一个单 HTML 文件的小游戏，看看谁能自己把需求拆清楚。
另外一点，很多人问“3D 游戏开发工具有哪些”，这次我特意不选 Unity、Unreal、Godot，直接用 Three.js。原因很简单：模型生成的 C#、C++ 代码没法在我本地零依赖地编译验证，而 Three.js 写出来的就是纯前端项目，浏览器一把梭，任何一台电脑都能跑。这对评测来说是最公平的。
1.2 三位参赛选手的定位
这次参与横评的三位选手，背景差异其实挺明显的。
Step 5 Preview 是 Step 系列最新放出的预览版，主打“计划-执行”循环，拿到需求后会把任务拆成多个阶段逐步生成。我理解它的定位是：给一个模糊目标，它能自己规划出地图、角色、交互、UI 这些模块，然后逐个产出代码。
DeepSeek V4 Pro 延续了 DeepSeek 系列在推理上的强项，代码生成风格更“程序员”。它的输出结构清晰、命名规范，模块化做得很好，但有时候过于追求“最优解”，反而忽略了一些产品层面的细节。
GLM5.3 这边我测的是 FlashX 版本。FlashX 是智谱跑量用的加速轻量变体，特点就一个字：快。生成速度确实比另外两个要明显高出一截，但快带来的一个副作用是部署环境对 vLLM 镜像版本很敏感，这个我后面会专门说。
三个模型分别代表了“规划派”“工程派”和“速度派”，同做一个需求，画风应该会很有意思。
| 模型 | 风格定位 | 我关心的核心能力 |
|---|---|---|
| Step 5 Preview | 任务拆分与多步执行 | 能不能把大需求拆成小步骤，不跑偏 |
| DeepSeek V4 Pro | 工程化代码生成 | 代码结构是否稳健，边界处理是否到位 |
| GLM5.3 FlashX | 高速生成 | 出稿速度之外，完整性会不会打折 |
2. 测试方案：同一个需求，六条硬标准
2.1 游戏需求文档：体素迷宫收集金币
考题我是这么定的：一个 10×10 的体素风格迷宫，玩家用 WASD 控制角色在迷宫里移动，收集金币，攒够 5 个金币就胜利。角色不能穿墙，墙壁和道路用不同颜色区分。所有几何体用代码生成，不允许加载外部图片资源，最后输出单 HTML 文件。
这个需求量级说大不大说小不小。10×10 的地图意味着需要一套随机生成算法，WASD 控制意味着监听键盘事件并更新坐标，碰撞检测意味着每一帧都要做 AABB 级别的判断，金币收集意味着格子的状态管理。三个模型都必须一整套全部搞定，任何一个环节掉链子都直接体现为“游戏没法玩”。
我特意加了两条限制：一是“不加载外部图片”，二是“单 HTML 文件”。这两条是为了筛掉一些讨巧行为。之前我测试过别的模型，让它做个 3D 场景，结果它抄了一段new THREE.TextureLoader().load('textures/floor.png')，图片根本不存在，场景黑屏一坨。这种“看起来专业、实际跑不通”的代码，在真实开发里是灾难级的。
2.2 我用的评测提示词
下面是我实际发给三个模型的提示词，一个字都没改，保证公平：
请用 Three.js 做一个浏览器 3D 游戏，所有代码放在一个 HTML 文件中。 场景：在一个 10x10 的体素风格迷宫中，玩家使用 WASD 控制角色前后左右移动。 要求： 1. 迷宫随机生成，墙壁和地面用不同颜色的立方体表示，不要用任何外部图片资源，所有几何体用代码创建。 2. 角色不能穿越墙壁，碰撞检测要准确。 3. 迷宫中随机放置金币，玩家走到金币上即收集，界面显示已收集数量。 4. 收集 5 个金币后，显示胜利提示并停止游戏。 5. 使用 CDN 引入 Three.js。 6. 保证代码可以直接在浏览器中打开运行，给出完整代码。这个提示词我打磨过几轮。它不直接告诉模型“你应该把代码分成 initMap、createPlayer、gameLoop 几个函数”，因为一旦拆太细，评测的就是提示词的工程能力，而不是模型的规划能力。我故意把功能点用条目列清楚，模型自由发挥，最后看谁的结构更好。除了提示词之外，所有模型都拿同样的运行环境：Chrome 最新版、本地无服务器、直接双击 HTML 文件打开。
2.3 评分维度：一次跑通、还原度、代码质量、性能、部署
跑完生成环节，我按照五个维度打分：
- 首次运行通过率：生成的 HTML 直接在浏览器打开，能不能出现完整游戏画面。
- 需求还原度：随机迷宫、碰撞、金币、计分、胜利条件，一个功能算一项。
- 代码质量：变量命名、模块划分、有没有写死魔法数字、有没有明显冗余。
- 运行性能：帧率是否稳定，角色移动是否顺滑，CPU 占用是否夸张。
- 修复成本：如果第一版跑不通或逻辑有漏洞，我需要花几轮对话才能修好。
前四个维度容易理解，最后一点“修复成本”是最容易被 benchmark 忽略的。很多模型第一版像是能跑，但一交互就穿模或者金币永远刷在墙上，你得来回引导它修。修的次数越多，说明模型对需求的理解越浅。这轮实测里，三个模型在修复成本上的差异，比第一版跑通率的差异要明显得多。
3. 实测过程实录
3.1 Step 5 Preview：第一版就能跑，规划能力确实强
先跑的是 Step 5 Preview。我猜它的“计划-执行”机制发挥了作用，因为生成出来的代码结构非常“懂事”：开头是场景和相机的初始化，中间是地图生成和角色创建，最后是游戏主循环，函数命名也一目了然。
第一版直接在 Chrome 里打开，迷宫、角色、金币全都正常渲染出来，WASD 移动也灵敏。但它有一个问题：角色撞墙时会轻微抖动，是因为碰撞发生后坐标没有做回退修正，每一帧都在“进墙-弹回-再进墙”之间反复横跳。我把这个问题截图丢回去，让它修，它给出的方案是把角色移动改成“先尝试移动，检测到碰撞就退回到上一帧的位置”，还顺手给速度乘了一个clamp限制。
修完之后手感好了很多。更让我意外的是，它在修复时自己加了一个小功能：角色初始位置用绿色方块标出，终点附近用金色方块提示，虽然提示词里没要求，但它觉得这样能提升可玩性。这种主动补全体验细节的行为，让我觉得它确实在“做产品”而不是“交作业”。
不过它也暴露了一个问题：迷宫生成算法不够严谨。它用的是简单的随机开墙法，没有保证所有道路连通，导致某些金币可能刷在玩家永远走不到的死角。这还是我后续检查代码时发现的，如果只盯着“能跑”这个标准，很容易漏掉。
3.2 DeepSeek V4 Pro：代码老练，但地图生成钻了漏洞
DeepSeek V4 Pro 的输出风格跟 Step 5 Preview 完全是两路。它没有多余的规划说明，直接从<!DOCTYPE html>开始写，代码量大约 180 行，字符很紧凑，但模块边界异常清晰。每个模块上面还写了两行注释，完全是老程序员的手笔。
第一版也是能直接跑的，迷宫渲染、角色控制都没有问题。但我在测试玩法时发现了一个隐蔽的坑：金币生成逻辑是从所有空格子里随机选坐标，它没有判断这个格子是否“可达”。如果随机迷宫本身存在封闭区域，金币就有概率刷在墙中间或者死胡同里，玩家永远收集不够 5 个。
我第二轮提示它“金币必须放在玩家可达区域内”，它没有简单地在生成金币时加一个“不是墙”的判断，而是自己引入了一个 flood fill 算法：先以玩家出生点为起点，遍历所有可达空格，再从可达列表中随机选金币坐标。这手处理很漂亮，说明它对“全局可达性”是有理解的，而不是只顾局部正确。
DeepSeek V4 Pro 的另一个优点是变量命名非常克制。它没有用a、b、temp这种敷衍的名字，而是wallBoxes、coinAnims、playerSpeed，读代码的时候省了我大量力气。代价是它的输出偶尔会显得“教科书式”，美观但不够灵活，比如 UI 部分用了最简单的div叠加，没有像 Step 5 Preview 那样做漂亮的 HUD。
3.3 GLM5.3 FlashX：速度是真快，部署坑也是真多
GLM5.3 FlashX 是我在一个月前就接入的，主要看重它的生成速度。实测中它的出稿速度大概是另外两个模型的 1.5 到 2 倍，同样的提示词，这边已经输出完一段代码，那边还在慢慢“思考”。如果只是刷量生成小demo，这个优势非常大。
但速度快的代价是代码的毛刺更多。GLM5.3 FlashX 第一版同样能运行，但它生成的代码里用了THREE.CapsuleGeometry，这个几何体在比较老的 Three.js 版本里根本不存在——我只用了一个r128的 CDN 链接，结果直接报错。把 CDN 升到r158之后才正常。另外它会在代码里默默加载一个'assets/coin.mp3'的音效文件，而这个文件显然是不存在的，导致控制台报 404。虽然不影响核心玩法，但这个问题在真实项目里就是隐患。
更麻烦的是自部署问题。如果你不用官方 API，而是在本地用 vLLM 跑 GLM5.3 FlashX 做代码生成，镜像版本真的要挑。我一开始用的 vLLM 0.6.6 镜像，长上下文输入时 prefill 奇慢，生成一个几百行 HTML 文件要等接近一分钟。换到支持 FlashAttention 编译的更新版本镜像后，速度才恢复到正常水平。如果你手头是 910B 这类加速卡，还得额外确认镜像里有没有对应算子的预编译，这个坑比模型本身的参数还难折腾。
3.4 三份结果的横向对照表
三个模型全部测完，我整理了一张对照表。需要说明的是，这个表是基于这轮“体素迷宫收集金币”的具体任务，不代表模型在所有场景下的绝对排名。
| 对比项 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 FlashX |
|---|---|---|---|
| 第一版直接运行 | 通过 | 通过 | 通过（需升级 Three.js 版本） |
| 需求还原度 | 9/10 | 8/10 | 7/10 |
| 回合内是否跑偏 | 很少跑偏 | 偶尔过度设计 | 有外部资源幻觉 |
| 代码可读性 | 较好 | 优秀 | 中等 |
| 关键轮次修复成本 | 1 轮 | 1 轮 | 2 轮 |
| 生成速度 | 中 | 中 | 最快 |
| 额外亮点 | 主动补全游戏反馈 | flood fill 可达性算法 | HUD 和音效设计 |
看完这张表，我的整体感受是：三个模型的写作能力已经非常接近了，真正拉开差距的是“对完整项目的把控力”。Step 5 Preview 胜在规划，DeepSeek V4 Pro 胜在工程，GLM5.3 FlashX 胜在速度，各有各的擅场。
4. 横跨三个模型的通用大坑
4.1 资源幻觉：模型让你加载根本不存在的图片
这次测试里最典型的坑就是外部资源幻觉。三个模型都或多或少出现过TextureLoader加载图片、AudioLoader加载音频的行为，尤其是当提示词里没有强制“纯代码生成”时。模型“知道”一个游戏项目应该加载纹理和音频，于是它就编造了一个资源路径，但路径下什么都没有。
解决方式最有效的就是在提示词里写死：所有几何体用代码创建，不接受外部图片资源。如果项目本身允许美术资源，那么建议让模型先输出资源清单，再输出代码，不要让它一次性把路径编出来。还有一种偏方是做一个本地拦截脚本，把模型的输出里所有load(调用替换为空，但不是长久之计，治标不治本。
4.2 Three.js 版本差异：高版本 API 在老版本里不存在
Three.js 的版本迭代非常激进，API 变动大到离谱。最典型的是CapsuleGeometry，这是 r142 之后才加入的，你用老版本 CDN 直接报is not a constructor。还有渲染器颜色空间相关的配置，r152 之前用renderer.outputEncoding，r152 之后改成了renderer.outputColorSpace，两个写法在对方版本里都会报错或静默失效。
我的建议是测试时统一锁定 CDN 版本，比如都使用https://cdnjs.cloudflare.com/ajax/libs/three.js/r158/three.min.js，然后在提示词里明确写“基于 r158 版本 API 编写”。这样避免模型用了它训练数据里更熟悉的旧 API，也方便横向对比。顺带提一句，如果要用 OrbitControls，务必用和 Three.js 主版本配套的examples/jsm路径，不同版本的 module 路径差异也很大。
4.3 自建部署的坑：GLM5.3 FlashX 该用哪个 vLLM 镜像
如果你走 API 渠道，这段可以跳过。但如果是自部署 GLM5.3 FlashX，vLLM 的镜像版本不夸张地说，直接决定你是在“评测模型”还是在“调试环境”。我实测下来，vLLM 0.6.x 早期镜像对长上下文的 prefill 支持较差，喂进去几千 token 的提示词后首 token 延迟明显升高；新版本的镜像对 FlashAttention 的支持更完整，生成速度能提升接近一倍。
另外要注意模型的 chat template。有些镜像里的 tokenizer_config.json 没有带 GLM 专用的 chat template，导致messages格式的提示词被拼得乱七八糟，生成出来的代码也会带着一堆毫无意义的重复片段。遇到这种情况，不要先怀疑模型，先查一下请求日志里最终发送给模型的 input 是什么格式，十次有九次是模板的问题。
提示：我在本地跑 GLM5.3 FlashX 时，不直接信任默认的 vLLM 镜像，而是先看官方仓库指定的 tag。如果你拿到的模型权重需要特殊的
trust_remote_code选项，记得显式加上，否则加载权重时会漏掉自定义层。
4.4 长上下文生成时的另一个坑：代码中途截断
3D 游戏代码往往超过 300 行，模型输出很容易被上下文窗口截断，或者触发输出长度上限。我遇到过 GLM5.3 FlashX 生成到一半突然收尾，留下一个没有</script>的 HTML 文件，浏览器里只出现一个空白页面。
碰到这种情况，第一反应不要重新生成。模型已经完全理解需求了，你可以只发一句指令：“继续从刚才的位置输出剩余代码”，它通常能接着写完。如果模型的 API 不支持继续生成，那就把刚才输出的完整代码作为前缀重新喂一次，并在末尾加上“请补全剩余部分”，效果也还行。这里特别提醒一点，输出中断时很多模型会在下一轮重新输出整个文件，导致上下文爆炸。可以在提示词里加一句“只输出从上次中断位置开始的后续代码，不要重复已输出内容”，能有效节省 token。
5. 实测之后的选型心得
5.1 三个模型分别适合干什么
经过这两天的折腾，我对这三个模型的定位有了更明确的认识。
Step 5 Preview 适合拿来“从 0 到 1 做原型”。它会主动把需求拆解成模块，生成出来的代码结构清晰，甚至还会补一些你没要求但体验明显更好的细节。作为第一版草稿生成器，它的完成度是最高的。
DeepSeek V4 Pro 适合“已经有明确设计，需要稳定落地”的场景。它的代码工程化能力强，变量命名规范，边界处理严谨。如果你是在已有项目里让它改功能，或者让它按 RFC 写一个独立模块，它大概率能写出那种“直接可以进 code review”的代码。
GLM5.3 FlashX 适合“快速试错”的场景。它生成速度快，适合一次性批量生成多种方案，然后你挑一个方向深入。但它的产物通常需要你更严格地 review，尤其是外部资源引用和 API 版本兼容性，基本每次都要手动修。
5.2 如果你也想复测，我的建议
想完整复现我这轮测试的朋友，有三条建议。
第一，需求文本必须一字不改。模型对措辞特别敏感，改了任何限制条件，横向对比就失去了意义。建议把提示词存成文件，三个模型共用同一个文件。
第二，固定运行环境。Three.js 的版本、Chrome 的版本、是否有本地服务器，这些都会影响结果。我这次是直接把 HTML 文件双击在本地打开的，没有起服务器，所以跨域问题不会出现。如果你想更贴近生产环境，也可以统一用npx serve起一个静态服务器。
第三，记录修复轮次。不要只看第一版能不能跑，更重要的是你为了让它满足需求花了多少轮对话。这个数字最能反映模型对你需求的理解深度，也最能预测你在实际项目中会被它拖住多少时间。
我个人现在的做法是：先用 GLM5.3 FlashX 跑出三五个可选方案感受方向，选定一个后交给 DeepSeek V4 Pro 把核心逻辑重写得严谨一些，最后用 Step 5 Preview 做完整的场景收尾和体验补全。当然，这只是我这轮实测之后总结出的工作流，不代表这是标准答案，但至少你能从中看到这几个模型各自的价值边界。测试环境的坑踩完之后，后面再拿它们做新项目，应该能少熬两个夜了。
