1. 三款模型同台做3D游戏我为什么选这个题最近这段时间AI编程工具圈子里最热闹的事情之一就是几个新版本模型几乎前后脚放出来。Step 5 Preview、DeepSeek V4 Pro、GLM5.3这三个名字在开发者社区里被反复提起讨论的焦点也很集中到底谁写代码更靠谱谁在复杂项目里不容易翻车。我平时的工作流里WorkBuddy 是主力工作台CodeBuddy 也会穿插着用所以看到这三个模型都宣称在代码生成上有明显提升之后我就想干脆做个横向实测用一个足够复杂、足够综合的任务把它们拉到同一个赛道上比一比。选什么任务合适呢写个爬虫、做个后台接口这些太简单了体现不出模型之间的差距。思来想去我决定让它们各自独立完成一个3D游戏。3D游戏这个任务有几个好处第一它涉及图形渲染、物理模拟、用户输入、游戏循环、状态管理等多个子系统能全面考察模型的架构能力第二3D游戏对代码的正确性要求很高一个矩阵变换写错整个画面就全乱了很容易看出模型是不是真的理解了几何数学第三这个任务足够大能逼出模型在长上下文里保持逻辑一致性的能力而这恰恰是区分模型水平高低的关键指标。这篇文章我会把整个实测过程完整拆开来讲包括我怎么设计测试方案、每个模型实际生成出来的代码质量如何、遇到了哪些坑、最后哪个模型的表现让我最意外。如果你也在纠结日常开发该用哪个模型或者想知道怎么用 WorkBuddy 这类工作台把AI编程的效率拉满那这篇内容应该能给你一些直接可用的参考。2. 测试方案设计怎么让三个模型公平地打一场2.1 任务定义与统一提示词公平对比的前提是任务定义必须完全一致。我给三个模型用的是同一段提示词内容大致是这样的用 Three.js 做一个3D第一人称视角的迷宫探索游戏要求包含随机迷宫生成、WASD 移动、鼠标视角旋转、碰撞检测、计时器、小地图、通关判定这几个核心功能代码要能直接在浏览器里跑起来不需要额外的构建工具。为什么选 Three.js 而不是 Unity 或者 Godot因为 Three.js 是纯 JavaScript 的 Web 3D 库模型生成的代码可以直接在浏览器里验证不需要安装引擎、配置项目、处理资源导入这些额外步骤。这样一来变量就控制住了模型之间的差异纯粹体现在代码生成能力上而不是对某个引擎的熟悉程度。提示词里我特意没有给太详细的实现步骤只说了功能需求。这是故意的我想看看模型会不会主动做合理的架构决策比如怎么组织迷宫数据结构、怎么处理碰撞检测的边界情况、怎么设计游戏状态机。如果提示词写得太细那就变成考执行力了而不是考设计能力。2.2 评测维度与打分标准光看能不能跑太粗糙了我设计了一套多维度的评分标准每个维度满分10分最后算加权总分。具体维度包括功能完整度提示词里要求的七个功能实际实现了几个有没有偷工减料代码可运行性生成的代码能不能直接跑需不需要手动修 bug架构合理性代码组织是否清晰模块划分是否合理有没有把逻辑都堆在一个文件里几何与数学正确性3D 相关的矩阵运算、向量计算、碰撞检测是否正确交互体验操作是否流畅有没有明显的卡顿或者手感问题代码可读性命名是否规范注释是否到位变量作用域是否合理权重方面功能完整度和可运行性各占25%架构合理性和数学正确性各占20%交互体验和可读性各占5%。这个权重分配的逻辑是一个游戏首先得能玩其次得写得对最后才是写得好不好看。2.3 运行环境与验证方式三个模型生成的代码我都在同一台机器上测试浏览器用的是 Chrome 最新稳定版硬件配置是 M2 MacBook Pro 16GB 内存。每个模型的代码我都跑三遍排除偶发性问题。验证的时候我会实际玩几分钟走遍迷宫的各个角落测试碰撞检测在墙角、窄道这些边界情况下是否正常。另外我还准备了一个小工具用来统计每个模型生成代码的行数、函数数量、平均函数长度这些指标作为架构合理性的辅助参考。这些数据不能说明全部问题但能提供一些客观的对比依据。3. Step 5 Preview 实测第一印象与代码拆解3.1 生成速度与初始输出Step 5 Preview 的响应速度是三个模型里最快的从提交提示词到完整输出大约用了40秒左右。它一次性生成了一个完整的 HTML 文件里面包含了 Three.js 的 CDN 引入、游戏主逻辑、样式和 HTML 结构总共约680行代码。第一眼看上去代码结构还算清晰用了几个类来组织不同的功能模块MazeGenerator负责迷宫生成Player负责玩家状态和移动Game作为主控制器。这种面向对象的组织方式在3D游戏里是合理的因为游戏本身就有很多有状态的对象需要管理。不过仔细看下去问题就开始暴露了。迷宫生成用的是递归回溯算法这个选择本身没问题但它的实现里有一个边界条件处理得不对。当迷宫尺寸是奇数的时候生成的迷宫最外圈会有一行或者一列是通路玩家可以直接走出去这就破坏了迷宫的封闭性。这个 bug 不是致命的但说明模型在处理边界条件的时候不够细致。3.2 核心功能实现质量移动和视角控制这部分Step 5 Preview 做得中规中矩。WASD 移动用的是基于相机朝向的向量计算这个思路是对的但它在处理斜向移动的时候没有做归一化导致同时按 W 和 D 的时候移动速度会比只按 W 快大约41%。这是一个很经典的错误说明模型对向量归一化的理解还停留在表面。碰撞检测是3D游戏里最容易出问题的地方Step 5 Preview 用的是简单的 AABB轴对齐包围盒检测把玩家当成一个圆柱体迷宫墙壁当成一系列矩形。这个方案在大多数情况下能工作但在墙角位置会出现卡住的现象因为玩家同时碰到两面墙的时候两个方向的碰撞响应会互相抵消导致玩家动弹不得。我实测的时候在几个拐角处确实遇到了这个问题需要松开按键换个方向才能继续走。小地图功能倒是实现得不错用 Canvas 2D 在右上角画了一个俯视图玩家位置用红点标注迷宫墙壁用灰色线条表示。这个实现方式比用第二个 Three.js 相机做画中画要轻量得多性能开销小是个聪明的选择。3.3 踩到的坑与修复过程Step 5 Preview 生成的代码不能直接跑有一个语法错误在迷宫生成函数里它用了一个未定义的变量wallThickness应该是想用常量但忘了声明。这个错误很低级但好在很容易修加一行const wallThickness 1;就好了。修完这个错误之后游戏能跑起来了但玩起来手感很怪。鼠标视角旋转的灵敏度太高轻轻一动鼠标视角就转了大半圈根本没法瞄准方向。我看了下代码它把鼠标移动的movementX直接乘以了一个系数就加到相机旋转上没有做任何平滑或者限制。我手动把系数从 0.002 改到 0.0008 之后手感才正常。还有一个问题是计时器。Step 5 Preview 用setInterval每秒更新一次计时显示但游戏循环用的是requestAnimationFrame两者不同步导致计时器显示的时间和实际经过的时间有偏差玩久了能差出好几秒。正确的做法应该是在游戏循环里用performance.now()计算真实经过的时间。这个问题不影响游戏运行但说明模型对时间管理的理解不够深入。4. DeepSeek V4 Pro 实测稳扎稳打但有小瑕疵4.1 代码组织与架构设计DeepSeek V4 Pro 的生成速度比 Step 5 Preview 慢一些大约用了55秒。它输出的代码量更大约850行但多出来的部分主要是注释和错误处理不是冗余代码。架构方面DeepSeek V4 Pro 明显更有章法。它把代码分成了六个模块Maze、Player、InputManager、CollisionSystem、GameRenderer、Game。这种模块划分比 Step 5 Preview 更细每个模块的职责也更单一。特别是把输入管理和碰撞检测单独抽出来这个设计很专业因为这两个系统在游戏开发里本来就是独立演化的后面要加手柄支持或者换成物理引擎只需要改对应的模块就行。代码里还定义了一套事件系统玩家移动、碰撞、通关这些事件都会触发对应的回调。这个设计在小型游戏里有点过度工程但考虑到这是模型生成的代码能主动做这种架构决策说明它对软件设计模式的理解比较到位。4.2 3D数学与碰撞检测的细节DeepSeek V4 Pro 在数学处理上明显更严谨。移动向量的归一化它做对了斜向移动和直线移动速度一致。视角旋转用了四元数而不是欧拉角避免了万向节死锁的问题这个选择在3D游戏里是标准做法但很多模型生成代码的时候会图省事直接用欧拉角。碰撞检测它用的是射线检测加滑动响应。具体来说玩家移动之前先发一条射线检测前方有没有墙壁如果有就计算墙壁的法线把移动向量投影到法线垂直的平面上这样玩家就会沿着墙壁滑动而不是卡住。这个方案比 Step 5 Preview 的 AABB 检测要高级得多实际玩起来手感也顺滑很多贴着墙走的时候不会有卡顿感。不过它也有一个小问题射线检测的长度用的是玩家移动距离但没有加上玩家半径。这意味着玩家可以走到离墙壁非常近的位置视觉上看起来像是脸贴墙了。正确的做法应该是射线长度等于移动距离加上玩家半径这样玩家和墙壁之间会始终保持一个合理的距离。这个问题不影响功能但影响视觉体验。4.3 实际运行表现与手感评价DeepSeek V4 Pro 生成的代码可以直接运行没有语法错误这一点比 Step 5 Preview 强。游戏跑起来之后帧率很稳定在我的机器上基本保持在60fps没有明显的掉帧。操作手感是三个模型里最好的。移动速度适中视角旋转平滑碰撞响应自然。小地图的绘制也比 Step 5 Preview 精细用了不同的颜色区分已探索和未探索的区域这个细节很加分。计时器用的是performance.now()和游戏循环同步时间显示准确。通关判定也做了走到迷宫出口会弹出提示显示用时。整体来说DeepSeek V4 Pro 生成的这个游戏是三个里面完成度最高、最能直接玩的。唯一让我不太满意的是代码注释。虽然注释数量不少但很多注释是废话比如// 更新玩家位置这种看函数名就知道的事情还要写一行注释。真正需要解释的地方比如四元数旋转的计算逻辑、射线检测的数学原理反而没有注释。这说明模型在注释的取舍上还不够智能。5. GLM5.3 实测有亮点也有硬伤5.1 迷宫生成算法的选择GLM5.3 的生成速度最慢用了将近70秒但它的输出有一个很明显的亮点迷宫生成算法用的是 Prim 算法而不是递归回溯。Prim 算法生成的迷宫岔路更多、死胡同更少玩起来探索感更强。这个选择说明模型不只是套模板而是真的在根据任务特点做算法选型。代码里还加了一个难度参数可以通过调整迷宫尺寸和墙壁密度来改变难度。虽然提示词里没要求这个功能但模型主动加了算是超出预期。不过这个难度参数没有暴露到界面上玩家没法在游戏里调整只能改代码实用性打了折扣。5.2 渲染与性能优化尝试GLM5.3 在渲染方面做了一些优化尝试。它用了 InstancedMesh 来渲染迷宫墙壁把所有墙壁合并成一个绘制调用而不是每面墙单独一个 Mesh。这个优化在迷宫尺寸大的时候效果很明显我测试了一个50x50的迷宫帧率依然能保持在60fps而 Step 5 Preview 在同样尺寸下掉到了30fps左右。但是这个优化也带来了一个问题InstancedMesh 的碰撞检测不能直接用射线检测需要额外的数学计算。GLM5.3 在这部分的处理有问题碰撞检测的精度不够玩家有时候会穿墙特别是在快速移动的时候。我试了几次在迷宫的某些位置按住 W 一直走确实能穿过去。这是一个比较严重的 bug直接影响了游戏的可玩性。5.3 代码中的硬伤与修复难度除了穿墙问题GLM5.3 的代码还有一个更麻烦的 bug内存泄漏。它在每次重新生成迷宫的时候都会创建新的几何体和材质但没有销毁旧的。玩了几次重新开始之后内存占用会持续上升最后浏览器标签页会变得很卡。这个问题的修复需要引入资源管理机制不是改一两行代码能解决的。另外GLM5.3 生成的代码里有一个异步加载的问题。它试图从外部加载一个纹理图片作为墙壁材质但那个图片地址是它编造的根本不存在。加载失败之后墙壁变成了纯黑色整个迷宫看起来像是一个黑洞。虽然不影响功能但视觉效果大打折扣。我手动把纹理加载的代码注释掉换成纯色材质之后才正常。综合来看GLM5.3 在算法选型和性能优化上有想法但在工程细节上不够扎实生成的代码需要比较多的手动修复才能达到可用状态。6. 三款模型横向对比数据说话6.1 评分汇总与关键指标把三个模型的各项得分整理成表格对比起来更直观评测维度Step 5 PreviewDeepSeek V4 ProGLM5.3功能完整度25%7/109/108/10代码可运行性25%6/109/105/10架构合理性20%7/109/108/10数学正确性20%6/109/106/10交互体验5%6/109/107/10代码可读性5%7/108/107/10加权总分6.558.906.85从数据上看DeepSeek V4 Pro 在几乎所有维度上都领先特别是在代码可运行性和数学正确性这两个关键指标上优势明显。Step 5 Preview 和 GLM5.3 的总分接近但失分点不同Step 5 Preview 主要是数学和交互体验拖了后腿GLM5.3 则是可运行性和数学正确性有问题。6.2 各自擅长的场景分析虽然总分有高低但每个模型都有自己的特点适合不同的使用场景。Step 5 Preview 的优势是快。如果你需要快速生成一个原型先看看效果再迭代它的速度优势很有价值。而且它的代码结构不算差改起来不算费劲。适合那种先跑起来再说的场景。DeepSeek V4 Pro 的优势是稳。生成的代码质量高数学严谨架构清晰基本不需要大改。适合那种对代码质量有要求、希望一次成型的场景。缺点是速度稍慢但在可接受范围内。GLM5.3 的优势是有想法。它在算法选型和性能优化上会主动做决策有时候能给出超出预期的方案。但工程细节不够扎实需要使用者有比较强的 debug 能力。适合那种愿意花时间调优、追求性能的场景。6.3 在 WorkBuddy 里的实际调用体验这三个模型我都是在 WorkBuddy 里调用的。WorkBuddy 的工作台模式很适合这种多模型对比的场景可以在同一个界面里切换不同的模型不用来回折腾配置。它的自定义指令功能也很有用我提前设置了几条规则比如生成的代码必须包含错误处理、变量命名使用驼峰式这些规则对所有模型都生效省去了每次都要重复说明的麻烦。WorkBuddy 的跨对话记忆功能在这次实测里也帮了不少忙。我在第一个对话里定义了游戏的功能需求后面切换模型的时候不需要重新描述它记得之前的上下文。这个功能在长时间的项目开发里特别实用不用每次都从头解释背景。不过有一点要注意WorkBuddy 的系统缓存目录默认在 C 盘如果你经常生成大项目缓存文件会占不少空间。可以在设置里把缓存目录改到其他盘具体路径在偏好设置的存储选项里。这个改动需要重启 WorkBuddy 才生效改完之后之前的缓存不会自动迁移需要手动复制过去。7. 实操心得与避坑指南7.1 提示词怎么写才能让模型少犯错这次实测让我对提示词的写法有了新的认识。之前我写提示词比较随意想到什么说什么但这次三个模型用的是同一段提示词输出质量差异这么大说明提示词本身还有优化空间。一个有效的技巧是在提示词里明确列出必须实现的功能和禁止使用的方案。比如这次我如果加上碰撞检测必须处理墙角情况、计时器必须与游戏循环同步这两条Step 5 Preview 可能就不会犯那两个错误。模型不是不会做而是不知道你关心什么你明确指出来它就会往那个方向使劲。另一个技巧是给一个参考实现的结构。比如你可以说代码分成迷宫生成、玩家控制、碰撞检测、渲染四个模块这样模型就会按照这个结构来组织代码而不是自己乱分。这个技巧在团队协作里特别有用因为大家用同一个结构代码风格统一review 起来也方便。7.2 代码审查的重点检查项模型生成的代码不能直接信必须审查。根据这次的经验我总结了一个检查清单按优先级排列数学计算向量归一化、矩阵乘法、角度转弧度这些地方最容易出错而且错了之后现象很隐蔽边界条件数组越界、除零、空值模型经常忽略这些资源管理创建的几何体、材质、纹理有没有销毁事件监听有没有移除时间处理计时器是否与游戏循环同步有没有用setInterval这种不精确的方式异步操作加载资源的失败处理Promise 的 reject 有没有 catch这个清单不是只适用于3D游戏任何模型生成的代码都可以按这个思路审查。养成习惯之后审查速度会快很多。7.3 常见问题速查表问题现象可能原因排查方法修复方案画面全黑相机位置或朝向错误打印相机位置和旋转检查相机初始化参数移动速度异常向量未归一化对比斜向和直线移动速度对移动向量做 normalize穿墙碰撞检测精度不足快速移动测试改用射线检测或增加检测频率卡顿掉帧绘制调用过多查看渲染统计使用 InstancedMesh 合并内存持续增长资源未销毁查看内存占用曲线在重新生成时 dispose 旧资源计时不准计时器与循环不同步对比计时和实际时间用 performance.now() 计算这个表里的问题都是我这次实测中实际遇到的不是从文档里抄的。每个问题的排查方法和修复方案都验证过可以直接用。7.4 模型选择建议如果你只是偶尔用 AI 写点小工具三个模型都能胜任选哪个差别不大。但如果你要做的是有一定复杂度的项目我的建议是对代码质量要求高、不想花太多时间 debug 的选 DeepSeek V4 Pro需要快速出原型、后续会大量手动修改的选 Step 5 Preview追求性能优化、愿意花时间调优的选 GLM5.3当然这只是基于这次3D游戏实测的结论。不同任务类型下模型的表现可能会有变化。比如纯算法题、数据处理、前端页面这些场景的评测结果可能和3D游戏不一样。最好的办法还是自己拿实际项目去试找到最适合自己工作流的那个。8. 后续可以怎么扩展这个测试这次实测只覆盖了3D游戏这一个场景虽然信息量不小但还不足以全面评价三个模型的能力。如果你有兴趣自己扩展这个测试我有几个方向可以推荐。第一个方向是换任务类型。比如让模型做一个带实时协作的待办事项应用考察它对 WebSocket、状态同步、冲突解决这些问题的处理能力。或者做一个数据可视化仪表盘考察它对图表库的选用和数据处理的能力。不同任务类型能暴露出模型的不同短板。第二个方向是加长上下文。这次的任务提示词比较短模型在长上下文里的表现没有充分测试。你可以试着给一个几千行的现有项目让模型在现有代码基础上加功能看看它能不能理解项目结构、遵循现有代码风格、不破坏已有功能。这个能力在实际工作里比从零生成代码更重要。第三个方向是多人协作场景。让两个模型分别写前端和后端然后对接起来看看接口定义是否一致、错误处理是否兼容。这个测试能考察模型的沟通能力和契约意识在团队开发里很关键。我现在正在准备第二个方向的测试拿一个真实的中型项目让三个模型分别加功能看看谁改得最干净、引入的 bug 最少。结果出来之后会再写一篇分享。如果你也在做类似的对比测试欢迎交流特别是如果你发现了某个模型在特定场景下的独特优势那是我最感兴趣的信息。