1. 三款模型同台竞技：这个对比测试到底在测什么
三个模型，同一个任务，一个3D游戏。这个测试的设计思路其实很朴素——把Step 5 Preview、DeepSeek V4 Pro和GLM5.3放在同一条起跑线上，看谁能真正把一个可运行的3D游戏从零搭出来。我拿到这个对比需求的时候，第一反应是：3D游戏这个选题选得好，因为它同时考验模型的几个硬能力——空间几何理解、实时渲染逻辑、物理碰撞计算、状态管理，还有最关键的，代码能不能跑起来。
很多人做模型对比喜欢用算法题或者CRUD接口，那些东西区分度太低了。3D游戏不一样，它有一个明确的验收标准：你打开浏览器或者运行程序，能不能看到一个能操控的3D场景。这个标准没法糊弄，代码写错了就是黑屏，逻辑写反了就是穿模，性能没优化就是卡成幻灯片。
我这次实测的环境是统一的：同一台开发机，同样的Node.js版本，同样的浏览器，同样的提示词框架。提示词我打磨了三轮，确保三个模型拿到的需求描述完全一致。需求大概是这样的——用Three.js做一个第一人称视角的3D迷宫探索游戏，包含WASD移动、鼠标视角、碰撞检测、小地图、计时器，以及一个终点触发胜利条件。听起来不复杂对吧？但真正跑起来，每个模型的表现差异非常明显。
提示：做模型对比测试，最大的坑是提示词不一致。你以为你写的是同一个需求，但措辞的微小差异会导致模型理解偏差巨大。我的做法是把提示词写成结构化的规格文档，分模块描述，每个模块给明确的输入输出定义。
为什么选Three.js而不是Unity或者Godot？因为Three.js是纯代码方案，模型可以直接输出可运行的HTML+JS，不需要安装引擎、不需要配置项目文件。这才能公平对比模型的代码生成能力。如果用Unity，模型输出的C#脚本还得手动挂载到场景对象上，中间引入的人为操作太多，变量就不可控了。
这个测试适合谁看？如果你正在选型AI编程助手，或者想了解当前几个主流模型在复杂代码生成任务上的真实水平，这篇实测对你有直接参考价值。如果你只是想找个能写3D游戏的模型，那结论也很明确——往下看。
2. 三个模型的代码生成策略拆解
2.1 Step 5 Preview：结构化最强的方案
Step 5 Preview拿到需求后的第一反应很有意思——它先输出了一份项目结构规划，然后才开始写代码。这个行为在其他两个模型上没有出现。它把整个游戏拆成了场景初始化、玩家控制器、碰撞系统、UI层、游戏状态管理五个模块，每个模块单独一个文件。
这个策略的好处非常明显：代码可维护性高，每个模块职责清晰。但代价是文件数量多，模块之间的依赖关系需要额外处理。Step 5 Preview用了ES6的import/export来组织模块，这意味着你必须用本地服务器来运行，直接双击HTML文件是跑不起来的。
从代码质量来看，Step 5 Preview的碰撞检测写得最扎实。它没有用简单的AABB包围盒，而是实现了一个基于射线检测的方案，玩家移动前先发射射线判断前方是否有障碍物。这个方案在迷宫这种直角场景下表现很好，不会出现穿墙或者卡在墙角的情况。
// Step 5 Preview 的碰撞检测核心逻辑 const raycaster = new THREE.Raycaster(); function checkCollision(position, direction) { raycaster.set(position, direction); const intersects = raycaster.intersectObjects(walls); return intersects.length > 0 && intersects[0].distance < playerRadius; }但Step 5 Preview也有一个明显的问题——它的UI层写得过于复杂。小地图功能它用了一个独立的Canvas 2D渲染循环，跟Three.js的渲染循环并行运行。功能是实现了，但性能开销比预期大。我在低配机器上测试时，帧率从60掉到了45左右。
2.2 DeepSeek V4 Pro：单文件暴力美学
DeepSeek V4 Pro走的是完全相反的路线——所有代码塞进一个HTML文件。打开就是完整的游戏，不需要服务器，不需要构建工具，双击就能玩。这个策略对新手极其友好，你拿到代码就能直接跑，没有任何环境配置的门槛。
单文件方案的优势在于交付简单，但代价是代码组织度低。DeepSeek V4 Pro输出的文件大概有800多行，HTML、CSS、JS全部混在一起。如果你想改某个功能，得在800行里找到对应的代码段。不过它的注释写得还算清楚，每个大段落都有分节注释。
碰撞检测方面，DeepSeek V4 Pro用了最朴素的网格占位法——迷宫本身就是一个二维数组，0表示通路，1表示墙壁。玩家移动时，把目标位置换算成网格坐标，查数组判断是否可通行。这个方案在网格迷宫里完全够用，而且计算量极小，性能是最好的。
// DeepSeek V4 Pro 的网格碰撞 const maze = [ [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] ]; function canMove(x, z) { const gridX = Math.floor(x + offsetX); const gridZ = Math.floor(z + offsetZ); return maze[gridZ] && maze[gridZ][gridX] === 0; }但DeepSeek V4 Pro的弱点在于视觉效果。它的迷宫墙壁就是简单的灰色方块，没有纹理，没有光影变化。能玩，但不好看。如果你想要一个能拿得出手的demo，需要自己后期加材质和光照。
2.3 GLM5.3：平衡型选手
GLM5.3的方案介于前两者之间——它用了三个文件：index.html、game.js、style.css。不算特别模块化，但也不是一坨。这个折中方案在实际使用中体验不错，既保持了代码的可读性，又不需要复杂的构建流程。
GLM5.3最让我惊喜的是它的光照系统。它自动给场景加了环境光和方向光，墙壁有了明暗面，地面有了阴影。虽然都是Three.js的基础光照，但模型能主动想到加这些，说明它对“3D游戏看起来应该是什么样”有基本的审美判断。
碰撞检测方面，GLM5.3用了球体碰撞——把玩家当作一个半径为0.5的球体，墙壁当作长方体，检测球体与长方体的相交。这个方案比AABB更精确，比射线检测更简单，是一个很务实的中间选择。
// GLM5.3 的球体碰撞 function checkSphereCollision(playerPos, wall) { const closest = new THREE.Vector3( Math.max(wall.min.x, Math.min(playerPos.x, wall.max.x)), Math.max(wall.min.y, Math.min(playerPos.y, wall.max.y)), Math.max(wall.min.z, Math.min(playerPos.z, wall.max.z)) ); return playerPos.distanceTo(closest) < playerRadius; }不过GLM5.3的小地图实现有点取巧——它直接用了Three.js的OrthographicCamera渲染了一个俯视图，而不是单独画Canvas。这个方案代码量少，但性能开销比Canvas方案大，因为相当于场景被渲染了两遍。
2.4 三模型策略对比速查
| 对比维度 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 文件组织 | 五模块多文件 | 单HTML文件 | 三文件分离 |
| 运行门槛 | 需要本地服务器 | 双击即玩 | 需要本地服务器 |
| 碰撞方案 | 射线检测 | 网格占位 | 球体碰撞 |
| 视觉表现 | 中等，无光照 | 基础，无光照 | 较好，有光照 |
| 小地图实现 | Canvas 2D | Canvas 2D | 第二相机 |
| 代码可维护性 | 高 | 低 | 中 |
| 性能表现 | 中 | 高 | 中低 |
3. 实操过程全记录：从提示词到可运行游戏
3.1 提示词工程的关键细节
我用的提示词不是一句话，而是一份结构化的需求文档。为什么这么做？因为3D游戏涉及的技术点太多，如果提示词太笼统，模型会自由发挥，最后三个模型做出来的东西根本不是同一个游戏，就没法对比了。
我的提示词框架分四层：第一层是技术栈约束，明确指定Three.js版本和运行环境；第二层是功能清单，逐条列出必须实现的功能点；第三层是交互定义，详细描述每个按键和鼠标操作对应的行为；第四层是验收标准，说明什么情况下算“完成”。
注意：提示词里千万不要写“做一个好玩的3D游戏”这种模糊描述。模型对“好玩”的理解千差万别，有的给你加音效，有的给你加敌人AI，最后你根本没法对比核心能力。需求越具体，对比越公平。
具体到每个功能点，我给的描述是这样的：移动系统——WASD控制前后左右，移动速度恒定，无加速度；视角系统——鼠标移动控制视角旋转，俯仰角限制在正负80度；碰撞系统——玩家不能穿过墙壁，碰撞后沿墙壁滑动而不是完全停止。这些细节直接决定了模型输出的代码质量。
3.2 运行环境搭建的坑
三个模型输出的代码，运行方式不一样，这里踩了不少坑。Step 5 Preview和GLM5.3都需要本地服务器，我用的是最轻量的方案：
# 在项目目录下启动一个静态服务器 npx serve . # 或者用Python自带的 python -m http.server 8080DeepSeek V4 Pro的单文件方案可以直接双击打开，但这里有一个隐藏问题——如果你用了ES6模块语法，浏览器会因为CORS策略拒绝加载。DeepSeek V4 Pro聪明的地方在于它完全没用import，所有代码都是全局作用域，所以双击就能跑。
还有一个坑是Three.js的版本。三个模型默认引用的都是CDN上的最新版，但最新版有时候会有API变动。我实测下来，r128到r150之间的版本最稳定，再新的版本有些几何体API改了，模型生成的代码可能会报错。
<!-- 推荐固定版本，避免API变动导致代码跑不起来 --> <script src="https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js"></script>3.3 实际运行效果对比
Step 5 Preview跑起来的第一印象是“完整”。主菜单、游戏界面、胜利界面都有，状态切换流畅。移动手感偏“重”，因为射线检测每帧都要计算，响应有一点点延迟。小地图在右上角，显示玩家位置和迷宫全貌，但刷新率明显低于主画面。
DeepSeek V4 Pro跑起来的第一印象是“快”。帧率稳定在60，移动响应极其跟手，因为网格碰撞的计算量几乎可以忽略。但画面确实简陋，灰色墙壁灰色地面，玩久了容易视觉疲劳。小地图是Canvas画的，刷新很流畅。
GLM5.3跑起来的第一印象是“舒服”。光照让场景有了立体感，墙壁的明暗变化让空间感更强。但帧率不太稳定，在复杂视角下会掉到40左右，因为双相机渲染的开销确实大。小地图用的是第二相机，跟主画面同步刷新，看起来最自然。
3.4 代码修改和扩展的难易度
如果你拿到代码后想改东西，三个模型的体验完全不同。Step 5 Preview的模块化结构最好改，找到对应的文件改就行，不会影响到其他模块。比如你想把移动速度从5改成10，直接去player.js里改一个常量就完事了。
DeepSeek V4 Pro的单文件方案改起来最痛苦。800行代码里找移动速度的定义，你得用搜索功能。而且它的变量命名不够规范，有些地方用speed，有些地方用moveSpeed，搜索的时候得试好几个关键词。
GLM5.3的三文件方案改起来中规中矩。逻辑代码在game.js里，样式在style.css里，结构在index.html里。分工明确，但game.js也有400多行，找东西需要一点耐心。
实操心得：不管你用哪个模型生成的代码，拿到手第一件事是加注释标记关键参数。把移动速度、鼠标灵敏度、碰撞半径这些常用参数集中放到文件顶部，后面调参会方便很多。
4. 常见问题与排查技巧实录
4.1 黑屏问题排查
黑屏是3D游戏开发中最常见的问题，没有之一。三个模型生成的代码我都遇到过黑屏，原因各不相同。
Step 5 Preview的黑屏是因为模块加载顺序问题。它的main.js依赖scene.js，但HTML里的script标签顺序写反了，导致scene还没定义就被引用了。解决方法是调整script标签顺序，或者改用type="module"让浏览器自动处理依赖。
DeepSeek V4 Pro的黑屏是因为CDN加载失败。它用的CDN地址在某些网络环境下不稳定，Three.js没加载成功，后面的代码全部报错。解决方法很简单，把CDN地址换成国内可访问的镜像，或者直接下载Three.js放到本地。
GLM5.3的黑屏是因为相机位置问题。它把相机初始化在了迷宫墙壁内部，渲染出来的画面全是墙壁的背面，看起来就是一片黑。把相机位置往外移一点就好了。
| 黑屏原因 | 表现 | 解决方法 |
|---|---|---|
| 模块加载顺序错误 | 控制台报ReferenceError | 调整script顺序或改用module |
| CDN加载失败 | 控制台报Three is not defined | 换CDN或本地引用 |
| 相机在物体内部 | 画面全黑但控制台无报错 | 调整相机初始位置 |
| 渲染循环未启动 | 画面全黑且无报错 | 检查requestAnimationFrame调用 |
4.2 穿墙和卡墙问题
穿墙是碰撞检测没做好，卡墙是碰撞检测做过头了。Step 5 Preview的射线检测方案基本不会穿墙，但在墙角处偶尔会卡住，因为射线从两个方向都检测到了墙壁，玩家被夹在中间动不了。
DeepSeek V4 Pro的网格碰撞在正常移动时没问题，但如果帧率突然下降，玩家单帧移动距离过大，可能会直接跳过墙壁所在的网格。这就是所谓的“隧道效应”。解决方法是在移动前做插值，把大位移拆成多个小位移逐步检测。
GLM5.3的球体碰撞在大多数情况下表现良好，但在斜角墙壁处会有轻微的穿透感，因为球体与长方体的相交检测在斜角处不够精确。
避坑技巧：如果你的游戏对碰撞精度要求高，建议用射线检测方案，但要在墙角处加一个“滑动”逻辑——当玩家被卡住时，尝试沿墙壁方向移动，而不是完全停止。
4.3 性能优化实战
3D游戏的性能问题主要集中在两个方面：渲染开销和计算开销。
渲染开销方面，最大的杀手是阴影。GLM5.3开了阴影后，帧率直接掉了15帧。如果你不是特别需要阴影效果，关掉它是最简单的优化手段。另外，迷宫墙壁如果用了独立的Mesh，draw call数量会很高。把墙壁合并成一个Geometry可以大幅降低draw call。
计算开销方面，碰撞检测是主要消耗。Step 5 Preview的射线检测每帧要发射多条射线，在复杂场景下开销不小。优化方法是降低检测频率，不需要每帧都检测，可以每两帧检测一次，中间帧用上一帧的结果。
// 降低碰撞检测频率的简单实现 let frameCount = 0; function update() { frameCount++; if (frameCount % 2 === 0) { checkCollision(); } // 其他更新逻辑 }4.4 常见问题速查表
| 问题现象 | 可能原因 | 排查步骤 | 解决方案 |
|---|---|---|---|
| 画面全黑 | 相机位置/渲染循环/CDN | 看控制台报错 | 逐项检查 |
| 移动无响应 | 事件监听未绑定 | 检查addEventListener | 确认键盘事件绑定 |
| 鼠标视角反转 | 旋转方向计算错误 | 检查rotation赋值 | 调整正负号 |
| 帧率低于30 | 阴影/draw call过多 | 用性能面板分析 | 关阴影/合并几何体 |
| 小地图不刷新 | 渲染循环未包含 | 检查小地图更新调用 | 加入主循环 |
| 胜利条件不触发 | 距离判断阈值错误 | 打印玩家与终点距离 | 调整阈值 |
5. 模型选型建议与实战心得
5.1 什么场景选哪个模型
如果你要快速验证一个3D游戏的想法，不想折腾环境配置，DeepSeek V4 Pro的单文件方案最省事。拿到就能跑，改起来虽然麻烦但至少能跑。适合做原型验证和快速demo。
如果你要做一个需要长期维护的项目，Step 5 Preview的模块化方案最合适。前期搭建稍微麻烦一点，但后期扩展和修改的成本最低。适合正式项目开发。
如果你对视觉效果有要求，又不想自己写光照代码，GLM5.3是首选。它自动加的光照让场景看起来更专业，省去了你调光照的时间。适合做展示型demo。
5.2 我踩过的坑和总结的经验
第一个坑是提示词太笼统。我第一轮测试的时候只写了“做一个3D迷宫游戏”，结果三个模型做出来的东西差异巨大，有的用第一人称，有的用第三人称，有的甚至做了个2D俯视图。根本没法对比。后来我把需求拆成具体的功能点，每个点给明确的验收标准，对比才有意义。
第二个坑是忽略了Three.js版本差异。三个模型引用的CDN版本不一样，有些API在新版本里改了，导致代码跑不起来。后来我统一固定了r128版本，问题就消失了。
第三个坑是性能测试环境不统一。我一开始在台式机上测，三个模型都跑得很流畅，看不出差异。后来换到一台老笔记本上测，差异立刻显现——DeepSeek V4 Pro还能跑50帧，GLM5.3掉到了30帧以下。
实操心得：做模型对比测试，一定要控制变量。环境要统一，提示词要统一，验收标准要统一。否则你测出来的差异可能来自环境而不是模型本身。
5.3 后续扩展方向
这三个模型生成的3D游戏都只是基础版本，后续可以扩展的方向很多。加敌人AI是一个方向，用简单的状态机就能实现巡逻和追击逻辑。加道具系统也不难，在迷宫里放几个可拾取的对象，碰到就触发效果。加关卡系统需要改一下迷宫数据的加载方式，从硬编码改成从JSON文件读取。
如果你想把这个游戏做成一个完整的项目，建议用Step 5 Preview的架构做基础，把GLM5.3的光照方案移植过来，再用DeepSeek V4 Pro的网格碰撞做性能优化。三个模型的优点结合起来，能做出一个相当不错的3D游戏。
最后分享一个小技巧：不管你用哪个模型生成代码，拿到后先跑一遍，把控制台的报错全部解决，再开始改功能。带着报错改代码，你会分不清是新bug还是旧bug。这个习惯能帮你省下大量排查时间。
