按理说，AI 写代码的实测我应该早就做了，但市面上大多数对比都有点“表演性质”——模型写个 Hello World 就算成功，或者背后偷偷改了十几遍。这次我不玩虚的：把同一个 3D 游戏需求，原封不动地丢给最近热度很高的 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个模型，让它们各自独立从零写一遍。游戏要求我已经定死：用 Three.js 做一个网页 3D 小游戏，玩家用 WASD 控制角色移动、空格跳跃，在 3D 场景里收集金币并躲避障碍物，30 秒倒计时结束按分数结算。整个测试过程中，我不手动改代码，只把报错信息回传给模型让它自己修。这篇文章就是全部记录：三个模型分别表现如何、代码结构差异在哪、哪个最适合当你的游戏开发搭档，看完你心里就有数了。

1. 测试背景与思路设计

1.1 为什么同时测试这三个模型

这三个模型最近在编程圈确实绕不开。Step 5 Preview 是预览版，主打的标签就是代码结构化，官方示例里那些工程目录、接口设计确实干净，很多人拿它当“代码架构师”用。DeepSeek V4 Pro 是深度求索这一代产品里稳定性口碑最高的版本，社区里跑过长上下文的都知道它的“不跑题”能力，连续对话五十轮不带崩，用来写完整项目很合适。GLM5.3 则是智谱这一代的热度担当，生成速度快、创意表现强，而且开源生态活跃，很多人用它做游戏原型和互动 Demo。

我选这三个还有个原因：它们代表三种不同的模型取向。DeepSeek V4 Pro 是“稳妥型”——功能永远给你做齐，不追求花活；GLM5.3 是“创意型”——喜欢加特效加氛围，但代码稳定度偶尔打折；Step 5 Preview 是“结构型”——代码优雅、注释完整，但细节上有一些新模型常见的“小别扭”。三种风格放在同一个需求下，正好能看出选模型到底该看什么，是看能力上限，还是看下限。

如果只测一个模型，你很难判断它到底是好是坏。同一份提示词交给三个模型，等于让三个程序员做同一道题，差异就是最好的说明书。所以我把游戏需求、运行环境、评分标准全都固定成同一套，把所有不可控因素降到最低，剩下唯一的变量就是模型本身的生成能力。

1.2 测试方案：先定死规则再跑分

这种对比最怕的不是模型不好，而是测试条件不统一。条件不统一时结果就变成“凭感觉”，说什么都对，说什么都错。我给自己定的规则是这样三条：

第一，提示词完全一致。我写了一份统一需求文档，开头注明技术栈用 Three.js，中间按功能块逐条列出，结尾强调“不要改 HTML 骨架，不要用本地资源路径”。三个模型看到的是一模一样的文字。

第二，运行环境一致。开发机是 Win11 + Chrome 129，Three.js 固定走 CDN 的 r160 版本，本地用 VSCode 起一个npx serve静态服务。为什么不用 file:// 直接打开？因为 Three.js 走 ES module 时 file 协议会有跨域限制，窗口直接白屏。这些小坑如果不提前排掉，测出来的黑屏问题可能跟模型没有任何关系，先被环境坑了一道。

第三，评分维度一致且量化。我预设了五个维度：首轮运行是否成功、功能点完整度、代码可读性、帧率和加载耗时、操作手感。每一项分别记分，最后汇总。比如“功能点完整度”我拆成八个小项：角色移动、摄像机控制、跳跃、碰撞检测、金币旋转、计分显示、倒计时、失败/胜利界面。每个模型完成了几个就记几个，不做模糊的主观判断。

这套方案执行下来，对比结果才敢拿出来写文章。哪怕最终结论是“各有胜负”，那也是有依据的各有胜负，而不是“我觉得 A 好一点”的空话。

2. 核心细节解析与实操要点

2.1 环境准备的三个关键选择

先说说环境为什么这么配，因为这一步直接决定后续测试能不能顺利跑。

第一个选择是 Three.js 版本锁定 r160。现在 Three.js 更新很快，从 r125 开始删掉了旧的 Geometry 体系，全面转向 BufferGeometry。如果你不锁版本，模型可能生成一套旧 API 的代码，报错后你还得帮它猜是不是版本问题，等于把模型的锅背到自己身上。锁死 r160 之后，报错原因就非常集中：要么是模型 API 记错了，要么是实现逻辑有问题。

第二个选择是用npx serve起本地静态服务，而不是直接双击 HTML 文件。很多新手跑 Three.js 项目时会遇到“明明代码没问题，浏览器却全白”的怪事，十有八九是 ES module 的跨域限制。模型生成的代码几乎都会用import * as THREE from 'three'，这种模块化加载在 file:// 协议下是不被 Chrome 允许的。先起一个本地服务，就把这一类环境问题直接排除掉了。

第三个选择是开着 Chrome DevTools 的 Performance 面板记录帧率和加载耗时。评价一个 3D 游戏好不好，不能只看“能跑”，还得看“顺不顺”。我用 Performance 面板录了 30 秒游玩过程，记录 FPS 波动、脚本执行耗时、内存占用这几个指标。这样就能分辨出哪个模型写的游戏是真的优化过，哪个只是“能看不能用”。

2.2 统一提示词：怎么设计才能不坑模型

提示词是这次测试的核心变量，我先把它完整贴出来，再讲为什么这么写。

项目类型：Three.js 网页版 3D 小游戏 技术栈：Three.js r160（通过 CDN 引入）、原生 JavaScript、HTML/CSS 核心玩法：玩家在 3D 场景中收集金币并躲避障碍物 操作方式：WASD 控制角色前后左右移动，空格键跳跃，方向键控制摄像机旋转 场景元素： 1. 地面：绿色草地材质，带网格辅助线 2. 天空：蓝色天空盒或渐变背景 3. 障碍物：至少 5 个随机分布的立方体，颜色为红褐色 4. 金币：至少 10 个随机分布的金色圆柱体，需自动旋转 5. 角色：一个灰色球体或立方体，需要可见的阴影 游戏规则： 1. 30 秒倒计时，结束后弹出成绩结算界面 2. 每收集一个金币加 10 分，显示在左上角 HUD 3. 碰到障碍物会减速并闪红屏 0.5 秒 4. 角色不能走出地面边界，相机不能穿墙 界面要求： 1. 左上角显示分数和倒计时 2. 游戏结束显示“游戏结束，得分：XX” 3. 提供“重新开始”按钮 额外约束： 1. 使用 THREE.BufferGeometry，禁止使用 THREE.Geometry 2. 所有资源使用 CDN 或程序化生成，不要引用本地文件 3. 输出为一个完整的 HTML 文件，包含全部 CSS 和 JavaScript

这份提示词看起来不长，但每个字段都是有目的性的。用“项目类型”开头，是让模型第一眼就知道自己身处哪个领域，避免它在“2D 游戏”“3D 场景”“纯静态页面”之间摇摆。把玩法、操作、场景元素按列表拆开，是为了让模型像对检查单一样逐项实现，减少遗漏。写清 THREE.BufferGeometry 这个约束，是在赌模型可能见过旧代码——结果后来 GLM5.3 真的踩中了这个坑，幸好我提前堵了一部分。

还有一个容易被忽略的点：约束用的是“不要引用本地文件”。这能防止模型顺手生成一张./textures/grass.jpg之类的本地路径图片，导致最后游戏因为找不到文件而加载失败。让所有资源都走程序化生成或 CDN，是保证“零外部依赖可运行”的关键。

2.3 评分维度：不只看“跑不跑得起来”

很多评测把“能运行”当成最大标准，但我觉得对一个 3D 游戏来说，这只是及格线。真正拉开差距的是下面的维度表格。

功能完整度这部分我要特别说明一下。八个小项不是拍脑袋定的，而是我把提示词里的“核心玩法”“场景元素”“游戏规则”三项拆解后得到的可检验指标。比如“金币旋转”和“碰撞检测”是两个独立指标，因为模型可能实现了碰撞却没有旋转，也可能金币会转但碰不到。拆开之后，每个模型的完成情况一目了然，不会出现“好像都做了，又好像没做”的模糊状态。

3. 实操过程与核心环节实现

3.1 DeepSeek V4 Pro：第一轮就稳稳跑通

我先测的是 DeepSeek V4 Pro。提示词发出去之后，它大概思考了 15 秒，然后开始逐段输出代码。整个生成过程持续了大概 50 秒，最终产出一个约 800 行的完整 HTML 文件。我把文件保存到本地，启动 serve，浏览器一开，游戏直接跑了起来，没有任何报错。

说实话，这个结果有点超出我的预期。它的完成度非常高：地面是绿色草地材质，带网格辅助线；金币是旋转的圆柱体，碰上去有“叮”的计分反馈；障碍物分散在场景各处，碰撞后角色减速并闪红屏；左上角分数和倒计时一目了然；倒计时结束后会弹出结算界面和“重新开始”按钮。提示词里列的八项功能，它完成了全部八项，没有遗漏。

代码结构也是三个模型里最传统的——一个大的初始化函数负责场景、相机、渲染器，一系列小函数处理移动、碰撞和 UI。下面这段是它的金币旋转逻辑：

// 金币旋转与拾取检测 function rotateCoins(delta) { coins.forEach(coin => { coin.rotation.y += delta * 2; }); } function checkCoinCollection() { const playerPos = player.position; coins.forEach((coin, index) => { if (coin.userData.collected) return; const dist = playerPos.distanceTo(coin.position); if (dist < 1.5) { coin.userData.collected = true; scene.remove(coin); score += 10; updateHUD(); } }); }

它懂得用userData.collected做标记，避免重复碰撞判定，这个细节很加分。但要挑毛病也能挑：角色碰撞体积偏大，明明视觉上离障碍物还有一段距离，却已经撞上了。我怀疑它没有对角色和障碍物的碰撞箱做精细调整，用的是同一个distance阈值。手感上跳跃高度也偏低，空格按下去角色只离开地面一点点，缺乏“弹跳感”。这些问题不影响运行，但影响游玩体验。

3.2 GLM5.3：生成最快，但第一轮报错

GLM5.3 是三者里生成速度最快的，从发出提示词到完整代码输出只用了约 32 秒。速度确实爽，但爽完之后问题也来了——浏览器一开直接报错，页面白屏。

Console 里的错误信息是这样的：

THREE.Geometry is not a constructor

这是典型的 API 版本错乱。GLM5.3 生成了new THREE.Geometry()这种早就被移除的旧版写法，r160 里根本不存在这个类。我把它报错的信息原封不动贴回对话，要求“使用 BufferGeometry 或 BoxGeometry 重写”，它很快就承认错误并做了修正。第二轮重新运行时，游戏成功进入场景。GLM5.3 修 bug 的态度和速度都不错，总共多花了一轮就搞定。

修正后的视觉效果反而是三个模型里最惊艳的。它自动加了粒子光影效果，场景中漂浮着细小的光尘，还做了日落色调的天空渐变。金币的边缘有反光材质，比另两个模型的纯色圆柱体好看不少。但代价也明显：这些粒子效果导致帧率在部分场景下降到 45 FPS 左右，偶尔能察觉到卡顿。另外它的障碍物碰撞判定比较粗糙，角色走到障碍物侧面时会“卡住”几秒，像是被吸进了一个碰撞死角，只能朝反方向挣脱。

3.3 Step 5 Preview：代码漂亮，但细节有小别扭

Step 5 Preview 是三者里生成最慢的，约 65 秒，但它交给我的代码结构相当工整。函数拆分清晰，每个函数上方都有注释，变量命名有明确的语义。比如playerVelocity、coinRotationSpeed这种名字，一看就懂，不需要猜。我还发现它做了一个另两个模型都没做的设计：把摄像机设置成跟随视角，而不是固定在一个地方俯视全场。

这个设计非常聪明。固定俯视视角虽然实现简单，但玩家在场景里跑动时，会因为视角死角而看不到背后的金币；跟随视角则让玩家始终以角色为中心来观察环境，游戏体验一下子提升一个档次。下面是它实现跟随相机的一段代码：

// 摄像机跟随角色，使用平滑插值避免抖动 function updateCamera() { const followOffset = new THREE.Vector3(0, 8, 10); const targetPos = player.position.clone().add(followOffset); camera.position.lerp(targetPos, 0.05); camera.lookAt(player.position); }

lerp平滑插值这个细节说明它对 3D 游戏有基本的性能概念，知道直接赋值会导致镜头抖动。但 Step 5 Preview 在金币拾取判定上出了点问题：它把每个金币放在一个隐形小圆柱体上，碰撞检测判断的是隐形圆柱体的位置，导致玩家有时候明明碰到了金币模型，却没有计分反馈，得“隔空”再走两步才能拾取。这种小别扭不算致命，但玩起来会有一瞬间的迟疑——我捡到还是没捡到？

3.4 修复环节对比：把报错丢回给模型的效率

整个测试中，我把每个模型第一次报错的信息原封不动回传给它们，观察修复效率。DeepSeek V4 Pro 首轮没报错，所以不需要修复。GLM5.3 报错一次，修一次就通过。Step 5 Preview 首轮报错一次，修一次通过，但金币拾取偏差是小问题，它第二次修正时主动把碰撞半径改成了更合理的数值。

这里我有个明显的感受：模型修复代码的能力，普遍比从零生成代码的能力要强。因为它们面对的是一个具体的报错文本，上下文更聚焦，直接照着错误改就行。这对实际开发的指导意义很大：如果你拿到一个模型生成的代码跑不通，不要犹豫，直接把报错信息复制粘贴回去让模型自己修，比自己去拆解代码高效得多。

4. 对比分析与体验总结

4.1 完成度与稳定性：DeepSeek 赢在下限

先看硬数据。下面的表格记录了三个模型在本次测试中的核心表现。

DeepSeek V4 Pro 最亮眼的不是某一项特别突出，而是它根本不需要修 bug。生成即运行，运行即完整。这种“一次到位”的能力在真实项目里非常珍贵，因为你省掉的不只是修复时间，还有来回对话的沟通成本。如果你只有一个晚上做一个项目 demo，选它最稳。

GLM5.3 的失败项在首轮报错，一个 API 版本问题让第一轮“白做”。但它胜在修复之后功能完整，视觉效果碾压其他两个。Step 5 Preview 则是功能完整度略低一点，金币拾取偏差属于体验细节，不影响整体流程。

4.2 代码质量与可维护性：Step 5 最像正经工程

如果你打算在模型生成的代码基础上做二次开发，代码可维护性比首轮运行成功率更重要。我自己维护过别人写的烂代码，深知那种“能跑但不敢动”的痛苦。

Step 5 Preview 的代码最像正经程序员写出来的工程代码。函数拆分清楚，注释覆盖率高，每个关键操作都有对应的语义化命名。我甚至可以直接在它的代码上面继续加需求，比如加个双人模式，因为角色移动、碰撞检测、UI 更新是分开的函数，改起来不需要动全局逻辑。

DeepSeek V4 Pro 的代码介于“能看”和“工整”之间。它的功能实现完全没问题，但代码整体堆在几个大的函数里，没有 Step 5 那种清晰的模块化意识。如果只是玩一玩，完全够用；想二次开发，需要先花点时间理清它的内部逻辑。

GLM5.3 的代码最随性。变量命名偶尔会冒出el、ex这类含义不明的缩写，函数的职责边界也比较模糊。但它的注释写得挺勤快，关键代码块旁边都有中文注释说明“这里是重力”“这里是碰撞”，对新手反而比较友好。

4.3 运行性能与可玩性：视觉惊艳不等于体验好

性能层面的差异要拆开看。DeepSeek V4 Pro 和 Step 5 Preview 的平均帧率都稳定在 60 FPS，说明它们的基础渲染优化没有大问题。GLM5.3 加了粒子效果之后，在某些镜头角度下帧率掉到 45 FPS，肉眼能感知到轻微掉帧。但话说回来，如果玩家不盯着帧率看，45 FPS 也不是不能玩。

真正拉开差距的是操作手感。DeepSeek V4 Pro 跳跃高度太低，导致过障碍物时总有一种“不太敢跳”的压迫感。GLM5.3 的手感整体顺畅，但侧面碰撞卡住的问题很影响节奏。Step 5 Preview 的跳跃高度和移动速度最接近常规 3D 游戏体验，加上跟随视角带来的更强沉浸感，整体可玩性最高。

加载速度方面，GLM5.3 因为额外引入了粒子纹理资源，首屏 1.8 秒，比其他两个慢了半秒左右。放在小游戏场景下可以接受，但如果做更大型的项目，这部分性能成本需要提前考虑。

4.4 怎么选：没有最好，只有最合适

综合整个测试，我给出的选型建议很简单：

这三个模型并不是互相替代的关系。做游戏 demo 想要稳定省时间，直接选 DeepSeek V4 Pro；想拿游戏截图发朋友圈惊艳一下，GLM5.3 的视觉效果更有优势；要在这个游戏基础上继续加功能、迭代新玩法，Step 5 Preview 的代码结构会让你后续开发更省力。

另外我还想说一个可能很多人没注意到的点：这次测试的背景里，GLM5.3 和 doubao-seed-2.0-code 这类开源模型在社区里已经形成了一波“用大模型做开源安卓 3D 游戏”的热潮。如果你打算把模型生成的游戏打包到安卓端，GLM5.3 的可玩性底子和创意表现会有优势，但代码稳定性上你得多花一点修缮功夫；而 DeepSeek V4 Pro 则更适合做“先稳定再优化”的起点。

5. 常见问题与排查技巧实录

5.1 3D 场景黑屏，只能看到左上角 FPS

这是最典型的问题。我在测试 GLM5.3 时遇到的报错导致白屏，其实是最好排查的一类，因为 Console 里直接给出了错误。但有些黑屏不报错，游戏画面就是一片黑。这时候先看相机：camera.position是不是离场景太近夹在了模型内部？渲染器的setSize有没有监听窗口resize事件？还有一点容易被忽略：requestAnimationFrame(animate)循环是否正常启动。还有 setup 阶段如果renderer.outputColorSpace设置不当，画面也可能整体发黑。

我的排查顺序是：先看 Console 报错，再看相机位置，最后看渲染循环。把这三步走完，九成问题都能定位。

5.2 金币碰撞检测“穿模”，碰得到但捡不到

Step 5 Preview 遇到的拾取偏差就是这类问题。模型生成的碰撞检测有时候会把碰撞体放在一个看不见的子节点上，而不是模型本体上。解决方法是在代码里找到碰撞检测的半径参数，比如dist < 1.5这里的1.5，改成dist < 2.5或者更大，直到手感合适。

另一个常见原因是碰撞计算发生在角色移动之前，导致捡金币的判定总是“晚半拍”。把碰撞检测放在requestAnimationFrame里的render之前执行，问题一般就解决了。

5.3 模型“幻觉”旧版 Three.js API

GLM5.3 的THREE.Geometry报错就是典型的 API 幻觉。模型在训练数据里见过大量旧版本 Three.js 代码，没有意识到自己在用已经废弃的写法。最简单粗暴的预防方式是在提示词里写死版本约束，比如“使用 r160 版本 API，禁用 THREE.Geometry”。

如果已经报错了，不要自己 rewrite，直接把报错信息贴回对话，加上一句“请检查是否为旧版 API，改成 r160+ 语法”。模型在已知报错文本的情况下，改代码的准确率要高很多。实测下来，一次修复通过率大概是 80% 以上。

5.4 生成速度快的模型，翻车率也高

GLM5.3 的生成速度最快，但也是唯一一个首轮报错的模型。这个现象背后其实有点规律：生成速度快往往意味着采样更激进，在保持流畅性的同时牺牲了一些准确性。所以如果你用 GLM5.3 做复杂项目，建议在提示词里补充更多的约束条件，比如“请先列出实现步骤，再写代码”，让模型多一层思考再输出。

Step 5 Preview 恰恰相反，生成了 65 秒才出结果，但结构最好。所以我的个人习惯是：写小 demo 用快模型，写长期维护的项目用慢一点的模型。速度不是第一优先级，稳定性才是最稀缺的。也别迷信“快模型+人肉修复”，如果你要改十个 bug，付出的时间远远超过模型多思考的那三十秒。

整个测下来，我最大的体会是：没有哪个模型是永远的神，只有适不适合当前任务的模型。同一份提示词，DeepSeek V4 Pro 负责稳，GLM5.3 负责炫，Step 5 Preview 负责工整。以后再做这种对比，我一定会先把“报错修复轮次”和“二次开发成本”这两个指标也拉进来，因为这俩才是决定一个 AI 能不能真正帮你干活的关键。另外，如果你准备用自己的需求复跑一遍，我建议把提示词里每条需求都写成可勾选的检查项，这样模型不容易漏，你的评测也更经得起推敲。