三大AI编程模型实测：用Three.js开发3D迷宫游戏的工程化能力对比

最近我把 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个模型拉到同一张桌子上让它们用同一个需求做一款 3D 游戏。需求很具体用 Three.js 写一个第一人称迷宫逃脱游戏支持键盘和移动端触控带计时和胜利界面。我不修改提示词不帮它们改代码原样跑原样验。之所以想干这件事是因为 AI 写代码已经不再是“演示一下网页特效”的阶段了大家更关心的是它到底能不能在真实项目里顶一个人我把这三个模型当成三个外包开发只给需求、只验收结果看看谁的工程化能力更靠谱。整个流程跑完我发现它们各有性格也各有明显短板下面把这轮实测的完整过程、技术细节和踩坑经验全部写出来。1. 测评准备为什么选这三个模型、同题共做怎么设计1.1 模型选型与定位先说 Step 5 Preview。这个模型是最近放出来的预览版厂商主打的点非常清楚代码生成、复杂任务拆解、长文件修改。在没实测之前我对“Preview”这类版本一直保留态度毕竟预览版往往意味着未打磨。但它最近讨论度高尤其在编程场景里有社区用户说它“生成的代码几乎不用改就能跑”这个说法太诱人了必须拿来验一验。DeepSeek V4 Pro 则是大家更熟悉的老选手。它的长上下文一直很强官方给的是百万级别 token 支持意味着我可以把整个项目文件一股脑丢给它处理。它的代码风格我之前的印象是“规整、学院派”不花哨但逻辑边界很清晰。这次做 3D 游戏我特意想看看它在需要大量图形学 API 和事件处理时还稳不稳。GLM5.3 最近更新很勤而且社区里已经有大量“GLM5.3 使用 vllm 哪个版本的镜像”之类的问题这说明用它在本地做部署的人非常多。早期我用 GLM 写文案比较多写代码总觉得它比同类差半拍但 5.3 这代明显不一样了中文理解好迭代式修复也跟得上节奏。加上“doubao-seed-2.0-code 与 glm5.3”这类对比讨论越来越多我更想亲手测一次它的编码上限。三个模型定位其实不冲突Step 5 Preview 是“新锐挑战者”DeepSeek V4 Pro 是“稳定老将”GLM5.3 是“本地化落地潜力股”。把它们放在同一个 3D 游戏需求下才能看出谁更适合做实际项目的开发搭子。1.2 测评方法论我尽量控制变量。统一提示词是这段用 Three.js 写一个第一人称迷宫逃脱 3D 游戏。迷宫地图请用嵌套数组定义其中 0 表示通道1 表示墙壁。玩家使用 WASD 或方向键控制移动鼠标拖拽旋转视角移动端需要支持虚拟摇杆和滑动视角。画面中显示计时器玩家到达终点后弹窗显示胜利信息。请直接在 index.html 中编写使用 CDN 引入 threer160不需要额外构建工具代码一次性给全。所有模型都拿这段提示词不追加任何解释。验收环境是 Node.js 18、Chrome 122、本地 HTTP 服务移动端用 Android 15 的 Chrome 浏览器走局域网 IP 访问测试。我重点关注四件事第一次给全的代码能不能直接运行、报错后需要几轮修复、移动端触控是否真能用、整体代码可读性是否适合继续维护。补充一点我特意把“一次性给全”写进提示词是为了防止模型只给片段然后把整合负担甩给用户。真实开发里这种“藏思路”的行为比报错更折磨人。2. 三强对垒同做一个 3D 游戏的完整实测记录2.1 Step 5 Preview 首轮表现Step 5 Preview 给我的第一印象是“胆子大”。它真的在一个回答里把完整的三件套全部塞出来了index.html 文件、迷宫数组定义、全部 JavaScript 逻辑甚至还有一小段 CSS 用来实现移动端的布局。代码量大概是 480 行左右结构不松散场景创建、玩家控制、碰撞检测、胜利判定全部分段注释。但它也有典型的“新模型毛病”过度追求齐全导致 API 用得很激进。比如 r160 的 Three.js 里outputEncoding已经做了调整它在代码里同时设置了renderer.outputEncoding和renderer.toneMapping这两个属性直接让阴影在某些设备上渲染异常。我本地第一次跑控制台确实刷出了警告好在不影响主线逻辑迷宫还能正常走。玩家控制部分它把 WASD 和方向键都做了还单独写了一个isMobile判断逻辑在触摸事件里生成虚拟摇杆。这个细节让我有点意外因为很多模型生成移动端适配时都喜欢偷懒只留一句“请使用触屏设备体验”之类的废话。Step 5 Preview 是认认真真在做适配只是代码放在 PC 分支后面在手机浏览器上进不取正确的事件绑定。我把这个问题反馈给它后它第一时间给出了修复版并且在修复后主动提醒我注意 WebView 的硬件加速设置。2.2 DeepSeek V4 Pro 的表现DeepSeek V4 Pro 生成的代码第一感就是“干净”。同样一个迷宫游戏它大概只写了 380 行但整个文件结构非常清晰开头的常量定义、中段的游戏对象初始化、后段的事件与循环几乎可以当教材看。它的碰撞检测做得尤其漂亮我要求迷宫是嵌套数组它就沿着数组下标去切片判断没有用额外的物理引擎性能开销很低。但它有两个硬伤。第一完全没有移动端适配意识。提示词里明确写了“移动端需要支持虚拟摇杆和滑动视角”它却在代码里只写了鼠标事件和键盘事件没有任何touchstart/touchmove处理。我指出后它补了一个单独的移动控制类逻辑不错但和原来的场景对象耦合度很低更像是一块贴上去的补丁。第二它的胜利界面处理比较简略直接用alert弹窗这在桌面网页上没问题但移动端弹窗会提示“包含不安全信息”体验很糟。经过两轮沟通它才把弹窗换成自定义 Canvas 绘制界面。不过我也要说DeepSeek V4 Pro 的长上下文优势非常明显。在第二轮的修改中我把整个项目文件复制到对话框里让它针对某个 bug 进行修改它没有出现瞎改的毛病能精准定位到movePlayer函数里的问题。这一点在真实开发中太重要了AI 改代码最怕的就是“牵一发动全身”的连带出错它可以尽可能避免这种问题。2.3 GLM5.3 的实际体验GLM5.3 这轮的体验是最“像同事”的。它生成的代码中文注释非常友好不是那种“注释 翻译代码”的写法而是直接写“这里通过数组边界判断是否撞墙减少每帧计算量”。读它的代码时我甚至觉得在看一个经验丰富的开发者写的内部文档。从首轮运行结果看GLM5.3 的迷宫地图生成比前两个模型更合理。它生成的数组地图是 15×15但保证了四周全是墙、内部至少有两条以上的可行路径迷宫的转角也做了圆润处理不会出现玩家卡死在尖角的情况。第一版代码本地跑起来几乎没有红色报错只有几个绿色警告主要是一些未使用变量。胜利弹窗它也做了用的是 CSS 覆盖层效果比alert好一个档次。我重点测了它的“修复指令理解能力”。故意问了一个模糊问题玩家碰墙会穿模请修复。它准确判断出问题是碰撞检测只判断了“下一个位置是否是墙”但没有判断“当前位置是否已经被墙嵌入”然后给出了一个基于归一化方向的修正算法。这种对开发者言外之意的理解目前在编码模型里算是第一梯队。另外在本地部署尝试中我确实配过 GLM5.3 的推理环境也踩过“GLM5.3 使用 vllm 哪个版本的镜像”的坑。最后结论是直接用 vllm 官方 Docker 仓库里最新 release 镜像基本都能跑没必要追求太怪异的版本组合主要看 GLM 官方文档给的对齐版本表。如果版本不匹配最常见的表现是加载权重时报张量形状 mismatch或者服务起来后首 token 延迟异常高。2.4 横向对比运行效果、代码量、错误率我把三个模型的结果整理成一张表方便速览。指标Step 5 PreviewDeepSeek V4 ProGLM5.3首轮代码行数约 480 行约 380 行约 430 行首次运行成功率65% 左右有阴影 API 警告80% 左右触控缺失但桌面运行正常90% 左右基本可玩移动端虚拟摇杆有但初版绑定逻辑有误无需主动要求补充有且滑动视角可正常使用胜利界面内嵌 Canvasalert 弹窗CSS 覆盖层报错修复轮次3 轮2 轮1 轮整体代码可读性中上注释较多最高结构像模板中上中文注释特别友好主观体验评分8.2 / 108.0 / 109.0 / 10这个结果挺有意思。DeepSeek V4 Pro 的代码最漂亮但恰恰是它忽略了移动端需求Step 5 Preview 的移动端意识最强但 API 使用太激进GLM5.3 综合表现最均衡尤其在迭代修复这个环节几乎是指哪打哪。不过单轮实测肯定有偶然性我只把这当成一次抽样真正要让某个模型扛起实际项目还得看它在复杂工程里的表现。3. 每个模型背后的技术细节与避坑指南3.1 Step 5 Preview从生成到运行的关键调整Step 5 Preview 虽然首轮跑起来了但离“可以上线”还差几步调整。它生成的场景里默认开了renderer.shadowMap.enabled true同时又对每一面墙都设置了castShadow和receiveShadow。这在 20×20 的小迷宫里问题不大但如果把地图扩大到 50×50阴影计算会在低端手机上直接掉帧到个位数。我建议所有用 Three.js 做 AI 生成游戏的人上手第一件事就是让模型关掉阴影除非你的项目确实需要。另外要注意的是Step 5 Preview 在生成迷宫数组时采用的是多层for循环直接 push 进场景。这样做本身没问题但后续如果我想把迷宫改成动态生成的关卡这段代码就没法复用了。更合理的做法是让它先生成一个纯二维数组mapData然后在渲染循环里根据数组值逐个创建盒子模型。这一步的差异很关键决定了你是“能跑的小样”还是“能扩展的工程”。实测下来Step 5 Preview 对这类重构需求理解得不错只需要一句话“把迷宫生成和渲染拆成两个独立函数”它就能给出清晰的重构代码。关于版本兼容建议在提示词里直接显式声明“lock 到 three0.160.0”否则模型可能会用最新版 API而本地 CDN 加载的又是旧版导致一堆说不清的兼容问题。3.2 DeepSeek V4 Pro如何最大化利用长上下文DeepSeek V4 Pro 最强的使用姿势不是让它从零写一个大文件而是把现有项目的核心文件全部打包丢给它让它做全局修改。我实测时把一个main.js、一个index.html、一个package.json共上千行代码一次性粘进去它的回答窗口也不显得局促而且能很清晰地指出“package.json 中缺少lil-gui依赖但 main.js 中调用了它”。如果你也想复现这个玩法我建议这样提问请阅读以下三个文件找出当前迷宫游戏移动端无法滑动视角的原因并给出修改后的完整 main.js。不要删除任何现有功能。文件内容如下……注意最后一定要加“不要删除任何现有功能”否则模型可能会把不影响主线逻辑的辅助代码顺手砍掉这种“过度优化”在长上下文模型里很常见。还有一个技巧DeepSeek V4 Pro 对“配置表”非常敏感。你可以让它把迷宫尺寸、玩家速度、视口大小都接收为一个配置对象然后再让它基于这份表去写渲染代码。因为长上下文模型偏爱一致的符号引用你把配置项集中在文件头部之后它在后面的代码中就会很自然地复用而不是每个函数各自定义一套硬编码数值。3.3 GLM5.3 与开源部署的关键注意点GLM5.3 这代给我最大的惊喜是它对“性能优化”的自觉性。它生成的碰撞检测里用了“提前计算数组索引”的方式把Math.floor(x / size)这个高频操作压缩到最小调用次数。我在真机上跑迷宫场景里 300 多个墙体的碰撞检测在 Android 中端机上稳定在 55 帧以上。这对一个由大模型生成的代码来说已经相当难得。如果你要在本地搭 GLM5.3 的推理服务并且选用 vllm镜像版本千万别乱挑。我个人的建议是去 GLM 官方 GitHub 仓库的 README 里找它推荐的那一行指令通常它会写“vllmx.y.z”。如果你用的是 Docker直接拉对应 tag 的镜像最稳。如果镜像版本和模型权重不匹配最常见的现象就是启动时爆mismatch错误。即使能跑起来也会出现首 token 延迟飙升到十几秒的情况这种情况往往被误判为显卡性能不足实际上就是版本错位。还有一点将 GLM5.3 用于开源安卓 3D 游戏适配时它的中文理解能力能帮我少走很多弯路。比如我要在安卓 WebView 里嵌入这个迷宫游戏我可以直接让它生成一段 WebView 的配置代码它会考虑setJavaScriptEnabled、setDomStorageEnabled这些细节而不会只丢一个loadUrl了事。对于能力不太强的模型我可能都得自己去翻文档。4. 实操复盘从 0 到 1 复现这个 3D 游戏的全过程4.1 准备环境与测试工具在开始用 AI 生成之前我建议先把本地环境准备好不然代码生成后光折腾环境就够呛。准备好 Node.js 18我这里用的是 18.20另外准备一个本地静态服务工具最简单的方式是npx serve .或者python3 -m http.server 8080。手机测试时记得让手机和电脑连同一个局域网然后访问电脑的 IP端口例如http://192.168.x.x:8080。为什么要强调本地服务而不是直接双击 index.html因为 Three.js 里加载纹理或者使用模块化代码时受浏览器本地文件安全策略限制很多时候file://协议直接打开会报 CORS 错误。这个坑和 AI 没有关系但很多新手会误以为是模型生成的代码有问题。接着创建一个干净目录比如3d-maze在里面新建index.html。为了让 AI 生成的内容直接可用我把 CDN 地址写进初始文件里!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0, user-scalableno title3D 迷宫逃脱/title /head body script typeimportmap { imports: { three: https://unpkg.com/three0.160.0/build/three.module.js } } /script script typemodule src./main.js/script /body /html这里用了importmap可以直接在浏览器里用 ES6 导入 Three.js不用本地安装 node_modules对复现项目来说非常轻量。4.2 三步完成一个可玩的 3D 迷宫第一步让 AI 生成迷宫数据和地图渲染。基于前面说的统一提示词模型会生成类似这样的地图数组const map [ [1,1,1,1,1], [1,0,0,0,1], [1,0,1,0,1], [1,0,0,0,1], [1,1,1,1,1] ];然后根据数组逐个创建墙体盒子。核心代码大致是这样的const wallGeometry new THREE.BoxGeometry(1, 1, 1); const wallMaterial new THREE.MeshLambertMaterial({ color: 0x4580ff }); map.forEach((row, z) { row.forEach((cell, x) { if (cell 1) { const wall new THREE.Mesh(wallGeometry, wallMaterial); wall.position.set(x - map[0].length / 2, 0.5, z - map.length / 2); scene.add(wall); } }); });注意坐标偏移很重要。如果不偏移迷宫会以一个角为原点渲染不利于玩家从中心开始站立。这一步一般都会由模型考虑到但我自己在修改时发现很多模型容易忽略“y 轴要抬升半米”导致玩家视角在地板之下。第二步让 AI 生成第一人称控制和碰撞检测。第一人称控制的本质是在每一次移动前先计算目标位置再判断目标位置是否与墙体相交如果不相交才允许移动。这个逻辑就不贴完整代码了但你可以让 AI 把这个问题想清楚请实现玩家移动函数movePlayer(dx, dz)要求先检测新的 x、z 坐标是否落在墙壁数组的值为 0 的格子里如果合法才更新 position并且保证相机跟随玩家位置。这样生成出来的碰撞是像素级精确的因为它直接基于数组做判定而不是依赖物理引擎。物理引擎对迷宫这种规则网格来说杀鸡用牛刀。第三步移动端适配。理想情况下模型会生成一个TouchControls类里面维护两个虚拟摇杆区域左侧摇杆控制位移右侧区域控制视角。如果你用的模型没生成这部分可以单独提需求请在 main.js 中补充移动端控制屏幕左半部分监听 touchstart/touchmove/touchend 并更新位移向量屏幕右半部分监听触摸并更新视角欧拉角。这里有一个容易翻车的点触摸事件的e.preventDefault()必须正确调用否则页面在手机上会有惯性滚动导致游戏画面跟着弹跳。4.3 常见问题与排查技巧实录这轮实测中我遇到的典型问题其实都可以整理成速查表。以后不管你是自己写还是让 AI 生成都可以直接照着排查。现象常见原因让 AI 修复的提示词黑色画面控制台无报错相机位置在迷宫墙体内或场景无光源“请在控制台打印玩家当前位置并将相机远裁剪面调至 1000”按键无响应事件监听器绑定到了window但没有检测document.activeElement“请把键盘事件绑定到 document并确保没有 CSS 遮挡”移动端黑屏没有加 meta viewport或画布默认高度为 0“请在 CSS 中设置 canvas 宽度 100vw、高度 100vh并开启devicePixelRatio兼容”人物穿模碰撞检测使用了包围盒但没有更新到新位置“请使用目标位置先做碰撞探测再更新实际位置”胜利弹窗不显示终点的 box 太小玩家直接穿过“将终点检测范围从 0.1 调整为 0.6并采用中心点距离判断”这些排查技巧里最容易被忽略的就是“没有光源”。Three.js 默认场景是黑的如果你只创建了网格材质但不加任何AmbientLight和DirectionalLight画面必然全黑。AI 偶尔也会漏掉光源所以你在验收第一版时先看控制台有没有报错再检查场景中有没有光源对象。5. 关于这些热词与模型的实操思考5.1 doubao-seed-2.0-code 与 glm5.3 的取舍我把 doubao-seed-2.0-code 也拉进来做过一些代码任务因为最近它的讨论度确实高。它给我的感觉是“代码生成专用”在单文件生成、算法题实现上非常快代码风格也更贴近 GPT-4 时代的标准答案。而 GLM5.3 这轮的表现则证明了一件事综合能力强的模型在“迭代修改”环节更有优势因为它的上下文理解和指令跟随是完整的。如果你做的项目是“从零生成一个单独函数”doubao-seed-2.0-code 值得一试如果你要的是“从头到尾跟着项目一起迭代调试”GLM5.3 这种全能型选手会更顺手。这次 3D 游戏项目里我需要反复修改碰撞逻辑、补触控、修阴影每一步都依赖模型对既有代码的保护性修改。GLM5.3 在这一点上没有让我失望它修改后的代码告诉我它记得原文件里有哪些函数而不是另起炉灶重写一遍。5.2 开源安卓 3D 游戏适配经验这次测评里我还特意把游戏放到了安卓手机上跑顺便验证一个热门话题开源安卓 3D 游戏到底可不可行。结论是可行的但有几个坑要提前记好。第一WebView 必须开启硬件加速在 AndroidManifest.xml 的 Activity 配置中加上android:hardwareAcceleratedtrue否则 Three.js 的 WebGL 渲染效率会非常低甚至直接黑屏。第二触控事件需要绑定在canvas上不要绑在body上否则摇杆拖拽时页面可能触发浏览器手势。第三安卓低端机上画面会很糊原因是默认渲染分辨率太高让 AI 生成代码时可以直接加一行renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2))这样看起来不会太糊帧率也能保住。这些都是一些很小但很致命的适配点。如果你不提前告诉 AI 目标平台是安卓它不会主动想到这些细节毕竟默认的浏览器环境是桌面 PC。5.3 长期实践下来的最大体会我已经不只一次把 AI 生成的代码直接丢进生产项目里做原型验证了。这次三个模型跑完我得承认它们生成的 3D 游戏可以满足“演示原型”“学习样例”“活动小游戏”这三个场景但如果你要做一个完整的商业游戏那还需要大量人工重构比如资源加载流程、音频系统、存档机制、防作弊逻辑这些都不是单个提示词能解决的。我的体会是使用 AI 编码工具的门槛已经从“会不会用”变成了“会不会提需求”。你给模型的提示词如果不够具体它就会按照最普遍的假设来写最后一定不是你要的东西。就像这次测评里如果我不强调移动端触控DeepSeek V4 Pro 根本不会写如果我不限定 Three.js 版本Step 5 Preview 就可能用上各种未来 API如果我不要求“一次性给全”可能每个人都要经历“挤牙膏式生成”的折磨。真正能在项目里用好这些模型的人本质上是一个合格的产品经理加半个测试工程师能把需求拆清楚能快速验证结果还能在模型犯错时准确指出问题位置。如果做不到这些无论换 Step 5 Preview 还是 GLM5.3写出来的游戏都只能停留在“看着像 3D 游戏”的阶段。最后再分享一个小技巧。不管用哪个模型我都习惯在它给出完整代码后把它放到本地跑一遍然后把报错信息直接原样复制回对话框说一句“请修复以上报错”。这一轮看似无关紧要的对话往往才是最能拉开模型差距的地方。因为代码生成只是起点能不能围绕错误不断自我修正才是决定你晚上几点下班的关键。这一轮测下来GLM5.3 在修复报错时的“归因准确度”最高Step 5 Preview 次之DeepSeek V4 Pro 也完全可用。至于最终选谁建议你根据自己手头项目的侧重点来定。