1. 三款模型同台竞技：这个对比测试到底在测什么

三个大模型，同一个3D游戏需求，同样的对话式开发流程，最后跑出来的东西到底差多少。这个测试的出发点其实很朴素——现在做AI辅助开发的人越来越多，但大部分人只盯着“能不能生成代码”，很少有人系统性地比较过不同模型在同一个完整项目里的表现差异。Step 5 Preview、DeepSeek V4 Pro、GLM5.3这三个模型，分别代表了不同的技术路线和训练侧重，把它们放在同一个3D游戏开发任务里跑一遍，能看出来的东西比跑分榜单直观得多。

我选择3D游戏作为测试载体，原因有几个。第一，3D游戏开发天然涉及多个技术栈的交叉——场景搭建、光照系统、物理碰撞、相机控制、交互逻辑、资源管理，这些模块之间的耦合度高，能充分暴露模型在复杂项目中的架构能力。第二，3D游戏有明确的视觉反馈，好不好一眼就能看出来，不像后端接口那样需要反复调试才能感知差异。第三，Three.js这个技术栈足够成熟，文档丰富，三个模型都有充分的训练数据覆盖，不会因为某个模型没见过某个API而产生不公平的偏差。

测试任务本身我设计得比较克制：一个基于Three.js的3D跑酷类小游戏，玩家控制一个方块在程序化生成的赛道上跳跃、躲避障碍、收集金币，包含完整的计分系统和游戏结束判定。这个需求描述控制在200字以内，不提供任何额外的技术细节或代码示例，完全依赖模型自身的理解能力和代码生成能力。每个模型都通过对话式开发工具WorkBuddy来驱动，保证交互方式一致，排除工具差异带来的干扰。

注意：测试用的提示词完全一致，不针对任何模型做特殊优化。这意味着如果某个模型对提示词的理解有偏差，那也是它自身能力的一部分，不做额外补偿。

为什么要用WorkBuddy而不是直接调API？因为对话式开发工具更接近真实开发者的使用场景。大部分人在实际工作中不会手写HTTP请求去调模型，而是通过一个集成的开发环境来交互。WorkBuddy的工作台模式支持多轮对话、文件管理、实时预览，这些功能会影响模型的输出质量——比如模型能不能看到自己上一轮生成的代码、能不能感知到运行时的报错信息，这些都会显著影响最终结果。用统一的工具来跑，测出来的差异才更有参考价值。

三个模型的版本信息需要交代清楚：Step 5 Preview是较新的预览版本，DeepSeek V4 Pro是深度求索的旗舰模型，GLM5.3来自智谱。这三个模型在代码生成领域都有不错的口碑，但各自的训练数据分布、上下文窗口大小、推理策略都有差异。这些差异在简单任务上可能看不出来，但在3D游戏这种需要多轮迭代、跨文件协调的场景里，会被放大得很明显。

2. 开发环境搭建与测试流程设计

2.1 WorkBuddy工作台的配置要点

WorkBuddy的工作台模式是我这次测试的主要操作界面。安装过程不复杂，但有几个配置项直接影响后续的开发体验，值得单独说一下。首次启动后，建议先把系统缓存目录改到非系统盘，因为3D游戏开发过程中会产生大量的临时文件和预览缓存，默认放在C盘的话，一个下午就能吃掉好几个G的空间。在设置里找到“缓存目录”选项，改到一个空间充裕的盘符就行，改完之后重启工作台生效。

工作台的对话记录存储也值得关注。默认情况下，所有对话历史都存在本地SQLite数据库里，时间长了这个文件会变得很大。如果你打算长期用WorkBuddy做开发，建议定期清理不需要的对话记录，或者在设置里开启自动归档。我实测下来，连续开发一周左右，对话记录文件能到200MB以上，虽然不影响功能，但备份和迁移的时候会比较麻烦。

另一个容易被忽略的点是WorkBuddy的Skill系统。工作台预装了一些常用的Skill，比如代码格式化、依赖检查、预览服务等。做3D游戏开发的时候，我建议把“实时预览”和“控制台输出捕获”这两个Skill打开。实时预览让你能直接在工具里看到游戏画面，不用切到浏览器；控制台输出捕获则能把运行时的报错信息自动喂给模型，省去手动复制粘贴的步骤。这两个功能对多轮迭代的效率提升非常明显。

提示：WorkBuddy的SSH连接器功能在本地开发时用不上，但如果你后续要把项目部署到远程服务器，这个功能可以省去很多配置麻烦。本地测试阶段可以先不管它。

2.2 三个模型的接入方式与参数设置

三个模型都通过WorkBuddy的模型接入功能来调用。Step 5 Preview和GLM5.3可以直接在模型列表里选择，DeepSeek V4 Pro需要手动配置一下API端点。接入的时候有几个参数需要留意：温度值统一设为0.7，这个值在代码生成任务里比较平衡，既不会太死板也不会太随机；最大输出长度设为8192个token，3D游戏的单文件代码量比较大，设太小会导致代码被截断；上下文窗口根据各模型的实际能力来设，Step 5 Preview和GLM5.3都支持较长的上下文，DeepSeek V4 Pro的上下文窗口稍小一些，但在这个项目里够用。

接入完成后，建议先跑一个简单的“Hello World”测试，确认模型能正常响应。有时候API端点配置正确但网络策略有问题，会导致请求超时。WorkBuddy的错误提示比较清晰，如果连接失败，先检查API密钥和端点地址，再检查网络策略设置。

2.3 测试任务的标准化描述

为了保证公平性，我给三个模型的任务描述完全一致。提示词是这样的：

用Three.js做一个3D跑酷小游戏，要求： 1. 玩家控制一个方块，在程序化生成的赛道上自动向前跑 2. 按空格键跳跃，可以躲避障碍物 3. 赛道上有金币可以收集，收集后加分 4. 撞到障碍物游戏结束，显示最终得分 5. 包含基本的场景光照和相机跟随 6. 所有代码放在一个HTML文件里，用CDN引入Three.js

这个描述刻意保持模糊，没有指定具体的实现方式。比如“程序化生成赛道”可以有很多种做法——无限循环的赛道段、随机生成的障碍物布局、基于噪声的地形生成等等。模型选择哪种方案，能反映出它的架构偏好和代码组织能力。“相机跟随”也没有指定是固定偏移还是平滑插值，这些细节的取舍能看出模型对游戏开发惯例的理解程度。

每个模型都进行最多5轮对话迭代。第一轮生成完整代码，后续轮次根据实际运行效果进行修正和优化。如果某个模型在第一轮就生成了可运行的代码，后续轮次用来增加细节；如果第一轮有问题，后续轮次用来排查和修复。5轮之后无论是否完美，都停止迭代，记录最终状态。

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

3.1 Step 5 Preview：架构清晰但细节粗糙

Step 5 Preview在第一轮就生成了一个结构相当完整的代码框架。它把游戏逻辑分成了几个清晰的模块：场景初始化、赛道生成器、玩家控制器、碰撞检测、计分系统。每个模块都有独立的函数封装，变量命名也比较规范。这种架构意识在代码生成模型里不算常见，大部分模型倾向于把所有逻辑塞在一个大函数里。

但细节上问题不少。赛道生成用的是最简单的“随机放置障碍物”方案，没有做赛道段的循环复用，导致跑了一段距离之后场景里的物体数量持续增长，帧率明显下降。跳跃的物理模拟也有问题——它用了一个固定的跳跃高度，没有考虑重力加速度的累积效应，导致连续跳跃时手感很怪。金币的碰撞检测用的是包围盒相交，但包围盒的尺寸设置偏大，经常出现“看起来没碰到但判定为收集”的情况。

第二轮迭代我让它修复帧率问题，它给出了一个对象池的方案，把超出视野的障碍物回收复用。这个思路是对的，但实现的时候有个bug——回收的物体没有重置位置和状态，导致复用后的障碍物出现在奇怪的位置。第三轮修复了这个bug，但对象池的容量设得太小，高速奔跑时还是会出现物体突然消失的情况。

Step 5 Preview的代码风格比较“教科书”，注释写得很详细，但有些注释是废话，比如“// 设置变量x为10”这种。它在处理Three.js的API时偶尔会用一些已经废弃的方法，比如Geometry而不是BufferGeometry，虽然Three.js做了兼容处理，但控制台会报警告。

3.2 DeepSeek V4 Pro：物理模拟最扎实

DeepSeek V4 Pro第一轮生成的代码在架构上不如Step 5 Preview那么工整，所有逻辑都写在一个大的init函数和animate循环里，函数拆分不够细致。但它的物理模拟明显更扎实。跳跃用了基于速度的积分方式，重力加速度、初速度、跳跃高度之间的关系处理得很自然，连续跳跃的手感接近商业游戏的水平。

赛道生成方面，DeepSeek V4 Pro用了一个基于种子的伪随机算法，虽然也是随机放置障碍物，但通过种子控制保证了每次运行的赛道布局一致，方便调试。这个细节说明它在生成代码时考虑了开发者的实际使用场景。金币的碰撞检测用了球体检测而不是包围盒，判定更精确，很少出现误判。

不过DeepSeek V4 Pro在代码组织上有个问题：它倾向于把所有东西都塞进一个文件里，而且变量命名比较随意，a、b、temp这种命名到处都是。第一轮生成的代码有将近800行，全部在一个<script>标签里，找特定逻辑的时候需要滚动很久。第二轮我让它按功能拆分模块，它拆是拆了，但模块之间的依赖关系处理得不太好，出现了几个循环引用的问题。

第三轮修复循环引用之后，代码质量明显提升。DeepSeek V4 Pro在后续迭代中表现出了很强的“理解意图”能力——我说“跳跃手感有点飘”，它能准确理解是重力参数需要调整，而不是去改跳跃的触发逻辑。这种对模糊反馈的准确解读，在实际开发中非常省时间。

3.3 GLM5.3：迭代响应最快但稳定性一般

GLM5.3的响应速度是三个模型里最快的，第一轮生成完整代码只用了不到30秒。代码风格介于前两者之间，有一定的模块化意识，但不如Step 5 Preview那么系统。它的赛道生成方案比较有意思——用了预制的赛道段模板，每个模板包含固定的障碍物和金币布局，然后随机拼接这些模板。这个方案在性能上比纯随机放置要好，但模板的多样性有限，跑久了会发现赛道重复。

GLM5.3最大的问题是稳定性。第一轮生成的代码里有一个明显的语法错误——一个函数定义缺少了闭合的大括号，导致整个脚本无法运行。WorkBuddy的控制台捕获到了这个错误并反馈给模型，第二轮修复了。但第三轮我让它增加一个“加速道具”功能时，它引入了一个新的bug：道具的碰撞检测和金币的碰撞检测用了同一个变量名，导致收集金币时也会触发加速效果。

第四轮修复了这个变量冲突，但代码里又出现了几个未定义的变量引用。GLM5.3在快速迭代时似乎容易“顾此失彼”，每次修改都可能引入新的问题。不过它的优势在于响应快，如果你愿意多花几轮对话来打磨，最终也能得到一个可用的版本。第五轮之后，游戏基本能正常运行，但代码里还有一些冗余的逻辑和未使用的变量。

3.4 三模型关键指标对比

从表格能看出来，DeepSeek V4 Pro在物理模拟和意图理解上优势明显，适合对游戏手感有要求的场景。Step 5 Preview的代码架构最规范，适合需要后续维护和扩展的项目。GLM5.3的响应速度最快，适合快速原型验证，但需要预留更多轮次来修复问题。

4. 实操过程中的关键细节与避坑经验

4.1 对话式开发工具的缓存管理

用WorkBuddy做3D游戏开发，缓存目录的管理是个容易被忽视但影响很大的问题。Three.js的项目在预览时会生成大量的着色器编译缓存、纹理缓存和几何体缓存。默认情况下这些缓存都存在系统盘的用户目录下，一个中等复杂度的3D场景跑上几十次预览，缓存就能到1-2GB。如果你的系统盘空间紧张，很快就会收到磁盘空间不足的警告。

把缓存目录改到D盘或者其他数据盘是个好习惯。在WorkBuddy的设置里找到“系统缓存目录”选项，改完之后需要重启工作台。改完之后建议手动清理一次旧缓存，不然旧的缓存文件还会占着空间。清理的时候注意不要删掉正在使用的项目的缓存，否则下次预览会重新编译着色器，第一次加载会明显变慢。

另外，WorkBuddy的对话记录文件也值得定期清理。每次和模型对话都会在本地数据库里存一份完整的对话历史，包括代码片段和运行日志。做3D游戏开发时，一轮对话可能就包含几百行代码，数据库膨胀得很快。我一般每周清理一次，把已经完成的项目对话归档或者删除。WorkBuddy支持按项目筛选对话记录，清理起来还算方便。

4.2 模型切换时的上下文处理

在WorkBuddy里切换模型时，有一个细节需要注意：默认情况下，切换模型后新的模型看不到之前的对话历史。这意味着如果你用Step 5 Preview生成了第一版代码，然后切换到DeepSeek V4 Pro想让它继续优化，DeepSeek V4 Pro是不知道之前发生了什么。你需要手动把之前的代码和问题描述复制到新的对话里。

WorkBuddy有个“跨对话记忆”的Skill可以解决这个问题，但需要手动开启。开启之后，切换模型时可以选择“继承上下文”，把之前的对话摘要传递给新模型。不过这个功能不是完美的——摘要会丢失一些细节，特别是代码的具体实现。我的做法是，切换模型时直接把当前代码文件作为附件上传，然后在提示词里简要说明之前遇到的问题和已经尝试过的方案。这样虽然多花一点时间，但能保证新模型有足够的上下文来做出合理的修改。

注意：不同模型的上下文窗口大小不一样。Step 5 Preview和GLM5.3的上下文窗口较大，可以一次性传入较长的代码文件。DeepSeek V4 Pro的上下文窗口稍小，如果代码超过一定长度，需要分段传入或者只传入关键部分。

4.3 3D游戏开发中的常见性能陷阱

三个模型在生成3D游戏代码时，都或多或少踩了一些性能陷阱。这些陷阱在代码审查时不容易发现，但实际运行起来会明显影响体验。我整理了几个最常见的：

陷阱一：每帧创建新对象。在animate循环里用new THREE.Vector3()或者new THREE.Color()创建临时对象，会导致垃圾回收频繁触发，帧率波动明显。正确的做法是在循环外面创建好临时对象，循环里复用。Step 5 Preview和GLM5.3都犯过这个错误，DeepSeek V4 Pro在第一轮就避免了。

陷阱二：碰撞检测的复杂度。如果场景里有N个障碍物和M个金币，朴素的碰撞检测是O(N*M)的复杂度。当N和M都比较大时，每帧的计算量会很大。正确的做法是用空间分割或者简单的距离预筛选来减少检测次数。三个模型都没有主动做这个优化，需要手动提醒。

陷阱三：材质和几何体的复用。每个障碍物都创建独立的材质和几何体会导致显存占用飙升。正确的做法是共享材质和几何体实例，只改变位置和旋转。DeepSeek V4 Pro在第二轮迭代时主动做了这个优化，另外两个模型需要明确要求才会做。

陷阱四：阴影贴图的分辨率。默认的阴影贴图分辨率可能过高，导致渲染开销大。对于小游戏来说，1024x1024的分辨率通常就够了，不需要用到2048x2048。这个参数在Three.js的DirectionalLight里设置，三个模型默认用的都是2048，需要手动调低。

4.4 提示词工程的实战技巧

经过这次对比测试，我总结了几条在WorkBuddy里驱动模型做3D游戏开发的提示词技巧：

第一，第一轮提示词要“留白”。不要把所有细节都写死，给模型留出架构决策的空间。比如“程序化生成赛道”比“用预制的赛道段模板随机拼接”更好，因为前者能看出模型的方案选择能力，后者只是执行指令。

第二，反馈要具体但不要过于技术化。说“跳跃手感有点飘”比说“重力加速度参数需要从-9.8调整到-20”更好。前者测试的是模型对游戏体验的理解，后者只是让它改一个数字。DeepSeek V4 Pro在理解“手感”这类模糊反馈上表现最好。

第三，每轮只聚焦一个问题。不要在一轮对话里同时要求修复bug、增加功能、优化性能。模型在多任务并行时容易顾此失彼，GLM5.3尤其明显。一轮解决一个问题，虽然总轮次多了，但每轮的质量更高。

第四，善用WorkBuddy的控制台捕获功能。运行时报错信息直接喂给模型，比手动描述错误现象要准确得多。WorkBuddy的控制台捕获Skill能自动把错误堆栈和日志附加到对话里，模型看到原始错误信息后，修复的准确率明显提升。

5. 常见问题与排查技巧实录

5.1 模型生成的代码无法运行怎么办

这是最常见的问题，三个模型都出现过。排查思路按优先级排列：

第一步，看控制台报错。WorkBuddy的控制台捕获功能会显示具体的错误信息和行号。大部分情况下，错误信息足够定位问题。常见的错误类型包括：语法错误（缺少括号、分号）、API使用错误（调用了不存在的方法）、变量未定义（拼写错误或作用域问题）。

第二步，检查Three.js的版本兼容性。三个模型在生成代码时，有时会混用不同版本的Three.js API。比如Geometry是旧版API，BufferGeometry是新版API，混用会导致运行时错误。在HTML文件里明确指定Three.js的版本号，比如https://cdn.jsdelivr.net/npm/three@0.160.0/build/three.min.js，可以减少这类问题。

第三步，逐段注释排查。如果错误信息不够明确，把代码分成几段，逐段注释掉，看哪一段注释后错误消失。这个方法比较笨但很有效，特别是对于逻辑错误而不是语法错误的情况。

第四步，让模型自己排查。把完整的错误信息和相关代码片段发给模型，让它分析原因。DeepSeek V4 Pro在这方面的准确率最高，Step 5 Preview次之，GLM5.3有时会给出错误的诊断。

5.2 游戏运行卡顿的优化方向

3D游戏卡顿的原因很多，按影响程度从大到小排列：

我实测下来，最常见的卡顿原因是每帧创建新对象和碰撞检测复杂度过高。前者通过代码审查就能发现，后者需要实际运行才能感知。建议在开发阶段就打开浏览器的性能分析工具，定期检查帧率和GC情况。

5.3 模型“忘记”之前的要求怎么处理

多轮对话中，模型有时会“忘记”之前的要求。比如第一轮要求“按空格键跳跃”，到第三轮修改其他功能时，跳跃功能被意外删除了。这种情况在GLM5.3上出现的频率最高，Step 5 Preview和DeepSeek V4 Pro相对较少。

处理方法是：在每轮对话的开头，用一两句话重申核心要求。比如“保持之前的跳跃和金币收集功能不变，现在增加一个加速道具”。这样模型在修改时会有意识地保留已有功能。另外，WorkBuddy的“自定义指令”功能可以设置一些全局规则，比如“每次修改代码时保留所有已有功能”，这个规则会对后续所有任务生效，减少功能丢失的情况。

如果功能已经被删除了，最直接的恢复方法是让模型对比修改前后的代码差异，找出被删除的部分并恢复。WorkBuddy的对话历史里保留了每一轮的代码版本，可以手动对比。DeepSeek V4 Pro在对比代码差异方面表现最好，能准确指出哪些行被删除了。

5.4 不同模型间的代码迁移问题

有时候你会想用模型A生成的代码，让模型B来继续优化。这种跨模型迁移有几个坑需要注意：

第一，代码风格差异。不同模型的代码风格不一样，模型B在修改模型A的代码时，可能会把风格改得面目全非。如果你在意代码风格的一致性，建议在迁移时明确要求“保持现有代码风格”。

第二，API使用习惯差异。比如Step 5 Preview喜欢用requestAnimationFrame做游戏循环，DeepSeek V4 Pro喜欢用setInterval。迁移时如果不统一，可能会出现两个循环同时运行的问题。

第三，变量命名冲突。模型B在添加新功能时，可能会使用和模型A已有变量相同的名字，导致冲突。迁移时建议先让模型B通读一遍现有代码，了解已有的变量和函数命名。

我的做法是，跨模型迁移时，先让新模型“阅读并总结”现有代码的结构和关键变量，然后再提出修改要求。这样虽然多一轮对话，但能避免很多低级错误。

6. 三模型选型建议与后续扩展方向

6.1 什么场景选什么模型

基于这次实测，我给三个模型画一个适用场景的画像：

Step 5 Preview适合需要长期维护和扩展的项目。它的代码架构最规范，模块划分清晰，变量命名合理，后续接手的人能比较快地理解代码结构。如果你打算把一个原型发展成正式项目，用Step 5 Preview打底会比较省心。但它在物理模拟和性能优化上需要更多手动干预。

DeepSeek V4 Pro适合对游戏体验有要求的项目。它的物理模拟最扎实，对模糊反馈的理解最准确，迭代过程中引入新bug的频率最低。如果你做的是动作类、跑酷类游戏，手感很重要，DeepSeek V4 Pro是首选。它的代码风格比较随意，但后期可以手动整理。

GLM5.3适合快速原型验证。它的响应速度最快，能在短时间内生成大量代码，适合在项目初期快速试错。但它的稳定性一般，需要预留更多轮次来修复问题。如果你只是想快速验证一个玩法想法，GLM5.3的效率最高。

6.2 用WorkBuddy做3D游戏开发的进阶技巧

WorkBuddy的工作台模式还有一些进阶用法，能进一步提升3D游戏开发的效率：

自定义Skill的组合使用。WorkBuddy支持把多个Skill组合成一个工作流。比如“代码生成→语法检查→预览启动→控制台捕获”可以串成一个自动化流程，每次模型生成代码后自动执行后续步骤。这个功能在设置里的“Skill编排”里配置，配置一次之后后续所有项目都能用。

对话记录的导出与复用。WorkBuddy支持把对话记录导出为Markdown或JSON格式。如果你在某个项目里调出了一组好用的提示词，可以导出保存，下次做类似项目时直接导入复用。我一般会把“3D游戏开发”相关的对话记录单独归档，积累了一套提示词模板。

本地部署的考虑。如果你对数据隐私有要求，WorkBuddy支持本地化部署。本地部署的版本功能上略有精简，但核心的对话和代码生成功能都在。本地部署对硬件有一定要求，建议至少16GB内存和一块支持CUDA的显卡。本地部署的模型响应速度取决于你的硬件配置，高端显卡上能接近云端版本的速度。

6.3 这个测试后续可以怎么扩展

这次测试只覆盖了3D跑酷这一个品类，后续可以从几个方向扩展：

品类扩展。试试塔防、解谜、射击等不同类型的3D游戏，看模型在不同玩法下的表现差异。不同品类对物理模拟、AI行为、关卡设计的要求不一样，能更全面地评估模型能力。

复杂度扩展。增加多人联机、存档系统、排行榜等功能，测试模型在更复杂系统下的架构能力。多人联机涉及网络同步和状态管理，对模型的系统设计能力要求更高。

技术栈扩展。除了Three.js，还可以试试Babylon.js、PlayCanvas等其他的3D引擎。不同引擎的API设计差异很大，能看出模型的泛化能力。

评估维度扩展。除了代码质量和运行效果，还可以加入代码可读性、注释质量、安全性等维度的评估。特别是安全性，游戏代码里如果有注入风险或者资源泄露问题，在实际项目中会很麻烦。

我个人在实际操作中的体会是，模型之间的差异在简单任务上不明显，但在3D游戏这种多模块、多轮迭代的场景里，差异会被显著放大。选模型不是选“最好的”，而是选“最适合当前项目阶段和需求的”。原型阶段用GLM5.3快速试错，核心玩法确定后用DeepSeek V4 Pro打磨手感，最后用Step 5 Preview整理架构准备长期维护，这个组合策略在实际项目中比较实用。