上周终于拿到了 Step 5 Preview 的内测资格。作为长期跟国产大模型写代码能力的人，我第一反应不是拿它去刷 LeetCode，而是做了一个有点狠的测试：和 DeepSeek V4 Pro、GLM5.3 一起，用完全相同的需求，各自独立开发一个 3D 跑酷小游戏。3D 游戏看起来很炫，实际上是对图形学基础、前端工程能力、代码组织能力和 Bug 修复能力的全方位考验，比单纯刷算法题更能看出一款模型的真实水平。这篇文章就把我这几天实测的全过程、三个模型各自的代码风格、一次通过率、修复迭代能力，以及那些踩过之后必须写下来的坑，一次性说清楚。
1. 为什么拿“3D 游戏”当 AI 代码能力的试金石
1.1 3D 游戏最难的地方不在“会写”，在“会组合”
很多人觉得 3D 游戏就是 Three.js 的 API 拼凑，让模型写一段 Demo 也不是什么难事。真实情况远没有这么简单。一个能在浏览器里跑起来的 3D 跑酷游戏，至少要同时处理好六个维度：场景搭建、相机跟随、角色控制、碰撞检测、随机生成器和游戏状态管理。这里面任何一环出问题，游戏都玩不起来。
我在设计测试任务时，刻意剔除了“炫技”成分，不要求后处理特效，不要求物理引擎，只要求一个能玩、有反馈、能重开的小游戏。但即便是这样，模型也必须理解三件事：第一，Three.js 的坐标系统与旋转逻辑；第二，游戏循环中requestAnimationFrame的正确用法；第三，碰撞检测不能每帧遍历所有对象导致性能崩掉。这三个问题靠背 API 是不够的，需要模型真正理解“组合逻辑”。
这也是为什么我最终放弃了“写一个贪吃蛇”“写一个俄罗斯方块”这类题目。二维逻辑题的代码量太短，模型很容易靠记忆生成一段能跑的东西，区分度不够。而 3D 游戏需求足够复杂，能逼着模型把能跑通的代码和能维护的工程区分开。
1.2 测试任务与评分卡设计
为了公平起见，三个模型拿到的是逐字相同的需求。我把它写成了一个完整的中文 Prompt，里面包含了玩法、功能、技术栈和输出要求：
- 使用 Three.js 和原生 JavaScript，输出一个完整可运行的 HTML 文件；
- 第三人称视角，相机跟随角色并保持一定高度与角度；
- 角色自动向前跑动，可通过键盘左右方向键切换三条跑道；
- 障碍物随机生成并从远处朝角色移动，形状至少包含立方体、球体、圆柱三种；
- 场景中随机生成金币，角色碰到金币加分；
- 碰撞到障碍物游戏结束，显示得分，并提供重新开始按钮；
- 使用光照和网格地面营造 3D 氛围，代码模块化，注释清晰。
执行环境统一用 Chrome 浏览器，本地起一个 Vite 静态服务，模型生成的是单个 HTML 文件，里面通过 CDN 引入 Three.js。我不允许模型引入额外的物理引擎或 UI 框架，目的是把变量控制住，只看模型本身对需求的理解和实现能力。
评分卡我设计成了五个维度，满分 100 分：
| 维度 | 分值 | 考察点 |
|---|---|---|
| 需求覆盖度 | 30 | 所有玩法功能是否完整实现 |
| 代码质量 | 20 | 变量命名、模块拆分、注释、可读性 |
| 一次通过率 | 20 | 首轮运行是否有报错、是否可玩 |
| 画面表现 | 15 | 光照、配色、运镜、动画流畅度 |
| 迭代修复能力 | 15 | 给出报错后能否准确定位并修复 |
其中“一次通过率”是很多人忽略但极其重要的指标。编码模型生成的代码，如果第一轮就能直接跑起来，说明它对 API 版本、语言特性和逻辑流程的把握是整体性的；如果第一轮跑不起来，即便后面能修好，也意味着使用者要额外付出调试成本。
2. 三个模型的本尊介绍与测试准备
2.1 Step 5 Preview：内测版需要足够的宽容度
Step 5 Preview 是我这次测试的核心对象。它的命名延续了 Step 系列的迭代节奏，官方给出的定位是通用大模型，主页上放出来的能力重点包括复杂推理、长文本理解和代码生成。我拿到的内测版本通过 API 调用，体验上更像是“推理能力优先”的模型，在数学和逻辑推导上的表现比前代有明显进步。
但实话实说，预览版意味着不能抱太高预期。API 偶尔出现超时，生成的长代码在中间段落偶尔会丢逻辑，这些都是测试中真实遇到的情况。我在使用前给自己定的心态是：重点看它“能不能做到”，而不是“是否完美做到”。毕竟评测的核心价值，是给后面想尝试的人一个心理预期，而不是捧杀任何一个模型。
在实际测试里，Step 5 Preview 给我的感觉像一个“有自己想法的年轻工程师”。它写代码不是循规蹈矩的模板流，而是会在某些地方用出一些不常见但合理的思路，比如用简化球体检测代替复杂的 AABB 碰撞计算，后面我会详细讲。这种偶发的灵光乍现，是标准答案式代码训练不出来的东西，也是我这次测试里最意外的收获之一。
2.2 DeepSeek V4 Pro：代码能力的老牌种子选手
DeepSeek V4 Pro 在这次测试里扮演的是“对照标杆”角色。上一代 DeepSeek V3 在代码生成领域的口碑已经很高，V4 Pro 在架构上做了更新，官方口径强调代码推理能力和长链路的指令遵循能力。我在多个内部小项目里用过它，整体印象是“稳”，但这恰恰是评测里最有价值的参照系。
V4 Pro 对长 Prompt 的指令遵循能力非常强。我给的提示词里有 7 个明确要求，它在首轮代码里 7 个全部覆盖，没有一个遗漏。而且它生成的代码量明显比另外两个模型大，注释密度也最高。如果你是一个想通过 AI 学习 Three.js 源码风格的初学者，V4 Pro 的代码是最好的教材。
它最让我印象深刻的一点是工程意识。它会主动把游戏拆成Game、Player、ObstacleManager、ScoreManager这样的类结构，代码之间的耦合度控制得比较好。当我后续要求扩展功能时，它知道应该在哪个类里面加方法，而不是把整个文件重写一遍。这种“可维护性”在 AI 生成代码里极其稀缺。
2.3 GLM5.3：Flashx 与本地部署是两条路线
GLM5.3 的情况要复杂一些，准确说它不是一个模型，而是一个系列。我在测试里用了两条路线：一是直接调用官方 GLM5.3-Flashx 的 API，速度快、免部署，适合快速验证；二是尝试本地部署 GLM5.3 Flash 权重，用昇腾 910B 的推理环境去跑。两条路线的体验差异非常大，我必须先把这个前提说清楚，否则结论会很误导人。
官方 API 版的 GLM5.3-Flashx 响应速度很快，代码生成的整体质量不输另外两家，风格上更“务实”，不会写太多花哨的封装，代码直接了当。本地部署版则完全是另一个故事，因为 910B 这种国产加速卡跑开源模型需要专门的 vLLM 镜像支持。社区里最常问的问题就是“GLM5.3 使用 vLLM 该用哪个版本的镜像”，这次我实测的关键结论是：默认安装的最新版 vLLM 在加载 GLM5.3 Flash 权重时大概率会报算子不兼容错误，需要使用官方指定的适配镜像版本，具体版本号要以模型仓库发布说明为准。
部署踩坑这件事本身并不奇怪，开源模型在不同硬件上的兼容性一直是老大难。但对于普通开发者，我的建议很直接：如果只是做代码生成测试，直接用 GLM5.3-Flashx 的官方 API，不要在部署上浪费时间；如果你需要私有化部署做代码辅助工具，再认真研究镜像版本和加速卡的算子适配问题。
2.4 测试环境与工程化注意事项
统一测试环境是一个容易被忽略但极其重要的环节。我用的是一台 2023 年的 Windows 笔记本，浏览器是 Chrome 最新稳定版，Node 版本是 20 LTS。三个模型生成的代码我都放进同一个目录里跑，避免因为 CDN 版本不一致导致差异。
这里必须说一个细节：Three.js 的 CDN 引用方式在不同版本之间差异很大。r150 之前和 r150 之后，部分 API 的命名和引入路径都变了。比如THREE.Geometry在旧版本中存在，在最新版本中已经完全移除；灯光、纹理、渲染器的outputEncoding属性也在持续迭代。如果模型生成代码时引用的版本和执行环境不匹配，就会出现莫名其妙的报错。
我给三个模型的提示词里，指定的 CDN 链接是https://unpkg.com/three@0.160.0/build/three.min.js，锁定版本，不允许模型自由发挥。这个做法帮我过滤掉了“版本不一致导致的假性失败”，确保最终的差异主要来自模型本身。
3. 同一道题，三种答案：首轮生成对比
3.1 Step 5 Preview 的首次表现
Step 5 Preview 的首轮代码大概用了 20 多秒生成完毕，总行数约 430 行。代码结构分为createScene、createPlayer、createObstacle、checkCollision、update这几大块，函数命名直接但不算优雅。它没有采用 class 继承那一套，而是用闭包和模块化函数来组织逻辑，整体风格比较轻量。
最特别的设计在碰撞检测部分。它没有用标准的三维 AABB 碰撞盒子，而是把所有物体简化成“圆柱体近似”，用圆心距离和半径之和来判断是否碰撞。这个方案在视觉上略粗糙，但计算量小、代码短，对于金币这种圆形拾取物反而手感更自然。面向”快速出 Demo“的场景，这种取舍我完全能接受。
首轮运行的时候，页面能打开，场景能渲染，角色能动，障碍物也能生成。但有一个明显的 Bug：金币没有出现在正确的跑道上，很多金币浮在半空中或者穿进地面。显然是 Random 生成金币时虽然随机了水平位置，却没有把垂直坐标严格对齐到地面高度。这个小问题不致命，但属于典型的“细节意识”缺失，说明模型在生成代码时对场景坐标系的统一性缺少整体把控。
3.2 DeepSeek V4 Pro 的首次表现
DeepSeek V4 Pro 生成了这次测试中最大的一坨代码，接近 700 行。初看会觉得“有点啰嗦”，但运行起来之后就明白了：多出来的这一两百行，几乎全花在了边界处理上。角色切换跑道时会有平滑的横向移动过渡，障碍物生成时有严格的间隔控制，避免两堵墙叠在一起导致无法躲避。这些细节在需求里都没有写，是模型自己决定的处理方式。
它的首轮运行是我在整个测试中最接近“零报错”的一次。打开页面的瞬间，游戏直接进入可玩状态，角色、跑道、障碍物、金币、计分全部正常。我只发现一个小问题：重开按钮点击后，计分板没有归零，重新开始的分数会叠加到旧分数上。这个 Bug 给了后续迭代测试一个很好的切口。
V4 Pro 在画面表现上也是最完整的。它把跑道做成了三条半透明的光带，还加上了雾化效果和动态背景色，游戏氛围明显好于其他两个模型。虽然它不是追求极致渲染的引擎，但作为 AI 生成的原型，这个画面效果已经能直接拿去做内部演示了。
3.3 GLM5.3 的首次表现
GLM5.3-Flashx 的生成速度是三个模型里最快的，几乎是一点提示词就开始出代码，首轮代码大约 380 行，行数最少，风格非常“省”。它的代码注释只有关键位置有，函数封装也是点到为止。不过需求里的所有功能点，它都实现了，只是实现方式更朴素——比如角色切换跑道时，它是瞬间切换，没有平滑过渡动画。
这带来一个很有意思的问题：用 GLM5.3 写出来的代码效率可能最高，但“手感”和“观感”会差一些。如果你只是需要一个功能正确、逻辑清晰的纯逻辑原型，GLM5.3-Flashx 的表现完全够用；但如果你追求的是一个能拿去展示、能让人立刻产生兴趣的交互 Demo，它还需要在视觉反馈和动效上多做迭代。
首轮运行时的最大问题是“重新开始按钮”。点击后页面直接刷成黑屏，控制台报Cannot read properties of null (reading 'add')。原因是按钮的点击事件里，它直接调用了重新初始化场景的函数，但没有清空旧场景的 DOM 容器引用，导致旧场景对象和新场景对象发生了冲突。这个问题在 GLM5.3 的本地部署版里也存在，说明是模型本身的逻辑短板，不是部署环境的问题。
3.4 三个模型的第一轮代码对比表
为了让大家看得更直观，我把首轮生成的关键信息汇总成表：
| 对比项 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3-Flashx |
|---|---|---|---|
| 代码行数 | 约 430 | 约 700 | 约 380 |
| 生成速度 | 约 30 秒 | 约 40 秒 | 约 15 秒 |
| 首轮可玩性 | 可玩，金币坐标有误 | 可玩，重开计分未归零 | 可玩，重开黑屏 |
| 结构风格 | 模块化函数 | 面向对象 class | 平铺式简写 |
| 画面表现 | 中等 | 优秀 | 中等 |
| 代码注释 | 主要函数有注释 | 全程有注释 | 关键位置注释 |
三个模型的首轮结果都有一个共同点：功能覆盖率都做到了 100%。这说明现在的编码模型在“理解需求并生成可运行原型”这件事上，已经跨越了基本门槛。接下来的差距，全部体现在细节处理和维护成本上。
4. 限时 Debug：谁能在报错面前稳住
4.1 我把同样的三个报错分别喂给模型
首轮跑完之后，我进入第二轮测试：对三个模型生成的代码，我注入同样的三个报错场景，让模型自己修复。这一步是真正的分水岭，因为 AI 生成代码的最大问题从来不是写不出来，而是写出来之后维护笨蛋。
我注入的第一个报错是TypeError: geometry.computeBoundingSphere is not a function，原因是我把最新的 Three.js 版本回退到了 r140，老版本某些几何体 API 行为不一致。第二步是Uncaught ReferenceError: score is not defined，一个作用域引用错误。第三步是THREE.WebGLRenderer is not a constructor，模拟 CDN 引入失败。
结果差异非常明显。DeepSeek V4 Pro 的第一轮修复，三条报错全部定位准确，修复后游戏正常运行，并且它还主动加了一个try...catch包裹渲染器初始化逻辑，防止 CDN 临时加载失败直接白屏。这种“防御性编程”意识，说明它对“错误处理”这件事有一套完整的知识体系。
Step 5 Preview 处理报错的速度也很快，修复准确率是三家里第二高的。它最有意思的做法是，修复完第一条报错后，它没有只改报错那一行，而是顺手把相关的几何体创建逻辑全部改用新版 API 写法，等于把整条链路的兼容性都理顺了。这种“治根”的思路，比单纯“治标”更让我认可。
GLM5.3-Flashx 的表现稍弱一些。它能够定位到报错的位置，但在修复时倾向于“局部打补丁”，比如报错说score is not defined，它就只在事件回调里补一个let score = 0，却没有考虑到这个局部变量与全局计分逻辑冲突。修完之后，报错消失了，但计分重置的行为又出现了新问题。这说明模型在处理“跨作用域状态同步”这类问题时的能力还有短板。
4.2 扩展功能的迭代：计分板、音效、难度曲线
Debug 测试结束后，我又做了一个扩展功能的迭代测试。我向每个模型提出三个新需求：给游戏加入音效反馈；让障碍物的生成速度随着游戏时间逐步变快；在页面上显示一个实时的“最高分”记录，用 localStorage 存储。
这一步测试的是模型的“增量开发”能力。懂工程的人都知道，在已有代码上加功能，往往比从零写代码难得多，因为你必须先理解现有结构，再找到合适的插入点。
DeepSeek V4 Pro 在这个环节依然是完成度最高的。它用AudioContext生成了一段简单的跳跃音效和得分音效，没有依赖外部音频文件，规避了资源加载的问题。难度曲线它做成了一行公式：speed = baseSpeed + elapsedTime * 0.01，简洁清晰。最高分记录它用了标准的localStorage.getItem和setItem，逻辑完整。
Step 5 Preview 的扩展能力接近 V4 Pro，但风格更激进。它把音效做成了可配置对象，甚至留了两个接口给未来接入不同音效源。最高分存储和 V4 Pro 的方案基本一致。比较意外的是，Step 5 Preview 在改代码时把原来的碰撞检测函数重构了一遍，虽然功能没有变化，但代码结构比以前更整洁。这种“顺手优化”对于开发者来说是把双刃剑：优化得好是惊喜，优化不好就引入了新的回归风险。
GLM5.3-Flashx 在这次扩展测试里继续“写最小代码”。它把音效直接做成了console.log的占位输出，理由是“浏览器环境可能不支持自动播放音频”——这个理由技术上成立，但产品层面完全不能接受。难度曲线和最高分它倒是认真实现了，代码虽然短，但逻辑是对的。整体来说，它的扩展能力在“能跑”这个水平线上，距离“好用”还有一段距离。
4.3 移动端适配实测
最后一个实操测试是移动端适配。我把三个模型生成的页面都通过局域网映射到手机上，用 Chrome DevTools 设备模拟器以及真机分别跑了一遍。考虑到很多 3D 游戏原型最终要拿去做分享展示，移动端的表现不能忽视。
DeepSeek V4 Pro 在移动端表现最好。它生成的代码里，Three.js 渲染器的像素比设置用了Math.min(window.devicePixelRatio, 2)，主动限制了高分辨率屏幕的渲染压力。另一个细节是它把控制逻辑同时绑定到键盘和触摸点击事件上，触屏用户可以点击屏幕左侧、右侧来切跑道。
Step 5 Preview 在移动端能跑，但出现了一个性能问题：在低端手机上帧率只有 20 帧左右。原因是它在渲染器初始化时没有设置像素比限制，导致高密度屏幕的渲染压力较大。这个问题属于移动端开发的经典考点，模型知道怎么写，但它默认按桌面场景优化，疏忽了这个参数。
GLM5.3-Flashx 在移动端的表现反而是三个模型里最稳的。它生成的代码量小，绘制调用少，在低端手机上的帧率比 Step 5 Preview 高了将近一倍。但代价是画面精度低，金币和障碍物的模型面数较少，放大看会有明显的锯齿感。如果你是要做 3D 游戏 Demo 的性能下限测试，GLM5.3 的小代码结构反而有优势。
5. 跑分与结论：谁更适合做 3D 游戏原型
5.1 最终评分卡
整个测试下来，我按事先定好的评分卡对三个模型做了打分。我尽量排除主观偏好，每一项都基于实际的运行表现：
| 维度 | Step 5 Preview | DeepSeek V4 Pro | GLM5.3-Flashx | 本地部署 GLM5.3 |
|---|---|---|---|---|
| 需求覆盖度（30） | 28 | 30 | 26 | 26 |
| 代码质量（20） | 17 | 19 | 14 | 14 |
| 一次通过率（20） | 15 | 19 | 17 | 16 |
| 画面表现（15） | 10 | 14 | 9 | 9 |
| 迭代修复能力（15） | 12 | 15 | 9 | 10 |
| 总分 | 82 | 97 | 75 | 75 |
这个结果总体符合我的预期。DeepSeek V4 Pro 是综合实力最强的，尤其是迭代修复能力和代码组织能力，优势非常突出。Step 5 Preview 离可用级只有一步之遥，细节意识和防御性编程还需要打磨，但它那种偶尔冒出来的独特思路，让它成为一个值得持续观察的选手。GLM5.3-Flashx 的定位更适合轻量任务，而它的本地部署版如果要拿来跑这种复杂项目，vLLM 镜像和算子的坑会比代码本身的坑更让人头疼。
5.2 模型选择的个人建议
这次测试之后，我给自己定了三个选型原则。如果你做 AI 辅助开发，可以参考一下。
第一条原则是“按场景选模型，不按名气选模型”。如果你需要在一个大型工程里扩展功能、重构代码，DeepSeek V4 Pro 是首选，它的工程意识能降低维护成本；如果你只是临时需要一个一次性 Demo，GLM5.3-Flashx 的生成速度是优势，反正用完就扔；而如果你有时间反复打磨一个作品，Step 5 Preview 的独特思路可能会给你带来一些意想不到的灵感。
第二条原则是“首轮能跑，远比你想象的重要”。首轮能跑意味着模型的整体逻辑是自洽的，之后的每一次修复都是在补细节。首轮不能跑，意味着你可能需要几轮对话才能把大坑填平，这个时间成本不可小觑。这也是为什么我给了 V4 Pro 最高的通过率分。
第三条原则是“本地部署之前，先确认两件事”。第一件事是你的推理框架版本是否与模型权重兼容，第二件事是你的加速卡算子是否覆盖了模型全部层类型。如果这两件事没有提前查清楚，很可能花半天时间部署，最后还是灰溜溜跑回 API。
6. 三个模型实测之后的避坑清单
6.1 Three.js 项目里的通用坑
这次测试让我把 Three.js 项目的常见坑都踩了一遍，写在这里给大家当参考。
第一个坑是 CDN 版本锁定。做 AI 生成项目的复现时，CDN 版本不锁定等于没有复现环境。我在测试中锁定了 Three.js 0.160.0，但如果你用了 AI 生成的旧代码，很可能它引用的是 r120 甚至更老的版本，API 完全对不上。最简单的做法是让模型在代码里明确写出 CDN 地址和版本号，不要让它用默认的three.min.js这种没有版本标识的链接。
第二个坑是渲染器像素比。移动端性能出现问题，十有八九是这个参数没设置。renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2))这行代码看起来不起眼，却决定着一个页面在手机上会不会掉帧。建议在生成代码的提示词里直接加上这一条硬性要求。
第三个坑是重新开始逻辑。几乎所有 AI 生成的 3D 游戏，第一次点“重新开始”都会出问题。本质原因是模型在初始化场景时没有彻底销毁旧场景的资源。标准做法是在重开函数里先调用renderer.dispose()，然后移除所有场景对象，再重新创建。这个坑我已经在多个模型上见过，属于高频 Bug。
第四个坑是资源加载失败的白屏。AI 生成的代码里面经常会有一些外部资源引用的假设，比如加载外部模型、加载贴图。本地测试时这些资源一旦不存在，整个页面就会卡在加载中。我建议在提示词里明确说“不允许使用外部模型文件，所有模型必须用内置几何体生成”。
6.2 模型使用上的硬经验
除了代码本身的坑，模型使用上也有几条硬经验要分享。
第一条是提示词要像写需求文档一样写。把功能点拆成编号条目，明确禁止使用的技术栈，限定输出格式。我发现这次测试的三个模型，凡是提示词里的“明确禁止项”执行得都很好。比如我说“不允许引入物理引擎”，三个模型都没有用物理引擎。越具体的约束，模型的指令遵循能力越能发挥出来。
第二条是修正需求时必须给足上下文。当你让模型修复 Bug，不要只把报错信息贴过去，最好把报错发生的代码位置、运行环境、已经尝试过的修复方案一并给出。我在 Debug 测试里发现，给了完整上下文的修复请求，模型修复成功率比只贴报错信息高出一大截。这就像你带着完整病历去看医生，医生当然更容易诊断，成功的概率自然不同。
第三条是本地部署要查版本镜像，不要想当然装最新版。这次 GLM5.3 的本地部署测试里，我一开始直接装了最新的 vLLM，加载权重时报了一堆算子错误，查了模型仓库的说明才发现官方推荐的是特定镜像版本。换镜像之后问题基本消失，推理速度也上来了。这个经验放在任何开源模型的私有化部署里都适用：先看官方发布说明，再装环境，顺序不能反。如果你担心这一步麻烦，直接用官方 API 是最省心的方案。
我个人这几天的测试体会是：AI 生成 3D 游戏代码这件事，已经过了“能不能跑”的及格线，真正拉开差距的是“好不好改”和“好不好用”。DeepSeek V4 Pro 用极强的工程意识和稳定的迭代能力证明了自己是现阶段最省心的队友；Step 5 Preview 让我看到了不少灵性，只是还欠点火候；GLM5.3 更像一个高效的工具，给你最短路径，但不负责体验。最后再分享一个小技巧：如果拿 AI 做游戏 Demo，别只让它一次性生成完整代码，多留几轮对话做迭代，把“加音效”“加动效”“加场景效果”这类小需求拆开提问，生成质量会比一次憋一个大需求高出不少。这个习惯我用了很久，屡试不爽。
