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

1. 项目概述当AI助手遇见游戏引擎最近在捣鼓Godot引擎想看看能不能把现在火热的AI能力给整合进来让开发流程更智能一些。我试过一些简单的脚本生成插件但总觉得差点意思——它们大多是单向的、一次性的指令比如“生成一个跳跃脚本”然后给你一段代码就完事了。这就像你有个很厉害的助手但每次只能问他一个问题他回答完就消失了没法进行持续的、有上下文的对话和协作。直到我接触到了MCPModel Context Protocol协议感觉眼前突然一亮。简单来说MCP是一个标准化的协议它定义了大语言模型AI如何与外部工具、数据源和服务进行安全、结构化的交互。你可以把它想象成AI的“USB接口”或“插件系统”。通过MCPAI模型比如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协议完美地解决了这些问题。它的核心优势在于“动态工具发现”和“结构化数据流”。动态工具发现我们的Godot-MCP-Server启动后会向连接的AI客户端如Claude宣告“嗨我这里有这些工具可用list_scene_nodes、get_script_code、run_in_editor...”。AI客户端在会话开始时就能拿到这份“工具菜单”并能在对话中智能地决定何时调用哪个工具。我们后续添加新工具AI无需任何更新就能自动获得新能力。结构化数据流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 } }这个工具的实现揭示了几个关键陷阱线程安全所有对Godot场景树和编辑器UI的操作必须在主线程进行。MCP的消息循环如果在子线程就必须用call_deferred或SceneTree的idle_frame信号来调度任务。编辑器状态管理直接操作磁盘上的.tscn文件是危险的应该始终通过EditorInterface操作当前加载的编辑器状态。错误处理粒度不能一出错就整个工具崩溃。要区分“文件不存在”、“节点未找到”、“类型无效”等不同错误并给出清晰的错误码和信息方便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 ServerClaude 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.jsonWindows:%APPDATA%\Claude\claude_desktop_config.jsonLinux:~/.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工具的思考与操作过程Claude理解我的意图后首先会调用tools/list确认我有scene_add_node、script_create_or_update等工具。调用scene_add_node参数为{“scene_path”: “res://levels/world01.tscn”, “parent_path”: “/root/World01/Enemies”, “node_type”: “CharacterBody2D”, “node_name”: “MovingEnemy”}。Server执行在编辑器中创建节点。接着Claude需要为这个新节点添加子节点。它可能会连续调用两次scene_add_node分别创建Sprite2D和CollisionShape2D并指定正确的parent_path即第一步返回的node_path。然后Claude调用resource_get或类似工具检查res://assets/enemy_slime.png是否存在并可能调用resource_import确保其导入设置正确比如设置为2D纹理。调用scene_set_property工具将Sprite2D节点的texture属性设置为那个图片资源。对于CollisionShape2D需要设置其shape属性。Claude可能会先调用scene_add_node在根节点下创建一个临时的RectangleShape2D资源节点配置好大小然后将其赋值给碰撞形状最后删除临时节点。或者如果我们的工具集提供了create_collision_shape这样的高级工具它会直接调用。最后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)Claude可能会建议“脚本已创建并附加。你需要我为你调整碰撞形状的大小以匹配精灵图吗我可以调用scene_set_property工具。” 在获得你的确认后它继续操作。整个交互过程是对话式、迭代式的。AI不再是扔给你一段代码就结束而是像一个真正的结对编程伙伴理解上下文执行操作并询问下一步。这才是“深度集成”的魅力。5. 性能优化、安全与边界思考5.1 性能与稳定性保障当工具集变得庞大频繁的AI调用可能会对编辑器性能产生影响。以下是我在实践中总结的优化点工具调用队列与限流不要每一个AI请求都立刻执行。实现一个简单的任务队列在主线程的_process或idle_frame中逐个处理。特别是文件操作、资源扫描等耗时工具要设置为异步并立即返回一个“任务已接收”的响应等完成后通过SSE或另一个回调通知AI。避免阻塞MCP的通信线程。缓存机制对于project_get_structure获取项目文件树这类频繁调用但数据变化不快的工具实现缓存。可以设置缓存过期时间如5秒在有效期内直接返回缓存结果大幅减少文件IO。资源加载优化Godot加载大型资源如高清纹理、复杂场景是阻塞的。在工具中如果只是需要资源的元信息如路径、类型应使用ResourceLoader.exists和ResourceLoader.get_resource_uid等轻量级API避免完全加载Resource对象。日志与监控为MCP Server添加详细的日志系统记录每个工具的调用、参数、耗时和结果。这不仅能帮助调试还能让你发现哪些工具是性能瓶颈。例如如果resource_find_unused每次调用都耗时10秒以上你可能需要考虑把它做成一个后台定时任务。5.2 安全与权限的考量让AI拥有操作你编辑器和项目文件的能力听起来很强大但也伴随着风险。必须建立安全边界操作范围沙盒化默认情况下所有文件操作应限制在当前项目目录内res://。任何试图访问项目外文件如user://是允许的但系统目录的操作都应被明确拒绝或需要额外授权。可以在Server启动时通过环境变量GODOT_PROJECT_PATH来界定安全边界。危险操作确认对于删除文件file_delete、覆盖重要脚本、修改项目设置中的关键参数等操作工具不应直接执行。可以设计为两阶段第一阶段工具返回一个详细的“预执行计划”给AI由AI呈现给用户确认第二阶段在收到用户的明确确认指令通过另一个工具调用或特定参数后再执行。或者更简单粗暴一点直接在Server层面禁止这类工具。操作回滚Undo集成Godot编辑器有强大的撤销/重做栈。我们的工具在修改场景或资源时必须利用EditorUndoRedoManager来创建操作。这样用户随时可以按CtrlZ撤销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()会话隔离与上下文清理确保一次AI会话中创建的一些临时节点或资源在会话结束后能被正确清理或者明确标记为临时状态防止污染项目。5.3 可能遇到的问题与排查清单在实际使用中你肯定会遇到各种问题。下面是一个快速排查清单问题现象可能原因排查步骤Claude无法识别Godot工具1. MCP Server未启动。2. Claude配置错误。3. 协议版本不兼容。1. 检查Godot编辑器控制台看插件日志是否有错误。2. 检查claude_desktop_config.json格式和路径是否正确。3. 重启Claude Desktop在聊天框输入/debug查看MCP连接状态。工具调用超时或无响应1. 工具函数执行卡死如死循环。2. 主线程被阻塞。3. Stdio管道堵塞。1. 为每个工具调用设置超时如5秒。2. 检查工具中是否有同步的耗时操作如大文件读取改为异步。3. 确保所有向stdout的写入后都调用了flush()。AI生成的指令参数错误1. 工具描述不够清晰。2. 参数Schema太宽松。1. 优化工具描述使用更具体、无歧义的语言。2. 收紧参数Schema多用enum、pattern正则约束字符串格式。编辑器操作成功但场景未保存操作未加入撤销栈或未标记场景为脏。确保所有修改场景的操作都通过EditorUndoRedoManager进行它会自动处理脏状态。部分编辑器API调用失败在非主线程调用了UI相关API。将所有调用EditorInterface、SceneTree、节点操作的方法用call_deferred包装。资源路径识别错误AI使用了绝对路径或错误的相对路径。在工具中对传入的路径参数进行规范化处理统一转换为以res://或user://开头的Godot资源路径。一个我踩过的大坑早期版本中我让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引擎内部理解项目的每一个细节能够以开发者熟悉的对话方式将繁琐、重复、探索性的任务自动化让我们能更专注于真正创造性的游戏设计工作。