1. 用3D游戏当考题：为什么不拿LeetCode当尺子

1.1 一个浏览器3D小游戏能测出模型多少东西

做AI编程模型实测，最怕的就是选错题。之前圈里很多人拿算法题、SQL题、正则题去测模型，测来测去发现分数都差不多，一放到真实项目里就露馅。原因很简单：算法题是"单点能力测试"，而真实开发是多文件、多状态、多系统协作的复杂任务。

所以我这次专门挑了"从零写一个浏览器3D收集游戏"当统一考卷，让Step 5 Preview、DeepSeek V4 Pro、GLM5.3三个模型各自独立完成。选3D游戏不是因为它炫，而是因为它天然覆盖了写业务代码时最容易翻车的几类能力：

• 三维数学：坐标系统、向量、矩阵变换、射线检测，差一个符号游戏就黑屏；
• 渲染管线理解：场景、相机、光源、材质、动画帧循环，必须知道谁是初始化、谁在update里被调用；
• 交互与状态管理：键盘事件、指针锁定、计分、胜负条件、游戏循环的暂停与恢复；
• 资源与工程化：模型加载、贴图路径、构建配置、事件兼容性。

也就是说，这一个小游戏同时考察了模型对数学的理解、对游戏框架的熟悉程度、代码组织能力和排查运行错误的能力。换个说法：如果模型连这个都写不利索，那让它去写一整个后台管理系统的把握也不会大到哪里去。

顺便说一句，这个选题特别适合那些一边用AI写代码、一边心里没底的开发者。你不需要有3D基础，跟着这篇文章看完三个模型的第一版代码长什么样、哪里能跑哪里翻车，基本就能判断出哪个工具更值得用在你自己的项目里。

1.2 固定考卷：同一个需求，同一个验收标准

为了让对比公平，我给三个模型完全一致的需求描述，不换措辞、不加额外提示。游戏需求定成这样：

• 游戏类型：第一人称3D收集游戏，浏览器运行；
• 操作方式：WASD移动，鼠标控制视角，支持Pointer Lock鼠标锁定；
• 场景：随机生成的围墙迷宫，地面、墙壁有明显材质区分；
• 金币：场景中随机分布至少20个金币，玩家靠近后自动拾取并播放反馈；
• UI：左上角实时显示已收集金币数量和用时；
• 胜负：金币全部收集完后弹出胜利提示，显示总用时；
• 技术栈：Three.js + Vite + 原生JavaScript，不用额外游戏引擎。

验收标准也写进提示词里：npm install和npm run dev一条命令能启动，浏览器控制台无报错，刷新后地图随机变化，金币不生成在墙体内部。

我特地要求"金币不生成在墙体内部"这一条，因为这是3D游戏里最常见的逻辑漏洞，测的就是模型对空间关系的理解。很多模型生成的随机位置代码只考虑了2D平面范围，完全没判断位置是否落在障碍物内部。

评分维度固定四个：

这些都是我在实际测试里会逐一记录的硬指标，不靠个人喜好打分。

2. 同一条起跑线：提示词、部署方式与硬件环境

2.1 把需求写成一份"甲方需求文档"

给AI模型写提示词，最忌讳的就是一句"帮我写个游戏"就交差。模型不知道你心里想的"游戏"长什么样，它只能给你它最熟悉的模板产物。所以我这次把提示词写成了简短但明确的PRD，核心结构是：项目类型、核心功能列表、技术约束、验收标准。

我当时用的提示词模板是这样的（中文版）：

请用 Three.js + Vite 和原生 JavaScript 实现一个浏览器端第一人称3D收集游戏。 功能要求： 1. WASD 控制移动，鼠标控制视角，点击画布后启用 Pointer Lock； 2. 地图为随机生成的围墙迷宫，地面和墙壁需有不同颜色或材质区分； 3. 场景中随机分布至少 20 个金币，金币不能生成在墙壁内部； 4. 玩家靠近金币自动拾取，并播放简单拾取反馈； 5. 左上角显示已收集金币数量和游戏用时； 6. 所有金币收集完成后弹出胜利提示窗，显示总用时。 技术约束： - 不引入除 three 以外的游戏引擎； - 使用原生 JavaScript，不用 TypeScript； - 所有代码放在 src 目录下，入口文件为 main.js。 验收标准： - 执行 npm install 后，npm run dev 可正常启动； - 浏览器控制台无报错； - 每次刷新地图随机变化； - 金币不会初始生成在墙壁内部。

这一段提示词有两处是决定成败的：一是"金币不能生成在墙壁内部"这种负向约束，模型在生成时才会主动写空间碰撞判断；二是"验收标准"提前给出了可执行的检查命令，模型就会倾向于生成一个完整可启动的工程，而不是随手丢一堆互相没有引用关系的文件。

如果你问为什么不用英文提示词，我的体会是这类国产模型的中文理解已经足够好，中文需求反而能让它们在命名和注释上更贴合中文项目习惯。英文模型在某些框架细节上可能表现更好，但从实际测试来看差距很小，真正拉开差距的还是提示词里有没有写清验收边界。

2.2 模型接入方式：一个API、一个本地跑，一个混合模式

三个模型的接入方式差别很大，这本身也是实测的一部分。

Step 5 Preview 走的是官方API。响应速度快，代码生成基本在几十秒内完成。它背后的多模态推理在生成长代码时比较稳，给我的感受是上下文越长越不容易"忘事"，但这也得看实际测试结果，不能光看宣传。

DeepSeek V4 Pro 我用的是API方式。这个模型的中文对话手感好，解释问题时会主动给类比，但写代码的时候更"克制"——它不会主动加很多花哨功能，基本上需求里写什么就生成什么，这对横向对比来说反而是好事，至少不会被它自作主张的功能干扰评分。

GLM5.3 则是本地部署跑起来的。之所以本地部署，是因为我想一起验证一个社区里大家都很关心的问题：GLM5.3 用什么版本的 vLLM 镜像推理最稳。我这边的结论是，如果你要用 vLLM 跑 GLM5.3，不要图省事用老版本镜像，至少选 0.8.6.post1 以上的官方镜像。我自己先后试过 0.7.x 和 0.8.x，0.7.x 会在某些新算子上报"unsupported operation"，换成新版本之后问题消失。0.9.x 我也试过，能跑，但综合稳定性不如 0.8.6.post1 系列。这个结论对同样玩本地部署的朋友应该能省不少时间。

顺带提一句，网上常有人拿 doubao-seed-2.0-code 和 glm5.3 放在一起说本地部署的事，我测下来这两个模型的vLLM镜像选择思路接近，都是越新越稳，但如果你同时跑其他模型，注意镜像之间不要互相覆盖依赖。

2.3 固定硬件配置和运行环境

测试机器是一台双卡工作站，具体配置如下：

• CPU：Intel i9-13900K
• 显卡：NVIDIA RTX 4090 24GB（跑GLM5.3时单卡够用）
• 内存：64GB DDR5
• 系统：Ubuntu 22.04
• 浏览器：Chrome 最新稳定版
• Node.js：20 LTS

GLM5.3 在 24GB 显存下可以跑 INT8 量化，生成速度中等偏上，长代码输出时明显不如API服务快，但胜在完全离线、数据不出本机。三个模型的测试时间都控制在同一个下午，避免网络波动、服务负载带来的偏差。

3. 同题实战：三份第一版答卷，三种不同的"性格"

3.1 Step 5 Preview：第一版就跑起来了，但金币长在了墙里

Step 5 Preview 的代码生成速度是三家里最快的。第一版就把项目结构拆得很清楚，src/main.js、src/game/scene.js、src/game/player.js、src/game/maze.js，模块命名一看就是有经验的工程习惯。相机初始化、PointerLockControls 接入、材质颜色这些常规部分全部一次写对。

第一版运行后，游戏能启动，能走，能跳（虽然提示词没要求跳跃，它仍然加了空格跳跃），透视和鼠标转向都没问题。控制台干净，没有任何报错。说实话第一眼印象非常好，因为它生成的迷宫不是简单的网格，而是带墙体厚度的真正迷宫结构。

但问题出在金币生成逻辑上。它虽然做了"金币位置不与墙体相交"的判断，但用的方式是"首先生成金币，然后检测是否在墙内，如果不在就留下"。这本身没问题，问题在于它检测金币是否在墙内时，只判断了金币中心点是否落在墙体长方体内部，而金币本身是半径不小的圆柱体，有一部分嵌进墙里时中心点仍然在墙外，于是出现了金币半截嵌在墙里的情况。开局一眼望去，墙边和拐角处全是"长"出来的金币。

这一轮我判定为"第一版能跑但达不到验收标准"，给它记了一轮返工。修复指令只需要一句话："金币位置必须加上半径偏移，确保金币整体与墙体距离大于金币半径。"它立刻理解了问题，给出了基于AABB距离检测的修复代码，第二次运行就完全正常了。

3.2 DeepSeek V4 Pro：代码最像人写的，但碰撞检测翻了车

DeepSeek V4 Pro 给我的第一感觉是：代码可读性极高。变量命名、注释风格都非常接近一个熟手工程师的手笔。同样一个迷宫生成算法，它写得比Step 5 Preview还要简洁，用了并查集来做随机迷宫生成，注释里还解释了为什么选这个算法而不是深度优先搜索。对于想通过AI代码学点东西的开发者来说，这种风格很友好。

但它也有自己的问题，而且是一个特别典型的"看着对、实际不对"的问题：碰撞检测用了Sphere（球体）来近似玩家与墙壁的碰撞。墙壁是长方体，球体碰撞在面朝墙正面的时候表现还行，但玩家斜着贴墙走、或者走到墙角附近时，角色会明显穿进墙里，视觉上就是半个身子陷在墙内还能继续走。原因很简单：球体包围盒在长条形的墙壁拐角处覆盖不了真实边缘，碰撞响应算出来的是"近似距离"，而不是真正的最近距离。

第一版能跑，但穿模严重。我要求它修复后，它给出的第二版换成了AABB激光检测方案，用射线扫过玩家移动向量来判断是否撞墙，穿模问题解决了，但引入了一个新问题：靠近墙角时鼠标视角会轻微抖动，因为这个方法在墙角附近会同时检测到两面墙的碰撞，产生方向冲突。又花了一轮把锐利角判断加进去，才算达到可玩状态。

所以DeepSeek V4 Pro在这一题上记了两轮返工。它的代码风格和解释能力让我很想给它加分，但现实就是：它在空间几何这种需要"具体算准"的地方，反而不如它自己写业务逻辑时那么稳。

3.3 GLM5.3：数学功底扎实，但工程细节要靠人盯着

GLM5.3 本地部署的响应速度明显比前两个API服务慢，但代码质量并不差。它在三维数学上的表现尤其突出：向量计算、玩家移动时的方向归一化、相机与移动方向的一致性处理，都很准确。比如它生成的移动代码里，把"前进方向"先投影到水平面再归一化，避免了从高处下落时速度异常这种细节问题，这一点另外两个模型的第一版都没注意到。

但它有两个真实的工程问题。第一，第一版完全没有考虑移动端触屏。需求里没有明确说"要支持触屏"，它就直接锁定了键盘鼠标方案，连一个"检测到触屏设备时显示虚拟摇杆"的注释都没留。这不是不懂，而是它倾向于严格按字面需求执行的最小实现。第二，资源路径写的是绝对路径/textures/...，本地开发没问题，但把构建产物部署到服务器子目录时会直接404，需要用相对路径或者把asset路径改成环境变量。

这两处问题都不是"能不能跑"层面的，而是"上了生产才知道痛"层面的。考虑到GLM5.3是本地部署、适合做离线和私有化项目，这两个工程细节反而比逻辑错误更需要人工把关。返工轮数记了两轮，第二轮把触屏支持和资源路径问题都解决掉。

4. 横向对比：四个维度看清三家的真实差距

4.1 一次通过率与返工轮数

先把最硬的数据摆在前面：

三个模型第一版都能启动，这符合2025-2026年主流大模型的基准水平。真正的差距在"离可玩还差多远"。Step 5 Preview 的问题是逻辑瑕疵，属于"思路对但差一步"；DeepSeek V4 Pro 的问题是方案选型错误，属于"选了错误的碰撞模型导致几何失效"；GLM5.3 的问题是边界覆盖不全，属于"严格完成任务但没覆盖未明说的场景"。

我建议读到这里不要急着给谁下结论。注意看返工轮数的性质：Step 5 Preview 那一轮修复相当于"改一行判断逻辑"，最简单；DeepSeek V4 Pro 的两轮是真要换实现方案；GLM5.3 的两轮是补功能边界，工作量居中。如果按"单位时间的人力介入成本"来算，Step 5 Preview 最低，DeepSeek V4 Pro 最高。

4.2 代码可读性：谁生成的代码敢直接给同事Review

代码可读性是我个人很看重的维度，因为AI生成的代码最终还是要有人来维护。三个模型在这方面的差异不小：

• Step 5 Preview：模块结构清晰，每个文件职责单一，函数命名直白，冗余代码少。它的代码风格更像"团队规范约束过"的产物，整体上可以直接进代码评审流程。
• DeepSeek V4 Pro：可读性最高，注释详细到接近教程级别，算法选择还会写理由。但对生产项目来说，注释稍显啰嗦，135行的迷宫生成器里注释占了约30%。
• GLM5.3：代码结构合理，但变量命名偶尔偏学术，比如用deltaTimeFactor而不是speedMultiplier，看代码的人只能多花时间猜意图。注释存在但不够体系化。

综合来看，如果团队已经有明确的代码规范，Step 5 Preview 生成的代码最"省事"；如果是个人学习项目，DeepSeek V4 Pro 反而更适合当导师；如果项目不需要频繁Review，GLM5.3 的代码完全够用。

4.3 指令理解与错误修复行为：面对Bug时的三种姿态

这个维度在横向测评里很容易被忽略，但实际开发中非常重要，因为真实项目里模型生成的第一版代码很少能直接用，关键看后续修bug的体验。

Step 5 Preview 修bug时是"定位式"的。它会先指出问题出在哪个文件哪个函数，然后用一段简短代码做局部替换，不会动不相干的部分。对业务影响小，适合merge到已有代码里。

DeepSeek V4 Pro 修bug时偏向"重写式"。当它发现自己原来的方案不对，往往会把整个函数甚至整个文件重写一遍，而不是做最小改动。优点是最终代码整体一致性好，缺点是在已有项目里容易引发意外的diff噪声。

GLM5.3 修bug时爱"反问"。碰到需求中它觉得模糊的地方，会先抛出一个需要你确认的问题，确认之后再动手。这种交互在明确需求时反而有点拖沓，但在需求本身就模糊的真实项目里，这个习惯能省掉后面的来回折腾。

4.4 响应速度、上下文表现与实际使用体验

响应速度方面，Step 5 Preview 和 DeepSeek V4 Pro 通过API调用，首字返回都很快，一次生成完整项目大约需要40-90秒；GLM5.3本地部署，同样的项目生成时间在3分钟左右，但在生成过程中你还能继续干别的事。

上下文表现为我重点关注了"长对话遗忘问题"。三个模型在生成第一版后，我都故意不在第二轮重复需求细节，直接给缺陷反馈。结果差异明显：

• Step 5 Preview 在4-5轮对话后仍然记得金币半径、墙体厚度这些具体参数；
• DeepSeek V4 Pro 到第三轮时已经开始简化需求，比如把"至少20个金币"理解成"适量金币"；
• GLM5.3 的上下文保持中规中矩，前两轮没问题，第三轮开始有轻微偏移。

成本方面，API方案按token计费，两个API模型生成这个游戏的单次成本都在几毛钱人民币级别；本地部署则主要看电费和显卡折旧。对个人开发者来说成本都不算压力。

5. 选型建议：这次实测之后，我会怎么用这三个模型

5.1 什么场景适合Step 5 Preview

经过这轮3D游戏实测，我会把Step 5 Preview当"快速原型机"用。它的优势是生成速度快、模块结构好、修bug能精准定位，特别适合我脑子里有一个模糊想法、需要半小时内看到可运行Demo的情况。比如这次3D游戏，用Step 5 Preview生成第一版再修一轮，20分钟内就能得到一个可玩雏形。

如果你的场景是：需要频繁做需求迭代、代码要进团队评审、希望AI改动尽量小而精准，Step 5 Preview 是三个里最顺手的选择。但也要提醒一句，它的代码虽然结构好，功能扩展时不会主动替你想边界条件，需求描述漏掉的东西它就是不会做，提示词必须要细。

5.2 什么场景选择DeepSeek V4 Pro

DeepSeek V4 Pro 适合当"结对编程老师"。它写的代码注释丰富、命名规范、算法思路解释透彻，生成结果有很强的学习价值。我在项目里如果遇到不熟悉的库或算法，首选用它来生成参考代码，再人工理解后重写。

但这轮的碰撞检测翻车也说明一个问题：它生成的代码"看起来正确"的能力强于"实际验证正确"的能力。所以用DeepSeek V4 Pro写出的代码，尤其是几何计算、物理模拟类逻辑，建议要专门加一轮人工测试，别被它详细的注释迷惑。适合的场景是：中小规模项目、重视代码可维护性、你有时间做验收测试。

5.3 什么场景选择GLM5.3

GLM5.3 最典型的用法是本地部署、离线运行。我在它身上验证了vLLM镜像选择，结论就是选0.8.6.post1以上版本的官方镜像，然后安装依赖时不要和项目里的torch版本冲突。它的数学功底在这轮测试里给我的印象最深，处理向量、变换这类逻辑比其他两个更稳。

适合GLM5.3的场景包括：对数据安全敏感的开发环境、没有外部API可用的小组、以及需要长期运行在固定机器上的自动化编码任务。代价是响应速度不如API快，而且它默认严格按字面需求工作，你要提前把触屏支持、资源相对路径这类工程细节写进提示词里，否则后续要靠人工打补丁。

顺带说一句，我测完这三个模型之后，又用同一份考卷跑了一轮 doubao-seed-2.0-code，它在本地部署方式和GLM5.3类似，结果也接近，但细节就不展开说了。另外这类模型生成的代码逻辑，同样可以直接移植到开源安卓3D游戏里跑，只要把WebGL渲染部分换成对应的原生绑定即可。

5.4 通用避坑清单：三份实测里沉淀的教训

最后把这次实测中值得复用的经验列出来，不限定某个模型，所有用AI写3D游戏或者其他图形项目的人都适用。

第一，提示词里必须写验收标准和负向约束。"至少20个金币"是正向需求，"金币不能生成在墙壁内部"是负向约束。实测下来，两个模型的差异主要不在正向需求完成度上，而在负向约束的落实情况上。不写负向约束，模型大概率会用最简单的方式生成随机位置，然后留下一堆只有能跑但没脑子的bug。

第二，AI生成的碰撞检测和物理逻辑必须人工验证。这次三家模型的碰撞检测各有一个翻车方向：一家是包围盒半径没算，一家是碰撞模型选错，一家是边界条件覆盖不全。图形学代码不像CRUD，错误不会报错，它只会让你看着难受。上线前至少花十分钟走一遍墙角、高速移动、窗口缩放这几个经典用例。

第三，资源定位别信AI的"一次到位"。绝对路径、相对路径、CDN路径，三个模型各有各的处理方式，但都有一个共同点：只在当前环境下正确。只要部署目标变了，路径问题就会冒出来。用AI生成含资源加载的代码时，养成习惯在提示词里写明"所有资源路径使用相对路径，且兼容子目录部署"。

第四，长对话中要警惕需求简化。DeepSeek V4 Pro在第三轮开始丢掉"20个金币"这种数字细节，GLM5.3在第三轮也有轻微偏移，Step 5 Preview坚持得最久但也做不到无限记忆。每轮对话里把关键数字和约束重复一遍，或使用项目内文档做长期记忆，是更稳妥的做法。

第五，不要用同一套提示词去测两家模型就拍板选型。模型各有性格，有的擅长严格按需求执行，有的擅长自驱补全，有的擅长代码风格。把"哪个模型最好"换成"哪个模型最匹配我的工作流"，才是这次实测真正有价值的产出。

我自己的经验是，三个模型在同一道3D游戏题上的表现拉不开那种"能用与不能用"的鸿沟，真正的差异是返工成本和修复体验。Step 5 Preview修起来像改自己的代码，DeepSeek V4 Pro修起来像接手别人的代码，GLM5.3则像跟一个严谨但有点轴的同事结对。你更愿意跟谁一起干活，答案其实在落地项目里，不在排行榜上。