基于MCP协议实现AI与Godot引擎深度集成：打造智能开发副驾驶

1. 项目概述：当AI助手遇见游戏引擎

最近在捣鼓Godot引擎，想看看能不能把现在火热的AI能力给整合进来，让开发流程更智能一些。我试过一些简单的脚本生成插件，但总觉得差点意思——它们大多是单向的、一次性的指令，比如“生成一个跳跃脚本”，然后给你一段代码就完事了。这就像你有个很厉害的助手，但每次只能问他一个问题，他回答完就消失了，没法进行持续的、有上下文的对话和协作。

直到我接触到了MCP（Model Context Protocol）协议，感觉眼前突然一亮。简单来说，MCP是一个标准化的协议，它定义了大语言模型（AI）如何与外部工具、数据源和服务进行安全、结构化的交互。你可以把它想象成AI的“USB接口”或“插件系统”。通过MCP，AI模型（比如Claude、GPT）不再是一个封闭的黑盒，它可以动态地发现、调用你本地的工具，读取项目文件，甚至操作软件界面，从而实现真正意义上的“深度集成”。

于是，Godot-MCP-Pro这个项目的想法就诞生了：基于MCP协议，在Godot引擎内部构建一个功能完备的MCP服务器（Server）。这样一来，像Claude Desktop、Cursor这类集成了MCP客户端的AI助手，就能直接与你的Godot编辑器对话。它不再仅仅是生成代码片段，而是可以理解你的整个项目结构，根据你的自然语言指令，执行诸如“在场景A中添加一个受重力影响的刚体”、“检查当前场景中所有未使用的材质资源”、“为这个角色控制器脚本添加一个二段跳功能并测试”等复杂操作。

这个项目适合所有使用Godot的开发者，无论你是独立游戏制作人想提升效率，还是团队希望引入AI辅助编码和设计。它解决的核心问题是打破AI与开发环境之间的壁垒，让AI从“代码建议者”升级为“项目协作者”。

2. 核心设计：为什么是MCP，以及如何架构

2.1 为什么选择MCP协议而非传统API？

在决定技术路线时，我对比了几种常见的AI集成方案。最直接的是用OpenAI API或本地LLM的API，在插件里直接发HTTP请求。但这种方式有几个硬伤：首先是上下文隔离，每次请求都是独立的，AI无法感知Godot编辑器内的实时状态（比如选中的节点、打开的脚本、控制台错误）。其次，功能扩展麻烦，每增加一个能力（如读取文件、执行命令），都需要重新设计插件与AI的通信格式。

而MCP协议完美地解决了这些问题。它的核心优势在于“动态工具发现”和“结构化数据流”。

1. 动态工具发现：我们的Godot-MCP-Server启动后，会向连接的AI客户端（如Claude）宣告：“嗨，我这里有这些工具可用：list_scene_nodes、get_script_code、run_in_editor...”。AI客户端在会话开始时就能拿到这份“工具菜单”，并能在对话中智能地决定何时调用哪个工具。我们后续添加新工具，AI无需任何更新就能自动获得新能力。

2. 结构化数据流：MCP使用JSON-RPC over stdio（标准输入输出）或SSE（服务器发送事件）。这意味着通信是双向、持续且结构化的。AI可以发起一个“调用工具”的请求，我们的Server执行后，将结果（成功或失败，附带详细数据）结构化地返回。AI可以基于这个结果进行下一步的推理和操作，形成一个闭环的工作流。

注意：选择stdio作为主要传输模式，是因为它最简单、最通用，无需处理网络端口和跨域问题，特别适合本地桌面应用集成。SSE模式则更适合需要从Web端远程连接的情况。

2.2 Godot-MCP-Pro 整体架构拆解

整个项目可以清晰地分为三层，我画个简单的框图在脑子里，这里用文字描述一下：

第一层：MCP传输层这是最底层，负责与AI客户端建立连接并处理MCP协议的基础消息。我们使用一个独立的线程或Thread来运行一个消息循环，持续监听来自stdin的JSON-RPC请求，并将处理结果写入stdout。这一层要严格遵循MCP协议规范，实现initialize、tools/list、tools/call、resources等核心方法。为了健壮性，必须加入完整的错误处理和超时机制，防止某个工具调用卡死导致整个通信链路瘫痪。

第二层：工具抽象层这是核心业务逻辑所在。我们将Godot编辑器能提供的所有能力，封装成一个个独立的“工具”（Tool）。每个工具都是一个GDScript类，它有一个明确的名称、描述、参数schema（遵循JSON Schema格式）和一个执行函数。例如：

• editor_get_selected_nodes: 获取当前编辑器中选中的节点路径列表。
• scene_open_and_select: 打开指定场景文件并选中某个节点。
• script_create_or_update: 创建新脚本或更新现有脚本内容。
• run_project: 启动游戏测试。
• resource_find_unused: 扫描项目，找出未被引用的资源。

这一层的关键设计在于工具的设计粒度。工具太粗（如make_game）会让AI无从下手；工具太细（如node_set_position_x）会导致交互繁琐。我的经验是，围绕Godot编辑器的核心工作流来设计：场景编辑、脚本编写、资源管理、项目构建、调试测试。每个工具应完成一个原子性的、有明确价值的操作。

第三层：Godot编辑器交互层这是实际执行操作的一层。工具层发出的指令，最终要通过Godot的EditorPlugin API、ClassDB、或直接执行GDScript代码来影响编辑器状态。这里挑战最大，因为Godot的编辑器API在GDScript中访问有一定限制，有些操作需要通过Engine.get_singleton(“EditorInterface”)获取编辑器单例，再调用其方法。有些高级操作，甚至需要利用Callable和Thread来避免阻塞主线程。

一个典型的调用链是这样的：AI客户端发送请求 -> 传输层解析 -> 路由到对应的工具函数 -> 工具函数调用Godot编辑器API执行操作 -> 将执行结果（成功/失败+数据）封装 -> 通过传输层返回给AI客户端。

3. 关键实现：从协议对接到工具开发

3.1 搭建MCP Server骨架

首先，我们需要在Godot中创建一个EditorPlugin，作为我们MCP服务的入口。这个插件在启动时，会尝试启动一个子进程（或者自身作为进程）来处理MCP通信。但更优雅的方式是，我们直接在插件内创建一个TCPServer或使用Thread来模拟stdio通信。为了方便和通用性，我选择了通过Godot的OS.execute或Thread配合管道来模拟标准输入输出。

核心的通信循环伪代码逻辑如下：

# 在某个线程中运行 var stdin = FileAccess.open(“user://mcp_stdin”, FileAccess.READ_WRITE) # 示例，实际需用管道 var stdout = FileAccess.open(“user://mcp_stdout”, FileAccess.READ_WRITE) while is_running: var line = stdin.get_line() if line.is_empty(): OS.delay_msec(10) continue var request: Dictionary = JSON.parse_string(line) if request.has(“method”): var response = handle_request(request) stdout.store_line(JSON.stringify(response)) stdout.flush() func handle_request(req: Dictionary) -> Dictionary: var method = req[“method”] var params = req.get(“params”, {}) var id = req.get(“id”, null) match method: “initialize”: return {“jsonrpc”: “2.0”, “id”: id, “result”: {“protocolVersion”: “2024-11-05”, “capabilities”: {}}} “tools/list”: var tools = [] for tool_name in registered_tools: var tool_def = _get_tool_definition(tool_name) # 返回包含name, description, inputSchema的工具定义 tools.append(tool_def) return {“jsonrpc”: “2.0”, “id”: id, “result”: {“tools”: tools}} “tools/call”: var tool_name = params[“name”] var tool_args = params.get(“arguments”, {}) # 调用具体的工具函数 var result = call_tool_function(tool_name, tool_args) return {“jsonrpc”: “2.0”, “id”: id, “result”: result} _: return {“jsonrpc”: “2.0”, “id”: id, “error”: {“code”: -32601, “message”: “Method not found”}}

实操心得：JSON-RPC的消息处理一定要做好异常捕获。Godot的JSON.parse_string在遇到格式错误时会直接报错崩溃，必须用if JSON.parse_string(line) is Dictionary这样的判断包裹。同时，每个工具调用都应用try-catch包裹，确保一个工具出错不会影响Server整体运行。

3.2 开发核心工具：以“智能场景修改”为例

让我们深入一个具体工具的实现，比如scene_add_node，它的功能是根据AI的描述，在指定场景的指定父节点下，创建一个新节点并配置基础属性。

首先，定义工具的描述和参数Schema，这决定了AI如何理解和使用这个工具：

func get_definition() -> Dictionary: return { “name”: “scene_add_node”, “description”: “在指定的场景和父节点路径下，添加一个新的Godot节点。可以指定节点类型、名称和初始属性。”, “inputSchema”: { “type”: “object”, “properties”: { “scene_path”: {“type”: “string”, “description”: “.tscn场景文件的资源路径，如 ‘res://levels/main.tscn‘”}, “parent_path”: {“type”: “string”, “description”: “父节点在场景中的路径，如 ‘/root/Main/World’。如果是空字符串，则添加到根节点。”}, “node_type”: {“type”: “string”, “description”: “要创建的节点类型，如 ‘Node2D‘, ‘Sprite2D‘, ‘RigidBody2D‘”}, “node_name”: {“type”: “string”, “description”: “新节点的名称”}, “properties”: {“type”: “object”, “description”: “可选，节点的初始属性键值对，如 {‘position’: Vector2(100, 200)}”} }, “required”: [“scene_path”, “node_type”] } }

接下来是工具的执行函数。这里面的坑最多：

func execute(args: Dictionary) -> Dictionary: var scene_path: String = args[“scene_path”] var node_type: String = args[“node_type”] var parent_path: String = args.get(“parent_path”, “”) var node_name: String = args.get(“node_name”, “”) var properties: Dictionary = args.get(“properties”, {}) # 1. 验证场景文件存在 if not ResourceLoader.exists(scene_path): return {“error”: {“code”: “FILE_NOT_FOUND”, “message”: “场景文件不存在: %s” % scene_path}} # 2. 加载场景PackedScene（注意：不能在非主线程直接加载？） # 这里需要小心！如果编辑器已经打开了这个场景，直接加载文件可能会与编辑器状态冲突。 # 更好的做法是：通过EditorInterface获取当前打开的编辑器实例。 var editor := Engine.get_singleton(“EditorInterface”) var edited_scene_root: Node = editor.get_edited_scene_root() # 判断目标场景是否就是当前打开的场景 var current_scene_path = editor.get_edited_scene().scene_file_path if editor.get_edited_scene() else “” if current_scene_path != scene_path: # 如果不是当前场景，我们需要通知AI，或者尝试打开该场景。 # 简单起见，先返回错误，要求用户先打开场景。 return {“error”: {“code”: “SCENE_NOT_OPEN”, “message”: “目标场景未在编辑器中打开。请先打开 ‘%s‘ 或使用 ‘scene_open‘ 工具。” % scene_path}} # 3. 在当前场景中查找父节点 var parent_node: Node = edited_scene_root if not parent_path.is_empty(): parent_node = edited_scene_root.get_node_or_null(NodePath(parent_path)) if not parent_node: return {“error”: {“code”: “NODE_NOT_FOUND”, “message”: “未找到父节点路径: %s” % parent_path}} # 4. 创建新节点实例 if not ClassDB.class_exists(node_type): return {“error”: {“code”: “INVALID_TYPE”, “message”: “无效的节点类型: %s” % node_type}} var new_node: Node = ClassDB.instantiate(node_type) if not new_node: return {“error”: {“code”: “INSTANTIATE_FAILED”, “message”: “无法实例化节点类型: %s” % node_type}} # 5. 设置节点名称和属性 if not node_name.is_empty(): new_node.name = node_name for key in properties: if new_node.has_property(key): new_node.set(key, properties[key]) else: # 记录警告，但不失败 print(“警告: 节点类型 %s 没有属性 ‘%s‘” % [node_type, key]) # 6. 将节点添加到场景（此操作必须在主线程进行！） # 这里涉及到Godot编辑器的线程安全。直接调用add_child会失败。 # 必须使用Callable.call_deferred或EditorInterface的API。 parent_node.call_deferred(“add_child”, new_node) new_node.owner = edited_scene_root # 设置owner以便保存 # 7. 在编辑器中选中新节点（可选，但用户体验好） editor.get_selection().call_deferred(“clear”) editor.get_selection().call_deferred(“add_node”, new_node) return { “success”: true, “message”: “节点创建成功”, “data”: { “node_path”: str(new_node.get_path()), “node_name”: new_node.name } }

这个工具的实现揭示了几个关键陷阱：

1. 线程安全：所有对Godot场景树和编辑器UI的操作，必须在主线程进行。MCP的消息循环如果在子线程，就必须用call_deferred或SceneTree的idle_frame信号来调度任务。
2. 编辑器状态管理：直接操作磁盘上的.tscn文件是危险的，应该始终通过EditorInterface操作当前加载的编辑器状态。
3. 错误处理粒度：不能一出错就整个工具崩溃。要区分“文件不存在”、“节点未找到”、“类型无效”等不同错误，并给出清晰的错误码和信息，方便AI理解并采取下一步（比如建议用户先打开场景）。

3.3 工具集的扩展策略

除了场景操作，一个完整的Godot-MCP-Server应该包含以下几类工具，我列出一些核心想法：

脚本与代码智能：

• script_analyze：分析指定脚本，返回函数列表、依赖关系、复杂度提示。
• script_refactor：根据AI建议，重命名变量、提取函数等简单重构。
• script_diagnose：运行GDScript Linter或静态检查，返回错误和警告。

资源管理：

• resource_import：指导AI如何正确导入一张图片（设置压缩模式、生成不同尺寸）或一个3D模型（生成碰撞体、LOD）。
• resource_audit：扫描整个项目，找出尺寸过大的纹理、未压缩的音频、重复的资源。

项目与构建：

• project_setting_get/set：读取或修改项目设置（如物理参数、输入映射）。
• build_and_run：执行指定平台的导出预设并运行。
• performance_profile：启动性能分析器，运行一段时间后，返回热点函数或资源消耗报告。

调试与测试：

• add_debug_print：在指定函数的开头智能插入带有上下文信息的print语句。
• create_unit_test：为选定的GDScript类生成一个基础的测试框架。

设计这些工具时，要时刻记住“AI友好性”。工具的描述要足够清晰，参数Schema要尽可能严谨（使用enum类型约束可选值），这样AI才能更准确地理解和使用它们。例如，resource_import的参数里，图片的压缩模式应该被定义为[“Lossless“, “Lossy“, “VRAM Compressed“]这样的枚举，而不是一个自由字符串。

4. 配置与实战：连接Claude Desktop进行真实对话

Server写好了，怎么用起来？这里以目前对MCP支持最好的Claude Desktop为例，展示完整的配置和实战流程。

4.1 配置Claude Desktop连接本地MCP Server

Claude Desktop允许通过一个claude_desktop_config.json配置文件来添加自定义的MCP服务器。我们的Godot-MCP-Pro插件需要提供一个稳定的、可执行的命令行接口。

第一步：在Godot插件中暴露命令行接口我们不能让Claude直接启动Godot编辑器，那样太重了。更优的方案是，我们的EditorPlugin在启动时，在后台默默启动一个轻量的、独立的MCP服务进程（可以用GDScript写，但更推荐用更快更稳定的语言如Python、Go或Rust编写一个守护进程，然后通过本地Socket与Godot插件通信）。这里为了简化，假设我们写了一个Python脚本godot_mcp_server.py作为桥梁。

在Godot插件的_enter_tree方法中：

func _enter_tree(): # 启动一个子进程，运行我们的Python MCP桥接服务器 var output = [] var exit_code = OS.execute(“python3”, [“res://addons/godot_mcp_pro/bridge/server.py”], output, true, false) if exit_code != 0: printerr(“Failed to start MCP bridge server:“, output)

第二步：创建Claude Desktop配置文件Claude Desktop的配置文件通常位于：

• macOS:~/Library/Application Support/Claude/claude_desktop_config.json
• Windows:%APPDATA%\Claude\claude_desktop_config.json
• Linux:~/.config/Claude/claude_desktop_config.json

我们需要创建或编辑这个文件，添加我们的服务器配置：

{ “mcpServers”: { “godot-editor”: { “command”: “python3”, “args”: [ “/绝对路径/到/你的/godot项目/addons/godot_mcp_pro/bridge/server.py” ], “env”: { “GODOT_PROJECT_PATH”: “/绝对路径/到/你的/godot项目” } } } }

第三步：重启Claude Desktop并验证保存配置文件后，完全重启Claude Desktop。在聊天界面，你应该能看到Claude的能力被扩展了。你可以直接问：“你现在有哪些和Godot相关的工具？” Claude应该能列出我们Server注册的所有工具。

4.2 实战对话示例与技巧

假设我们有一个简单的2D平台游戏项目，现在想添加一个会移动的敌人。

我的提示（自然语言）：

“我正在Godot里做一个2D游戏，当前打开了res://levels/world01.tscn场景。我想在‘Enemies’节点下添加一个‘MovingEnemy’节点，类型是CharacterBody2D。它应该有一个Sprite2D子节点显示敌人图片，还有一个CollisionShape2D子节点用于碰撞。图片用res://assets/enemy_slime.png。另外，请为这个MovingEnemy创建一个新的GDScript脚本，让它能在平台上来回巡逻。”

Claude（借助MCP工具）的思考与操作过程：

1. Claude理解我的意图后，首先会调用tools/list确认我有scene_add_node、script_create_or_update等工具。
2. 调用scene_add_node，参数为{“scene_path”: “res://levels/world01.tscn”, “parent_path”: “/root/World01/Enemies”, “node_type”: “CharacterBody2D”, “node_name”: “MovingEnemy”}。Server执行，在编辑器中创建节点。
3. 接着，Claude需要为这个新节点添加子节点。它可能会连续调用两次scene_add_node，分别创建Sprite2D和CollisionShape2D，并指定正确的parent_path（即第一步返回的node_path）。
4. 然后，Claude调用resource_get或类似工具，检查res://assets/enemy_slime.png是否存在，并可能调用resource_import确保其导入设置正确（比如设置为2D纹理）。
5. 调用scene_set_property工具，将Sprite2D节点的texture属性设置为那个图片资源。
6. 对于CollisionShape2D，需要设置其shape属性。Claude可能会先调用scene_add_node在根节点下创建一个临时的RectangleShape2D资源节点，配置好大小，然后将其赋值给碰撞形状，最后删除临时节点。或者，如果我们的工具集提供了create_collision_shape这样的高级工具，它会直接调用。
7. 最后，Claude调用script_create_or_update工具，为MovingEnemy节点创建脚本。它会生成类似以下的GDScript代码，并附上详细的注释：

extends CharacterBody2D @export var speed: float = 100.0 @export var move_distance: float = 200.0 var start_x: float var target_x: float var direction: int = 1 func _ready(): start_x = global_position.x target_x = start_x + move_distance # 初始化时面向移动方向 update_facing_direction() func _physics_process(delta): # 计算目标位置 var target_position = Vector2(target_x if direction > 0 else start_x, global_position.y) # 向目标位置移动 var movement = (target_position - global_position).normalized() * speed * delta var collision = move_and_collide(movement) # 如果撞到墙壁，或者接近目标点，则调头 if collision or global_position.distance_to(target_position) < 5.0: direction *= -1 update_facing_direction() # 更新下一个目标点 target_x = start_x if direction > 0 else start_x + move_distance func update_facing_direction(): # 根据方向翻转Sprite子节点（假设Sprite是第一个子节点） var sprite = get_child(0) as Sprite2D if sprite: sprite.flip_h = (direction < 0)

8. Claude可能会建议：“脚本已创建并附加。你需要我为你调整碰撞形状的大小以匹配精灵图吗？我可以调用scene_set_property工具。” 在获得你的确认后，它继续操作。

整个交互过程是对话式、迭代式的。AI不再是扔给你一段代码就结束，而是像一个真正的结对编程伙伴，理解上下文，执行操作，并询问下一步。这才是“深度集成”的魅力。

5. 性能优化、安全与边界思考

5.1 性能与稳定性保障

当工具集变得庞大，频繁的AI调用可能会对编辑器性能产生影响。以下是我在实践中总结的优化点：

1. 工具调用队列与限流：不要每一个AI请求都立刻执行。实现一个简单的任务队列，在主线程的_process或idle_frame中逐个处理。特别是文件操作、资源扫描等耗时工具，要设置为异步，并立即返回一个“任务已接收”的响应，等完成后通过SSE或另一个回调通知AI。避免阻塞MCP的通信线程。

2. 缓存机制：对于project_get_structure（获取项目文件树）这类频繁调用但数据变化不快的工具，实现缓存。可以设置缓存过期时间（如5秒），在有效期内直接返回缓存结果，大幅减少文件IO。

3. 资源加载优化：Godot加载大型资源（如高清纹理、复杂场景）是阻塞的。在工具中，如果只是需要资源的元信息（如路径、类型），应使用ResourceLoader.exists和ResourceLoader.get_resource_uid等轻量级API，避免完全加载Resource对象。

4. 日志与监控：为MCP Server添加详细的日志系统，记录每个工具的调用、参数、耗时和结果。这不仅能帮助调试，还能让你发现哪些工具是性能瓶颈。例如，如果resource_find_unused每次调用都耗时10秒以上，你可能需要考虑把它做成一个后台定时任务。

5.2 安全与权限的考量

让AI拥有操作你编辑器和项目文件的能力，听起来很强大，但也伴随着风险。必须建立安全边界：

1. 操作范围沙盒化：默认情况下，所有文件操作应限制在当前项目目录内（res://）。任何试图访问项目外文件（如user://是允许的，但系统目录）的操作，都应被明确拒绝或需要额外授权。可以在Server启动时，通过环境变量GODOT_PROJECT_PATH来界定安全边界。

2. 危险操作确认：对于删除文件（file_delete）、覆盖重要脚本、修改项目设置中的关键参数等操作，工具不应直接执行。可以设计为两阶段：第一阶段，工具返回一个详细的“预执行计划”给AI，由AI呈现给用户确认；第二阶段，在收到用户的明确确认指令（通过另一个工具调用或特定参数）后，再执行。或者，更简单粗暴一点，直接在Server层面禁止这类工具。

3. 操作回滚（Undo）集成：Godot编辑器有强大的撤销/重做栈。我们的工具在修改场景或资源时，必须利用EditorUndoRedoManager来创建操作。这样，用户随时可以按Ctrl+Z撤销AI做的一切更改。这不仅是安全网，也是符合用户习惯的体验。在工具函数中，应该这样写：

   var undo_redo = editor.get_undo_redo() undo_redo.create_action(“Add Node via AI”) undo_redo.add_do_method(parent_node, “add_child”, new_node) undo_redo.add_do_property(new_node, “owner”, edited_scene_root) undo_redo.add_undo_method(parent_node, “remove_child”, new_node) undo_redo.commit_action()

4. 会话隔离与上下文清理：确保一次AI会话中创建的一些临时节点或资源，在会话结束后能被正确清理，或者明确标记为临时状态，防止污染项目。

5.3 可能遇到的问题与排查清单

在实际使用中，你肯定会遇到各种问题。下面是一个快速排查清单：

一个我踩过的大坑：早期版本中，我让AI直接执行OS.execute(“git”, [“add”, “.”])这样的命令。这非常危险，且破坏了“操作可撤销”的原则。现在，所有需要调用外部命令的功能，都被封装成独立的、有明确描述和确认机制的工具，并且执行结果会详细返回给AI和用户。

6. 未来展望与生态想象

实现基础的MCP集成只是第一步。这个模式打开了巨大的想象空间，未来的扩展可以沿着这几个方向：

更智能的上下文感知：目前的工具调用还比较依赖AI的“猜测”。我们可以让Server更主动地提供上下文。例如，实现一个get_editor_context工具，主动向AI报告当前编辑器的焦点：正在编辑哪个脚本的第几行、场景中选中了哪些节点、控制台最新的错误是什么。这样AI的提议会更加精准。

学习与工作流固化：AI与用户的交互过程可以被记录和分析。比如，用户经常让AI“创建一个碰到玩家会爆炸的敌人”。几次之后，系统可以提示：“是否将这个‘爆炸敌人’的创建过程保存为一个可复用的‘模板工具’或‘宏’？” 未来，用户可以直接调用这个宏，快速生成变体。

多模型协作与专家系统：不同的AI模型可能擅长不同的领域。我们可以设计一个路由层，让Claude负责高级规划和自然语言理解，让Code Llama或专门的GDScript模型负责生成高质量代码，让一个视觉模型分析游戏截图并提出UI调整建议。MCP Server可以作为这些模型之间的协调者。

与引擎深度特性结合：集成Godot的实时多人编辑（EditorCollaboration）功能。想象一下，AI作为一个“协作者”出现在编辑会话中，其他团队成员可以实时看到AI正在进行的修改并提出建议。或者，利用Godot的信号系统，让AI可以订阅编辑器事件（如“节点被选中”、“脚本被保存”），从而在更合适的时机主动提供帮助。

这个项目的终极目标，不是创造一个替代开发者的AI，而是打造一个智能的、可扩展的、安全的开发者副驾驶系统。它深植于Godot引擎内部，理解项目的每一个细节，能够以开发者熟悉的对话方式，将繁琐、重复、探索性的任务自动化，让我们能更专注于真正创造性的游戏设计工作。