最近我干了一件挺折腾的事把 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 126Three.js 版本锁定 r164Vite 用 5.x。整个项目用 Vite 的 vanilla 模板初始化因为 Three.js 游戏不强依赖框架原生 JS 反而更容易看出模型的基础功力。三个模型全部通过 API 接入没有用网页聊天界面。为啥不用网页版因为聊天界面有流式输出 自动保存历史的隐式加分项而且不同平台对代码块的呈现方式不同API 调用则可以用相同的参数配置temperature 设为 0.7max_tokens 设为 8000把变量控制到最小。接入方式统一了出来的差异才真正是模型能力的差异。这里有个细节我想强调max_tokens 设 8000 是因为 3D 游戏代码量大很多模型默认输出上限只有 4k tokens如果中途被截断出来的代码必然残缺。实测中 GLM5.3 的首次回答就超过了 6500 tokensDeepSeek 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、浏览器打开的流程来测首轮可运行情况如下模型首轮是否直接可跑首屏是否正常显示是否存在明显逻辑 Bug备注Step 5 Preview部分可跑是碰撞粒度不足快速移动偶尔穿墙角需手动加细分步长DeepSeek V4 Pro是是无明显致命 Bug视觉单调但有完整性GLM5.3否是移动方向不随视角变化不可玩需手动修正控制逻辑我这里说的部分可跑指 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 代码审查员反而是最有效的开发姿势。