1. 写在前面：这波新模型，我直接拉出来“三英战吕布”

先说个背景。这两年AI编程工具卷得厉害，但真正让我感觉“代差”出现的，是最近这一波新模型集中发布。Step 5 Preview、DeepSeek V4 Pro、GLM5.3，几乎前后脚放出消息，尤其是GLM5.3 FlashX那个“910B部署”的讨论一出来，社区里全是蹲实测的。

光看跑分没意思，刷榜数据说明不了问题。我个人的习惯是：拿一个足够复杂、需要多步推理、且结果可验证的任务，直接拉出来溜溜。这次我选的项目是——让这三个模型各自独立完成同一个3D小游戏。

为什么不选写个API接口或者修个Bug？因为3D游戏开发有个天然优势：它不是“填空式”编码，而是多模态混合推理的产物。你需要同时处理三维空间数学（向量、矩阵、欧拉角）、交互设计（键盘鼠标事件映射）、渲染管线（场景图、相机投影、光照模型）以及资源调度（贴图加载、循环帧更新）。任何一个环节掉链子，游戏要么跑不起来，要么逻辑鬼畜。

这次实测我给自己定了三个硬指标：

• 代码能不能一次跑通（容错率）
• 优化潜力和架构设计（工程性）
• 遇到报错时的自修复能力（实用度）

游戏选型也刻意做了平衡——用Three.js做第一人称迷宫解谜。为什么选它？Three.js是目前Web 3D事实标准，而且它足够底层：相机、灯光、碰撞检测全都需要手写逻辑。这就能逼出模型的真实水平。三个模型，同一套Prompt，同样的运行环境，拒绝一切模糊空间。

2. 任务设计与验收标准

2.1 为什么是“同一个游戏”而不是“任意游戏”

这个细节很重要。如果你给三个模型的指令是“写一个好玩的小游戏”，那它们各自发挥，产出完全不同，其实很难横向比较。

我的做法是，把需求写成一份极其具体的PRD（产品需求文档），包含：

• 使用Three.js（0.155.0版本），单HTML文件实现
• 第一人称视角，WASD移动，鼠标拖拽转向
• 迷宫的墙体随机生成，每局不同
• 终点放置一个旋转的金色立方体，玩家触达后游戏结束计时
• 碰撞检测必须精确到墙体边缘，不允许穿模
• 界面右侧实时显示当前坐标和行走距离

这三个模型面对的是完全一样的约束条件，才能看出各自的理解能力和实现路径。我在Prompt里故意加入了一些“信息对称”设计——不告诉它们怎么做，只告诉它们要什么。这就很考验模型把自然语言翻译成架构方案的功力。

2.2 评测标尺：别光看“跑没跑起来”

我见过很多AI生成代码的评测，标准就一条：“能跑就是好模型”。这其实是个误区。能跑只是及格线。我这次用五个维度打分，每项0-10分：

单项8分以上算优秀，6-8分算可用，6分以下属于“还得喂”。

3. 实测全过程记录

3.1 Step 5 Preview：稳如老狗的“保守派”学霸

先说Step 5 Preview。这个名字陌生的朋友可能不知道，它走的是高密度推理路线——简单说，就是它倾向于在思考阶段就把问题想透，而不是抢跑输出。

实测第一轮，它给出的是代码是结构化的IIFE模式（立即执行函数表达式），把所有功能封装在init()函数里，用模块注释分成了：场景初始化、迷宫生成、玩家控制、动画循环四个区块。

一个很妙的细节是，它在迷宫生成算法里用了递归回溯法——不是那种简单的随机堆墙。这意味着生成的迷宫天然存在唯一解，而且不存在“死胡同套死胡同”的低级问题。

代码跑通后我特意测了边界条件：贴着墙走、高速斜切墙角、倒车撞墙。没有一次穿模。它的碰撞检测用的是AABB（轴对齐包围盒）算法，然后做了0.2单位的收缩补偿。这个补偿值非常关键——如果设大了玩家会感觉“隔空撞墙”，设小了容易卡墙角。Step 5 Preview一次就找准了。

要说缺点——它写的是面向过程Vanilla JS，不是ES Module。在模块化和组件化这块偏保守。

3.2 GLM5.3 FlashX：真没想到，代码能力这次是“满血版”

说实话，看到GLM5.3 FlashX这个版本代号的时候，我的预期比较低。上一代产品强在中文理解，代码生成只能算“够用”。但这次FlashX明显把编码能力作为核心升级点，实测下来确实打脸了我的偏见。

它的代码结构是三个模型里唯一一个直接使用class进行系统设计的，游戏主逻辑拆成了三个类：MazeGenerator（迷宫生成器）、PlayerController（玩家控制器）、GameRenderer（渲染器）。

同时在我指定的技术栈基础上，主动引入了一个高阶特性——帧率自适应，用requestAnimationFrame的时间戳动态调整移动速度。这个细节太重要了。我在144Hz的显示器和60Hz的显示器上分别测试，Step 5 Preview和DeepSeek V4 Pro的游戏速度明显不同（帧率越高跑得越快），GLM5.3的表现则完全一致。

它的碰撞检测用的是射线投射法，相比AABB需要实时计算射线与墙体交点的重心坐标，理论精度更高。不过带来的问题就是计算量稍大——在低端手机上跑出了轻微掉帧。这算是精度和性能的权衡取舍。

3.3 DeepSeek V4 Pro：数学底子太硬了，思路惊人地优雅

DeepSeek V4 Pro给我的整体印象是：像一个数学系研究生在写代码——极致地追求算法优雅性。

先看出手。它没有用Three.js自带的加载器来做迷宫墙体排布，而是自己封装了一个稀疏矩阵数据结构，只存储有墙的格子坐标。这意味着内存占用与墙体数量成正比，而不是与整个地图面积成正比。本地测试50x50的地图，内存占用比其他两版低了至少30%。

更惊艳的是它处理第一人称转向的方式：不是常见的欧拉角累积，而是用四元数处理所有旋转，只有在最后应用给相机时才转换。懂行的朋友都知道这是为什么——欧拉角会导致万向锁问题，玩家快速摇头晃脑时画面会突然翻转180度。

它的代码注释密度也是最高的，几乎每三行就有注释说明“为什么这么做”——这在团队协作和后期维护时价值极大。

不过DeepSeek V4 Pro在文件组织上有一个小毛病：它对报错处理的“防御性”过强，写了大量Try-Catch。这在调试时反而不方便，因为真正的运行时错误会被埋掉。

4. 排错实录与避坑指南

4.1 三个模型都踩过的同一个坑

很有趣的是：三个模型在第一次Run的时候，全都忽略了键盘事件的preventDefault()处理。在浏览器里打开游戏后，按空格键页面会自己往下滚，按WASD时如果页面有滚动条会出现上下的漂移。

这个问题的坑不在于不调用preventDefault，而在于：你用的是window.addEventListener还是document.addEventListener——两者捕获事件的阶段和优先级不同。如果代码里既有Canvas鼠标事件又有全局键盘事件，事件委托的失效模式会非常隐蔽。

4.2 GLM5.3的“悬浮”Bug

虽然GLM5.3在代码架构上拿了最高分，但它在运行测试中出现了第一个报错——玩家从高处掉落时会陷入“无限下落”的状态。查了它的逻辑：它的下落检测用的是当前Y坐标是否小于地图层高度，但迷宫是纯2D的，它忘了设置玩家Y轴坐标的初始值，导致默认0和墙面底部50产生了冲突。

这个问题属于典型的“参数初始化遗漏”，修起来只需要一行代码。但暴露了一个AI生成代码的通病：对运行时环境的隐式假设过多。

4.3 DeepSeek V4 Pro的“过度设计”之痛

DeepSeek V4 Pro的问题出现在性能层面。它的稀疏矩阵数据结构在大地图下表现极佳，但在小地图（10x10以内）时，初始化开销反而高于简单数组方案。我实测了Player未动前15帧的渲染耗时——它比Step 5 Preview慢了将近两倍。

这提醒我们一个工程师直觉：在性能和复杂度之间要有灰度判断。最优算法不是永远的最优解，严格匹配场景规模的算法才是。

4.4 一次跑通后的“硬件玄学”

还有一个所有模型都没有处理好的情况——首次加载时的资源预编译延迟。Three.js的着色器（Shader）第一次编译耗时通常在200ms-500ms，这段期间如果玩家已经按下WASD，位移量会被累积到第一帧，导致开局人物瞬间瞬移。

这个问题的正统解法是预载一个无关的离屏渲染管线，或者直接在第一帧之前做事件锁存。

5. 横向对比：谁最适合当你的“3D编码搭子”

5.1 完全量化对比表

先看三个版本同一任务下的全维度评分：

5.2 按照你自己的使用场景来选

如果让我给一个简单粗暴的选择结论：

• 求稳，用于生产环境、快速产出：选Step 5 Preview。它的代码风格和我见过的十年以上的资深前端写出来的最像，不炫技、不过度设计，每一处都恰好在“够用”的边界上。这类代码进Code Review的压力最小。

• 团队协作，需要复用，需要扩展，长期迭代：选GLM5.3 FlashX。它的抽象层次和类封装意识明显领先于另外两个选手，尤其是帧率自适应那一步能体现它对运行时环境的深度理解。如果让它配合TypeScript工程化，体验会更香。

• 算法密集型项目，或者对性能有极致要求的功能：选DeepSeek V4 Pro。不要小看那个稀疏矩阵的存储选择——在移动端WebGL项目里，GPU内存和JS堆的占用直接影响崩溃率。但你要做好心理准备，它的代码你需要花额外时间去读注释才能看懂每个“为什么”。

这是个相对结论，不意味着其他两个模型的绝对性能差——而是意味着在不同约束条件下的适应度不同。

5.3 关键：Prompt细节决定生成质量

我实测过程中发现，对这些模型来说，Prompt里最关键的不是“请实现一个迷宫”这种敷衍话术，而是把验收口径写清楚。

比如我这次Prompt里有一段话：

碰撞检测的结果需要稳定复现：正面撞击、斜角撞击、高速切入三种场景都不能出现卡模型或穿模现象。如果无法同时满足，优先保证不穿模，允许轻微修正位移。

这类语句在与Step 5 Preview和GLM5.3交互时效果极其显著——因为它们都具备较强的“指令跟随”能力，会为了实现这条规则主动debug自己的代码逻辑。

但对DeepSeek V4 Pro，它比较吃“数学化描述”。你如果告诉它“碰撞体需要做边缘收缩”，它可能会忽略；如果你说“碰撞盒每个轴向收缩0.25个单位”，它会精确照做。

这说明一个核心经验：大模型写3D代码时，你的Prompt就是变相的“产品文档”。术语越统一，逻辑越可验证，模型给出有效代码的概率越高。

6. 最终总结与个人偏爱

三个模型跑完同一个任务，我电脑上留下了三份均能运行、但气质迥异的代码。我不能说哪个模型代表“最终答案”，但有一件事是确定的——2025年下半年，这波已经发布的模型把AI生成3D互动内容的水准拉到了一个新台阶。

个人偏爱层面，我最倾向的是GLM5.3 FlashX的代码设计，因为它的代码结构让我感受到“作者有架构思维”；而如果要快速交付一个演示版本，我会不假思索地用Step 5 Preview的输出直接改两笔上线。

最后给所有看到这里的同行一句掏心窝的话：不要迷信“最强模型”这个标签，每个模型都有自己的心智模型和思维惯性。真正决定项目高度的，依然是你如何定义需求、如何约束边界、如何在关键时刻做取舍。一次三方实测做到这里，我很期待这个月再更新一次跑分时，又会有谁杀出重围。