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 最新稳定版。每个模型生成的代码我都单独建目录互不干扰。评测维度我列了个表后面每个模型都会按这个表打分评测维度具体考察点权重代码可运行性能否一次跑通报错数量30%3D 空间正确性坐标轴、相机、光照是否正确25%代码组织模块划分、文件结构是否合理20%交互完整性键盘、碰撞、计分是否可用15%可扩展性加新功能是否容易10%这个权重分配是有讲究的。可运行性占最高因为一个跑不起来的项目其他都是空谈。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.jsStep 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 关键指标对比把三个模型的实测结果整理成表看得更清楚对比项Step 5 PreviewDeepSeek V4 ProGLM5.3首次可运行需修 2 处需修 1 处需修 3 处3D 数学正确性中高高代码组织优中良功能完整度中中高代码量大中大注释质量中优中额外功能无无有调试难度中低高这个表里首次可运行那一行很关键。三个模型没有一个能一次跑通都需要人工修正。这个结果其实符合预期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 游戏生成的典型问题在测试过程中我整理了一份常见问题速查表这些问题在三个模型生成的代码里都不同程度地出现过问题现象根本原因排查方法修复方式画面全黑相机位置在物体内部或朝向错误打印相机 position 和 lookAt 目标调整相机初始位置物体不可见坐标轴用错Y 和 Z 混淆检查 position 赋值统一坐标系约定移动方向反了世界坐标和本地坐标混用打印移动向量用 quaternion 变换方向相机抖动插值系数与帧率不匹配检查 deltaTime 使用用帧率无关插值碰撞不触发包围盒尺寸或位置不对可视化包围盒更新包围盒矩阵性能暴跌每帧创建新对象检查循环内 new 操作对象池或复用这张表里的每一条我都在实测中遇到过。最坑的是物体不可见那条因为代码不报错你只能看到一片空白排查起来很费时间。我的经验是遇到这种情况先检查相机再检查物体位置最后检查材质和光照。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 基础逻辑上有没有问题避免一上来就生成复杂项目出了问题不知道是基础逻辑错了还是复杂逻辑错了。这个分步验证的思路比一次性生成整个项目要高效得多。

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

相关推荐

FAISS、Chroma、PGVector向量库选型实战：原理、性能与踩坑经验

C++零基础入门教学路径：从环境搭建到类与对象

蓝绿与灰度环境：核心差异、落地细节与组合实践

更多资讯

SIMPACK变速设置全解析：传动比、换挡逻辑与动力传动系统建模

从配音工具到语音工作台：构建可批量生产的VoiceStudio语音合成工作流

Paperclip：轻量级 React+Node.js AI Agent 协作框架

机器学习模型测试中的5种偏差问题与解决方案

IP定位技术解析：精度验证与商业应用实践

LSTM与SVM混合模型在工业故障诊断中的应用实践

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？