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 PreviewDeepSeek V4 ProGLM5.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的响应最明显生成的代码里多了配置文件或常量定义区。这个技巧不复杂但效果很实在。