“用 AI 做游戏”这件事听起来很科幻但真正上手之后你会发现它比想象中更接近“生产力工具”而不是“自动生成器”。尤其是当 Godot 游戏引擎遇到 MCP 协议之后AI 不再只是帮你写一段孤立的代码而是可以真正“接手”一个项目读取文件、创建脚本、补全配置、检查报错。本文就围绕一个非常具体的场景展开用 AI 配合 Godot MCP从零开始制作一款超级英雄游戏并顺带聊聊不同 AI 模型Opus 5、Kimi K3、GPT Sol 等在同一套工作流里的表现差异。这篇文章适合三类读者一是想用 AI 提升游戏开发效率的独立开发者二是刚开始接触 Godot 的新手三是对 MCP 协议与 AI Agent 工作流感兴趣的技术爱好者。文中会给出完整的项目结构、可运行的 GDScript 代码、MCP 服务搭建思路以及一套不需要“迷信某个模型”的横向评测方法。读完之后你不仅能照着手搓一个超级英雄 Demo还能沉淀出一套适合自己的“AI 辅助游戏开发”流程。1. 背景与核心概念为什么 Godot 和 MCP 是绝配1.1 游戏开发的真实痛点游戏开发从来不是“写代码”这么简单。一个最小的可玩 Demo往往包含场景组织、节点树设计、资源导入、输入映射、碰撞检测、UI 状态、音效播放等大量琐碎环节。哪怕用 Godot 这种以“简洁”著称的引擎新手依然会卡在“为什么脚本没生效”“为什么场景一片空白”“为什么节点找不到”这类问题上。过去我们解决这些问题主要靠搜索引擎或官方文档。但 AI 出来后开发方式发生了变化AI 能直接看懂代码、解释报错、生成脚本。问题在于——AI 默认情况下是“无状态的”它看不到你项目里的文件结构也不知道你 node 树里到底挂了什么。你让它写一个player.gd它写得再漂亮也可能因为没绑对节点、没导出变量、没配置输入动作而无法运行。MCPModel Context Protocol模型上下文协议解决的正是这个“上下文缺失”的问题。它像一个接口层让 AI 可以访问外部工具和资源比如某个目录下的文件、某个项目的代码、某个数据库里的数据。对于 Godot 项目来说这意味着 AI 可以真正“打开你的项目”看你的目录结构、读你的脚本、写新的代码文件甚至帮你补全场景配置。1.2 MCP 是什么和普通 API 有什么区别MCP 是 Anthropic 在 2024 年底提出的开放协议目标是标准化“AI 模型如何调用外部工具”。它的核心思想是让 AI 应用通过一个统一协议去连接不同的数据源和工具服务而不是每家各写一套插件系统。你可以这样类比常规 API 是“人去找接口”而 MCP 是“接口主动出现在 AI 面前”。AI 通过 MCP 客户端连接到 MCP 服务器服务器暴露出一系列工具toolsAI 根据任务需要决定调用哪些工具。整个过程对用户来说几乎是透明的。与普通 API 相比MCP 有几个明显优势维度普通 APIMCP 服务上下文感知需要手动把数据塞进 Prompt工具主动读取项目文件工具调用需要写大量胶水代码统一协议规范客户端自动发现复用性每个场景写一套同一套服务可被多个 AI 客户端复用安全边界靠业务代码控制可通过服务端权限设计限制能力放在 Godot 游戏开发场景里MCP 的价值就非常明显AI 需要频繁读取project.godot、.tscn场景文件、.gd脚本才能给出真正贴合项目的建议。如果只是把代码粘贴给 AI它很难理解项目的完整结构但通过 MCPAI 可以直接“看到”项目全貌。1.3 为什么选用 Godot 作为实操对象Godot 是开源、跨平台、轻量级的游戏引擎支持 GDScript、C#、VisualScript 等多种语言。相比 Unity 和 UnrealGodot 的项目文件结构更简单配置文件是基于文本的脚本与场景文件也易于被 AI 理解和修改。这为 AI 参与开发提供了天然的便利。更重要的是Godot 4.x 的节点体系对初学者非常友好场景即节点树脚本挂载在节点上场景之间的实例化关系清晰。这种设计让 AI 生成的代码更容易贴合实际项目也让“AI 生成-人工微调”的协作模式更容易落地。本文的实战部分会以一个完整的超级英雄游戏为例子把 Godot 的 2D 游戏基础能力和 MCP 的工具调用能力结合起来。你可以把它看成一条主线AI 负责生成框架和脚本人负责场景挂载和视觉微调MCP 则负责让 AI“看得见”项目文件。2. 环境准备与版本说明2.1 工具安装清单在开始实操之前需要先准备以下工具。版本信息不必纠结到具体小版本因为工具链在快速迭代重点把思路理顺。工具用途建议Godot 4.x游戏开发主引擎推荐 4.2 以上稳定版优先Python 3.x构建 MCP Server至少 3.10 以上MCP SDK / FastMCP编写 MCP 服务按官方文档安装最新版任意 MCP 客户端连接 AI 模型Claude Desktop、Codex、Cursor 等一个 AI 模型账号执行代码生成Opus 5、Kimi K3、GPT Sol 均可我在本文示例中使用的是 Windows Godot 4.x Python 3 的环境但这套流程在 macOS、Linux 上也同样适用。关键是理解“MCP Server 如何暴露出工具”“AI 如何通过 MCP 读写项目文件”这两个核心链路。2.2 创建 Godot 项目打开 Godot 项目管理器新建一个项目项目名称可以叫SuperHeroMCP。渲染器选择 Forward 或 Mobile 都可以2D 游戏对渲染要求不高。创建完成后项目目录下会自动生成project.godot文件这是 Godot 项目的核心配置文件。为了让项目结构清晰建议手动创建以下目录SuperHeroMCP/ ├── project.godot ├── scenes/ # 场景文件 ├── scripts/ # GDScript 脚本 └── assets/ # 图片与音频资源这个阶段可以先不手动创建脚本。后面通过 MCP 服务让 AI 来帮你生成这些文件正好可以验证 MCP 是否真的“能写”。2.3 安装 MCP 相关依赖MCP 服务的实现方式有很多种。这里我选择用 Python 编写因为 Python 在快速原型和文件操作方面非常方便。先创建一个虚拟环境并安装依赖# 在项目根目录下创建虚拟环境 python -m venv .venv # 激活虚拟环境Windows .venv\Scripts\activate # 激活虚拟环境macOS / Linux source .venv/bin/activate # 安装 MCP 相关依赖 pip install mcp fastmcp说明一下mcp是官方 SDKfastmcp是社区封装目的是简化工具注册过程。不同版本的方法名可能有差异如果你的版本更新请以官方文档为准。核心思路是不变的用装饰器注册工具让 MCP 客户端能发现并调用这些工具。3. 核心原理MCP 如何驱动 Godot 开发3.1 MCP 三层架构MCP 的整体架构可以拆成三层MCP Client客户端运行在 AI 模型所在的应用程序中例如 Claude Desktop、Codex CLI 等。客户端负责把 AI 的工具调用请求发送给服务器。MCP Server服务器连接数据和工具的桥梁。对于游戏开发场景服务器可以封装“文件读写”“目录扫描”“命令行执行”等工具。AI Model模型根据用户指令和当前对话上下文判断要调用哪个工具并解释工具返回的结果。以“AI 创建 player.gd”为例完整链路是这样的用户给 AI 发指令 ↓ AI 发现 MCP 工具中存在 create_gdscript ↓ AI 调用 create_gdscript(file_pathscripts/player.gd, content...) ↓ MCP Server 执行文件写入 ↓ 返回“写入成功” ↓ AI 向用户展示代码和后续步骤整个过程中AI 不再“盲写”而是真正把代码写进了你的项目目录。人需要做的是在编辑器里把脚本挂载到对应节点或者让 MCP Server 提供更多场景修改能力。3.2 最小可用的 MCP Server 示例下面这个 MCP Server 示例暴露了两个工具create_gdscript用于创建或覆盖 GDScript 文件read_file用于读取项目文件。这是整个 AI 辅助游戏开发的最小闭环AI 能读、能写。# 文件路径mcp_server.py # 说明这是一个最小可用的 MCP Server 骨架用于给 AI 提供 Godot 项目文件读写能力。 # 注意不同版本的 FastMCP 或 mcp 包在 API 上可能略有差异请以官方 SDK 文档为准。 from fastmcp import FastMCP # 创建 MCP Server 实例 mcp FastMCP(godot-assistant) mcp.tool() def create_gdscript(file_path: str, content: str) - str: 在 Godot 项目中创建或覆盖一个 GDScript 文件。 Args: file_path: 相对项目根目录的脚本路径例如 scripts/player.gd content: 完整的 GDScript 代码内容 # 在真实项目中建议做路径安全校验防止 AI 写入项目目录之外 with open(file_path, w, encodingutf-8) as f: f.write(content) return f成功写入 {file_path} mcp.tool() def read_file(file_path: str) - str: 读取 Godot 项目中的任意文本文件。 Args: file_path: 相对项目根目录的文件路径例如 project.godot try: with open(file_path, r, encodingutf-8) as f: return f.read() except FileNotFoundError: return f错误文件 {file_path} 不存在请先检查项目目录 if __name__ __main__: # 启动 MCP Server mcp.run()这段代码看起来很简单但它已经具备了一个 MCP Server 的基本形态通过装饰器注册工具工具函数有参数说明和返回值。AI 模型在连接上这个服务器后会通过工具描述来决定何时调用、传入什么参数。需要注意mcp.run()在不同 SDK 版本中可能需要指定transport参数例如stdio模式。一般命令行客户端默认使用 stdio 标准输入输出通信所以大多数情况下直接运行即可。如果你使用的是其他协议需要按官方文档调整。3.3 在 AI 客户端中配置 MCP不同 AI 客户端的配置方式不同。以常见的桌面客户端或 CLI 工具为例一般都需要在配置文件中声明 MCP Server 的启动命令。下面是一个通用的 JSON 配置片段{ mcpServers: { godot-assistant: { command: python, args: [mcp_server.py], cwd: D:/Projects/SuperHeroMCP } } }配置完成后重启 AI 客户端它就能自动发现godot-assistant服务所提供的工具。之后你在对话里发出“帮我创建玩家脚本”之类的指令模型就会尝试调用 MCP 工具而不是仅仅输出一段代码文本。这里有一个很实用的经验与其让 AI 直接生成所有代码不如先让 AI 通过read_file观察项目结构再规划要创建哪些文件。这样能让 AI 的输出更贴合项目现状。4. 完整实战AI 制作超级英雄游戏4.1 任务拆解与需求定义在动手之前先定义一个明确的目标我们要做一个“超级英雄”2D 小游戏包含英雄的移动、发射激光子弹、敌人接近并攻击、英雄掉血、UI 显示血量这几个核心模块。为了控制篇幅这里不会涉及复杂的动画资源而是用 Godot 内置的多边形图形或占位精灵来替代美术素材。实际给 AI 的 Prompt 可以这样写你是一名资深 Godot 4 游戏开发工程师。请帮助我在当前项目中制作一个超级英雄 2D Demo。 项目要求 1. 英雄是一个可移动的圆形角色使用 WASD 或方向键移动。 2. 英雄可以发射激光子弹子弹为小型矩形。 3. 敌人会从右侧生成并向英雄移动碰到英雄会造成伤害。 4. 英雄有生命值生命值归零时游戏结束并打印日志。 5. UI 需要显示英雄的当前生命值。 输出要求 - 先读取项目目录结构确认 project.godot 是否存在。 - 创建 scripts/player.gd、scripts/bullet.gd、scripts/enemy.gd。 - 说明这些脚本应该挂在什么类型的节点上。 - 如果存在脚本编译问题请说明可能原因。这个 Prompt 里有两个关键设计一是明确“先读取项目结构”这样 AI 会先去调用read_file形成对项目的初步感知二是要求“说明脚本挂载节点”因为 Godot 中脚本必须挂在正确的节点上才能正常运行这也是新手最容易踩的坑。4.2 生成玩家脚本下面是我在项目中实际使用并验证过的一版玩家脚本。它不依赖复杂的外部资源只要挂在一个CharacterBody2D节点上即可运行。# 文件路径scripts/player.gd # 挂在CharacterBody2D 节点 # 功能主角移动 发射激光子弹 extends CharacterBody2D export var move_speed: float 300.0 export var max_health: int 100 export var bullet_scene: PackedScene var health: int max_health func _ready() - void: # 将玩家加入 player 分组方便敌人查找 add_to_group(player) health max_health func _physics_process(_delta: float) - void: # 使用 Godot 内置的 ui_* 输入动作无需额外配置 InputMap 也可运行 var input_dir : Input.get_vector(ui_left, ui_right, ui_up, ui_down) velocity input_dir * move_speed move_and_slide() func _unhandled_input(event: InputEvent) - void: # 空格键发射子弹 if event.is_action_pressed(ui_accept): _shoot() func _shoot() - void: if bullet_scene null: print(警告未在 Inspector 中绑定 bullet_scene) return var bullet: Area2D bullet_scene.instantiate() bullet.global_position global_position Vector2(32, 0) bullet.direction Vector2.RIGHT get_tree().current_scene.add_child(bullet) func take_damage(amount: int) - void: health max(0, health - amount) print(英雄剩余血量: , health) if health 0: _die() func _die() - void: print(英雄倒下了游戏结束) queue_free()这段代码包含几个关键知识点export是 GDScript 中的导出变量可以在编辑器 Inspector 面板中直接赋值这也是让脚本复用性变强的重要机制。Input.get_vector会同时处理两个轴上的输入返回一个归一化方向向量。_unhandled_input用于捕获未被 UI 或节点消费的输入事件。bullet_scene作为PackedScene导出这样能在不同场景中复用同一个玩家脚本。4.3 生成子弹脚本子弹是一个Area2D它在物理帧中向右移动并在碰到敌人时触发伤害。这里需要注意Area2D检测的是“进入其区域的节点”与CharacterBody2D的碰撞行为不同适合用来做子弹、道具这类实体。# 文件路径scripts/bullet.gd # 挂在Area2D 节点 # 功能激光子弹飞行并造成伤害 extends Area2D export var speed: float 600.0 var direction: Vector2 Vector2.RIGHT func _ready() - void: # 连接 body_entered 信号避免在编辑器中手动连接 body_entered.connect(_on_body_entered) # 开启自动清理避免子弹长时间残留 var timer : get_tree().create_timer(3.0) timer.timeout.connect(queue_free) func _physics_process(_delta: float) - void: global_position direction * speed * _delta func _on_body_entered(body: Node2D) - void: # 如果碰到的是敌人调用其 take_damage 方法 if body.has_method(take_damage): body.take_damage(20) queue_free()为了让子弹场景可以复用建议在场景编辑器中创建一个Area2D挂一个Sprite2D或ColorRect作为可视化外形然后保存为scenes/bullet.tscn。把scripts/bullet.gd挂到根节点上这样玩家脚本中的bullet_scene就能引用它。4.4 生成敌人脚本敌人脚本的核心是“追踪玩家”。为了简化这里没有实现寻路算法而是直接用方向向量朝玩家移动。角色碰到敌人时敌人会自动扣除玩家生命值然后销毁自己。# 文件路径scripts/enemy.gd # 挂在CharacterBody2D 节点 # 功能追踪玩家并造成接触伤害 extends CharacterBody2D export var move_speed: float 100.0 export var damage: int 10 var player: Node2D func _ready() - void: # 通过分组查找玩家 player get_tree().get_first_node_in_group(player) func _physics_process(_delta: float) - void: if player null or not is_instance_valid(player): return var to_player: Vector2 global_position.direction_to(player.global_position) velocity to_player * move_speed move_and_slide() _check_touch_player() func _check_touch_player() - void: if player null or not is_instance_valid(player): return if global_position.distance_to(player.global_position) 24.0: if player.has_method(take_damage): player.take_damage(damage) queue_free()这里有一个容易被忽略的点get_tree().get_first_node_in_group(player)返回的可能是null所以在使用之前一定要判空。AI 生成的代码有时候会忽略这种边界条件导致运行时崩溃这也是为什么 AI 生成的代码必须经过人工 review 的原因之一。4.5 场景组织与挂载方式到这一步我们已经有了三个核心脚本。但它们还无法直接运行因为还没有创建场景、没有把脚本挂到节点上。在 Godot 中场景是脚本的载体。推荐的最小场景结构如下MainNode2D ├── PlayerCharacterBody2D │ └── CollisionShape2D用于物理碰撞 ├── EnemySpawnerNode负责定时生成敌人 └── CanvasLayer └── HealthLabelLabel显示生命值我在实际项目中通常会先把player.gd挂到一个CharacterBody2D节点上给节点添加一个CollisionShape2D然后保存为scenes/player.tscn。接着创建一个bullet.tscn把bullet.gd挂上给根节点加一个CollisionShape2D再在玩家场景的 Inspector 中把bullet_scene拖拽绑定到bullet.tscn。这一步属于“编辑器操作”AI 暂时无法完全替代。不过随着 MCP 工具链的完善未来也有可能通过脚本自动生成场景文件。这里保留人工环节反而能让你更清楚每个脚本是如何被场景调用的。如果你希望敌人自动生成可以再让 AI 写一个enemy_spawner.gd# 文件路径scripts/enemy_spawner.gd # 挂在Node 节点 # 功能每隔一定时间生成敌人 extends Node export var enemy_scene: PackedScene export var spawn_interval: float 2.0 export var spawn_position: Vector2 Vector2(400, 200) func _ready() - void: var timer : get_tree().create_timer(spawn_interval) timer.timeout.connect(_spawn_enemy) func _spawn_enemy() - void: if enemy_scene null: return var enemy: CharacterBody2D enemy_scene.instantiate() enemy.global_position spawn_position get_tree().current_scene.add_child(enemy) # 生成后递归调用实现循环生成 var timer : get_tree().create_timer(spawn_interval) timer.timeout.connect(_spawn_enemy)4.6 不同 AI 模型的横向评测方法标题里提到了 Opus 5、Kimi K3、GPT Sol 的“对决”。我不打算给出某种绝对结论因为模型版本更新太快今天的最佳选择随时可能被替代。更值得记录的是一套稳定的评测方法论你可以亲自去复现。我建议把任务拆分成三轮第一轮生成能力用同一个 Prompt 分别让三个模型生成完整的玩家、子弹、敌人脚本记录是否按要求生成了完整代码代码是否有明显的语法错误是否主动说明了文件路径和挂载节点是否使用了 Godot 4 的 API而不是 Godot 3第二轮修复能力人为制造一些错误例如把ui_accept输入动作改成不存在的动作让模型看代码并修复。观察是否能根据报错信息定位问题是否能结合项目上下文给出准确建议是否会在修复后主动补充验证方法第三轮项目整合能力让模型读取整个项目目录然后提一个需求例如“增加一个怪物刷新点”。观察是否先扫描了项目结构生成的代码与现有代码风格是否一致是否考虑了脚本与场景的挂载关系可以做一个简单的评分表按 1~5 分进行打分评测维度Opus 5Kimi K3GPT Sol代码完整性1-51-51-5语法正确性1-51-51-5上下文感知1-51-51-5调试修复能力1-51-51-5工程组织能力1-51-51-5之所以不写死分数是因为模型能力、Prompt 措辞、甚至网络状态都会影响结果。建议你自己跑一遍效果会更有说服力。5. 常见问题与排查思路在实际操作中最让人头大的往往不是“AI 不会写”而是“AI 写了但跑不起来”。这里整理几个高频问题。问题现象常见原因解决思路AI 生成的脚本在编辑器中报红色语法错误使用了不存在的 API或语法版本不匹配检查 GDScript 版本确认是 Godot 4.x 语法脚本挂上节点后没有任何反应没有配置输入动作或脚本未挂载到正确的节点类型检查 InputMap确认动作名与脚本一致子弹不移动bullet.gd没有挂到 Area2D 上或_physics_process未执行确认节点类型检查脚本是否被正确加载敌人无法找到玩家玩家没有加入 “player” 分组或玩家已被销毁在_ready中调用add_to_group(player)运行时报错parent node is busy setting up场景初始化顺序问题避免在_ready中直接操作其他未完成的节点使用call_deferredMCP 客户端连接不上 Server路径配置错误、Python 环境不对、依赖缺失先命令行手动运行python mcp_server.py验证是否有报错这里重点说一个 Godot 新手高频坑脚本挂到错误的节点类型上。Godot 中CharacterBody2D、RigidBody2D、Area2D、Node2D是不同的类型脚本通过extends CharacterBody2D声明了自己适用的节点类型。如果你把它挂到一个普通Node2D上编辑器虽然会提示但很多人会忽略最终导致move_and_slide()方法不存在运行时直接报错。所以拿到 AI 生成的代码后第一件事不是复制而是确认三点脚本的extends声明和我打算挂载的节点类型是否匹配。脚本中引用的所有输入动作是否已经配置到 InputMap。场景中必须存在的节点如bullet_scene、enemy_scene是否已在 Inspector 中绑定。6. 最佳实践与工程建议6.1 利用 MCP 建立“项目上下文”在 AI 游戏开发工作流里最容易提升效率的环节不是“生成代码”而是“让 AI 理解项目”。建议 MCP Server 至少暴露以下工具扫描项目目录结构。读取任意.gd、.tscn、.godot文件。创建或覆盖脚本文件。搜索项目中的关键字。执行 Godot 命令行编译检查例如godot --headless --check-only。项目根目录可以这样设计先把 AI 通过 MCP 生成的脚本统一放进scripts/目录再用read_file让 AI 查看project.godot。当 AI 知道项目里有什么、脚本之间如何依赖之后它生成的代码质量会明显提升。6.2 Prompt 设计的几个要点给 AI 的提示词不要只写一句“帮我做个游戏”。至少要包含引擎版本Godot 4.x 还是 Godot 3.x。节点类型脚本挂在哪种节点上。输入映射使用哪些动作名是否需要新建。资源路径脚本、场景、素材分别放在哪个目录。输出格式是只给代码还是同时给操作步骤。例如在 Godot 4 项目中为一个 CharacterBody2D 节点编写移动脚本。 输入动作使用 ui_left、ui_right、ui_up、ui_down。 移动速度为 250。 不要在脚本中加载外部资源。 输出完整 GDScript 代码并说明应该在编辑器中如何配置。这段 Prompt 的信息密度更高AI 生成的代码也会更靠谱。6.3 让 AI 做“小步提交”AI 的上下文窗口是有限的。与其一次让它生成整个游戏不如把一个大型任务拆成多个小任务每个任务生成一个或几个文件然后由人工快速 review 后再进入下一轮。举例来说第一轮生成玩家移动脚本。第二轮生成子弹脚本。第三轮生成敌人脚本。第四轮生成 UI 显示与游戏结束逻辑。第五轮整合测试。这种“小步快跑”的方式一方面能降低 bug 定位难度另一方面也方便使用 Git 做版本管理。每完成一个阶段就提交一次回滚成本会非常低。6.4 资源管理与资产组织虽然本文的 Demo 没有使用美术资源但如果你想继续扩展成更像样的游戏资源管理一定不能混乱。建议遵循 Godot 官方推荐的目录规范assets/ ├── sprites/ # 角色、物品、特效图片 ├── audio/ │ ├── bgm/ # 背景音乐 │ └── sfx/ # 音效 └── fonts/ # 字体同时善用 Godot 的autoload特性把全局状态例如玩家血量、关卡得分存到一个单例脚本里。这比让 AI 在每个节点脚本里各自维护状态要严谨得多。6.5 安全边界与工程红线在把 AI 接入真实项目时有几个安全边界必须重视不要让 MCP Server 无限制地写文件建议限定在项目目录内防止 AI 意外覆盖其他文件。不要把 API Key、数据库密码等敏感信息写进项目也不要让 AI 的脚本去读取项目外的敏感文件。涉及 Git 操作时最好由人来执行 commit 和 pushAI 只负责生成代码。生成代码后一定要进行语法检查和运行验证尤其是_die()等销毁类操作需要确认不会造成空引用。AI 是提效工具不是免责工具。所有交给 AI 生成的代码最终维护责任仍然在人身上。7. 总结与下一步这篇文章从环境搭建讲到 MCP Server 编写再到超级英雄游戏的角色移动、子弹攻击、敌人追踪、UI 概览完整覆盖了“AI Godot MCP”的最小可行开发链路。你可以发现AI 在整条链路里不只是“代码生成器”更像是一个能感知项目上下文的配对工程师。它负责把脚本写进正确的位置你负责场景挂载、资源调整和玩法设计。如果你看完之后想动手实践我建议按照下面的路线走先跑通最小的 MCP Server让 AI 能读能写项目文件。再让 AI 生成一个简单的玩家移动脚本手动在编辑器中挂载并运行。接着扩展子弹和敌人逻辑形成可玩的核心循环。最后才考虑加入资源、音效和完整 UI。这个过程中你可能会遇到模型版本差异、API 变动、场景挂载等一堆小问题但这恰恰是掌握这套工作流必经的路。不同 AI 模型的对决结果也只有在你自己环境里跑起来才真正有意义。如果这篇文章对你有帮助建议先收藏备用。后续我也会继续分享 Godot 与 AI 协作的进阶内容包括弹幕系统、资源热更新、以及如何进一步扩展 MCP 工具集。欢迎在评论区交流你在实操中遇到的问题也可以分享你使用不同 AI 模型生成代码的有趣经验。