三大AI模型实测生成安卓3D游戏：Godot代码到APK打包全记录

最近我干了一件挺费电的事：把 Step 5 Preview、DeepSeek V4 Pro、GLM5.3 三个模型拉到同一个考场，让它们用同一份需求文档，从零写一个开源的安卓 3D 小游戏《森林金币跑酷》。为什么选 3D 游戏当考题？因为 3D 游戏里包含场景树、物理碰撞、输入映射、UI 脚本、安卓生命周期和性能优化，比写接口、写 CRUD 更能暴露模型对“一个完整项目”的理解能力。这篇不是要证明谁封神，而是把我实测时用的提示词、三个模型分别给出的代码结构、打包成 APK 的过程中踩过的坑，以及最后沉淀出来的 AI 辅助开发流程，原原本本记录在这里。不管你是独立游戏开发者，还是刚想用 AI 练手写游戏的新手，应该都能从这里抄到一点能直接用的东西。

1. 为什么选“开源安卓 3D 游戏”当试金石

1.1 3D游戏对模型来说是一次“综合大考”

一个看似简单的“3D跑酷”，背后至少牵扯五层问题：第一层，场景结构，你要把玩家、地面、树木、金币、障碍、灯光、UI 组织成一颗合理的 Scene Tree，而不是全塞进一个节点；第二层，物理与碰撞，玩家是 CharacterBody3D 还是 RigidBody3D，金币用 Area3D 检测触发还是用静态碰撞体；第三层，输入与交互，键盘 A/D 只是桌面调试用的，真机要处理触摸滑动，还要把屏幕坐标转成 3D 坐标系里的位移；第四层，移动端性能，Draw Call、节点数量、渲染方式、纹理压缩每一项都可能让低端安卓机直接变成幻灯片；第五层，导出管道，Godot 项目能不能打出 APK，取决于 export_presets.cfg、签名、SDK 版本是否齐全。如果模型只能输出一个孤零零的 main.gd，等于交白卷。所以我这次评测的标准也很简单：不是看谁对话时说话好听，而是看它生成的代码导入 Godot 后能不能跑、能不能改、能不能打包。

我特意把题目限定为“开源安卓 3D 游戏”，这也是有原因的。开源意味着我不能偷偷绕过版权问题，所有资源需要程序化生成；安卓意味着必须考虑触屏、内存、包体和续航；3D 则逼着模型理解坐标、相机和光照。三者叠加下来，能刷掉一大批只会背“代码模板”的回复。我想要的答案，不是一段看起来存在但根本跑不起来的“代码幻觉”，而是一份可以直接交给引擎执行的真实项目。这也是我为什么把需求文档写得很长，长到像一张验收清单。

1.2 技术选型：为什么偏偏选 Godot 4

选引擎是评测前最需要认真考虑的事。Unity 和 Unreal 我都想过，但第一它们不是严格意义上的开源引擎，商用授权有各种限制；第二它们的场景文件格式复杂，模型生成的一大堆.unity、.uasset很难在纯文本层面逐行审查；第三空项目体积太大，不符合“开源安卓 3D 游戏”里“小而美”的预期。Three.js 也不算理想，它本质是 WebGL 渲染库，要套一层 Capacitor 或 WebView 才能变成 APK，性能损失和兼容性问题反而会干扰评测。最终我选了 Godot 4，核心原因有三个：一是引擎本身对开发者友好，导出安卓 APK 是官方一级支持；二是场景文件.tscn、脚本.gd、配置project.godot都是纯文本，模型生成的代码我能用 diff 工具对比；三是它自带 Primitive Mesh、StandardMaterial3D 和 MultiMesh，正好支持我在需求里要求的“不依赖外部模型，程序化生成场景”。

为了让测试变量尽量少，我设计了一个低多边形风格的《森林金币跑酷》：狐狸沿 Z 轴自动前进，玩家通过 A/D 键或左右滑动在 X 方向换道，路上捡金币、躲障碍，60 秒倒计时结束看总分。玩法到这里已经够简单，但足够触发物理、输入、UI、计时、音效、动画旋转这些常见模块。我还在需求里明确写了“所有资源用 Primitive Mesh / 程序化生成，不依赖外部 3D 模型”，这一条能把 AI 偷懒丢链接或者生成一堆假资源文件的路径堵死。另一方面也方便后续打包安卓，没有大体积模型，APK 体积才能控制在二三十 MB 以内，低端机也能跑得动。

2. 实测准备：同一份需求文档，三个模型，一套评测口径

2.1 测试环境与评测规则

先说说测试环境，方便你复现时有参考。我用的笔记本是 i5-1240P + 16GB 内存，系统是 Ubuntu 22.04，引擎是 Godot 4.2.2 stable，Android SDK 版本 34，JDK 17。三个模型里，Step 5 Preview 我是通过内测通道访问的，DeepSeek V4 Pro 和 GLM5.3 走的是各自的 API 接口。为了降低随机性，同一个需求我给每个模型都发了三遍，取最能跑通且没有致命报错的那次作为最终结果。我还统一了对话轮次：第一轮收集项目结构和场景树，第二轮收集关键脚本，第三轮补全遗漏的project.godot和导出配置。这看起来比一次“一键生成”更接近真实用法，因为现在没有模型能够在一个回复里高质量地输出整棵项目树，多轮交互才是落地时最高效的方式。

要提前说明的是，Step 5 Preview 名字里就带 Preview，性能表现很可能随版本更新变化；DeepSeek V4 Pro、GLM5.3 也可能有服务端配置差异。所以下面所有结论只代表我那台电脑、那几天、那些对话上下文的实测结果，别当成官方数据。我之所以把提示词完整贴出来，就是希望你能用自己的账号重新跑一遍，用同一套题目验证。

2.2 我给三个模型用的同一份提示词

我正在开发一个开源的安卓 3D 小游戏《森林金币跑酷》，使用 Godot 4.2。 需求： 1. 玩家控制一只小狐狸，在森林场景中沿 Z 轴自动前进，通过 A/D 键或左右滑动控制水平移动（X 轴）。 2. 地面使用大型绿色平坦 Mesh，道路两侧程序化生成低多边形树木和石头。 3. 金币随机出现在前方约 5-20 米处，悬浮在 1 米高度，自动绕 Y 轴旋转；玩家碰到金币 +10 分，播放短音效。 4. 障碍物为原木/石头，玩家碰触后扣 1 点生命，生命为 0 则游戏结束。 5. HUD 显示分数、生命、倒计时 60 秒；倒计时归零后显示结算面板，包含分数和“重新开始”按钮。 6. 所有资源用 Primitive Mesh / 程序化生成，不依赖外部 3D 模型和网络下载。 7. 项目需支持触屏滑动输入与键盘输入，能在 Android 8 以上设备稳定运行，帧率不低于 30 FPS。 8. 代码需包含场景树结构说明、关键注释，并遵循 MIT 开源协议。 请先给出建议的目录结构和场景树，再给出全部 GDScript 脚本、`.tscn` 场景文件和 `project.godot` 配置。

这份提示词里有几个词是精心设计的：“开源”要求模型考虑许可证；“安卓”要求它知道 target SDK 和触屏；“不依赖外部模型文件”是为了压缩生成体积；“60 秒倒计时”是明确验收标准。模型非常吃“验收标准”，你写“做一个跑酷游戏”，它可能会给你 20 个文件的天马行空设计；你写“倒计时 60 秒，碰到障碍扣 1 点生命，生命为 0 结束”，它至少知道该实现哪些变量和信号。我后来复盘时发现，三个模型对“请先给出建议的目录结构和场景树，再给出全部脚本”这一句的理解差异很大，Step 5 会认真列目录，DeepSeek 会直接开干，GLM 会老老实实先给你场景树。不同的理解方式，直接影响了后续生成质量。

2.3 评测维度：不只看“能不能跑”

我这次没有用主观打分器，而是建了一张评测表：首次导入可用代码量、场景结构清晰度、移动端性能考虑、中文需求理解、代码注释、修复到可玩需要的对话轮次。需要说明的是，“首次导入可用代码量”指的是把模型给的文件全部复制进空项目后，打开主场景时没有红色报错的比例，不是“能看出这是个游戏”的比例。很多模型生成代码单独看逻辑正确，但放在 Godot 的_physics_process里有个节点类型写错，导入就直接红屏，这就不算可用。真实游戏开发里，代码不是论文，能在编辑器里跑起来、在真机上不掉帧才是硬指标。所以第三轮我会手动修正明显错误，但不改架构，记录的是“我花了多少力气才能把它变成可玩 demo”。这个环节最花时间，也最能拉开差距。

3. 三方“交卷”：Step 5 Preview、DeepSeek V4 Pro、GLM5.3 的生成结果

3.1 Step 5 Preview：推理链路长，但第一次运行直接红屏

Step 5 Preview 这次给了我一种“心里很有数”的感觉。它第一轮输出就包含 7 个文件：project.godot、main.tscn、player.gd、coin.gd、obstacle.gd、game_manager.gd、export_presets.cfg，场景树把光照、地形、玩家、生成器、HUD 分得清清楚楚。我最欣赏的是它在移动端性能上的敏感度：生成的 80 棵树不是普通 Node，而是建议我用 MultiMesh 实例化；金币没有用每帧旋转动画，而是直接算rotation.y += delta * 2.0。这些细节说明模型对“少掉 Draw Call”有概念。

func _physics_process(delta): position.x = move_toward(position.x, target_x, speed * delta) position.x = clamp(position.x, min_x, max_x)

不过第一次打开场景还是红屏了。问题出在它把触摸屏幕坐标直接赋给target_x，导致手指在屏幕左侧点击时，狐狸瞬间跑到画面外；更隐蔽的是障碍物节点的CollisionShape3D用了 BoxShape，却把节点旋转了 45 度，碰撞盒和视觉模组对不上。我把这两个报错和现象回贴给它，它第二轮就给出了基于“滑动偏移增量”的输入映射方案，并把碰撞盒改成ConvexPolygonShape3D，红屏问题解决。整体来讲，Step 5 的推理链路确实长，适合当架构师，但需要你手里先有一份验收清单，否则它会在一个答案里塞进太多自己认为“优雅”的东西。

3.2 DeepSeek V4 Pro：代码最工程化，但有点刹不住车

DeepSeek V4 Pro 这次生成的工程最像“正经商业项目”。它给了 12 个文件，包含Autoload/GameState.gd、Scenes/Player.gd、Scenes/Coin.gd、Scenes/Obstacle.gd、Scripts/SpawnManager.gd，还引入了信号系统和 Resource 配置表。比如金币碰撞代码：

signal coin_collected(value: int) func _on_area_3d_area_entered(area: Area3D) -> void: coin_collected.emit(10) queue_free()

第一眼看上去很规范，实际运行也基本能玩，但我在真机测试时发现首帧会卡顿十几秒，原因就是它在_ready()里一次性生成了 80 个金币节点，低端安卓根本吃不消；另外它还设计了三个 Autoload 单例，初始化顺序稍不留神就互相引用为 null，这让一个 60 秒的小游戏承担了太多架构。我向它反馈“请改成按玩家 Z 位置动态生成、循环复用金币，并取消 GameAudio 的单例，把音效播放器放在主场景里”，它倒是很听话，改了以后帧率从首帧 10 FPS 回到 55 FPS。

DeepSeek V4 Pro 的代码注释是我见过最友好的，甚至会在变量上方写清楚单位、边界值、TODO。如果你是要维护一个长线项目，这种风格很舒服。但如果你只想在周末做一个开源安卓 3D demo，它会给你一种“杀鸡用了牛刀”的疲劳感。评测时我把它的架构分打得很高，可玩 demo 修复成本却因此涨了一轮，因为它对“简单优先”的克制力不够强。

3.3 GLM5.3：中文需求理解最顺，场景搭建最直观

GLM5.3 是三个模型里给我“土办法”感觉最强的。它只给了 5 个文件，但main.tscn里已经把所有关键节点都摆好了，地面、道路、灯、玩家、金币、障碍、HUD 都有，导入就能看到画面。它对中文需求的理解确实顺，例如我写“玩家碰到金币 +10 分，播放短音效”，它生成的代码直接用$HUD/ScoreLabel更新分数，并且在.tscn里预留了AudioStreamPlayer节点。它第一个版本的碰撞逻辑：

func _on_coin_area_entered(area): score += 10 $HUD/ScoreLabel.text = str(score) queue_free()

问题也有：节点路径硬编码意味着只要我把ScoreLabel移到别处，整个脚本就崩；金币的碰撞体用了AnimatableBody3D，会让area_entered信号在真机上触发两次，得分翻倍。但这些属于“修起来很快”的小坑，我反馈一次后它就把路径改成了@export var score_label: Label，并把碰撞体改回StaticBody3D，总共只用了两轮就进入可玩状态。

如果给新手推荐，GLM5.3 是最容易跑通的那个，因为它的输出最“直接”，几乎没有绕弯；但它的扩展性弱一些，没有状态管理，也没有数据驱动的生成器，后期想加新玩法只能自己动手。这个取舍放在“开源安卓 3D 游戏”场景里很微妙——要快速出第一个版本，它最合适；要长期维护，还得靠人工重构或让更工程化的模型参与进来。

3.4 三方结果横向对比

从表格可以看出来，首次跑通难度最低的是 GLM5.3，工程规范最完整的是 DeepSeek V4 Pro，而综合完成度最高的是 Step 5 Preview。我把“修复到可玩所需轮次”作为核心指标，是因为它最接近真实开发中的成本：模型再聪明，只要修 bug 花掉一下午，就不如一个能更早跑起来的朴素方案。这里不是给模型排名，而是告诉你每个模型的脾气不一样：Step 5 适合帮你定方案，DeepSeek 适合帮你补工程，GLM 适合帮你快速立起 demo。如果你想要一个能立刻打印出来炫耀的版本，先用 GLM 起步，再让 DeepSeek 补结构，最后用 Step 5 做性能收敛，这条组合路径在这个项目里其实相当顺。

4. 实操过程：把 Godot 项目变成开源安卓 APK

4.1 环境准备：SDK、JDK、导出模板一个都不能少

生成代码只是第一步，真正让“开源安卓 3D 游戏”这几个字落地的，是把它打包成 APK。这一步三个模型都做得不算好：Step 5 在export_presets.cfg里写了包名，但忘了写版本号；DeepSeek 连导出预设都没给；GLM 给了，但把min_sdk写成 19，而 Godot 4.2 最低要求其实是 21。所以最后是我手工把导出环境统一了一遍。先装 JDK 和 SDK，如果你用 Ubuntu，可以执行：

sudo apt install openjdk-17-jdk mkdir -p ~/Android/Sdk sdkmanager "platforms;android-34" "build-tools;34.0.0" "platform-tools"

然后是导出模板。Godot 的 export template 必须和引擎版本完全一致，漏掉就会出现 “No export template found”。在编辑器里打开“编辑器 > 管理导出模板”，下载对应的 4.2.2 稳定版模板。下载后回到“编辑器设置 > 导出 > Android”，把 SDK 路径填进去，比如~/Android/Sdk。我在这步卡过三次，所以多说一句：模板和引擎版本不一致时，命令行导出不会给出明确提示，只在控制台里打一行 “Android build module not found”，非常容易被忽略。

4.2 导出配置与打包命令：从编辑器导出到命令行构建

在“导出”窗口添加一个 Android 预设，包名我填的是com.example.forestcoin，方向设为横屏，因为跑酷的左右换道视野需要横向空间。最低 SDK 改到 21，目标 SDK 34。权限方面，单机小游戏不需要 INTERNET、不需要定位，保持干净的权限列表反而更适合开源项目。图标方面，Godot 4 允许你只提供一张 512x512 的 PNG，它自动生成各分辨率；注意 PNG 不要带透明通道抖动，否则某些国产安卓机上图标边缘会发毛。

godot --headless --export-release "Android" build/forestcoin.apk

前提是你已经在导出面板保存了 Android 预设，并且安装过导出模板。这里有个小坑：如果你用--export-debug，打出来的包会带远程调试代码，体积会大不少，商店审核也可能敏感；开源项目放在 GitHub 给用户自取，用 Release 就好。如果你只是想装到手机上快速看效果，开发机连接 USB 后直接adb install -r build/forestcoin.apk就行。

4.3 包体大小和真机验证：20 MB 的“小而美”是怎么做到的

因为我们强制“不依赖外部模型”，整个项目里没有 FBX、没有贴图大文件，只有程序化生成的 Mesh、标准材质和一段不到 1 秒的音效，所以 APK 最终只有 21 MB。这个数值在 Godot 4 里算合理，空模板本身就要占 20 MB 左右。想让体积再小一点，可以在项目设置的渲染 > Vulkan 里把纹理压缩设为 ETC2/ASTC，但前提是素材原本是 PNG/JPG，程序化的 3D 模型不吃这套。真机验证是必须的，不要只在编辑器 Play 里跑，因为编辑器跑的是桌面渲染管线和鼠标输入，和安卓的 Mobile 渲染、触摸输入完全是两回事。我用一台骁龙 695 的旧手机装上 APK，盯着 Godot Profiler 看 Draw Call：三个模型第一版全部偏高，Step 5 用了 MultiMesh 所以最好，DeepSeek 一次性生成节点直接首帧爆炸，GLM 每棵树的 Mesh 是独立实例，差点 CPU 满载。

最后我用了一个很土但有效的优化：把所有树、石头统一塞进两个 MultiMesh 节点，场景里只保留 1 个光源，关掉阴影贴图。优化后 Draw Call 从 300 多降到 60，骁龙 695 上稳定 60 FPS。这段经验也写进 README，README 里我还特意标注了“本项目由 AI 生成 + 人工修改”，这既是透明度，也是给后来者一个预期：你看到的风险代码，可能并不是人类逐行写的，需要自己审查后再用。

4.4 开源发布：许可证、README，以及不要提交的三类文件

开源不是把文件夹往 GitHub 一拖就完事。我建仓库后补了 MIT LICENSE，因为 Godot 引擎本身采用宽松许可证，我的项目代码用 MIT 不会和引擎冲突。README 里除了功能介绍，还写了环境准备、打包命令、操作说明。最重要的是.gitignore，否则你会把三类不该进仓库的东西传上去：.godot/缓存目录、*.keystore签名文件、build/下生成的 APK。特别是 keystore，它相当于你的应用身份证，一旦公开，别人就可以拿你的签名去发布篡改包，等于把你整个开源项目的信誉都卖掉。我在 README 里只保留构建命令，不贴 keystore 路径和密码，只是为了安全。

发布后我收到了几条 issue，有反馈说“金币碰撞会双倍加分”，还有问“为什么打包出来体积比你说的多”。这正好变成新的测试用例。开源安卓 3D 游戏的好处就是，每个人都是你的测试员，但你也要为 demo 的质量兜底。因此我强烈建议在 README 里放一张“已知问题”清单，比如“当前版本音效是占位实现，部分安卓机型不出声”，这会让用户少一些失望。

5. 实测中遇到的高频问题与排查技巧实录

5.1 三个模型生成的代码，最常见的 6 个坑

回到代码层面。三个模型交叉跑一遍，我总结出六个反复出现的坑：

第一个坑是碰撞信号重复触发。很多模型喜欢把金币和障碍做成Area3D，再用area_entered判断，但碰撞体如果是移动的 CharacterBody3D，或者金币本身是AnimatableBody3D，信号会在一次物理帧里触发两次，导致加分翻倍、掉血翻倍。我的处理方式是给玩家加一个 0.3 秒的冷却计时器，或者干脆在进入时置一个is_collected标志。

第二个坑是屏幕坐标和 3D 坐标混淆。模型生成的输入处理经常直接把event.position.x赋给玩家节点坐标，但屏幕像素坐标和 3D 世界坐标根本不是一回事。需要基于滑动增量来计算水平目标位置，再乘以一个和 Camera 距离相关的灵敏度系数；或者用Camera3D.project_ray_origin做射线检测。这个坑在三个模型里都出现了，Step 5 最典型。

第三个坑是节点路径硬编码。$HUD/ScoreLabel这种写法很直观，但一旦你调整了节点层级，整个脚本就崩。我建议在模型生成后做一次机械替换，把$路径/节点改成@export var score_label: Label，然后在场景里拖拽绑定。这样后续改 UI 不会互相牵连。

第四个坑是物理和渲染帧率不匹配。金币旋转放在_process()里没问题，但玩家位置更新放到_process()就会导致抖动，因为物理系统的步长是固定的 60Hz，而渲染帧率可能是 120Hz。要么统一用_physics_process，要么在_process里做插值。这个属于新手看不出来、真机上很明显的问题。

第五个坑是一次性生成太多节点。80 个金币、50 棵树的场景在桌面编辑器里毫无压力，但在低端安卓上首帧就是灾难。解决方法有延迟生成、对象池、MultiMesh，建议模型生成完先人工扫一眼“循环里new了什么”。

第六个坑是导出配置不完整。模型给的代码再完美，没有export_presets.cfg就让安卓打包无从谈起。所以提示词里要明确“请包含导出配置”，并且在拿到结果后人工核对一次包名、版本号、SDK 版本。如果模型没给，不要求“再写一次”，而是直接把“缺少文件报错”贴给模型，它自己会补。

5.2 高频问题速查表

排查时不要对着代码干瞪眼，我的顺序很固定：先看 Godot 编辑器底部错误输出，再看手机adb logcat，最后才去看模型生成的代码。很多时候模型写的是“理论正确”，但场景节点没连接、信号没绑定，这类问题用肉眼很难找。把日志原样复制到对话框里，比你说“帮我修一下”有用十倍。实测下来，三个模型都能根据完整错误日志定位到具体函数，Step 5 甚至能推断出是物理帧里哪个节点为 null 导致的空引用。

5.3 独家技巧：把“一整个项目”拆给 AI 分阶段写

最后一招，也是这次测试最大的收获：不要要求模型一次生成所有文件。如果你是人工从零开发，你也不会一次性写完整棵树再统一调试，你会先搭地面，再放玩家，再写碰撞。AI 同样需要这种节奏。我的理想对话顺序是：先把需求文档发出去，让它给项目结构和场景树；确认结构合理后，让它先写player.gd和main.tscn的玩家部分；跑通基础移动后，再让它生成coin.gd、obstacle.gd；最后才把game_manager.gd、HUD、音效、导出配置补上。每一步都跑一遍，出问题马上带着日志追问。这个流程看起来慢，实际上比“一次性生成 12 个文件然后修 20 个报错”快得多，因为错误是逐步暴露的，定位范围小，模型的修复准确率也会更高。

配合 Git 使用，效果更好。每次让 AI 修改之前，先git commit保存当前可运行版本；改崩了就回滚，再换一种方式问。我在测试三个模型时，给每个模型都单独开了一个 Git 分支，这样横评结果一目了然：Step 5 的 branch 最后留下的是性能优化版本，DeepSeek 的 branch 留下的是工程化版本，GLM 的 branch 留下的是最小可玩版本。这个习惯现在也沿用到了我自己的商业项目上，几乎成了刚需。

6. 让 AI 帮你做 3D 游戏的可复用工作流

6.1 需求文档要写“验收标准”，而不是“愿望清单”

很多朋友跟我说，AI 生成游戏代码不如预期，我让他们把提示词贴出来，发现问题大多出在需求太模糊。比如“帮我做一个 3D 跑酷”，AI 只能自由发挥，结果当然不可控。我这次的需求文档几乎是按验收标准写的：操作方式、坐标系、生命值、倒计时、资源约束、性能目标、开源协议，每一条都能在完成后逐项勾选。模型不擅长读心，它擅长把明确要求翻译成代码。你给它“碰撞一次扣 1 点生命，生命为 0 结束”，它就能生成对应的变量和判断；你只给它“有碰撞和生命系统”，它就给你一套自认为合理的规则，你多半不满意。需求里的约束越多，越能压低模型的“幻觉空间”。

6.2 先架构后填代码，每轮只交付一个小模块

提示词写作上，我建议采用“三层递进”结构：第一层是项目背景和总体目标，第二层是具体约束和验收清单，第三层是“请先给项目结构和场景树，再开始写代码”。让模型先做架构师，再做程序员。等它给出结构后，再逐步引导：“现在只实现玩家移动，其他模块先留空函数”“现在添加金币碰撞，复用刚生成的玩家信号”。这样每一轮输出量小，token 不容易截断，错误也少。我测试的三个模型里，DeepSeek V4 Pro 对“只实现一个模块”的要求执行得最彻底，Step 5 Preview 总是忍不住多写后续逻辑，GLM5.3 则需要你明确告诉它“不要写多余内容”。

6.3 从地面到打包：推荐的一套落地顺序

实操顺序建议固定为：地面和玩家 -> 输入和碰撞 -> 金币 -> 障碍 -> 音效和 UI -> 计分和倒计时 -> 导出安卓。每一步之间都要有可运行的中间态。比如地面和玩家完成时，你已经能在编辑器里看到狐狸站在森林里；输入和碰撞完成时，可以直接用 A/D 移动并撞墙测试；金币和障碍完成后，游戏已经能“玩”了。最后再加 UI 和打包，不要把 UI 提前，否则模型生成的脚本会过早耦合进$HUD路径，后面一动 UI 就崩。我这次按照这个顺序让三个模型重新生成了一遍，整体修复成本比第一次少了一轮左右。

6.4 错误日志是最好的“追加提示词”，但也别忘了人工复核点

当项目报错时，我最推荐的提问模板是：先贴出完整错误日志，再贴触发错误的那一段代码，然后加一句“只修改导致这个错误的函数，不要重构其他逻辑”。三个模型里，DeepSeek 对这个指令的理解最好，Step 5 有时会过度修复把相邻代码也改了，GLM 则容易把错误归咎在环境上。所以收到修改结果后，一定要用 diff 确认它到底改了什么。人工复核主要集中在三块：一是权限，不要向系统申请不必要权限；二是物理参数，碰撞层是否只有玩家层和障碍层；三是资源，是否有外部链接或需要联网下载的内容。开源安卓 3D 游戏尤其要注意隐私，单机联网权限能不开就不开。

6.5 别把模型当“全栈工程师”，当“结对程序员”更轻松

最后说一点个人感受。这次实测完，我对“AI 替代程序员”的说法更不感冒了，至少 3D 游戏这个方向还差得远。模型能帮你快速从 0 到 1，但 1 到 10 之间全是工程决策：要不要用对象池？场景树怎么设计？碰撞掩码怎么分层？包体要不要压纹理？这些决策不好好做，游戏很快会在真机上现出原形。把模型当成一个话很多、知识面很广、但时不时会写出幻觉代码的“结对程序员”，你的心态会好很多。

如果让我给刚入坑的朋友一个建议，我会说：别急着让 AI 一次性写完整个游戏，先让它给你项目结构，再逐模块推进；每改一步都跑一次，每崩一次都贴日志；跑通后记得做一次真机测试，再把仓库整理干净。我自己就是在这样跑了三版之后，才对 Godot 4 的安卓导出、MultiMesh、碰撞信号这些坑有了肌肉记忆。希望这篇记录能帮你少踩几个我已经踩过的坑。