1. 三个模型同台做3D游戏，我为什么选这个题
最近圈子里讨论度最高的一件事，就是几个主流代码大模型在同一类任务上的横向对比。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字频繁出现在各种实测帖里，但大多数对比都停留在"写个贪吃蛇""做个待办清单"这种二维层面。二维任务有个问题：逻辑分支有限，UI 布局套路化，模型之间的差距很容易被"能跑就行"掩盖过去。
3D 游戏不一样。它同时压测模型的空间数学能力、渲染管线理解、状态管理、资源组织、性能取舍，甚至包括对物理引擎 API 的准确记忆。一个向量叉乘写反了，整个相机就是黑的；四元数顺序搞错了，角色会像陀螺一样乱转。这些错误在二维任务里根本不会暴露。
所以我把同一个需求——"做一个可玩的 3D 小游戏"——分别丢给这三个模型，记录它们从零到可运行的全过程。这篇文章不是跑分榜，而是把每个模型在真实工程场景下的表现、踩到的坑、以及我作为使用者需要补位的部分，完整摊开讲。如果你正在纠结用哪个模型做图形类项目，或者想了解 3D 游戏开发里哪些环节最容易被模型搞砸，这篇应该能帮你省下不少试错时间。
需要先说明：三个模型我用的都是各自较新的版本，提示词尽量保持一致，测试环境统一在一台普通开发机上，浏览器用 Chromium 内核。所有代码最终都跑在 Web 端，技术栈锁定 Three.js，因为它是目前生态最成熟、模型训练语料最丰富的 Web 3D 库，对三个模型来说起跑线相对公平。
2. 测试任务的设计：为什么是"3D 收集类小游戏"
2.1 任务规格的刻意约束
我没有让模型自由发挥，而是给了一个明确到近乎苛刻的规格。原因很简单：开放式需求下，模型会各自选择不同的技术路线，最后根本没法比。约束条件如下：
- 场景：一个封闭的方形平台，四周有围栏，防止角色掉出去
- 角色：一个胶囊体，WASD 控制移动，空格跳跃，鼠标拖拽旋转视角
- 目标物：随机生成 10 个旋转的金色方块，碰到即收集，计数加一
- 反馈：收集全部后屏幕中央显示"完成"，并给出用时
- 相机：第三人称跟随，带平滑插值
- 物理：需要重力、地面碰撞、跳跃落地检测
这个规格覆盖了 3D 游戏的核心闭环：输入、相机、物理、碰撞、状态、UI。任何一个环节出问题，游戏都玩不起来。
2.2 为什么锁定 Three.js 而不是原生 WebGL
有人会问，为什么不直接测原生 WebGL 或者更底层的方案。我的判断是：原生 WebGL 的样板代码太多，模型很容易在着色器编译、缓冲区绑定这些地方翻车，最后测出来的差异其实是"谁更会抄模板"，而不是"谁更懂 3D"。Three.js 把渲染管线封装好了，模型只需要处理场景图和游戏逻辑，这样对比的才是真正的空间思维和工程组织能力。
另外，Three.js 的 API 在训练语料里出现频率极高，三个模型对它都不陌生，这保证了测试的公平性。如果换成某个冷门引擎，可能三个模型都写不对，那就失去对比意义了。
2.3 评分维度怎么定
我没有用单一的"能不能跑"来打分，而是拆成五个维度，每个维度都有明确的观察点：
| 维度 | 观察点 | 权重 |
|---|---|---|
| 首次可运行率 | 复制代码后能否直接跑起来 | 高 |
| 空间数学正确性 | 向量、四元数、相机朝向是否正确 | 高 |
| 物理与碰撞 | 重力、跳跃、落地、收集判定是否合理 | 高 |
| 代码组织 | 模块划分、状态管理是否清晰 | 中 |
| 交互手感 | 移动速度、相机平滑、跳跃力度是否舒适 | 中 |
权重不是拍脑袋定的。首次可运行率排最高，是因为对大多数使用者来说，改一个跑不起来的项目比从零写还累。空间数学和物理并列，是因为这两个是 3D 的命门，错了就是黑屏或穿模。代码组织和交互手感属于"锦上添花"，但决定了这个项目能不能继续迭代。
3. Step 5 Preview 的首轮输出：结构最完整，但有个隐蔽的数学错误
3.1 它一次给全了所有模块
Step 5 Preview 的第一轮输出让我有点意外。它没有像很多模型那样只给一个 HTML 文件塞满所有代码，而是主动拆成了几个模块：场景初始化、角色控制、相机跟随、收集物管理、UI 层。虽然最终我还是把它们合并到一个文件里方便测试，但这个组织意识说明它对工程结构有概念。
它给出的技术选型也很合理：用CapsuleGeometry做角色，用Raycaster做地面检测，用Vector3做移动方向计算。这些都是 Three.js 里的标准做法，没有剑走偏锋。
3.2 相机跟随里的四元数陷阱
问题出在相机跟随。Step 5 Preview 用了一种"相机始终看向角色"的实现，代码大致是这样的逻辑：每帧计算相机到角色的方向向量，然后用lookAt让相机朝向角色。听起来没问题，但它同时又在鼠标拖拽时直接修改相机的rotation。这两套逻辑打架了。
具体表现是：鼠标拖拽旋转视角时，相机会先转过去，然后下一帧lookAt又把它拽回来，导致视角抖动，严重时相机直接翻转。这个 bug 很隐蔽，因为静态看代码逻辑是通的，只有实际拖拽才会暴露。
我判断它犯这个错的原因，是它把"相机朝向"和"相机位置"两个概念混在一起处理了。正确的做法应该是：鼠标控制的是相机相对于角色的球面坐标（方位角 + 俯仰角），相机位置由这个球面坐标算出来，然后lookAt角色。这样旋转和跟随就是同一套逻辑，不会打架。
修复其实不难，我把它那段相机代码换成了球面坐标方案：
// 球面坐标控制相机 let theta = 0; // 水平角 let phi = Math.PI / 3; // 俯仰角 const radius = 8; function updateCamera() { const target = player.position.clone().add(new THREE.Vector3(0, 1, 0)); const offset = new THREE.Vector3( radius * Math.sin(phi) * Math.sin(theta), radius * Math.cos(phi), radius * Math.sin(phi) * Math.cos(theta) ); camera.position.copy(target).add(offset); camera.lookAt(target); }改完之后视角就稳了。这个坑值得单独记一笔：凡是相机同时要"跟随"又要"被鼠标控制"的场景，一定要用球面坐标统一管理，不要让两套旋转逻辑并存。
3.3 物理部分它偷了懒
Step 5 Preview 的跳跃实现是直接给 Y 轴速度赋值，然后每帧减一个固定值模拟重力。这在简单场景下能用，但它没有做落地检测的边界处理。角色落地后速度没有清零，导致会有一帧的抖动，而且如果帧率波动，跳跃高度会不一致。
我补了一个简单的速度归零和地面吸附逻辑：
if (player.position.y <= groundY) { player.position.y = groundY; velocityY = 0; isGrounded = true; }这个补充不算复杂，但说明 Step 5 Preview 在物理细节上偏向"能跑就行"，需要使用者自己补边界条件。
4. DeepSeek V4 Pro 的表现：数学最稳，但代码组织偏散
4.1 空间数学几乎零错误
DeepSeek V4 Pro 在空间数学上的表现是三个里最扎实的。它的移动方向计算直接用了相机的前向量和右向量做叉乘，没有出现轴向搞反的问题。角色移动时，按 W 永远是朝着屏幕里走，按 A 永远是往左，这个"直觉正确性"其实很多模型做不到。
它的相机方案一开始就用了球面坐标，没有踩 Step 5 Preview 那个坑。跳跃物理也做了落地检测和速度清零，甚至加了简单的摩擦衰减。从纯技术正确性看，它的首轮输出质量最高。
4.2 但它的代码是一整坨
问题在于组织。DeepSeek V4 Pro 把所有逻辑塞进了一个巨大的animate函数里，输入处理、物理更新、碰撞检测、UI 刷新全混在一起。功能是通的，但你想改任何一个环节，都得在几百行里翻找。
我实测下来，这种写法在项目初期没问题，但一旦要加新功能——比如加个敌人、加个计时器——就会非常痛苦。我后来手动把它拆成了几个更新函数：
function updateInput() { /* 处理键盘鼠标 */ } function updatePhysics() { /* 重力、碰撞 */ } function updateCollectibles() { /* 旋转、收集判定 */ } function updateUI() { /* 计数、计时 */ } function animate() { requestAnimationFrame(animate); updateInput(); updatePhysics(); updateCollectibles(); updateUI(); renderer.render(scene, camera); }拆完之后逻辑清晰多了。这说明 DeepSeek V4 Pro 是"技术强但工程习惯一般"的类型，适合你已经有架构思路、只需要它帮你实现具体算法。
4.3 收集判定它用了距离检测
DeepSeek V4 Pro 判断角色是否碰到收集物，用的是两个物体中心点的距离小于某个阈值。这个方案简单有效，但有个小问题：如果收集物做大一点，或者角色移动速度快一点，可能会"穿过去"而没触发。更稳妥的做法是用包围盒相交检测，或者做连续碰撞检测。
不过对于这个规格的小游戏，距离检测够用了。我提这一点是想说明：模型给的方案往往是"够用"而不是"最优"，你得知道它的边界在哪，什么时候需要升级方案。
5. GLM5.3 的路线：交互手感最好，但首轮跑不起来
5.1 它在手感调校上有想法
GLM5.3 的输出有个明显特点：它在移动速度、跳跃力度、相机平滑这些"手感参数"上花了心思。它给移动加了一个加速度和减速度的过渡，而不是瞬间启停，角色动起来更顺滑。相机跟随也做了插值，不会硬邦邦地贴着角色。
这些细节说明 GLM5.3 对"游戏体验"有感知，不只是把功能堆出来。如果你做的是需要手感的产品，这一点很加分。
5.2 但它首轮代码有引用错误
可惜的是，GLM5.3 的首轮代码跑不起来。问题出在它引用了一个没有定义的变量——它在相机更新函数里用了一个cameraTarget，但这个变量在初始化部分根本没声明。这种错误属于典型的"生成时上下文丢失"，模型写着写着忘了前面有没有定义。
我补上声明之后就能跑了。但这个体验提醒我：GLM5.3 的输出需要更仔细地过一遍变量引用，尤其是跨函数使用的变量。它不像 DeepSeek V4 Pro 那样数学严谨，也不像 Step 5 Preview 那样结构完整，它的优势在体验层，但基础层需要你把关。
5.3 它的收集反馈做得最细
跑起来之后我发现，GLM5.3 在收集反馈上做得最细。收集物被碰到时，它会做一个缩放消失的动画，而不是瞬间消失。UI 计数也有一个数字跳动的效果。这些都不影响功能，但让游戏感觉更"完整"。
这让我重新思考评分维度：如果只看"能不能跑"，GLM5.3 首轮是失败的；但如果看"跑起来之后的体验"，它反而是最好的。所以模型选型真的要看你的优先级——是要快速拿到能跑的骨架，还是要一个体验打磨过的半成品。
6. 三个模型的横向对比：一张表看清差异
把三个模型的表现整理成表，差异就很直观了：
| 对比项 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 首次可运行 | 可运行，相机有bug | 可运行 | 需修改变量后运行 |
| 空间数学 | 相机逻辑有冲突 | 几乎零错误 | 基本正确 |
| 物理细节 | 落地处理偷懒 | 较完整 | 较完整 |
| 代码组织 | 模块化意识强 | 单函数堆砌 | 中等 |
| 交互手感 | 一般 | 一般 | 最好 |
| 主要短板 | 相机双逻辑打架 | 代码结构散 | 变量引用错误 |
从这张表能看出一个规律：三个模型各有所长，没有全能选手。Step 5 Preview 强在结构，DeepSeek V4 Pro 强在数学，GLM5.3 强在体验。你选哪个，取决于你项目里最不能妥协的是什么。
如果你的项目对正确性要求极高，比如涉及复杂物理或精密空间计算，DeepSeek V4 Pro 的数学稳定性最省心。如果你要快速搭一个可扩展的骨架，Step 5 Preview 的组织方式更好接手。如果你做的是面向用户的体验型产品，GLM5.3 的手感调校能帮你省下不少打磨时间。
7. 实测中暴露的共性问题与我的补位经验
7.1 三个模型都不擅长"帧率无关"的物理
这是最值得说的一点。三个模型的物理更新都是直接按帧减速度，没有乘以 deltaTime。这意味着在 144Hz 屏幕上，角色跳跃高度会比 60Hz 屏幕上低，因为帧数多了，每帧减的速度累积起来更快。
正确做法是把所有物理量都乘以帧间隔：
const delta = clock.getDelta(); velocityY -= gravity * delta; player.position.y += velocityY * delta;这个坑在二维游戏里也存在，但 3D 里因为相机和物理耦合更紧，表现更明显。我实测下来，三个模型都需要手动补这个 deltaTime。这不是模型能力问题，而是训练语料里大量示例代码本身就是简化版，模型学到了这些简化写法。
7.2 收集物的旋转它们都用了欧拉角
三个模型让收集物旋转，用的都是rotation.y += speed这种欧拉角累加。对于单个轴旋转没问题，但如果以后要加多轴旋转或者朝向某个目标，欧拉角会出现万向节死锁。更稳妥的是用四元数或者rotateOnAxis。
不过对于这个规格，欧拉角够用。我提这一点是想说：模型倾向于用最简单能实现的方案，你得知道什么时候该升级。如果收集物只是原地转，欧拉角没问题；如果它要追踪玩家或者做复杂运动，就得换方案。
7.3 输入处理都没做按键状态管理
三个模型的键盘输入都是监听keydown和keyup事件，用一个对象记录按键状态。这个方案本身没问题，但它们都没有处理"窗口失焦"的情况。如果你按着 W 键切到别的窗口，再切回来，角色会一直往前走，因为keyup事件没触发。
修复方法是监听blur事件，清空所有按键状态：
window.addEventListener('blur', () => { keys = {}; });这个细节很小，但实际使用中很影响体验。三个模型都没主动加，需要使用者自己补。
7.4 我的补位清单
基于这次实测，我整理了一份"模型输出后必查清单"，不管你用哪个模型，这几项都建议过一遍：
- 相机是否有双重旋转逻辑（跟随 + 鼠标控制是否打架）
- 物理更新是否乘以 deltaTime
- 落地检测是否做了速度清零和位置吸附
- 窗口失焦时按键状态是否清理
- 收集判定是否考虑了高速穿透
- 变量引用是否完整（尤其跨函数使用的）
这份清单帮我省了很多调试时间。模型能给你 80% 的骨架，剩下 20% 的边界处理，才是决定项目能不能真正跑起来的关键。
8. 如果让我重新做一次，我会怎么组织提示词
8.1 把约束写进提示词，而不是事后修
这次实测最大的收获是：模型的输出质量，很大程度上取决于你提示词里的约束密度。我第一轮给的提示词只描述了功能，没有描述技术约束，所以三个模型都用了各自的默认写法，导致我需要事后补 deltaTime、补失焦处理。
如果重来一次，我会在提示词里直接写明：
- 所有物理更新必须乘以 deltaTime
- 相机使用球面坐标统一管理，不要混用 lookAt 和直接改 rotation
- 监听 window blur 事件清空按键状态
- 收集判定使用包围盒而非中心点距离
把这些写进去，模型的首轮输出质量会高很多。这不是模型变强了，而是你帮它排除了它容易犯的错。
8.2 分阶段要代码，而不是一次要全
另一个经验是：一次性要完整项目，模型容易在后期丢失上下文，出现变量未定义这类错误。更好的做法是分阶段：先要场景和相机，跑通后再要角色控制，再要物理，最后要收集和 UI。每个阶段都验证通过再进入下一阶段。
这样虽然交互轮次多了，但每轮的输出都更可靠，调试成本反而更低。GLM5.3 那个变量未定义的错误，如果分阶段要，很可能就不会出现。
8.3 让模型解释它的选择
我还会加一条：让模型在给代码的同时，说明关键选择的原因。比如"为什么相机用球面坐标""为什么物理要乘 deltaTime"。这样你能快速判断它的方案是否合理，而不是等跑起来才发现问题。模型解释得清楚，说明它真的理解；解释得含糊，往往就是它抄了个模板但没想明白。
9. 关于 WorkBuddy 这类工具在 3D 项目里的实际用法
热词里出现了不少 WorkBuddy 相关的搜索，我顺带说说这类工具在 3D 游戏开发里的定位。WorkBuddy 本质上是一个任务编排和工作流管理工具，它不直接写 3D 代码，但可以帮你把"模型生成、代码验证、问题记录"这几步串起来。
我的用法是这样的：把 3D 游戏的开发拆成若干任务卡，每张卡对应一个模块（场景、相机、物理、收集、UI），每张卡里记录提示词、模型输出、验证结果、修复记录。这样当你要换模型重做某个模块时，历史记录都在，不用从头回忆。
WorkBuddy 的自定义指令功能在这里特别有用。你可以给它定几条规则，比如"所有代码输出必须包含 deltaTime 处理""相机相关代码必须说明旋转方案"，然后这些规则对所有任务生效。这相当于把你的补位经验固化成了流程，下次不管用哪个模型，输出都会自动带上这些约束。
至于 WorkBuddy 的安装、缓存目录修改、私有化部署这些操作层面的问题，属于工具本身的配置，和 3D 开发关系不大，这里就不展开了。核心思路是：把模型当成生产力，把 WorkBuddy 这类工具当成生产流程的管理层，两者配合才能稳定产出。
10. 最后分享几个我踩出来的实操技巧
第一个技巧：测试 3D 代码时，先把相机固定住。相机是 3D 项目里最容易出问题的部分，如果相机在动，你很难判断是角色移动错了还是相机跟错了。我的做法是先把相机写死在一个固定位置，验证角色移动和物理正确后，再打开相机跟随。这样能把问题隔离，调试效率高很多。
第二个技巧：用坐标轴辅助对象定位问题。Three.js 有AxesHelper，加一行scene.add(new THREE.AxesHelper(5))就能看到红绿蓝三个轴。当角色移动方向不对时，看一眼轴就知道是哪个方向反了。这个比盯着代码猜快得多。
第三个技巧：收集物的判定阈值要略大于视觉尺寸。模型给的距离检测阈值往往等于收集物的半径，但实际玩的时候，玩家会觉得"明明碰到了却没收集到"。把阈值放大 10% 到 20%，手感会好很多。这是纯体验层面的调整，模型不会主动做，但玩家能明显感知。
第四个技巧：跳跃力度和重力要一起调。很多人只调跳跃初速度，结果角色要么跳得太高滞空太久，要么跳得太矮。正确的做法是同时调重力和初速度，让跳跃高度和滞空时间都符合预期。经验值是重力设为 -20 到 -30，初速度设为 8 到 12，具体看你的场景尺度。
这几个技巧都是我在反复调试里攒下来的，模型不会告诉你，但实际做项目时能帮你省下大量时间。3D 游戏开发的门槛不在写代码，而在这些手感细节的打磨上。模型能帮你跨过代码门槛，但手感这道坎，还是得自己过。
