1. 三个模型同台做3D游戏我为什么选这个题最近圈子里讨论度最高的话题之一就是几个主流大模型在同一个实战任务上的横向对比。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字频繁出现在各种技术群里但大多数讨论都停留在跑分和参数层面真正拿同一个完整项目去实测的内容少之又少。我花了大概三天时间用同一个3D游戏需求分别驱动这三个模型从零开始搭建、调试、跑通中间踩了不少坑也积累了一些在官方文档里绝对看不到的经验。这篇文章适合几类人看正在选型AI编程工具的技术负责人、想了解大模型实际编码能力边界的开发者、以及单纯好奇现在的大模型到底能不能独立做游戏的围观群众。我会把整个过程的完整链路拆开讲包括我怎么设计测试用例、每个模型在哪些环节表现突出、哪些地方翻车了、以及最后我怎么把三个模型的产出整合成一个能跑的东西。先交代一下测试环境。我用的是一台常规开发机32GB内存RTX 4070显卡系统是Ubuntu 22.04。3D游戏引擎选的是Three.js原因是它纯浏览器端运行不依赖复杂的本地编译环境三个模型对它的训练数据覆盖都比较充分公平性相对好。游戏类型选了一个第三人称收集类小游戏——玩家控制一个角色在场景里移动收集随机刷新的道具有计时和计分。这个需求复杂度适中既涉及3D渲染、物理碰撞、相机跟随又不会大到让模型直接放弃。提示做模型横向对比时任务复杂度要控制在单个模型能在一次对话里完成主体框架的范围内。任务太大所有模型都会因为上下文窗口限制而表现趋同任务太小又区分不出能力差异。我之所以特别关注Step 5 Preview是因为它在社区里的讨论声量虽然不如另外两个大但在代码生成这个细分方向上不少人反馈它的结构组织能力有惊喜。DeepSeek V4 Pro 则是老牌选手代码能力一直在线。GLM5.3 最近热度很高尤其是配合各种工作台工具使用的场景被反复提及。三个模型各有拥趸但真正放在同一个3D游戏项目里对比我还没看到有人认真做过。2. 测试用例的设计怎么让对比结果有说服力2.1 需求拆解与提示词统一横向对比最容易犯的错误就是给不同模型喂不同的提示词。我在这件事上非常克制三个模型收到的初始需求完全一致连标点符号都没改。需求描述大概是这样用Three.js做一个第三人称3D收集游戏。场景是一个200x200的平面四周有围墙。玩家角色是一个胶囊体用WASD控制移动鼠标控制视角旋转。场景里随机刷新20个金色方块作为收集物玩家碰到就消失并加10分。屏幕左上角显示分数和剩余时间倒计时120秒。时间归零时弹出结算界面显示最终得分。相机跟随玩家保持一定距离和高度。这个需求我反复打磨过确保它覆盖了3D游戏开发的几个核心模块场景搭建、角色控制、相机系统、碰撞检测、UI系统、游戏状态管理。同时每个模块的描述都足够具体不会让模型在理解需求上产生歧义。2.2 评估维度的确定我没有只看能不能跑起来这一个指标。实际评估时我记录了六个维度评估维度具体含义记录方式首次可运行率第一次生成的代码直接跑起来的比例百分比代码结构文件拆分、模块化程度、命名规范主观评分1-5物理与碰撞碰撞检测是否准确、有无穿模实测观察相机手感跟随是否平滑、有无抖动或穿墙实测体验调试轮次从首次运行到完全可用需要几轮修改计数扩展友好度后续加功能是否容易主观评分1-5这套维度是我根据多年做外包项目的验收标准改的。甲方验收游戏Demo时最看重的就是能不能跑和手感对不对代码写得再漂亮跑不起来或者操作别扭都是白搭。2.3 控制变量环境与工具链三个模型我都是在同一台机器、同一个浏览器Chrome 120、同一个Three.js版本r158下测试的。每个模型生成代码后我都是新建一个干净的HTML文件通过本地静态服务器打开避免缓存和依赖污染。有一点需要说明这三个模型我都是通过API直接调用的没有经过任何中间工作台或代理层。这样做的原因是中间层可能会对提示词做改写或对输出做后处理影响对比的纯粹性。如果你平时习惯用工作台类工具实际体验可能和我的结果有差异这个后面会专门讲。3. Step 5 Preview 的首轮表现结构惊喜与细节遗憾3.1 代码组织方式让人眼前一亮Step 5 Preview 给我的第一印象是这模型有工程思维。它没有把所有代码塞进一个HTML文件里而是主动拆成了四个文件index.html、main.js、player.js、game.js。main.js负责场景初始化和渲染循环player.js封装了角色控制和相机逻辑game.js管理游戏状态和收集物。这种拆分方式不是我在提示词里要求的是它自己决定的。我特意在提示词里只说了用Three.js做游戏没有提任何文件结构的要求。它主动做模块化说明它在训练时见过大量真实项目的组织方式而不是只会写教学Demo。player.js里的相机跟随逻辑写得尤其干净。它用了一个平滑插值的方式让相机跟随角色而不是硬绑定位置。核心代码大概是这样// 相机平滑跟随 const idealOffset new THREE.Vector3(0, 5, -8); idealOffset.applyQuaternion(player.quaternion); idealOffset.add(player.position); camera.position.lerp(idealOffset, 0.1); camera.lookAt(player.position);这个lerp的0.1系数选得很讲究。太大了相机会抖太小了跟随会有延迟感。0.1是一个经验值说明模型对相机手感这件事有实际认知不是随便填的数字。3.2 碰撞检测的实现选择收集物的碰撞检测Step 5 Preview 用的是简单的距离判断而不是引入物理引擎。每个收集物是一个方块它计算玩家胶囊体和方块中心的距离小于某个阈值就判定为收集。这个方案对于这个游戏来说完全够用而且性能开销极小。我特意问过它为什么不引入Cannon.js或Ammo.js这类物理引擎。它的回答是这个游戏只需要碰到就消失的判定不需要真实的物理反馈引入物理引擎会增加复杂度和加载时间得不偿失。这个判断是对的。很多新手做游戏时喜欢上来就堆物理引擎结果发现大部分功能用不上还拖慢了性能。3.3 首轮翻车的地方Step 5 Preview 的首轮代码并不是完美的。我跑起来之后发现了两个问题。第一个问题是围墙的碰撞没有做。玩家可以直接穿墙走出去走到场景外面就掉下去了。它在场景搭建部分确实生成了四面墙的几何体但玩家移动逻辑里没有对围墙做边界检测。这是一个明显的遗漏说明它在生成场景和实现交互之间的关联性上还有欠缺。第二个问题是计时器的实现有bug。它用了setInterval每秒减一但没有在游戏结束时清除这个定时器。结果就是时间归零弹出结算界面后计时器还在后台跑分数还在被扣。这个bug很典型属于功能能跑但边界情况没处理。这两个问题我各花了一轮对话就修好了。修围墙碰撞时它主动提出用THREE.Box3做边界检测比我预想的方案更规范。修计时器时它加了clearInterval并在结算时暂停游戏循环处理得也算干净。4. DeepSeek V4 Pro 的实战稳但保守4.1 一次成型率最高DeepSeek V4 Pro 的首轮代码是三个模型里唯一一个直接跑起来没有报错的。它把所有代码放在一个HTML文件里结构上不如Step 5 Preview清爽但胜在完整。场景、角色、相机、收集物、UI、计时、结算所有模块都在而且逻辑自洽。它的角色控制用的是经典的PointerLockControls这是Three.js官方示例里的标准方案。鼠标锁定、WASD移动、视角旋转全部按标准实现。相机跟随用的是直接绑定位置加偏移量没有做平滑插值手感上比Step 5 Preview稍微硬一点但也不算差。4.2 保守但可靠的碰撞方案DeepSeek V4 Pro 的碰撞检测用的是Box3.intersectsBox比Step 5 Preview的距离判断更精确。它给玩家和每个收集物都创建了包围盒每帧检测相交。这个方案在收集物数量少的时候完全没问题但如果收集物增加到几百个性能会有压力。我后来问它如果收集物数量很大怎么办它建议用空间分割或者只检测玩家附近的收集物。这个回答说明它有性能优化的意识只是在首轮生成时选择了最稳妥的方案。这种先保证能跑再考虑优化的思路其实很符合工程实践。4.3 缺少惊喜的地方DeepSeek V4 Pro 的问题在于太标准了。它的代码像是从教科书里抄下来的每个部分都对但没有任何超出预期的设计。UI是纯HTML的div叠加没有做任何样式美化。收集物就是纯色方块没有旋转动画或发光效果。结算界面就是一个alert弹窗连个像样的面板都没有。我让它加一些视觉效果时它加了收集物的旋转和场景的环境光但整体审美依然偏保守。这不是能力问题更像是风格取向——它优先保证功能正确视觉表现放在次要位置。5. GLM5.3 的表现视觉惊艳与逻辑波动5.1 视觉细节最丰富GLM5.3 生成的代码第一眼看上去是最像游戏的。它给场景加了雾效、给收集物加了自发光材质和旋转动画、给玩家角色加了拖尾效果、UI用了半透明毛玻璃风格。结算界面是一个带动画的面板而不是alert。这些视觉细节不是我在提示词里要求的是它主动加的。从审美角度说GLM5.3 的产出最接近一个能拿给人看的Demo。如果你做的是需要展示给非技术人员的原型GLM5.3 的默认审美会省掉很多后期美化的工作。5.2 逻辑层面的波动但GLM5.3 在逻辑层面出现了几个让我意外的波动。首先是角色移动速度它设了一个很大的值导致玩家移动起来像在飞很难精确控制。我调小之后它又在下一轮修改里把速度改回去了好像没有记住之前的调整。其次是收集物的刷新逻辑。它写了一个随机位置生成但没有做重叠检测结果有好几个收集物叠在一起。更麻烦的是有些收集物刷在了围墙里面玩家根本拿不到。这个问题在Step 5 Preview和DeepSeek V4 Pro那里都没有出现。第三个问题是相机穿墙。当玩家靠近围墙时相机会穿到墙外面去导致视野被遮挡。这个问题三个模型都有但GLM5.3 的最严重因为它把相机距离设得比较远。5.3 修复过程的体验修GLM5.3 的bug时我感觉它的记忆力不如另外两个。我指出收集物重叠的问题后它修了重叠检测但把之前调好的移动速度又改回了默认值。这种修一个坏一个的情况在另外两个模型上很少出现。不过它的优势在于当你明确描述想要的效果时它能给出很有创意的实现。比如我说让收集物被收集时有一个爆裂效果它用粒子系统做了一个相当漂亮的爆炸动画代码也不复杂。这种给方向就能出彩的能力在需要快速做视觉原型时很有价值。6. 三轮调试后的最终对比6.1 数据汇总我把三个模型从首轮到完全可用的过程整理成了表格对比项Step 5 PreviewDeepSeek V4 ProGLM5.3首次可运行否2处报错是否1处报错代码结构评分533碰撞准确性353相机手感534视觉表现325调试轮次3轮2轮5轮扩展友好度543综合可用度高高中高6.2 各自的适用场景Step 5 Preview 适合需要长期维护和扩展的项目。它的模块化结构让后续加功能很舒服我后来加了一个道具加速的功能只改了player.js和game.js两个文件没有动其他部分。如果你做的是要持续迭代的产品原型它的结构优势会越来越明显。DeepSeek V4 Pro 适合追求稳定和一次成型的场景。它的代码可能不是最漂亮的但最不容易出意外。如果你时间紧、不想反复调试它的首轮产出直接能用的概率最高。GLM5.3 适合做视觉演示和快速原型。它的默认审美最好能省掉大量美化工作。但你需要接受它在逻辑细节上可能不够严谨要留出额外的调试时间。6.3 一个意外的发现测试过程中我发现一个有意思的现象三个模型对第三人称相机的理解差异很大。Step 5 Preview 理解的是相机在角色后方跟随DeepSeek V4 Pro 理解的是相机围绕角色旋转GLM5.3 理解的是相机在角色斜上方俯视。这三种理解都合理但做出来的手感完全不同。这说明即使需求描述得很具体模型对空间关系的理解依然存在差异。如果你对相机手感有明确要求最好在提示词里用更具体的语言描述比如相机位于角色正后方5个单位、上方3个单位的位置。7. 关于工作台类工具的实际体验7.1 工作台对模型能力的放大与限制测试过程中我也试了通过工作台类工具调用这几个模型。工作台的价值在于它提供了文件管理、多轮对话记忆、代码预览等便利功能但代价是它可能会对提示词做改写或者对输出做格式化处理。我实测下来通过工作台调用时模型的代码结构普遍会变得更规整因为工作台通常会有代码规范检查。但另一方面工作台也可能限制模型的发挥比如强制要求某种文件结构或者对输出长度做截断。注意如果你要做严格的模型能力对比建议直接调用API。工作台的中间层会引入额外变量让对比结果失真。7.2 缓存与性能的取舍工作台类工具通常会在本地缓存对话记录、运行日志和临时文件。用久了之后缓存目录会变得很大。我见过有人的工作台缓存占了十几个GB主要是因为每次代码预览都会生成快照。如果你打算长期使用工作台建议定期清理缓存或者把缓存目录迁移到空间更大的盘。具体操作方式因工具而异一般在设置里能找到缓存目录或数据存储位置的选项。迁移前记得先关闭工作台否则文件被占用会导致迁移失败。7.3 规则设定对输出质量的影响工作台通常支持给模型设定自定义规则或系统提示词。我试过给同一个模型设定不同的规则输出质量差异很明显。比如设定优先保证代码可运行性时模型会倾向于用更保守的实现设定追求代码简洁优雅时模型会尝试更高级的写法但翻车概率也更高。我的建议是规则不要设太多三到五条就够了。规则太多会互相冲突模型反而无所适从。比较实用的几条规则包括代码必须能直接运行、关键逻辑要有注释、避免使用已废弃的API、文件结构要清晰。8. 从这次实测里我总结的几条经验8.1 提示词里要写验收标准这次测试最大的收获是在提示词里明确写出验收标准能显著提升首轮可用率。比如我后来把需求改成代码必须能直接在浏览器打开运行不能有控制台报错玩家不能穿墙三个模型的翻车率都下降了。模型不知道你的验收标准是什么它只能猜。你写得越具体它猜得越准。这就像给外包团队提需求你说做个游戏他给你个能跑但粗糙的东西你说做个游戏要求60帧流畅运行、无穿模、UI美观他给你的东西质量会高一个档次。8.2 分阶段提需求比一次性提需求好我试过一次性把完整需求丢给模型也试过分阶段提需求。分阶段的效果明显更好。比如先让它做场景角色移动跑通了再做收集物碰撞最后做UI计时结算。每个阶段验收通过再进入下一阶段整体返工率低很多。一次性提需求的问题是模型要同时处理太多约束容易顾此失彼。分阶段提需求每个阶段的约束少模型更容易做对。而且分阶段的过程中你可以根据上一阶段的产出调整下一阶段的描述灵活性更高。8.3 不要迷信一次生成完美代码三个模型我都试过让它们一次生成完整可用的代码没有一个能做到完美。这不是模型能力不行而是3D游戏开发本身的复杂度决定的。即使是有经验的开发者做这样一个Demo也需要反复调试不可能一次写对。把AI当成一个能快速产出初稿的初级开发者而不是能直接交付的资深开发者心态会好很多。初稿有bug是正常的你的价值在于快速定位问题并给出修复方向。8.4 保留每个模型的性格用久了会发现每个模型都有自己的性格。Step 5 Preview 偏工程思维DeepSeek V4 Pro 偏稳健保守GLM5.3 偏视觉创意。了解这些性格后你可以根据任务类型选择模型做架构设计找Step 5 Preview做核心逻辑找DeepSeek V4 Pro做视觉原型找GLM5.3。不要试图让一个模型在所有方面都表现完美那是不现实的。组合使用各取所长才是效率最高的方式。8.5 调试时给现象而不是指令修bug时我发现给模型描述现象比给指令更有效。比如不要说把移动速度改成5而要说玩家移动太快了很难精确控制感觉像在冰上滑。前者模型只会改一个数字后者模型会理解你的意图可能会同时调整加速度和摩擦力。这个技巧在三个模型上都有效。模型对自然语言的意图理解能力比我们想象的要强。你描述得越像真实用户的反馈它给出的修复方案越合理。9. 后续可以继续深挖的方向这次测试只覆盖了3D游戏这个单一场景而且游戏复杂度控制在中低水平。如果你想继续深挖有几个方向值得尝试。第一个方向是提高游戏复杂度比如加入敌人AI、多关卡、存档系统。复杂度提升后模型之间的差异可能会更明显尤其是代码组织能力和长上下文记忆能力。第二个方向是换技术栈比如用Unity或Godot做同样的游戏。不同引擎的API风格差异很大模型对它们的熟悉程度也不同对比结果会很有意思。第三个方向是测试多模型协作。比如让Step 5 Preview做架构设计DeepSeek V4 Pro写核心逻辑GLM5.3做视觉优化看能不能组合出一个比单模型更好的结果。这个方向我觉得最有潜力也更接近实际工作场景。第四个方向是测试长时间迭代。让同一个模型连续迭代二十轮看它的代码质量是逐渐提升还是逐渐劣化。这个测试能反映模型的长期记忆和上下文管理能力对需要长期维护的项目很有参考价值。我在实际使用中的体会是这三个模型都已经到了能干活的水平但离干好活还有距离。它们的产出需要你把关、调试、优化但确实能帮你省掉大量重复劳动。把AI当成一个不知疲倦的初级搭档而不是一个能替代你的专家这个定位目前来看是最务实的。 
长河君 · 2026/11/3 4:02:03 · 阅读 1.2k Step 5 Preview、DeepSeek V4 Pro、GLM5.3 同台实测：谁更适合做3D游戏？
1. 三个模型同台做3D游戏我为什么选这个题最近圈子里讨论度最高的话题之一就是几个主流大模型在同一个实战任务上的横向对比。Step 5 Preview、DeepSeek V4 Pro、GLM5.3 这三个名字频繁出现在各种技术群里但大多数讨论都停留在跑分和参数层面真正拿同一个完整项目去实测的内容少之又少。我花了大概三天时间用同一个3D游戏需求分别驱动这三个模型从零开始搭建、调试、跑通中间踩了不少坑也积累了一些在官方文档里绝对看不到的经验。这篇文章适合几类人看正在选型AI编程工具的技术负责人、想了解大模型实际编码能力边界的开发者、以及单纯好奇现在的大模型到底能不能独立做游戏的围观群众。我会把整个过程的完整链路拆开讲包括我怎么设计测试用例、每个模型在哪些环节表现突出、哪些地方翻车了、以及最后我怎么把三个模型的产出整合成一个能跑的东西。先交代一下测试环境。我用的是一台常规开发机32GB内存RTX 4070显卡系统是Ubuntu 22.04。3D游戏引擎选的是Three.js原因是它纯浏览器端运行不依赖复杂的本地编译环境三个模型对它的训练数据覆盖都比较充分公平性相对好。游戏类型选了一个第三人称收集类小游戏——玩家控制一个角色在场景里移动收集随机刷新的道具有计时和计分。这个需求复杂度适中既涉及3D渲染、物理碰撞、相机跟随又不会大到让模型直接放弃。提示做模型横向对比时任务复杂度要控制在单个模型能在一次对话里完成主体框架的范围内。任务太大所有模型都会因为上下文窗口限制而表现趋同任务太小又区分不出能力差异。我之所以特别关注Step 5 Preview是因为它在社区里的讨论声量虽然不如另外两个大但在代码生成这个细分方向上不少人反馈它的结构组织能力有惊喜。DeepSeek V4 Pro 则是老牌选手代码能力一直在线。GLM5.3 最近热度很高尤其是配合各种工作台工具使用的场景被反复提及。三个模型各有拥趸但真正放在同一个3D游戏项目里对比我还没看到有人认真做过。2. 测试用例的设计怎么让对比结果有说服力2.1 需求拆解与提示词统一横向对比最容易犯的错误就是给不同模型喂不同的提示词。我在这件事上非常克制三个模型收到的初始需求完全一致连标点符号都没改。需求描述大概是这样用Three.js做一个第三人称3D收集游戏。场景是一个200x200的平面四周有围墙。玩家角色是一个胶囊体用WASD控制移动鼠标控制视角旋转。场景里随机刷新20个金色方块作为收集物玩家碰到就消失并加10分。屏幕左上角显示分数和剩余时间倒计时120秒。时间归零时弹出结算界面显示最终得分。相机跟随玩家保持一定距离和高度。这个需求我反复打磨过确保它覆盖了3D游戏开发的几个核心模块场景搭建、角色控制、相机系统、碰撞检测、UI系统、游戏状态管理。同时每个模块的描述都足够具体不会让模型在理解需求上产生歧义。2.2 评估维度的确定我没有只看能不能跑起来这一个指标。实际评估时我记录了六个维度评估维度具体含义记录方式首次可运行率第一次生成的代码直接跑起来的比例百分比代码结构文件拆分、模块化程度、命名规范主观评分1-5物理与碰撞碰撞检测是否准确、有无穿模实测观察相机手感跟随是否平滑、有无抖动或穿墙实测体验调试轮次从首次运行到完全可用需要几轮修改计数扩展友好度后续加功能是否容易主观评分1-5这套维度是我根据多年做外包项目的验收标准改的。甲方验收游戏Demo时最看重的就是能不能跑和手感对不对代码写得再漂亮跑不起来或者操作别扭都是白搭。2.3 控制变量环境与工具链三个模型我都是在同一台机器、同一个浏览器Chrome 120、同一个Three.js版本r158下测试的。每个模型生成代码后我都是新建一个干净的HTML文件通过本地静态服务器打开避免缓存和依赖污染。有一点需要说明这三个模型我都是通过API直接调用的没有经过任何中间工作台或代理层。这样做的原因是中间层可能会对提示词做改写或对输出做后处理影响对比的纯粹性。如果你平时习惯用工作台类工具实际体验可能和我的结果有差异这个后面会专门讲。3. Step 5 Preview 的首轮表现结构惊喜与细节遗憾3.1 代码组织方式让人眼前一亮Step 5 Preview 给我的第一印象是这模型有工程思维。它没有把所有代码塞进一个HTML文件里而是主动拆成了四个文件index.html、main.js、player.js、game.js。main.js负责场景初始化和渲染循环player.js封装了角色控制和相机逻辑game.js管理游戏状态和收集物。这种拆分方式不是我在提示词里要求的是它自己决定的。我特意在提示词里只说了用Three.js做游戏没有提任何文件结构的要求。它主动做模块化说明它在训练时见过大量真实项目的组织方式而不是只会写教学Demo。player.js里的相机跟随逻辑写得尤其干净。它用了一个平滑插值的方式让相机跟随角色而不是硬绑定位置。核心代码大概是这样// 相机平滑跟随 const idealOffset new THREE.Vector3(0, 5, -8); idealOffset.applyQuaternion(player.quaternion); idealOffset.add(player.position); camera.position.lerp(idealOffset, 0.1); camera.lookAt(player.position);这个lerp的0.1系数选得很讲究。太大了相机会抖太小了跟随会有延迟感。0.1是一个经验值说明模型对相机手感这件事有实际认知不是随便填的数字。3.2 碰撞检测的实现选择收集物的碰撞检测Step 5 Preview 用的是简单的距离判断而不是引入物理引擎。每个收集物是一个方块它计算玩家胶囊体和方块中心的距离小于某个阈值就判定为收集。这个方案对于这个游戏来说完全够用而且性能开销极小。我特意问过它为什么不引入Cannon.js或Ammo.js这类物理引擎。它的回答是这个游戏只需要碰到就消失的判定不需要真实的物理反馈引入物理引擎会增加复杂度和加载时间得不偿失。这个判断是对的。很多新手做游戏时喜欢上来就堆物理引擎结果发现大部分功能用不上还拖慢了性能。3.3 首轮翻车的地方Step 5 Preview 的首轮代码并不是完美的。我跑起来之后发现了两个问题。第一个问题是围墙的碰撞没有做。玩家可以直接穿墙走出去走到场景外面就掉下去了。它在场景搭建部分确实生成了四面墙的几何体但玩家移动逻辑里没有对围墙做边界检测。这是一个明显的遗漏说明它在生成场景和实现交互之间的关联性上还有欠缺。第二个问题是计时器的实现有bug。它用了setInterval每秒减一但没有在游戏结束时清除这个定时器。结果就是时间归零弹出结算界面后计时器还在后台跑分数还在被扣。这个bug很典型属于功能能跑但边界情况没处理。这两个问题我各花了一轮对话就修好了。修围墙碰撞时它主动提出用THREE.Box3做边界检测比我预想的方案更规范。修计时器时它加了clearInterval并在结算时暂停游戏循环处理得也算干净。4. DeepSeek V4 Pro 的实战稳但保守4.1 一次成型率最高DeepSeek V4 Pro 的首轮代码是三个模型里唯一一个直接跑起来没有报错的。它把所有代码放在一个HTML文件里结构上不如Step 5 Preview清爽但胜在完整。场景、角色、相机、收集物、UI、计时、结算所有模块都在而且逻辑自洽。它的角色控制用的是经典的PointerLockControls这是Three.js官方示例里的标准方案。鼠标锁定、WASD移动、视角旋转全部按标准实现。相机跟随用的是直接绑定位置加偏移量没有做平滑插值手感上比Step 5 Preview稍微硬一点但也不算差。4.2 保守但可靠的碰撞方案DeepSeek V4 Pro 的碰撞检测用的是Box3.intersectsBox比Step 5 Preview的距离判断更精确。它给玩家和每个收集物都创建了包围盒每帧检测相交。这个方案在收集物数量少的时候完全没问题但如果收集物增加到几百个性能会有压力。我后来问它如果收集物数量很大怎么办它建议用空间分割或者只检测玩家附近的收集物。这个回答说明它有性能优化的意识只是在首轮生成时选择了最稳妥的方案。这种先保证能跑再考虑优化的思路其实很符合工程实践。4.3 缺少惊喜的地方DeepSeek V4 Pro 的问题在于太标准了。它的代码像是从教科书里抄下来的每个部分都对但没有任何超出预期的设计。UI是纯HTML的div叠加没有做任何样式美化。收集物就是纯色方块没有旋转动画或发光效果。结算界面就是一个alert弹窗连个像样的面板都没有。我让它加一些视觉效果时它加了收集物的旋转和场景的环境光但整体审美依然偏保守。这不是能力问题更像是风格取向——它优先保证功能正确视觉表现放在次要位置。5. GLM5.3 的表现视觉惊艳与逻辑波动5.1 视觉细节最丰富GLM5.3 生成的代码第一眼看上去是最像游戏的。它给场景加了雾效、给收集物加了自发光材质和旋转动画、给玩家角色加了拖尾效果、UI用了半透明毛玻璃风格。结算界面是一个带动画的面板而不是alert。这些视觉细节不是我在提示词里要求的是它主动加的。从审美角度说GLM5.3 的产出最接近一个能拿给人看的Demo。如果你做的是需要展示给非技术人员的原型GLM5.3 的默认审美会省掉很多后期美化的工作。5.2 逻辑层面的波动但GLM5.3 在逻辑层面出现了几个让我意外的波动。首先是角色移动速度它设了一个很大的值导致玩家移动起来像在飞很难精确控制。我调小之后它又在下一轮修改里把速度改回去了好像没有记住之前的调整。其次是收集物的刷新逻辑。它写了一个随机位置生成但没有做重叠检测结果有好几个收集物叠在一起。更麻烦的是有些收集物刷在了围墙里面玩家根本拿不到。这个问题在Step 5 Preview和DeepSeek V4 Pro那里都没有出现。第三个问题是相机穿墙。当玩家靠近围墙时相机会穿到墙外面去导致视野被遮挡。这个问题三个模型都有但GLM5.3 的最严重因为它把相机距离设得比较远。5.3 修复过程的体验修GLM5.3 的bug时我感觉它的记忆力不如另外两个。我指出收集物重叠的问题后它修了重叠检测但把之前调好的移动速度又改回了默认值。这种修一个坏一个的情况在另外两个模型上很少出现。不过它的优势在于当你明确描述想要的效果时它能给出很有创意的实现。比如我说让收集物被收集时有一个爆裂效果它用粒子系统做了一个相当漂亮的爆炸动画代码也不复杂。这种给方向就能出彩的能力在需要快速做视觉原型时很有价值。6. 三轮调试后的最终对比6.1 数据汇总我把三个模型从首轮到完全可用的过程整理成了表格对比项Step 5 PreviewDeepSeek V4 ProGLM5.3首次可运行否2处报错是否1处报错代码结构评分533碰撞准确性353相机手感534视觉表现325调试轮次3轮2轮5轮扩展友好度543综合可用度高高中高6.2 各自的适用场景Step 5 Preview 适合需要长期维护和扩展的项目。它的模块化结构让后续加功能很舒服我后来加了一个道具加速的功能只改了player.js和game.js两个文件没有动其他部分。如果你做的是要持续迭代的产品原型它的结构优势会越来越明显。DeepSeek V4 Pro 适合追求稳定和一次成型的场景。它的代码可能不是最漂亮的但最不容易出意外。如果你时间紧、不想反复调试它的首轮产出直接能用的概率最高。GLM5.3 适合做视觉演示和快速原型。它的默认审美最好能省掉大量美化工作。但你需要接受它在逻辑细节上可能不够严谨要留出额外的调试时间。6.3 一个意外的发现测试过程中我发现一个有意思的现象三个模型对第三人称相机的理解差异很大。Step 5 Preview 理解的是相机在角色后方跟随DeepSeek V4 Pro 理解的是相机围绕角色旋转GLM5.3 理解的是相机在角色斜上方俯视。这三种理解都合理但做出来的手感完全不同。这说明即使需求描述得很具体模型对空间关系的理解依然存在差异。如果你对相机手感有明确要求最好在提示词里用更具体的语言描述比如相机位于角色正后方5个单位、上方3个单位的位置。7. 关于工作台类工具的实际体验7.1 工作台对模型能力的放大与限制测试过程中我也试了通过工作台类工具调用这几个模型。工作台的价值在于它提供了文件管理、多轮对话记忆、代码预览等便利功能但代价是它可能会对提示词做改写或者对输出做格式化处理。我实测下来通过工作台调用时模型的代码结构普遍会变得更规整因为工作台通常会有代码规范检查。但另一方面工作台也可能限制模型的发挥比如强制要求某种文件结构或者对输出长度做截断。注意如果你要做严格的模型能力对比建议直接调用API。工作台的中间层会引入额外变量让对比结果失真。7.2 缓存与性能的取舍工作台类工具通常会在本地缓存对话记录、运行日志和临时文件。用久了之后缓存目录会变得很大。我见过有人的工作台缓存占了十几个GB主要是因为每次代码预览都会生成快照。如果你打算长期使用工作台建议定期清理缓存或者把缓存目录迁移到空间更大的盘。具体操作方式因工具而异一般在设置里能找到缓存目录或数据存储位置的选项。迁移前记得先关闭工作台否则文件被占用会导致迁移失败。7.3 规则设定对输出质量的影响工作台通常支持给模型设定自定义规则或系统提示词。我试过给同一个模型设定不同的规则输出质量差异很明显。比如设定优先保证代码可运行性时模型会倾向于用更保守的实现设定追求代码简洁优雅时模型会尝试更高级的写法但翻车概率也更高。我的建议是规则不要设太多三到五条就够了。规则太多会互相冲突模型反而无所适从。比较实用的几条规则包括代码必须能直接运行、关键逻辑要有注释、避免使用已废弃的API、文件结构要清晰。8. 从这次实测里我总结的几条经验8.1 提示词里要写验收标准这次测试最大的收获是在提示词里明确写出验收标准能显著提升首轮可用率。比如我后来把需求改成代码必须能直接在浏览器打开运行不能有控制台报错玩家不能穿墙三个模型的翻车率都下降了。模型不知道你的验收标准是什么它只能猜。你写得越具体它猜得越准。这就像给外包团队提需求你说做个游戏他给你个能跑但粗糙的东西你说做个游戏要求60帧流畅运行、无穿模、UI美观他给你的东西质量会高一个档次。8.2 分阶段提需求比一次性提需求好我试过一次性把完整需求丢给模型也试过分阶段提需求。分阶段的效果明显更好。比如先让它做场景角色移动跑通了再做收集物碰撞最后做UI计时结算。每个阶段验收通过再进入下一阶段整体返工率低很多。一次性提需求的问题是模型要同时处理太多约束容易顾此失彼。分阶段提需求每个阶段的约束少模型更容易做对。而且分阶段的过程中你可以根据上一阶段的产出调整下一阶段的描述灵活性更高。8.3 不要迷信一次生成完美代码三个模型我都试过让它们一次生成完整可用的代码没有一个能做到完美。这不是模型能力不行而是3D游戏开发本身的复杂度决定的。即使是有经验的开发者做这样一个Demo也需要反复调试不可能一次写对。把AI当成一个能快速产出初稿的初级开发者而不是能直接交付的资深开发者心态会好很多。初稿有bug是正常的你的价值在于快速定位问题并给出修复方向。8.4 保留每个模型的性格用久了会发现每个模型都有自己的性格。Step 5 Preview 偏工程思维DeepSeek V4 Pro 偏稳健保守GLM5.3 偏视觉创意。了解这些性格后你可以根据任务类型选择模型做架构设计找Step 5 Preview做核心逻辑找DeepSeek V4 Pro做视觉原型找GLM5.3。不要试图让一个模型在所有方面都表现完美那是不现实的。组合使用各取所长才是效率最高的方式。8.5 调试时给现象而不是指令修bug时我发现给模型描述现象比给指令更有效。比如不要说把移动速度改成5而要说玩家移动太快了很难精确控制感觉像在冰上滑。前者模型只会改一个数字后者模型会理解你的意图可能会同时调整加速度和摩擦力。这个技巧在三个模型上都有效。模型对自然语言的意图理解能力比我们想象的要强。你描述得越像真实用户的反馈它给出的修复方案越合理。9. 后续可以继续深挖的方向这次测试只覆盖了3D游戏这个单一场景而且游戏复杂度控制在中低水平。如果你想继续深挖有几个方向值得尝试。第一个方向是提高游戏复杂度比如加入敌人AI、多关卡、存档系统。复杂度提升后模型之间的差异可能会更明显尤其是代码组织能力和长上下文记忆能力。第二个方向是换技术栈比如用Unity或Godot做同样的游戏。不同引擎的API风格差异很大模型对它们的熟悉程度也不同对比结果会很有意思。第三个方向是测试多模型协作。比如让Step 5 Preview做架构设计DeepSeek V4 Pro写核心逻辑GLM5.3做视觉优化看能不能组合出一个比单模型更好的结果。这个方向我觉得最有潜力也更接近实际工作场景。第四个方向是测试长时间迭代。让同一个模型连续迭代二十轮看它的代码质量是逐渐提升还是逐渐劣化。这个测试能反映模型的长期记忆和上下文管理能力对需要长期维护的项目很有参考价值。我在实际使用中的体会是这三个模型都已经到了能干活的水平但离干好活还有距离。它们的产出需要你把关、调试、优化但确实能帮你省掉大量重复劳动。把AI当成一个不知疲倦的初级搭档而不是一个能替代你的专家这个定位目前来看是最务实的。