企业官网建设流程全解析

“用 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，它写得再漂亮，也可能因为没绑对节点、没导出变量、没配置输入动作而无法运行。

MCP（Model Context Protocol，模型上下文协议）解决的正是这个“上下文缺失”的问题。它像一个接口层，让 AI 可以访问外部工具和资源，比如某个目录下的文件、某个项目的代码、某个数据库里的数据。对于 Godot 项目来说，这意味着 AI 可以真正“打开你的项目”，看你的目录结构、读你的脚本、写新的代码文件，甚至帮你补全场景配置。

1.2 MCP 是什么？和普通 API 有什么区别

MCP 是 Anthropic 在 2024 年底提出的开放协议，目标是标准化“AI 模型如何调用外部工具”。它的核心思想是让 AI 应用通过一个统一协议，去连接不同的数据源和工具服务，而不是每家各写一套插件系统。

你可以这样类比：常规 API 是“人去找接口”，而 MCP 是“接口主动出现在 AI 面前”。AI 通过 MCP 客户端连接到 MCP 服务器，服务器暴露出一系列工具（tools），AI 根据任务需要决定调用哪些工具。整个过程对用户来说几乎是透明的。

与普通 API 相比，MCP 有几个明显优势：

放在 Godot 游戏开发场景里，MCP 的价值就非常明显：AI 需要频繁读取project.godot、.tscn场景文件、.gd脚本，才能给出真正贴合项目的建议。如果只是把代码粘贴给 AI，它很难理解项目的完整结构；但通过 MCP，AI 可以直接“看到”项目全貌。

1.3 为什么选用 Godot 作为实操对象

Godot 是开源、跨平台、轻量级的游戏引擎，支持 GDScript、C#、VisualScript 等多种语言。相比 Unity 和 Unreal，Godot 的项目文件结构更简单，配置文件是基于文本的，脚本与场景文件也易于被 AI 理解和修改。这为 AI 参与开发提供了天然的便利。

更重要的是，Godot 4.x 的节点体系对初学者非常友好：场景即节点树，脚本挂载在节点上，场景之间的实例化关系清晰。这种设计让 AI 生成的代码更容易贴合实际项目，也让“AI 生成-人工微调”的协作模式更容易落地。

本文的实战部分，会以一个完整的超级英雄游戏为例子，把 Godot 的 2D 游戏基础能力和 MCP 的工具调用能力结合起来。你可以把它看成一条主线：AI 负责生成框架和脚本，人负责场景挂载和视觉微调，MCP 则负责让 AI“看得见”项目文件。

2. 环境准备与版本说明

2.1 工具安装清单

在开始实操之前，需要先准备以下工具。版本信息不必纠结到具体小版本，因为工具链在快速迭代，重点把思路理顺。

我在本文示例中使用的是 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是官方 SDK，fastmcp是社区封装，目的是简化工具注册过程。不同版本的方法名可能有差异，如果你的版本更新，请以官方文档为准。核心思路是不变的：用装饰器注册工具，让 MCP 客户端能发现并调用这些工具。

3. 核心原理：MCP 如何驱动 Godot 开发

3.1 MCP 三层架构

MCP 的整体架构可以拆成三层：

1. MCP Client（客户端）：运行在 AI 模型所在的应用程序中，例如 Claude Desktop、Codex CLI 等。客户端负责把 AI 的工具调用请求发送给服务器。
2. MCP Server（服务器）：连接数据和工具的桥梁。对于游戏开发场景，服务器可以封装“文件读写”“目录扫描”“命令行执行”等工具。
3. AI Model（模型）：根据用户指令和当前对话上下文，判断要调用哪个工具，并解释工具返回的结果。

以“AI 创建 player.gd”为例，完整链路是这样的：

用户给 AI 发指令 ↓ AI 发现 MCP 工具中存在 create_gdscript ↓ AI 调用 create_gdscript(file_path="scripts/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", encoding="utf-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", encoding="utf-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 中，场景是脚本的载体。

推荐的最小场景结构如下：

Main（Node2D） ├── Player（CharacterBody2D） │ └── CollisionShape2D（用于物理碰撞） ├── EnemySpawner（Node，负责定时生成敌人） └── CanvasLayer └── HealthLabel（Label，显示生命值）

我在实际项目中，通常会先把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 分进行打分：

之所以不写死分数，是因为模型能力、Prompt 措辞、甚至网络状态都会影响结果。建议你自己跑一遍，效果会更有说服力。

5. 常见问题与排查思路

在实际操作中，最让人头大的往往不是“AI 不会写”，而是“AI 写了但跑不起来”。这里整理几个高频问题。

这里重点说一个 Godot 新手高频坑：脚本挂到错误的节点类型上。Godot 中CharacterBody2D、RigidBody2D、Area2D、Node2D是不同的类型，脚本通过extends CharacterBody2D声明了自己适用的节点类型。如果你把它挂到一个普通Node2D上，编辑器虽然会提示，但很多人会忽略，最终导致move_and_slide()方法不存在，运行时直接报错。

所以拿到 AI 生成的代码后，第一件事不是复制，而是确认三点：

1. 脚本的extends声明和我打算挂载的节点类型是否匹配。
2. 脚本中引用的所有输入动作是否已经配置到 InputMap。
3. 场景中必须存在的节点（如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 后再进入下一轮。

举例来说：

1. 第一轮：生成玩家移动脚本。
2. 第二轮：生成子弹脚本。
3. 第三轮：生成敌人脚本。
4. 第四轮：生成 UI 显示与游戏结束逻辑。
5. 第五轮：整合测试。

这种“小步快跑”的方式，一方面能降低 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 和 push，AI 只负责生成代码。
• 生成代码后一定要进行语法检查和运行验证，尤其是_die()等销毁类操作，需要确认不会造成空引用。

AI 是提效工具，不是免责工具。所有交给 AI 生成的代码，最终维护责任仍然在人身上。

7. 总结与下一步

这篇文章从环境搭建讲到 MCP Server 编写，再到超级英雄游戏的角色移动、子弹攻击、敌人追踪、UI 概览，完整覆盖了“AI + Godot + MCP”的最小可行开发链路。你可以发现，AI 在整条链路里不只是“代码生成器”，更像是一个能感知项目上下文的配对工程师。它负责把脚本写进正确的位置，你负责场景挂载、资源调整和玩法设计。

如果你看完之后想动手实践，我建议按照下面的路线走：

1. 先跑通最小的 MCP Server，让 AI 能读能写项目文件。
2. 再让 AI 生成一个简单的玩家移动脚本，手动在编辑器中挂载并运行。
3. 接着扩展子弹和敌人逻辑，形成可玩的核心循环。
4. 最后才考虑加入资源、音效和完整 UI。

这个过程中，你可能会遇到模型版本差异、API 变动、场景挂载等一堆小问题，但这恰恰是掌握这套工作流必经的路。不同 AI 模型的对决结果，也只有在你自己环境里跑起来，才真正有意义。

如果这篇文章对你有帮助，建议先收藏备用。后续我也会继续分享 Godot 与 AI 协作的进阶内容，包括弹幕系统、资源热更新、以及如何进一步扩展 MCP 工具集。欢迎在评论区交流你在实操中遇到的问题，也可以分享你使用不同 AI 模型生成代码的有趣经验。