三款大模型同台实测：从零开发3D游戏，谁更胜一筹？-北京尧图网络

1. 三款模型同台竞技这个对比测试到底在测什么三个大模型同一个任务——从零做一个能跑的3D游戏。听起来像是评测机构的标准化跑分但实际动手之后你会发现这件事远比跑个benchmark复杂得多。Step 5 Preview、DeepSeek V4 Pro、GLM5.3这三个名字最近在开发者圈子里被反复提及各自都有明确的定位和拥趸。但把它们放在同一个3D游戏开发任务里横向对比考验的就不只是代码生成能力了。我拿到这个对比任务的时候第一反应是3D游戏开发这个场景选得很有意思。它不像写个排序算法或者CRUD接口那样有标准答案3D游戏涉及渲染管线、场景图管理、物理碰撞、输入处理、资源加载、帧率控制等多个子系统任何一个环节掉链子最终跑起来的效果就是“能看但不能玩”或者“能玩但卡成PPT”。这恰好能暴露模型在长链条任务规划、跨文件代码一致性、图形学领域知识这几个维度的真实水平。先说清楚这三个模型各自的特点。Step 5 Preview是阶跃星辰最新的预览版本主打代码生成和复杂推理DeepSeek V4 Pro是深度求索的旗舰模型在数学和逻辑推理上一向口碑不错GLM5.3是智谱的最新迭代在中文理解和工程化落地方面积累深厚。三者都是当前国内第一梯队的选手但风格差异明显。我设计的测试任务是用Three.js做一个第一人称视角的3D迷宫探索游戏要求包含随机迷宫生成、WASD移动、鼠标视角控制、碰撞检测、小地图、计时器和通关判定。这个任务的好处是——它足够复杂能拉开差距又足够聚焦不会因为需求模糊导致结果不可比。所有模型使用相同的提示词分三个阶段交互先出架构方案再生成核心代码最后根据运行报错进行修复。提示做模型对比测试时提示词的一致性比提示词的“精妙程度”更重要。我见过太多对比文章给A模型精心设计的提示词给B模型随便扔一句话然后得出结论说A比B强——这种测试没有参考价值。为什么选Three.js而不是Unity或Godot因为Three.js是纯代码驱动的模型生成的每一行JavaScript都能直接对应到最终效果没有编辑器操作的黑盒。Unity虽然更主流但模型没法直接操作编辑器界面生成的C#脚本还得手动挂载、配置参数对比维度就不纯粹了。Three.js的另一个好处是浏览器直接跑省去了编译和部署环节测试效率高很多。这个测试适合谁来参考如果你正在选型代码生成工具或者想了解当前大模型在3D图形编程上的真实能力边界这篇实测记录应该能给你一些直观的参考。如果你只是好奇“AI能不能做游戏”那结论可能会让你意外——能但离“做好”还有一段距离。2. 三阶段实测过程全记录2.1 第一阶段架构方案生成对比第一阶段我让三个模型分别给出项目的架构设计。提示词是“我要用Three.js做一个第一人称3D迷宫游戏包含随机迷宫生成、WASD移动、鼠标视角、碰撞检测、小地图、计时器和通关判定。请给出完整的文件结构和模块划分方案。”Step 5 Preview的回复最详细。它给出了一个六文件结构main.js负责初始化和主循环mazeGenerator.js用递归回溯算法生成迷宫playerController.js处理输入和移动collisionSystem.js做AABB碰撞检测minimap.js用Canvas 2D绘制俯视图gameState.js管理计时和通关逻辑。每个文件的职责边界清晰模块间的依赖关系也标注了。特别值得一提的是它主动提到了“用requestAnimationFrame驱动主循环用deltaTime保证不同帧率下的移动速度一致”——这个细节说明它理解游戏循环的本质。DeepSeek V4 Pro的方案更偏向“一步到位”。它给了一个单文件方案所有逻辑塞在一个HTML文件里大约800行代码。好处是复制粘贴就能跑坏处是后续修改和扩展很麻烦。它在架构说明里提到“为了降低部署复杂度采用单文件内联方式”这个取舍有道理但对于一个需要持续迭代的游戏项目来说单文件结构很快就会变成维护噩梦。不过它在物理碰撞部分给出了具体的数学公式包括射线与AABB求交的推导过程这部分比另外两家更扎实。GLM5.3的方案介于两者之间给了四个文件index.html、game.js、maze.js、utils.js。它的特色是在utils.js里封装了一个事件总线用来解耦输入系统和游戏逻辑。这个设计模式在中小型游戏里确实好用但GLM5.3没有进一步解释为什么需要事件总线只是说“便于扩展”。从架构完整性来看Step 5 Preview GLM5.3 DeepSeek V4 Pro。对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3文件结构6文件职责清晰单文件约800行4文件含事件总线模块解耦高低中高游戏循环设计明确提到deltaTime未特别说明提到固定时间步碰撞检测方案AABB射线求交AABBAABB扩展性评估优差良2.2 第二阶段核心代码生成质量第二阶段是重头戏——让三个模型基于各自的架构方案生成完整代码。我逐个在本地环境跑了一遍记录下实际运行效果。Step 5 Preview生成的代码一次通过率最高。迷宫生成用的是递归回溯代码逻辑正确生成的迷宫没有死循环和孤立区域。玩家控制器里对键盘事件的处理很规范用了keydown和keyup配合状态对象而不是直接在事件回调里改位置——这个细节很关键前者能保证按住W键持续移动后者会导致按键重复触发。碰撞检测部分它把玩家简化为一个圆柱体用圆形与网格单元的相交测试来判断碰撞虽然不是最精确的方案但对于迷宫游戏来说够用了而且计算量小。不过Step 5 Preview有一个明显问题小地图的坐标映射搞反了。它把世界坐标的X轴映射到了Canvas的Y轴导致小地图上的方向跟实际移动方向不一致。这个bug我在第三阶段反馈后才修复。DeepSeek V4 Pro的代码在数学上最严谨。它的碰撞检测用了射线投射从玩家位置向移动方向发射一条射线检测与墙壁的交点然后根据交点距离决定是否允许移动。这个方案比AABB更精确能处理斜向移动时的墙角碰撞。但问题在于——它生成的射线检测代码里射线方向向量没有归一化导致移动速度在不同方向上不一致。斜着走比直着走快这在游戏里是致命的。我检查了代码发现它在计算方向向量后直接用了没有调用.normalize()。GLM5.3的代码最“稳”。没有特别惊艳的设计但每个模块都能正常工作。它的迷宫生成用了Prim算法生成的迷宫通路比较宽敞走起来舒服。小地图绘制用了离屏Canvas做缓存每帧只重绘变化的部分性能比另外两家好。但它的鼠标视角控制有个小毛病没有做俯仰角限制鼠标一直往上推视角会翻转。这个bug在FPS游戏里很常见修复也简单加个Math.max和Math.min夹紧就行。注意模型生成的3D代码最常见的三类bug是——向量未归一化导致速度不一致、坐标系映射错误导致方向反了、角度未夹紧导致视角翻转。这三个坑我在不同模型上都踩到过建议在代码审查时优先检查这几处。2.3 第三阶段报错修复与迭代能力第三阶段我模拟真实开发场景把运行时报错和异常表现反馈给模型看它们能不能准确定位并修复。Step 5 Preview的修复能力最强。我把小地图方向反了的问题描述给它它立刻定位到minimap.js里的坐标映射函数解释说“世界坐标的X轴对应Canvas的X轴Z轴对应Y轴我写反了”然后给出了修正后的代码。更关键的是它还主动检查了其他地方的坐标映射发现玩家位置指示器的旋转角度也错了一并修了。这种“举一反三”的能力在调试阶段非常省心。DeepSeek V4 Pro在修复射线未归一化的问题时第一次改错了地方。它把归一化加在了碰撞检测函数里但移动速度的计算在另一个函数中导致问题依旧。我第二次反馈后它才找到正确的修改位置。这说明它在跨文件追踪数据流方面稍弱需要更明确的错误定位信息。GLM5.3修复俯仰角限制只花了一轮。它直接在鼠标移动事件里加了角度夹紧逻辑代码简洁有效。但当我反馈“小地图性能可以优化”时它给出的方案是“降低小地图刷新频率到每秒10次”这个方案能用但不够优雅——更好的做法是只在玩家移动时重绘静止时不重绘。GLM5.3没有主动想到这个层面。修复场景Step 5 PreviewDeepSeek V4 ProGLM5.3坐标映射错误一轮修复主动排查关联问题未测试未测试向量归一化未测试两轮修复首次定位错误未测试俯仰角限制未测试未测试一轮修复性能优化建议主动提出离屏Canvas方案未测试给出降频方案不够优雅3. 三款模型的能力边界与选型建议3.1 各自擅长的场景跑完整个测试三个模型的画像已经比较清晰了。Step 5 Preview适合复杂项目的从零搭建。它的架构设计能力明显高出一档能把一个模糊的需求拆解成职责清晰的模块并且在编码阶段保持跨文件的一致性。如果你要做一个中等规模以上的项目需要模型帮你规划整体结构Step 5 Preview是首选。它的代码风格也最接近有经验的开发者——变量命名规范、注释到位、错误处理完善。DeepSeek V4 Pro适合算法密集型的模块开发。它的数学功底在三个模型里最强碰撞检测的射线求交推导、迷宫生成的递归回溯实现都写得严谨准确。但它在工程化方面偏弱单文件方案虽然跑得快但不利于维护。如果你的任务核心是某个具体算法比如寻路、物理模拟、 procedural generationDeepSeek V4 Pro能给出质量最高的代码。GLM5.3适合快速原型验证。它的代码最“稳”很少出现跑不起来的情况虽然缺少惊艳的设计但胜在可靠。对于需要快速验证想法、做demo的场景GLM5.3的产出效率最高。它的中文注释也最自然适合中文团队协作。3.2 共同的短板三个模型在3D游戏开发上有一个共同的短板对性能优化的理解停留在表面。它们都能写出功能正确的代码但很少主动考虑渲染批次合并、几何体实例化、纹理压缩这些进阶优化手段。Step 5 Preview提到了离屏Canvas缓存小地图这已经是三个模型里最深入的性能优化了。如果你要做的是一个商业级的3D应用模型生成的代码只能作为起点后续的性能调优还得靠人工。另一个共同问题是对边界情况的处理不够全面。比如窗口resize时的相机宽高比更新、页面失焦时暂停游戏循环、移动端触摸事件的支持这些在实际项目中必须考虑的问题三个模型都没有主动提及。你需要在使用时自己补全这些逻辑。实操心得用模型生成3D游戏代码时建议在提示词里明确加上“考虑窗口resize、页面失焦暂停、移动端触摸支持”这几个要求。不加的话它们大概率会忽略。3.3 关于WorkBuddy的配合使用这次测试过程中我用WorkBuddy做了一些辅助工作。WorkBuddy的工作台模式很适合管理这种多模型对比的任务——我可以把三个模型的对话分别放在不同的工作区里互不干扰。它的跨对话记忆功能在第三阶段修复时特别有用我不需要反复粘贴之前的代码WorkBuddy能自动关联上下文。WorkBuddy的自定义指令功能也值得一说。我给它定了一条规则“所有代码生成任务优先考虑模块解耦和可测试性”后续所有对话都自动遵循这个规则省去了每次重复说明的麻烦。对于需要长期维护的项目这个功能能显著提升一致性。不过WorkBuddy的系统缓存目录默认在C盘如果你跟我一样C盘空间紧张建议在设置里改到D盘。具体路径在“设置-高级-缓存管理”里改完之后重启WorkBuddy生效。另外它的安全审核机制比较严格生成涉及网络请求的代码时会触发审核提示这是正常现象确认代码用途合规即可继续。4. 常见问题与排查技巧实录4.1 模型生成3D代码的高频问题速查问题现象可能原因排查方法修复方案斜向移动速度异常方向向量未归一化检查移动计算前是否调用normalize对方向向量做归一化处理小地图方向与实际相反坐标轴映射错误对比世界坐标与Canvas坐标的对应关系交换X/Z轴到Canvas X/Y轴的映射鼠标上推视角翻转俯仰角未夹紧检查pitch角是否限制在±90度内用Math.max/min夹紧角度按住按键不持续移动在keydown回调里直接改位置检查是否用状态对象记录按键用keydown/keyup维护按键状态帧率波动时移动速度不一致未使用deltaTime检查移动量是否乘以帧间隔用clock.getDelta()获取帧间隔迷宫出现孤立区域生成算法有缺陷用洪水填充验证连通性换用递归回溯或Prim算法4.2 提示词工程的实际技巧跟这三个模型打交道的过程中我总结了几条实用的提示词技巧。第一条明确技术栈版本。Three.js的API在不同版本间有破坏性变更比如Geometry在r125之后被移除改用BufferGeometry。如果你不说版本模型可能生成过时的API调用。我的做法是在提示词开头就写“使用Three.js r160版本”。第二条分阶段交互比一次性生成效果好。一次性让模型生成完整游戏代码它容易在细节上偷懒。分三个阶段——先架构、再核心模块、最后整合——每个阶段聚焦一个目标产出质量明显更高。Step 5 Preview在分阶段模式下表现尤其好因为它的上下文保持能力最强。第三条报错信息要具体。不要只说“跑不起来”要给出控制台报错、异常表现、复现步骤。模型不是调试器它需要足够的信息才能定位问题。我通常会把Chrome DevTools的报错截图转成文字贴给模型修复准确率能提升不少。4.3 本地环境搭建的注意事项Three.js项目虽然浏览器直接跑但有几个环境细节容易踩坑。如果你用ES Module方式引入Three.js需要通过HTTP服务访问直接双击HTML文件会触发CORS错误。最简单的做法是在项目目录下跑python -m http.server 8000然后浏览器访问localhost:8000。Node环境的话npx serve也行。纹理加载是另一个坑。模型生成的代码里纹理路径经常写的是相对路径但实际文件可能不在对应位置。建议在代码里加一个纹理加载失败的回调打印出具体是哪个文件没找到方便排查。还有一点模型生成的代码默认假设屏幕是桌面端宽屏。如果你在移动端浏览器打开可能会发现控制台报“touch事件未处理”的警告。这不是bug但会影响移动端体验。需要自己补上触摸事件监听。5. 从实测结果看3D游戏开发的AI辅助边界5.1 模型能做什么不能做什么把三个模型的表现放在一起看AI在3D游戏开发中的能力边界已经比较清晰了。能做的生成标准化的游戏循环骨架、实现常见的算法迷宫生成、碰撞检测、寻路、编写输入处理和状态管理代码、根据报错定位问题并给出修复方案。这些任务占了一个3D游戏项目60%到70%的代码量模型能显著缩短开发时间。不能做的性能调优的深度优化、美术资源的创建和处理、游戏手感的调校、复杂物理模拟的精确参数调整。这些任务要么需要人类的美学判断要么需要针对具体硬件的反复测试模型目前还替代不了。做得不够好的边界情况的全面考虑、跨模块的数据流追踪、对“代码可维护性”的主动追求。模型倾向于生成“能跑就行”的代码如果你不明确要求它不会主动做模块解耦、错误处理、单元测试这些工程化的工作。5.2 实际项目中的协作模式基于这次测试我目前采用的协作模式是模型出草稿人工做精修。具体来说新项目启动时让Step 5 Preview出架构方案和核心模块代码我审查后调整模块划分。算法密集的部分比如迷宫生成和碰撞检测让DeepSeek V4 Pro单独生成我验证数学正确性。快速原型阶段用GLM5.3因为它的代码最稳很少需要调试。代码审查的重点放在三个地方向量运算是否正确、坐标系映射是否一致、边界情况是否处理。这三处是模型最容易出错的地方也是人工审查价值最大的地方。5.3 后续可以扩展的方向这次测试只覆盖了Three.js这一个技术栈。如果你用的是Babylon.js、PlayCanvas或者原生WebGL模型的表现可能会有差异。Babylon.js的API更面向对象模型生成代码的准确率可能会更高原生WebGL的样板代码多模型容易在细节上出错。另一个值得探索的方向是让模型生成单元测试。3D游戏的逻辑部分——迷宫生成、碰撞检测、计分规则——都是可以单元测试的。如果让模型同时生成实现代码和测试代码能大幅提升代码的可靠性。我试过让Step 5 Preview给迷宫生成函数写测试它生成了包括连通性验证、边界检查、性能基准在内的完整测试用例质量超出预期。最后分享一个我在这次测试里学到的小技巧当你觉得模型生成的代码“哪里不对但又说不上来”的时候把代码贴回给模型让它“以代码审查者的身份找出潜在问题”。三个模型在这种模式下都能发现一些自己之前忽略的bug。Step 5 Preview甚至能指出“这个变量名有歧义建议重命名”这种代码风格层面的问题。这个自审查的步骤我現在已经加到了标准工作流里。

三款大模型同台实测：从零开发3D游戏，谁更胜一筹？

相关推荐

图智能平台：从数据建模到业务应用的全栈解决方案

无模型自适应控制在多智能体编队中的实践与优化

Java实测：Jev与Laya开源平替决策模型对比

更多资讯

DVWA 本地部署教程：一条命令拉起你的 Web 安全靶场

CADCraft 界面本地化实战：17 种语言、显示时目录、字体回退与自动化切换

MindOS安全设计全解析：Bearer Token认证、路径沙箱、写保护与原子写入如何守护本地隐私

dsh-purge 安装指南：DSH 提示词调校、44 项补丁管理与本地回退教程

OBS Studio 快捷键配置终极指南：全局热键、场景热键与冲突排查一次讲清

C++ PCL kdtree

今日更新

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

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

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

本周精选

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

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

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

本月热门

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

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

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

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