1. 三款模型同台竞技：这个对比测试到底在测什么
三个大模型，同一个3D游戏需求，同样的对话轮次限制，最后跑出来的东西差距有多大？这个问题比任何跑分榜单都更让我好奇。Step 5 Preview、DeepSeek V4 Pro、GLM5.3，这三个名字最近在开发者圈子里被反复提及，但真正把它们拉到同一个实战场景里做横向对比的内容并不多。我花了整整两天时间，用完全相同的提示词、相同的迭代次数、相同的验收标准，让它们各自从零开始构建一个可运行的3D游戏原型。
先说清楚这个测试的定位。它不是那种跑几个基准测试题然后列个分数表的学术评测，而是一个面向实际交付的工程化对比。我关心的核心问题很具体：在有限的对话轮次内，哪个模型能真正理解3D游戏的空间逻辑？哪个模型生成的代码结构更合理、更容易继续迭代？哪个模型在遇到报错时能自己定位并修复？这些问题直接决定了你在实际开发中愿不愿意把这类任务交给它。
测试用的3D游戏需求我刻意选了一个中等复杂度的场景：一个第三人称视角的收集类游戏，玩家控制角色在有限空间内移动，收集随机生成的物品，有计分系统和计时器，碰撞检测要正常工作，相机要跟随角色平滑移动。这个需求的好处是它覆盖了3D游戏开发的几个核心模块——场景管理、角色控制、物理碰撞、UI系统、相机逻辑——但又不会复杂到需要大量美术资源或复杂动画。
为什么选这三个模型来对比？Step 5 Preview作为新晋选手，很多人好奇它的实际编码能力到底在什么水平；DeepSeek V4 Pro在代码生成领域一直口碑不错，是很多人心中的基准线；GLM5.3则是近期讨论度很高的选手，尤其在中文开发者社区里被频繁提及。把它们放在一起，能看出不同技术路线在同一个任务上的表现差异。
整个测试过程我用了WorkBuddy作为统一的运行环境。这个选择本身也值得说一下——WorkBuddy提供了一个标准化的项目工作台，能让我在不同模型之间切换时保持环境一致，避免因为环境差异导致的结果偏差。它的工作台模式可以让我把每个模型的输出放在独立的项目空间里运行，互不干扰，同时又能快速对比运行效果。
注意：这个测试的核心目的是观察模型在真实开发场景中的表现差异，不是给模型排座次。每个模型都有自己的擅长领域和适用场景，关键是找到适合你当前任务的那一个。
测试的验收标准我定了四条硬指标：第一，代码必须能直接运行，不需要我手动补全关键逻辑；第二，3D场景中的基本交互必须正常，包括移动、碰撞、收集判定；第三，代码结构要清晰，有基本的模块划分，方便后续扩展；第四，在遇到运行错误时，模型要能根据报错信息给出有效的修复方案。这四条标准看起来简单，但实际跑下来，三个模型的表现差异非常明显。
2. 测试环境搭建与统一标准设定
2.1 为什么选择WorkBuddy作为统一运行环境
在开始对比之前，我需要一个能保证公平性的运行环境。直接用本地IDE不是不行，但不同模型生成的代码对依赖版本、项目结构的要求不一样，手动配置容易引入变量。WorkBuddy的工作台模式解决了这个问题——它提供了一个标准化的项目容器，每个模型的项目独立运行，环境配置一次搞定。
具体操作上，我在WorkBuddy里创建了三个独立的工作台空间，分别命名为step5-test、deepseek-test、glm-test。每个空间里预装了相同的运行环境：Node.js 20.x、Three.js r160、Vite构建工具。这样无论哪个模型生成的代码，运行时的基础条件完全一致。
WorkBuddy的另一个好处是它的对话记录管理功能。每个模型的完整对话历史都被自动保存，包括我发的提示词、模型返回的代码、运行报错信息、修复过程。这让我在后期复盘时能精确回溯每一步的决策点，而不是靠记忆去还原。
实操心得：如果你也要做类似的模型对比测试，强烈建议用统一的工作台环境。我试过直接在本地切换项目，光是依赖版本冲突就浪费了大半天时间，而且很容易把环境问题误判成模型能力问题。
2.2 提示词设计与轮次控制
提示词的设计直接决定了测试的有效性。我用的提示词分三轮，每轮有明确的交付目标：
第一轮提示词的核心是让模型理解需求并给出完整的项目结构。我写的是：“用Three.js创建一个第三人称3D收集游戏。玩家用WASD控制角色移动，鼠标控制相机旋转。场景中随机生成10个可收集物品，玩家靠近时自动收集并加分。有60秒倒计时，时间到显示最终得分。请给出完整的项目文件结构和所有代码。”
第二轮提示词针对运行中出现的具体问题。比如某个模型生成的碰撞检测不工作，我就把报错信息和相关代码片段贴回去，让它修复。
第三轮提示词是功能增强，要求添加一个简单的开始界面和重新开始按钮。
每轮对话我只给一次机会，不反复追问。这样能看出模型一次成型的能力，而不是靠多轮引导才勉强跑通。实际开发中，你不可能无限次地跟模型来回拉扯，一次性能给出可用方案的能力非常关键。
2.3 验收流程与评分维度
验收流程分三步走。第一步是代码审查，看项目结构是否合理、模块划分是否清晰、有没有明显的逻辑漏洞。第二步是实际运行，在WorkBuddy的工作台里启动项目，手动操作角色移动、收集物品、等待计时结束，观察所有功能是否正常。第三步是修复能力测试，如果运行报错，把错误信息反馈给模型，看它能否准确定位问题并给出有效修复。
评分维度我列了一个表，方便量化对比：
| 维度 | 说明 | 权重 |
|---|---|---|
| 代码完整性 | 是否包含所有必要文件，能否直接运行 | 25% |
| 功能正确性 | 移动、碰撞、收集、计时是否正常 | 30% |
| 代码结构 | 模块划分、命名规范、可读性 | 20% |
| 修复能力 | 报错后能否准确定位并修复 | 15% |
| 扩展友好度 | 后续添加功能是否方便 | 10% |
这个权重分配反映了我对实际开发场景的理解：能跑起来是第一位的，跑得对是第二位的，跑得好是加分项。很多评测喜欢把代码优雅度放在很高的位置，但在实际项目中，一个能稳定运行但代码稍显粗糙的方案，远比一个结构精美但跑不起来的方案有价值。
3. 三个模型的首轮输出对比
3.1 Step 5 Preview的首轮表现
Step 5 Preview给我的第一印象是结构意识很强。它返回的项目结构是这样的：
step5-game/ ├── index.html ├── src/ │ ├── main.js │ ├── scene.js │ ├── player.js │ ├── collectibles.js │ ├── ui.js │ └── utils.js └── package.json这个结构把场景管理、玩家控制、收集物逻辑、UI系统分成了独立的模块，每个模块的职责很清晰。main.js作为入口负责初始化和主循环，scene.js管理Three.js的场景、相机、灯光，player.js处理角色移动和相机跟随，collectibles.js负责物品生成和碰撞检测，ui.js管计时器和得分显示。
代码质量方面，Step 5 Preview生成的代码有比较完整的注释，关键函数都有说明。比如在player.js里，它把移动逻辑和相机控制分开成两个函数，移动逻辑里还区分了前后左右四个方向的向量计算。碰撞检测用的是简单的距离判断，虽然不是最精确的方案，但对于收集类游戏来说完全够用。
不过首轮输出也有明显问题。计时器逻辑有bug——它把计时器放在了主循环里用帧数累加，但没有考虑不同设备帧率不同的问题。在高刷新率屏幕上，60秒会变成30秒左右。这个bug在运行测试时暴露得很明显。
注意：帧率相关的计时问题是3D游戏开发中的经典坑。用requestAnimationFrame做计时一定要用时间戳差值，不能用帧数累加。Step 5 Preview在这个点上踩了坑，但它在后续修复轮次里很快就改对了。
3.2 DeepSeek V4 Pro的首轮表现
DeepSeek V4 Pro的首轮输出走的是单文件路线。它把所有代码都塞进了一个index.html里，用script标签引入Three.js的CDN版本，然后在一个大script块里写了所有逻辑。项目结构极其简单：
deepseek-game/ └── index.html这种做法的优点是部署极其方便，双击就能跑，不需要任何构建工具。对于快速原型验证来说，这其实是个合理的选择。但缺点是代码可读性和可维护性差，所有逻辑混在一起，后续要加功能得在几百行代码里找位置。
功能实现上，DeepSeek V4 Pro的完成度不错。移动控制、相机跟随、物品收集、计时器、得分显示都实现了。碰撞检测用的是Three.js的Box3包围盒，比Step 5 Preview的距离判断更精确一些。计时器用了Date.now()的时间戳差值，没有帧率问题。
但它的相机控制有个明显缺陷——鼠标旋转相机时没有做角度限制，可以无限旋转，导致视角会翻转。这个问题在实际操作时很影响体验，你需要小心翼翼地控制鼠标，不然视角就乱了。
代码风格上，DeepSeek V4 Pro的命名比较随意，变量名有a、b、c这种，函数也没有太多注释。对于快速验证来说够用，但如果要在此基础上继续开发，阅读成本会比较高。
3.3 GLM5.3的首轮表现
GLM5.3的首轮输出在结构上介于前两者之间。它用了模块化的思路，但模块划分比Step 5 Preview粗一些：
glm-game/ ├── index.html ├── game.js └── style.cssgame.js里包含了所有游戏逻辑，但用注释分成了几个区块：场景初始化、玩家控制、物品系统、UI更新。这种组织方式比单文件好一些，但不如Step 5 Preview的细粒度模块化。
GLM5.3最突出的地方是代码的健壮性处理。它在很多地方加了防御性判断，比如在访问DOM元素前先检查是否存在，在计算向量前先检查是否为零向量。这些细节说明它在生成代码时考虑了边界情况。
但它的物品收集判定有问题。它用的是射线检测来判断玩家是否靠近物品，但射线的方向和长度设置不太对，导致有时候明明走到物品旁边了却收集不到。这个问题在测试时反复出现，需要手动调整参数才能正常工作。
计时器方面，GLM5.3用了performance.now()，没有帧率问题。UI部分它用了一个简单的div覆盖层来显示得分和时间，样式比较朴素但功能正常。
3.4 首轮对比小结
把三个模型的首轮输出放在一起看，差异很明显：
| 对比项 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3 |
|---|---|---|---|
| 项目结构 | 多文件模块化 | 单文件 | 双文件 |
| 代码注释 | 较完整 | 较少 | 中等 |
| 计时器实现 | 帧数累加（有bug） | 时间戳（正确） | performance.now（正确） |
| 碰撞检测 | 距离判断 | Box3包围盒 | 射线检测（有问题） |
| 相机控制 | 正常 | 无角度限制 | 正常 |
| 一次运行成功率 | 需修复计时器 | 可直接运行 | 需修复收集判定 |
Step 5 Preview的结构最好但踩了计时器的坑，DeepSeek V4 Pro一次跑通但代码组织粗糙，GLM5.3健壮性不错但核心功能有缺陷。这个结果说明一个道理：首轮输出的质量不能只看代码漂不漂亮，要看核心功能是否真正可用。
4. 修复轮次的能力差异
4.1 报错反馈与定位精度
修复轮次是拉开差距的关键环节。我把每个项目的运行报错信息原样贴回给对应的模型，观察它们的反应。
Step 5 Preview收到计时器bug的反馈后，回复很直接：“问题出在计时器使用了帧数累加，不同刷新率下实际时间不一致。应该改用时间戳差值。”然后它给出了修改后的代码，把原来的frameCount++改成了记录startTime和currentTime，用差值计算剩余时间。修改后的代码一次通过，计时准确。
DeepSeek V4 Pro在首轮没有报错，但我主动反馈了相机角度限制的问题。它的回复是：“在相机旋转逻辑中添加俯仰角限制，限制在-89度到89度之间。”然后给出了修改代码，在计算相机位置时加了clamp函数。修改后相机控制正常了。
GLM5.3收到收集判定问题的反馈后，第一轮修复没有完全解决。它调整了射线的长度参数，但方向问题还在。我第二次反馈后，它才意识到应该用玩家位置到物品位置的距离判断，而不是射线检测。第二轮修复才真正解决问题。
这个过程中有个细节值得注意：Step 5 Preview和DeepSeek V4 Pro在修复时都会解释问题原因，而GLM5.3第一轮修复时只是改了参数，没有说明为什么这么改。解释原因的价值在于，你能判断它是否真正理解了问题，还是只是在碰运气。
4.2 修复后的代码质量变化
修复轮次不仅看能不能改对，还要看改完之后代码质量有没有下降。
Step 5 Preview修复计时器后，顺便把时间相关的逻辑抽成了一个独立的Timer类，放在utils.js里。这个改动让代码结构更清晰了，计时逻辑可以复用到其他需要计时的场景。这种顺手优化的行为说明它在生成代码时有全局视角。
DeepSeek V4 Pro修复相机后，代码还是保持单文件结构，但它在修改处加了注释说明角度限制的原因。代码可读性没有明显变化，但也没有变差。
GLM5.3第二轮修复后，把射线检测改成了距离判断，但修改得比较仓促，留下了一些不再使用的变量和函数。代码里出现了raycaster变量但已经不再使用的情况，需要手动清理。
实操心得：模型修复问题时，观察它是否顺手清理废弃代码、是否补充必要的注释，能看出它的代码素养。有些模型只关注“把bug修好”，有些模型会关注“修完之后代码是否还整洁”。后者在实际项目中更有价值。
4.3 多轮对话中的上下文保持
三个模型在多轮对话中保持上下文的能力也有差异。
Step 5 Preview在三轮对话后，仍然记得第一轮定义的项目结构，修复时会把新代码放到正确的模块文件里。它甚至记得我在第一轮提到的“60秒倒计时”这个具体参数，修复时没有改变这个设定。
DeepSeek V4 Pro在第二轮对话时，对第一轮代码的记忆有些模糊。我让它修复相机问题时，它重新生成了整个相机控制部分的代码，而不是只修改有问题的几行。这导致一些原本正常的功能需要重新验证。
GLM5.3在第二轮对话时出现了上下文丢失的情况。我反馈收集判定问题时，它问了一句“你用的是哪个版本的Three.js”，说明它没有记住第一轮对话中已经说明的环境信息。这种上下文丢失在多轮开发中会增加沟通成本。
5. 最终成品对比与实操体验
5.1 三个版本的实际运行效果
经过修复轮次后，三个版本都能正常运行了。但实际体验下来，差异还是很明显。
Step 5 Preview的版本操作手感最流畅。角色移动有加速度和减速度的过渡，不是瞬间启停，这让操作感觉更自然。相机跟随有平滑插值，转动视角时不会太生硬。物品收集有简单的缩放消失动画，虽然简单但提升了反馈感。计时器准确，得分显示清晰。
DeepSeek V4 Pro的版本功能最完整但手感一般。移动是瞬间响应的，没有过渡，操作起来有点“硬”。相机旋转虽然加了角度限制，但旋转速度是固定的，不能调节。物品收集是瞬间消失，没有动画反馈。不过它的碰撞检测最精确，物品的收集判定很准确。
GLM5.3的版本功能正常但细节粗糙。移动和相机都正常，但物品收集后没有视觉反馈，只是得分数字变了。计时器准确，但UI样式比较简陋。整体感觉是“能用但不够精致”。
5.2 代码可扩展性对比
如果我要在这个原型基础上继续开发，三个版本的扩展难度差异很大。
Step 5 Preview的模块化结构让扩展最容易。要加一个新功能，比如“加速道具”，我只需要在collectibles.js里加一个道具类型，在player.js里加一个速度倍率变量，在ui.js里加一个状态显示。每个改动都在独立的文件里，互不影响。
DeepSeek V4 Pro的单文件结构扩展起来最麻烦。所有代码都在一个文件里，加功能需要在几百行代码里找到合适的位置插入。而且变量命名比较随意，找起来费劲。
GLM5.3的双文件结构扩展难度中等。game.js里的代码有注释分区，找位置不算太难，但所有逻辑还是混在一起，加复杂功能时容易互相干扰。
5.3 性能表现
我用Chrome的Performance面板简单测了一下三个版本的帧率表现。在同样的场景复杂度下（10个物品、一个角色、简单光照），三个版本都能稳定在60fps。差异不大，说明对于这个复杂度的场景，三个模型的代码性能都够用。
但如果把物品数量增加到100个，差异就出来了。Step 5 Preview的版本仍然稳定在60fps，因为它用了对象池来管理物品，避免了频繁创建销毁对象。DeepSeek V4 Pro的版本掉到了45fps左右，因为它在每帧都遍历所有物品做碰撞检测。GLM5.3的版本掉到了50fps左右，比DeepSeek好一些但不如Step 5 Preview。
这个测试说明，代码结构的好坏在简单场景下看不出来，但在复杂场景下会直接影响性能。Step 5 Preview在生成代码时就考虑了性能优化，这是它结构意识强的另一个体现。
6. 常见问题与排查技巧实录
6.1 3D游戏开发中的高频坑
在测试过程中，我整理了一些三个模型都容易踩的坑，以及对应的排查方法：
| 问题现象 | 可能原因 | 排查方法 | 修复方案 |
|---|---|---|---|
| 计时器不准 | 帧数累加而非时间戳 | 在不同刷新率设备上测试 | 改用Date.now()或performance.now()差值 |
| 相机视角翻转 | 俯仰角无限制 | 持续上下旋转鼠标 | 添加clamp限制在-89到89度 |
| 碰撞检测失效 | 坐标系不一致 | 打印玩家和物品的世界坐标 | 统一使用世界坐标系计算距离 |
| 物品收集不到 | 判定距离过小 | 逐步增大判定距离测试 | 根据角色和物品尺寸设置合理阈值 |
| 移动卡顿 | 每帧创建新向量 | 检查是否在循环内new对象 | 复用向量对象或使用对象池 |
| 场景加载慢 | 同步加载资源 | 查看Network面板 | 改用异步加载或预加载 |
6.2 模型使用中的实操建议
基于这次测试，我总结了几条使用这类模型做3D游戏开发的建议：
第一，首轮提示词要尽可能具体。不要只说“做一个3D游戏”，要说清楚视角类型、操作方式、核心玩法、技术栈。提示词越具体，模型一次成型的概率越高。我这次测试用的提示词已经算比较具体了，但如果在第一轮就明确要求“计时器必须用时间戳实现”，Step 5 Preview就不会踩那个坑。
第二，修复反馈要包含完整信息。把报错信息、相关代码片段、你的操作步骤都贴回去，不要只说“不工作”。信息越完整，模型定位问题越准确。GLM5.3第一轮修复没到位，部分原因是我只说了“收集判定有问题”，没有描述具体的操作场景。
第三，不要期望一次完美。三个模型都需要至少一轮修复才能达到可用状态。把首轮输出当作“初稿”而不是“成品”，心态会好很多。实际开发中，模型生成代码加人工修复的混合模式，效率远高于纯人工编写。
第四，注意上下文窗口的限制。多轮对话后，模型可能会忘记早期的设定。重要的参数和约束条件，在后续对话中可以重复强调。比如“保持60秒倒计时不变”这种话，在修复轮次里提一句，能避免模型改错。
6.3 WorkBuddy使用中的注意事项
WorkBuddy作为运行环境，整体体验不错，但有几个点需要注意：
缓存目录管理。WorkBuddy默认把对话记录、运行缓存和临时文件放在系统盘的用户目录下。如果长时间使用，这个目录会变得很大。可以在设置里把缓存目录改到其他盘，具体路径在设置的高级选项里。我把它改到了D盘的一个专门目录，系统盘空间压力小了很多。
工作台隔离。每个工作台空间是独立的，但共享同一个Node.js环境。如果两个项目依赖不同版本的同一个包，可能会有冲突。建议在项目目录里用独立的package.json管理依赖，WorkBuddy会自动识别并使用项目本地的依赖版本。
对话记录导出。WorkBuddy的对话记录默认存在本地，可以在设置里导出为Markdown格式。这个功能在做模型对比时很有用，能把三个模型的完整对话历史导出后并排对比。
提示：WorkBuddy的工作台模式适合做这种多模型对比测试，但如果你只是日常开发，直接用本地IDE加模型API的方式可能更灵活。工具的选择取决于你的具体场景，没有绝对的好坏。
7. 我的选择与后续扩展思路
两天测试跑下来，如果让我选一个模型来继续开发这个3D游戏原型，我会选Step 5 Preview。原因不是它在每个维度都最强，而是它的代码结构最适合继续迭代。模块化的组织方式让我能快速定位和修改功能，对象池的使用说明它在性能方面有前瞻性考虑，修复问题时顺手优化代码的习惯也让我省了不少事。
DeepSeek V4 Pro适合快速验证想法的场景。单文件、零配置、双击就能跑，如果你只是想快速看看某个玩法是否可行，它的效率最高。但一旦要在此基础上做正式开发，代码组织的短板就会暴露出来。
GLM5.3的表现中规中矩，健壮性处理是亮点，但核心功能的实现精度还需要提升。它在中文语境的理解上有些优势，如果你用中文描述复杂需求，它可能比其他两个模型理解得更准确。
后续如果要扩展这个原型，我打算沿着几个方向走：一是把物品系统做成可配置的，支持不同类型的收集物和不同的分值；二是加入简单的音效反馈，提升操作感；三是把UI系统独立出来，方便换皮肤和适配不同屏幕尺寸。这些扩展在Step 5 Preview的模块化结构下做起来会比较顺手。
最后分享一个我在测试中发现的小技巧：让模型生成代码时，在提示词里加一句“请考虑后续扩展的便利性，把可能变化的部分做成可配置的参数”。这句话能让模型在生成代码时多一层思考，产出的代码往往会有更好的扩展性。我试过在三个模型上都加这句话，Step 5 Preview和GLM5.3的响应最明显，生成的代码里多了配置文件或常量定义区。这个技巧不复杂，但效果很实在。
