1. 三款模型同台竞技：这个对比测试到底在测什么
三个模型，同一个3D游戏项目，同样的提示词，最后跑出来的东西能差多少？这个问题我在过去两周里反复验证了好几轮，结论比我预想的要有意思得多。
先把这个测试的基本盘交代清楚。Step 5 Preview、DeepSeek V4 Pro、GLM5.3，这三个都是当前代码生成领域讨论度很高的模型。我选择用3D游戏作为测试载体，原因很直接：3D游戏开发是一个典型的“全栈压力测试”场景，它同时涉及数学计算（向量、矩阵、四元数）、图形学基础（光照、材质、相机）、状态管理（游戏循环、输入处理）、资源组织（模型加载、纹理管理）以及交互逻辑（碰撞检测、动画系统）。一个模型如果只能写CRUD或者简单的算法题，放到3D游戏这个场景里会立刻露馅。
具体测试项目我定为“一个可交互的3D迷宫探索游戏”，技术栈选择Three.js + 原生JavaScript，不依赖任何游戏引擎。这个选择本身就有讲究：用Unity或Godot的话，大量工作被引擎封装了，模型只需要写业务逻辑脚本，测不出底层能力；用纯Three.js则要求模型自己处理场景图构建、相机控制、光照设置、碰撞检测等所有环节，更能拉开差距。
测试任务拆解为五个递进阶段：第一阶段生成基础场景（地面、墙壁、光照、相机）；第二阶段加入第一人称控制器（WASD移动 + 鼠标视角）；第三阶段实现碰撞检测（不能穿墙）；第四阶段加入收集品和计分系统；第五阶段做视觉打磨（阴影、雾效、材质优化）。每个阶段用相同的提示词分别喂给三个模型，记录生成代码的质量、可运行性和完成度。
注意：这种对比测试最忌讳“一次性把需求全丢进去”。分阶段测试才能看出模型在增量开发中的上下文保持能力，这恰恰是实际项目中最常用的工作模式。
为什么要关注这个测试？因为现在市面上关于代码模型的评测大多集中在LeetCode风格算法题或者简单的Web页面生成上，这些任务有标准答案，模型很容易“背题”。但3D游戏开发没有标准答案，同一个需求有无数种实现路径，模型必须真正理解空间几何、渲染管线和交互逻辑之间的关系，才能写出能跑的代码。这就好比让三个人分别造一辆能骑的自行车，比让他们做同一道数学题更能看出真实水平。
另外补充一点，这次测试全程使用了WorkBuddy作为开发工作台来管理三个模型的对话和代码版本。WorkBuddy在这个场景里的价值在于它可以为每个模型维护独立的对话上下文，同时用统一的文件系统管理生成产物，方便我做横向对比。如果你还没用过WorkBuddy，可以把它理解为一个“多模型协作开发环境”，它本身不生成代码，但提供了对话管理、文件操作、指令定制等能力，让你在一个界面里同时跟多个模型协作。
2. 三个模型的首轮表现：基础场景搭建能力对比
2.1 测试方法与提示词设计
首轮测试的提示词我刻意写得比较简洁，模拟真实开发中“有个大概想法就开干”的场景：
用Three.js创建一个3D迷宫场景，要求： - 地面使用纹理贴图 - 墙壁用BoxGeometry生成，围成一个10x10的迷宫 - 添加环境光和方向光 - 相机位于迷宫入口处，朝向迷宫内部 - 页面全屏显示，带基本响应式处理这段提示词的关键在于“留白”。我没有指定迷宫的具体布局算法、没有规定纹理来源、没有说明光照参数，这些空白正是拉开模型差距的地方。好的模型会做出合理的默认选择并解释原因，差的模型会生成一堆占位符然后告诉你“请自行替换”。
2.2 Step 5 Preview 的生成结果
Step 5 Preview 给我的第一印象是“工程化思维很强”。它没有直接开始写代码，而是先输出了一段简短的技术方案说明：建议使用递归回溯算法生成迷宫布局，纹理使用Canvas动态生成以避免外部资源依赖，光照采用半球光+方向光组合来兼顾性能和视觉效果。
代码层面，Step 5 Preview 的产出结构非常清晰。它把迷宫生成逻辑单独封装成了一个MazeGenerator类，墙壁的创建用了InstancedMesh来优化性能——这一点让我比较意外，因为10x10的迷宫其实用普通Mesh也完全跑得动，但它主动考虑了“如果迷宫规模扩大”的扩展性。相机控制部分它用了Three.js自带的PointerLockControls，这是标准做法，没什么好说的。
不过Step 5 Preview 有一个小问题：它生成的纹理代码用了CanvasTexture，但Canvas的绘制逻辑写得太简单，就是纯色填充加了一些噪点，视觉效果比较朴素。另外它在响应式处理上只监听了resize事件更新相机宽高比，没有处理移动端的触摸控制。
2.3 DeepSeek V4 Pro 的生成结果
DeepSeek V4 Pro 的风格截然不同。它一上来就生成了一份非常详细的代码注释文档，几乎每个函数上面都有JSDoc风格的说明。代码组织上，它没有用类，而是用了一系列工厂函数来创建场景元素，这种风格更偏函数式。
迷宫生成方面，DeepSeek V4 Pro 用的是“预定义布局+随机旋转”的方案——它硬编码了几个迷宫模板，然后随机选取并旋转。这个方案的好处是保证迷宫一定连通（不会出现死胡同封死的情况），坏处是多样性有限。墙壁创建它用了普通的Mesh循环，没有做性能优化。
光照部分 DeepSeek V4 Pro 做得比较细致，它设置了方向光的阴影参数（shadow map size、camera frustum等），还加了简单的环境光遮蔽效果。纹理方面它直接用了Three.js示例中常见的砖墙纹理URL，这意味着如果网络不通或者该资源失效，场景会显示为纯白。
2.4 GLM5.3 的生成结果
GLM5.3 的产出走的是“最小可用”路线。代码量是三个模型中最少的，迷宫生成用了最简单的递归分割算法，墙壁就是一个个独立的BoxGeometry，没有任何优化。光照只有环境光和一个方向光，没有阴影。相机控制用了自己手写的鼠标事件监听，没有用PointerLockControls。
但GLM5.3有一个明显的优势：它的代码一次就跑通了，没有任何报错。Step 5 Preview 的InstancedMesh用法有一个小bug（矩阵更新顺序问题），DeepSeek V4 Pro 的纹理加载在没有网络的环境下会报CORS错误，而GLM5.3的代码虽然简陋，但“开箱即用”的完成度最高。
2.5 首轮对比小结
| 维度 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 代码组织 | 类封装，结构清晰 | 工厂函数，注释详尽 | 过程式，简洁直接 |
| 迷宫算法 | 递归回溯，可扩展 | 模板+旋转，保证连通 | 递归分割，最简实现 |
| 性能优化 | InstancedMesh | 无特殊优化 | 无特殊优化 |
| 光照质量 | 中等 | 较高（含阴影） | 基础 |
| 纹理处理 | Canvas动态生成 | 外部URL加载 | 纯色材质 |
| 一次跑通 | 有小bug | 网络依赖问题 | 完全跑通 |
| 代码量 | 约280行 | 约350行 | 约180行 |
实操心得：第一轮测试最容易被忽略的指标是“代码可运行性”。很多评测只看代码是否“看起来专业”，但实际开发中，一个能跑但简陋的版本远比一个精致但报错的版本有价值。GLM5.3在这一轮的表现提醒我，不要被代码的“卖相”迷惑。
3. 增量开发阶段：上下文保持与需求理解深度
3.1 第二轮测试：加入第一人称控制器
第二轮提示词是在第一轮代码基础上追加需求：
在现有场景基础上，添加第一人称控制器： - WASD控制前后左右移动 - 鼠标移动控制视角旋转 - 移动速度恒定，不需要加速度 - 按Shift可以加速跑 - 限制玩家不能穿墙这里的关键测试点是“不能穿墙”。这个需求涉及碰撞检测，而碰撞检测在3D空间中有多种实现方式：AABB包围盒、球体检测、射线检测等。模型选择哪种方案，直接反映了它对3D空间问题的理解深度。
Step 5 Preview 选择了射线检测方案。它在每一帧中从相机位置向移动方向发射射线，如果射线与墙壁相交且距离小于移动步长，就阻止移动。这个方案精确度高，但在墙角处容易出现“卡住”的问题——因为射线只检测一个方向，斜向移动时可能被误判。不过Step 5 Preview 在代码中加了一个“滑动”逻辑：如果前方被阻挡，尝试沿墙壁方向滑动。这个细节说明它确实“理解”了第一人称移动的常见问题。
DeepSeek V4 Pro 用的是AABB包围盒方案。它为玩家维护一个碰撞盒，每帧检测与所有墙壁的包围盒是否相交。这个方案实现简单，但精度较低——玩家可能会在视觉上“嵌入”墙壁一小段距离才被阻止。DeepSeek V4 Pro 也意识到了这个问题，它在注释中写道“如需更高精度可改用胶囊体碰撞”，但没有实际实现。
GLM5.3 的碰撞检测最粗糙：它只检测玩家位置是否在墙壁的网格坐标范围内，相当于把连续空间离散化了。这个方案在网格对齐的迷宫中勉强能用，但移动手感很“顿”，因为玩家位置被强制吸附到网格上。
3.2 第三轮测试：收集品与计分系统
第三轮需求：
在迷宫中随机放置10个收集品（发光的小球），玩家靠近时自动收集， 收集后小球消失并播放一个简单的缩放动画，屏幕上显示计分。 全部收集后显示“通关”提示。这一轮主要测试模型对“游戏状态管理”的理解。收集品系统涉及状态存储（哪些已被收集）、碰撞检测（玩家与收集品的距离判断）、动画系统（收集时的缩放效果）和UI更新（计分显示）。
Step 5 Preview 在这一轮的表现最好。它把收集品逻辑封装成了一个CollectibleManager，内部维护了一个collected集合来记录已收集的物品ID。动画方面它用了Three.js的AnimationMixer，虽然对于简单的缩放动画来说有点“杀鸡用牛刀”，但确实能跑。UI更新它用了自定义事件，在收集时触发collectible:collected事件，UI层监听该事件更新计分。这种解耦设计在后续扩展时非常方便。
DeepSeek V4 Pro 的实现比较直接：用一个数组存储所有收集品，每帧遍历检测距离，收集后直接从场景中移除并更新一个全局变量。简单有效，但收集动画只是简单地设置visible = false，没有过渡效果。UI更新直接操作DOM元素。
GLM5.3 在这一轮出现了明显的上下文丢失。它生成的代码中，收集品的位置是硬编码的，而不是随机生成的——尽管提示词明确说了“随机放置”。另外它没有实现“全部收集后显示通关提示”的逻辑，只做到了计分显示。这说明GLM5.3在长对话中的指令跟随能力有所下降。
3.3 上下文保持能力对比
为了更直观地展示三个模型在增量开发中的表现，我整理了一个对比表：
| 能力维度 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 需求完整实现 | 全部实现 | 全部实现 | 遗漏2项 |
| 与上轮代码兼容 | 完全兼容 | 完全兼容 | 部分冲突 |
| 架构一致性 | 保持类封装风格 | 保持函数式风格 | 风格漂移 |
| 边界情况处理 | 主动处理墙角滑动 | 注释提及但未实现 | 未处理 |
| 代码可维护性 | 高（事件解耦） | 中（全局变量） | 低（硬编码） |
Step 5 Preview 在三轮增量开发中始终保持了一致的架构风格，每一轮新增的功能都能和之前的代码自然融合。DeepSeek V4 Pro 的代码质量稳定，但在架构层面没有太多主动设计。GLM5.3 在前两轮表现尚可，到第三轮开始出现明显的指令遗漏和风格不一致。
注意：增量开发中的“上下文保持”不只是记住之前的代码，更重要的是记住之前的架构决策和代码风格。如果一个模型第一轮用了类封装，第三轮突然变成全局函数，后续维护会非常痛苦。
4. 视觉打磨与性能优化：细节处的功力差距
4.1 第四轮测试：阴影、雾效与材质升级
最后一轮提示词要求做视觉打磨：
优化场景视觉效果： - 开启方向光阴影，墙壁和地面接收阴影 - 添加雾效，远处逐渐隐没 - 墙壁材质改为带法线贴图的砖墙效果 - 收集品小球添加自发光和光晕效果 - 整体色调偏暖这一轮是“加分项”测试，因为即使不做这些优化，游戏也能跑。但正是这些细节，最能看出模型对Three.js渲染管线的熟悉程度。
Step 5 Preview 的阴影配置很规范：它设置了shadow.mapSize为2048x2048，调整了shadow.camera的near/far和left/right/top/bottom来精确覆盖迷宫范围，还开启了shadow.bias来消除阴影条纹（shadow acne）。这些参数不是随便填的，需要理解阴影贴图的工作原理才能设置合理。雾效它用了FogExp2（指数雾）而不是线性雾，理由是“指数雾在室内场景中过渡更自然”。材质方面它用MeshStandardMaterial配合程序化生成的法线贴图（用Canvas绘制噪声再转为法线），虽然效果不如专业法线贴图，但胜在零外部依赖。
DeepSeek V4 Pro 的阴影配置比较基础，只设置了castShadow和receiveShadow，没有调整阴影相机参数，导致阴影边缘有锯齿。雾效用了线性雾，参数是拍脑袋填的（near=10, far=50），实际效果一般。材质它加载了外部法线贴图URL，同样有网络依赖问题。光晕效果它用了Sprite加径向渐变纹理，实现方式正确但纹理分辨率太低，看起来有马赛克。
GLM5.3 在这一轮基本“摆烂”了。它只开启了阴影但没有调整任何参数，雾效加了一行scene.fog = new THREE.Fog(0xcccccc, 10, 100)，材质没有变化，光晕效果直接没做。代码注释里写着“可根据需要调整”，把工作留给了开发者。
4.2 性能实测数据
我在同一台机器（MacBook Pro M1, 16GB RAM）上用Chrome DevTools的Performance面板记录了三个版本在迷宫中的平均帧率：
| 指标 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 平均FPS | 58 | 52 | 60 |
| 帧率波动 | ±3 | ±8 | ±2 |
| Draw Call数 | 45 | 120 | 210 |
| 三角形数 | 12K | 18K | 24K |
| 内存占用 | 85MB | 110MB | 95MB |
Step 5 Preview 的InstancedMesh优化在这里体现了价值：Draw Call只有45，远低于其他两个模型。DeepSeek V4 Pro 因为每个墙壁是独立Mesh，Draw Call偏高。GLM5.3 虽然帧率最高（因为场景最简单），但Draw Call高达210，如果迷宫规模扩大，性能会急剧下降。
4.3 视觉质量主观评分
我邀请了三位有Three.js开发经验的朋友做盲评（不知道哪个版本是哪个模型生成的），从1-10分打分：
| 评分维度 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 光影真实感 | 8.2 | 7.5 | 5.0 |
| 材质细节 | 7.8 | 7.0 | 4.5 |
| 氛围营造 | 8.5 | 7.2 | 5.5 |
| 整体完成度 | 8.0 | 7.3 | 5.2 |
Step 5 Preview 在视觉打磨上的优势比较明显，尤其是在氛围营造上——它的暖色调雾效配合自发光收集品，确实有一种“探索神秘迷宫”的感觉。DeepSeek V4 Pro 中规中矩，该有的都有但不够精致。GLM5.3 的视觉表现基本停留在“能看”的水平。
5. 常见问题与排查技巧实录
5.1 三个模型共性问题汇总
在实际测试过程中，我遇到了一些跨模型的共性问题，这里整理成速查表：
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 场景全黑 | 相机位置在物体内部或光照未生效 | 检查相机position和lookAt | 调整相机位置，确认光照强度>0 |
| 墙壁不可见 | 材质面朝向错误 | 检查material.side设置 | 设为THREE.DoubleSide |
| 移动卡顿 | 碰撞检测每帧遍历所有物体 | 用console.time测量碰撞检测耗时 | 引入空间分割或简化碰撞体 |
| 阴影闪烁 | shadow bias设置不当 | 调整bias值观察变化 | 设置bias为-0.0001到-0.001 |
| 纹理模糊 | 纹理过滤或分辨率问题 | 检查texture.minFilter | 设置 anisotropy 和 mipmap |
| 收集品无法触发 | 距离判断阈值太小 | 打印玩家与收集品距离 | 增大触发半径或改用包围盒检测 |
5.2 模型特有的“坑”
Step 5 Preview 的InstancedMesh有一个隐蔽问题：它在更新实例矩阵时没有调用instanceMatrix.needsUpdate = true，导致在某些Three.js版本中矩阵更新不生效。这个bug不会报错，只是墙壁位置不对。排查方法是检查InstancedMesh的矩阵更新标志。
DeepSeek V4 Pro 的纹理加载用了外部URL，在本地开发时如果没开本地服务器（直接file://打开），会因为CORS策略加载失败。它没有做加载失败的fallback处理，导致场景中墙壁显示为默认白色。解决方法是添加onError回调设置备用材质。
GLM5.3 的鼠标控制代码用了movementX和movementY，但没有做浏览器兼容性处理。在部分浏览器中这两个属性可能为undefined，导致视角无法旋转。需要添加event.movementX || 0的兜底。
5.3 实操避坑建议
提示：用AI生成3D游戏代码时，永远先在一个最小场景中验证核心功能（比如先只放一个立方体和一个光源），确认渲染管线通了再逐步添加复杂度。一次性生成完整场景然后调试，效率会低很多。
另外分享一个我在WorkBuddy中管理多模型对话的技巧：为每个模型创建一个独立的“项目空间”，在空间内维护一个CONTEXT.md文件记录当前项目的架构决策和已完成功能。每次新对话开始时，先把CONTEXT.md的内容作为系统指令注入，这样即使模型本身没有跨对话记忆，也能通过外部文件保持上下文一致性。WorkBuddy的自定义指令功能可以把这个流程自动化——设置一条规则“每次对话开始时读取项目目录下的CONTEXT.md”，后续所有任务都会自动生效。
6. 三模型能力画像与选型建议
6.1 各自的能力画像
经过完整的五轮测试，三个模型的能力画像已经比较清晰了。
Step 5 Preview 是“架构型选手”。它的优势在于工程化思维——主动做性能优化、主动处理边界情况、主动解耦模块。生成的代码结构清晰，后续扩展和维护成本低。缺点是偶尔会在细节上“想太多”，比如用AnimationMixer做简单缩放动画，增加了不必要的复杂度。它适合需要长期维护、功能会持续迭代的项目。
DeepSeek V4 Pro 是“稳健型选手”。它的代码质量稳定，注释详尽，该实现的功能都能实现，但很少主动做超出需求的设计。它的风格偏向“把需求翻译成代码”，而不是“理解需求背后的意图”。适合需求明确、不需要太多架构设计的场景。
GLM5.3 是“快速原型型选手”。它的代码最简洁，生成速度最快，在简单场景下能快速跑通。但随着需求复杂度增加，它的指令跟随能力和上下文保持能力会下降。适合做概念验证或者一次性demo，不适合长期项目。
6.2 选型决策表
| 使用场景 | 推荐模型 | 理由 |
|---|---|---|
| 快速验证想法 | GLM5.3 | 生成快，代码简单，改起来方便 |
| 中小型项目开发 | DeepSeek V4 Pro | 稳定可靠，注释清晰，协作友好 |
| 复杂系统架构 | Step 5 Preview | 架构设计能力强，扩展性好 |
| 学习Three.js | DeepSeek V4 Pro | 注释详细，适合理解代码逻辑 |
| 性能敏感场景 | Step 5 Preview | 主动做性能优化 |
| 多轮增量开发 | Step 5 Preview | 上下文保持最好 |
6.3 组合使用策略
实际开发中不一定只用一个模型。我目前的习惯是：用GLM5.3快速生成原型验证可行性，确认方向后用Step 5 Preview重构架构，中间遇到具体问题用DeepSeek V4 Pro查漏补缺。在WorkBuddy中切换模型只需要新建一个对话，项目文件是共享的，所以这种“接力开发”模式操作起来很顺畅。
最后分享一个我在这次测试中总结的小技巧：给模型写3D游戏提示词时，把“空间关系”描述清楚比把“功能列表”列全更重要。比如“相机在迷宫入口，面朝迷宫中心”比“添加一个相机”有用得多，因为3D开发中最容易出错的就是空间位置和朝向。你可以试试在提示词里加上“用坐标描述每个物体的位置和朝向”，生成代码的准确率会明显提升。
