最近 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 PreviewDeepSeek V4 ProGLM5.3 FlashX第一版直接运行通过通过通过需升级 Three.js 版本需求还原度9/108/107/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.outputEncodingr152 之后改成了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 FlashXvLLM 的镜像版本不夸张地说直接决定你是在“评测模型”还是在“调试环境”。我实测下来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 做完整的场景收尾和体验补全。当然这只是我这轮实测之后总结出的工作流不代表这是标准答案但至少你能从中看到这几个模型各自的价值边界。测试环境的坑踩完之后后面再拿它们做新项目应该能少熬两个夜了。