实际做 3D 星球跑酷时第一个让人想放弃的瞬间往往不是建模而是角色刚站起来就沿着世界坐标系掉出星球。用 AI 插件在 Godot 里做游戏最典型的场面是模型帮你写了一整段 GDScript你复制进编辑器按 F5 运行结果角色直接飞出星球。本文用 Claude Fable 5.1 作为对话式编程助手用 Ziva 这类 Godot AI 插件把生成结果接回编辑器目标是从零完成一个能站在星球表面跑跳、能躲避障碍并计分的 3D 跑酷原型。写完以后你不仅能复现这个项目也能把“AI 生成代码 - 检查物理与碰撞 - 调试 - 导出”这套流程迁移到其他 Godot 小游戏里。1. 这套工作流要解决的核心问题AI生成代码不等于项目能跑很多刚接触 AI 辅助游戏开发的人会把“让 AI 写代码”当成“让游戏完成”。这两者之间差着场景搭建、输入映射、物理体配置、碰撞层设置和游戏状态管理。Claude Fable 5.1 和 Ziva 插件配合的核心价值不是替你按下运行键而是把一个较大的开发目标拆成若干个可以验证的小任务。1.1 Claude Fable 5.1 在开发链路里负责什么先解释一个关键点Claude Fable 5.1 这个叫法在社区里更多是某一代 Claude 对话能力和 Fable 风格的组合叫法。它本身不是 Godot 内置插件而是一个对话式编程助手。你可以把它放在浏览器、桌面客户端或命令行环境里用自然语言向它描述需求。在星球跑酷这个项目里它主要负责三类工作根据需求生成 GDScript 脚本例如角色控制、球面重力、障碍生成。解释一段报错信息告诉你 Godot 4.x 中某个 API 的迁移方式。帮你重构参数把移动速度、跳跃高度、重力强度从硬编码改为export变量。对话式编程最容易犯的错误是上下文不完整。如果你只写一句“给我做一个星球跑酷”它给出的代码大概率是理想地面游戏的变形。要让生成结果可用你需要在会话里提供项目结构、Godot 大版本、场景树等背景信息。下面是一个可以复制的提示词框架你是擅长 Godot 4.x 和 GDScript 的工程师。 我正在做一个 3D 星球跑酷原型。 场景结构如下 - Planet.tscnStaticBody3D子节点有 SphereMesh 和 CollisionShape3D半径 10。 - Player.tscnCharacterBody3D子节点有 CollisionShape3D 和 MeshInstance3D。 请写出 Player.gd要求 1. 每帧根据与星球中心的连线更新 up_direction实现球面重力。 2. 用 move_left / move_right / move_forward / move_back 控制移动。 3. 支持跳跃跳跃力度可导出。 4. 不需要动画先用胶囊体占位。 请给出可运行代码不要解释太多。这个提示词把技术栈、场景结构、功能边界、验收方式都定义好了AI 返回的代码才有实际落地的可能。1.2 Ziva 插件在编辑器里负责什么Ziva 插件在 Godot 中的角色是让 AI 能力进入编辑器内部。它通常作为 EditorPlugin 出现在addons目录下提供面板、快捷操作和代码生成入口。你在编辑器中选中一个节点它可以把节点上下文交给大模型再在面板里输出建议代码甚至直接生成.gd文件。从工程角度看这类插件把“外部对话”变成了“编辑器内对话”减少了复制粘贴的损耗。但不同插件的安装方式、权限申请、网络请求逻辑差别很大。下面的流程以常见 Godot 4.x 插件加载方式为例如果 Ziva 插件的入口或配置项在后续版本里改了请以你自己安装版本的 README 为准。插件接入前先理解它的运行边界插件通过 HTTP 请求把代码片段和提示词发给模型服务。它需要读取你的项目文件才能生成符合上下文的代码。它的输出本质上是“建议”不会自动保证物理和碰撞配置正确。也就是说Ziva 插件负责降低“从对话到代码”的摩擦而验证代码正确性仍需要你完成。1.3 为什么星球跑酷特别适合验证这套工作流星球跑酷比普通平面跑酷多了两个难点。第一重力方向不是固定向下的。角色站在星球赤道和站在北极重力方向完全不同。所有依赖Vector3.DOWN的移动逻辑都会立刻失效。第二角色朝向需要随球面法线变化。地面不是无限平面角色可能站在任意角度所以up_direction必须每帧重算。这两个难点很容易用一句话向 AI 描述却很难直接用传统代码模板解决。因此它很适合用来检验一套 AI 辅助工作流是否靠谱AI 生成代码人类检查物理模型再通过日志和调试工具验证结果。下面是传统开发与 AI 辅助开发的对比对比项传统开发AI 辅助开发写代码方式手动编写完整脚本描述需求后生成候选代码场景搭建手动创建节点和碰撞体插件可能辅助生成部分结构错误排查看日志逐级定位把日志发给模型请求解释验证责任开发者开发者模型不承担运行责任失败模式语法错误、逻辑错误版本不匹配、物理配置缺失、提示词模糊这个表格想说明一点AI 插件能缩短编码时间但没有改变“你为项目负责”的事实。2. 环境准备Godot 4.x、AI 会话和插件接入在写球面重力之前先把环境对齐。版本不一致会导致后面大量代码无法运行尤其容易发生在 AI 生成代码的场景里。2.1 安装 Godot 与项目初始化本文示例基于 Godot 4.x。Godot 3.x 和 4.x 在移动 API 上有明显差异例如move_and_slide的参数从传递式改成属性式。如果你安装的是 3.xAI 生成的 4.x 代码会直接报语法错误。安装步骤相对简单从 Godot 官网下载对应系统的标准版压缩包。解压后运行可执行文件进入项目管理器。点击“新建项目”填写项目名称例如PlanetRunner。渲染器选择 Forward Plus 或 Mobile新手用 Forward Plus 即可。点击“创建文件夹”和“创建”后进入编辑器。进入编辑器后先确认主场景类型。后续步骤会创建 3D 场景所以项目初始化时选择 3D 场景即可也可以在底部“以便其他方式”里手动新建Node3D。在项目根目录下建议按照下面的目录结构组织文件PlanetRunner/ ├── project.godot ├── scenes/ │ ├── Main.tscn │ ├── Planet.tscn │ └── Player.tscn ├── scripts/ │ ├── Player.gd │ └── GameManager.gd └── addons/ └── ziva_plugin/scenes放场景文件scripts放脚本addons放第三方插件。结构清晰之后AI 生成的代码路径描述也会更准确。2.2 把 Ziva 插件接进编辑器Ziva 插件这类第三方 AI 插件安装方式大同小异。先下载插件压缩包把解压后的目录复制到项目的addons文件夹中。操作路径如下在 Godot 编辑器中点击顶部菜单“项目”。选择“项目设置”切换到“插件”标签页。找到 Ziva 插件对应的条目勾选“启用”。点击“确定”后编辑器右方或底部会多出插件面板。很多插件在第一次启用时不会立刻显示需要重启编辑器才能加载 EditorPlugin。如果面板没有出现第一步不是重装插件而是查看底部“输出”面板中是否有加载报错。常见输出面板错误有两种资源丢失例如插件引用了不存在的扩展脚本。依赖缺失例如插件需要某个 DLL 或语言绑定但没有放入addons目录。Ziva 插件通常会把生成代码的能力做成一个 Dock 面板。你选中节点后面板会读取节点路径、脚本内容和选中信息然后等待你输入提示词或直接调用 AI 接口。需要强调的是涉及 API Key 的配置不要硬编码进项目文件。推荐的做法是放到操作系统环境变量中或者使用插件提供的环境变量配置入口。如果你把 Key 写进project.godot后提交到 Git等于把凭证公开。2.3 把 Claude Fable 5.1 的会话上下文设计好接入插件后下一步是为 AI 会话建立上下文。上下文质量决定了生成代码的可用性建议每次开始新会话时先发一段固定格式的项目说明。一个可行的上下文模板项目Godot 4.x 3D 星球跑酷。 场景 - PlanetStaticBody3D球体半径 12带 SphereShape 碰撞。 - PlayerCharacterBody3D胶囊体高 2宽 1。 - Main挂载 GameManager.gd负责生成障碍和计分。 技术约束 - 只使用 GDScript不使用 C#。 - 物理循环用 _physics_process。 - 移动方向要基于角色自身朝向不要基于 Vector3.DOWN。 当前问题角色站在星球顶部时移动正常走到星球侧面后往空中飞。 请定位原因并给出修复后的 Player.gd。把场景结构、节点名、半径、版本、问题现象都写清楚AI 在没有更多线索的情况下也能缩小排查范围。同时建议为每个功能单独开一个会话不要在一个长会话里反复横跳。例如“生成球面重力脚本”是一个会话“设计障碍生成逻辑”是另一个会话。这样每次生成的结果都能独立回滚一旦某个功能崩掉不会影响其他代码。3. 球面重力先让角色“住”在星球上这是整个原型中最关键的一步。角色能不能站在星球表面取决于你如何定义“向下”。3.1 为什么普通跑酷角色会直接坠出星球在平面跑酷游戏中重力方向固定是Vector3.DOWN。角色站在平地上up_direction永远是Vector3.UP。移动和跳跃都基于这两个向量运算。星球场景完全不一样。角色站在星球顶面时向下的方向是指向球心走到星球侧面时向下的方向是水平朝左走到星球底部时向下的方向反过来向上。如果仍然使用固定重力角色会在星球侧面被“水平拉扯”最终脱离球面。解决思路是每一帧根据角色位置计算指向球心的方向把它作为当前帧的重力方向同时更新CharacterBody3D.up_direction。这样move_and_slide和is_on_floor的判断基准也会跟随球面变化。3.2 搭建 Planet 场景和 Player 场景先创建Planet.tscn新建场景根节点类型选StaticBody3D命名为Planet。给Planet添加子节点MeshInstance3DMesh 选择SphereMesh半径设为12。给Planet添加子节点CollisionShape3DShape 选择SphereShape半径设为12。在MeshInstance3D上新建一个StandardMaterial3D把颜色改成绿色或偏暗的纹理方便观察角色位置。再创建Player.tscn新建场景根节点类型选CharacterBody3D命名为Player。添加子节点CollisionShape3DShape 选择CapsuleShape3D高度设为2半径设为0.5。添加子节点MeshInstance3DMesh 选择CapsuleMesh尺寸与碰撞体一致。在Player上挂载scripts/Player.gd。场景树不需要做得复杂先用胶囊体占位。等跑酷逻辑跑通后再把胶囊体替换成角色模型。3.3 核心脚本基于球面法线的 CharacterBody3D在Player.gd中实现球面重力和移动控制。核心思路是获取从角色指向星球中心的向量。将这个向量的归一化结果作为新的up_direction。把速度分解为“沿星球表面方向”和“沿星球半径方向”。重力只作用于半径方向移动只作用于表面方向。参考代码如下extends CharacterBody3D export var planet: Node3D export var move_speed : 8.0 export var jump_velocity : 10.0 export var gravity_strength : 16.0 func _physics_process(delta: float) - void: if planet null: return var to_center: Vector3 planet.global_position - global_position var up: Vector3 to_center.normalized() up_direction up # 把当前速度拆成“沿向上方向”和“沿表面方向” var vertical_speed: float velocity.dot(up) # 球面重力向星球内部加速 vertical_speed - gravity_strength * delta # 读取输入计算水平方向 var input_dir : Input.get_vector(move_left, move_right, move_forward, move_back) var right : global_transform.basis.x var forward : -global_transform.basis.z var wish_dir : right * input_dir.x forward * input_dir.y var horizontal_speed : Vector3.ZERO if wish_dir.length() 0.01: # 把目标方向投影到星球切平面 wish_dir (wish_dir - up * wish_dir.dot(up)).normalized() horizontal_speed wish_dir * move_speed # 跳跃 if Input.is_action_just_pressed(jump) and is_on_floor(): vertical_speed jump_velocity # 重组速度 velocity horizontal_speed up * vertical_speed move_and_slide() # 让角色模型沿着星球法线重新向上 _align_with_planet(up, delta) func _align_with_planet(up: Vector3, delta: float) - void: var new_basis : Basis( global_transform.basis.x, up, -global_transform.basis.z ) global_transform.basis new_basis.orthonormalized()这段代码的关键在于velocity.dot(up)。它把速度投影到球面法线方向得到角色当前“离开星球”的速度分量。然后重力只调整这个分量移动只负责切平面上的速度。这样角色既不会被甩出球面也不会朝星球内部陷进去。_align_with_planet的作用是让胶囊体的模型朝向跟随表面法线。这里使用orthonormalized()把矩阵重新正交化避免变形。教学原型可以接受这个做法如果是正式项目建议使用贝塞尔插值平滑过渡避免角色瞬间跳动。星球重力相关参数可以整理成下表参数含义建议值调节影响move_speed水平移动速度8值越大角色越难控制转弯jump_velocity跳跃初速度10值越大跳跃越高滞空时间越长gravity_strength球面重力加速度16值越大下落越快跳跃手感越“重”这里没有使用现实中的9.8因为游戏手感通常需要调大重力值否则跳跃感偏飘。4. 跑酷核心移动、跳跃、障碍生成和计分球面重力跑通后开始加入真正的“跑酷”内容。4.1 先配好 Input Map否则 AI 写的代码全是死代码很多 AI 生成的 GDScript 会直接使用Input.get_vector(move_left, move_right, move_forward, move_back)但你的项目里根本没有这些 action。结果就是角色完全不动而 AI 代码本身没有报错。在 Godot 4.x 中配置方式如下打开“项目设置”。切换到“输入映射”页面。添加move_left映射到键盘A键。添加move_right映射到D键。添加move_forward映射到W键。添加move_back映射到S键。添加jump映射到空格键。完成后把 Player.gd 挂到 Player 节点上再把 Planet 节点拖到 Player 的planet导出属性中。这一步非常容易漏掉但漏掉后所有球面重力逻辑都不会生效。4.2 编写 GameManager 管理障碍和分数建立Main.tscn根节点选Node3D挂载GameManager.gd并把Planet.tscn和Player.tscn作为子场景实例化到 Main 中。GameManager.gd负责三件事使用对象池生成障碍物避免反复instantiate和queue_free。监听角色碰撞处理生命值和游戏结束。更新 HUD 上的分数。障碍物生成的核心代码如下extends Node3D export var obstacle_scene: PackedScene export var planet: Node3D export var spawn_interval : 2.0 export var pool_size : 8 var _pool: Array[Node3D] [] var _timer: Timer var _score : 0 var _running : false onready var score_label: Label $HUD/ScoreLabel func _ready() - void: for i in pool_size: var obstacle: Node3D obstacle_scene.instantiate() add_child(obstacle) obstacle.visible false _pool.append(obstacle) _timer Timer.new() _timer.wait_time spawn_interval _timer.timeout.connect(_on_spawn_timeout) add_child(_timer) _timer.start() _score 0 _running true func _process(_delta: float) - void: if _running: _score 1 score_label.text Score: %d % _score func _on_spawn_timeout() - void: if _pool.is_empty(): return var obstacle: Node3D _pool.pop_back() var spawn_direction : Vector3.RIGHT.rotated(Vector3.UP, randf() * TAU) var surface_position : planet.global_position spawn_direction * 12.0 var obstacle_up : (surface_position - planet.global_position).normalized() obstacle.global_position surface_position obstacle_up * 0.6 obstacle.visible true if obstacle.has_method(reset_obstacle): obstacle.reset_obstacle() func return_obstacle(obstacle: Node3D) - void: obstacle.visible false _pool.append(obstacle) func game_over() - void: _running false score_label.text Game Over, Score: %d % _score get_tree().paused true这里要理解几个设计选择。第一障碍物采用对象池。跑酷游戏会频繁生成和销毁障碍反复创建节点会造成瞬时卡顿。预先创建 8 个障碍实例重复使用能明显减少场景树抖动。第二障碍物生成位置使用环绕星球的spawn_direction每次在圆周上随机一个角度。这样角色跑到任何一个位置都有一定概率遇到障碍。第三get_tree().paused true暂停场景树。注意如果游戏结束后需要重新开始延迟一秒再调用get_tree().reload_current_scene()更自然。4.3 障碍物场景与碰撞返回逻辑新建Obstacle.tscn根节点选StaticBody3D或Area3D。这里使用Area3D作为检测器因为跑酷原型中障碍物一般不参与物理反弹只需要触发“碰到即结束”。场景结构Obstacle (Area3D) ├── CollisionShape3D (BoxShape3D) └── MeshInstance3D (BoxMesh)给 Obstacle 挂一个脚本提供reset_obstacle方法extends Area3D export var player: Node3D func reset_obstacle() - void: body_entered.disconnect(_on_body_entered) func _on_body_entered(body: Node3D) - void: if body is CharacterBody3D: body.queue_free()body_entered信号不要忘记连接到_on_body_entered方法。你可以在编辑器中连接也可以在_ready中连接。更稳妥的连接方式是使用body_entered.connect(_on_body_entered)同时增加一个hit信号把碰撞通知给 GameManagersignal hit(body: Node3D) func _on_body_entered(body: Node3D) - void: if body is CharacterBody3D: hit.emit(body)然后在 GameManager 里处理最终游戏结束逻辑。4.4 HUD 和玩家重生入口HUD 使用CanvasLayerMain ├── Planet (StaticBody3D) ├── Player (CharacterBody3D) ├── HUD (CanvasLayer) │ └── ScoreLabel (Label)ScoreLabel 字体建议在编辑器中调大一些方便看到分数变化。游戏运行后Label 每帧增加 1 分这个实现方式在原型阶段够用但它并不精确。正式项目中应该基于距离或时间增量累计而不是依赖_process的帧率。如果需要重生功能可以先隐藏 Player再在 GameManager 里延迟重新设置位置func restart_player() - void: var player : get_node(Player) player.global_position planet.global_position Vector3.UP * 12.5 player.visible true这样玩家死亡后不必立刻重启整个游戏可以先原地复活继续测试。5. 运行验证从编辑器测试到导出可执行文件代码写完后最重要的一步是验证而不是急着加更多功能。5.1 编辑器内的最小验证步骤按 F5 运行前先检查以下几个点Player 节点的planet导出属性是否已经赋值。Input Map 中是否已经有move_left等 action。Obstacle.tscn 是否已经拖到 GameManager 的obstacle_scene导出属性上。Planet 的碰撞层和 Player 的碰撞层是否都能互相检测。运行后依次验证这些行为角色站在星球顶部静止时不会下沉也不会飞出。按 W 和 S 可以在星球表面前后移动。按 A 和 D 可以左右转弯。按空格键可以跳离球面并在重力作用下落回表面。障碍物每隔一定间隔生成在星球表面。角色撞到障碍物后游戏结束分数停止。如果角色在某个角度突然抖动优先检查_align_with_planet的正交化逻辑和胶囊体碰撞体尺寸。5.2 用调试工具确认球面重力是否生效在运行游戏时可以打开 Debug 菜单中的“显示碰撞形状”确认碰撞体是否贴合星球表面。如果碰撞体歪斜说明up_direction更新没有生效。还可以在_physics_process中加入临时日志if Input.is_key_pressed(KEY_F3): print(up, up_direction) print(velocity, velocity)观察日志中up_direction是否随着角色在星球上不同位置而变化。如果始终是(0, 1, 0)说明planet引用为空或者角色根本没有在星球表面移动。5.3 导出前的测试用例表导出为可执行文件之前至少要完成下面这些测试。测试项预期结果未通过的常见原因角色站在星球顶部静止不下落不穿模planet 未赋值重力方向错误角色走到星球侧面跟随球面法线倾斜不会飞出up_direction 未更新跳跃后落回表面能正常落地并触发 is_on_floor碰撞体设置错误跳跃初速度过小游戏运行超过 1 分钟无明显卡顿分数持续增加对象池未生效障碍物不断实例化撞到障碍物游戏结束分数停止Area3D 的 body_entered 未连接导出到 Windows、Linux 或 Web 平台时还要注意项目设置中的主场景是否指向 Main.tscn。如果主场景为空导出后运行只会出现空白窗口。6. 三个最容易翻车的坑插件、球面重力和版本兼容AI 辅助开发唯一的确定性是你会遇到超出预料的错误。下面三个坑在独立开发环境中非常典型。6.1 Ziva 插件面板不显示或网络状态异常现象是插件启用后编辑器没有出现对应的 AI 面板或者面板打开后一直在转圈没有任何输出。排查顺序检查输出面板有没有插件报错。检查项目根目录下是否存在addons/ziva_plugin/plugin.cfg。检查插件是否启用了但需要重启编辑器。检查插件依赖的网络服务是否可达是否配置了正确的模型服务地址和 API Key。如果插件需要 API Key不要直接在提示词里写明文密钥。先配置到环境变量在插件设置中引用环境变量名称。这类“装好但面板不显示”的问题不只发生在 Godot。在 IDEA、PyCharm、VS Code 等 IDE 的 AI 插件生态里也经常出现常见原因都是版本不匹配或插件目录结构不完整。6.2 角色在星球背面卡住或穿模现象是角色明明在星球上突然卡进地面或者从侧面被挤出去。常见原因有三个没有在每一帧更新up_direction导致碰撞系统仍按世界坐标检测地面。星球碰撞体是SphereShape但 Player 胶囊半径大于星球半径导致碰撞穿透。_align_with_planet中使用了旧朝向矩阵正交化后产生抖动干扰移动。检查方式是开启 Debug 碰撞形状观察角色与球面的接触状态。解决方法是在物理循环开头重新计算up_direction并把碰撞体尺寸改小把角色位置初始化为星球中心 法线 * 半径。6.3 AI 生成的 API 与 Godot 4.x 不匹配现象是 AI 给出了move_and_slide(velocity, Vector3.UP)这种 Godot 3.x 写法放在 4.x 中直接报错。Godot 4.x 中CharacterBody3D的移动 API 发生了明显变化Godot 3.xGodot 4.xmove_and_slide(velocity, Vector3.UP)velocity velocity; move_and_slide()is_on_floor()依赖参数is_on_floor()由up_direction决定gravity参数直接传入通常手动累加到velocityInput.is_action_pressed保持兼容但Input.get_vector更推荐遇到这类报错先把报错日志复制给 Claude Fable 5.1并要求它明确标注“这是 Godot 4.x 专用写法”。不要靠记忆猜测迁移规则。7. 让 AI 辅助开发更可控的工程习惯AI 插件能让代码生成变快但也会让代码失控变快。下面几个习惯会显著降低返工成本。7.1 给 AI 分层任务不要让它一口气写完整个游戏完整游戏涉及场景、物理、输入、UI、音效、状态机一次生成的结果很难兼容。更合理的做法是拆成小块第一层先生成球面重力相关的 Player.gd。第二层生成对象池管理逻辑。第三层生成了障碍物生成与碰撞信号。每完成一层都运行一次游戏验证。验证刚通过的代码才允许进入下一步。7.2 使用 Git 管理版本AI 生成代码前先提交AI 生成的代码不一定比老代码更好。如果改动后发现无法回退开发效率反而下降。推荐的操作顺序当前版本稳定后先提交一次 Git。让 AI 生成新功能或重构。运行测试。如果结果不理想使用git checkout -- scripts/Player.gd回滚。对于一个小项目这已经足够。生产项目建议增加分支和 Merge Request 审查流程。7.3 发布前检查清单发布原型前把下面清单过一遍[ ] 主场景是否指向 Main.tscn。[ ] 所有export属性是否在编辑器里正确赋值。[ ] Input Map 是否包含游戏用到的全部 action。[ ] 球面重力是否在不同纬度都能正常工作。[ ] 障碍物是否使用对象池并且没有泄漏节点。[ ] 碰撞体尺寸与 Mesh 是否匹配。[ ] 是否存在硬编码的绝对路径如res://写死。[ ] 游戏结束后能否暂停或重新开始。[ ] 导出平台上字体和界面布局是否正常。[ ] 是否处理了 Player 死亡后的场景重置。这个清单同样适用于后续版本迭代每次加新功能后都可以过一遍。8. 从跑酷原型继续扩展的方向到这里你已经完成了一个最小闭环角色站在星球表面能跑能跳障碍持续生成计分可用程序可导出。这只是一个起点。8.1 从一个星球变成多星球把星球数据从硬编码半径改为export再创建一个可切换星球边的管理逻辑。角色从一个星球跳到另一个星球时需要动态更新planet引用。实现思路是让 Player 记录当前所在的星球节点当进入另一个星球的引力范围时切换planet引用。这个机制可以用Area3D检测func _on_gravity_area_entered(area: Area3D) - void: var new_planet : area.get_parent() if new_planet: planet new_planet多星球会带来一个复杂问题多个星球的重力叠加。如果两个星球距离较近需要设计“哪个星球的引力更强”的判断规则。常见做法是选择最近星球作为唯一引力源避免叠加。8.2 增加更多跑酷机制当前原型只有一种障碍和一种跳跃。可以继续扩展双段跳跃。障碍物类型分为低矮型和空中型。星球表面随机生成能量道具。移动速度随分数提升难度递增。添加动画状态机让胶囊体在奔跑、跳跃、落地之间切换。这些扩展很适合继续交给 AI 辅助实现但每一次扩展都要先补测试场景。8.3 对新手的最后一个建议学习 Godot 最有效的方式是先把一个功能拆到最小再用 AI 生成代码。生成后不要急着合并先改参数观察变化再回看代码结构。星球跑酷是一个很好的练习项目因为它同时涉及 3D 物理、输入系统、对象管理和游戏状态任何一个环节出错都会提醒你AI 可以帮你写代码但理解代码背后为什么这样写才是你真正掌握这套引擎的方式。