三大代码模型同台实测：3D游戏开发谁更强？-北京尧图网络

1. 三个模型同台做3D游戏我为什么选这个题最近圈子里讨论度最高的一件事就是几个主流代码大模型在同一类任务上的横向对比。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字频繁出现在各种技术群里但真正拿它们做同一个完整项目、把过程记录下来的内容并不多。大多数评测停留在写个贪吃蛇生成一个待办列表这种粒度离真实开发差得太远。我这次选的任务是做一个可运行的3D游戏。为什么是3D游戏因为它天然覆盖了图形渲染、数学计算、物理碰撞、状态管理、资源加载、输入处理这几条主线任何一个环节掉链子整个项目就跑不起来。它不像CRUD接口那样可以靠模板糊弄过去模型必须真正理解三维空间里的坐标变换、向量运算和渲染循环才能写出能跑的东西。这对模型的代码能力、空间推理能力和长上下文一致性都是硬考验。这篇文章适合三类人看一是正在选型、想知道这几个模型各自擅长什么的开发者二是想用AI辅助做游戏但不知道从哪下手的新手三是已经在用WorkBuddy这类工作台工具、想把它和代码模型结合起来提效的人。我会把三个模型的实际表现、踩到的坑、以及我最终怎么把项目跑通的完整过程写出来不吹不黑只讲实测。需要先说明一点模型版本迭代很快我测试时用的具体版本和参数配置会在下面标注清楚你复现时如果发现结果有差异大概率是版本更新导致的思路和方法论仍然适用。2. 三个模型接同一个需求第一轮输出差在哪2.1 我给的提示词长什么样为了让对比公平三个模型收到的是完全相同的提示词。我没有用那种帮我写一个3D游戏的模糊说法而是把需求拆成了结构化的规格说明。实测下来提示词的结构化程度直接决定第一轮输出的可用率这一点比模型本身的差异影响还大。我的提示词大致包含这几块技术栈限定Three.js 原生JavaScript不用框架、游戏类型第三人称视角的收集类小游戏玩家控制角色在场景里移动并收集发光物体、核心功能清单WASD移动、鼠标旋转视角、碰撞检测、计分、计时、性能要求目标60帧场景物体不超过50个、以及输出格式要求单个HTML文件可直接在浏览器打开。提示给代码模型下需求时输出格式要求这一条千万别省。不限定的话有的模型会给你拆成十几个文件有的会引入一堆构建工具配置最后你光是把项目跑起来就要花半小时。2.2 第一轮输出的直观对比三个模型都在几十秒内给出了完整代码但质量差异在第一眼就能看出来。Step 5 Preview 的输出最整。它直接给了一个单HTML文件Three.js通过CDN引入代码结构清晰分了初始化、场景搭建、玩家控制、游戏循环、碰撞检测几个模块注释也写得比较到位。我直接保存成html文件双击打开场景就渲染出来了角色能移动虽然手感有点飘但基本功能都在。DeepSeek V4 Pro 的输出偏工程化。它同样给了单文件但代码里加了不少防御性判断和错误处理比如WebGL上下文创建失败的回调、资源加载超时的提示。功能上也能跑但它默认用了较新版本的Three.js API有些方法名和我本地缓存的老版本对不上第一次打开控制台报了几个警告。GLM5.3 的输出最激进。它主动加了一些我没要求的东西比如简单的粒子效果、角色移动时的拖尾、以及一个简易的暂停菜单。想法很好但代码量明显更大而且它用了一个我没听说过的第三方物理库导致我不得不额外去确认这个库的CDN地址是否可用。对比维度Step 5 PreviewDeepSeek V4 ProGLM5.3输出形式单HTML文件单HTML文件单HTML文件首次可运行性直接可跑需调整API版本需确认第三方库代码结构模块清晰防御性强功能丰富但臃肿额外功能无错误处理粒子、菜单等注释质量较详细详细一般2.3 为什么第一轮差异这么大这个差异背后其实是三个模型在指令遵循和自由发挥之间的取舍不同。Step 5 Preview 明显更倾向于严格按需求清单来你说什么它做什么不越界。DeepSeek V4 Pro 倾向于把代码写得更健壮会主动补一些工程实践里的东西。GLM5.3 则倾向于我理解你想要一个好玩的游戏所以会主动加体验层面的东西。没有绝对的好坏取决于你的场景。如果你要的是快速拿到一个能跑的原型Step 5 Preview 的第一轮输出最省事。如果你要的是能长期维护的代码DeepSeek V4 Pro 的防御性写法更有价值。如果你自己还没想清楚要什么GLM5.3 的主动发挥可能给你灵感但也可能给你添乱。3. 把三个版本都跑起来之后问题才真正暴露3.1 角色移动手感一个被低估的难点第一轮代码都能跑但能跑和能玩是两回事。我逐个试玩之后发现三个版本在移动手感上都有问题只是问题类型不同。Step 5 Preview 的版本角色移动是直接改position的没有加速度和阻尼按一下走一下松开立刻停感觉像在冰面上滑行的方块突然被钉住。DeepSeek V4 Pro 的版本加了速度变量但阻尼系数设得太大角色像在泥里走。GLM5.3 的版本因为有拖尾效果视觉上稍微掩盖了手感问题但底层还是一样的直接位移。这里涉及一个3D游戏里很基础但很容易被忽略的点移动手感本质上是速度对时间的积分问题。直接改position相当于瞬时速度无穷大而真实的手感需要输入→加速度→速度→位置这样一条链中间还要有摩擦力和最大速度限制。这个逻辑模型不是不会写而是如果提示词里没明确要求它默认就用最简单的写法。我后来在提示词里补了一句移动需要有加速和减速过程模拟惯性三个模型的输出质量立刻上了一个台阶。Step 5 Preview 给出的实现最干净用了简单的线性插值DeepSeek V4 Pro 用了更物理的写法区分了地面和空中的不同阻尼GLM5.3 则把加速曲线做成了可配置的参数。3.2 碰撞检测从穿模到能玩的排查过程碰撞检测是这次实测里问题最集中的地方。第一轮三个版本用的都是最简单的包围盒检测结果就是角色会卡在物体边缘或者直接穿过去。我先在Step 5 Preview的版本上排查。现象是角色走到收集物附近时有时候能收集到有时候直接穿过去。我打开控制台打印了角色和收集物的坐标发现收集物的判定半径设的是0.5但收集物模型的实际尺寸是1.0也就是说判定范围只有实际大小的一半。这是模型想当然设的参数它没有根据模型尺寸去计算判定范围。DeepSeek V4 Pro 的版本问题不一样它用了包围盒但包围盒的更新时机有问题。角色移动之后包围盒的位置没有同步更新导致判定用的是上一帧的位置。这个bug很隐蔽因为快速移动时才会明显慢速走的时候几乎看不出来。我是在让它跑起来之后盯着角色绕圈走了两分钟才发现的。GLM5.3 的版本因为引入了物理库碰撞检测反而是最准的但代价是性能开销大场景里物体一多帧率就掉。我测了一下同样是50个物体GLM5.3的版本帧率比另外两个低15帧左右。注意碰撞检测的坑几乎都出在判定范围和更新时机这两件事上。排查的时候不要盯着碰撞逻辑本身看先打印坐标和包围盒数据八成问题出在数据不同步。3.3 帧率与性能谁在偷偷拖后腿性能这块我做了相对严格的测试。测试环境是一台普通的开发笔记本浏览器用Chrome场景里放50个静态物体加10个可收集物角色持续移动用浏览器的性能面板记录30秒的平均帧率。Step 5 Preview 的版本平均58帧偶尔掉到52帧掉帧发生在角色同时靠近多个物体时应该是碰撞检测的循环开销。DeepSeek V4 Pro 的版本平均55帧波动比Step 5 Preview大因为它每帧都在做包围盒更新即使物体没动。GLM5.3 的版本平均43帧物理库是主要开销来源。这个结果说明一个事模型默认写出来的代码性能优化基本是缺位的。它们会优先保证功能正确不会主动去做对象池、空间分区、脏标记这些优化。如果你对性能有要求必须在提示词里明确提或者拿到代码后自己优化。我后来给三个版本都加了一个简单的优化把静态物体的碰撞检测从每帧执行改成只在角色移动超过一定距离时才执行。这一个改动就让三个版本的帧率都提升了5到8帧。这个优化思路模型不是想不到而是它默认不会主动做因为需求里没提。4. 用WorkBuddy把三个模型的产出管起来4.1 为什么单靠对话窗口管不住这个项目做到这一步我手里已经有三个版本的代码、一堆测试记录、还有各种修改笔记。如果全靠对话窗口来管理很快就会乱套改到第三版的时候想对比第一版的某个函数得往上翻半天想记录某个坑的排查过程只能写在便签里三个模型的输出混在一起时间一长根本分不清哪段代码是谁写的。这就是我开始用WorkBuddy的原因。它本质上是一个工作台可以把不同来源的代码、文档、任务记录放在同一个空间里管理。对于这种多模型对比的项目它的价值在于把对话变成了可管理的资产。4.2 我实际用到的几个功能我主要用了WorkBuddy的三个能力。第一个是跨对话记忆。三个模型的对比过程是分散在多次对话里的跨对话记忆让我不用每次都重新交代背景它知道我在做3D游戏对比知道当前进展到哪一步。这个功能在长周期项目里特别省心。第二个是自定义指令。我给这个项目定了几条规则所有代码修改必须记录修改原因、所有测试结果必须带帧率数据、对比结论必须区分模型能力问题和提示词问题。这几条规则定下去之后后续所有相关任务都会自动遵守不用我每次重复。第三个是任务拆分与追踪。我把整个项目拆成了第一轮输出对比移动手感优化碰撞检测修复性能优化最终整合几个任务每个任务的状态和产出都挂在工作台上。这样我随时能看到进度也不会漏掉某个环节。提示给WorkBuddy定规则的时候规则要具体到可执行。记录修改原因比做好记录有用得多因为前者有明确的判断标准后者全靠自觉。4.3 把模型输出导入工作台的实操细节具体操作上我是这样做的每个模型的第一轮输出我都保存成独立的文件命名规则是模型名_版本_日期比如step5_v1_0315.html。然后在WorkBuddy里建了一个对比任务把三个文件都挂上去附上我的试玩记录和帧率数据。修改代码的时候我不直接在原文件上改而是复制一份出来改原文件保留作为基线。这样后面想对比改之前和改之后的差异时随时能调出来。这个习惯看起来笨但在多版本对比的场景里能省掉大量返工。还有一个细节WorkBuddy的系统缓存目录默认在C盘如果项目文件多、缓存积累快C盘空间会紧张。我在设置里把缓存目录改到了D盘具体路径在设置的高级选项里改完之后重启一下工作台就生效了。这个操作对长期做项目的用户来说挺重要不然用着用着C盘就红了。5. 三个模型的能力边界我摸出来的几条规律5.1 谁更适合从零起步从零起步这个场景Step 5 Preview 的表现最稳。它的输出结构清晰、依赖最少、首次可运行率最高。你给它一个明确的需求清单它基本能一次给到位不需要来回拉扯。对于想快速验证想法、或者对3D游戏开发不太熟的人来说用它起步的摩擦最小。DeepSeek V4 Pro 更适合从零起步但要求工程规范的场景。它的代码里自带错误处理和边界判断虽然第一轮可能需要调一下API版本但调好之后代码的健壮性明显更好。如果你做的不是一次性demo而是打算长期迭代的东西它的起点更高。GLM5.3 适合你自己也没想清楚要什么的场景。它会主动给你加功能、加效果有时候能给你惊喜。但如果你需求很明确它的自由发挥反而会增加你的清理成本。5.2 谁更适合改bug和迭代迭代阶段我的体感是 DeepSeek V4 Pro 最强。我把一个具体的bug描述给它比如角色快速移动时会穿过收集物它能比较准确地定位到是包围盒更新时机的问题给出的修复方案也考虑到了性能影响。Step 5 Preview 也能修但它的修复往往比较就事论事改完这个bug可能引入另一个小问题。GLM5.3 修bug的时候容易顺手改一堆别的东西导致diff很大review起来累。这里有个经验迭代阶段一定要把上下文控制好。不要在一个对话里从项目开始聊到项目结束那样模型会被前面的信息干扰。我的做法是每个bug开一个新的对话只贴相关的代码片段和现象描述修完再合并回主文件。这样模型的注意力集中修复质量更高。5.3 长上下文一致性一个容易被忽略的指标这个项目做到后期代码文件已经有一千多行。这时候我发现一个现象当我把整个文件贴给模型让它改某个函数时三个模型都出现了不同程度的遗忘——改完的函数和文件里其他部分的命名风格、变量约定对不上。Step 5 Preview 的遗忘最轻基本能保持风格一致。DeepSeek V4 Pro 次之偶尔会引入新的命名习惯。GLM5.3 的遗忘最明显有两次它改完的函数直接用了和文件里完全不同的参数顺序导致调用处报错。这个问题的根源是长上下文里的信息衰减。模型在处理长文件时对文件开头定义的约定记忆会变弱。应对办法有两个一是把关键约定写在文件顶部的注释里让模型每次都能看到二是改代码时只贴相关片段不要贴整个文件。我后来改用第二种方法长上下文一致性问题基本消失了。6. 最终整合我怎么把三个版本的优点拼成一个能玩的游戏6.1 整合策略不是选一个而是各取所长做到最后我没有选某一个版本作为最终版而是做了一次整合。具体来说以 Step 5 Preview 的版本为骨架因为它的结构最清晰、依赖最少把 DeepSeek V4 Pro 的错误处理和包围盒更新逻辑移植过来把 GLM5.3 的粒子效果和暂停菜单摘出来去掉它那个重量级物理库换成自己写的轻量碰撞检测。这个整合过程本身就是一次很好的学习。你会发现不同模型的代码风格差异很大Step 5 Preview 喜欢用函数式写法DeepSeek V4 Pro 喜欢用类GLM5.3 喜欢用配置对象。整合的时候要统一风格不然代码会很难维护。我最后统一成了类配置对象的混合风格核心逻辑用类封装可调参数抽成配置对象。6.2 整合后踩的新坑整合不是简单的复制粘贴中间出了几个新问题。最典型的是坐标系不一致Step 5 Preview 用的是Y轴向上GLM5.3 的粒子效果默认是Z轴向上直接移植过来之后粒子是横着飞的。我花了不少时间才定位到是坐标系的问题因为粒子效果本身看起来能动只是方向不对很容易以为是参数问题。还有一个坑是事件监听的重复绑定。三个版本各自绑定了键盘事件整合的时候没注意导致按一下W角色移动了两倍距离。这个问题的排查方法是打印事件触发次数一看日志就明白了。注意多来源代码整合时优先检查三件事——坐标系约定、事件绑定、全局变量命名冲突。这三个是最高频的整合问题。6.3 最终成品的能力清单整合后的版本最终实现了这些功能第三人称视角跟随、带惯性的移动手感、基于距离的碰撞检测、收集物计数、倒计时、暂停菜单、收集时的粒子反馈、以及一个简单的结算界面。帧率稳定在60帧场景里50个物体加10个收集物角色持续移动不掉帧。代码总量大概八百行单HTML文件双击就能玩。从开始到完成三个模型的对话加起来大概二十多轮WorkBuddy里记录了完整的对比数据和修改日志。7. 给想复现这套流程的人几条实在建议如果你也想做类似的模型对比或者想用AI辅助做一个3D游戏这几条是我踩过坑之后总结的能帮你省不少时间。第一提示词的结构化程度比模型选择更重要。同一个模型提示词从模糊变清晰输出质量能差出一倍。技术栈、功能清单、性能要求、输出格式这四块一定要写清楚。第二第一轮输出不要直接用来做最终版。三个模型的第一轮输出都有明显问题移动手感、碰撞检测、性能优化基本都要手动补。把第一轮当成能跑的草稿心态会好很多。第三迭代时控制上下文。每个bug开新对话只贴相关代码不要贴整个文件。这一条能显著提升修复质量也能避免模型遗忘文件里的约定。第四用工作台工具管理多版本。WorkBuddy这类工具的价值在项目变复杂之后才体现出来跨对话记忆和自定义指令这两个功能对长周期项目帮助最大。记得把缓存目录改到空间大的盘。第五整合多来源代码时先统一约定。坐标系、事件绑定、命名风格这三样不统一后面全是坑。最后说一个我自己的体会这三个模型没有绝对的强弱它们的差异更多是性格差异。Step 5 Preview 稳、DeepSeek V4 Pro 严谨、GLM5.3 有想法。选哪个取决于你当前阶段最需要什么。如果你拿不准就三个都试一遍用同一个需求跑一轮半天时间就能摸清它们的脾气。这个时间投入比看十篇评测文章都值。

三大代码模型同台实测：3D游戏开发谁更强？

相关推荐

VoiceStudio：开源视频配音工具的架构与实战

Hermes Agent 架构全解析：子系统拆解与执行路径实战指南

Python实现FPS红点准星：圆心定位与动态绘制

更多资讯

GPU服务器集群系统级参数调优与性能优化指南

ADK Runtime架构解析：AI Agent开发的事件驱动引擎

TOON数据格式：优化LLM处理效率的结构化数据方案

SeaweedFS存储空间回收机制与优化实践

开源雷达周刊：十个开源工具串成可试用自动化流程

昇腾RAG索引结构优化：从HNSW到IVF_PQ的工程实践

今日更新

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

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

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

本周精选

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

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

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

本月热门

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

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

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

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