1. 三款模型同台竞技的背景与实测动机1.1 为什么我要做这次横向对比最近这段时间AI 编程助手这个赛道热闹得有点不像话。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字几乎同时出现在我的信息流里身边做开发的朋友分成三派各说各的好。有人说 Step 5 Preview 在长上下文任务里稳得离谱有人说 DeepSeek V4 Pro 写算法题像开挂还有人把 GLM5.3 吹成了国产代码模型天花板。听多了这种争论我反而起了逆反心理——与其看别人吵架不如自己动手做一次真实项目的横向实测。我选的项目是从零做一个 3D 游戏。为什么偏偏选 3D 游戏因为这类项目对模型的考验是全方位的它既需要数学功底向量、矩阵、四元数、碰撞检测又需要图形学知识渲染管线、光照模型、着色器还得有工程能力场景管理、资源加载、状态机最后还要能把这些东西组织成能跑起来的完整代码。一个模型如果只会写 LeetCode 风格的算法题在 3D 游戏这种综合性任务上会立刻露馅。这就像考驾照场地考满分不代表上路不熄火。这次实测我给自己定的规则很简单同一个需求描述分别喂给三个模型看谁产出的代码能最快跑起来、结构最合理、后续扩展最省心。需求我写得尽量克制不引导任何特定实现方式让模型自己发挥。最终目标是做一个可以在浏览器里直接玩的 3D 小游戏——一个低多边形风格的收集类游戏玩家控制角色在场景里移动收集散落的光球有简单的计分和计时。1.2 三个模型的基本盘与预期在动手之前我先梳理了一下三个模型的定位这有助于理解它们后续的表现差异。Step 5 Preview是阶跃星辰推出的预览版本主打长上下文和复杂推理。从公开信息看它在多轮对话和长文档理解上有明显优势这对 3D 游戏这种需要记住前面写了什么的任务很关键。我预期它在代码一致性和跨文件组织上会表现不错。DeepSeek V4 Pro是深度求索的旗舰版本代码能力一直是它的招牌。V4 Pro 在算法和数学推理上的口碑很好我预期它在物理计算、碰撞检测这类需要精确数学的地方会很强但可能在工程结构上偏学院派。GLM5.3是智谱的最新版本综合能力均衡中文理解尤其出色。我预期它在理解我的中文需求描述时最不容易跑偏代码风格可能偏实用主义。提示做模型横向对比时一定要先明确每个模型的定位和擅长领域否则很容易用苹果和橘子的方式得出错误结论。比如拿一个擅长算法的模型去比工程结构本身就不公平。1.3 实测环境的统一配置为了保证对比的公平性我把三个模型的运行环境尽量统一。测试机器是一台 32GB 内存、RTX 4070 显卡的工作站操作系统是 Ubuntu 22.04。三个模型都通过各自的 API 接口调用温度参数统一设为 0.3偏低减少随机性最大输出长度设为 8192 token。前端运行环境是 Chrome 120用 Vite 做本地开发服务器。这里有个细节值得说温度参数的选择对代码生成影响很大。我试过 0.7 的温度三个模型都会出现自由发挥的情况比如擅自引入我没要求的库或者把简单的实现复杂化。调到 0.3 之后输出明显收敛更贴近需求本身。如果你也在做类似的代码生成测试建议从 0.2 到 0.4 之间开始调。2. 需求拆解与三模型首轮产出对比2.1 我给出的需求描述原文为了让对比有据可查我把需求描述原文贴出来。这段描述我刻意写得像产品经理给开发提需求不涉及任何技术选型做一个 3D 收集类小游戏浏览器里能直接玩。玩家用 WASD 控制一个角色在平面上移动鼠标控制视角旋转。场景里随机散布 20 个发光的光球玩家靠近光球就能收集每收集一个加 10 分。游戏限时 60 秒时间到了显示总分。场景要有地面、几棵树或者柱子作为参照物光照要自然一点。角色移动要平滑不能一顿一顿的。这段描述里其实埋了几个考点视角控制涉及相机和鼠标事件、碰撞检测靠近判定、计时系统游戏循环、场景装饰资源组织、平滑移动插值和帧率无关。哪个模型能把这些点都照顾到基本就能看出它的综合能力。2.2 Step 5 Preview 的首轮产出分析Step 5 Preview 拿到需求后第一轮就给出了一个相当完整的方案。它选择了 Three.js 作为渲染引擎理由是浏览器 3D 场景的事实标准生态成熟。这个选择很务实没有为了炫技去用原生 WebGL。它的代码组织让我印象深刻主动拆成了五个模块——场景初始化、角色控制、光球管理、游戏状态、主循环。每个模块职责清晰模块之间通过一个简单的状态对象通信。这种结构不是需求里要求的是它自己判断这样更好维护才做的。我特意检查了模块间的依赖关系没有循环引用说明它在生成时是有全局规划的不是一段一段拼出来的。平滑移动这块它用了deltaTime做帧率无关的插值代码里明确写了position.lerp(targetPosition, 1 - Math.pow(0.001, deltaTime))。这个写法比简单的lerp(a, b, 0.1)要专业因为后者在不同帧率下移动速度会不一致。这个细节说明 Step 5 Preview 对游戏开发的常见坑是有认知的。不过它也有个小问题光球的碰撞检测用了简单的距离判断但没有考虑角色本身的半径。结果就是玩家要走到光球正中心才能收集手感偏硬。这个问题在三个模型里都出现了后面我会专门讲怎么修。2.3 DeepSeek V4 Pro 的首轮产出分析DeepSeek V4 Pro 的首轮产出走的是另一条路。它同样选了 Three.js但代码风格明显更数学化。角色移动部分它没有用简单的向量加法而是引入了速度向量和加速度的概念做了一套带阻尼的移动系统。代码里能看到velocity.multiplyScalar(damping)这样的写法物理感很强。碰撞检测是它的亮点。它没有用简单的距离判断而是写了一个球体与球体的精确碰撞函数还考虑了角色移动速度对检测的影响加了简单的防穿透处理。这段代码的数学严谨性明显高于另外两个模型注释里还推导了为什么用平方距离而不是开方距离性能优化。但它的工程结构就相对松散。所有代码几乎都堆在一个文件里虽然有注释分隔但没有模块化。我数了一下单文件超过了 600 行。对于一个小游戏来说能跑但如果要扩展成更复杂的项目这个结构会很快变成负担。这印证了我之前的预期DeepSeek V4 Pro 强在算法和数学弱在工程组织。还有个细节它的光照设置偏暗场景看起来有点阴天的感觉。需求里说了光照要自然一点它用了环境光加方向光但方向光强度给低了。这个不算错但说明它对自然的理解偏保守。2.4 GLM5.3 的首轮产出分析GLM5.3 的首轮产出是最接地气的。它对中文需求的理解确实最到位比如不能一顿一顿的这个口语化描述它直接对应到了帧率无关的插值实现还在注释里写了避免低帧率下的卡顿感。它的代码结构介于前两者之间有模块化但不如 Step 5 Preview 彻底有数学严谨性但不如 DeepSeek V4 Pro 深入。它把代码分成了三个文件——主逻辑、工具函数、配置常量。配置常量单独抽出来这个做法很实用因为游戏参数比如移动速度、光球数量、时限经常要调抽出来之后改起来方便。GLM5.3 最让我惊喜的是它对场景装饰的处理。需求里说几棵树或者柱子它没有简单地放几个立方体而是用程序化生成的方式做了低多边形风格的树——树干是圆柱树冠是几个缩放的二十面体。这个细节让场景看起来明显比另外两个模型更有游戏感。而且它把树的生成封装成了函数可以传参数控制树的密度和大小扩展性很好。它的短板在计时系统。它用了setInterval来做倒计时而不是在游戏主循环里累加deltaTime。这两者的区别在于setInterval的精度受浏览器调度影响长时间运行会有累积误差而基于deltaTime的累加则和渲染帧率绑定更准确。这个小问题在 60 秒的游戏里影响不大但如果是长时间运行的游戏就会暴露。2.5 首轮产出对比速查表对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3渲染引擎选择Three.jsThree.jsThree.js代码模块化五模块最彻底单文件最松散三文件居中移动平滑处理帧率无关插值速度阻尼物理帧率无关插值碰撞检测精度简单距离精确球体碰撞简单距离场景装饰基础几何体基础几何体程序化低多边形树计时系统主循环累加主循环累加setInterval中文需求理解良好良好最佳首轮可运行性直接可跑直接可跑直接可跑这张表是我实测后整理的不是模型自己说的。从表里能看出三个模型都能完成基本任务但各有侧重。没有哪个模型是全面碾压的选哪个取决于你更看重什么。3. 核心环节的深度实测与代码剖析3.1 角色移动系统三种实现思路的取舍角色移动是 3D 游戏的手感基础这块我花了最多时间对比。三个模型的实现思路差异很大值得逐个拆解。Step 5 Preview 用的是目标位置插值法。每一帧根据输入计算出一个目标位置然后让角色当前位置向目标位置插值。核心代码大概是这样// Step 5 Preview 的移动实现 const targetPos currentPos.clone().add(moveDirection.multiplyScalar(speed * deltaTime)); mesh.position.lerp(targetPos, 1 - Math.pow(0.001, deltaTime));这个写法的好处是移动非常平滑而且天然帧率无关。1 - Math.pow(0.001, deltaTime)这个系数是经过推导的保证在不同帧率下每秒的插值进度一致。缺点是角色永远追不上目标位置会有一个微小的延迟感。对于收集类游戏来说这个延迟可以接受但如果是格斗游戏就会影响操作精度。DeepSeek V4 Pro 用的是速度阻尼法。它维护一个速度向量输入改变的是加速度速度再积分成位置同时速度每帧乘以一个阻尼系数。代码大概是这样// DeepSeek V4 Pro 的移动实现 velocity.addScaledVector(acceleration, deltaTime); velocity.multiplyScalar(Math.pow(damping, deltaTime)); mesh.position.addScaledVector(velocity, deltaTime);这个写法物理感最强角色有惯性起步和停止都有加速减速过程手感偏重。适合模拟真实物理但对于一个轻松的收集游戏来说有点用力过猛。而且阻尼系数的调参比较敏感调不好角色会像在冰面上滑。GLM5.3 用的是直接位移法加平滑。它先直接算出位移然后对位移做一个平滑处理// GLM5.3 的移动实现 const displacement moveDirection.multiplyScalar(speed * deltaTime); const smoothed displacement.clone().multiplyScalar(smoothingFactor); mesh.position.add(smoothed);这个写法最简单直接手感介于前两者之间。smoothingFactor是一个 0 到 1 之间的常数调起来直观。缺点是它其实不是严格帧率无关的smoothingFactor固定的话高帧率下平滑效果会减弱。不过在实际测试中60 帧和 120 帧的差异肉眼几乎看不出来。实操心得如果你要做的是休闲游戏GLM5.3 的写法最省心如果要做有物理感的游戏DeepSeek V4 Pro 的思路更合适如果追求极致的平滑和帧率无关Step 5 Preview 的插值法最稳。我最后在项目里用的是 Step 5 Preview 的方案因为收集类游戏对操作精度要求不高平滑优先。3.2 碰撞检测从能跑到手感好的关键碰撞检测这块三个模型的差距在首轮就体现出来了但真正的问题是在实测中才暴露的。前面说过Step 5 Preview 和 GLM5.3 都用了简单的距离判断DeepSeek V4 Pro 用了精确球体碰撞。听起来 DeepSeek 更好但实际测试下来问题不在精度而在判定半径。简单距离判断的代码是这样的// 简单距离判断 const dist player.position.distanceTo(orb.position); if (dist collectRadius) { collectOrb(orb); }这里collectRadius如果设成光球的半径那玩家必须走到光球正中心才能收集手感很硬。如果设成光球半径加玩家半径手感就自然多了。三个模型里只有 DeepSeek V4 Pro 在代码注释里提到了这一点另外两个都需要手动调。DeepSeek V4 Pro 的精确碰撞还多了一层处理它计算了玩家这一帧的移动路径判断路径是否与光球相交而不是只看当前位置。这解决了高速移动时穿透光球的问题。代码大概是这样// DeepSeek V4 Pro 的防穿透检测 const movement player.position.clone().sub(player.prevPosition); const toOrb orb.position.clone().sub(player.prevPosition); const t toOrb.dot(movement) / movement.lengthSq(); const clampedT Math.max(0, Math.min(1, t)); const closestPoint player.prevPosition.clone().add(movement.multiplyScalar(clampedT)); if (closestPoint.distanceTo(orb.position) collectRadius) { collectOrb(orb); }这段代码的数学是投影几何把玩家移动路径投影到光球方向找到路径上离光球最近的点再判断距离。这个处理在玩家移动速度很快时特别有用。我实测把玩家速度调到很高Step 5 Preview 和 GLM5.3 都会出现穿过光球但没收集的情况DeepSeek V4 Pro 则稳定收集。不过这里有个性能考量精确碰撞每帧要对 20 个光球都做一次投影计算虽然计算量不大但如果光球数量增加到几百个就需要加空间分区优化了。对于 20 个光球的小游戏这个开销可以忽略。3.3 场景装饰程序化生成 vs 手工摆放场景装饰这块GLM5.3 的程序化生成思路明显胜出。我详细看了它的实现值得展开讲。它的树生成函数大概是这样// GLM5.3 的程序化树生成 function createTree(x, z, scale) { const tree new THREE.Group(); const trunkGeo new THREE.CylinderGeometry(0.2 * scale, 0.3 * scale, 2 * scale, 6); const trunkMat new THREE.MeshStandardMaterial({ color: 0x8B4513 }); const trunk new THREE.Mesh(trunkGeo, trunkMat); trunk.position.y 1 * scale; tree.add(trunk); const crownGeo new THREE.IcosahedronGeometry(1 * scale, 0); const crownMat new THREE.MeshStandardMaterial({ color: 0x228B22, flatShading: true }); const crown new THREE.Mesh(crownGeo, crownMat); crown.position.y 2.5 * scale; tree.add(crown); tree.position.set(x, 0, z); return tree; }这里有几个细节值得说。圆柱的径向分段设为 6这是低多边形风格的关键分段太多就变成高模了失去风格感。二十面体的 detail 设为 0也是同样的道理。flatShading: true让树冠有棱有角强化低多边形风格。这些参数选择说明 GLM5.3 对低多边形美学是有理解的不是随便填的数。Step 5 Preview 和 DeepSeek V4 Pro 都是手工摆放几个立方体或圆柱虽然也能用但场景看起来比较空缺乏游戏感。我后来把 GLM5.3 的树生成函数移植到了最终项目里稍微改了下参数效果很好。注意程序化生成虽然好但要注意随机种子的控制。如果每次刷新页面树的位置都变玩家会失去空间记忆。我在最终项目里用了固定种子的伪随机函数保证每次生成的场景一致。3.4 计时系统一个容易被忽视的精度问题计时系统看起来简单但三个模型的实现差异暴露了一个常见误区。Step 5 Preview 和 DeepSeek V4 Pro 都在主循环里累加deltaTime// 主循环累加计时 let elapsed 0; function animate() { const deltaTime clock.getDelta(); elapsed deltaTime; if (elapsed 60) { endGame(); } // ... 渲染逻辑 }GLM5.3 用了setInterval// setInterval 计时 let remaining 60; const timer setInterval(() { remaining - 1; if (remaining 0) { clearInterval(timer); endGame(); } }, 1000);两者的区别在长时间运行时会显现。setInterval的 1000 毫秒是至少 1000 毫秒浏览器在繁忙时可能延迟到 1010 甚至 1020 毫秒累积下来 60 秒的计时可能实际过了 62 秒。而主循环累加deltaTime是和渲染帧绑定的虽然也有误差但不会累积得那么快。我实测跑了几次setInterval版本的 60 秒实际耗时在 60.5 到 61.2 秒之间波动主循环版本在 60.1 到 60.3 秒之间。对于休闲游戏这个差异可以接受但如果做的是竞速游戏这个误差就会影响公平性。还有个细节页面切到后台时浏览器的setInterval会被节流可能变成每秒只执行一次甚至更慢。而requestAnimationFrame驱动的游戏主循环在后台会暂停切回来时deltaTime会是一个很大的值需要做上限截断否则角色会瞬移。这个坑我在实测中踩到了后面会讲怎么处理。4. 整合优化与最终项目落地4.1 取长补短的整合策略三个模型各有优劣我的最终项目没有直接用任何一个的完整产出而是做了一次取长补短的整合。具体策略是移动系统用 Step 5 Preview 的帧率无关插值因为收集类游戏平滑优先。碰撞检测用 DeepSeek V4 Pro 的精确球体碰撞加防穿透但把判定半径改成了玩家半径加光球半径。场景装饰用 GLM5.3 的程序化树生成加了固定随机种子。计时系统用主循环累加deltaTime并加了后台切换的deltaTime截断。代码结构用 Step 5 Preview 的五模块划分但把配置常量单独抽出来参考了 GLM5.3 的做法。这个整合过程本身就是一次学习。我发现模型生成的代码更像是草稿真正能用的代码需要人来判断和整合。每个模型都有自己的偏见——Step 5 Preview 偏工程DeepSeek V4 Pro 偏数学GLM5.3 偏实用。人的价值在于知道什么场景该用什么。4.2 关键参数的计算与调优过程整合过程中有几个参数需要计算和调优我把过程记录下来。移动速度需求里没给具体数值我根据游戏体验反推。场景大小是 40x40 单位玩家从中心走到边缘需要 20 单位。我希望这个时间在 3 秒左右所以速度设为 20/3 约等于 6.7 单位每秒。实测下来 6.7 稍快调到 6.0 手感最好。收集半径玩家角色半径 0.5光球半径 0.3。如果判定半径设为 0.8两者之和玩家边缘碰到光球边缘就算收集手感自然。如果设为 0.3就要走到光球中心太硬。最终用 0.8。光球数量与分布需求说 20 个。我实测发现 20 个在 40x40 的场景里密度适中玩家平均每 3 秒能收集一个60 秒理论上能收集 20 个。但实际因为要跑动一般能收集 12 到 15 个。这个难度曲线我觉得合适不会太简单也不会太挫败。光照参数环境光强度 0.6方向光强度 0.8方向光位置在 (10, 20, 10)。这个组合下场景明亮但不刺眼阴影柔和。我试过环境光 0.8 加方向光 1.0太亮光球的光晕都看不清了。光球发光效果用MeshStandardMaterial的emissive属性颜色设为青色强度 0.5。再加一个点光源在光球位置强度 1.0距离 3。这样光球在场景里很显眼玩家一眼就能看到。4.3 后台切换的 deltaTime 截断处理前面提到的后台切换坑我详细讲下怎么处理。当页面切到后台requestAnimationFrame会暂停。切回来时clock.getDelta()返回的是从上次暂停到现在的总时间可能是几十秒。如果不处理角色会瞬间移动几十秒的距离直接飞出场景。处理方法是给deltaTime加一个上限// deltaTime 截断 let deltaTime clock.getDelta(); if (deltaTime 0.1) { deltaTime 0.1; }0.1 秒相当于 10 帧的时间即使卡顿也不会让角色移动太远。这个处理三个模型都没做是我实测中踩坑后加的。这个坑很隐蔽因为开发时很少切后台但玩家实际使用时切后台是高频操作。提示除了 deltaTime 截断还可以监听visibilitychange事件在页面隐藏时暂停游戏显示时恢复。这样体验更好但实现稍复杂。对于小游戏deltaTime 截断就够了。4.4 最终项目的性能表现整合后的项目我做了性能测试。在 RTX 4070 上1080p 分辨率下稳定 60 帧GPU 占用率约 15%。在集成显卡的笔记本上帧率在 45 到 60 之间波动GPU 占用率约 40%。这个性能对于浏览器 3D 游戏来说是可以接受的。性能瓶颈主要在光球的点光源上。每个光球一个点光源20 个点光源对 GPU 是不小的负担。我试过把点光源去掉只保留emissive发光帧率在集成显卡上能提升到稳定 60 帧但光球的发光感会弱一些。最终我保留了点光源因为视觉效果更重要而且目标用户的设备一般不会太差。如果要做进一步优化可以考虑用实例化渲染InstancedMesh来批量渲染光球或者用后处理的 bloom 效果来模拟发光减少实时光源数量。这些是后续可以扩展的方向。5. 常见问题排查与避坑经验实录5.1 模型生成代码的典型问题速查表在实测过程中我整理了三个模型生成代码时的高频问题做成速查表方便对照。问题现象可能原因排查方法解决方案角色移动一顿一顿用了固定步长而非 deltaTime检查移动代码是否乘了 deltaTime改用帧率无关插值高速移动穿过光球碰撞检测只看当前位置把速度调高测试加路径投影检测切后台回来角色瞬移deltaTime 未截断切后台 10 秒再切回加 deltaTime 上限计时不准用了 setInterval对比实际耗时改主循环累加场景太暗光照强度不足检查环境光和方向光强度环境光 0.6 方向光 0.8光球不显眼缺少发光效果检查材质 emissive加 emissive 和点光源树的位置每次刷新都变随机种子未固定刷新页面观察用固定种子伪随机代码越写越乱单文件堆砌看文件行数按职责拆模块这张表里的每一条都是我实际踩过的坑不是理论推测。比如切后台回来角色瞬移这条我是在测试时无意中切了下后台才发现的如果不做这个测试这个 bug 会一直留到用户手里。5.2 三个模型各自的脾气与应对用久了会发现每个模型都有自己的脾气了解这些能让你用得更顺手。Step 5 Preview 偏工程它会主动帮你做模块化、加注释、考虑扩展性。好处是代码结构好坏处是有时候会过度设计。比如我只要一个简单的距离判断它可能会给你封装成一个带配置项的碰撞系统。应对方法是需求描述里明确说保持简单不要过度封装。DeepSeek V4 Pro 偏数学它喜欢用严谨的数学表达代码里经常出现向量运算和矩阵推导。好处是精度高、边界情况处理好坏处是代码可读性对新手不友好。应对方法是如果看不懂它的数学可以让它用更直白的方式重写这段。GLM5.3 偏实用它的代码最接近能直接用的水平中文注释也最到位。好处是上手快坏处是有时候会在细节上偷懒比如计时用 setInterval。应对方法是关键模块要自己 review 一遍别完全信任。实操心得我现在的习惯是同一个需求先让三个模型各出一版然后对比着看。不是为了选一个而是为了看不同思路。有时候 A 模型的某个细节处理得妙B 模型的某个结构更合理整合起来比任何单一模型都好。这个三模型对照法虽然费点时间但产出质量明显更高。5.3 从能跑到好玩的最后一公里代码能跑起来只是第一步从能跑到好玩还有一段路。这段路模型帮不上太多忙得靠人来调。我实测发现模型生成的游戏在手感上普遍偏硬。具体表现是移动响应太直接没有缓冲收集反馈太弱没有音效和粒子难度曲线太平没有起伏。这些都需要手动调。我做的几个调整移动加了一点起步和停止的缓冲参考了 DeepSeek V4 Pro 的阻尼思路但只用了很小的阻尼系数保持轻快感。收集光球时加了一个缩放消失的动画用requestAnimationFrame做一个 0.2 秒的缩放比直接消失有反馈感。光球收集后 5 秒在随机位置重生保持场景里始终有 20 个光球避免后期没东西可收集。这些调整都不复杂但效果很明显。我让几个朋友试玩加了这些细节之后的版本他们的评价从能玩变成了有点意思。游戏开发的最后一公里往往就是这些细节决定的。5.4 关于 WorkBuddy 等工具链的延伸思考实测过程中我也在思考工具链的问题。现在市面上像 WorkBuddy 这类 AI 工作台工具越来越多它们把模型能力包装成了更易用的形态。对于不写代码的人来说这类工具确实降低了门槛。但对于要做 3D 游戏这种复杂项目的开发者来说直接调用模型 API 反而更灵活因为你可以控制每一个细节可以对比不同模型可以整合最优方案。WorkBuddy 这类工具的价值在于标准化流程比如它可能内置了代码审查、测试生成、文档编写等 skill。如果你做的是重复性较高的开发任务用这类工具能省不少事。但如果你做的是探索性的、需要反复对比和调优的项目直接和模型对话更合适。我的建议是把 WorkBuddy 这类工具当成加速器而不是替代品。它能帮你更快地完成已知任务但探索未知方案时还是得自己动手。这次三模型实测就是一次探索过程中学到的关于移动插值、碰撞检测、计时精度的知识是任何工具都给不了的。6. 实测结论与个人体会三个模型跑完这一轮我的整体感受是它们都能完成 3D 游戏的基础开发但各有各的性格。Step 5 Preview 像个靠谱的架构师代码结构最省心DeepSeek V4 Pro 像个严谨的数学家边界情况处理最到位GLM5.3 像个务实的工程师上手最快、中文理解最好。如果非要选一个综合最强我会选 Step 5 Preview因为它的工程结构在项目变大时优势最明显。但如果只做小项目GLM5.3 的性价比最高。DeepSeek V4 Pro 适合对物理精度要求高的场景比如模拟类游戏。最后分享一个我在这次实测中最大的体会模型生成的代码质量很大程度上取决于你的需求描述质量。我第一版需求描述写得比较随意三个模型的产出都偏通用。后来我把需求拆得更细明确了场景大小、角色速度范围、光球数量这些具体参数产出质量立刻上了一个台阶。所以与其纠结用哪个模型不如先把需求想清楚。需求描述里的每一个模糊点都会变成模型产出里的一个坑。 
长河君 · 2026/11/2 10:06:25 · 阅读 1.2k 三款AI编程助手实测：Step 5、DeepSeek V4 Pro、GLM5.3开发3D游戏对比
1. 三款模型同台竞技的背景与实测动机1.1 为什么我要做这次横向对比最近这段时间AI 编程助手这个赛道热闹得有点不像话。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字几乎同时出现在我的信息流里身边做开发的朋友分成三派各说各的好。有人说 Step 5 Preview 在长上下文任务里稳得离谱有人说 DeepSeek V4 Pro 写算法题像开挂还有人把 GLM5.3 吹成了国产代码模型天花板。听多了这种争论我反而起了逆反心理——与其看别人吵架不如自己动手做一次真实项目的横向实测。我选的项目是从零做一个 3D 游戏。为什么偏偏选 3D 游戏因为这类项目对模型的考验是全方位的它既需要数学功底向量、矩阵、四元数、碰撞检测又需要图形学知识渲染管线、光照模型、着色器还得有工程能力场景管理、资源加载、状态机最后还要能把这些东西组织成能跑起来的完整代码。一个模型如果只会写 LeetCode 风格的算法题在 3D 游戏这种综合性任务上会立刻露馅。这就像考驾照场地考满分不代表上路不熄火。这次实测我给自己定的规则很简单同一个需求描述分别喂给三个模型看谁产出的代码能最快跑起来、结构最合理、后续扩展最省心。需求我写得尽量克制不引导任何特定实现方式让模型自己发挥。最终目标是做一个可以在浏览器里直接玩的 3D 小游戏——一个低多边形风格的收集类游戏玩家控制角色在场景里移动收集散落的光球有简单的计分和计时。1.2 三个模型的基本盘与预期在动手之前我先梳理了一下三个模型的定位这有助于理解它们后续的表现差异。Step 5 Preview是阶跃星辰推出的预览版本主打长上下文和复杂推理。从公开信息看它在多轮对话和长文档理解上有明显优势这对 3D 游戏这种需要记住前面写了什么的任务很关键。我预期它在代码一致性和跨文件组织上会表现不错。DeepSeek V4 Pro是深度求索的旗舰版本代码能力一直是它的招牌。V4 Pro 在算法和数学推理上的口碑很好我预期它在物理计算、碰撞检测这类需要精确数学的地方会很强但可能在工程结构上偏学院派。GLM5.3是智谱的最新版本综合能力均衡中文理解尤其出色。我预期它在理解我的中文需求描述时最不容易跑偏代码风格可能偏实用主义。提示做模型横向对比时一定要先明确每个模型的定位和擅长领域否则很容易用苹果和橘子的方式得出错误结论。比如拿一个擅长算法的模型去比工程结构本身就不公平。1.3 实测环境的统一配置为了保证对比的公平性我把三个模型的运行环境尽量统一。测试机器是一台 32GB 内存、RTX 4070 显卡的工作站操作系统是 Ubuntu 22.04。三个模型都通过各自的 API 接口调用温度参数统一设为 0.3偏低减少随机性最大输出长度设为 8192 token。前端运行环境是 Chrome 120用 Vite 做本地开发服务器。这里有个细节值得说温度参数的选择对代码生成影响很大。我试过 0.7 的温度三个模型都会出现自由发挥的情况比如擅自引入我没要求的库或者把简单的实现复杂化。调到 0.3 之后输出明显收敛更贴近需求本身。如果你也在做类似的代码生成测试建议从 0.2 到 0.4 之间开始调。2. 需求拆解与三模型首轮产出对比2.1 我给出的需求描述原文为了让对比有据可查我把需求描述原文贴出来。这段描述我刻意写得像产品经理给开发提需求不涉及任何技术选型做一个 3D 收集类小游戏浏览器里能直接玩。玩家用 WASD 控制一个角色在平面上移动鼠标控制视角旋转。场景里随机散布 20 个发光的光球玩家靠近光球就能收集每收集一个加 10 分。游戏限时 60 秒时间到了显示总分。场景要有地面、几棵树或者柱子作为参照物光照要自然一点。角色移动要平滑不能一顿一顿的。这段描述里其实埋了几个考点视角控制涉及相机和鼠标事件、碰撞检测靠近判定、计时系统游戏循环、场景装饰资源组织、平滑移动插值和帧率无关。哪个模型能把这些点都照顾到基本就能看出它的综合能力。2.2 Step 5 Preview 的首轮产出分析Step 5 Preview 拿到需求后第一轮就给出了一个相当完整的方案。它选择了 Three.js 作为渲染引擎理由是浏览器 3D 场景的事实标准生态成熟。这个选择很务实没有为了炫技去用原生 WebGL。它的代码组织让我印象深刻主动拆成了五个模块——场景初始化、角色控制、光球管理、游戏状态、主循环。每个模块职责清晰模块之间通过一个简单的状态对象通信。这种结构不是需求里要求的是它自己判断这样更好维护才做的。我特意检查了模块间的依赖关系没有循环引用说明它在生成时是有全局规划的不是一段一段拼出来的。平滑移动这块它用了deltaTime做帧率无关的插值代码里明确写了position.lerp(targetPosition, 1 - Math.pow(0.001, deltaTime))。这个写法比简单的lerp(a, b, 0.1)要专业因为后者在不同帧率下移动速度会不一致。这个细节说明 Step 5 Preview 对游戏开发的常见坑是有认知的。不过它也有个小问题光球的碰撞检测用了简单的距离判断但没有考虑角色本身的半径。结果就是玩家要走到光球正中心才能收集手感偏硬。这个问题在三个模型里都出现了后面我会专门讲怎么修。2.3 DeepSeek V4 Pro 的首轮产出分析DeepSeek V4 Pro 的首轮产出走的是另一条路。它同样选了 Three.js但代码风格明显更数学化。角色移动部分它没有用简单的向量加法而是引入了速度向量和加速度的概念做了一套带阻尼的移动系统。代码里能看到velocity.multiplyScalar(damping)这样的写法物理感很强。碰撞检测是它的亮点。它没有用简单的距离判断而是写了一个球体与球体的精确碰撞函数还考虑了角色移动速度对检测的影响加了简单的防穿透处理。这段代码的数学严谨性明显高于另外两个模型注释里还推导了为什么用平方距离而不是开方距离性能优化。但它的工程结构就相对松散。所有代码几乎都堆在一个文件里虽然有注释分隔但没有模块化。我数了一下单文件超过了 600 行。对于一个小游戏来说能跑但如果要扩展成更复杂的项目这个结构会很快变成负担。这印证了我之前的预期DeepSeek V4 Pro 强在算法和数学弱在工程组织。还有个细节它的光照设置偏暗场景看起来有点阴天的感觉。需求里说了光照要自然一点它用了环境光加方向光但方向光强度给低了。这个不算错但说明它对自然的理解偏保守。2.4 GLM5.3 的首轮产出分析GLM5.3 的首轮产出是最接地气的。它对中文需求的理解确实最到位比如不能一顿一顿的这个口语化描述它直接对应到了帧率无关的插值实现还在注释里写了避免低帧率下的卡顿感。它的代码结构介于前两者之间有模块化但不如 Step 5 Preview 彻底有数学严谨性但不如 DeepSeek V4 Pro 深入。它把代码分成了三个文件——主逻辑、工具函数、配置常量。配置常量单独抽出来这个做法很实用因为游戏参数比如移动速度、光球数量、时限经常要调抽出来之后改起来方便。GLM5.3 最让我惊喜的是它对场景装饰的处理。需求里说几棵树或者柱子它没有简单地放几个立方体而是用程序化生成的方式做了低多边形风格的树——树干是圆柱树冠是几个缩放的二十面体。这个细节让场景看起来明显比另外两个模型更有游戏感。而且它把树的生成封装成了函数可以传参数控制树的密度和大小扩展性很好。它的短板在计时系统。它用了setInterval来做倒计时而不是在游戏主循环里累加deltaTime。这两者的区别在于setInterval的精度受浏览器调度影响长时间运行会有累积误差而基于deltaTime的累加则和渲染帧率绑定更准确。这个小问题在 60 秒的游戏里影响不大但如果是长时间运行的游戏就会暴露。2.5 首轮产出对比速查表对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3渲染引擎选择Three.jsThree.jsThree.js代码模块化五模块最彻底单文件最松散三文件居中移动平滑处理帧率无关插值速度阻尼物理帧率无关插值碰撞检测精度简单距离精确球体碰撞简单距离场景装饰基础几何体基础几何体程序化低多边形树计时系统主循环累加主循环累加setInterval中文需求理解良好良好最佳首轮可运行性直接可跑直接可跑直接可跑这张表是我实测后整理的不是模型自己说的。从表里能看出三个模型都能完成基本任务但各有侧重。没有哪个模型是全面碾压的选哪个取决于你更看重什么。3. 核心环节的深度实测与代码剖析3.1 角色移动系统三种实现思路的取舍角色移动是 3D 游戏的手感基础这块我花了最多时间对比。三个模型的实现思路差异很大值得逐个拆解。Step 5 Preview 用的是目标位置插值法。每一帧根据输入计算出一个目标位置然后让角色当前位置向目标位置插值。核心代码大概是这样// Step 5 Preview 的移动实现 const targetPos currentPos.clone().add(moveDirection.multiplyScalar(speed * deltaTime)); mesh.position.lerp(targetPos, 1 - Math.pow(0.001, deltaTime));这个写法的好处是移动非常平滑而且天然帧率无关。1 - Math.pow(0.001, deltaTime)这个系数是经过推导的保证在不同帧率下每秒的插值进度一致。缺点是角色永远追不上目标位置会有一个微小的延迟感。对于收集类游戏来说这个延迟可以接受但如果是格斗游戏就会影响操作精度。DeepSeek V4 Pro 用的是速度阻尼法。它维护一个速度向量输入改变的是加速度速度再积分成位置同时速度每帧乘以一个阻尼系数。代码大概是这样// DeepSeek V4 Pro 的移动实现 velocity.addScaledVector(acceleration, deltaTime); velocity.multiplyScalar(Math.pow(damping, deltaTime)); mesh.position.addScaledVector(velocity, deltaTime);这个写法物理感最强角色有惯性起步和停止都有加速减速过程手感偏重。适合模拟真实物理但对于一个轻松的收集游戏来说有点用力过猛。而且阻尼系数的调参比较敏感调不好角色会像在冰面上滑。GLM5.3 用的是直接位移法加平滑。它先直接算出位移然后对位移做一个平滑处理// GLM5.3 的移动实现 const displacement moveDirection.multiplyScalar(speed * deltaTime); const smoothed displacement.clone().multiplyScalar(smoothingFactor); mesh.position.add(smoothed);这个写法最简单直接手感介于前两者之间。smoothingFactor是一个 0 到 1 之间的常数调起来直观。缺点是它其实不是严格帧率无关的smoothingFactor固定的话高帧率下平滑效果会减弱。不过在实际测试中60 帧和 120 帧的差异肉眼几乎看不出来。实操心得如果你要做的是休闲游戏GLM5.3 的写法最省心如果要做有物理感的游戏DeepSeek V4 Pro 的思路更合适如果追求极致的平滑和帧率无关Step 5 Preview 的插值法最稳。我最后在项目里用的是 Step 5 Preview 的方案因为收集类游戏对操作精度要求不高平滑优先。3.2 碰撞检测从能跑到手感好的关键碰撞检测这块三个模型的差距在首轮就体现出来了但真正的问题是在实测中才暴露的。前面说过Step 5 Preview 和 GLM5.3 都用了简单的距离判断DeepSeek V4 Pro 用了精确球体碰撞。听起来 DeepSeek 更好但实际测试下来问题不在精度而在判定半径。简单距离判断的代码是这样的// 简单距离判断 const dist player.position.distanceTo(orb.position); if (dist collectRadius) { collectOrb(orb); }这里collectRadius如果设成光球的半径那玩家必须走到光球正中心才能收集手感很硬。如果设成光球半径加玩家半径手感就自然多了。三个模型里只有 DeepSeek V4 Pro 在代码注释里提到了这一点另外两个都需要手动调。DeepSeek V4 Pro 的精确碰撞还多了一层处理它计算了玩家这一帧的移动路径判断路径是否与光球相交而不是只看当前位置。这解决了高速移动时穿透光球的问题。代码大概是这样// DeepSeek V4 Pro 的防穿透检测 const movement player.position.clone().sub(player.prevPosition); const toOrb orb.position.clone().sub(player.prevPosition); const t toOrb.dot(movement) / movement.lengthSq(); const clampedT Math.max(0, Math.min(1, t)); const closestPoint player.prevPosition.clone().add(movement.multiplyScalar(clampedT)); if (closestPoint.distanceTo(orb.position) collectRadius) { collectOrb(orb); }这段代码的数学是投影几何把玩家移动路径投影到光球方向找到路径上离光球最近的点再判断距离。这个处理在玩家移动速度很快时特别有用。我实测把玩家速度调到很高Step 5 Preview 和 GLM5.3 都会出现穿过光球但没收集的情况DeepSeek V4 Pro 则稳定收集。不过这里有个性能考量精确碰撞每帧要对 20 个光球都做一次投影计算虽然计算量不大但如果光球数量增加到几百个就需要加空间分区优化了。对于 20 个光球的小游戏这个开销可以忽略。3.3 场景装饰程序化生成 vs 手工摆放场景装饰这块GLM5.3 的程序化生成思路明显胜出。我详细看了它的实现值得展开讲。它的树生成函数大概是这样// GLM5.3 的程序化树生成 function createTree(x, z, scale) { const tree new THREE.Group(); const trunkGeo new THREE.CylinderGeometry(0.2 * scale, 0.3 * scale, 2 * scale, 6); const trunkMat new THREE.MeshStandardMaterial({ color: 0x8B4513 }); const trunk new THREE.Mesh(trunkGeo, trunkMat); trunk.position.y 1 * scale; tree.add(trunk); const crownGeo new THREE.IcosahedronGeometry(1 * scale, 0); const crownMat new THREE.MeshStandardMaterial({ color: 0x228B22, flatShading: true }); const crown new THREE.Mesh(crownGeo, crownMat); crown.position.y 2.5 * scale; tree.add(crown); tree.position.set(x, 0, z); return tree; }这里有几个细节值得说。圆柱的径向分段设为 6这是低多边形风格的关键分段太多就变成高模了失去风格感。二十面体的 detail 设为 0也是同样的道理。flatShading: true让树冠有棱有角强化低多边形风格。这些参数选择说明 GLM5.3 对低多边形美学是有理解的不是随便填的数。Step 5 Preview 和 DeepSeek V4 Pro 都是手工摆放几个立方体或圆柱虽然也能用但场景看起来比较空缺乏游戏感。我后来把 GLM5.3 的树生成函数移植到了最终项目里稍微改了下参数效果很好。注意程序化生成虽然好但要注意随机种子的控制。如果每次刷新页面树的位置都变玩家会失去空间记忆。我在最终项目里用了固定种子的伪随机函数保证每次生成的场景一致。3.4 计时系统一个容易被忽视的精度问题计时系统看起来简单但三个模型的实现差异暴露了一个常见误区。Step 5 Preview 和 DeepSeek V4 Pro 都在主循环里累加deltaTime// 主循环累加计时 let elapsed 0; function animate() { const deltaTime clock.getDelta(); elapsed deltaTime; if (elapsed 60) { endGame(); } // ... 渲染逻辑 }GLM5.3 用了setInterval// setInterval 计时 let remaining 60; const timer setInterval(() { remaining - 1; if (remaining 0) { clearInterval(timer); endGame(); } }, 1000);两者的区别在长时间运行时会显现。setInterval的 1000 毫秒是至少 1000 毫秒浏览器在繁忙时可能延迟到 1010 甚至 1020 毫秒累积下来 60 秒的计时可能实际过了 62 秒。而主循环累加deltaTime是和渲染帧绑定的虽然也有误差但不会累积得那么快。我实测跑了几次setInterval版本的 60 秒实际耗时在 60.5 到 61.2 秒之间波动主循环版本在 60.1 到 60.3 秒之间。对于休闲游戏这个差异可以接受但如果做的是竞速游戏这个误差就会影响公平性。还有个细节页面切到后台时浏览器的setInterval会被节流可能变成每秒只执行一次甚至更慢。而requestAnimationFrame驱动的游戏主循环在后台会暂停切回来时deltaTime会是一个很大的值需要做上限截断否则角色会瞬移。这个坑我在实测中踩到了后面会讲怎么处理。4. 整合优化与最终项目落地4.1 取长补短的整合策略三个模型各有优劣我的最终项目没有直接用任何一个的完整产出而是做了一次取长补短的整合。具体策略是移动系统用 Step 5 Preview 的帧率无关插值因为收集类游戏平滑优先。碰撞检测用 DeepSeek V4 Pro 的精确球体碰撞加防穿透但把判定半径改成了玩家半径加光球半径。场景装饰用 GLM5.3 的程序化树生成加了固定随机种子。计时系统用主循环累加deltaTime并加了后台切换的deltaTime截断。代码结构用 Step 5 Preview 的五模块划分但把配置常量单独抽出来参考了 GLM5.3 的做法。这个整合过程本身就是一次学习。我发现模型生成的代码更像是草稿真正能用的代码需要人来判断和整合。每个模型都有自己的偏见——Step 5 Preview 偏工程DeepSeek V4 Pro 偏数学GLM5.3 偏实用。人的价值在于知道什么场景该用什么。4.2 关键参数的计算与调优过程整合过程中有几个参数需要计算和调优我把过程记录下来。移动速度需求里没给具体数值我根据游戏体验反推。场景大小是 40x40 单位玩家从中心走到边缘需要 20 单位。我希望这个时间在 3 秒左右所以速度设为 20/3 约等于 6.7 单位每秒。实测下来 6.7 稍快调到 6.0 手感最好。收集半径玩家角色半径 0.5光球半径 0.3。如果判定半径设为 0.8两者之和玩家边缘碰到光球边缘就算收集手感自然。如果设为 0.3就要走到光球中心太硬。最终用 0.8。光球数量与分布需求说 20 个。我实测发现 20 个在 40x40 的场景里密度适中玩家平均每 3 秒能收集一个60 秒理论上能收集 20 个。但实际因为要跑动一般能收集 12 到 15 个。这个难度曲线我觉得合适不会太简单也不会太挫败。光照参数环境光强度 0.6方向光强度 0.8方向光位置在 (10, 20, 10)。这个组合下场景明亮但不刺眼阴影柔和。我试过环境光 0.8 加方向光 1.0太亮光球的光晕都看不清了。光球发光效果用MeshStandardMaterial的emissive属性颜色设为青色强度 0.5。再加一个点光源在光球位置强度 1.0距离 3。这样光球在场景里很显眼玩家一眼就能看到。4.3 后台切换的 deltaTime 截断处理前面提到的后台切换坑我详细讲下怎么处理。当页面切到后台requestAnimationFrame会暂停。切回来时clock.getDelta()返回的是从上次暂停到现在的总时间可能是几十秒。如果不处理角色会瞬间移动几十秒的距离直接飞出场景。处理方法是给deltaTime加一个上限// deltaTime 截断 let deltaTime clock.getDelta(); if (deltaTime 0.1) { deltaTime 0.1; }0.1 秒相当于 10 帧的时间即使卡顿也不会让角色移动太远。这个处理三个模型都没做是我实测中踩坑后加的。这个坑很隐蔽因为开发时很少切后台但玩家实际使用时切后台是高频操作。提示除了 deltaTime 截断还可以监听visibilitychange事件在页面隐藏时暂停游戏显示时恢复。这样体验更好但实现稍复杂。对于小游戏deltaTime 截断就够了。4.4 最终项目的性能表现整合后的项目我做了性能测试。在 RTX 4070 上1080p 分辨率下稳定 60 帧GPU 占用率约 15%。在集成显卡的笔记本上帧率在 45 到 60 之间波动GPU 占用率约 40%。这个性能对于浏览器 3D 游戏来说是可以接受的。性能瓶颈主要在光球的点光源上。每个光球一个点光源20 个点光源对 GPU 是不小的负担。我试过把点光源去掉只保留emissive发光帧率在集成显卡上能提升到稳定 60 帧但光球的发光感会弱一些。最终我保留了点光源因为视觉效果更重要而且目标用户的设备一般不会太差。如果要做进一步优化可以考虑用实例化渲染InstancedMesh来批量渲染光球或者用后处理的 bloom 效果来模拟发光减少实时光源数量。这些是后续可以扩展的方向。5. 常见问题排查与避坑经验实录5.1 模型生成代码的典型问题速查表在实测过程中我整理了三个模型生成代码时的高频问题做成速查表方便对照。问题现象可能原因排查方法解决方案角色移动一顿一顿用了固定步长而非 deltaTime检查移动代码是否乘了 deltaTime改用帧率无关插值高速移动穿过光球碰撞检测只看当前位置把速度调高测试加路径投影检测切后台回来角色瞬移deltaTime 未截断切后台 10 秒再切回加 deltaTime 上限计时不准用了 setInterval对比实际耗时改主循环累加场景太暗光照强度不足检查环境光和方向光强度环境光 0.6 方向光 0.8光球不显眼缺少发光效果检查材质 emissive加 emissive 和点光源树的位置每次刷新都变随机种子未固定刷新页面观察用固定种子伪随机代码越写越乱单文件堆砌看文件行数按职责拆模块这张表里的每一条都是我实际踩过的坑不是理论推测。比如切后台回来角色瞬移这条我是在测试时无意中切了下后台才发现的如果不做这个测试这个 bug 会一直留到用户手里。5.2 三个模型各自的脾气与应对用久了会发现每个模型都有自己的脾气了解这些能让你用得更顺手。Step 5 Preview 偏工程它会主动帮你做模块化、加注释、考虑扩展性。好处是代码结构好坏处是有时候会过度设计。比如我只要一个简单的距离判断它可能会给你封装成一个带配置项的碰撞系统。应对方法是需求描述里明确说保持简单不要过度封装。DeepSeek V4 Pro 偏数学它喜欢用严谨的数学表达代码里经常出现向量运算和矩阵推导。好处是精度高、边界情况处理好坏处是代码可读性对新手不友好。应对方法是如果看不懂它的数学可以让它用更直白的方式重写这段。GLM5.3 偏实用它的代码最接近能直接用的水平中文注释也最到位。好处是上手快坏处是有时候会在细节上偷懒比如计时用 setInterval。应对方法是关键模块要自己 review 一遍别完全信任。实操心得我现在的习惯是同一个需求先让三个模型各出一版然后对比着看。不是为了选一个而是为了看不同思路。有时候 A 模型的某个细节处理得妙B 模型的某个结构更合理整合起来比任何单一模型都好。这个三模型对照法虽然费点时间但产出质量明显更高。5.3 从能跑到好玩的最后一公里代码能跑起来只是第一步从能跑到好玩还有一段路。这段路模型帮不上太多忙得靠人来调。我实测发现模型生成的游戏在手感上普遍偏硬。具体表现是移动响应太直接没有缓冲收集反馈太弱没有音效和粒子难度曲线太平没有起伏。这些都需要手动调。我做的几个调整移动加了一点起步和停止的缓冲参考了 DeepSeek V4 Pro 的阻尼思路但只用了很小的阻尼系数保持轻快感。收集光球时加了一个缩放消失的动画用requestAnimationFrame做一个 0.2 秒的缩放比直接消失有反馈感。光球收集后 5 秒在随机位置重生保持场景里始终有 20 个光球避免后期没东西可收集。这些调整都不复杂但效果很明显。我让几个朋友试玩加了这些细节之后的版本他们的评价从能玩变成了有点意思。游戏开发的最后一公里往往就是这些细节决定的。5.4 关于 WorkBuddy 等工具链的延伸思考实测过程中我也在思考工具链的问题。现在市面上像 WorkBuddy 这类 AI 工作台工具越来越多它们把模型能力包装成了更易用的形态。对于不写代码的人来说这类工具确实降低了门槛。但对于要做 3D 游戏这种复杂项目的开发者来说直接调用模型 API 反而更灵活因为你可以控制每一个细节可以对比不同模型可以整合最优方案。WorkBuddy 这类工具的价值在于标准化流程比如它可能内置了代码审查、测试生成、文档编写等 skill。如果你做的是重复性较高的开发任务用这类工具能省不少事。但如果你做的是探索性的、需要反复对比和调优的项目直接和模型对话更合适。我的建议是把 WorkBuddy 这类工具当成加速器而不是替代品。它能帮你更快地完成已知任务但探索未知方案时还是得自己动手。这次三模型实测就是一次探索过程中学到的关于移动插值、碰撞检测、计时精度的知识是任何工具都给不了的。6. 实测结论与个人体会三个模型跑完这一轮我的整体感受是它们都能完成 3D 游戏的基础开发但各有各的性格。Step 5 Preview 像个靠谱的架构师代码结构最省心DeepSeek V4 Pro 像个严谨的数学家边界情况处理最到位GLM5.3 像个务实的工程师上手最快、中文理解最好。如果非要选一个综合最强我会选 Step 5 Preview因为它的工程结构在项目变大时优势最明显。但如果只做小项目GLM5.3 的性价比最高。DeepSeek V4 Pro 适合对物理精度要求高的场景比如模拟类游戏。最后分享一个我在这次实测中最大的体会模型生成的代码质量很大程度上取决于你的需求描述质量。我第一版需求描述写得比较随意三个模型的产出都偏通用。后来我把需求拆得更细明确了场景大小、角色速度范围、光球数量这些具体参数产出质量立刻上了一个台阶。所以与其纠结用哪个模型不如先把需求想清楚。需求描述里的每一个模糊点都会变成模型产出里的一个坑。