1. 三款模型同台竞技的背景与实测动机1.1 为什么要做这个对比测试最近这段时间AI 编程助手这个赛道热闹得有点不像话。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字几乎同时出现在我的信息流里身边做开发的朋友也在群里反复讨论到底哪个更能打。光看官方放出来的 benchmark 数据说实话已经很难分辨高下了——各家都说自己在代码生成、逻辑推理、长上下文理解上有了质的飞跃但真正落到一个完整的、有交互、有渲染、有状态管理的 3D 游戏项目上谁能在实际工程中少让我擦屁股这才是硬指标。我决定做这个实测核心动机很简单用同一个需求、同一套评判标准让三个模型各自从零开始构建一个可运行的 3D 游戏。不是那种跑个 demo 就完事的玩具而是包含场景搭建、角色控制、碰撞检测、UI 交互、状态管理这些真实游戏开发环节的完整项目。这样测出来的结果比任何跑分都更有说服力。另外还有一个很现实的原因——我平时用 WorkBuddy 做工作流管理它支持接入不同的模型后端。如果我能搞清楚这三个模型在 3D 游戏开发这个具体场景下的真实表现后续在 WorkBuddy 里配置模型路由策略时就有据可依了。毕竟不是所有任务都需要最贵的模型把合适的任务分配给合适的模型这才是工程化的思路。1.2 三个模型的基本盘在正式开测之前先简单交代一下三个选手的基本情况方便你理解后面的对比结果。Step 5 Preview是阶跃星辰推出的最新预览版模型主打代码生成和复杂推理。从官方释放的信息来看它在多轮对话中的上下文保持能力有显著提升这对游戏开发这种需要反复迭代修改的场景来说是个关键能力。Preview 版本意味着它还在快速迭代中可能会有些不太稳定的地方但也可能藏着最新的优化。DeepSeek V4 Pro是深度求索的旗舰版本在代码社区的口碑一直不错。V4 Pro 相比前代在推理深度和代码结构理解上有明显加强尤其是在处理大型项目文件时能更好地维持代码风格的一致性。它的强项在于对复杂逻辑的拆解能力这在游戏开发中做状态机和碰撞检测时特别重要。GLM5.3是智谱的最新版本这个版本在工具调用和结构化输出上做了不少优化。GLM 系列一直以中文理解见长但在代码生成方面5.3 版本据说有了跨越式的进步。它的特点是生成的代码注释比较充分对新手友好但在极致性能优化上可能不如前两者激进。提示这三个模型都可以通过 API 接入 WorkBuddy 使用。如果你在 WorkBuddy 里配置了多个模型后端可以通过自定义指令让不同任务路由到不同模型。具体配置方法后面会详细说。1.3 测试项目的统一需求定义为了保证公平我给三个模型下达了完全相同的需求描述。需求文档我反复打磨了三遍确保没有歧义也没有隐含的提示偏向某个模型。核心需求如下使用 Three.js 构建一个 3D 场景包含地面、若干障碍物、一个可控制的角色角色支持 WASD 键盘控制移动鼠标控制视角旋转实现基础的碰撞检测角色不能穿过障碍物场景中放置若干可收集物品收集后 UI 显示计数包含一个简单的计时器显示游戏进行时间代码需要模块化组织至少分为场景管理、角色控制、碰撞检测、UI 管理四个模块提供完整的 HTML 入口文件和必要的构建配置这个需求覆盖了 3D 游戏开发的核心环节但又不会复杂到让模型无法在单次对话中完成。每个模型我都给了相同的对话轮次预算——最多 5 轮交互每轮可以提出修改意见但不会帮模型写代码。2. 三个模型的代码生成过程拆解2.1 Step 5 Preview 的首轮输出分析Step 5 Preview 的首轮响应速度是最快的大概 12 秒左右就吐出了完整代码。它一上来就给出了一个相当完整的项目结构文件划分很清晰src/ main.js scene/ SceneManager.js Environment.js player/ PlayerController.js InputHandler.js physics/ CollisionDetector.js ui/ HUD.js items/ CollectibleManager.js这个结构比我预期的还要细致它甚至把环境搭建和场景管理拆开了。从工程角度看这种拆分是合理的——环境负责静态的地面、光照、天空盒场景管理负责动态对象的增删和渲染循环。但这也意味着文件数量多了模块间的依赖关系需要更小心地维护。Step 5 Preview 生成的代码有一个很明显的特征它大量使用了 ES6 的 class 语法并且每个类都有清晰的构造函数和生命周期方法。比如 SceneManager 类里有init()、update()、dispose()三个标准方法这种设计模式在游戏开发中很常见说明模型对游戏引擎的架构模式有比较好的理解。不过首轮输出也有几个问题。第一它在 PlayerController 里直接引用了 CollisionDetector 的实例但没有处理循环依赖的问题。第二它的碰撞检测用的是简单的 AABB 包围盒对于角色移动来说够用但如果场景中有旋转的障碍物就会出问题。第三UI 模块的样式是内联在 JS 里的没有分离出 CSS 文件后期维护会有点麻烦。2.2 DeepSeek V4 Pro 的代码风格与架构选择DeepSeek V4 Pro 的响应速度稍慢一些大概 18 秒但它的输出质量让我眼前一亮。它没有像 Step 5 Preview 那样把文件拆得很细而是采用了更务实的组织方式src/ index.js core/ Game.js Loop.js entities/ Player.js Obstacle.js Collectible.js systems/ InputSystem.js PhysicsSystem.js RenderSystem.js ui/ HUD.js这个结构的关键差异在于DeepSeek V4 Pro 引入了 ECS实体-组件-系统的简化思想。它把 Player、Obstacle、Collectible 都归为 entities把输入、物理、渲染归为 systems。虽然它没有实现完整的 ECS 框架但这种分类方式让代码的可扩展性好了很多。如果后续要加新的游戏对象只需要在 entities 里加一个类在 systems 里注册对应的处理逻辑就行。DeepSeek V4 Pro 生成的代码还有一个亮点它在 PhysicsSystem 里实现了一个简单的空间哈希网格来做碰撞检测的粗筛。这个优化对于障碍物数量较多的场景很有用能把碰撞检测的复杂度从 O(n²) 降到接近 O(n)。虽然对于这个测试项目来说有点杀鸡用牛刀但说明模型在生成代码时会考虑性能问题而不是只求功能跑通。不过 DeepSeek V4 Pro 也有它的问题。它的代码注释比较少有些关键逻辑需要仔细读才能理解意图。比如它在处理角色移动时把速度向量和输入向量做了归一化处理但没有注释说明为什么要这样做。对于不熟悉向量运算的开发者来说可能会看得一头雾水。2.3 GLM5.3 的实现路径与特色处理GLM5.3 的响应速度介于两者之间大概 15 秒。它的代码组织方式又不一样更偏向于功能模块的扁平化组织src/ main.js game.js controls.js collision.js items.js ui.js utils.js这种组织方式的好处是直观每个文件对应一个明确的功能域找代码的时候不需要在多层目录里翻。但缺点是当项目变大时单个文件会变得很长。GLM5.3 生成的game.js就有 400 多行包含了场景初始化、渲染循环、状态管理等多个职责。GLM5.3 最让我惊喜的地方是它的代码注释非常充分而且是用中文写的。每个函数上面都有 JSDoc 风格的注释说明了参数含义和返回值。关键算法步骤也有行内注释比如在碰撞检测部分它详细解释了为什么用射线检测而不是包围盒检测——因为射线检测能更准确地判断角色是否真的碰到了障碍物表面而不是碰到包围盒就触发碰撞。但 GLM5.3 在性能优化上确实保守一些。它的碰撞检测是每帧对所有障碍物做遍历没有做任何空间划分。在障碍物数量少的时候没问题但如果场景复杂起来帧率会明显下降。另外它的 UI 更新是每帧都重新设置 DOM 元素的 textContent没有做脏检查虽然现代浏览器对这种操作优化得不错但终究不是最佳实践。2.4 首轮输出的横向对比把三个模型的首轮输出放在一起看差异就很明显了对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3响应速度最快约12秒最慢约18秒中等约15秒文件组织细粒度多文件ECS风格分层扁平化功能模块代码注释中等英文为主较少关键处有充分中文注释性能意识一般强有空间优化保守先求正确可扩展性好但依赖管理需注意最好ECS思想一般文件会膨胀首轮可运行性直接可跑需微调依赖注入直接可跑这个对比结果其实挺有意思的。Step 5 Preview 胜在速度和结构DeepSeek V4 Pro 胜在架构和性能意识GLM5.3 胜在可读性和注释。没有哪个模型是全面碾压的选择哪个更多取决于你的项目阶段和个人偏好。3. 实际运行中的问题与迭代修复3.1 Step 5 Preview 的循环依赖修复Step 5 Preview 生成的代码虽然首轮就能跑起来但当我尝试在 PlayerController 里调用 CollisionDetector 的方法时控制台报了一个Cannot access CollisionDetector before initialization的错误。这是典型的循环依赖问题——PlayerController 引用了 CollisionDetector而 CollisionDetector 又引用了 PlayerController 来获取角色位置。我在第二轮对话里把这个错误贴给了 Step 5 Preview它的修复方案很干脆引入一个事件总线EventBus来解耦两个模块。PlayerController 不再直接持有 CollisionDetector 的引用而是通过 EventBus 发布位置更新事件CollisionDetector 订阅这个事件来获取最新位置。// EventBus.js class EventBus { constructor() { this.listeners {}; } on(event, callback) { if (!this.listeners[event]) this.listeners[event] []; this.listeners[event].push(callback); } emit(event, data) { if (this.listeners[event]) { this.listeners[event].forEach(cb cb(data)); } } }这个修复方案很优雅不仅解决了循环依赖还让模块间的通信更加清晰。但 Step 5 Preview 在修复时没有提醒我EventBus 的实例需要在所有模块之间共享导致我一开始在每个模块里都 new 了一个 EventBus事件根本传不过去。这个坑我后面会详细说怎么避免。3.2 DeepSeek V4 Pro 的依赖注入调整DeepSeek V4 Pro 的首轮代码在运行时报了一个Game is not a constructor的错误。排查后发现它在index.js里用了import Game from ./core/Game.js但在Game.js里用的是命名导出export class Game没有默认导出。这是一个很常见的模块导入导出不匹配问题。我把错误信息反馈给 DeepSeek V4 Pro 后它没有简单地改成默认导出而是重新设计了模块的导出策略。它把所有核心类都改成命名导出然后在index.js里用命名导入import { Game } from ./core/Game.js; import { Loop } from ./core/Loop.js;同时它还在Game.js里加了一个静态工厂方法Game.create()把依赖注入的逻辑集中管理static create(canvas) { const loop new Loop(); const input new InputSystem(); const physics new PhysicsSystem(); const render new RenderSystem(canvas); return new Game(loop, input, physics, render); }这个改动让整个项目的依赖关系变得非常清晰所有系统实例都在一个地方创建和组装后续要替换某个系统的实现也很方便。DeepSeek V4 Pro 在修复问题时展现出的架构思维确实比另外两个模型更胜一筹。3.3 GLM5.3 的性能优化迭代GLM5.3 的首轮代码功能完全正常但我在场景里放了 50 个障碍物之后帧率从 60fps 掉到了 35fps 左右。用 Chrome 的 Performance 面板分析后发现瓶颈在碰撞检测的遍历上——每帧要对 50 个障碍物做射线检测每个障碍物又要检测 6 个面总共 300 次射线检测确实有点吃力。我把性能分析结果发给 GLM5.3它在第三轮给出了优化方案先用包围盒做粗筛只对包围盒相交的障碍物做精确的射线检测。这个两级检测策略把射线检测的次数从 300 次降到了平均 20 次左右帧率回到了 58-60fps。// 粗筛包围盒检测 const playerBox new THREE.Box3().setFromObject(player.mesh); for (const obstacle of obstacles) { if (!playerBox.intersectsBox(obstacle.boundingBox)) continue; // 精筛射线检测 const hit this.raycastCheck(player, obstacle); if (hit) return hit; }GLM5.3 在优化时还加了一段注释解释了为什么选择包围盒而不是球体做粗筛——因为障碍物大多是长方体包围盒的贴合度更高误判率更低。这种细节说明它在生成代码时确实在思考而不是机械地套模板。3.4 三个模型的迭代效率对比从发现问题到修复完成三个模型的表现如下模型首轮问题数修复轮次修复后稳定性迭代体验Step 5 Preview2个循环依赖、EventBus实例2轮稳定响应快修复方案优雅DeepSeek V4 Pro1个导入导出不匹配1轮非常稳定修复时顺带优化架构GLM5.31个性能瓶颈1轮稳定优化方案有详细解释Step 5 Preview 虽然首轮问题最多但它的修复速度最快而且给出的 EventBus 方案确实解决了根本问题。DeepSeek V4 Pro 的问题最少修复时还顺手提升了代码质量。GLM5.3 的问题最具体优化方案也最有教育意义。4. WorkBuddy 在多模型协作中的实战配置4.1 为什么要在 WorkBuddy 里配置多模型做完这个实测之后我最大的感受是没有哪个模型是万能的但如果你能把它们组合起来用效果会好很多。Step 5 Preview 适合快速出原型DeepSeek V4 Pro 适合做架构设计和性能优化GLM5.3 适合写注释和文档。如果能在 WorkBuddy 里根据任务类型自动路由到不同的模型开发效率会有明显提升。WorkBuddy 本身是一个工作流管理工具它的核心能力是把复杂的开发任务拆解成多个步骤每个步骤可以配置不同的执行策略。它支持接入多种模型后端你可以给每个步骤指定用哪个模型。比如“生成项目骨架”这个步骤用 Step 5 Preview“优化碰撞检测”这个步骤用 DeepSeek V4 Pro“补充代码注释”这个步骤用 GLM5.3。4.2 WorkBuddy 的安装与基础配置WorkBuddy 的安装过程不复杂但有几个细节需要注意。首先它支持 Windows、macOS 和 LinuxWindows 7 也能跑但官方建议 Windows 10 以上。安装包在官网就能下载安装时建议把系统缓存目录改到 D 盘因为默认的 C 盘缓存目录在长时间使用后会积累大量临时文件可能影响系统盘性能。安装完成后第一件事是配置模型后端。在 WorkBuddy 的设置里找到“模型管理”添加你的 API 密钥。每个模型后端需要配置以下信息模型名称用于在 WorkBuddy 里识别API 端点地址API 密钥默认参数温度、最大 token 数等注意WorkBuddy 的模型配置支持自定义指令。你可以给每个模型设置专属的系统提示词比如给 GLM5.3 设置“生成代码时请附带详细的中文注释”这样每次调用它都会自动带上这个要求。4.3 给 WorkBuddy 定规则让多模型协作自动化WorkBuddy 最强大的功能之一是自定义指令和规则系统。你可以定义一套规则让 WorkBuddy 根据任务类型自动选择合适的模型。比如我设置了这样几条规则当任务涉及“生成新文件”或“创建项目结构”时路由到 Step 5 Preview当任务涉及“重构”或“性能优化”时路由到 DeepSeek V4 Pro当任务涉及“添加注释”或“写文档”时路由到 GLM5.3当任务涉及“调试”时先让 Step 5 Preview 快速定位再让 DeepSeek V4 Pro 深入分析这些规则在 WorkBuddy 的“自定义指令”面板里配置语法很简单基本上就是“如果任务包含关键词 X则使用模型 Y”这样的逻辑。配置好之后后续所有任务都会自动按照规则执行不需要每次手动切换模型。4.4 WorkBuddy 的 Skill 系统与跨对话记忆WorkBuddy 的 Skill 系统是我觉得最实用的功能之一。你可以把常用的操作封装成 Skill比如“创建一个 Three.js 项目骨架”可以做成一个 Skill“运行碰撞检测性能测试”可以做成另一个 Skill。每个 Skill 可以指定用哪个模型来执行。跨对话记忆 Skill 则解决了多轮对话中上下文丢失的问题。在开发 3D 游戏的过程中我经常需要在不同的对话里讨论不同的模块。跨对话记忆 Skill 会把关键决策和代码片段持久化存储当我在新对话里提到“之前那个碰撞检测方案”时它能自动关联到之前的上下文。提示WorkBuddy 的跨对话记忆默认存储在本地如果你在多个设备上工作需要手动同步记忆文件。记忆文件的位置可以在设置里查看建议定期备份。4.5 私有化部署与安全审核如果你在团队里使用 WorkBuddy可能会考虑私有化部署。WorkBuddy 支持 Docker 部署官方提供了 Docker 镜像。部署时需要配置好模型后端的网络连通性如果模型 API 在内网需要确保 Docker 容器能访问到。WorkBuddy 的安全审核功能也值得一说。它会自动检查生成的代码中是否包含敏感信息或危险操作比如硬编码的密钥、不安全的文件操作等。在团队协作场景下这个功能能避免很多低级错误。安全审核的规则可以自定义你可以根据团队的规范添加额外的检查项。5. 3D 游戏开发中的模型选型经验总结5.1 什么任务适合什么模型经过这次完整的实测我对三个模型的适用场景有了比较清晰的认识。下面这张表是我根据实际体验整理的选型建议任务类型推荐模型理由快速原型搭建Step 5 Preview响应快结构清晰能快速跑通架构设计与重构DeepSeek V4 Pro架构思维强会主动考虑扩展性性能优化DeepSeek V4 Pro有性能意识能给出量化优化方案代码注释与文档GLM5.3中文注释充分解释清晰调试与错误修复Step 5 Preview定位快修复方案直接有效复杂算法实现DeepSeek V4 Pro逻辑拆解能力强边界情况考虑周全新手友好型代码GLM5.3注释多可读性好适合学习这个选型不是绝对的只是一个基于我实际体验的参考。你的项目特点不同最优选择可能也不一样。关键是要理解每个模型的强项和弱项然后根据当前任务的需求来匹配。5.2 多模型协作的注意事项多模型协作虽然能取长补短但也有一些坑需要注意。最大的问题是代码风格不一致。Step 5 Preview 喜欢用 class 和生命周期方法DeepSeek V4 Pro 偏好函数式组合GLM5.3 则倾向于扁平化的模块导出。如果三个模型交替修改同一个文件代码风格会变得很混乱。我的解决办法是在 WorkBuddy 里配置一个统一的代码规范检查 Skill每次模型生成代码后自动运行 ESLint 和 Prettier把风格统一掉。另外在给模型的系统提示词里明确要求“遵循项目现有的代码风格”也能减少风格漂移。另一个问题是上下文传递。当一个模型修改了某个模块的接口另一个模型在后续任务中可能不知道这个变更。WorkBuddy 的跨对话记忆 Skill 能缓解这个问题但最可靠的方式还是在每次任务开始时把相关的接口定义和关键代码片段作为上下文提供给模型。5.3 我踩过的三个坑第一个坑是EventBus 实例不共享。前面提到过Step 5 Preview 用 EventBus 解决循环依赖时我在每个模块里都 new 了一个 EventBus导致事件根本传不过去。正确的做法是在入口文件创建一个全局 EventBus 实例然后通过构造函数注入到需要的模块里。第二个坑是Three.js 版本兼容性。三个模型生成的代码都基于 Three.js但它们默认使用的版本不一样。Step 5 Preview 用的是 r150 左右的 APIDeepSeek V4 Pro 用的是 r160GLM5.3 用的是 r155。有些 API 在不同版本间有变化比如Geometry在 r125 之后就被移除了如果模型生成了旧版 API 的代码运行时会直接报错。我的建议是在项目开始时明确指定 Three.js 版本并在 WorkBuddy 的规则里加上版本检查。第三个坑是性能测试的环境差异。GLM5.3 的碰撞检测优化在 my machine 上效果很好但换到一台集成显卡的笔记本上帧率提升就没那么明显了。后来发现是因为集成显卡的瓶颈在渲染而不是物理计算。所以性能优化一定要在目标设备上测试不能只看开发机的数据。5.4 后续可以扩展的方向这个实测项目本身还有很多可以深挖的地方。比如可以加入网络同步测试模型在处理 WebSocket 通信和状态同步时的表现。也可以加入移动端适配看看模型生成的代码在触屏设备上的交互逻辑是否合理。还可以加入资源加载管理测试模型对异步加载和进度条的实现能力。从 WorkBuddy 的角度可以进一步优化多模型路由策略。比如引入一个任务复杂度评估器自动判断当前任务是简单还是复杂简单任务路由到响应快的模型复杂任务路由到推理能力强的模型。这样能在保证质量的前提下最大化开发效率。另外WorkBuddy 的 Skill 系统也值得深入折腾。我目前只做了几个基础的 Skill比如项目骨架生成和代码规范检查。后续可以做一个自动化测试 Skill每次模型生成代码后自动运行单元测试把测试结果反馈给模型进行自我修正。这样就能形成一个闭环减少人工干预。提示WorkBuddy 的 Skill 开发支持自定义脚本你可以用 JavaScript 或 Python 编写 Skill 的执行逻辑。官方文档里有详细的 Skill 开发指南建议从简单的 Skill 开始逐步增加复杂度。5.5 给不同阶段开发者的建议如果你是刚接触 3D 游戏开发的新手我建议从 GLM5.3 开始。它的代码注释充分逻辑清晰适合用来学习 Three.js 的基本用法和游戏循环的架构。等你看懂了基本结构再尝试用 Step 5 Preview 快速搭建自己的项目最后用 DeepSeek V4 Pro 做性能优化和架构升级。如果你是有经验的开发者可以直接用 DeepSeek V4 Pro 做主力它的架构思维和性能意识能帮你省去很多后期重构的麻烦。Step 5 Preview 可以作为快速验证想法的工具GLM5.3 则用来补充文档和注释。如果你在团队里推广 AI 辅助开发WorkBuddy 的多模型配置和规则系统能帮你统一团队的开发流程。建议先制定一套代码规范和模型使用规则然后在 WorkBuddy 里配置好这样团队成员不需要每个人都去研究哪个模型适合什么任务直接按照规则执行就行。我在实际使用中发现模型的能力边界在快速变化今天的最优选择可能下个月就被颠覆了。所以最重要的不是记住哪个模型好而是建立一套快速评估和切换模型的机制。WorkBuddy 的规则系统正好能满足这个需求你可以随时调整路由策略而不需要改变自己的工作习惯。