这个月我干了一件挺折腾的事：把身边正在用的三个顶级AI编程模型拉到同一起跑线，让它们各写一个3D小游戏。任务完全一样，提示词完全一样，连开发环境都一模一样。三个被测模型分别是Step 5 Preview、DeepSeek V4 Pro和GLM5.3。选择3D游戏作为考题，是因为它比整天刷的LeetCode、CRUD接口难太多了——一个3D游戏需要代码同时处理三维向量、相机投影、碰撞体积、光照阴影、动画循环、键盘输入和UI更新。这些模块任何一个环节出错，游戏就会黑屏、闪退、穿模或者卡成PPT。这种复杂度能非常直观地把模型之间的能力差距拉出来，而不是像普通问答那样你好我好大家好。这篇文章我把完整实测过程、代码细节、踩坑记录和横向对比结论全部摊开讲，不管你是用AI写业务代码的工程师，还是想靠AI搞独立游戏的开发者，都能从里面找到实际能用的东西。

1. 实测背景与目标设定

1.1 为什么拿3D游戏当考题

先说清楚一件事：AI写代码的能力评测，最怕的就是任务太简单。你让它生成一个计算器、一个Todo List，闭眼都能过，根本分不出高下。但3D游戏完全不是一个量级。一个最基础的"控制角色移动、收集金币、躲避障碍"的3D小游戏，背后至少要拉通这些知识：

• 三维坐标系下的向量运算、位置插值、距离判断
• 透视相机的参数设置与跟随算法
• 渲染循环里的时间步进（deltaTime）与物体更新
• 键盘事件监听与角色控制
• 碰撞检测的近似算法与物体生命周期管理
• 材质、光照、阴影、雾效这些视觉层面的系统配置

更关键的是，这些模块不是孤立的。相机代码写错了，角色动起来就头晕；碰撞检测写错了，金币永远捡不到；渲染循环里每帧创建新对象，浏览器就直接卡死。这种强耦合、多依赖的场景，最能暴露模型在"系统级理解"上的真实水平。

另外我还有一个私心：3D游戏是很多开发者想尝试但总被数学劝退的方向。如果AI能把这块的基础代码生成质量拉上去，那对独立开发者来说等于是白捡了一个3D数学助教。所以我这次刻意把任务往"开箱即用"的方向设计——不要求艺术资产，不搞复杂玩法，就用最简单的几何体搭出完整可玩的游戏，让每个模型在纯代码能力上一决高下。

1.2 三个被测模型的定位差异

这次参与实测的三个模型，定位上其实有明显的错开：

Step 5 Preview延续了"Step"系列在深度推理上的路子，官方口径强调的是多步思考、复杂任务拆解、代码逻辑链的连贯性。这类模型通常在被调教得"稳重"，适合写架构严谨、可维护性强的代码，但代价是可能偏保守、模板化。

DeepSeek V4 Pro这条线大家都很熟了，一贯的风格是长上下文、高性价比、中文友好。V4 Pro在工程任务上明显加强了工具调用和代码生成能力，特别是处理长文件、多轮迭代改需求时，不需要你反复粘贴代码，直接甩一句话它就能定位到修改点。

GLM5.3走的则是全能路线，多模态理解、Agent能力、代码生成一把抓。它在中文场景下的自然语言理解非常强，你描述需求时越口语化，它给出的方案反而越接近你脑子里想的那个效果。

不过这里必须强调：厂商宣传归宣传，实测才是硬道理。我接下来的所有结论只基于这一次限定时段内的实际体验，不代表模型的最终水平，也不排除后续版本升级带来的变化。你要是测出来的结果跟我不同，太正常了，毕竟模型这玩意迭代速度实在太快。

2. 环境准备与任务设计

2.1 技术栈选型：Three.js + Vite + TypeScript

实测之前得先把技术栈钉死，不然三个模型写出来的代码五花八门，根本没法对比。

这次我选了Three.js作为3D渲染库。原因很简单：它是浏览器3D领域生态最庞大的方案，GitHub上star数接近10万，社区教程、官方示例、Stack Overflow的问答多到爆炸，这意味着模型的训练数据里关于Three.js的正确代码量级最大，生成时不容易瞎编API。

Babylon.js其实也能做，而且引擎能力更工业级，但它在中文社区的讨论热度远不如Three.js，模型对它的API掌握程度大概率会漏出破绽。这种对比測試的意义就是把变量控制到最少，所以我不选它。

构建工具用的Vite，配合TypeScript。Vite启动快、报错信息清晰，很适合快速验证；TypeScript则能逼着模型把类型写对——很多AI生成的JS代码能跑是因为鸭子类型帮你兜底，但一旦声明了接口、类型标注，那些隐性的属性拼写错误就会立刻暴露。

完整的工程初始化命令如下：

npm create vite@latest ai-3d-test -- --template vanilla-ts cd ai-3d-test npm install three npm install -D @types/three

这个组合对AI来说非常友好，因为three的官方类型定义就是最好的API文档，模型在生成代码时会参考类型提示来推断方法签名。

2.2 统一任务书：一份覆盖核心玩法的提示词

为了让三个模型在相同的起跑线上工作，我把需求完整地写在提示词里，而不是一句"做个3D游戏"就甩过去。任务书太模糊，AI就自由发挥，最后你根本没法分辨是它的能力问题还是你的表达问题。

我给三个模型的任务要求如下：

使用Three.js + TypeScript开发一个3D小游戏，具体要求：

1. 玩家角色：一个半径为0.5的金色球体，用WASD键控制沿XZ平面移动，按空格键跳跃，重力效果要自然。
2. 场景：绿色圆形平面作为地面，静态蓝天背景，开启阴影映射，至少一盏平行光。
3. 收集物：场景中随机位置生成10个金币（黄色小圆柱体），玩家碰到后金币消失并计分，全部收集则显示"胜利"画面。
4. 障碍物：地面上有若干个缓慢移动的红色立方体，碰到玩家后游戏结束，显示"失败"画面。
5. 相机：第三人称跟随视角，镜头平滑跟随玩家，不穿模、不抖动。
6. 界面：HTML叠加层显示当前分数、倒计时和新游戏按钮。
7. 代码组织清晰，所有逻辑写在src/main.ts中，全局不使用any类型。

你会发现我故意把需求压得很细，连"金色球体""红色立方体""圆形平面"这种视觉细节都写进去了。这样做有两个目的：一是让三个模型的输入完全一致，二是方便我后续从"需求还原度"这个维度打分。AI写代码最怕的就是需求理解偏差，如果同一个描述三个模型做出了三种玩法，那对比的就不是代码能力而是玄学。

另外我特意要求全局不用any类型。这招很狠，因为很多AI生成代码遇到复杂API时第一反应就是把类型糊成any来绕过检查。这一步可以直接卡掉一批"看起来有用但经不起编译"的代码。

2.3 评分维度与通过标准

评测不是看个热闹就行，我预先定好了一套可量化的评分表，分五个维度：

• 首次可运行性：拿到代码直接npm run dev，忽略编译报错和运行时崩溃按次数扣分。
• 需求覆盖率：对照提示词里的7条需求逐项核对，每缺一项扣分。
• 3D数学正确性：重点检测碰撞检测的精度、相机跟随的平滑度、跳跃重力曲线的合理性。
• 视觉质量：光照、阴影、色彩搭配、雾效、整体观感。
• 代码可维护性：模块划分是否清晰、有没有硬编码坐标、注释是否解释了"为什么"而不是"是什么"。

每一项满分20分，总分100。三个模型前后对比，谁强谁弱一目了然。接下来是重头戏——实际测试过程。

3. 实测记录：三款模型逐个出战

3.1 Step 5 Preview：开局一次跑通，但代码有点啰嗦

第一个上场的是Step 5 Preview。说实话我对它期望值很高，毕竟定位就是推理能力，3D游戏这种逻辑密集型任务应该是它的主场。

提交提示词之后大概等了40秒开始流式输出，生成的代码很长，足足500多行。我仔细观察了一下输出节奏：它不是一口气写完，而是先写了一小段场景初始化，然后停顿，像是"思考"了下一块应该写什么，再继续输出移动逻辑、碰撞逻辑、UI逻辑，模块间切换非常清晰。

第一次运行就通过了编译，这是相当不错的成绩。我打开浏览器，一个金色球体出现在绿色地面上，阳光、阴影、远处的山丘背景都齐活了，WASD移动顺畅，空格跳跃的重力下落曲线很自然，相机跟随没有抽搐感。

让我特别满意的是它的碰撞检测写法。它没有直接用Three.js自带的Raycaster去射三条射线，而是巧妙地用一个近距离平方比较：

function checkCollisions(playerPos: THREE.Vector3): void { const threshold = 1.2; const thresholdSq = threshold * threshold; // 遍历所有金币，用平方距离判断收集。 // 用平方距离而不是distance()可以避免开根号计算，每帧省下10次sqrt。 coins.forEach((coin, index) => { if (!coin.visible) return; const coinPos = coin.getWorldPosition(new THREE.Vector3()); const dx = playerPos.x - coinPos.x; const dz = playerPos.z - coinPos.z; if (dx * dx + dz * dz < thresholdSq) { coin.visible = false; score += 1; updateScoreDisplay(); } }); // 障碍物碰撞检测用的是AABB近似， // 把球体简化为边长2.4的立方体包围盒，足够接近且更稳定。 obstacles.forEach((obstacle) => { if (!obstacle.visible) return; const obsPos = obstacle.position; const dx = playerPos.x - obsPos.x; const dz = playerPos.z - obsPos.z; if (Math.abs(dx) < 1.2 && Math.abs(dz) < 1.2) { endGame(false); } }); }

这段代码的水平其实已经超过很多初级前端工程师了。它不是背答案，而是真的理解了碰撞检测里的性能优化思路——平方距离、简化包围盒、visible标记而不是销毁物体。这些都是典型的"实践出真知"的写法。

但它的缺点也很明显：代码太啰嗦了。每个函数前面都有三四行长注释，解释"为什么这么写"，连THREE.Clock的标准用法都要写注释。虽然不扣分，但读起来就像在翻官方文档，缺乏一点"人味儿"。另外它把大部分变量都放在模块顶层，没有搞成类或独立的函数式模块，500多行里散落着十几个let变量。如果后续要扩展新玩法，这个代码会变得不好维护。

我的评价是：稳，但稳得像一个很认真的新人；所有需求100%覆盖，零bug，但代码风格偏保守。

3.2 DeepSeek V4 Pro：物理引擎的真实感与失控时刻

第二个上场的是DeepSeek V4 Pro。它的输出风格跟Step 5 Preview完全不一样，几乎没做停顿思考，噼里啪啦一口气就把600多行代码全倒出来了。光看速度确实快得离谱。

我满怀期待地运行，结果第一版直接把我逗笑了：它写的跳跃，居然是用Cannon.js物理引擎模拟真实的重力和碰撞响应。一个用Three.js渲染的球体碰撞体和一个用Cannon.js模拟的物理世界同步，好处是跳跃下落带一点真实的抛物线形变，球体落地还会有轻微弹跳，画面物理感极其真实。

但坏处也很致命：物理世界的参数没调好。球体质心比视觉模型低了一截，每次落地之后会带着惯性往前滑一段，然后因为摩擦系数设置太小，又慢慢飘回原地。我控制角色走到金币旁边，金币倒是会被吸走，但角色自己一直处于"被一股神秘力量推着走"的状态，手感非常诡异。

第二轮我带着报错信息回问：

跳跃后落地会滑行，手感太飘。请检查Cannon.js的linearDamping和angularDamping设置，并确保物理体中心与视觉模型对齐。

这次它给出了关键调整，直接补全了物理相关的参数：

import * as CANNON from 'cannon-es'; const world = new CANNON.World(); world.gravity.set(0, -9.82, 0); world.broadphase = new CANNON.SAPBroadphase(world); const playerBody = new CANNON.Body({ mass: 1, shape: new CANNON.Sphere(0.5), position: new CANNON.Vec3(0, 2, 0), // 线性阻尼调的稍大，落地后动能快速衰减，防止滑行 linearDamping: 0.9, // 角阻尼拉满，球体不会莫名其妙自旋 angularDamping: 0.95, }); // 每帧用物理体位置回写视觉模型 player.position.copy(playerBody.position as unknown as THREE.Vector3); player.quaternion.copy(playerBody.quaternion as unknown as THREE.Quaternion);

这一轮修改很有效。阻尼值调上去之后，落地滑行的问题基本消失了。但问题也随之而来：物理引擎带来的性能开销非常明显。我本机跑起来帧率掉到45fps左右，而Step版本稳定在58fps。对一个小游戏来说，这个性能差距有点不能接受。

更麻烦的是，物理引擎虽然好，但用它处理"玩家移动"其实是大材小用。角色移动本质上是运动学问题，用物理引擎做反而容易引入重力、摩擦力这些不可控因素。三个模型处理跳跃的方式高下立判：Step版本用速度公式直接算位移，简单稳定；DeepSeek版本用物理引擎强模拟，效果真实但脆弱。

三轮对话下来，DeepSeek V4 Pro最终跑通。它的最终版物理手感在所有模型里确实最好——跳跃高度曲线平滑，落地有一瞬间的压缩回弹，这套效果放到独立游戏里都拿得出手。但代价是要多花两轮调试，还要接受物理计算带来的性能折损。

我的评价是：上限很高，但需要你懂一点物理知识，不然它给你的东西你驾驭不了。

3.3 GLM5.3：画面最漂亮，bug也最刁钻

第三个上场的是GLM5.3。它生成的代码只有400行左右，是所有模型里最短的——但它居然在第一版里塞进了Post-processing泛光效果和一套Toon风格着色器。视觉效果狠狠惊艳了一把：金色球体边缘有柔和的发光，红色障碍物上带一点卡通描边，地面用了一个渐变材质，整体画面质感直接把另外两个模型秒了。

你可以说这是作弊，毕竟另外两个模型都在老老实实实现玩法，它却直接奔着"好看"去了。但GLM的问题也藏在这种"美学优先"的策略里。

第一版运行有3个bug，全都是很刁钻的类型：

• 第87行用了一个未初始化的const变量，编译直接报错。这个低级错误在Step版本里不可能出现。
• 障碍物的事件监听器绑到了window上，结果按键盘时整个页面都在触发移动，角色跟着键盘一起跳动。它本意是监听window保证焦点不丢失，结果忘了在dispose里解绑。
• 渲染器的阴影设置写错了：renderer.shadowMap.type = THREE.Vector2。这是个典型的语义错误，THREE.Vector2存在，但跟阴影过滤算法根本不是一回事。这种错误靠TypeScript类型检查能拦住，但GLM为了绕开类型报错，把渲染器声明成了any，直接把底部保护层拆了。

我把这三个bug原样贴回给GLM5.3，要求它逐条修复。它的应对很厉害：直接重写了阴影配置，并且主动加了一个sceneTraverser来批量为所有物体设置阴影。修复后的代码如下：

const renderer = new THREE.WebGLRenderer({ antialias: true }); renderer.shadowMap.enabled = true; renderer.shadowMap.type = THREE.PCFSoftShadowMap; // 修复为正确的软阴影枚举值 // 遍历场景，为所有网格统一开启阴影投射和接收，避免漏配置 scene.traverse((child) => { if (child instanceof THREE.Mesh) { child.castShadow = true; child.receiveShadow = true; child.material.needsUpdate = true; } });

这个traverse解法非常聪明，因为Three.js的阴影默认是关闭状态，AI生成的代码经常漏掉这个开关导致画面一片"漂"感觉，而GLM5.3直接用遍历把它兜住了。

修复之后整体运行起来，帧率只有55fps左右，但画面观感是最好的——柔和的泛光让金币看起来像小灯泡，Toon风格的边缘线让整个场景更接近一个二次元游戏。如果任务目标是"做一个视觉漂亮的3D demo"，GLM5.3领先另外两个一个身位。

我的评价是：GLM5.3在美术表现上确实有一套，但代码稳定性需要靠迭代补。它更适合做视觉原型，不适合直接交付生产代码。

4. 三款模型生成代码的横向对比

4.1 性能与完成度实测数据

三轮实测下来，我把关键数据整理成了表格，方便直接看结论：

几个值得展开的点：

代码行数最能体现风格差异。DeepSeek V4 Pro用了612行实现同一个功能，因为它塞进了物理引擎同步、材质初始化、事件详绑；GLM5.3只有402行，但同样是因为它砍掉了物理逻辑和部分UI细节。Step 5 Preview的486行居中，但它的代码密度最高——每行都干了正事，没有凑数的。

运行时错误最考验模型底功。Step版本零bug一次跑通，这在3D游戏这种复杂度下相当难得。GLM的3个bug里有一个是类型语义错误（THREE.Vector2），说明它在Three.js API的类型记忆上存在明显盲区。DeepSeek虽然没有直接报错，但物理参数不调好的话也等于不可用，只是问题藏在运行时而不是编译期。

性能表现上，物理引擎是最致命的性能杀手。DeepSeek版本一旦开启物理模拟，每帧同步位置和旋转数据，直接把帧率从58拉垮到45。如果你要做的是网页小游戏，我更建议走Step的"手写运动学"方案，稳定、可控、省电。

4.2 3D数学能力：从碰撞检测和相机跟随看高下

3D数学是这次测试里拉开差距的核心地带，我挑两个典型环节单独分析。

碰撞检测这一块，Step 5 Preview的平方距离判断和AABB近似组合拳写得很聪明。它甚至考虑到用distanceToSquared替代distance()来省掉开根号运算，这说明它对Three.js的API是真正理解而不是死记硬背。DeepSeek V4 Pro干脆绕过了手写碰撞检测，直接用Cannon物理引擎的碰撞事件来做。这种方式正确性很高，但前提是物理体和视觉模型严格对齐，否则就会出现"看起来没碰到但游戏结束了"的幽灵碰撞。GLM5.3的碰撞检测写得最朴素，就是每帧对每个金币调用getWorldPosition然后做一次欧几里得距离判断，没有做任何优化。在金币只有10个的情况下够用，但一旦场景里摆上50个金币，每帧50次new THREE.Vector3()就会造成明显的垃圾回收卡顿。

相机跟随是另一个分水岭。三个模型都用的是"Lerp插值+LookAt"的经典方案，但细节品质差距很大：

// 这是Step 5 Preview的写法：目标位置计算与lerp系数分离，可读性高 const desiredPosition = new THREE.Vector3( player.position.x, player.position.y + 5, player.position.z - 8 ); camera.position.lerp(desiredPosition, 0.08); camera.lookAt(player.position);

DeepSeek V4 Pro把lerp系数做到了1.0，等于完全没有平滑过渡，相机就像焊在角色头上一样，转头的时候画面会突然甩一个方向，玩久了会晕。GLM5.3的lerp系数设成了0.03，平滑是平滑了，但角色急转弯时镜头像一个反应迟钝的跟拍云台，会明显滞后半拍，操作手感黏糊糊的。

这种细节差距，正是3D游戏里"手感"的来源。普通玩家说不清差在哪，但玩起来就是觉得"不跟手"或者"太飘"。AI能生成出代码，但"手感"这种需要反复试玩才能调出来的东西，模型还需要依赖人类的反馈来迭代。

4.3 代码风格与可维护性的差异

三个模型写完的同款功能，你光看代码结构就能认出来是谁写的。

Step 5 Preview的代码风格像一本正经的官方教程。变量命名清晰准确，每个流程分块注释，还专门用//---------------分割线把场景初始化、玩家控制、碰撞检测、UI更新四个区块标得清清楚楚。缺点是略微啰嗦，一处简单的score += 1都要解释为什么直接修改而不是用setter。

DeepSeek V4 Pro的代码像一个老工程师"炫技"。它优先选择高级方案（物理引擎、事件代理、模块化），但有时候高级方案完全架在过度设计上——一个只需要运动学模拟的跳跃愣是配了一套完整的物理引擎同步代码。如果后续有人接手这个项目，必须同时理解Three.js和Cannon.js两套体系才能改得动。

GLM5.3的代码最像艺术家的草图。变量命名充满主观色彩，比如障碍物数组叫movingBlocks，金币数组叫goldenCoins，跳跃高度直接写3.5而不是用常量JUMP_VELOCITY。优点是可读性强、有画面感；缺点是硬编码太多，很难调参。

从可维护性角度，这次我评Step 5 Preview第一。它的代码即使给一个从没接触过Three.js的人看，也能按图索骥理解每一步在干什么。

5. 常见问题与排查技巧实录

5.1 AI写3D代码的六大经典翻车点

这次实测的收获不止是三个模型的对比，我自己也整理了一份AI写3D代码时最容易踩的坑。这些坑跟模型无关，但凡是让AI写Three.js代码，基本上都会踩中其中几个。

第一：忘记调用renderer.render()。这是最低级也是最常见的错误。AI的代码往往把场景初始化、相机设置、物体创建全写好了，但渲染循环的末尾漏掉renderer.render(scene, camera)，结果屏幕上啥都不显示。这次GLM第一版就有这个问题，它把render调用写进了一个永远不执行的if(false)分支里。

第二：阴影不显示。Three.js的阴影系统是按"映射"走的，必须在渲染器和光源上双重开启，模型经常只开其中一处。这次三个模型里有两个第一版都出现了这种情况。排查方法也很简单：检查渲染器是否有shadowMap.enabled = true，同时检查平行光是否设置了castShadow = true。

第三：坐标系概念混淆。getWorldPosition()返回的是世界坐标，position返回的是局部坐标，这两者经常被AI混用。如果父物体有位移或旋转，用错了坐标就会出现金币明明摆在眼前但角色怎么都捡不到的情况。

第四：每帧创建新对象导致GC卡顿。这是Three.js性能优化的核心规则，但AI生成的代码经常在碰撞检测或渲染循环里new THREE.Vector3()。JavaScript的垃圾回收器会在某帧突然把所有新建的临时对象清空，导致画面周期性掉帧。这次的DeepSeek版本就有这个问题。解决办法是像Step版本那样，提前声明一个tempVec复用它。

第五：事件监听器绑定错对象。移动游戏的键盘事件应该绑定到window或document，但AI经常绑到具体某个DOM元素上，结果鼠标焦点不在canvas上时按键就没反应。GLM这次恰恰相反，绑到了window上但忘了处理焦点变化。

第六：材质贴图或颜色参数乱填。有些模型生成代码时会写出new THREE.MeshStandardMaterial({ color: 0x000000 })这种黑色材质，然后在光线不足的场景里什么都看不清。这倒不是错误，但反映了模型对视觉呈现的全局考虑不足。

5.2 让AI改好一段3D代码的提示词心法

这次实测还有一个额外收获：跟AI迭代调试时的提示词套路。很多人在AI生成代码报错后只会把报错信息原样粘贴，这样效果极差。我整理了一套"三段式反馈法"，实测下来效率最高。

第一步：贴原始错误信息。直接把终端或浏览器的报错完整粘贴，一句废话都不要多。注意要包含栈调用信息，方便AI定位具体文件行。

第二步：描述期望行为。用一句话说明"现在发生了什么，以及你期望它发生什么"。比如"角色落地后滑行太远，期望它原地停住"。这一步看起来简单，但实际上是在帮助AI建立"当前状态"和"目标状态"的对比，它的下一轮代码才不至于南辕北辙。

第三步：给出约束条件。如果这次修改有特定要求，明说。比如"不要引入新的第三方库"、"保持现有代码结构不变"、"修改只限于src/main.ts文件"。约束越明确，AI越不会自作主张重构你的工程。

这次DeepSeek V4 Pro的物理调参就是用了这套方法。第一次只用"太飘了"三个字反馈，它改出来的代码引入了更多不确定参数；第二次明确告诉它改linearDamping和angularDamping，它瞬间就锁定了正确方向。

5.3 三款模型的推荐使用场景

跑完全程，我根据自己的使用偏好给三个模型画了一个推荐地图。

Step 5 Preview适合你需要"一把过"的场景。生成一个通用功能、做一个小工具、搭一个项目骨架，它就是那个"高可靠度"的选项。在3D游戏这种高复杂度项目里，它能保证第一版就能跑，省下的调试时间价值有多大，做过项目的人都知道。缺点是它可能给你一个很"标准"但缺乏惊喜的方案。

DeepSeek V4 Pro适合复杂系统交互和多轮迭代。它生成代码时上下文吸收能力强，你让它改一个功能，它会记得之前所有对话里的约束，不需要你反复提醒。在物理效果模拟、动画编排这类"重逻辑"任务上，它愿意上真正的引擎方案。但你要有后续调参的心理准备，第一版往往是"半成品"。

GLM5.3适合你拿它做视觉原型和创意探索。它的审美和画面感在三个模型里一枝独秀，生成的效果往往超出预期。它可以成为你独立游戏的美术顾问——你告诉它"我想要一个赛博朋克色调的3D街景"，它给你的方案远比其他模型有味道。但使用它时一定要开启严格的TypeScript检查，防止它用any绕过告警。

根据实测经验给一个开箱即用的调整

最后分享一个我在这次测试里发现的小技巧：如果你决定用Three.js配合AI快速开发一个小游戏，可以在tsconfig.json里把noUncheckedIndexedAccess和noImplicitAny这两个选项打开。前者能逼AI处理数组索引的undefined可能性，后者直接从编译层杜绝any逃逸。这次实测里，Step 5 Preview和GLM5.3的表现差异，有相当一部分就来自类型检查的严格程度。

这两天实测下来，我最大的体会是：三个模型的差距没有想象中那么大，它们都能跑出一个完整的3D游戏，但个人的性格差异确实很明显——Step像稳健的顾问，DeepSeek像激进的工程师，GLM像浪漫的设计师。你选谁，取决于你自己更欣赏哪一种协作方式。如果非要给一条建议，那就是：别指望一个模型解决所有问题，把任务拆开，谁擅长什么就让谁干什么。这个开源安卓3D游戏方向的尝试只是第一步，同样的方法可以用来做更复杂的场景——让AI给你搭好3D骨架，你专注于玩法内核和美术风格，这可能是未来独立开发者最高效的工作流。