最近在 WorkBuddy 里面又测试了一个新模型：Step 5 Preview。

从官方给出的定位来看，Step 5 Preview 是一款面向真实 Agentic 任务的旗舰模型，重点放在软件工程、专业知识工作这些需要模型持续执行的复杂任务上，金融也是它比较强调的一个方向。

模型采用稀疏 MoE 架构，总参数量 600B，但每个 Token 实际激活 27B 参数，同时支持 1M 上下文和视觉输入。

官方这次还专门提到了一个点：智能和成本之间的 Pareto Frontier。

简单理解，就是在保持较强模型能力的同时，把实际任务的使用成本继续往下压。官方公布的数据里，Step 5 Preview 在相近智能水平下，任务成本也明显低于一些同级模型。

不过这些 Benchmark 看起来都挺漂亮，放到真实的 Agent 任务里面到底怎么样，还是得实际跑一次才知道。

所以这次我直接把它放进 WorkBuddy 里面，和 DeepSeek V4 Pro、GLM5.3 做一次相同任务的对比。

直接让三个模型从零开始，做一个能真正操作的 3D Minecraft 小游戏。

3D Minecraft 小游戏制作

这次测试做一个 3D Minecraft 小游戏，工具统一使用 WorkBuddy，三个模型也全部使用同一套提示词：

创建一个 Minecraft 风格的 3D 小岛。 玩家第一人称进入世界。 包含草地、树木、河流、山体、小木屋。 WASD 移动，鼠标控制视角。 左键破坏方块，右键放置方块。 加入昼夜变化和太阳移动。

这次主要测试三个模型，分别是 Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3。

别看这段提示词比较短，我反而觉得这种测试更能看出模型的差距。

因为提示词里面只规定了最终要实现什么，并没有告诉模型应该使用什么技术方案，也没有规定项目结构和实现路径。

所以最后能做成什么样，基本就看模型自己怎么理解、拆解和执行任务了。

Step 5 Preview

先来看看 Step 5 Preview 的制作流程。

第一步，先检测当前环境，然后对任务进行拆分。

第二步，开始进行代码编写。

第三步，代码完成以后，模型会自己测试游戏能不能正常运行。

我觉得第三步其实是整个流程里面比较关键的一步。

因为项目最后能不能直接交付，很大程度上就看模型有没有把测试和修复这一步做好。

从截图里面也能看出来，模型并不是代码写完以后就直接结束，而是在不断检查项目的运行状态。

一方面通过浏览器的报错信息查找代码问题，另一方面还会通过截图检查实际游戏画面，比如页面有没有正常渲染、组件有没有丢失、UI 有没有出现异常。

也就是说，一个是看代码和报错，一个是直接看最终页面。

两种方式结合起来不断测试和修改，直到项目可以正常运行。

后面模型甚至还会自己进入这个 3D 项目里面实际操作一下，检查移动、交互这些功能有没有问题。

当没有发现其他明显问题后，这个项目才算真正完成，可以直接交付。

最后还有一个小细节。

模型会申请删除权限，把前面生成的测试文件和多余文件删除，只留下最终需要的项目文件，让整个目录保持干净。

整个流程看起来步骤并不复杂，但我觉得关键还是第三步的自动测试和修复。

大家应该多少都用 AI 写过一些小 Demo。

有时候模型代码写完以后，看起来任务结束了，结果打开页面才发现这里有 Bug、那里不能点击。

然后我们再把问题告诉 AI：

“这里有 Bug，帮我修改一下。”

模型又得重新读取上下文、重新定位问题，再修改一轮。

这样一来一回，不仅整个任务的战线被拉长了，Token 消耗也会继续增加。

所以模型能不能在第一次交付前主动发现这些问题，其实还挺重要的。

模型制作时间为55分钟

消耗tokens为17M左右tokens消耗金额在12块左右。

一千多万的tokens消耗金额只有12块，这样来看的确比较优惠，因为在模型在自我检测代码这块消耗时间比较久所以tokens消化当然也会多一些。

DeepSeek V4 Pro

接下来让 DeepSeek V4 Pro 使用完全相同的任务再执行一次，看看最终效果。

DeepSeek V4 Pro 整体流程和前面的 Step 5 Preview 差不多。

也是先检测环境、编写代码，然后测试项目。

不过到了第三步的检测和修复环节，两边的差距就开始出来了。

从执行过程里面可以看到，DeepSeek V4 Pro 有不少深度思考内容，也确实检测到了一些 Bug，并进行了修改。

但这些思考最后并没有完全反馈到最终交付结果里面。

项目完成以后，我先实际打开 Demo 看了一下。

第一个问题就出现了：

我进不去游戏。

重新启动项目以后，这次可以正常进入。

进入以后，页面整体没有太大问题。

物品栏这些基础元素都已经做出来了，方块的放置和破坏功能也可以正常使用。

但是很快又发现了第二个问题。

人物无法移动。

WASD 和空格跳跃键都没有任何反馈。

于是我把这个问题重新交给模型，让它进行第二次处理。

最后问题还是正常修复了。

模型定位到了两个主要原因，一个是碰撞检测出现假阳性，另一个是输入开关绑定错误。

修复以后重新进入游戏，这次人物已经可以正常移动和操作。

所以 DeepSeek V4 Pro 最终也完成了这个项目。

只是和 Step 5 Preview 相比，它在第一次交付之前的主动测试还不够完整，一些实际交互问题需要我进入游戏以后才能发现，再让模型进行第二轮修复。

DeepSeek V4 Pro第一次制作时间消耗了35分钟。

虽然比Step 5 Preview快了不少，但是加上后续的二次修改时间14分钟左右，所以时间总体上比Step 5 Preview大差不差。

另一个就是tokens消化了，那这个就是DeepseekV4Pro的优势了。

DeepseekV4Pro在官网上的标价要比Step 5 Preview便宜些，实际使用中也没有感觉显著的便宜。

当然这个是deepseek官方的高峰期的价格，低峰期价格应该还会更低。

GLM5.3

最后再使用完全相同的提示词测试一下 GLM5.3。

整个执行流程其实也比较类似。

先检测环境，然后写代码，接着测试、修改，最后完成项目交付。

不过这次测试 GLM5.3 的时候，在 WorkBuddy 里面遇到了一个小问题。

模型存在速率限制，连续使用一段时间以后会被限速。

好在出现限速的时候，整个项目已经基本完成，所以对最终结果影响不算特别大。

接下来直接进入游戏看看实际效果。

从视频里面可以看到，整体完成度还是可以的。

游戏可以正常运行，人物移动和基础交互也没有问题。

另外 GLM5.3 还对状态栏里面的方块图标做了一些渲染优化，视觉效果会更完整一些。

不过也有一个比较明显的小瑕疵。

水面的处理有点问题，最后做成了一种方块向下凹陷的效果，看起来不太自然。

这一部分没有继续处理好，也不排除和后面模型出现限速有一定关系。

GLM5.3 在时间上的确要快一些，而且整个过程是一次性制作完成的，中间没有进行二次人为干预，最终耗时 33 分钟。

不过这里有个比较特殊的情况，就是 GLM5.3 在制作过程中被限速了。好在限速之前项目已经顺利制作完成，如果项目还没做完就碰到限速，那就比较恼火了。

所以这个 33 分钟的成绩其实也比较特殊。如果没有触发限速，按照正常的执行情况来看，我估计完整耗时应该也会在 45 分钟左右。

然后就是价格。

这次在 WorkBuddy 中使用 GLM5.3，一共消耗了 271 WorkBuddy 积分。

因为 WorkBuddy 积分和模型实际 Token 成本之间没办法直接换算，所以这里也很难做一个准确的价格对比。不过GLM5.3 的使用成本肯定要比上面两个模型更高一些。

最后

三个模型全部跑完以后，这次测试的差别其实还挺明显。

如果只看最后的结果，三个模型都把 3D Minecraft 小游戏做出来了，基础的移动、方块交互、场景这些功能也基本都能实现。

但如果把整个制作过程放在一起看，差别主要出现在了第一次交付之前，模型到底会自己检查到什么程度。

Step 5 Preview 花的时间最长，55 分钟左右，而且消耗了大约 1700 万 Tokens。

但它花了不少时间在浏览器测试、截图检查、实际进入游戏操作以及持续修复上，最后第一次交付出来的项目基本就可以直接玩。

DeepSeek V4 Pro 第一次只用了 35 分钟，看起来快了不少，但后面因为人物无法移动这些问题，又增加了大约 14 分钟的二次修改。

这样算下来，两边最终耗时其实已经比较接近了。

GLM5.3 这次 33 分钟就完成了，而且没有人工二次干预，不过中途碰到了模型限速，所以这个时间也只能作为这一次测试的参考。

这也是我这次测试 Step 5 Preview 感受比较明显的地方。

它并不是急着把代码写完然后结束任务，而是愿意继续花时间，把「写代码—运行—检查—修改—再测试」这个过程自己跑下去。

对于这种几十分钟甚至更长的 Agent 任务来说，我反而更看重这一点。

因为模型第一次交付的时候少留几个 Bug，后面人工重新介入、重新描述问题、再跑一轮修改的时间也就省下来了。

从这次 3D 游戏测试来看，Step 5 Preview 官方强调的长期任务执行和软件工程能力，至少在 WorkBuddy 这个案例里面，还是能比较直观地看出来的。