这个月我干了一件挺折腾的事把身边正在用的三个顶级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 vitelatest 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小游戏具体要求玩家角色一个半径为0.5的金色球体用WASD键控制沿XZ平面移动按空格键跳跃重力效果要自然。场景绿色圆形平面作为地面静态蓝天背景开启阴影映射至少一盏平行光。收集物场景中随机位置生成10个金币黄色小圆柱体玩家碰到后金币消失并计分全部收集则显示胜利画面。障碍物地面上有若干个缓慢移动的红色立方体碰到玩家后游戏结束显示失败画面。相机第三人称跟随视角镜头平滑跟随玩家不穿模、不抖动。界面HTML叠加层显示当前分数、倒计时和新游戏按钮。代码组织清晰所有逻辑写在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 demoGLM5.3领先另外两个一个身位。我的评价是GLM5.3在美术表现上确实有一套但代码稳定性需要靠迭代补。它更适合做视觉原型不适合直接交付生产代码。4. 三款模型生成代码的横向对比4.1 性能与完成度实测数据三轮实测下来我把关键数据整理成了表格方便直接看结论评测指标Step 5 PreviewDeepSeek V4 ProGLM5.3首次运行即可运行是是物理手感异常否3处bug最终版本可运行是是是平均帧率本机58 fps45 fps开启物理引擎55 fps代码总行数486612402需求覆盖率7/77/75/7缺胜利界面自定义、新游戏按钮样式调试轮次134视觉质量中规中矩写实但暗淡惊艳Toon泛光总分百分制888279几个值得展开的点代码行数最能体现风格差异。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骨架你专注于玩法内核和美术风格这可能是未来独立开发者最高效的工作流。