最近花了一整天，干了一件比较“折腾”的事：用同一个3D游戏需求，分别让 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个大模型各写一版完整代码，然后逐个跑起来实测、拆代码、改bug、对比效果。这个测试的起因很简单，我自己平时做前端原型和小游戏demo，已经重度依赖AI编码模型，但对“哪个模型更适合生成可运行的游戏”这件事一直没有一个量化的答案。与其听宣传，不如拿同一道题做一次同题作文。这篇文章就是我这次实测的完整记录，包含需求设计、评测维度、代码对比、运行数据、排错实录和最终的选型建议。如果你也在纠结用哪个模型写游戏原型，或者想了解这仨模型在真实编码场景下的差距，这篇应该能给你省不少时间。

1. 为什么拿“3D游戏”当测试题：它能一次覆盖模型的能力盲区

先说结论：3D游戏是最适合测大模型代码能力的题目之一，因为它天然包含了一个完整应用的几乎所有关键环节。这里不是要写一个能上线盈利的商业游戏，而是用一个小而全的3D交互场景，逼出模型在多个维度的真实表现。

1.1 3D游戏比普通CRUD难在哪

普通网页应用或者管理后台，核心就是“数据进、数据出”，逻辑相对平铺直叙。但一个3D小游戏，哪怕再简单，也必须同时处理下面这几类问题：

• 场景搭建与渲染管线：你需要建一个3D场景，有地面、墙壁、灯光、相机、材质，这些东西在Three.js里每一块都是一堆配置代码。模型必须清楚这些API的写法，不能靠猜。
• 物理与碰撞检测：角色往前走，碰到墙不能穿过去。这需要把玩家坐标和场景里的障碍物做空间关系判断。很多模型在这个环节翻车，最常见的就是“碰撞检测写反了”——角色被墙挡住完全动不了，或者干脆穿墙。
• 交互与事件系统：键盘控制移动、鼠标拖拽旋转视角、按钮点击触发重置。这些看似基础的东西，组合起来很容易出状态冲突的bug。
• 游戏循环与状态管理：一帧一帧更新位置、判断胜利条件、管理计时器，这是游戏逻辑的主循环。如果状态管理混乱，经常出现“赢了之后再玩一次计时还是旧的”这种问题。

一个模型要把这四块全都一次写对、还能直接跑，需要的不是背一本API手册，而是真正理解“一个程序是怎么从头到尾协作起来的”。所以我选3D游戏做测试题，就是想看看每个模型的“全局项目组织能力”。

1.2 统一需求：不让模型在起跑线上拉开差距

为了公平，我给三个模型出了完全一样的题目，一个字不改。需求定稿如下：用Three.js做一个3D迷宫寻宝小游戏，迷宫随机生成，玩家用WASD控制角色在迷宫内移动，通过碰撞检测避免穿墙，到达藏宝点后判定胜利，同时记录通关时间。界面要求包含开始界面、胜利提示和重玩按钮，并且不允许使用其他图形框架，全部用原生JS配合Three.js实现。

这个需求看起来简单，但我刻意埋了几个容易出问题的点：碰撞检测、随机迷宫生成、状态重置。这三个点如果没有做好，后面运行时会非常痛苦。提示词里还加了一条硬性要求：代码必须是一个完整的 html 文件，方便我直接双击打开运行。

1.3 评测维度：不只看能不能跑

我用五个维度来打分，每个维度都有自己的理由：

这不是一个严格意义的基准测试，但对实际做项目的人来说，这个权重分配基本反映了真实体验：效率第一，能不能跑起来永远是最大的事。

2. 实现思路全对比：三种迥异的“工程师风格”

同一份需求，三个模型交出的答案是三种完全不同的风格。这一步最有意思：你能明显感觉到每个模型的“性格”。

2.1 Step 5 Preview：结构最清晰，像个严谨的老工程师

Step 5 Preview 给出的方案是标准的“模块化分层”，代码拆分得很规整：迷宫生成器、玩家控制器、碰撞检测、渲染逻辑，各自独立成函数。

迷宫生成它用了经典的递归回溯算法（DFS回溯）：从一个单元格开始，随机往邻居走，打通墙壁，走不通就回头，最终形成一个“通路蜿蜒”的完美迷宫。这个算法生成的迷宫没有封闭死区，任何两个点之间都有且仅有一条路，作为游戏场景非常合适。

我印象比较深的是它的碰撞检测方案，这是三个版本里最稳的一个。它没有用复杂的几何碰撞体，而是利用迷宫本身是网格这一特性，做了一个“网格映射检测”：玩家坐标换算成网格坐标，如果目标格是墙壁，就禁止更新坐标；如果是空地，就放行。代码大概长这样：

function checkCollision(x, z) { // 将世界坐标转换为迷宫网格坐标 const col = Math.floor((x - offsetX) / cellSize); const row = Math.floor((z - offsetZ) / cellSize); // 边界外直接拦截 if (row < 0 || row >= maze.length || col < 0 || col >= maze[0].length) return true; // 墙壁返回碰撞 return maze[row][col] === 1; }

这种做法的好处是效率极高——一次数组下标访问就完成了碰撞判断，完全不依赖Three.js的物理引擎或射线检测。而且玩家在移动过程中只要按格子走，手感就会非常顺滑，不会出现被“隐形墙壁”卡住的情况。值得一提的是，Step 5 Preview生成的第一版代码，我双击打开，直接就能玩。这个“一次通过”的体验在三个模型中是最舒服的，后面所有调试时间都省了。

2.2 DeepSeek V4 Pro：功能最全，但首版有两个报错

DeepSeek V4 Pro 的思路明显是“做加法”。它选择用Prim算法生成迷宫，这种算法生成的迷宫没有明显的长走廊，路径更随机、岔路更多，游戏的探索感更强。同时在游戏性上，它额外加了小地图、计时器、步数统计，甚至用Web Audio API合成了一段简单的背景音效，这些细节让整个游戏的完成度一下子高了不少。

但功能全也带来了问题：它第一版代码体量最大，而且有两处明显报错。一个是变量作用域冲突，另一个是阴影贴图导致性能严重下降。报错本身不复杂，把报错信息直接粘回对话里，它修得非常快，两轮就解决了，但毕竟没有做到“开箱即用”。修完之后实跑，整体功能确实是三版里最丰富的，尤其是小地图，对玩家判断自己在迷宫里的位置帮助极大，体验加分不少。

2.3 GLM5.3：画面表现力最强，但bug修复轮次最多

GLM5.3 的版本视觉上最好看。它给墙壁加了纹理材质，宝藏点用了一个缓慢旋转的金色发光体，还补了一圈粒子光晕。场景里加了环境光和点光源，视角转动时光照变化明显，整体观感直接拉高一个档次。

但它的问题也很明显：第一版代码存在一个严重的碰撞检测逻辑错误。它的移动判定里把“可通行”和“不可通行”的条件写反了，导致角色能直接穿过墙壁，但同时被空地卡住——这等于整个移动逻辑反转了。把bug反馈给它之后，修复倒是快，可修完碰撞，新的问题又冒出来了：角色在撞墙之后相机位置发生抖动，因为碰撞后的位置修正没有做平滑处理，每个帧都在“推进去”和“被墙挡出来”之间振荡。又修了一轮才稳定下来。整场测下来，GLM5.3在视觉细节上花的心思最多，但代码的严谨性确实垫底，前后改了三轮才算可用。

3. 核心环节逐行拆解：迷宫算法、碰撞检测、鼠标视角到底谁写得好

光看整体风格不够，我把三个模型代码里最核心的几个环节拎出来做了二次对比。这三个环节是游戏代码里最有技术含量的部分，也是判断一个模型“是真的懂游戏开发，还是在套模板”的关键。

3.1 迷宫生成算法：三种随机性的实际差异

迷宫生成有很多种算法，这次测试里三个模型恰好用了三种不同的：DFS回溯、Prim、递归回溯。从玩家体验看，这三种带来的感受完全不同。

Step 5 Preview用的DFS回溯生成的迷宫，通道弯弯曲曲，像真正的人工迷宫，路径较长，探索时间久，但路线相对单一，基本跟着走廊走就能到终点。DeepSeek V4 Pro用的Prim算法生成的迷宫更“破碎”，岔路多、直道短，走起来更容易迷失方向，适合喜欢探索的玩家。GLM5.3虽然也用递归回溯，但代码实现里对邻居的遍历顺序是固定的，导致生成的迷宫有明显的规律性——往一个方向走的偏好多，玩两局就能摸清套路。

这里有一个实际影响：迷宫算法不仅关系到可玩性，还关系到碰撞检测的复杂度。规整网格生成的迷宫，用网格映射做碰撞检测最合适；迷宫结构越不规则，碰撞检测越需要更细致的几何判断。三版代码都恰好沿用了网格碰撞，这也是这三种算法都是基于网格单元生成的结果，如果模型选择了基于连续空间的迷宫生成，代码复杂度会高很多。

3.2 碰撞检测的正确姿势：为什么Step 5的方案最省心

碰撞检测是这次测试里最大的分水岭。三个模型的实现方式完全不同，直接导致了最终体验的巨大差异。

Step 5 Preview的网格映射检测前面已经展示过了，核心是“提前判断目标位置是否合法，合法才更新坐标”。这种做法本质上是把碰撞检测从GPU的几何计算简化成了CPU层面的数组判断，稳定且高效。

DeepSeek V4 Pro用的是AABB包围盒检测算法，为玩家和每个墙壁块都建立了一个坐标区间，然后做矩形相交判断：

function aabbCollision(px, pz, wall) { return px < wall.maxX && px > wall.minX && pz < wall.maxZ && pz > wall.minZ; }

这种检测更精细，可以真正实现“碰到墙就停住”，不会像网格映射那样出现“半个身子卡进墙里”的情况。但缺陷是性能消耗大——每帧都要遍历附近的墙壁块做相交测试，当场景里墙壁数量多时，帧率会有明显波动。

GLM5.3的检测是最“理论化”的，用了射线投射检测：从玩家位置向移动方向发出一条射线，检测射线是否与墙壁相交。这在概念上是最“标准”的游戏物理方案，但实现不到位就会出现问题——射线检测的判段阈值一旦设置不当，就会出现角色在移动过程中抖动或者被莫名其妙阻挡的情况。它首版把阈值符号写反也属于这个范畴，实际修复起来确实比前两者更费精力。

3.3 鼠标视角控制：为什么不能直接套PointerLockControls

这一块三个模型的选择也很有意思。Step 5 Preview直接用了Three.js官方的PointerLockControls，用它来实现鼠标移动旋转视角、点击锁定鼠标的效果。好处是代码量极少，而且绝大多数PC浏览器支持良好。但在触屏设备上完全不工作，这意味着这版代码只能在PC上玩。

DeepSeek V4 Pro则自己写了一个轨道相机控制，用鼠标拖拽旋转视角，同时主动规避了PointerLockControls和碰撞检测之间的冲突。因为它意识到：PointerLockControls会直接接管相机旋转，如果碰撞检测需要根据相机朝向调整移动方向，两者容易打架。自己写拖拽控制虽然代码多了一些，但兼容性更好，也更好控制。

GLM5.3也用的是自研鼠标控制，但它的实现里把“视角旋转”和“角色朝向”逻辑耦合在一起，导致当角色撞墙停下时，视角也跟着抖一下。这个细微的体验问题，恰恰是很多自研控制都会踩的坑。

这里我的实测体会是：如果你只要一个能快速演示的游戏原型，用PointerLockControls其实是性价比最高的选择，代码少、稳定、PC上体验好；但如果要在移动端也能玩，就得像DeepSeek V4 Pro那样自己做拖拽控制，并且把碰撞和相机的逻辑严格分离。

4. 实测运行表现：帧率、体验、性能数据一览

代码层面的分析只是一部分，最终还是要看运行时表现。我把三个版本的代码在同一台机器上（笔记本 + Chrome浏览器，未做任何手动优化）分别跑了一遍，记录了完整的数据，数据汇总如下：

4.1 性能表现：功能越多，代价越大

从数据看，DeepSeek V4 Pro的版本功能最全，但代码量也最大，阴影贴图一开帧率直接掉到47FPS左右，画面能感觉到明显的卡顿——这在迷宫这种第一人称场景里非常影响体验。我后来手动把阴影关掉，帧率才回到60FPS。GLM5.3版本因为粒子特效的存在，室内场景狭窄处有轻微掉帧，不过整体还算流畅。Step 5 Preview版本最朴素，没有阴影也没有粒子，帧率全程稳定在60FPS，没有波动。

有一个直观类比：这就像买手机，功能堆满的机型跑分很高，但日常用起来发热耗电；而针对场景做取舍的机型，日常体验反而更顺。做游戏原型也是一样的道理，画面选项和性能之间永远是取舍关系。

4.2 实际体验：三个版本玩起来感受差异极大

从实际试玩的体验来说，三个版本我各玩了三局，体验差异确实很大：

Step 5 Preview那版整体就是“稳”，没有惊喜但也完全没有惊吓。迷宫弯弯绕绕，走起来像传统迷宫游戏，没有音效小地图这些花活，但全程操作顺畅，成功通关后能看到胜利画面显示用时，整体就是个干净完整的作品。

DeepSeek V4 Pro那版一进去就被小地图吸引住，真的省去了很多“我在哪、我要去哪”的无头苍蝇感，配合计时器，我连续玩了五局想刷新纪录。音效虽然只是简单的合成音，但反馈很清晰——路过可通行区域、撞墙、靠近宝藏都有不同的提示音。美术虽然没有GLM好看，但功能性最强。

GLM5.3那版视觉冲击力最强，光照和材质让迷宫更立体，宝藏点的金色光晕确实有“寻宝”氛围感。但基础玩法在修复后仍有一个小遗憾：角色贴身撞墙停下时，画面还是会微微一抖，虽然不影响玩法，但仔细体验能感觉到不够精细。

这部分的个人感受是：如果问家人朋友“这哪个好玩”，多数人会选DeepSeek V4 Pro版本，因为小地图和音效带来的游戏反馈比单纯画面更直接。而如果展示给设计师看，GLM5.3版本更容易赢得“哇”的惊叹。

5. 开发与调试实录：三个模型遇到典型问题时的表现

这一节记录的是我作为使用者，在开发调试过程中实际遇到的问题、排查思路和每个模型的反应。这些内容比较琐碎，但真实项目中恰恰是最花时间的环节。

5.1 三个模型的排错能力横评

DeepSeek V4 Pro第一版报错之后，我把浏览器控制台的报错信息原封不动粘给它。它做的第一件事是定位到具体行号，指出是什么作用域冲突，然后给出了完整的修复代码块，并提醒我“如果阴影仍然影响性能，可以关闭阴影渲染”。这种“给出方案并附带额外建议”的处理方式，在实际协作中效率非常高。

GLM5.3在处理穿墙bug时，第一次修复确实解决了穿墙问题，但也引入了相机抖动的新问题。当我追问“为什么角色在撞墙后画面会抖”时，它才开始意识到是位置修正不够平滑，补了一个插值过渡。这说明它在“从一个bug引出一个新bug”的链条上，缺少预见性，只能头疼医头。

Step 5 Preview虽然首版就没报错，我也故意改坏了几个变量来测试它的排错能力。它的回复风格更偏向“解释问题产生的原因，再给修复方案”，多了一个“为什么”的维度，这对开发者理解问题本质比直接给补丁更有帮助。

5.2 复杂交互中的常见问题速查

这次测试中出现的几个问题，我认为有很强的普适性，几乎在做任何three.js小游戏时都会遇到。我整理了一个排查表，方便大家直接对照：

我在三个模型生成的代码里轮番遇到了这些情况，尤其是“卡住不能移动”和“视角抖动”两个问题，出现概率很高。如果你准备用自己的方式写three.js小游戏，建议把这张表存下来，排查时能快很多。

5.3 一次有效的AI协作式开发工作流

经过这次实测，我总结出一个“AI写游戏”时比较稳定的工作流，这也是我后来做项目一直在用的方法：

第一步，把需求写成一个完整段落，包含玩法、技术栈、约束条件。约束条件一定要写清楚，比如“代码须是单个html文件”“不允许使用其他UI框架”，否则模型可能自由发挥过头。

第二步，首版代码生成后先别急着改，直接在浏览器跑一遍，收集第一手的报错信息。这一步最忌讳的是把报错内容丢进对话时不给上下文，要贴完整报错截图或控制台原文字段。

第三步，按优先级修bug：先保核心玩法（能不能动、能不能赢），再管体验细节（抖动、帧率、音效），最后才做视觉增强。如果模型一开始就把粒子特效堆得很满但又导致掉帧，可以明确要求“删掉粒子系统，优先保障60FPS”。

第四步，稳定运行后，把需求里的修改继续分轮次迭代，每次只提一个小需求点。我见过很多人喜欢一口气给模型列五个新需求，结果模型改来改去把原有逻辑改崩了。一次只改一件事，是最稳的做法。

6. 选型建议与个人使用心得

测完这三个模型，抛开厂商的技术宣传，单从这次3D游戏实测的体验出发，我的总结用一句话概括就是：Step 5 Preview 适合求稳的人，DeepSeek V4 Pro 适合求全的人，GLM5.3 适合对画面有执念的人。

6.1 不同需求下的选择参考

如果你做一个内部原型，需要快速验证一个玩法想法，Step 5 Preview 的直接可用体验会帮你省下大量时间。第一版跑通后，再根据实际体验迭代功能，它的稳定性能兜住你的需求。

如果你做的是要给用户或客户展示的Demo，希望五个功能点都点得到、玩得明白，DeepSeek V4 Pro 的功能丰富度是首选。它附带的小地图、计时器、音效这些细节，会显著降低Demo的“简陋感”，哪怕代码量大一些也值。

如果你是想做后期效果展示、或者本身就偏美术方向，GLM5.3 对光照、材质、粒子效果的把握确实更强。但前提是你得做好多轮调试的心理准备，并且你自身要有能力识别它代码里的逻辑bug，不能只依赖模型自查。

6.2 几个能提升AI生成质量的通用技巧

最后再分享几个这次测试之后我自己一直在用的技巧：

提示词里永远写清“完整可运行”和“不要简化”。只要我不加这句话，模型偶尔会偷懒，用注释代替真正实现，生成一个空壳。

遇到bug时直接贴报错信息，不要自己描述“好像有bug但不报错”。描述越模糊，模型的修复越容易跑偏。报错信息本身是模型最好的反馈信号。

想要画面好看，在需求阶段就明确写“添加环境光、阴影、材质色调”，而不是等生成完再补。模型首版设计时就是按“完整度”规划的，后续追加需求的改动成本比一开始就提要高十倍。

这次测试做完，我对AI辅助开发的态度反而更务实了。没有全能的模型，只有更匹配你当前任务的选择。就像做菜，有人喜欢稳定的大众菜馆，有人爱尝试创意料理，各有各的好，关键是你今天请什么客人、给谁吃。