最近我干了一件挺费电的事把 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 stableAndroid SDK 版本 34JDK 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 三方结果横向对比评测维度Step 5 PreviewDeepSeek V4 ProGLM5.3首次导入可用代码量6/7 文件10/12 文件5/5 文件场景结构清晰度高中过度分层中节点路径硬编码移动端性能考虑优中中中文需求理解良中优代码注释良优中我修复到可玩所需轮次3 轮4 轮2 轮从表格可以看出来首次跑通难度最低的是 GLM5.3工程规范最完整的是 DeepSeek V4 Pro而综合完成度最高的是 Step 5 Preview。我把“修复到可玩所需轮次”作为核心指标是因为它最接近真实开发中的成本模型再聪明只要修 bug 花掉一下午就不如一个能更早跑起来的朴素方案。这里不是给模型排名而是告诉你每个模型的脾气不一样Step 5 适合帮你定方案DeepSeek 适合帮你补工程GLM 适合帮你快速立起 demo。如果你想要一个能立刻打印出来炫耀的版本先用 GLM 起步再让 DeepSeek 补结构最后用 Step 5 做性能收敛这条组合路径在这个项目里其实相当顺。4. 实操过程把 Godot 项目变成开源安卓 APK4.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。这段经验也写进 READMEREADME 里我还特意标注了“本项目由 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 高频问题速查表现象可能原因定位思路修复方案APK 构建报 “No export template found”导出模板缺失或版本不匹配看控制台错误码检查模板版本下载与引擎版本一致的 export template真机黑屏 / 花屏桌面渲染管线不支持查 Logcat 中的 Vulkan 报错项目设置里把渲染方法改为 Mobile/Compat触屏滑动不跟手屏幕坐标直接用于 3D打印 event.position 对比世界坐标用滑动增量映射到 X 方向碰撞加分一次变两次Area3D 信号重复进入输出日志观察触发次数增加冷却标志或更换碰撞体首帧卡顿几十秒大量节点在 _ready 生成Profiler 看 Scene Load 有没有尖峰改成延迟生成 / MultiMeshUI 改名后脚本崩溃节点路径硬编码搜索代码中的$路径改成export引用声音在安卓上不出声音频驱动或资源未导出试听 WAV检查资源过滤使用默认驱动检查导出包含音频排查时不要对着代码干瞪眼我的顺序很固定先看 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、碰撞信号这些坑有了肌肉记忆。希望这篇记录能帮你少踩几个我已经踩过的坑。