★ FEATURED ARTICLE 最近AI编程圈最热闹的一件事就是各家模型密集放新版本尤其是代码生成方向几乎每周都有能让我这种老开发眼前一亮的产物。我手里攒了个特别适合做横向评测的活儿用同一份需求分别让Step 5 Preview、DeepSeek V4 Pro、GLM5.3三款模型写一个3D游戏不加任何辅助提示、不做二次修改纯看它们从零开始能交出什么样的成品。为什么挑3D游戏当考卷因为它是最考验模型综合能力的场景——从Three.js工程搭建、物理碰撞、场景光源到玩法逻辑、UI交互、运行性能任何一个环节理解不到位页面就直接黑屏给你看。这篇文章就是我的完整实测记录包含Prompt原稿、三款模型生成过程的细节对比、运行效果分析以及最后阶段遇到的坑和排查思路给想用AI做3D游戏开发或者正在纠结代码模型选型的朋友提供一份直接能抄的参考。1. 项目整体设计与评测思路1.1 为什么选择3D游戏作为测试基准写模型的代码评测如果只让AI写个计算器、待办事项这种十几行的小玩具根本拉不开差距最后全是都能跑的无效结论。3D游戏这个选型我是刻意选的因为它天然覆盖了足够宽的技术栈。渲染层要在Three.js、WebGL、CSS3D之间做选型还要考虑光照模型、阴影贴图、相机控制玩法层需要碰撞检测、状态机、定时器、事件监听工程层则牵扯模块拆分、资源加载、视口适配、性能优化。这些环节里任意一个模型理解不到位都会在运行时暴露出来。我一直觉得让AI做一件看起来简单但细节巨多的事才是检验它真实水平的唯一标准。另一个重要原因是纯文本生成3D游戏天然存在想象差。模型需要从我的文字描述里推测出画面风格、操作手感和关卡节奏这对语义理解和视觉想象能力的要求远高于生成一个CRUD页面。它写完逻辑还要能写出配套的HTML结构、CSS样式以及可能用到的纹理和模型数据。这些细节看似不起眼实际上把模型的综合输出能力暴露得一干二净。还有一点很实际3D游戏出错非常直观。页面空白、物体穿模、相机抖动、帧率拉胯任何一个玩过游戏的人都能一眼发现。评测门槛低不需要专业背景也能参与评价这对我写这篇文章来说非常重要。1.2 三款模型的基本定位与测试环境先介绍本次实测的三位主角。Step 5 Preview是最近刚放出测试通道的代码生成模型预览版主打长上下文和复杂项目一次成型社区里讨论热度挺高很多人说它在搭项目骨架这件事上有独到之处。DeepSeek V4 Pro是DeepSeek系列的最新开发者向版本延续了它家在中文需求理解上的传统优势参数规模大推理链路长社区普遍反馈补全感很强。GLM5.3则是智谱AI推出的通用大模型版本官方宣传里特别强调了它对前端框架和交互细节的把控实际表现如何正好这次拉出来遛遛。测试过程中我没有对三个模型做任何API层面的特殊配置。统一使用对话式生成不开联网搜索、不喂额外文档、不调温度参数全部走默认值。这样测出来的结果就是模型原生能力的差距不会被外部因素污染。测试环境是一台2021年的MacBook ProM1 Pro芯片、16GB内存浏览器用Chrome最新版本地用Vite起了一个静态开发服务器。选这个环境不是随手定的。M1芯片对WebGL的支持不算激进模型生成的代码如果有兼容性问题会在第一时间报错16GB内存也比较接近普通开发者的配置不会因为机器太强就掩盖掉代码本身的效率问题。在这个环境下能跑得动的项目大多数人的电脑基本也能跑得动。1.3 评测范围边界与评分体系为了避免评测失真我提前划定了边界。不测代码补全的联网能力只看模型本身的生成水平不拿某一款模型生成的代码去指导另一款改Bug防止结果交叉污染评分只针对游戏是否可玩、代码是否合理、结构是否清晰不对模型本身做倾向性评价。评分体系一共三块功能完整度占5分视觉完成度占3分工程质量占2分。功能层面看角色能否移动、跳跃是否灵敏、碰撞是否生效、计时得分是否准确视觉层面看场景物体丰富度、光照阴影是否正常、相机视角是否舒服工程层面看代码结构是否清晰、注释是否完善、有没有明显冗余、在低配机器上的帧率表现如何。这套评分标准偏主观但结合下面完整的实测记录读者完全可以对照自己的判断重新打分。2. 需求拆解与Prompt设计2.1 把做个3D游戏变成一份可执行的需求文档很多人让AI生成游戏上来就是一句帮我做一个3D游戏然后拿到结果一脸懵。说实话这真不能怪模型需求太空泛了。任何模型面对这种开放式任务都会往自己训练数据里最经典的模板靠——大概率生成一个只有几个旋转几何体的空场景或者一个粗糙到没法玩的迷宫。这不是模型笨是它真的不知道你想要什么。我这次的需求文档是自己提前拆过的前后花了大概一个小时把游戏拆成了7个维度玩法类型、场景设定、操作方式、核心机制、胜负条件、视觉风格、技术要求。层层拆完之后需求就变得非常具体了。最终的玩法定为跳跃收集类玩家控制一个卡通角色在3D平台上跳跃收集散落在空中的金色星星同时躲避移动障碍物60秒内收集的星星越多得分越高。整体视觉走低多边形卡通风刻意避开高精模型和复杂纹理这样既容易生成也不容易出错。技术要求方面我特别写了一条You need to use HTML CSS Three.js JavaScript所有代码放在一个HTML文件中。这个单文件约束是故意加的。拿三份单文件HTML做对比比拿三个多目录工程做对比要直观得多而且生成的文件双击就能跑对读者来说复现成本也最低。2.2 评测用Prompt原文给AI的Prompt我写得非常细格式化之后大概长这样请用HTML CSS Three.js JavaScript实现一个完整的3D跳跃收集游戏。 【玩法】玩家在地图上移动并跳跃收集随机生成的星星躲避移动障碍物。 【操作】WASD控制移动空格跳跃支持鼠标拖拽调整视角。 【地图】平整的草地平台四周有低多边形树木和石块。 【角色】一个低多边形风格的人形主角带简单颜色区分。 【机制】星星随机刷新每收集一个得10分障碍物沿固定路线移动碰到角色则扣生命值60秒倒计时结束后显示总分。 【视觉】卡通低多边形风格暖色调光照有阴影天空盒用渐变色。 【代码要求】所有代码放在一个HTML文件中使用CDN引入Three.js默认适配1280x720视口提供清晰的代码注释。这三份Prompt完全一致一字不改发给三个模型。有人可能担心不给参考图、不给示例链接模型真能生成出低多边形风格吗实测下来能。如今的主流模型对low poly这个概念是有足够的视觉理解的虽然做不出原创素材但会用几何体拼出树木、石块、人形角色这些基础形状效果还真不差至少一眼能认出是什么东西。2.3 统一验收标准说明三份结果生成之后我全部在本地跑起来按照同一套标准验收。功能层面逐项核对移动、跳跃、碰撞、计时、计分视觉层面看场景完成度、光照阴影、视角舒适度工程质量方面检查代码组织、注释质量、冗余程度和帧率表现。评分我全部自己来每项功能做没做、做到什么程度一目了然。为了让横向对比更直观我最后把所有结果整理成了一张表格在第4小节统一呈现。这里先把标准亮出来各位看完后面的实测过程可以直接对照标准重新评估每一个模型的表现。3. 三款模型的生成实测记录3.1 Step 5 Preview骨架能力强但交互手感欠打磨第一轮测的是Step 5 Preview。输入Prompt之后它花了大约28秒生成输出了一段约950行代码的单文件。我第一眼看到代码结构时确实有点意外——它为每个功能模块都写了注释头角色控制、碰撞检测、UI更新、星星生成全部拆成独立函数组织性上确实有独到之处社区说它搭骨架强看来不是吹的。把生成的文件保存成HTML直接打开首次运行没有报错场景正常加载出来草地平台、蓝天渐变、主角小人都在。当时我心里给它的工程分已经超过了及格线至少一次成型这件事它做到了。但接下来深入玩了几分钟问题就暴露出来了。首先是移动手感。WASD控制下角色太滑松开按键之后还会向前滑行好一段距离才慢慢停住这在需要精准跳跃的游戏里会让人很烦躁。更关键的是跳跃手感Step 5 Preview做的跳跃根本就不是真正意义上的跳跃而是角色沿Y轴做了一组先升后降的三帧位移模拟跳得很低大概只有0.8个单位高度。对于跳上平台收集星星这个核心玩法来说可操作空间实在太小几乎跳不上任何稍高的障碍物。其次碰撞检测有比较典型的问题。角色和障碍物之间用的是球对球检测理论上没问题但实际设置的碰撞半径明显比视觉物体大了一圈导致角色还没碰到障碍物系统就已经判定损失生命值。我实际玩了一轮大概被空气撞掉了3条命。这个观感非常差因为玩家无法理解自己为什么受伤。不过Step 5 Preview有一个亮点值得单独说它在render函数里对移动中的障碍物做了阴影实时更新这个细节正好抓住了3D实时渲染的沉浸感。纯代码生成场景里能主动关注这种视觉细节的模型还是少这点让我对它的上限有了更高评价。3.2 DeepSeek V4 Pro需求覆盖精准代码细节在线第二个测的是DeepSeek V4 Pro。生成耗时约35秒输出代码大约1100行是三款模型里最长的。打开页面之后画面是三个结果里最完整的一个更强的暖色光照对比、更细致的低多边形树木——树干加树冠分了三层建模角色甚至带了一组简单的行走动画整体视觉完成度非常接近一个正式的游戏Demo。从功能维度看DeepSeek V4 Pro生成的代码几乎覆盖了Prompt里提到的全部需求。WASD移动、空格跳跃、鼠标拖拽镜头甚至连鼠标滚轮缩放视角都做了。跳跃高度提高到了1.5个单位落地有缓冲移动加了阻尼手感明显好于Step 5 Preview。倒计时、得分、生命值三条UI都非常清楚结束画面还提供了重新开始的按钮游戏循环是完整的。我最看重的是它的碰撞系统。DeepSeek V4 Pro用的是包围盒包围球混合检测针对不同形状的物体采用不同方案树干用长方体包围盒、石头用球体包围盒。实测角色贴到障碍物边缘时判定准确没有出现Step 5 Preview那种空气碰撞的情况这对游戏体验的提升是决定性的。不过DeepSeek V4 Pro也有让人头疼的地方。它的代码依赖强度很高模块之间存在比较隐性的耦合比如有个全局变量控制角色状态一旦被其他函数意外修改整个游戏会重载。我调试时想改小跳跃高度结果重力常量没有联动调整角色跳到半空就往下栽。另外帧率比另外两款低了约15%排查后发现是阴影贴图分辨率设置得太激进每次渲染都要做全场景深度图计算对GPU压力不小。DeepSeek V4 Pro给我的整体印象是三款里最接近一位严谨工程师写的代码的产物结构、注释、健壮性都可圈可点但相应地它对运行资源的消耗也更大。如果游戏复杂度继续往上走性能瓶颈会是最先需要解决的问题。3.3 GLM5.3风格灵活创意加分但稳定性碰运气最后测的是GLM5.3。生成速度最快只用了大约17秒输出代码约620行明显比前两个精简。打开页面的第一眼印象是这东西挺有设计感——角色是个戴宽檐帽的小人地形不是单纯的平面而是带轻微起伏的丘陵星星收集物被做成了旋转的金币效果比前两个模型都更游戏化会让人觉得开发者是真正玩了并思考过什么有趣。GLM5.3在玩法上也很有自己的想法。Prompt里我要求障碍物沿固定路线移动它却额外做了一个障碍物在碰到角色瞬间临时加速的设定给游戏带来了短暂的紧张感。这算是超出预期的部分说明模型具备一定的游戏设计直觉。不过创意是要付出代价的这个临时加速机制导致难度曲线很不合理后期障碍物密集度高到基本躲不开玩到40秒左右几乎每一两秒就要被撞一次体验上有点心累。稳定性方面GLM5.3让我比较纠结。前两次运行页面都正常第三次刷新直接白屏检查代码发现是Three.js版本差异问题——它用了CDN上的较新版本而另外两款模型都用了经典r152。新版Three.js对某些旧式写法不再兼容导致渲染器初始化失败。这个不完全是模型的责任但确实暴露了它对版本适配的考虑不够周全。还有个小细节值得一提GLM5.3的空格跳跃没有做只允许在地面起跳的判断。正常情况下玩家在空中不能再次起跳它却允许无限二段跳。角色可以一路往天上飘这等于直接把游戏难度抹平了。在休闲游戏里这不是大问题但作为跳跃收集玩法它让玩家完全失去了对重力、节奏和风险的管理只能说是个明显的取舍偏差。4. 运行效果对比与代码质量分析4.1 三款模型输出代码的结构对比把三份代码并排放在一起看差异比想象中更直观。Step 5 Preview走的是大而全路线950行代码里放了大量防御性判断和冗余变量所有模块各归各的结构清晰但不够紧凑。DeepSeek V4 Pro是精打细算的典型1100行代码里几乎每个变量都有实际用途模块之间耦合度高一些但逻辑非常扎实。GLM5.3走的是极简主义620行依然完成了游戏框架但很多判断逻辑是硬编码在渲染循环里的可扩展性最差。具体差异我整理成了表格方便直接对照维度Step 5 PreviewDeepSeek V4 ProGLM5.3代码行数约950行约1100行约620行文件结构模块化注释完善耦合性强变量复用率高平铺直叙函数嵌套少功能覆盖度80%95%75%可运行性首次即可运行首次即可运行偶发白屏移动手感偏滑有阻尼问题手感接近正式游戏有二段跳Bug视觉表现中高中高平均帧率M1 Pro默认视口58FPS51FPS60FPS这个表可以说明一个核心问题代码量多不等于游戏更好但代码量过少往往意味着功能覆盖不足。GLM5.3帧率最高恰恰是因为它的场景物最少、计算量最低可玩性也因此打了折扣。DeepSeek V4 Pro帧率最低纯粹是细节堆得太多并不是基础性能不行通过优化完全能追回来。4.2 游戏可玩性与综合体验排序从真实游玩体验来看如果只让我选一个最接近商业小游戏Demo的DeepSeek V4 Pro排第一GLM5.3排第二Step 5 Preview排第三。DeepSeek V4 Pro赢在完整度上从开始界面、游戏循环到结束结算整个链路没有断裂感GLM5.3赢在手感和视觉创意如果抛开二段跳Bug它的操控感其实是最好的Step 5 Preview则像一个高完成度脚手架作为从零开始搭建项目的起点非常合适但要交付到可玩状态还需要一个完整的调优周期。公平性方面我需要说明一下GLM5.3是三个模型里唯一用了不符合预期的Three.js版本的如果给它换到与另外两款相同的经典版本也许稳定性表现会好很多。但取默认值本来就是实际开发中最常见的使用方式模型理应对自己选的默认版本负责。所以这个锅我还是决定记在它头上。这轮实测还有一个很有意思的发现三个模型的性格差异其实会在代码风格里体现得非常明显。Step 5 Preview喜欢把各种可能的情况都预判一遍有时候过度防御DeepSeek V4 Pro像一位严谨的工程师结构紧凑但改动需要理解全局GLM5.3则更像喜欢炫技的创作者想法多但边界感弱。这种风格差异会直接影响后续维护的成本——你在改代码之前得先理解这个模型的思维方式。5. 常见问题与排查技巧实录5.1 3D场景黑屏或白屏先看Three.js版本任何一个模型生成的3D游戏遇到的第一个问题大概率是页面空白。这次三个结果里GLM5.3就因为在CDN引用了一个较新版本的Three.js而触发了一次白屏。排查思路其实非常固定打开浏览器控制台看报错如果错误信息里出现THREE.WebGLRenderer is not defined或者X is not a constructor这类字样90%是Three.js没加载成功或者版本不兼容。我的建议是代码生成之后第一件事是固定Three.js的CDN版本。不要用不带版本号的最新版而是明确指定r152、r160、r168这样的具体版本。如果模型在代码里用到了某个版本才有的API你换了另一个版本很可能就起不来。这已经是AI生成代码时代的工程基本功了做不做直接影响后续能不能跑。另外黑屏还有一个很隐蔽的原因是WebGL上下文冲突。如果浏览器开了很多占用WebGL的页面或者系统GPU进程异常Three.js可能无法创建渲染上下文。这种时候刷新页面、重启浏览器大部分情况就能恢复不需要过度怀疑自己的代码。结合这轮实测我个人的经验是拿到一份AI生成的3D HTML文件第一步不是双击打开而是先快速扫一眼Three.js的CDN地址和场景初始化部分的代码确认版本和用法匹配之后再运行。这个动作能帮你省下大量排查白屏的时间。5.2 碰撞判断失真的排查思路碰撞是3D游戏里最容易出Bug的环节三个模型全都在这个环节出过问题。Step 5 Preview的空气碰撞是碰撞半径设置过大GLM5.3的二段跳是没有限制地面起跳而DeepSeek V4 Pro虽然准确度高但碰撞函数代码复杂、联调成本高。排查碰撞失真问题第一步是打开开发者工具的Console在碰撞检测函数里加console.log把实际发生碰撞时的距离值、两个物体的半径或包围盒尺寸打出来。对比一下就能看出到底是半径设置问题、坐标计算问题还是根本没有调用碰撞函数。这一步省不得盲改代码只会让问题更糟。还有一个很常见的坑是掉了碰撞检测用局部坐标的陷阱。模型生成的代码里物体往往带有旋转角度如果直接用position属性做距离计算碰撞区域会随着旋转偏移。正确的做法是先把世界坐标取出来比如用Object3D的getWorldPosition方法再基于世界坐标算距离或做相交测试。这个小细节我在处理模型生成代码时经常要用到建议大家在调试时多留个心眼。Step 5 Preview用的球对球碰撞比较适合教程场景但实际项目里障碍物往往是长方体球体假设很容易失真。至少给它一个更贴近视觉形状的简化碰撞体判断才会更准确。对于纯代码生成的游戏来说这不是一个很高门槛的要求但模型能主动做到的真不多。5.3 帧率低下的定位与优化DeepSeek V4 Pro那次比另外两款低15%帧率的情况实测下来的元凶是阴影贴图分辨率。Three.js默认的阴影贴图是512×512而DeepSeek V4 Pro把shadowMap的类型设置成了PCFSoftShadowMap并且把分辨率提到了2048渲染压力当然会明显上升。优化思路非常直接先把shadowMap的分辨率降下来从2048降到1024再看帧率是否恢复。如果场景光源数量多可以考虑合并光源或改用CSM级联阴影但在这种小游戏规模下完全没必要。另外调低阴影贴图类型从PCFSoftShadowMap降为PCFShadowMap视觉效果差别很小但性能收益肉眼可见。另一个容易忽略的帧率杀手是每帧实时创建物体。有些模型为了让星星持续刷新会在render循环里反复new新的Mesh导致每帧都产生大量内存垃圾触发GC之后帧率突然掉落。正确的方案是预创建对象池游戏开始时就生成一批星星被收集后先隐藏起来而不是销毁需要刷新时直接复用。这个优化一上帧率通常能提升10%以上而且代码改动量很小就看你懂不懂这个套路。5.4 快速让AI修复问题的技巧最后分享一个让AI自己修Bug的方法。很多人遇到问题之后直接把整段报错信息丢回给模型这当然可行但我建议你先做一步预处理把报错信息里不相关的部分删掉只保留关键行号和错误类型。因为模型在处理大段混乱文本时注意力会被无关信息带偏反而抓不住真正的错误点回复质量会明显下滑。如果一个简单问题连续让模型修三次都没修好我的建议是不要再和它死磕。换个策略把问题拆成更小的子问题重新提问。比如把碰撞半径的计算逻辑单独抽出来改成基于包围盒的函数这种明确指令比帮我修一下碰撞Bug更容易让模型命中要害。实测下来这种提问方式在大模型上的修复成功率要高很多。这个方法的核心逻辑在于大模型的上下文窗口虽然大但注意力是有限的。让它同时处理找Bug和保持整体代码结构两个任务效果远不如只让它处理一个。把问题切小本质上就是帮模型降低认知负担。6. 实测之后关于AI写游戏的真实体会三个模型全部测完我对AI写3D游戏这件事的整体认知刷新了不少。以前我一直觉得AI生成游戏就是玩具级别只能糊弄一下没写过代码的新手但这次实测证明在需求足够明确的前提下模型完全有能力生成一个可运行、可操作、有一定趣味性的3D小游戏。DeepSeek V4 Pro那个版本我后来又玩了几轮除了正常收集星星之外还解锁了不少无意识的彩蛋操作——卡视角穿模、利用惯性漂移绕过障碍物这些虽然都是Bug但意外增加了一点娱乐性。与此同时我也更清楚地意识到AI写代码的天花板不在于写出来而在于理解需求边界。比如低多边形这个视觉需求三个模型的理解就完全不同。Step 5 Preview理解成用简单几何体堆叠DeepSeek V4 Pro理解成用分层的低模结构GLM5.3则理解成整体风格卡通化。参数没有对错但如果你不把需求写细结果往往会像开盲盒一样无法控制。从我做开发这些年的角度来看这类工具我现在基本把它们当成高配版代码搜索引擎来用。项目框架、算法原理、UI布局它能以极高的效率给你一个非常扎实的起点但打磨手感、平衡数值、解决特定硬件兼容性问题还是得靠人。这不是对AI的失望而是对工具的合理预期——锤子不会自己盖楼只是让盖楼更快。如果硬要给出选型建议第一次用AI做3D游戏的朋友建议这样起步先把需求拆到200字以上明确操作方式、视觉风格、技术栈、边界条件然后从单文件Three.js小游戏开始做起。在这个前提下Step 5 Preview适合快速搭建项目骨架DeepSeek V4 Pro更适合追求完整可玩性GLM5.3适合用来激发创意灵感。不过无论选哪一款都要预留至少一轮人工调优的时间纯生成不改就能完美运行的游戏我到现在还没见过。最后说个我自己的小心得跑这种横向评测最忌讳的是玩完就扔。我的习惯是把三份代码全部归档到项目仓库里记录下生成日期、版本号、运行环境。等下一轮模型版本更新之后再用完全相同的Prompt跑一次前后对比就能很清楚地看到各家模型的进步速度。这次Same道的Three.js版本不一致问题放到下一轮很可能就是修复了直接可用。工具的进步永远比我们想象中快但评测方法论的迭代得靠我们自己坚持。如果这篇实测对你有参考价值建议你也自己动手跑一遍同样流程用同一个Prompt测试你手上能接触到的各类模型。参数不一定要复刻我的游戏题材换成跑酷、解密、模拟经营都可以但一定要认真记录结果往往会颠覆你的初始判断。下次等这几个模型出了更新版本我还会用同一份Prompt再跑一版对比到时候有结果了再来继续聊。
阅读完成 · 觉得有帮助？
