最近我把同一个 3D 游戏需求同时扔给了三组 AIStep 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 的实测数据汇总成一张表所有分数都是基于我这次具体任务的主观客观混合评价仅供参考评测维度Step 5 PreviewDeepSeek V4 ProGLM5.3首次能玩所需对话轮数421最终代码行数1200780680显性需求覆盖8/88/87/8触摸按钮功能完整但样式不完整隐性需求覆盖较高较高中等桌面端帧率58fps60fps62fps安卓 WebView 帧率55fps60fps56fps修复 bug 所需轮数222代码可读性中等过度拆分高结构清晰中等略粗糙需求变更适应性低抽象过重高中注意一个反直觉的地方首次能玩轮数最少的 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-fitcover并在游戏容器 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 androidAndroid Studio 里跑一次 build就能产出签名的 APK。整个流程比 Csharp 脚本编辑、预制体管理、资源烘焙那套东西简单一个数量级。有一个关键细节很容易忽略WebView 里的游戏资源尤其是图片、音频、3D 模型如果以 base64 内联进 HTMLAPK 体积会爆炸性增长。我这次测试没有用到外部资源但如果你后续加入模型和音效务必要用相对路径的方式引入并把资源文件放在 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 在同一个代码库上协作用互相制衡的方式逼近你要的交付质量。
