Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三模型生成 3D 游戏实测对比

1. 三款模型同台竞技的背景与选型逻辑

1.1 为什么挑这三个模型做同一件事

最近圈子里讨论度最高的三件事，一个是 Step 5 Preview 的发布，一个是 DeepSeek V4 Pro 在代码生成上的持续迭代，还有一个是 GLM5.3 在工程化场景里的落地表现。单独看每个模型的跑分和官方演示，说实话参考价值有限——跑分高不代表能干活，演示漂亮不代表你拿到手里能复现。所以我决定做一件最笨但最有效的事：让它们仨做同一个项目，一个完整的 3D 游戏，从零到能跑起来。

选 3D 游戏作为测试载体，不是随便拍的。3D 游戏这个场景天然覆盖了模型能力的多个维度：数学计算（向量、矩阵、四元数）、图形学基础（光照、投影、渲染管线）、状态管理（游戏循环、实体系统）、资源组织（模型加载、纹理管理）、以及最关键的——跨文件代码组织能力。一个 3D 游戏不可能塞在一个文件里，模型必须理解模块划分、接口约定、依赖关系，这比让它写一个算法题或者一个单文件脚本要难得多。

另外，3D 游戏还有一个隐性门槛：它需要模型对空间有直觉。很多模型写 2D 逻辑没问题，一到 3D 就开始犯迷糊，比如把 Y 轴和 Z 轴搞混、相机朝向算反、光照方向弄错。这些错误在代码层面看不出来，一跑就露馅。

1.2 测试环境的统一约定

为了保证公平，三个模型我用完全相同的输入。提示词是一段自然语言描述，大意是：用 Three.js 做一个 3D 小游戏，玩家控制一个角色在场景里移动，有障碍物、有可收集物品、有简单的计分系统，相机跟随角色，支持键盘操作。没有给任何代码片段，没有给文件结构，全靠模型自己发挥。

运行环境统一为 Node.js 20 + Vite 5，浏览器用 Chrome 最新稳定版。每个模型生成的代码我都单独建目录，互不干扰。评测维度我列了个表，后面每个模型都会按这个表打分：

这个权重分配是有讲究的。可运行性占最高，因为一个跑不起来的项目其他都是空谈。3D 空间正确性排第二，这是 3D 游戏区别于普通项目的核心。代码组织排第三，因为实际开发中你不可能只写一次，后续维护成本很重要。

提示：做模型对比测试时，一定要固定输入和环境。我见过太多人对比时给不同模型不同的提示词，或者一个用中文一个用英文，最后得出的结论完全没有参考价值。

2. Step 5 Preview 实测：惊喜与意外并存

2.1 首次生成的整体表现

Step 5 Preview 给我的第一印象是"敢写"。它生成的代码量是三个模型里最大的，文件结构也最完整。它自动创建了这样的目录结构：

src/ main.js game/ Game.js Player.js World.js Collectible.js utils/ math.js input.js config/ constants.js

这个结构说实话比我预期的好。很多模型生成 3D 游戏时会把所有东西塞进一个 main.js，Step 5 Preview 主动做了模块拆分，而且拆分逻辑是合理的——游戏主循环、玩家、世界、可收集物各占一个文件，工具函数和配置也单独抽出来了。这说明它对"工程化"这件事有概念。

但问题也来了。文件多了之后，跨文件的接口约定就成了考验。Step 5 Preview 在 Game.js 里调用 Player 的方法时，参数顺序和 Player.js 里的定义对不上。比如 Game.js 里写的是player.update(deltaTime, input)，但 Player.js 里定义的是update(input, deltaTime)。这种错误在单文件里不会出现，一旦跨文件就暴露了。

2.2 3D 空间逻辑的细节考察

我重点看了它的相机跟随逻辑。Step 5 Preview 用的是经典的第三人称跟随相机，思路是对的：相机位置 = 玩家位置 + 偏移量，然后 lookAt 玩家。但它在计算偏移量时犯了一个典型错误——没有考虑玩家的旋转。

// Step 5 Preview 生成的相机逻辑 const cameraOffset = new THREE.Vector3(0, 5, 10); camera.position.copy(player.position).add(cameraOffset); camera.lookAt(player.position);

这段代码在玩家不旋转时没问题，但一旦玩家转向，相机还是固定在世界的正后方，玩家转个身就看不到前方了。正确的做法应该是把偏移量用玩家的旋转矩阵变换一下，让相机始终在玩家的"背后"。

// 修正后的逻辑 const cameraOffset = new THREE.Vector3(0, 5, 10); cameraOffset.applyQuaternion(player.quaternion); camera.position.copy(player.position).add(cameraOffset); camera.lookAt(player.position);

这个错误很典型，说明模型理解"相机跟随"这个概念，但对"跟随"在 3D 空间里的数学含义理解不够深。它知道要加偏移量，但不知道偏移量需要跟着旋转走。

2.3 碰撞检测的实现方式

Step 5 Preview 的碰撞检测用的是最简单的包围盒检测，思路没问题，但实现上有性能隐患。它在每一帧里对每个可收集物都做一次距离计算，可收集物多了之后就是 O(n) 的复杂度。对于小场景够用，但这不是一个可扩展的写法。

// Step 5 Preview 的碰撞检测 collectibles.forEach(item => { const distance = player.position.distanceTo(item.position); if (distance < 1.5) { item.collect(); } });

更合理的做法是用空间分区或者简单的距离预筛选。不过考虑到这是个 demo 级别的项目，这个实现也能接受，只是我会在代码 review 时提出来。

2.4 Step 5 Preview 的实操心得

用下来我的感受是，Step 5 Preview 在"代码组织"和"工程结构"上明显强于另外两个模型，它生成的代码更像一个真实项目而不是一个 demo。但它在 3D 数学细节上不够严谨，需要人工修正的地方主要集中在空间变换这块。

注意：Step 5 Preview 生成的代码里，向量运算大量使用了applyQuaternion和applyMatrix4，这些方法在 Three.js 里是原地修改的，会改变原向量。如果你不小心把配置里的常量向量直接拿来用，会被改掉。我踩过这个坑，调试了半小时才发现是常量被污染了。

3. DeepSeek V4 Pro 实测：稳但保守

3.1 代码风格与结构选择

DeepSeek V4 Pro 生成的代码风格和 Step 5 Preview 完全不同。它选择了更保守的单文件加少量模块的方案，主要逻辑都在一个 main.js 里，只把配置抽了出来。这个选择不能说是错的，对于 demo 项目来说单文件确实更方便查看，但从工程角度就不如 Step 5 Preview 的分层清晰。

它的代码有一个明显特点：注释非常多。几乎每个函数上面都有 JSDoc 风格的注释，参数和返回值都标得很清楚。这个习惯很好，说明模型在生成代码时考虑了可读性。但注释多也有副作用，代码整体显得比较冗长，同样的功能它用了更多的行数。

3.2 3D 空间逻辑的准确性

DeepSeek V4 Pro 在 3D 数学上明显更严谨。它的相机跟随逻辑一次就写对了，用了四元数变换偏移量，而且它还额外加了一个平滑插值，让相机移动更自然：

// DeepSeek V4 Pro 的相机逻辑 const idealOffset = new THREE.Vector3(0, 5, 10); idealOffset.applyQuaternion(player.quaternion); idealOffset.add(player.position); camera.position.lerp(idealOffset, 1 - Math.pow(0.001, deltaTime)); camera.lookAt(player.position);

这个lerp的写法很专业，用Math.pow做帧率无关的插值，说明模型对游戏循环的时间步长有理解。这个细节很多人类开发者都不一定注意得到。

但 DeepSeek V4 Pro 也有它的问题。它在处理玩家移动时，把移动方向直接用了世界坐标，没有转换到玩家本地坐标。结果就是按 W 键时，不管玩家朝向哪，都是往世界的 Z 轴负方向走。这个在第三人称游戏里是错的，应该按玩家朝向走。

3.3 交互与游戏循环

DeepSeek V4 Pro 的游戏循环写得很标准，用了requestAnimationFrame加 deltaTime 的方式，帧率无关的更新逻辑处理得不错。键盘输入用了事件监听加状态对象的方式，比直接读event对象要合理。

计分系统它做得比较简单，就是一个变量加一，然后在 HUD 上更新。没有做连击、没有做分数动画，功能上够用但不够出彩。碰撞检测它用了Box3的intersectsBox方法，比 Step 5 Preview 的距离检测更准确，但性能上包围盒计算比距离计算要重。

3.4 DeepSeek V4 Pro 的实操心得

DeepSeek V4 Pro 给我的感觉是"稳"。它不会给你惊喜，但也不会给你惊吓。代码质量稳定，3D 数学准确，注释完整，适合那种你不想花太多时间调试、只想快速拿到一个能跑的版本的场景。

提示：DeepSeek V4 Pro 生成的代码里，lerp的插值系数用了1 - Math.pow(0.001, deltaTime)，这个写法在 deltaTime 很大时（比如切标签页回来）会导致相机瞬移。如果你要做生产级项目，建议加一个 deltaTime 的上限，比如Math.min(deltaTime, 0.1)。

4. GLM5.3 实测：激进但有亮点

4.1 生成策略的差异

GLM5.3 是三个模型里最"激进"的。它没有用 Three.js 的默认渲染器配置，而是自己配了一套后处理管线，加了 bloom 和抗锯齿。这个选择很大胆，因为后处理管线配置错了很容易导致整个画面黑屏或者性能暴跌。

它生成的代码结构介于 Step 5 Preview 和 DeepSeek V4 Pro 之间，分了几个模块但没有 Step 5 Preview 那么细。它把渲染相关的逻辑单独抽了一个 Renderer.js，这个划分我觉得比另外两个模型都合理，因为渲染配置确实应该独立出来。

4.2 3D 空间与渲染细节

GLM5.3 在 3D 空间逻辑上表现不错，相机跟随和玩家移动都写对了。它额外做了一个细节：给玩家加了一个阴影投射，并且配置了阴影相机。这个细节说明它对 3D 渲染管线有比较完整的理解。

但它的后处理管线配置有问题。它用了UnrealBloomPass，但阈值设得太低，导致整个画面都泛光，看起来像蒙了一层雾。这个参数需要根据场景亮度调整，不能直接用默认值。

// GLM5.3 的后处理配置 const bloomPass = new UnrealBloomPass( new THREE.Vector2(window.innerWidth, window.innerHeight), 1.5, // strength 太强 0.4, // radius 0.85 // threshold 太低 );

合理的阈值应该在 0.9 以上，强度在 0.5 左右，这样只有高亮部分才会泛光，而不是整个画面。

4.3 游戏逻辑的完整度

GLM5.3 的游戏逻辑是三个模型里最完整的。它做了计分、做了计时、做了游戏结束判定、还做了一个简单的开始界面。这些额外的功能说明它在生成代码时会考虑"一个完整的游戏应该有什么"，而不只是实现你明确要求的功能。

但功能多了之后 bug 也多了。它的游戏结束判定有逻辑漏洞，玩家收集完所有物品后游戏没有正确结束，因为它在判定时用的是>=而不是===，导致收集数超过总数时判定失败。这个 bug 很隐蔽，因为正常玩不会超过总数，但如果你用调试工具改一下计数就会触发。

4.4 GLM5.3 的实操心得

GLM5.3 是三个模型里最有"想法"的，它会主动加一些你没要求但合理的东西。这种主动性在探索阶段很有价值，但在需要精确控制的场景下可能会带来麻烦，因为你需要花时间去理解和调整它加的东西。

注意：GLM5.3 生成的后处理管线在移动端性能很差，bloom 在低端 GPU 上会掉帧严重。如果你要做移动端适配，建议把后处理关掉或者换成更轻量的方案。

5. 三款模型横向对比与选型建议

5.1 关键指标对比

把三个模型的实测结果整理成表，看得更清楚：

这个表里"首次可运行"那一行很关键。三个模型没有一个能一次跑通，都需要人工修正。这个结果其实符合预期，3D 游戏这种复杂项目，指望模型一次生成完美代码不现实。

5.2 不同场景下的选型逻辑

如果你是要快速验证一个想法，我建议用 DeepSeek V4 Pro。它生成的代码最稳，修的地方最少，3D 数学最可靠，你能最快拿到一个能跑的版本。虽然功能保守，但验证想法够用了。

如果你是要做一个需要长期维护的项目，Step 5 Preview 的代码组织更好，模块划分清晰，后续加功能更容易。但你需要花时间修正它的 3D 数学问题，尤其是空间变换那块。

如果你是要做一个演示或者想要一些现成的额外功能，GLM5.3 最合适。它自带开始界面、计时、后处理，省了你不少事。但你要做好调试的准备，它的 bug 相对多一些，而且后处理参数需要调。

5.3 组合使用的思路

实际工作中我不会只用一个模型。我的做法是：先用 DeepSeek V4 Pro 生成基础框架，拿到一个能跑的版本；然后用 Step 5 Preview 重新组织代码结构，把模块划分清楚；最后参考 GLM5.3 的额外功能，挑需要的加进去。这样每个模型的优势都用上了，劣势被规避了。

这个思路其实适用于任何模型组合。每个模型都有自己的强项和弱项，与其纠结哪个最好，不如想清楚每个模型适合干什么，然后组合起来用。

6. 实操中的常见问题与排查技巧

6.1 3D 游戏生成的典型问题

在测试过程中我整理了一份常见问题速查表，这些问题在三个模型生成的代码里都不同程度地出现过：

这张表里的每一条我都在实测中遇到过。最坑的是"物体不可见"那条，因为代码不报错，你只能看到一片空白，排查起来很费时间。我的经验是，遇到这种情况先检查相机，再检查物体位置，最后检查材质和光照。

6.2 模型生成代码的调试技巧

调试模型生成的代码和调试自己写的代码不一样。自己写的代码你知道思路，模型生成的代码你需要先理解它的思路。我的做法是先把代码通读一遍，找到主循环和核心逻辑，在关键位置加 console.log，然后跑起来看输出。

还有一个技巧是让模型自己解释代码。你可以把生成的代码贴回给模型，问它"这段代码的相机逻辑是什么"，它的解释往往能帮你快速定位问题。但要注意，模型的解释不一定和代码实际行为一致，最终还是要以运行结果为准。

提示：模型生成的 3D 代码里，最常见的隐藏问题是"常量污染"。比如你把一个 Vector3 常量传给某个会修改它的函数，常量就被改了。排查这种问题的方法是在关键位置打印常量值，看它有没有变化。

6.3 提升生成质量的提示词技巧

实测下来，提示词的质量对生成结果影响很大。我总结了几个有效的技巧：

第一，明确坐标系约定。在提示词里写清楚"Y 轴向上，Z 轴向前"，能减少很多坐标轴错误。第二，指定文件结构。如果你有偏好的目录结构，直接在提示词里写出来，模型会照着做。第三，要求帧率无关。明确说"所有动画和移动必须帧率无关"，模型就会用 deltaTime。第四，限制额外功能。如果你不想要后处理，明确说"不要加后处理管线"，否则 GLM5.3 这类模型会自作主张加上。

这些技巧看起来简单，但实测能显著提升首次生成的可运行率。我做过对比，加了这些约束之后，首次可运行率从 0% 提升到了 60% 左右。

7. 关于 WorkBuddy 在开发流程中的实际用法

7.1 WorkBuddy 与代码生成工具的配合

聊完模型对比，再说说 WorkBuddy 在这个流程里的位置。很多人把 WorkBuddy 和代码生成模型混为一谈，其实它们解决的是不同问题。代码生成模型负责"写代码"，WorkBuddy 负责"管流程"。

我在测试三个模型时，用 WorkBuddy 做了几件事：一是管理三个模型的测试任务，每个模型一个工作流，互不干扰；二是记录每个模型的测试结果和问题，方便后续对比；三是把排查出来的问题整理成知识库，下次遇到类似问题可以直接查。

WorkBuddy 的工作台模式很适合这种多任务并行的场景。你可以给每个模型建一个独立的工作区，把提示词、生成结果、测试记录都放在一起，切换起来很方便。它的自定义指令功能也很有用，你可以定义一套"代码审查规则"，让 WorkBuddy 在每次生成代码后自动检查几个关键点，比如有没有用 deltaTime、有没有常量污染、相机逻辑是否正确。

7.2 给 WorkBuddy 定规则的实际效果

热词里有人问"给 WorkBuddy 定几条规则，后续对所有任务都生效"，这个功能我实测过，确实好用。我给自己定了几条规则：第一，所有代码生成任务必须附带测试用例；第二，所有 3D 相关任务必须明确坐标系；第三，所有生成结果必须经过可运行性检查。

这几条规则定好之后，后续所有任务都会自动带上这些约束，不用每次重复说明。这个功能的价值在于把"经验"固化成了"规则"，你踩过的坑不会再踩第二次。

WorkBuddy 的跨对话记忆功能也值得一提。我在一个对话里排查出的问题，在另一个对话里它能记住。比如我之前排查过一个相机抖动的问题，后来在另一个任务里遇到类似现象，它主动提醒我检查插值系数。这个体验很自然，就像有个助手记得你之前做过什么。

7.3 私有化部署与缓存目录调整

热词里还有人问 WorkBuddy 的私有化部署和缓存目录调整。私有化部署这块，WorkBuddy 支持 Docker 部署，官方有镜像，配置好数据卷映射就行。缓存目录默认在用户目录下，如果你 C 盘空间紧张，可以在配置里改到 D 盘。这个改动很简单，改一个配置项重启就行，但要注意改之前先把现有缓存迁移过去，否则之前的记录会丢。

WorkBuddy 的安全审核功能在私有化部署时比较重要。它会检查生成的内容是否符合规范，避免一些不合适的内容进入你的工作流。这个功能默认开启，建议保持开启状态。

8. 实测后的个人体会与后续扩展方向

这轮实测做下来，我最大的感受是：模型之间的差距没有跑分显示的那么大，但每个模型的"性格"差异很明显。Step 5 Preview 像个架构师，喜欢把东西拆得很细；DeepSeek V4 Pro 像个稳健的工程师，不出错但也不出彩；GLM5.3 像个有想法的产品经理，总想加点你没要求的东西。

选哪个模型，取决于你现在需要什么。需要快速验证就用 DeepSeek V4 Pro，需要长期维护就用 Step 5 Preview，需要演示效果就用 GLM5.3。没有哪个模型全面碾压另一个，组合使用才是最优解。

后续我打算把这个测试扩展到更多模型，并且把测试用例标准化，做成一个可复用的评测框架。这样以后新模型出来，直接跑一遍就能知道它在 3D 游戏这个场景下的表现。另外我也想试试用 WorkBuddy 把这个流程自动化，从提示词生成到代码测试到结果记录全部串起来，减少人工操作。

最后分享一个小技巧：测试模型生成 3D 代码时，先让它生成一个最简单的场景——一个立方体加一个相机，跑通了再让它加功能。这样你能快速判断模型在 3D 基础逻辑上有没有问题，避免一上来就生成复杂项目，出了问题不知道是基础逻辑错了还是复杂逻辑错了。这个分步验证的思路，比一次性生成整个项目要高效得多。