AI编程横向实测：Step 5预览、DeepSeek V4 Pro与GLM5.3生成3D游戏全对比

最近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 Pro，M1 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行依然完成了游戏框架，但很多判断逻辑是硬编码在渲染循环里的，可扩展性最差。

具体差异我整理成了表格，方便直接对照：

这个表可以说明一个核心问题：代码量多不等于游戏更好，但代码量过少往往意味着功能覆盖不足。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再跑一版对比，到时候有结果了再来继续聊。