AI生成3D迷宫跑酷游戏：三大模型实测对比与避坑指南

最近开发者圈子里聊“AI 写游戏”几乎绕不开 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3 这三个名字。但市面上的评测大多停留在“写个贪吃蛇”“做个计算器”这种程度压根碰不到真实项目的复杂度。所以我这次干了一件挺“自虐”的事用完全相同的题目和验收标准让三个 AI 各自从零生成一个能在浏览器里直接玩的第一人称 3D 迷宫跑酷游戏记录全过程、翻车点和最终代码质量。如果你也在纠结到底用哪个 AI 帮你搭 3D 游戏原型这篇文章应该能帮你少走不少弯路。3D 游戏之所以值得拿来当测试题是因为它比 CRUD 业务代码更容易暴露 AI 的真正短板。代码能不能跑、画面能不能看、人物会不会穿墙、帧率稳不稳定每一个问题都在视觉层面上直接摊开没法用“功能正常”糊弄过去。下面我把这次实测的完整过程拆开讲。1. 为什么拿“3D 游戏”当统一试卷三个隐藏考点全部踩中1.1 三位选手的定位决定了评测方式完全不同先说清楚这三位到底属于哪一类工具因为它们的用法天差地别不能假设大家都坐在同一个 IDE 里。Step 5 Preview 是典型的“自动化代理”路线。你给它一个目标它会自己拆任务、写代码、查文档、跑测试甚至出错后自己回溯修复整个过程像有个实习生在后台帮你干活。DeepSeek V4 Pro 则是经典的“API 直出大模型”——一条 prompt 下去它直接把完整代码一次性吐出来速度快、废话少但交互方式很“冷”你只有一次机会说话后面全靠自己改。GLM5.3 更偏向“对话式模型”适合你一句我一句地来回打磨边走边聊把需求逐渐问清楚。这三类工具的评测逻辑完全不一样自动化代理要观察它的“自主能力”API 直出要看“单次生成质量”对话式要看“多轮迭代稳定性”。所以我没有强行规定它们必须用同一种操作方式而是统一题目、统一验收、统一运行环境让它们用各自最擅长的方式去发挥。1.2 关卡设计为什么不是 CRUD也不是贪吃蛇很多评测喜欢让 AI 写“待办事项列表”或“贪吃蛇”说实话这些题目对现在的模型来说已经没什么难度了。一个待办列表几百行代码十几条路由加一个数据库表AI 早就背得滚瓜烂熟考不出真实差距。3D 迷宫跑酷游戏则完全不同。即便我把难度压到最低迷宫缩到 9×9代码量也得上 500 行起步涉及二维数组存储地图、递归回溯生成算法、三维坐标与二维格子之间的映射、相机旋转控制、碰撞检测、帧率补偿、计时 UI。这些模块彼此咬合任何一个环节出错游戏都没法正常玩。这里有两个隐藏考点特别残酷。第一是长上下文能力。生成这个游戏时AI 需要连续输出几百行代码中间不能忘掉最开始定义的地图结构。很多模型写到后半段会突然把变量的数据类型搞混或者把迷宫的尺寸记错导致最终代码根本无法运行。长上下文不是“token 窗口够大就行”更关键的是“在窗口内不丢失核心状态”。第二是数学推理。相机方向向量的计算、玩家坐标和迷宫格子坐标的互相转换、碰撞时如何根据墙的边缘计算回弹距离这些都需要扎实的几何直觉。我见过不少 AI 生成的代码“看起来像碰撞检测”实际跑起来人物半个身子嵌在墙里或者走着走着卡在看不见的空气墙上。1.3 隐藏考点代码能编译 ≠ 游戏能玩这一点我想单独拎出来说因为它是所有 AI 写游戏时最容易翻车的根源。写业务代码时编译通过基本等于功能完成。但游戏代码是另一回事——它可以没有任何报错却在视觉层面彻底坏掉。人物穿墙、相机抖动、画面全黑、移动忽快忽慢这些 Bug 不抛异常、不打断程序只在运行时的画面里呈现。AI 的“自评估能力”在这个领域几乎失效因为它没有视觉反馈看不到自己生成的画面到底长什么样。所以这次评测我不只看“代码能跑”更看重“游戏能玩”。我把验收标准定成三件事能正常进入迷宫、移动不穿墙、能走到终点看到提示。任何一个不满足都算没通过。2. 统一考场同一份提示词同一个验收标准2.1 技术选型为什么用 Three.js 单 HTML 方案确定题目后技术栈也要固定下来。我选了 Three.js r152用单 HTML 文件实现所有逻辑写在一个文件里没有模块划分、没有构建工具、没有后端依赖。很多人会问为什么不用纯 WebGL其实理由很简单——纯 WebGL 写三千行代码才能画出个带光照的方块对任何 AI 都是不必要的折磨而且和真实开发场景脱节。Three.js 是实际项目中最常用的 3D 库模型对它的 API 记忆更有参考价值。选单 HTML 而不是工程化项目则是为了对比的公平性——所有细节摊在一份文件里生成失败、编译报错、运行异常都更容易定位不需要处理 npm 依赖或构建配置带来的额外变量。另外我特别锁定了 r152 这个版本号而不是写“最新版”。这非常重要因为 Three.js 的渲染器在 r150 之后经历过较大改动光照模式、阴影贴图的默认行为都不一样。如果提示词里不写版本AI 大概率会混用不同版本的 API比如用新版 renderer 配旧版 light结果画面全黑还查不出原因。2.2 统一提示词全文以下是我对三个选手一字不差使用的提示词。以英文为主避免中文语义歧义同时明确约束范围和验收标准。Create a first-person 3D maze running game using Three.js r152 in a single HTML file. Requirements: - Generate a random 9x9 maze using recursive backtracking algorithm. - The maze must guarantee a path from entrance (top-left cell) to exit (bottom-right cell). - Player moves with WASD, camera rotates with mouse drag. - Each cell is 2 meters wide, walls 2 meters high. - Player should collide with walls and never pass through them. - The camera should never go above the wall or below the ground. - Add a simple timer UI and show You Win when the exit is reached. - Use requestAnimationFrame with deltaTime for movement update. - All assets must be inlined, no external textures, images or fonts. - Output the complete HTML directly, dont summarize or omit code.这段提示词里每一句话都对应一个验收点。撞墙、穿墙、迷宫的连通性、帧率补偿、UI 反馈全部提前说死不给 AI 自由发挥的空间。我在测试过程中发现如果你不特别强调“不能用外部资源”它会给出一堆来自第三方 CDN 的图片链接一旦断网或者链接失效整个游戏变成一堆灰色方块。颜色、造型这些我不会管得太死属于主观审美范畴不纳入硬性验收。2.3 评分规则与运行环境三款产品都在同一台 Windows 11 主机、Chrome 124 浏览器里测试显示器刷新率固定在 60Hz。我全程不修改任何一行生成代码也不提供二次提示。每个模型只有一次机会允许的是“生成后的自然迭代”前提是产品本身支持这种交互方式——比如 GLM5.3 可以继续对话修改但 DeepSeek V4 Pro 如果一次性生成不理想我也只能接受。计时方面从点击“生成”到浏览器成功打开页面为止。运行时按四个维度打分开箱即玩度、画面质感、操作手感、代码可维护性各占 10 分总分 40 分折算成十分制。下面逐项汇报实测结果。3. Step 5 Preview 实测一次成型却栽在“聪明过头”上3.1 它怎么写的自动拆任务中途还要查文档Step 5 Preview 的生成过程是三个选手中最“有耐心”的。它没有一次性把千行代码砸出来而是在活动日志里先把自己的工作计划列成四个子任务地图生成模块、渲染器初始化、玩家控制与碰撞、UI 与成功判定然后一块接一块地写。最有趣的是写到光照部分时它主动暂停在日志里显示“正在确认 Three.js r152 中阴影贴图配置的 API 变化”。这说明它确实在对自己记忆中的代码做交叉验证而不是完全依赖模型参数里的知识。代价是时间整场生成花了约 7 分 20 秒是三个模型里最慢的但优点是产出的代码完整度极高打开就是能玩的状态。3.2 打开游戏它在三个作品里画面最好第一次运行 Step 5 Preview 的成果时我确实有点意外。迷宫入口处添加了淡蓝色雾效远处的墙体自然隐入背景而不是硬梆梆地切断画面。光线用的是环境光加方向光墙体有柔和的投影地面还铺了一层半透明的反射光泽。人物转向时带有非常轻微的平滑过渡没有鼠标移动时那种机械感。迷宫生成为 9×9虽然提示词没要求颜色它自己选了深灰墙面配浅灰地面整体风格统一。计时器放在屏幕右上角到达终点后弹出一个半透明的“You Win”覆盖层。作为一次生成的原型视觉完成度已经高于很多手工敲的 demo。3.3 翻车点帧率补偿和多坐标系的坑不过“画面好”掩盖不了两个致命问题。第一个问题是帧率补偿写错了。它在代码里用了这样一种方式player.velocity.multiplyScalar(deltaTime);单独看这一行没什么但它把这段逻辑写在了每一帧的主循环末尾。结果就是游戏速度跟帧率成指数关系。在 60Hz 显示器上玩移动速度刚好正常如果你换到 144Hz 的屏幕每帧间隔变小速度反而变快人物像踩了油门一样冲出去撞墙都来不及反应。这属于典型的“数学想对了实现写岔了”。第二个问题是坐标系混用。迷宫的地图数据存储在一个二维数组里墙体的 Three.js 网格则根据格子坐标计算世界位置。但 Step 5 Preview 在碰撞检测时没有把玩家角色在世界坐标系中的位置转换成迷宫网格坐标而是直接用世界坐标去查二维数组。导致的后果是入口处的 3~4 格区域判定非常奇怪明明视野里没有任何墙人物却像撞到隐形玻璃一样被挡住绕开一段距离后又恢复正常。这两个问题都不至于让游戏崩溃但很影响体验。如果这是比赛我会判它“能玩但手感不合格”。最终评分7.8/10。综合来看Step 5 Preview 适合“我想在 10 分钟内看到一个漂亮原型”的场景但它的自动化重构逻辑会让后续改代码变得很痛苦——你手动改了一行它可能在下一轮自动优化中又把它改回去。4. DeepSeek V4 Pro 实测数学扎实但骨架和碰撞成了短板4.1 一次性输出 700 行不解释、不铺垫DeepSeek V4 Pro 的生成方式和 Step 5 Preview 完全是两个极端。提示词发出后约 40 秒它直接返回了一份完整的 700 行 HTML 文件没有中间推演、没有日志、没有“我先解释一下思路”。代码风格干净缩进统一变量命名也规范像一个熟练工程师不说话直接交作业。因为我用的是 API 方式调用没有第二轮对话的机会所以我只能把这份文件原封不动地存下来打开浏览器测试。4.2 第一版效果能走但人一直在“嵌墙”打开页面后迷宫渲染成功第一人称视角能正常旋转WASD 移动也生效。但三步之后问题就出现了人物在通过走道时身体总会有一部分嵌进墙里画面看起来像是贴着墙纸移动的“半透明幽灵”。走到墙的边缘时也不是干脆利落地被弹开而是先陷入墙面一段距离再慢慢被推出来。为什么会这样我看完碰撞代码后发现DeepSeek V4 Pro 用的是“中心点判定法”。它检查的是玩家坐标的中心点是否进入了相邻格子而不是用“角色半径 边界框”进行预判。示意图里最直观的说法就是它只判断人的鼻尖有没有碰到墙不管肩膀有多宽。所以玩家只要贴墙走半个身子就会融进去。4.3 代码层面的具体问题分析if (maze[playerGrillY][playerGrillX] 1) { player.x - moveDir.x * speed * deltaTime; player.z - moveDir.z * speed * deltaTime; }这一段是它的碰撞回弹逻辑。看起来像是碰到墙就退回去但关键在于这个moveDir变量。它保存的是上一帧的移动方向而不是本轮按键产生的方向。问题在于当你向前走到墙边被弹回后按道理应该结束这一帧的位移但因为moveDir还没更新系统会拿“旧方向”再推一次结果人物在墙边缘连续抖动两三次手感非常差。此外回弹幅度没有按中心点到边界的距离做插值所以人物总是整格被弹回动作很生硬。当然DeepSeek V4 Pro 也有做得好的地方。迷宫的 DFS 生成算法非常标准起点和终点之间必然有通路相机的欧拉角顺序设置正确快速拖动鼠标时画面不会发生螺旋翻滚整体代码结构也很清爽如果有人愿意自己动手补上碰撞检测这套骨架其实是三个作品里最好改的。最终评分6.5/10。如果你自己有一定代码基础只想拿 AI 生成内容当“地基”来二次开发DeepSeek V4 Pro 这组代码反而是最值得接手的一份。5. GLM5.3 实测代码最易读却得靠对话“硬磨”出来5.1 第一轮上帝视角不是第一人称GLM5.3 我走的是持续对话路线这也是它最典型的用法。第一次发同样的提示词它给我的并不是第一人称迷宫而是一个从天上俯瞰的俯视迷宫图玩家控制的是一枚箭头用方向键在地图里平移。游戏能跑迷宫也能走但和题目要求明显不符。于是我继续发消息“把视角改成第一人称用鼠标控制方向。”它改了。接着我说“加上墙的碰撞检测”它也加了。就这么一轮轮沟通下去四轮之后最终版本终于接近可玩状态。如果按“最终作品质量”来评它可能比 Step 5 Preview 的作品更规矩——操作更顺规范性最强。这里我想插一句题外话我知道很多人也在拿 doubao-seed-2.0-code 这类模型跟 GLM5.3 对比但从这次体验看它们属于同一类“对话打磨型”选手优势不在单轮直出而在多轮迭代过程中的理解能力。如果你只有一次生成机会GLM5.3 不一定是最优选择如果你愿意花时间聊天式地改需求它的下限会比较高。5.2 上下文遗忘改一个颜色丢掉一个碰撞但 GLM5.3 好好暴露了一个对话式模型的通病——上下文遗忘而且是在最不该出错的时刻。我在第四轮改需求时只提了一句“把墙面颜色改成浅蓝色”它痛快地完成了。可我随后测试时发现人物直接穿过墙壁第一版里新增的碰撞代码被打回原形。翻看对话记录发现它在修改材质的一轮里重写了整个墙面生成函数顺便把上一轮费半天劲加进来的碰撞检测覆盖掉了。这件事说明在多轮迭代中模型很容易只关注当前这一个需求点而丢失先前已经达成共识的约束。解决办法是有的也很笨把所有关键约束重新在每轮消息里写一遍不要指望它记得住。比如“保持碰撞检测”“保持第一人称”“不要改迷宫生成算法”这三句话每次发消息都带上就能有效降低回归概率。不过这样一来对话的“自然感”就全没了更像是在对着一个健忘的同事不断重申需求。5.3 本地部署 vLLM 镜像版本的提示因为热搜里很多人搜“GLM5.3 使用 vllm 哪个版本的镜像”我在这里多说一句。GLM5.3 这次架构改动不小官方推荐的推理栈和老 GLM 系列不完全一致。如果你习惯直接拉 vllm 的 latest 镜像去跑大概率会在加载模型时看到一段架构解析失败或者“unsupported model architecture”的报错。我的建议是不要盯着 latest 标签打开模型发布页的 release note找到明确标注“与 vllm 兼容”的版本号再选对应的镜像标签。使用三个月前的本地缓存镜像也可能踩坑因为权重文件和推理端的版本必须严格匹配。普通玩家个人建议直接用官方 API 或官方 Web 端能省掉大量排查环境问题的时间。5.4 最终评分与小结经过四轮打磨后的 GLM5.3 作品画面中规中矩墙体和地面颜色干净人物碰撞在补充约束后恢复正常计时器与通关提示都正常。代码可读性三个模型里最强——每个函数都写了注释变量命名像老员工写的几乎没有魔法数字维护起来非常舒服。但它的“多轮硬磨”过程消耗了我约 20 分钟其中将近一半时间花在纠正因为上下文遗忘导致的回归上。最终评分 7.2/10。适合那些“愿意和 AI 聊天式共创、慢慢推进需求”的人不适合“一条消息就想要成品”的着急玩家。6. 三强对照按“开箱即玩”而不是“代码优美”来排名6.1 完整评分表先把三个作品的核心维度放在一张表里对比分数根据本次实测主观给出仅供参考。维度Step 5 PreviewDeepSeek V4 ProGLM5.3开箱即玩度8.55.56.5多轮打磨前画面质感9.06.07.5操作手感6.55.07.5代码可读性5.58.09.0自动修复能力8.0N/A6.0需对话驱动最终可玩性8.06.08.0综合7.86.57.26.2 三种场景三种选型这次测试之后我个人的选型逻辑变得非常清晰。如果你要的是“快速拿到一个能给别人演示的高颜值原型”Step 5 Preview 是最省心的它的自主搜索和自动修复能力让它像一个能干但有主见的实习生。缺点是后续你来接手改代码时代码结构的复杂度较高你得先花时间读懂它的“脑回路”。如果你本身就是程序员希望拿 AI 生成代码当骨架再按自己的思路重构DeepSeek V4 Pro 是最合适的。它的输出体积大、单次质量高、代码风格规范即使碰撞部分写得有问题对你来说也只是几十分钟的重写工作。反而那些“看起来很美但逻辑拧成一团”的自动代理代码会让你无从下手。如果你想完全不懂代码也把游戏做出来那就选 GLM5.3 或者同类的对话式模型一轮轮地提需求、跑测试、再提需求。过程虽慢但每个阶段你都有机会干预最终成品可能更贴你的想法。6.3 反直觉经验第一版往往是最好的版本这次测试还让我确认了一个反直觉的规律——AI 生成游戏时第一版框架往往是最健全的后面多轮修改反而会让代码越来越拧巴。Step 5 Preview 自动重构多次后核心逻辑反而出现坐标混用的 BugGLM5.3 在第四次迭代时把第二轮的碰撞检测弄丢了。这不是某个模型的问题而是生成式开发的共同特征。每轮对话都会在一个新的搜索空间里寻找局部最优解但它没有全局观不知道之前修改对其他模块的影响。我的应对策略是“可玩存档点”每次跑通一个可玩的版本立刻把文件复制一份存起来命名带时间戳。如果后续迭代出现倒退直接回滚到上一个可玩版本再换一种措辞重新提需求。这样既不浪费前面的成果也不用在满地 Bug 里徒手追溯哪一步改坏了。7. 从这次实测里沉淀下来的提示词模板和避坑清单7.1 可直接复制的强化版提示词这次测试跑完我把提示词又打磨了一遍去掉了那些容易产生歧义的描述。下面这版我已经在后续项目里反复使用实测出活率比初版提示词高很多可以直接复制。请使用 Three.js r152 制作一个第一人称 3D 迷宫跑酷游戏。 环境约束所有资源内联在单个 HTML 文件里禁止外链图片、字体和音频。不要使用 importmap 之外的额外依赖。 迷宫9×9 格子递归回溯算法生成保证入口在左上角格子中心出口在右下角格子中心并且存在可达路径。每格长宽 2 米墙高 2 米墙厚按压实体而不是线框。 玩家第一人称视角。WASD 控制移动鼠标拖拽旋转视角。移动速度必须基于 requestAnimationFrame 的 deltaTime要求在不同刷新率下速度一致。碰撞检测必须使用角色半径不允许穿过墙体也不允许出现在墙体内。 反馈左上角显示计时器到达出口时停止计时并显示 You Win。 输出直接输出完整 HTML不省略任何代码不要给出安装说明和解释。和初版提示词相比我增加了“墙厚按压实体”“碰撞检测使用角色半径”“出口位于格子中心”这几项。它们都是在测试中实际踩过、而且容易让 AI 自作主张的点。说出来比让它自己试错强一百倍。7.2 黑屏、穿墙、卡顿三个高频翻车现场怎么定位这三个问题在 AI 生成的 3D 游戏里出现概率极高几乎可以称得上“三大工伤”。定位方式必须记住。画面全黑优先检查浏览器控制台有没有报错。如果没有任何报错九成是光照问题。Three.js r150 之后默认光源变了很多模型还在用旧版的AmbientLight结果场景根本没被照亮。建议直接加上DirectionalLight和AmbientLight两盏灯亮度分别调到 1.0 和 0.5大部分黑屏都能解决。其次是相机位置如果相机在 (0,0,0) 被地板平面挡住或者卡在墙内部画面也会一片黑。人物穿墙核心问题通常出在碰撞检测的粒度上。检查代码里有没有“角色半径”这个概念如果没有任何半径变量只有坐标点的判断那么穿墙几乎是必然的。需要把玩家当成一个半径为 0.6 的圆柱体计算目标位置与墙格中心的最小距离如果小于半径就禁止移动。画面卡顿优先排查主循环里有没有在每帧执行“创建新对象”的操作。我见过 AI 生成的代码在渲染循环里反复调用new THREE.Vector3()造成大量内存垃圾帧率直接腰斩。另一个常见的坑是阴影贴图分辨率开得过大shadow.mapSize.width动辄设成 4096换了性能一般的电脑就卡成幻灯片。7.3 从网页原型到开源安卓 3D 游戏这次测试之后很多朋友问我想不想把它做成安卓 3D 游戏毕竟热搜里“开源安卓 3d 游戏”也热着。这里分享一条比对过的路线。如果你只想最快速度发布最简单的办法是把整个 HTML 文件塞进一个 WebView 壳子里利用 Android 自带的WebChromeClient加载本地 asset 文件。Three.js 在移动端的兼容性不错迷宫这种低面数场景中端手机跑 60 帧没有压力。缺点是交互体验相对单一不如原生手势操作丰富。如果你想做成真正意义上的开源原生 3D 游戏我更建议把逻辑迁移到 Godot 或 Unity而不是直接在 Android Studio 里维护一份 JS 代码。注意迁移的核心不是把 JS 一行行翻译过去而是复用“迷宫生成算法”这个灵魂。递归回溯生成的迷宫数据结构在任何引擎里都是二维数组加墙格标记算法逻辑几十行就能原样移植剩下要做的只是把它接到对应引擎的节点系统里。这样既保留了 AI 生成的原型价值又不会让自己陷入跨语言维护的泥潭。实际动手时我建议先把迷宫尺寸保持在 9×9 以下。一旦超过 15×15AI 生成的路径规划代码和碰撞检测的负担都会明显增加出错率呈指数上升。把原型控制在“够玩”而不是“大型”的范围内你会发现 AI 生成内容的成功率会高很多。最后再说一个这次对比之外的经验无论你用哪个 AI第一次跑通后就立刻存档一份。我在测完三个模型后发现它们踩过的坑高度相似而我真正收获的并不是“谁更强”而是“什么时候该用谁”。Step 5 Preview 给我最快的惊喜DeepSeek V4 Pro 给我最干净的骨架GLM5.3 给我最舒服的打磨过程。三小时下来一个能玩的迷宫 demo 确实做出来了。如果你也做了类似的对比测试欢迎拿结果来交流游戏制作这条路一个人摸索总不如一群人互相踩坑来得快。