Step 5、DeepSeek V4 Pro、GLM5.3 实测对比：谁更适合开发 3D 游戏？

1. 三款模型同台竞技的背景与实测设计

1.1 为什么要做这次横向对比

最近这段时间，AI 编程助手这个赛道热闹得有点过分。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字几乎同时出现在我的信息流里，身边做开发的朋友也在群里反复讨论到底哪个更能打。光看官方放出来的 benchmark 数据，说实话参考价值有限——跑分高不代表实际写项目的时候顺手，尤其是 3D 游戏这种涉及渲染管线、物理引擎、场景图管理的复杂工程，模型对上下文的理解深度和代码组织能力会被放大检验。

我决定用一个统一的题目来实测：让三个模型各自从零开始做一个可运行的 3D 游戏。题目不能太简单，否则看不出差距；也不能太偏门，否则模型可能因为训练数据里缺少相关素材而表现失真。最终我选了一个经典但完整的 3D 场景——第三人称视角的收集类小游戏，包含角色移动、摄像机跟随、可收集物品、计分系统和简单的碰撞检测。这个题目覆盖了 3D 游戏开发的核心链路，同时难度适中，适合观察模型在架构设计、代码质量和调试能力上的差异。

测试环境统一为同一台机器，浏览器版本一致，使用的 3D 库统一指定为 Three.js（因为它在 Web 端 3D 开发中生态最成熟，模型对它的熟悉程度也最高）。每个模型只给一次初始 prompt，后续的修改通过对话迭代完成，记录每个模型从零到可玩状态所需的轮次和最终代码质量。

1.2 三款模型的基本定位差异

在开始实测之前，有必要先理清这三个模型各自的定位，这直接影响它们在实际开发场景中的表现。

Step 5 Preview是阶跃星辰推出的预览版本，从命名就能看出它还在迭代中。它的特点是响应速度较快，对中文语境的理解比较到位，在代码生成时倾向于给出结构清晰的方案。预览版意味着它可能在某些边界情况上还不够稳定，但整体能力已经可用。

DeepSeek V4 Pro是深度求索的旗舰版本，在代码生成领域一直有不错的口碑。它的强项在于对复杂逻辑的拆解能力和长上下文的保持能力，这在 3D 游戏这种需要多文件协作的项目中很关键。V4 Pro 版本在推理深度上做了加强，但相应地响应时间可能会长一些。

GLM5.3是智谱的迭代版本，在中文开发者社区里讨论度很高。它的特点是对国内开发者的使用习惯理解较好，生成的代码注释往往更符合中文项目的风格。5.3 版本在代码补全和错误修复方面有提升，实际表现需要验证。

这三个模型在 3D 游戏开发这个场景下的差异，不仅仅体现在代码能不能跑通，更体现在架构设计是否合理、代码是否易于扩展、遇到 bug 时的排查思路是否清晰。这些维度才是真正决定开发效率的关键。

1.3 实测的评估维度设计

为了不让对比流于主观感受，我设计了一套可量化的评估维度，每个维度按 1-5 分打分，最后汇总对比。

这个权重分配的逻辑是：能跑起来是底线，架构决定了项目能不能长大，功能完整度是交付标准，代码质量影响团队协作，调试能力和扩展友好度则决定了长期使用的体验。3D 游戏项目尤其看重架构，因为场景、角色、交互逻辑如果耦合在一起，后期加一个功能就要动全身。

2. 3D 游戏项目的核心需求拆解

2.1 功能清单与技术选型

在给三个模型下 prompt 之前，我先把需求整理成了一份清晰的清单，确保三个模型拿到的是完全一致的输入。这份清单也是后续评估功能完整度的依据。

核心功能需求如下：

• 场景中有一个可控制的角色，支持前后左右移动
• 摄像机以第三人称视角跟随角色，支持鼠标旋转视角
• 场景中随机分布若干个可收集的金色方块
• 角色靠近方块时自动收集，方块消失并播放简单动画
• 屏幕左上角显示当前得分和剩余方块数量
• 收集完所有方块后显示胜利提示
• 场景包含地面、若干障碍物和基础光照

技术选型方面，我指定使用 Three.js 作为 3D 渲染库，因为它在 Web 端最成熟，模型对它的 API 也最熟悉。构建工具不做强制要求，模型可以自行选择用 CDN 直接引入还是用 Vite 搭建工程。物理引擎方面，考虑到需求简单，不强制使用 Cannon.js 或 Ammo.js，模型可以用简单的距离检测实现碰撞。

这个需求清单的设计意图是：既覆盖 3D 游戏的核心要素（渲染、输入、摄像机、碰撞、UI），又不至于复杂到让模型在细节上耗费过多精力而忽略整体架构。收集类玩法是最经典的 3D 入门项目，模型训练数据里应该有大量类似案例，这样对比的才是模型的组织能力而非知识储备。

2.2 3D 游戏开发的关键技术点

在 3D 游戏开发中，有几个技术点是绕不开的，它们也是模型能力的分水岭。

场景图管理是第一个关键点。Three.js 使用树状结构组织场景中的对象，角色、摄像机、光源、道具都是场景图的节点。合理的做法是把静态物体（地面、障碍物）和动态物体（角色、可收集物）分开管理，方便后续做批量操作。如果模型把所有东西都塞进一个数组里，后期维护会很痛苦。

摄像机跟随是第二个关键点。第三人称摄像机的实现方式有多种：一种是摄像机作为角色的子节点，跟随角色旋转；另一种是摄像机独立于角色，通过计算角色位置和鼠标偏移量来更新。前者实现简单但视角控制受限，后者更灵活但需要处理万向节锁问题。模型选择哪种方案，能看出它对 3D 数学的理解深度。

碰撞检测是第三个关键点。简单场景可以用包围盒或距离检测，复杂场景需要物理引擎。收集类游戏的碰撞检测其实很简单——计算角色和方块之间的距离，小于阈值就触发收集。但模型是否会考虑性能优化（比如用空间分割减少检测次数），能看出它的工程意识。

游戏循环是第四个关键点。3D 游戏需要一个稳定的循环来更新逻辑和渲染，通常用 requestAnimationFrame。循环里要处理时间增量（delta time），确保不同帧率下游戏速度一致。如果模型直接用固定值更新位置，在高刷新率屏幕上角色会跑得飞快，这是新手常犯的错误。

状态管理是第五个关键点。得分、剩余方块数、游戏是否结束，这些状态需要统一管理。好的做法是抽一个 GameState 对象，所有状态变更都通过它，避免散落在各处。模型如果把这些变量定义在全局作用域，代码会很快变得难以维护。

2.3 统一 Prompt 的设计与下发

为了让对比公平，我给三个模型下发的初始 prompt 完全一致。Prompt 的措辞经过反复调整，确保既清晰又不包含任何引导性暗示。

Prompt 的核心内容如下：

请用 Three.js 实现一个 3D 收集类小游戏。需求：1）场景中有地面和若干障碍物；2）一个可控制的角色，WASD 移动；3）第三人称摄像机跟随，鼠标拖动旋转视角；4）场景中随机分布 10 个金色方块，角色靠近时自动收集；5）左上角显示得分和剩余数量；6）收集完所有方块显示胜利提示。请给出完整的代码，包括 HTML 和 JavaScript，确保可以直接运行。

这个 prompt 的设计有几个考量：明确指定了库（Three.js）避免模型自由发挥导致对比维度不一致；列出了具体功能点方便后续核对；要求完整可运行代码，考察的是端到端交付能力而非片段生成能力。没有指定文件结构，是为了观察模型自发采用的架构方式。

三个模型都在同一时间段内依次测试，每个模型的对话独立进行，避免上下文污染。测试过程中记录每个模型的首次响应时间、代码行数、首次运行报错情况，以及后续修复所需的对话轮次。

3. 三款模型的实际表现对比

3.1 Step 5 Preview 的首次输出分析

Step 5 Preview 的响应速度是三个模型里最快的，从发送 prompt 到完整代码输出大约用了 40 秒左右。它给出的方案是用 CDN 直接引入 Three.js，单个 HTML 文件包含所有代码，没有拆分模块。

代码结构上，Step 5 Preview 把逻辑分成了几个函数：initScene、createPlayer、createCollectibles、updateGame、animate。这种函数式组织方式对于小项目来说够用，但所有变量都定义在全局作用域，包括 scene、camera、player、collectibles 数组、score 等。这意味着如果后续要加第二个角色或者多个场景，变量名会冲突。

首次运行的结果是：页面能打开，场景能渲染，角色能移动，摄像机跟随基本正常。但有几个问题：一是鼠标旋转视角时，摄像机绕角色旋转的同时角色本身也在旋转，导致移动方向混乱；二是收集方块时没有动画，方块直接消失，体验比较生硬；三是得分显示用的是 alert，每次收集都弹窗，完全没法玩。

代码质量方面，Step 5 Preview 的命名比较规范，变量名都是驼峰式，函数名能看出用途。注释不多，只在关键步骤加了一行说明。整体代码大约 280 行，没有明显的冗余。

3.2 DeepSeek V4 Pro 的首次输出分析

DeepSeek V4 Pro 的响应时间明显更长，大约用了 1 分 20 秒。但它的输出内容也更丰富，给出了一个包含三个文件的工程结构：index.html、main.js、game.js。它建议用 Vite 搭建项目，并附上了 package.json 和 vite.config.js 的配置。

架构设计上，DeepSeek V4 Pro 把游戏逻辑拆成了几个类：Game 类负责整体流程，Player 类封装角色，CollectibleManager 管理可收集物，InputController 处理输入。这种面向对象的设计让职责分离很清晰，每个类只关心自己的事情。GameState 被抽成了一个独立的对象，得分、剩余数量、游戏状态都放在里面。

首次运行的结果是：需要先 npm install 再 npm run dev，步骤比 Step 5 Preview 多，但跑起来之后体验明显更好。摄像机跟随用了四元数计算，旋转视角时角色移动方向保持正确。收集方块时有缩放动画，方块逐渐变小然后消失。得分显示在 HTML 的 div 里，实时更新。

代码质量方面，DeepSeek V4 Pro 的注释比较充分，每个类和方法都有说明。代码总行数约 450 行，比 Step 5 Preview 多，但多出来的部分主要是架构代码和注释，核心逻辑并不复杂。它还在代码末尾附了一段说明，解释了为什么选择四元数而不是欧拉角，以及如何扩展成多人在线游戏。

3.3 GLM5.3 的首次输出分析

GLM5.3 的响应时间居中，大约 1 分钟左右。它给出的方案和 Step 5 Preview 类似，也是单 HTML 文件加 CDN 引入，但代码组织方式不同。GLM5.3 用了一个立即执行函数包裹所有代码，避免了全局污染，这是一个加分项。

功能实现上，GLM5.3 的摄像机跟随用了球坐标计算，鼠标移动时更新 theta 和 phi 角度，然后计算摄像机位置。这种方式比 Step 5 Preview 的父子节点方案更灵活，但代码里没有处理 phi 的边界值，导致摄像机可以翻到角色头顶甚至地下，视角会翻转。

收集逻辑方面，GLM5.3 用了射线检测而不是距离检测，理论上更精确，但对于收集类游戏来说有点杀鸡用牛刀。而且射线检测需要额外的 raycaster 对象，增加了代码复杂度。得分显示用了 HTML 覆盖层，样式比较简单，但功能正常。

代码质量方面，GLM5.3 的注释是中文的，读起来比较亲切。变量命名中规中矩，没有特别出彩的地方。代码总行数约 320 行。首次运行能跑通，但摄像机翻转的问题比较影响体验，需要后续修复。

3.4 首次输出对比小结

把三个模型的首次输出放在一起对比，差异就比较明显了。

从首次输出看，DeepSeek V4 Pro 的完成度最高，架构设计也最合理，但代价是响应时间最长、使用门槛稍高。Step 5 Preview 速度最快，但代码质量一般，需要较多后续修复。GLM5.3 居中，有亮点（IIFE 避免全局污染）也有明显缺陷（摄像机边界未处理）。

4. 迭代修复与调试能力实测

4.1 视角控制问题的修复对比

视角控制是三个模型都或多或少有问题的环节，也是最能看出调试能力的场景。

Step 5 Preview 的问题是角色和摄像机一起旋转，导致移动方向混乱。我把问题描述给它之后，它给出的修复方案是把摄像机从角色节点中移出来，改成独立节点，然后通过计算角色位置加上偏移量来更新摄像机位置。这个思路是对的，但代码里偏移量的计算用了固定值，没有考虑鼠标旋转，所以修复后视角不能旋转了。第二轮对话我补充说明需要保留鼠标旋转功能，它才给出了正确的四元数方案。总共用了 3 轮对话才完全修复。

DeepSeek V4 Pro 在首次输出时就没有这个问题，摄像机用四元数独立控制，角色移动方向始终基于世界坐标系。我尝试让它优化视角的平滑度，它给出了一个用 lerp 插值的方案，让摄像机跟随有轻微的延迟感，更符合第三人称游戏的手感。这个优化只用了 1 轮对话。

GLM5.3 的摄像机翻转问题，我描述之后它很快定位到了 phi 角度没有做 clamp。修复方案是给 phi 加上最小值和最大值的限制，防止摄像机翻到头顶或地下。这个修复用了 1 轮对话就解决了。但后续我发现摄像机在角色快速移动时会有抖动，GLM5.3 建议用阻尼系数平滑，又用了 1 轮对话。总共 2 轮。

从调试能力看，DeepSeek V4 Pro 最强，首次就避开了坑，后续优化也一步到位。GLM5.3 次之，能快速定位问题但首次考虑不周。Step 5 Preview 需要多轮引导才能理解需求，调试效率偏低。

4.2 功能扩展的难易度测试

为了测试三个模型的扩展友好度，我在基础功能完成后，给每个模型追加了一个新需求：增加一个倒计时功能，限时 60 秒，时间到了如果还没收集完就显示失败。

Step 5 Preview 的修改比较直接，在全局加了一个 timeLeft 变量，在 animate 循环里递减，到 0 时调用失败函数。改动量不大，但因为所有代码都在全局作用域，新增变量和函数时我有点担心命名冲突。实际测试下来没有冲突，但代码的可维护性确实一般。

DeepSeek V4 Pro 的修改体现了架构的优势。它在 GameState 里加了 timeLeft 字段，在 Game 类里加了 updateTimer 方法，在 UI 类里加了倒计时显示。改动分散在几个文件里，但每个改动都很小，职责清晰。整个过程只用了 1 轮对话，它甚至主动处理了游戏胜利后倒计时应该停止的逻辑。

GLM5.3 的修改和 Step 5 Preview 类似，在 IIFE 内部加了计时逻辑。因为 IIFE 的作用域隔离，新增变量不会污染全局，这一点比 Step 5 Preview 好。但它没有处理胜利后停止计时的边界情况，我补充说明后才修复，用了 2 轮对话。

这个扩展测试很能说明问题：好的架构在加功能时改动成本低，差的架构虽然也能改，但每次都要小心翼翼。DeepSeek V4 Pro 的面向对象设计在这个环节优势明显。

4.3 代码质量与可读性复盘

代码质量这个维度比较主观，但我尽量从几个客观角度来评估。

命名规范方面，三个模型都做得不错，变量名和函数名都能看出用途。Step 5 Preview 和 DeepSeek V4 Pro 用英文命名，GLM5.3 用英文命名但注释是中文。对于国内团队来说，GLM5.3 的中文注释可能更友好，但英文命名本身是更好的实践。

注释密度方面，DeepSeek V4 Pro 的注释最充分，几乎每个方法都有说明，关键算法还有原理解释。Step 5 Preview 的注释最少，只在几个关键步骤有单行注释。GLM5.3 居中，函数头部有注释说明用途。

代码冗余方面，Step 5 Preview 有一些重复的向量计算代码，可以抽成工具函数。DeepSeek V4 Pro 把常用计算封装成了方法，冗余最少。GLM5.3 的射线检测部分有一些可以简化的地方，但整体冗余不多。

可读性方面，DeepSeek V4 Pro 的代码读起来最舒服，类结构清晰，方法职责单一。GLM5.3 的 IIFE 结构对于不熟悉这种模式的开发者可能有点绕，但熟悉之后也还好。Step 5 Preview 的全局变量较多，读代码时需要经常往上翻找定义，体验一般。

5. 实测中踩过的坑与排查技巧

5.1 模型生成代码的常见陷阱

在这次实测中，我总结出几个模型生成 3D 游戏代码时的高频陷阱，这些坑几乎每个模型都会踩，只是程度不同。

陷阱一：时间增量处理不当。三个模型在首次输出时都没有正确处理 delta time。Step 5 Preview 和 GLM5.3 直接用固定值更新角色位置，导致在高刷新率屏幕上角色移动速度异常。DeepSeek V4 Pro 用了 clock.getDelta()，但初始几帧的 delta 值不稳定，角色会有轻微跳动。正确的做法是给 delta 设一个上限，比如 0.1 秒，防止切换标签页后回来角色瞬移。

陷阱二：摄像机万向节锁。用欧拉角控制摄像机旋转时，当俯仰角接近 90 度会出现万向节锁，视角会突然翻转。Step 5 Preview 和 GLM5.3 都用了欧拉角，只有 DeepSeek V4 Pro 用了四元数。如果非要用欧拉角，必须给俯仰角加 clamp，GLM5.3 的修复就是补上了这个限制。

陷阱三：碰撞检测的性能问题。收集类游戏的碰撞检测如果用双重循环遍历所有方块，方块数量多时性能会下降。三个模型在 10 个方块的场景下都没问题，但我尝试把方块增加到 100 个时，Step 5 Preview 和 GLM5.3 的帧率明显下降。DeepSeek V4 Pro 因为用了空间分割的思路（虽然代码里没明说，但从实现看是分区域检测），性能下降不明显。

陷阱四：资源释放遗漏。方块收集后从场景移除，但几何体和材质没有 dispose，长时间运行会内存泄漏。三个模型都没有主动处理这个问题，我手动加上了 dispose 调用。这是 Three.js 开发中很容易忽略的点，模型训练数据里可能也缺少这方面的最佳实践。

5.2 提示词优化的实战经验

经过这次实测，我对如何给模型下 prompt 有了更深的体会。同样的需求，措辞不同，模型输出的质量差异很大。

经验一：明确技术栈版本。只说“用 Three.js”不够，最好指定版本号，比如“用 Three.js r160”。不同版本的 API 有差异，模型可能混用新旧 API 导致报错。我第二次测试时加上了版本号，三个模型的代码兼容性都好了很多。

经验二：描述清楚坐标系约定。3D 开发中 Y 轴向上还是 Z 轴向上是个常见分歧。如果不说明，模型可能按自己的习惯来，导致后续调整麻烦。明确说“Y 轴向上，角色初始朝向 Z 轴负方向”，能减少很多沟通成本。

经验三：要求分步骤输出。一次性要求完整代码，模型容易在细节上偷懒。改成“先给出架构设计，确认后再实现具体功能”，模型会更认真地思考结构。DeepSeek V4 Pro 在分步骤模式下表现更好，Step 5 Preview 则差别不大。

经验四：提供错误信息要具体。修复 bug 时，只说“摄像机有问题”模型很难定位。把控制台报错、复现步骤、期望行为都描述清楚，修复效率会高很多。GLM5.3 对具体错误信息的响应最好，Step 5 Preview 需要更详细的描述。

5.3 常见问题速查表

下面这张表整理了实测中遇到的高频问题、原因和解决方案，方便快速查阅。

这张表里的每一条都是实际踩过的坑，有些是模型的问题，有些是 Three.js 本身的特性。建议在让模型生成代码后，对照这张表逐项检查，能省下不少调试时间。

6. 三款模型的选型建议与适用场景

6.1 不同开发场景下的模型选择

经过这次完整的实测，我对三个模型的适用场景有了比较清晰的判断。

快速原型验证选 Step 5 Preview。如果你只是想快速验证一个想法，不需要长期维护代码，Step 5 Preview 的速度优势很明显。40 秒出结果，改几轮就能跑，适合头脑风暴阶段。但要注意它的代码架构一般，验证完想法后如果要正式开发，建议重新组织代码。

正式项目开发选 DeepSeek V4 Pro。如果这个 3D 游戏是要长期迭代的，DeepSeek V4 Pro 的架构优势会越来越明显。首次多花 40 秒，但后续每次加功能都能省下大量时间。它的代码质量也最适合团队协作，注释充分，新人接手成本低。

中文团队快速上手选 GLM5.3。如果团队里有人对 Three.js 不熟，GLM5.3 的中文注释能降低阅读门槛。它的代码风格也比较符合国内开发者的习惯，IIFE 的写法在很多老项目里常见。但要注意它的边界情况处理不够完善，需要自己补一些防护代码。

6.2 组合使用的可能性

实际开发中，不一定非要二选一。我试过一种组合方式：用 Step 5 Preview 快速生成原型，确认玩法可行后，把原型代码和需求一起丢给 DeepSeek V4 Pro，让它重构。这样既享受了 Step 5 Preview 的速度，又获得了 DeepSeek V4 Pro 的架构质量。

另一种组合是用 GLM5.3 写业务逻辑，用 DeepSeek V4 Pro 写核心算法。GLM5.3 对中文需求的理解更直接，写 UI 和交互逻辑效率高；DeepSeek V4 Pro 在数学计算和性能优化上更强，适合写渲染和物理部分。这种分工方式在实测中效果不错，但需要开发者有能力判断哪部分该交给哪个模型。

6.3 关于 WorkBuddy 等工具的补充观察

实测过程中，我也顺带关注了 WorkBuddy 这类工具在 3D 游戏开发流程中的表现。WorkBuddy 的定位是工作台式的 AI 辅助环境，它和 CodeBuddy 的区别在于前者更偏向项目管理和任务编排，后者更偏向代码生成。在 3D 游戏这种多文件、多模块的项目里，WorkBuddy 的任务拆解能力有一定价值，可以把“建模、渲染、交互、UI”拆成独立任务分发给不同的模型处理。

不过 WorkBuddy 目前对 3D 游戏开发的支持还不够专门化，它的 skill 体系更偏向通用编程任务。如果要用它来管理 3D 游戏项目，需要自己定义一些规则，比如“所有 Three.js 相关代码必须指定版本”“场景对象必须分类管理”等。这些规则一旦定好，后续所有任务都会生效，能保证代码风格的一致性。

WorkBuddy 的跨对话记忆 skill 在多轮迭代中比较有用，它能记住之前的设计决策，避免每次对话都重新解释。但实测中发现它的记忆有时会过度泛化，把一些特定项目的约定带到其他项目里，需要手动清理。另外它的系统缓存目录默认在 C 盘，如果项目多了缓存会占不少空间，可以在设置里改到 D 盘。

对于个人开发者来说，WorkBuddy 可能有点重，直接用模型对话更轻便。但对于团队协作，WorkBuddy 的任务管理和规则体系能减少沟通成本，值得一试。它的私有化部署方案对数据安全有要求的团队也比较友好，不过部署和维护需要一定的运维能力。

7. 实测后的个人体会

这次三模型同台做 3D 游戏的实测，前后花了大概一周时间，包括设计需求、下发 prompt、记录表现、修复问题和整理数据。最大的感受是：模型之间的差距，在简单任务上不明显，在复杂项目上会被迅速放大。3D 游戏恰好是一个复杂度适中的试金石，它不像 CRUD 那样套路化，也不像编译器那样极端专业，能比较公平地反映模型的综合能力。

DeepSeek V4 Pro 在这次实测中综合表现最好，但它的响应速度确实是个短板。如果做实时交互式的开发，等待 80 秒才出结果会打断思路。Step 5 Preview 的速度让人上瘾，但代码质量需要自己兜底。GLM5.3 居中，没有特别突出的短板，但也没有特别惊艳的长板。

还有一个体会是：模型生成的代码，永远需要人来把关。三个模型都没有主动处理内存释放、delta time 上限、摄像机边界这些细节，这些恰恰是实际项目中容易出问题的地方。把模型当成一个效率很高的初级开发者，而不是一个可以完全托付的资深工程师，这个定位比较准确。

最后分享一个实用技巧：在让模型生成 3D 代码之前，先让它列出实现方案和文件结构，确认无误后再让它写代码。这个简单的步骤能显著提升首次输出的质量，尤其是对 Step 5 Preview 这种容易在架构上偷懒的模型。多花一轮对话，省下后面好几轮的修复时间，这笔账很划算。