最近我干了一件挺折腾的事：把 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个模型拉到同一个考场，让它们各自从零写一个能跑的 3D 网页游戏。不是写个按钮弹窗那种"伪游戏"，而是带迷宫地图、第一人称视角、碰撞检测、金币收集、计时结算的完整玩法。折腾了两天，跑了三轮完整的"需求-编码-调试-复测"流程，踩了不少坑，也摸清了这三个模型各自的脾气。这篇就完整记录这次实测的过程和结论，给正在纠结用哪个模型搞代码生成的同学做个参考。

1. 为什么拿 3D 游戏当"模型体检机"——测试基准的设计思路

1.1 选 3D 游戏当测试题的原因

很多评测喜欢拿 LeetCode 算法题或 CRUD 接口生成来测模型，我觉得那玩意儿测出来的结果参考价值很有限。算法题是"单点函数能力"，CRUD 是"模板复用能力"，而真实的开发工作往往是"多点协作、上下文关联、持续迭代"的复合任务。3D 游戏恰好是这种复合任务的浓缩版。

一个 3D 网页游戏至少牵扯到几层能力。第一层是空间想象力，模型得理解三维坐标系里物体怎么摆、摄像机怎么放、移动方向向量怎么算；第二层是图形 API 的熟练度，Three.js 版本迭代快，API 改动频繁，模型有没有吃到新版本的用法；第三层是事件驱动逻辑，键盘监听、碰撞检测、状态流转这些是游戏骨架；第四层是工程组织能力，代码是堆在一个文件里还是按模块拆开，直接决定后续好不好维护。这几个维度叠加起来，基本能把模型的天花板和短板都压出来。

还有个很现实的原因：3D 游戏是即时反馈最快的任务之一。代码写错了，浏览器控制台立刻报错，画面立刻异常（卡死、穿墙、黑屏、视角乱飞），不需要写单元测试也能直观判断模型写得好不好。对做评测的人来说，这种"所见即所得"的验证方式效率极高。

1.2 这次测试的具体任务设计

为了避免模型"自由发挥"导致结果没法横向比较，我在需求文档里把游戏规格定得很死。最终的任务是做一个 15×15 的迷宫寻宝游戏，用 Three.js + Vite 实现，玩法是第一人称视角在迷宫里移动，收集 10 个金币，找到出口则结算成绩。

核心需求点一共列了八条：迷宫用二维数组表示并用递归回溯算法生成；第一人称通过 PointerLockControls 控制视角；WASD 控制移动方向；碰撞检测用基于迷宫网格的"预测目标格"方案；场景中放置 10 个金色圆柱体作为金币，拾取后计数；终点放一个可穿透的传送门模型，玩家靠近后触发结算界面；HUD 显示金币数和计时器；窗口尺寸变化时自动适配。

我还额外加了一条硬性约束：只能用原生 Three.js API，不允许引入 Cannon.js、Ammo.js 等物理引擎。物理引擎会帮模型把碰撞、重力全扛了，那就测不出模型对空间计算和碰撞逻辑的真实理解程度。

需求越具体，模型之间的差距越明显。有的模型会乖乖照做，有的会自作主张加花活，有的会简化掉"它认为不重要"的需求。这份需求文档本身也是测试工具的一部分。

2. 三个模型同场竞技前的准备工作

2.1 接入方式和基础环境

先说环境，这是很多人忽略的变量。我统一在 Windows 11 + Node.js 20 LTS 的环境下跑，浏览器用 Chrome 126，Three.js 版本锁定 r164，Vite 用 5.x。整个项目用 Vite 的 vanilla 模板初始化，因为 Three.js 游戏不强依赖框架，原生 JS 反而更容易看出模型的基础功力。

三个模型全部通过 API 接入，没有用网页聊天界面。为啥不用网页版？因为聊天界面有"流式输出 + 自动保存历史"的隐式加分项，而且不同平台对代码块的呈现方式不同；API 调用则可以用相同的参数配置（temperature 设为 0.7，max_tokens 设为 8000），把变量控制到最小。接入方式统一了，出来的差异才真正是模型能力的差异。

这里有个细节我想强调：max_tokens 设 8000 是因为 3D 游戏代码量大，很多模型默认输出上限只有 4k tokens，如果中途被截断，出来的代码必然残缺。实测中 GLM5.3 的首次回答就超过了 6500 tokens，DeepSeek V4 Pro 则控制在 5200 左右。后面反复验证发现，输出长度控制其实是模型的一个隐性特征。

2.2 给三个模型发同一份需求文档

需求文档我写了一版，内容跟最终的游戏规格完全一致。提示词的结构是：背景交代（做一个第一人称迷宫寻宝游戏）→ 技术栈约束（Vite + Three.js r164）→ 功能清单（八条逐项列明）→ 非目标说明（不需要物理引擎/不需要跳跃）。最后加了一句：请先给出项目文件结构和每个文件的完整代码，再给出运行步骤。

Step 5 Preview 拿到需求后没有立刻动笔，而是先追问了一个问题：迷宫是否要从入口到出口保证有通路。这个细节我确实没在需求里写死，虽然递归回溯算法天然保证通路，但模型能主动确认边界条件，是个加分项。DeepSeek V4 Pro 则直接开始列文件结构，把index.html、src/main.js、src/maze.js、src/player.js、src/items.js全拆好了，像在写一个正经工程。GLM5.3 也直接给出了完整方案，但把所有逻辑都塞进了main.js一个文件里，第一步就看得出风格差异。

2.3 一个容易被忽略的细节：如何在提示里"框住"需求

很多人用模型写代码，提示词写得潦草，"帮我做个迷宫游戏"这种一句话需求，出来的代码自然天马行空。这次实测我特意把提示词写得像一份真实的开发任务书，但三个模型的表现告诉我：提示词再详细，模型也还是会丢失部分约束。

事后对比发现，越是"自由发挥空间大"的需求（比如场景视觉风格），模型越容易改设定；越是"数值型"的需求（比如迷宫 15×15、金币 10 个），模型越能遵守。也就是说，如果你想用模型做游戏开发，最有效的约束手段是把所有规格数字化、可验证化，而不是用形容词约束。"漂亮的场景"远不如"地面用 #4a90d9 材质、墙体用岩石纹理贴图"来得有效。

这一步试下来我得到一个经验：评测模型或使用模型时，最好在提示词里显式声明"非目标"。"不需要跳跃、不需要物理引擎、不需要敌人 AI"这类否定声明，能明显减少模型塞私货的概率。三家里 GLM5.3 对否定约束的遵从性最好，Step 5 Preview 偶尔还是会想给游戏加个跳跃功能。

3. 同一需求的三路实现：迷宫寻宝的诞生过程

3.1 场景与迷宫生成：谁的算法最干净

三个模型都在第一时间写对了递归回溯迷宫生成算法，基本盘是稳的。但细节差别立刻出来了。Step 5 Preview 生成的迷宫数组是一个独立的maze.js模块，对外暴露generateMaze(rows, cols)函数，内部用了栈 + visited 二维数组的标准写法，还加了注释说明每个分支的作用。这段代码我拿给没学过算法的人看也能读懂，结构很干净。

DeepSeek V4 Pro 同样把迷宫生成独立成模块，但它多做了一件事：把迷宫数据和渲染逻辑解耦，返回的数组里用 1 表示墙体、0 表示通路，同时额外导出一个getCell()方法供碰撞检测模块调用。这种"数据访问接口化"的设计，明显是考虑到了后续模块之间的协作。

GLM5.3 的实现则完全不同，它没有把迷宫生成单独拎出来，而是直接在主文件里用二维数组字面量预置了一张 15×15 的地图，再通过某个函数把墙体从数组映射成 3D 立方体。它甚至没有用递归回溯算法，而是手写了一张迷宫地图进去。要说"能不能跑"，它肯定能跑，而且预置地图反而更容易人工调整关卡设计。但从"生成一个随机迷宫"的需求角度，GLM5.3 其实是偷懒了。它似乎把需求理解成了"有一个迷宫就行"，而不是"迷宫要程序化生成"。这个差异值得玩味。

3.2 第一人称控制与碰撞：这里的代码差异最大

第一人称控制是这次实测差距最悬殊的环节。三个模型都知道要用 PointerLockControls，但在处理"鼠标锁定后如何让移动方向跟随视角方向"这个关键点上写法完全不同。

Step 5 Preview 给出的方案是：把键盘输入的 W/S 映射到前进轴的getWorldDirection方向上，A/D 映射到右向量的反方向，每帧用camera.position.addScaledVector(moveDir, speed * delta)来移动。这个方案是教科书级的标准做法，移动手感很正，不会出现"按 W 但朝世界坐标北方走"的经典错误。

DeepSeek V4 Pro 的移动实现逻辑类似，但它额外处理了一个我没在需求里提到的问题：玩家身体与相机分离。它创建了一个不可见的playerMesh作为碰撞检测代理，让相机跟随这个代理物体移动。这样做的好处是后续加角色模型时相机不会穿模。虽然需求里没有要求，但这个设计体现了工程前瞻性。

GLM5.3 的移动逻辑则简化了很多，直接把键位映射到了世界坐标轴的固定方向：W 就朝 Z 轴负方向走，S 就朝正方向走。这意味着玩家转身后按 W，角色会横向移动而不是前进。在 PointerLock 视角模式下，这几乎是不可玩的状态。这个 Bug 不涉及复杂算法，纯粹是对"第一人称视角下移动方向应与朝向一致"这个常识的缺失。

碰撞检测方面，三家的方案倒是都集中在"网格预测"上：移动前先计算目标坐标，换算成迷宫数组的下标，判断该格子是不是墙。差别在于步进方式。Step 5 Preview 和 DeepSeek V4 Pro 都用了"分帧插值 + 细分步长"（每帧最多移动 0.05 格），避免高速移动时直接穿过墙角的格子缝隙。GLM5.3 直接用了完整速度矢量做单次位移，实测中贴墙快速移动时会出现轻微的穿模抖动。碰撞检测不光是"有没有判断"，还要考虑"判断粒度够不够细"，这就是典型的实操坑。

3.3 金币、计时与胜利判定：收尾能力的试金石

到了功能收尾阶段，模型之间的差距反而缩小了，因为金币收集和计时器都是简单的状态管理逻辑，不太考验深层理解。但这里出现了几个有意思的"隐藏需求"。

Step 5 Preview 给金币设计了旋转动画，每个金币圆柱体挂在场景上后，在render循环里统一rotateY。它还做了"金币收集后从场景移除 + 计数归零"的联动，不会出现金币消失了但计数还差一个的问题。DeepSeek V4 Pro 则给每个金币单独加了一个collected状态标记，配合 click 或 touch 事件判断是否拾取。这里差了一个维度：三维空间里的"碰到"不等于"点击"，用事件区域判断金币收集在老版本 Three.js 里可行，但 r164 里更推荐每帧检测玩家与金币的包围盒重叠。GLM5.3 则是用intersectsBox做射线检测，虽然射线检测跟自己身上的胶囊体碰撞盒不完全一致，但效果上问题不大。

胜利判定和结算界面是另一个观察点。Step 5 Preview 做完结算面板后还顺手加了一个"再来一次"按钮，点击后重新生成迷宫并把玩家传送到入口。这个功能虽然不在需求里，但对游戏完整性来说是加分项。DeepSeek V4 Pro 也做了重置逻辑，但它重置的地图是同一个地图，没有重新生成，这就少了"每局不同迷宫"的乐趣。GLM5.3 则在胜利判定后保持玩家可以继续移动，只是弹出结算面板并暂停了计时器，说实话有点糙。

4. 实测数据对比：代码量、首轮通过率与翻车点

4.1 首轮可运行率：三家里只有一个真正"一把过"

按照"拿到完整代码后，直接复制到项目目录、npm run dev、浏览器打开"的流程来测，首轮可运行情况如下：

我这里说的"部分可跑"，指 Step 5 Preview 生成的代码vite dev能启动、场景能渲染，但按 W 快速移动时出现了穿模现象，需要手动把移动逻辑里的单步位移改成 0.05 格步进。DeepSeek V4 Pro 是唯一一个首轮跑起来就能完整体验完整流程的，迷宫生成、碰撞、金币、胜利判定全部正常，交互上偶尔有点小卡顿，但没影响核心玩法。GLM5.3 则是严重到没法操作，因为移动方向不跟随视角，一转身就全部错乱。

这个结果其实挺反直觉的。GLM5.3 在中文本地化理解和需求还原度上表现最好，却在最核心的控制逻辑上掉链子。DeepSeek V4 Pro 在需求还原上做了一些裁切（比如没有重新生成随机迷宫），但恰恰是这种"适度裁切"让它没有引入额外 Bug。Step 5 Preview 更像一个"什么都想做到位"的全能选手，但细节补丁打得不够。

4.2 排错过程记录：发现问题、修复问题的速度

评测不能只看一次生成结果，还得看模型的"自我修复"能力。我把三家首轮的报错和明显 Bug 依次回传给各模型，要求它们在不改动整体架构的前提下最小化修复。

GLM5.3 的移动方向问题修复是最快的。我提示"移动方向应使用当前视角朝向而非固定坐标系方向"后，它第二次给出的代码就改成了基于getWorldDirection的实现，还主动把原来的固定方向代码注释掉并标了解释。但有一点：它在修复时把原来的 W/S 与 A/D 的处理逻辑合并了，导致修复后出现了一个新的横移反向 Bug（按 A 往右、按 D 往左）。这是模型在局部修复时对全局符号理解不足的典型表现。

DeepSeek V4 Pro 的唯一小问题是"点击重新开始后迷宫不重新生成"。我要求它补上这功能后，它通过在重置函数里重新调用generateMaze()就解决了，没有引入新问题，整个改动不超过十行。

Step 5 Preview 的穿模问题修复则没有表面看起来那么简单。它给出的修复方案是把移动拆分成 X 和 Z 轴分别检测碰撞：先尝试沿 X 轴移动并检测，再沿 Z 轴移动并检测，而非一次位移同时检测两个方向。这个方案是 3D 碰撞检测里很标准的"轴分离滑动"做法，修复效果很好。但它在实现过程中没有同步处理玩家碰撞半径（碰撞盒半径 0.3），导致玩家贴墙时身子有一半嵌进墙里。这个属于修复 A 问题时忽略了 B 参数。

4.3 代码风格与工程习惯对比

代码风格方面，三个模型的差异非常鲜明。DeepSeek V4 Pro 最接近"有经验的同事写的代码"：模块划分合理、函数命名准确、每个文件不超过 200 行、关键变量都有注释。它甚至把常量配置（玩家速度、金币数量、迷宫尺寸）集中放在一个config.js里，这个习惯很多中级开发都不一定有。

Step 5 Preview 的代码风格偏向"教科书"：注释密度高、命名没有缩写、逻辑非常直白，适合教学场景。但它的代码量大，单文件逻辑偏长，很多同步操作都堆在update循环里，没有进行合理的功能拆分。如果项目规模再大一点，这种写法很容易变成意大利面条。

GLM5.3 的代码风格就完全是另一条路线了。它的注释更像个项目经理在写说明，喜欢在代码块上写一大段"这里实现的是 XXX 功能，目的是 XXX"。代码本身偏广播式，所有函数都堆在一起，依赖全局变量。好处是看着很连贯，坏处是熵增很快——一旦需求变更，牵一发动全身。

5. 三个模型的真实水平与性格差异

5.1 Step 5 Preview：整体感强但容易过度设计

Step 5 Preview 给我的整体印象是"系统感极强"。它很少只做你要求的那点事，往往会顺带把周边逻辑补齐——金币旋转动画、再来一局按钮、结算统计面板，这些都是它主动加的。这种"补完"倾向在游戏原型开发里很讨喜，能让你快速得到一个有完成度的 Demo。

但它的过度设计也带来问题。最典型的一次是它在做碰撞检测时，主动引入了一个CollisionManager类，把碰撞逻辑封装成独立模块。逻辑本身没问题，问题在于它把这个类设计成了支持"动态碰撞体列表"的通用架构，而项目的需求只是跟静态墙体做碰撞。多余的抽象没有带来收益，反而让首轮代码量暴涨。如果你要用 Step 5 Preview 做开发，最好在提示词里明确控制它的发挥范围，否则代码量会明显膨胀，取舍由人。

5.2 DeepSeek V4 Pro：工程化最像"同事写的代码"

DeepSeek V4 Pro 在我这次测试里的表现最均衡。它写出来的代码不是最华丽的，但工程化程度最高：模块拆分清晰、命名规范、常量抽离、没有明显多余设计。它似乎天生倾向于"最小可行实现"——不会主动加跳跃，不会主动加动画，只会把需求里写了的功能稳扎稳打地做完。

这种性格在原型开发阶段其实是好事，因为需求外的东西它不乱碰，出 Bug 的概率就低。唯一要留意的点是它对"视觉表现"的想象力偏弱。它生成的场景是三个模型里最素的，地面是纯色平面、墙体是灰色立方体、金币是金色圆柱，一眼就是"程序员默认画风"。如果你的需求里对画面美感有要求，得在提示词里用更细节的指令去描述材质、光照、色调。另外我发现它在使用 Three.js 新版 API 时表现稳健，没有出现过使用已废弃 API 的情况，这一点对长期项目很重要。

5.3 GLM5.3：需求还原最老实，数学细节要盯

GLM5.3 这次测试的表现要分成两面看。一面是它的中文语义理解确实好，需求文档里那些带中文描述的条目（"金币碰到就消失且计数加一""终点是一个传送门效果"）它最遵守，基本没有自己乱改需求的情况。另一面是它对三维数学和三维交互的理解存在明显短板，移动方向跟视角方向分离的问题，直接暴露了它视角控制与坐标映射理解不深的问题。

这里我特别想展开说一下 GLM5.3 的"偷懒倾向"。它预置迷宫地图、简化金币判定、不加重置功能，表面看是功能缺失，实际是它倾向于把"实现成本高但需求里没强调"的部分自动降权。如果你用 GLM5.3 做开发，要反复强调需求里的核心功能点，最好明确到"必须程序化生成随机迷宫""不允许使用字面量预置地图"这种否定式约束。它也是一匹值得调教的马，但驯服之前会频繁掉链子。

6. 给想复测的人：操作建议与关键提醒

6.1 如何设计一份"防作弊"的测试任务

如果你也想自己复测这三个或更多模型，我的建议是任务设计时注意三个点：单点技能要细化，复合场景要串联，模糊地带要补全示例。

单点技能细化是指把"三维场景"这类大需求拆成可验证的原子项，比如"移动方向跟随相机朝向""碰撞前先做格子预测""计时器不因结算面板弹出而误停"。复合场景串联是指让各个功能之间产生依赖，比如"金币数量影响结算页的星级评价"，这种跨模块状态传递最能考验模型的全局意识。模糊地带补全示例则是把规范用代码片段的形式写进提示词，例如碰撞检测的伪代码可以直接给出来，要求模型按照该逻辑实现。你会发现一个很有意思的现象：提示词里给伪代码时，三个模型的代码质量和需求遵循度都会拉高一大截。

6.2 三个适用场景的选型建议

结合这次实测，如果让我给选择建议：追求工程规范度和代码可维护性，DeepSeek V4 Pro 排第一，特别适合团队项目里做基础模块或搭建框架。追求快速得到高完成度原型、愿意事后清理多余代码，Step 5 Preview 排第一，它帮你补全的边界逻辑有时候能给你很多新灵感。追求中文描述的忠实还原、并且你有能力自己修补底层逻辑细节，GLM5.3 排第一，它的理解能力能帮你省很多沟通成本，但你得给它"戴上缰绳"。

最后想给所有想拿 AI 做游戏开发的朋友一个提醒：评测模型的正确姿势不是看它"第一段代码多惊艳"，而是看它"在发现了自己的 Bug 之后，能不能精准修复而不引入新 Bug"。一次生成的代码是上限，排错迭代后面的代码才是日常。

我在踩完这些坑之后，最大的体会是：现阶段没有任何一个模型能当"全自动游戏开发引擎"，但它们做助理都绰绰有余。关键是把需求文档写得像一份正经的开发任务书，把边界条件、非目标、验收标准全部写清楚。这次实测的三个模型，Top 水平大约能把完整游戏开发的机械性工作承担掉八成，剩下的两成空间想象力、产品感和 bug 修复方向判断，还是得靠人来兜底。以后说不定连这两成都能省了，但今天，老老实实当个"AI 代码审查员"反而是最有效的开发姿势。