1. 三款模型同台竞技：这个3D游戏实测到底测了什么

三个大模型，同一个3D游戏需求，同样的对话轮次，最后跑出来的东西差距有多大？这个问题我琢磨了很久。最近拿到Step 5 Preview、DeepSeek V4 Pro和GLM5.3三个模型的内测权限，我决定用一个完整的3D游戏项目来做一次横向实测，不是跑分那种虚的，而是从零开始，让每个模型独立完成一个可运行的3D小游戏，然后从代码质量、运行效果、开发效率三个维度做对比。

先说清楚这个实测的定位。它适合正在选型AI编程工具的开发者、对3D游戏开发感兴趣但不想从零啃引擎的独立创作者，以及想了解当前主流大模型在复杂代码生成任务上真实水平的技术决策者。我不会只告诉你“哪个模型好”，而是把每个模型在开发过程中暴露出来的问题、绕过的弯路、最终产出的实际效果全部摊开来讲。你看完之后应该能判断：如果明天你要用AI辅助做一个3D游戏，该选谁、该怎么用、会遇到什么坑。

这次实测的游戏需求我刻意控制在一个“中等复杂度”的区间：一个3D场景，玩家可以控制角色移动，场景中有可交互的物体，有简单的碰撞检测，有计分系统，有开始和结束界面。技术栈选择Three.js加原生JavaScript，不依赖任何游戏引擎，这样能最大程度暴露模型在3D数学、场景图管理、渲染循环这些核心环节的真实能力。为什么不用Unity或Godot？因为那些引擎有大量样板代码和可视化编辑器，模型生成的内容会被引擎本身的能力掩盖，测不出真实水平。

三个模型的调用方式统一为API直连，温度参数统一设为0.7，最大输出token统一设为8192，每个模型分配相同的对话轮次预算：最多15轮交互，每轮可以要求模型修改或补充代码。这个约束很重要，因为实际开发中你不会无限次跟模型对话，轮次预算直接反映了模型的“一次做对率”和“纠错效率”。

实测从下午两点开始，到晚上九点结束，中间除了喝水没停过。三个模型并行跑，我同时维护三个对话窗口，每轮交互后立即在浏览器中运行代码，记录报错信息和视觉效果。下面把整个过程拆开来讲，包括每个模型在哪些环节表现出色、在哪些环节翻车、以及我从中总结出的实操经验。

2. 实测环境搭建与三个模型的接入方式

2.1 硬件与软件环境说明

测试机器是一台2023款的笔记本，配置为i7-13700H处理器、32GB内存、RTX 4060显卡（8GB显存），操作系统是Windows 11专业版。浏览器统一使用Chrome 120稳定版，开启硬件加速。为什么强调硬件？因为3D渲染对GPU有实际要求，如果显卡太弱，模型生成的代码即使正确也可能因为帧率过低而无法判断效果。32GB内存是必要的，因为三个模型并行对话加上浏览器多标签页运行，内存占用会飙升到20GB以上。

开发环境方面，我建了三个独立的项目文件夹，分别命名为step5-test、deepseek-test、glm-test，每个文件夹里放一个index.html和一个main.js。没有用构建工具，没有用npm，直接通过<script type="importmap">引入Three.js的CDN版本。这样做的好处是零配置，模型生成的代码可以直接在浏览器打开运行，不需要处理依赖安装、打包配置这些额外环节。坏处是没法用模块热更新，每次修改都要手动刷新页面，但这反而更接近“裸写代码”的真实场景。

提示：如果你要复现这个实测，建议至少准备16GB内存和一块支持WebGL 2.0的独立显卡。集成显卡也能跑，但在复杂场景下帧率会掉到20fps以下，影响对模型生成质量的判断。

2.2 三个模型的接入配置与参数统一

Step 5 Preview通过官方API接入，端点地址是标准的/v1/chat/completions格式，认证用Bearer Token。DeepSeek V4 Pro和GLM5.3同样走各自的API端点。三个模型的系统提示词完全一致，内容如下：

你是一个资深3D游戏开发者，精通Three.js和原生JavaScript。 请根据用户需求生成完整可运行的代码。 代码要求： 1. 使用Three.js r160以上版本 2. 所有代码放在单个HTML文件中，通过importmap引入Three.js 3. 包含完整的场景初始化、渲染循环、用户输入处理 4. 代码必须有详细注释 5. 不要使用任何外部模型文件，所有几何体用Three.js内置的创建

这个系统提示词的设计有讲究。限定Three.js版本是为了避免API差异导致的兼容问题，r160之后outputColorSpace替代了outputEncoding，如果模型混用新旧API会直接报错。要求单HTML文件是为了简化测试流程，不用处理跨文件引用。禁止外部模型文件是因为三个模型都没有多模态能力，没法生成或引用3D模型资源，用内置几何体（BoxGeometry、SphereGeometry等）可以保证每个模型都在同一起跑线上。

温度参数0.7是一个折中值。设太低（如0.2）会导致代码过于保守，缺乏创意；设太高（如1.0）会导致代码结构混乱，变量命名随意。0.7在代码生成任务中通常能兼顾结构合理性和实现多样性。最大输出token设为8192是因为一个完整的3D游戏代码大约在3000到6000token之间，8192留足了余量，避免因截断导致代码不完整。

2.3 统一的功能需求描述

给三个模型的初始需求描述完全一致，内容如下：

请创建一个3D小游戏，具体要求： 1. 场景：一个平面地面，上面随机分布20个彩色立方体 2. 玩家：一个球体，用WASD控制移动，鼠标控制视角旋转 3. 交互：球体碰到立方体时，立方体消失并加分 4. UI：左上角显示分数，屏幕中央有开始按钮，游戏结束后显示最终分数和重新开始按钮 5. 物理：球体不能穿出地面边界，立方体有轻微的上下浮动动画 6. 相机：第三人称跟随相机，平滑跟随球体移动

这个需求描述刻意写得“像人话”，没有用技术术语堆砌。比如“球体碰到立方体时立方体消失”而不是“实现碰撞检测并触发对象销毁”，这样能测试模型对自然语言的理解能力。需求中包含了场景、玩家控制、交互、UI、物理、相机六个模块，覆盖了3D游戏开发的核心环节，任何一个模块出问题都会导致游戏不可玩。

3. 第一轮生成结果对比：谁一次做对的更多

3.1 Step 5 Preview的首轮输出分析

Step 5 Preview在第一轮就生成了约4200token的完整代码，结构非常清晰。它把代码分成了几个逻辑块：场景初始化、玩家创建、立方体生成、输入处理、碰撞检测、UI管理、渲染循环。每个块之间用注释分隔，变量命名规范，比如playerSphere、cubeGroup、scoreDisplay这种一看就懂的名字。

让我意外的是它对相机跟随的处理。Step 5 Preview没有用简单的camera.position.copy(player.position)这种硬跟随，而是实现了一个带阻尼的平滑跟随：

const cameraOffset = new THREE.Vector3(0, 5, 10); const lerpFactor = 0.1; // 在渲染循环中 const targetPosition = player.position.clone().add(cameraOffset); camera.position.lerp(targetPosition, lerpFactor); camera.lookAt(player.position);

这段代码的逻辑是：相机目标位置始终在玩家上方5单位、后方10单位处，然后用lerp以0.1的插值系数平滑移动。效果是相机跟随有轻微的延迟感，不会像硬跟随那样生硬。这个细节说明Step 5 Preview在3D游戏开发方面有“经验性”的理解，不是机械地执行指令。

但首轮输出也有问题。碰撞检测用的是简单的距离判断：

const distance = player.position.distanceTo(cube.position); if (distance < 1.5) { cube.visible = false; score += 10; }

这个逻辑在球体半径0.5、立方体边长1的情况下，1.5的阈值偏大，会导致球体还没碰到立方体就触发消失。正确阈值应该是球体半径加立方体半边长，即0.5+0.5=1.0。这个错误在首轮运行时就暴露了，球体离立方体还有明显距离时立方体就消失了。

3.2 DeepSeek V4 Pro的首轮输出分析

DeepSeek V4 Pro的首轮输出约3800token，代码风格更偏向“教科书式”。它用了大量的类封装，把玩家、立方体、游戏管理器都写成了ES6类。这种结构在大型项目中是好的，但对于一个单文件小游戏来说有点过度设计。比如它定义了一个Player类，里面有constructor、update、handleInput、checkCollision四个方法，但实际上checkCollision的逻辑和update紧密耦合，拆开反而增加了理解成本。

DeepSeek V4 Pro在物理边界处理上做得很好。它用了一个clamp函数来限制球体位置：

function clamp(value, min, max) { return Math.max(min, Math.min(max, value)); } // 在更新位置后 player.position.x = clamp(player.position.x, -boundary, boundary); player.position.z = clamp(player.position.z, -boundary, boundary);

这个逻辑简单有效，球体永远不会跑出地面范围。而且它把边界值设为了一个常量boundary = 25，地面平面大小是50x50，球体活动范围是±25，刚好在地面边缘内。这个计算是合理的。

但DeepSeek V4 Pro的UI实现有问题。它用document.createElement动态创建按钮和分数显示，但CSS样式是内联的，而且用了position: absolute但没有设置z-index。结果在首轮运行时，开始按钮被Three.js的canvas盖住了，点不到。这个问题在第二轮才修复。

3.3 GLM5.3的首轮输出分析

GLM5.3的首轮输出最短，约3100token。代码结构最简洁，没有用类，全是函数式写法。它的场景初始化代码非常紧凑：

const scene = new THREE.Scene(); const camera = new THREE.PerspectiveCamera(75, innerWidth/innerHeight, 0.1, 1000); const renderer = new THREE.WebGLRenderer({ antialias: true }); renderer.setSize(innerWidth, innerHeight); document.body.appendChild(renderer.domElement);

这四行代码完成了场景、相机、渲染器的创建和挂载，没有任何多余操作。这种简洁性在快速原型开发中是优势，但GLM5.3在细节上丢分最多。它没有实现鼠标控制视角旋转，只做了WASD移动。需求里明确写了“鼠标控制视角旋转”，但GLM5.3的代码里完全没有鼠标事件监听。这是一个明显的需求遗漏。

另外，GLM5.3的立方体浮动动画用的是Math.sin(Date.now() * 0.001 + index)，每个立方体的相位偏移用index区分。这个逻辑是对的，但Date.now()在渲染循环中每帧调用，会导致动画速度受帧率影响。正确做法是用clock.getElapsedTime()，Three.js的Clock类会处理帧率补偿。这个细节说明GLM5.3对Three.js的惯用模式不够熟悉。

3.4 首轮对比小结

首轮结果说明一个问题：代码生成量不等于质量。GLM5.3最省token，但功能遗漏最严重。Step 5 Preview在3D游戏特有的细节（相机跟随、碰撞检测）上表现最好，说明它在训练数据中可能包含了更多游戏开发相关的代码。DeepSeek V4 Pro的工程化思维强，但在小项目上容易过度设计。

4. 第二轮迭代：错误修复与功能补全的较量

4.1 给三个模型的修复指令设计

第二轮我给三个模型发送了相同的修复指令，内容如下：

首轮代码运行后发现以下问题，请修复： 1. 碰撞检测阈值需要精确计算，球体半径0.5，立方体边长1，阈值应为1.0 2. 确保UI元素在canvas上方，按钮可点击 3. 补全鼠标控制视角旋转功能 4. 立方体浮动动画改用clock.getElapsedTime()实现 5. 修复后请输出完整代码，不要只输出修改部分

这个指令的设计原则是“具体到可执行”。我没有说“碰撞检测有问题”，而是给出了精确的阈值计算公式。这样做是为了测试模型的“指令遵循精度”——当需求足够明确时，模型能否准确执行。同时要求输出完整代码，是为了避免模型只给diff导致我手动合并出错。

4.2 Step 5 Preview的第二轮表现

Step 5 Preview在第二轮准确修复了所有五个问题。碰撞阈值改为了精确的1.0，并且加了一个注释说明计算依据。UI问题通过给canvas设置z-index: 0、给UI容器设置z-index: 10解决。鼠标控制用了PointerLockControls，这是Three.js官方提供的鼠标锁定控制器，实现视角旋转的标准方案。

但Step 5 Preview在引入PointerLockControls时犯了一个小错误。它从three/addons/controls/PointerLockControls.js导入，但importmap中只映射了three和three/addons/，没有单独映射three/addons/controls/。这导致浏览器报404错误。修复方法是在importmap中添加：

{ "imports": { "three": "https://unpkg.com/three@0.160.0/build/three.module.js", "three/addons/": "https://unpkg.com/three@0.160.0/examples/jsm/" } }

这个错误说明Step 5 Preview对importmap的路径解析规则理解不够精确。three/addons/映射到examples/jsm/后，three/addons/controls/PointerLockControls.js应该解析为examples/jsm/controls/PointerLockControls.js，这是正确的。但Step 5 Preview在代码中写的是three/addons/controls/PointerLockControls.js，而importmap中映射的是three/addons/，理论上应该能解析。实际报错的原因是CDN上examples/jsm/controls/PointerLockControls.js文件存在，但内部又引用了three模块，而three模块的映射是正确的。最终排查发现是CDN的CORS问题，换用cdn.jsdelivr.net后解决。

4.3 DeepSeek V4 Pro的第二轮表现

DeepSeek V4 Pro在第二轮修复了UI遮挡问题，方法是用position: fixed替代position: absolute，并显式设置z-index: 100。鼠标控制它没有用PointerLockControls，而是自己实现了一套基于mousemove事件的视角旋转：

let isMouseDown = false; let previousMouseX = 0; document.addEventListener('mousedown', () => { isMouseDown = true; }); document.addEventListener('mouseup', () => { isMouseDown = false; }); document.addEventListener('mousemove', (e) => { if (!isMouseDown) return; const deltaX = e.clientX - previousMouseX; camera.rotation.y -= deltaX * 0.005; previousMouseX = e.clientX; });

这套逻辑是“按住鼠标拖动旋转视角”，和PointerLockControls的“鼠标锁定后自由旋转”是两种不同的交互模式。需求里写的是“鼠标控制视角旋转”，没有指定具体模式，所以两种都算满足。但DeepSeek V4 Pro的实现有一个bug：previousMouseX在mousedown时没有重置，导致第一次拖动时视角会跳变。这个bug在第三轮才修复。

DeepSeek V4 Pro在碰撞检测上做了一个优化。它没有用简单的距离判断，而是用了Box3的intersectsSphere方法：

const cubeBox = new THREE.Box3().setFromObject(cube); const playerSphere = new THREE.Sphere(player.position, 0.5); if (cubeBox.intersectsSphere(playerSphere)) { cube.visible = false; score += 10; }

这个方案比距离判断更精确，因为它考虑了立方体的实际边界和球体的实际半径。但性能开销更大，每帧对20个立方体都要创建Box3和Sphere对象。在20个立方体的场景中影响不大，但如果立方体数量增加到200个，帧率会明显下降。这是一个“正确但不够高效”的方案。

4.4 GLM5.3的第二轮表现

GLM5.3在第二轮补全了鼠标控制，但实现方式比较粗糙。它用了camera.rotation.y -= e.movementX * 0.002，直接修改相机的Y轴旋转。这会导致一个问题：当相机旋转超过±90度时，视角会翻转。正确的做法是用camera.rotation.order = 'YXZ'，先设置旋转顺序，再修改rotation.y和rotation.x。GLM5.3没有设置旋转顺序，导致上下视角旋转时出现万向节死锁。

碰撞阈值GLM5.3改对了，但浮动动画的修改不彻底。它把Date.now()换成了clock.getElapsedTime()，但clock变量是在渲染循环内部创建的，每帧都新建一个Clock对象，导致getElapsedTime()始终返回0。正确做法是把clock定义在渲染循环外部：

const clock = new THREE.Clock(); function animate() { const elapsed = clock.getElapsedTime(); // 使用elapsed }

这个错误说明GLM5.3对“变量作用域”的理解有偏差。它知道要用clock，但不知道clock应该在哪里创建。

4.5 第二轮迭代的教训

第二轮暴露的核心问题是：模型能理解“要做什么”，但对“为什么这样做”和“这样做会有什么副作用”缺乏预判。Step 5 Preview的CDN问题、DeepSeek V4 Pro的鼠标跳变、GLM5.3的万向节死锁，都是“知道正确方案但实现细节出错”的典型表现。

从实操角度，我的建议是：不要指望模型一次生成完美代码，但可以通过精确的修复指令让它在第二轮达到可用状态。修复指令要满足三个条件：问题描述具体、修复方案明确、输出格式统一。满足这三个条件后，三个模型在第二轮都能产出可运行的游戏，但代码质量和细节处理仍有差距。

5. 最终运行效果与性能数据对比

5.1 三个版本的视觉与交互体验

经过三轮迭代（第三轮主要是微调），三个模型最终都产出了可玩的3D游戏。但玩起来的感受差异明显。

Step 5 Preview版本的操作最跟手。球体移动的加速度和阻尼调得恰到好处，按WASD时球体不会瞬间达到最大速度，而是有一个短暂的加速过程，松开按键后也会滑行一小段距离。这个手感是三个版本中最好的。相机跟随的平滑度也最高，快速转向时相机不会抖动。立方体浮动动画的节奏感很好，每个立方体的浮动相位差让场景看起来有生气。

DeepSeek V4 Pro版本的操作偏“硬”。球体移动是瞬时响应，按WASD立刻达到最大速度，松开立刻停止。这种手感在精确操作时更有利，但玩起来不够自然。相机跟随用了lerp但插值系数设为了0.3，跟随速度太快，几乎等于硬跟随。立方体浮动动画的幅度偏大，有些立方体浮动到了球体跳跃高度的上方，导致碰撞检测偶尔失效。

GLM5.3版本的操作有延迟感。球体移动用了velocity累加，但阻尼系数设得太小，导致球体松开按键后还会滑行很远，很难精确停在某个位置。相机旋转的万向节死锁问题在第三轮修复了，但修复方式是限制rotation.x在±80度范围内，牺牲了上下视角的完整性。立方体浮动动画正常，但碰撞检测偶尔会漏判，球体穿过立方体但没有触发消失。

5.2 帧率与性能数据

在相同硬件环境下，用Chrome的Performance面板记录了三个版本运行30秒的平均帧率：

GLM5.3帧率最高是因为它的场景最简单，没有实现相机平滑跟随和精确碰撞检测，每帧的计算量最小。Step 5 Preview的帧率略低是因为相机平滑跟随和碰撞检测的计算开销，但58fps已经足够流畅。DeepSeek V4 Pro的内存占用最高，因为它每帧创建Box3和Sphere对象，垃圾回收压力大。

Draw Call数量方面，三个版本都在22到26之间，差异不大。这是因为场景中的立方体都是独立的Mesh，没有做合批优化。如果要做性能优化，可以用InstancedMesh把所有立方体合并成一个Draw Call，但三个模型都没有主动做这个优化。

5.3 代码质量的主观评分

我从可读性、可维护性、健壮性三个维度给三个版本打了分（满分10分）：

Step 5 Preview的可读性最高，变量命名清晰，注释到位，逻辑分块合理。DeepSeek V4 Pro的可维护性不错，类封装虽然冗余但结构清晰，后续扩展功能时容易找到修改点。GLM5.3的健壮性最差，边界情况处理不足，比如球体移动到地面边缘时没有做限制，会掉出地面。

6. 实操心得与模型选型建议

6.1 三个模型各自的适用场景

Step 5 Preview适合“从零到一”的快速原型开发。它在首轮就能生成结构完整、细节到位的代码，尤其在3D数学和游戏逻辑方面表现突出。如果你要做一个3D游戏Demo或者交互式3D展示，Step 5 Preview是首选。它的相机控制和碰撞检测实现可以直接抄作业，省去了大量调试时间。

DeepSeek V4 Pro适合“工程化”的项目开发。它的类封装和模块化思维在大型项目中是优势，但在小项目上显得笨重。如果你要做一个需要长期维护、多人协作的3D应用，DeepSeek V4 Pro的代码结构更容易扩展。它的Box3碰撞检测方案虽然性能开销大，但精确度最高，适合对碰撞精度要求高的场景。

GLM5.3适合“快速验证”场景。它的代码最简洁，生成速度最快，token消耗最低。如果你只是想快速验证一个3D交互的想法，不需要精细的操作手感和完整的边界处理，GLM5.3可以在最短时间内给你一个可运行的版本。但后续要投入生产，需要大量手动修补。

6.2 用AI做3D游戏的实操技巧

第一，系统提示词里一定要限定Three.js版本和引入方式。我试过不限定版本，模型会混用r150和r160的API，outputEncoding和outputColorSpace混用直接报错。限定版本后这个问题完全消失。

第二，碰撞检测的阈值一定要在需求里写清楚。不要指望模型自己计算“球体半径加立方体半边长”，直接把数值写进需求里。我试过让模型自己算，三个模型算出来的阈值都不一样，有两个是错的。

第三，UI元素的层级问题要在需求里提前说明。Three.js的canvas默认是position: static，UI元素如果用position: absolute但不设z-index，会被canvas盖住。直接在需求里写“UI元素z-index设为100”可以避免一轮修复。

第四，鼠标控制视角的方案要指定。PointerLockControls和自定义mousemove是两种完全不同的交互模式，不指定的话模型会随机选，选到不合适的方案后修复成本很高。

第五，浮动动画一定要用clock.getElapsedTime()。Date.now()在渲染循环中会导致动画速度受帧率影响，高帧率设备上动画飞快，低帧率设备上动画慢如蜗牛。这个坑我踩过三次，每次都要手动改。

6.3 常见问题速查表

6.4 关于WorkBuddy在开发流程中的辅助作用

这次实测中我还试了用WorkBuddy来管理三个模型的对话记录和代码版本。WorkBuddy的工作台模式可以把三个模型的输出分别放在不同的面板里，方便对比。它的跨对话记忆功能让我可以在一个对话里引用另一个对话的代码片段，比如把Step 5 Preview的相机代码复制到DeepSeek V4 Pro的对话里让它参考。这个功能在横向对比时特别有用。

WorkBuddy的自定义指令功能也帮了大忙。我给它定了几条规则：“所有代码输出必须包含完整HTML结构”、“修复代码时必须输出完整文件”、“每次修改后标注修改点”。这些规则设置一次后对所有对话生效，省去了每次重复说明的麻烦。如果你经常做多模型对比测试，建议花十分钟把常用规则配置好，后续效率提升很明显。

不过WorkBuddy的系统缓存目录默认在C盘，如果你的C盘空间紧张，可以在设置里改到D盘。具体路径在“设置-高级-缓存管理”里，改完后重启WorkBuddy生效。这个细节官方文档里没写，我是试出来的。

7. 从这次实测中提炼的模型能力边界

三个模型在3D游戏开发这个任务上展现出的能力差异，本质上反映了它们在训练数据、架构设计和优化目标上的不同。Step 5 Preview在空间推理和游戏逻辑方面明显更强，它生成的相机跟随代码和碰撞检测代码都体现了对3D空间关系的准确理解。DeepSeek V4 Pro在工程结构方面更成熟，但缺乏对3D游戏特有模式的敏感度。GLM5.3在代码生成速度和简洁性上有优势，但在需要精确计算的环节容易出错。

一个有意思的观察是：三个模型都没有主动做性能优化。没有模型提出用InstancedMesh合并立方体，没有模型用对象池复用Box3和Sphere，没有模型做视锥体剔除。这说明当前的大模型在代码生成时更关注“功能正确”而非“性能最优”。如果你对性能有要求，需要在需求里明确写出来，比如“用InstancedMesh渲染所有立方体”、“碰撞检测对象要复用”。

另一个观察是：模型对“手感”这类主观体验的理解很有限。Step 5 Preview的移动手感最好，但它的加速度和阻尼参数也是猜的，不是算出来的。如果你对操作手感有精确要求，需要手动调参，不能指望模型一次给对。

这次实测让我对“用AI做3D游戏”这件事有了更实际的预期。AI可以帮你跳过大量样板代码和API查阅，但在3D数学、性能优化、交互手感这些需要经验积累的环节，仍然需要人工介入。把AI当作一个“能快速写出可运行代码的初级开发者”来用，而不是“能替代资深开发者的全能工具”，心态会好很多，产出也会更稳定。