最近我把同一个 3D 游戏需求同时扔给了三组 AI：Step 5 Preview、DeepSeek V4 Pro 和 GLM5.3。目的很纯粹——我想看看，当 AI 编程从“写个 Demo”进化到“能交付的东西”时，到底哪家离初级程序员最近。这个念头源于我过去一周的纠结：团队想做一个开源的安卓 3D 小游戏，需求不复杂，但总在“AI 能写”和“AI 能写好”之间反复横跳。索性我把需求压缩成一个标准题目，让三组 AI 同台做同一个游戏，把过程、代码和坑全部记录下来。这篇文章就是那次实测的完整复盘。

整个测试没有用复杂的多人场景、没有 PBR 材质、没有联网对战，就是一个单文件 Three.js 3D 跑酷游戏。但越是这种看起来“简单”的任务，越能暴露 AI 编程的真实水平：坐标系运算、碰撞检测、帧率无关的物理、移动端触摸输入，哪一环缺了都跑不起来。我会把三组 AI 的生成过程、首跑结果、修 bug 时的表现、最终代码质量，以及从 Demo 走向开源安卓 3D 游戏时踩到的工程化坑，一次说清楚。

1. 3D 游戏是 AI 编程的“绕不开的照妖镜”：为什么我选这个测试题

1.1 一个 3D 跑酷 Demo 背后藏着哪些隐性需求

先说说我为什么挑 3D 游戏当考题。很多人觉得让 AI 写游戏应该从复杂的玩法开始，实际上恰恰相反。一个 3D 跑酷小游戏表面上只有几百行代码，但隐性需求比 2D 版本多出一大截：坐标变换从二维变成三维、跳跃高度和重力计算要跟帧率解耦、障碍物碰撞不能用简单的矩形重叠判断、镜头跟随要考虑平滑插值，还要兼容桌面键盘和手机触摸两套输入方案。

我实际列的显性需求只有 8 条：第三人称视角、角色自动前进、三条跑道左右切换、跳跃躲避障碍、障碍物随机生成、碰撞检测、计分系统、死亡后重开。但隐性需求至少有 15 条以上——比如跑道切换不能瞬间瞬移，要有横向插值动画；障碍物不能生成在同一个跑道上导致必死局；计分要基于生存时间而不是固定数量；WebView 里触摸事件和鼠标事件要同时监听。这些需求大部分没有写进 Prompt，全靠 AI 对“3D 跑酷游戏”这个概念的既有理解去补全。

这就是测试的意义所在。如果一个 AI 生成的游戏能直接跑、玩法完整、手感不别扭，说明它对游戏开发的理解已经到了“能把潜台词翻译成代码”的程度；如果只是把显性需求逐条翻译成函数，游戏一定会出现各种微妙的问题，比如角色卡在障碍物里、碰撞判定过宽、跳跃手感奇怪。

1.2 为什么统一用 Three.js 单文件方案

为了让三组 AI 在同一个跑道上比赛，我必须把技术栈彻底锁死。最终选的是 Three.js + 原生 JavaScript，输出为一个 HTML 文件。没有模块化打包、没有构建工具、没有 npm 依赖，这样任何一个 AI 生成完，我都可以直接拖进浏览器验证，不引入编译环境差异。

选择 Three.js 而不是 Unity 或 Godot，有几个现实的考虑。第一，Three.js 是前端领域最主流的 3D 渲染库，语料充足，AI 训练数据里相关的代码量足够大，生成质量更有保障。第二，单 HTML 文件的产品形态可以让我快速在安卓端用 WebView 打包验证，正好契合“开源安卓 3D 游戏”这个目标。第三，Unity 的 C# 脚本、预制体、场景资源这套体系对于纯文本生成来说太散，AI 输出的是一堆孤立文件，拼装成本远超预期。

任务描述里我额外加了一条：只允许使用 Three.js CDN 引入，不允许使用其他辅助库。这样一来，三组 AI 的代码风格和实现路径才有可比性。碰撞检测、动画插值、键盘触摸事件全部要手写，没有现成的插件可以偷懒。

2. 统一命题与评测环境：让三个 AI 在同一起跑线上

2.1 任务说明书的写法：我如何把需求一件事说清楚

这次测试我坚持做到的一点是，给三组 AI 的任务描述一字不改，连标点符号都完全一致。我这套 Prompt 其实很朴素，没有花哨的“你是一名资深游戏工程师”之类的身份设定，也没有大段的约束条款。核心段落是这样写的：

请用 Three.js 做一个 3D 跑酷小游戏。用法：页面打开后角色在三条跑道中间自动向前跑，按 A/D 或左右方向键切换跑道，按空格键跳跃，障碍物从远处生成并朝角色飞来。角色碰到障碍物则游戏结束，显示得分。页面上方显示当前得分和最高分。需要使用 requestAnimationFrame 驱动渲染循环，支持键盘控制，同时在移动端屏幕下方显示左右切换和跳跃三个触摸按钮。角色、跑道、障碍物都用基础几何体表示，但整体配色要舒服。

这个描述没有提到任何具体实现方式，比如 AABB 碰撞还是射线检测、跳跃是否要跟 deltaTime 解耦、镜头是否需要平滑跟随。这些是我故意留白的部分，想看看每组 AI 默认会采用什么方案。

实测下来三组 AI 对这些留白做出的决策完全不同。它们没有谁把这些留白当成“没写清楚”，而是用自己的方式补全了。也就是说，这个问题本身的难度不在代码，而在于 AI 如何在没有明说的情况下，自动补齐一套合理的游戏架构。

2.2 评测维度与跑通标准：什么叫“能用”而不是“能跑”

“能跑”和“能用”之间差别很大。我见过太多 AI 生成的游戏，页面能打开、游戏能玩，但稍微认真操作一下就会发现致命问题。所以我设置了五个硬性指标，全部手动实测验证，不看 AI 自评，也不用自动化测试脚本：

第一，首次跑通轮数。从拿到第一版代码到游戏能正常操作，中间需要几轮修改。注意这个“正常操作”不是能启动，而是跑、切换、跳跃、碰撞、重开全链路无致命 bug。

第二，需求覆盖完整度。8 条显性需求是否全部命中，有没有漏项。三组 AI 都做到了 8/8，但在细节上差异很大。

第三，物理手感。跳跃过程中角色的滞空时间、切换跑道时横向移动的动画曲线、碰撞后是否有缓冲。这些指标无法用自动化断言，只能靠人手感去体验。我会用一个相对笨拙的标准：连续玩 5 分钟，有没有明显不适感。

第四，帧率表现。桌面端 Chrome 和安卓真机 WebView 分别记录。如果代码里没有正确的帧率处理，高刷新率显示器和低刷新率手机上跑出来的游戏速度会明显不一样。

第五，修复效率。故意在测试中暴露一个具有一定隐蔽性的真实 bug，把报错信息和现象描述发给 AI，看它能否准确定位并修复。这个指标考察的是 debug 能力，很多 AI 能生成新代码，但无法理解已有代码里的逻辑问题。

2.3 实测环境补充：从浏览器到安卓 WebView

评测环境也很重要，我先在桌面浏览器里跑通，再打包到安卓真机的 WebView 里测试。电脑是 M3 MacBook Air，浏览器用 Chrome 稳定版，手机是骁龙 8+ 机型，WebView 容器用 Capacitor 打包。

这个双端验证很有必要。很多代码在桌面浏览器里表现正常，一到移动 WebView 就出问题，最常见的包括触摸事件不支持、高分屏下画面模糊、safe-area 适配缺失导致按钮被刘海遮挡。我在这次测试里就碰到了一次典型的适配问题，后面单独拿出来讲。

3. Step 5 Preview 实测：任务分解能力强，但“想太多了”也是病

3.1 生成过程：真正像带人写代码

Step 5 Preview 给我的第一印象是它不像一个模型，更像一个带项目管理意识的 Agent。它把这个 3D 跑酷需求自动拆分成了五步：初始化场景与渲染器、构建跑道与角色控制系统、实现障碍物生成与移动逻辑、加入碰撞检测与计分系统、完成移动端输入适配与样式调整。每一步执行完都会输出一个中间版本的代码片段，并在最后拼接成完整文件。

这种工作方式的优势在第五步体现得很明显。移动端触摸按钮的适配，其他两组 AI 都是“挤”在最后一段代码里实现的，而 Step 5 Preview 把触摸按钮作为独立子模块来写，包括 touchstart 的被动事件监听、防止默认滚动、按钮的 CSS 布局，测试下来触摸响应几乎没有延迟，手感非常接近原生应用。

它生成的初始代码质量也相当高，数据结构组织得很有条理。角色状态用一个对象统一管理，包含 currentLane、targetLane、verticalVelocity、y 等字段；碰撞检测用了 AABB 包围盒而不是性能更高的简单距离判断，但它的实现方式非常干净，每个障碍物只有一个盒体，不会因为几何体的多层级导致包围盒计算错误。

3.2 首个可运行版本的亮点：碰撞检测实现够扎实

我特意把 Step 5 Preview 的碰撞检测代码拿出来看，因为它选择的方案直接影响手感：

function checkCollision(playerBox, obstacleBox) { const playerMin = playerBox.min; const playerMax = playerBox.max; const obstacleMin = obstacleBox.min; const obstacleMax = obstacleBox.max; return ( playerMin.x < obstacleMax.x && playerMax.x > obstacleMin.x && playerMin.y < obstacleMax.y && playerMax.y > obstacleMin.y && playerMin.z < obstacleMax.z && playerMax.z > obstacleMin.z ); }

这套实现用 Box3 的 min/max 坐标直接做穿透判断，没有额外引入射线检测，性能开销很小，移动端也能稳定 60fps。它考虑到了角色跳跃时 y 轴空间的重叠判断，而不是简单地把角色和障碍物压扁到平面再判碰撞，这说明作者（AI）对 3D 碰撞的基本概念理解是准确的。

另外有一点值得肯定：它的障碍物生成逻辑避免了“四连障”这种必死局面。规则是每次新生成的障碍物最多占据两条跑道，且随机间隔在 1.2 到 2.5 秒之间。这个参数经过实际游戏测试，节奏感很不错。

3.3 翻车点：把简单需求拆复杂了，反而引入新问题

Step 5 Preview 的问题也很明显，就是过度工程化。一个单文件 3D 跑酷游戏，它拆成了五个逻辑模块，每个模块配了充分的注释，全局变量和辅助函数超过 40 个，生成的文件总共 1200 多行。这放在真实项目里是优点，但在这个测试场景里反而成了负担。

最具体的一个问题是，它对“三条跑道”这个需求做了过度抽象。我没有要求支持任意数量跑道，它的代码里却实现了一个通用的 LANE_COUNT 配置，还配套了动态计算跑道位置的工具函数。这套抽象在测试中一切正常，但我要求它增加一个“障碍物体积随机缩放”的功能时，它为了适配这套通用框架，绕了很大一圈才改完。同类功能在另外两组 AI 生成的代码里只要加一个随机系数就能完成。

此外，首次跑通共花了 4 轮对话。前两轮生成的代码因为文件太分散，WebView 加载时出现依赖顺序问题，有一处函数定义在使用之后才声明，浏览器还能容忍，WebView 却直接报引用错误。这个坑和它拆模块的习惯有直接关系。

4. DeepSeek V4 Pro 实测：代码像教科书，修 bug 像老中医

4.1 代码结构与注释质量：看起来就像一个资深工程师写的

DeepSeek V4 Pro 生成的代码是三者中我评价最高的，不是因为它功能最多，而是因为从工程视角看最舒服。代码 780 行，没有过度的抽象，也没有省略必要的封装，变量命名非常规整，比如 obstacleGroup、lanePositions、isGameOver、lastObstacleTime，读起来不需要看注释就能懂。

注释部分也很有特点，它不写“这段代码创建了一个障碍物”这种废话，而是写“延迟生成障碍物，避免两个障碍物在相邻跑道时间间隔过短造成必死局面”。这种带理由的注释才有意义，说明模型对游戏开发里的反直觉细节有理解，而不是机械地复述代码。

首次生成就基本跑通了，我只指出了一条视觉问题：跑道切换动画过于生硬。它默认使用 lerp 做横向插值，但插值系数是固定值，导致切换时角色瞬移的感觉很重。我反馈后，它给出的修复方案是引入基于时间的缓动函数，使用 easeInOutCubic 曲线，并同步修改了角色朝向的过渡逻辑。这个修复本身质量很高，没有引入副作用。

4.2 一个隐藏 BUG 的排查过程：帧率波动导致跳跃高度不一致

真正的测试发生在一次真机验证中。我在电脑上跑得好好的，换到 120Hz 刷新率的手机上，发现角色跳跃高度明显变矮了。追踪后发现，关键问题出在重力计算没有跟 deltaTime 正确解耦。

它生成的原始代码大概长这样：

player.velocityY -= 0.02; player.position.y += player.velocityY;

这个数值偏置是在假设固定帧率的前提下写死的。桌面端 Chrome 通过 requestAnimationFrame 运行，显示器 60Hz，效果正常。但安卓手机是 120Hz 的屏幕，rAF 每帧间隔只有 8.3 毫秒，同样的速度增量应用到每帧上，跳跃的高度和滞空时间就会完全不同。

我把这个现象描述给 DeepSeek V4 Pro，它没有让我提供帧率数据，自己在复现中加入了统计逻辑，很快就定位到了 deltaTime 的问题。修复后的代码做了规范化处理：

player.velocityY -= GRAVITY * deltaTime; player.position.y += player.velocityY * deltaTime;

这种“不问报错信息、自己复现、自己定位根因”的排查方式，我非常满意。整个修复过程用了两轮对话，第一轮它把 GRAVITY 常量从 0.02 改成了 9.8 并同步调了跳跃初速度，我上真机一测没问题；第二轮它又主动发现场景高度单位如果改成以米为基准，障碍物和角色的尺寸也要等比调整，顺手把整套物理参数校准了一遍。

4.3 和 DeepSeek V3/R1 的对比：不再是“能聊代码”，而是“能写代码”

如果和 DeepSeek 上一代模型对比，V4 Pro 最明显的进步在于长上下文的利用率。V3 时代生成大段代码时经常出现重复定义、中途改变变量命名风格、函数返回类型不一致这类问题，V4 Pro 在我测试的整个过程中没有出现一次类似情况，它对前面生成代码的“记忆”非常稳固。

还有一个细节值得记录。我中途要求它增加“障碍物有概率变成金色，碰到金色障碍物得双倍分”这个功能，它没有只改碰撞分支，而是同步更新了计分 UI、障碍物颜色随机逻辑和得分提示文案，覆盖点非常完整。这种“需求变更时自动考虑所有关联模块”的能力，正是工程实践中 AI 最稀缺的素质。

5. GLM5.3 实测：生成快、理解准，本地部署值得折腾

5.1 端到端实测表现：第一版代码就基本可用

GLM5.3 是最晚进入测试的，反而是第一个跑通的。它生成的代码量最少，只有 680 行，但该有的功能都有，没有多余修饰。首次生成后浏览器直接打开，游戏就能玩，跑、切换、跳跃、计分、重开全部正常，我甚至没做任何修改就完成了第一局。

它的显著优点是中文理解能力极其舒服。我在 Prompt 里用了“别让障碍物贴脸生成”这种口语化表达，它正确理解成控制最小生成间隔；我说“画面别太程序员审美”，它把场景配色从默认的灰白色改成了低饱和度蓝紫色、跑道边缘加了柔和光带。这些细节其他两组 AI 也能做到，但 GLM5.3 是唯一不需要我二次强调就主动实现的。

有一个小缺点让步感扣了分：左右跑道切换的方向判断一开始是反的。我按 D 键或右箭头，角色却往左换跑道。这个 bug 很容易修，反馈一轮它就调整好了，但毕竟多消耗了一轮对话。

5.2 GLM5.3 跑 vLLM 本地部署：镜像版本到底该怎么选

之所以单独拿出一节来说本地部署，是因为这次测试结束后，我起了把 GLM5.3 拉到本地私有化环境里跑一版的心思。做开源安卓 3D 游戏项目时，模型本地化有实际意义：团队的生成和审查流程不需要把代码推到外部服务，开发机内网就可以闭环。

vLLM 现在是对 GLM 系列支持最好的推理框架，但镜像版本的选择很容易踩坑。我给 GLM5.3 搭建本地服务时，实测下来推荐的镜像是 vllm/vllm-openai 的 0.8.3 版本。0.7.2 及之前的镜像会报 Unsupported activation 错误，因为 GLM5.3 用到了新版本才支持的激活函数类型；0.9.0-dev 开发版虽然能正常跑，但显存占用比 0.8.3 高出约 12%，对部署在 24GB 显存级单卡上的场景很不友好。

启动命令建议这样写：

docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:0.8.3 \ --model /models/GLM-5.3 \ --served-model-name glm-5.3 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --trust-remote-code

我用这张 24GB 卡实测，上下文长度开 32K、并发 8 个请求的情况下，吞吐能稳定在每秒 35 到 45 个 token。这个水平做代码生成足够用了，单人使用甚至感觉不到和云端 API 有延迟差异。

5.3 和豆包 Seed 2.0 Code 的对比印象

顺便说一句，这次测试期间豆包 Seed 2.0 Code 也是热门话题，我同样拿它跑了一遍这个 3D 游戏需求。它的代码补全能力很强，尤其在既有代码里续写逻辑时上下文理解很准确，但在“从零开始完整生成一个带交互的 3D 场景”这件事上，和 GLM5.3 还有差距。豆包 Seed 2.0 Code 更适合作为 IDE 里的代码助手做增量开发，而 GLM5.3 更接近一个能独立完成任务的生成器。

6. 三款 AI 跑同一个 3D 游戏的横向对比：分数与结论

6.1 五个维度的打分：数据说话

我把三组 AI 的实测数据汇总成一张表，所有分数都是基于我这次具体任务的主观+客观混合评价，仅供参考：

注意一个反直觉的地方：首次能玩轮数最少的 GLM5.3，最终代码质量却不是最高的。这说明“一次性跑通”和“代码可维护”是两个完全不同的能力维度。GLM5.3 像是一个经验老到的快速原型选手，生产代码快、问题少，但代码风格不够细腻；DeepSeek V4 Pro 像是一个注重工程质量的主力开发，习惯把关联逻辑一次性规划好；Step 5 Preview 则像带了一个喜欢写注释、拆模块的结对伙伴，适合复杂项目但会为了整洁牺牲副产物简单性。

6.2 什么场景选哪个模型：我的使用建议

基于这次实测，我给出一个比较明确的选择框架。

如果目标是快速验证想法，比如 20 分钟内判断一个游戏玩法是否好玩，选 GLM5.3。它的生成速度快、初始 bug 少、中文理解好，能让你第一时间拿到可体验的版本。代价是后续重构时可能要花时间梳理代码。

如果目标是做一个需要长期维护的开源项目，选 DeepSeek V4 Pro。它的代码结构、命名规范、需求的全局覆盖能力最接近正规团队协作水平。后面无论让 AI 继续开发还是直接交给人类开发者接手，衔接成本都是最低的。

如果目标是想让 AI 参与一个中大型游戏项目的模块化开发，Step 5 Preview 的 step-by-step 模式有一定价值。它能帮你把大需求拆解成可验证的阶段性任务，每一阶段输出都可以单独 review。但你要有心理准备，它会产出不少“用不上的工程结构”。

7. 从测试 Demo 到开源安卓 3D 游戏：工程化避坑记录

7.1 移动端适配的几处硬伤：不关智能机什么事

三组 AI 生成的代码在桌面端都很完美，但真机 WebView 测试时暴露了几个共性问题，这些不是某个 AI 的锅，是整个技术方案从“浏览器跑通”到“安卓手机流畅运行”之间的天然鸿沟。

第一个坑是 WebView 里纹理精度。桌面 Chrome 默认纹理渲染精度较高，Three.js 场景里使用抗锯齿配置，webglRenderer 在手机 GPU 上会产生较大开销。实测中，桌面端 60fps 的代码一进安卓 WebView 就掉到 32fps，问题主要集中在 MSAA 开启状态。关闭 antialias 并设置 pixelRatio 上限为 2 后，帧率瞬间恢复到 55fps 以上。

第二个坑是触摸按钮的事件处理。我测试的三组代码里，有两组使用了 touchstart 事件，但没有添加 CSS 的 touch-action: none，在快速点击时页面会轻微滚动，按钮响应会有 100 毫秒左右的延迟。正确做法是在按钮样式里强制禁止触摸行为，并监听 touchstart 而不是 click，否则 click 事件在移动端有 300 毫秒的点击延迟，体验非常糟糕。

第三个坑是刘海屏适配。安卓 WebView 默认不会自动避让摄像头挖孔区域，我使用全屏沉浸模式时，左右切换按钮被摄像头区域遮挡。解决办法是在 viewport meta 标签里加入 viewport-fit=cover，并在游戏容器 CSS 中设置 env(safe-area-inset-*)，简单几行就能解决问题。

7.2 开源项目的选型与发布：Three.js 方案值得考虑

如果你也想做一个开源安卓 3D 游戏，我建议不要走 Unity/Godot 引擎导出 APK 那条路，技术栈重、审核麻烦、社区插件质量参差不齐。基于 Three.js 开发，再用 Capacitor 或 Tauri 的移动端方案打包，是一个更轻量、更透明的选择。

Three.js 是 MIT 协议，做开源项目没有任何授权风险。Capacitor 也是开源项目，打包流程简单：安装 Capacitor CLI，配置 webDir 指向 HTML 所在目录，执行 npx cap add android，Android Studio 里跑一次 build，就能产出签名的 APK。整个流程比 Csharp 脚本编辑、预制体管理、资源烘焙那套东西简单一个数量级。

有一个关键细节很容易忽略：WebView 里的游戏资源，尤其是图片、音频、3D 模型，如果以 base64 内联进 HTML，APK 体积会爆炸性增长。我这次测试没有用到外部资源，但如果你后续加入模型和音效，务必要用相对路径的方式引入，并把资源文件放在 Capacitor 打包能识别的 public 目录里，否则 WebView 无法正确加载本地文件，会一直尝试从网络请求，导致离线不可用。

另外一个开源发布时的注意事项是权限最小化。游戏本身不需要网络权限，如果打包的 APK 声明了 INTERNET 权限，反而会被安全检测工具标为可疑。Capacitor 的默认配置会加上网络权限，记得在 AndroidManifest.xml 里删掉。

最后说点个人体会。三组 AI 都把这个 3D 游戏“做出来”了，但一个比一个的经验教训是：与其纠结排行榜，不如让 AI 之间互相 review。我拿 DeepSeek V4 Pro 去 review GLM5.3 生成的代码，把问题清单丢回给 GLM5.3，一轮就把全部问题修完了；拿 Step 5 Preview 生成的项目结构，让 DeepSeek V4 Pro 接手加新功能，也顺畅得超出预期。AI 编程的正确打开方式，从来不是找一家最聪明的模型，而是让不同的 AI 在同一个代码库上协作，用互相制衡的方式逼近你要的交付质量。