录这期视频的时候我特意把画质拉到了1080p——倒不是画面有多精美主要是操作过程里的细节实在太多码率低了根本看不清楚AI是怎么一步步操作Godot编辑器的。从最开始的让AI帮我写GDScript脚本到后来让AI通过MCP直接读取场景树、创建节点、挂载脚本再到沉淀出SKILL任务流程把整个功能模块一口气做完这条路我前前后后折腾了几个月。这篇博文就是那期视频的完整文字版我会把演进过程中的关键思路、每一步为什么会卡住、以及最终闭环的配置细节全部讲清楚。如果你正在用Godot做游戏开发并且想让AI真正参与到项目开发而非仅限于聊天对话这篇文章非常值得一看。我会从最基础的AI生成代码讲起解释为什么这条路走不远然后引出MCP协议接入、SKILL任务编排最后给出一个完整的AI自动搭建2D平台跳跃Demo的实操案例。中间穿插的所有坑都是我实际踩过的希望能帮你少走弯路。1. 起点AI写GDScript只是表层的第一站1.1 为什么从Godot开始做AI集成先交代背景。我当时正在用Godot 4开发一个2D小游戏团队就我一个人所有功能都得自己写。Godot的最大优势是轻量、启动快、GDScript容易上手但正因为它不像Unity和Unreal那样有庞大的商业生态很多AI辅助开发工具都是其他引擎优先支持的。我翻遍了市面上的AI编程工具和插件发现针对Godot的成熟方案屈指可数大多数人的用法还停留在把代码复制粘贴给ChatGPT改一改这个层面。我对这种交互方式非常不满意原因很直接。第一代码粘贴模式存在天然的上下文断层——AI根本看不到你的项目结构不知道你有哪些场景、哪些节点、哪些autoload单例。它生成的代码经常看起来没什么问题但一挂到真实项目里就跑不起来因为节点路径是错的、信号连接是断的。第二写代码只是开发流程里的一个小环节真正的时间都花在搭场景、调整参数、连信号、调试联调这些杂活上而AI在这些环节里完全帮不上忙。所以从一开始我的目标就不是让AI写更多的代码而是让AI成为能够操作Godot项目的开发助手。这个目标决定了后面所有的技术选型我需要让AI能够感知项目结构并且能够直接操作编辑器。这个想法在几个月前看上去还挺异想天开的直到我接触了MCP协议事情才开始有了转机。1.2 基础生成阶段直接用大模型写GDScript的体验与局限在折腾MCP之前我经历了一段相当漫长的基础生成阶段。当时的用法非常朴素选中当前正在写的脚本复制全部内容发给大模型然后附上一段中文描述比如帮我加一个二段跳功能或者重构这段移动逻辑让它支持斜坡。大模型确实能很快给出修改后的代码而且大部分时候语法是对的。但问题出在跑起来这个环节。我整理了一下这个阶段最常见的几类失败失败场景具体表现根因节点路径错误$Sprite2D运行时为空AI不知道实际场景树结构信号连接失败body_entered不触发AI只生成方法不负责连接信号API版本误用用了Godot 3的旧API模型训练数据滞后资源路径猜错load(res://sprite.png)找不到文件AI猜不到你的文件命名其中最让我崩溃的是节点路径问题。举个例子我让AI帮我在角色落地时播放一个尘土粒子特效。我的角色是Player粒子节点DustParticles已经存在挂载在Player节点下面。AI在生成了下面这行代码$DustParticles.emitting true先不说这行代码本身对不对关键问题是这个脚本挂载在哪个节点上如果挂在Player上那么$DustParticles指向的是Player/DustParticles没问题但如果挂在Player的子节点Visual上$DustParticles就会去找Visual/DustParticles结果必然是空引用。AI根本不知道脚本要挂在哪里更不知道节点之间的层级关系它只能在代码层面猜一个最合理的结果。这些失败案例让我意识到一个残酷的事实大模型的知识储备是够用的但知识不等于项目上下文。AI知道GDScript的所有语法但它不知道你的player.tscn里到底有几个子节点。这种上下文断裂靠复制粘贴代码是永远补不上的。必须找一个办法让AI能直接看到项目内部而不是隔着屏幕猜。2. 卡点复盘纯Prompt生成在真实项目里断在哪里2.1 上下文断裂AI不知道你的项目里有什么第1章最后提到的上下文断裂我想展开讲透因为这是所有AI辅助开发方案设计的最底层逻辑。先说一个最简单的例子。我让AI帮我实现UI血量条的更新逻辑它生成的代码是func update_health(value: int) - void: $ProgressBar.value value这段代码单独看完全正确但到了项目里就很难用。因为$ProgressBar这个路径取决于HUD脚本挂在哪个节点上。如果HUD挂在CanvasLayer下面血量条在MarginContainer/Panel/ProgressBar那路径就完全不对了。这种信息AI是拿不到的除非你告诉它或者它自己读.tscn文件。实际上一个典型的Godot项目里这类AI看不见的信息非常多当前场景的节点树结构每个节点上挂的脚本、资源路径autoload单例的名称和属性输入映射的动作名比如ui_jump是否可用项目的自定义碰撞层设置这些信息散落在.tscn文件、.godot项目配置、以及编辑器内部的运行时状态里。纯文本对话模式下AI只能靠猜猜的准确率在项目复杂度上来之后就直线下降。这不是模型不行而是输入信息不完整——任何人在信息不全的情况下做决策都会出错。2.2 结构性操作的缺失生成代码容易挂载场景难第二个断点更加隐蔽但同样致命即使AI生成的代码完全正确依然需要人来完成一系列结构性操作才能跑起来。创建节点、挂载脚本、连接信号、设置碰撞层、调整参数——这些操作在Godot里虽然不难但极其琐碎而且占据了开发时间的大头。我自己统计过一个功能模块从需求到跑通的时间分配编写代码逻辑约30%搭建节点结构约25%微调参数物理参数、碰撞层、动画过渡约25%调试联调约20%也就是说纯代码生成最多只能覆盖30%的工作量。剩下的70%发生在编辑器里发生在节点树和检视器中——这些是AI完全无法触及的领域。回想一下你平时搭一个功能节点的过程创建Node2D、改名、挂脚本、加子节点CollisionShape2D、画形状、调整碰撞层……每一步都要点好几次鼠标。这些操作有一个共同特征它们高度规则化、重复化。规则化的操作意味着完全可以标准化标准化的下一步就是自动化。当时我脑子里的自动化还很模糊但方向已经逐渐清晰能不能让AI直接操作编辑器替我完成这些结构性的搭建步骤这个想法在当时没有现成的方案直到我研究起MCP协议答案才慢慢浮现出来。3. 引入MCP把Godot编辑器变成AI的眼睛和手3.1 MCP到底是什么它解决了什么本质问题MCP全称是Model Context Protocol模型上下文协议。它最早由Anthropic提出并开源核心目的很朴素给AI模型和外部工具、数据源之间定义一个标准化的交互接口。用大白话说MCP就是AI世界的USB-C接口——不同设备编辑器、数据库、浏览器都可以通过这个统一标准接入AIAI不需要为每个设备单独学习一套奇怪的调用方式。这个协议之所以能火起来是因为它解决了一个非常本质的问题大模型的信息世界和现实世界的隔离。模型再聪明它也只是在思考一个截断的上下文它接触不到你的文件系统、你的编辑器状态、你的场景树。MCP相当于给AI开了一条通道让它通过标准化的工具调用去主动获取真实世界的数据并执行真实世界的操作。拆开来看MCP涉及两个角色MCP Server服务端暴露一组工具比如读取场景文件获取节点树创建节点修改属性。它是能力的提供方跑在你想让AI操作的那套系统里。MCP Client客户端AI模型通过客户端来调用这些工具。在日常使用中它一般承载在AI编程工具如Claude Code、Codex内部。对Godot来说我们需要的是一个能跑在Godot编辑器环境里的MCP Server把Godot编辑器的能力暴露给AI。这样AI可以从猜项目结构变成直接读取项目结构从生成文本代码变成直接创建真实节点。这一步是质变原因在于MCP为AI提供了结构化上下文。AI不再需要从一个被截断的对话历史里推断节点路径而是可以随时调用get_scene_tree工具获取实时、准确的场景数据。这可以说从根上解决了第2章描述的上下文断裂问题。3.2 Godot侧MCP Server的搭建与配置细节Godot社区里其实已经有人在做MCP Server的开源实现社区项目godot-mcp是我测试下来比较好用的一个。整体架构如下AI编程工具Claude Code / Codex / Cursor ↓ MCP协议 MCP Client ↓ 本地 HTTP / WebSocket Godot引擎内运行的 MCP ServerEditorPlugin 形式 ↓ 调用 EditorInterface / SceneTree Godot 编辑器配置过程大致分四步第一步安装MCP Server插件。把godot-mcp插件拷贝到项目的addons目录并在Godot中启用。第二步启动MCP Server。在Godot编辑器里通常是通过菜单栏或者自动加载的方式启动MCP Server它会监听本机的一个端口比如8765。第三步在AI工具中注册MCP服务。以Claude Code为例在项目配置文件中加入一行MCP服务的声明指向本地端口。第四步验证连接。启动AI工具询问它读取当前场景结构看它是否通过MCP成功获取到数据。这里有一个非常关键的实现细节MCP Server必须作为EditorPlugin运行而不是普通的场景脚本。因为只有EditorPlugin才有权限访问EditorInterface单例才能读取编辑器当前打开的场景、操作节点树、访问资源文件。我第一次配置时吃了大亏MCP Server进程起来了端口也监听了但AI调用工具时一直报编辑器未初始化查了半天才发现是插件继承错了基类。一个简化版的MCP Server核心逻辑长这样tool extends EditorPlugin var server: TCPServer var port : 8765 func _enter_tree() - void: server TCPServer.new() if server.listen(port) ! OK: push_error(MCP Server 端口 %d 被占用 % port) return print(MCP Server 已启动监听端口 %d % port) func _exit_tree() - void: server.stop() func _process(_delta: float) - void: if not server.is_connection_available(): return var conn : server.take_connection() var data : conn.get_utf8_string(conn.get_available_bytes()) var payload : JSON.parse_string(data) if payload and payload.has(action): var result : _dispatch_action(payload[action], payload.get(params, {})) conn.put_utf8_string(JSON.stringify(result)) func _dispatch_action(action: String, params: Dictionary) - Dictionary: match action: get_scene_tree: return {ok: true, data: _collect_scene_tree()} create_node: return {ok: true, data: _create_node(params)} attach_script: return {ok: true, data: _attach_script(params)} return {ok: false, error: unknown action: %s % action}注意这是为了讲清原理做的简化生产环境还需要考虑数据大小、请求排队、错误恢复、鉴权等一堆问题。社区项目里这些都已经处理好了所以我的建议是先用现成的开源实现跑通了再根据自己的需求定制。3.3 实测MCP模式下AI调用编辑器API的工作效果配置好之后我做的第一个验证实验是让AI读取当前场景结构。我打开了一个包含主角、地面、UI三个子系统的场景然后问AI当前场景里有哪些节点AI通过MCP调用get_scene_tree返回了类似这样的结构化数据{ root: Main, children: [ { name: Player, type: CharacterBody2D, position: [200, 300], children: [ {name: Sprite2D, type: Sprite2D}, {name: CollisionShape2D, type: CollisionShape2D} ] }, { name: Ground, type: StaticBody2D, position: [0, 500] }, {name: CanvasLayer, type: CanvasLayer} ] }这次AI的回答完全不一样了。它不再泛泛而谈而是准确地告诉我场景根节点是MainPlayer是一个CharacterBody2D下面挂着Sprite2D和CollisionShape2D。有了这些真实数据AI再写代码时节点路径几乎不会出错因为它不是猜的而是看到的。更关键的能力是写操作。我尝试让AI在场景中创建一个新的Area2D节点命名PickupArea并挂上一个拾取脚本。AI通过MCP依次调用create_node和attach_script我在编辑器里亲眼看到节点被自动创建脚本被自动挂上。那一刻我意识到一直以来的瓶颈被打破了——AI不再只是一个文本生成器它已经变成了能实际操作编辑器的助手。不过实验也暴露出一个新问题MCP工具调用是点状的AI一次只能做一个操作缺少任务级的统筹。我问它做一个金币拾取系统它可能会先创建节点然后停下来问下一步做什么因为没有人告诉它这个任务应该按什么步骤执行。这个缺陷需要靠SKILL层来补上。4. SKILL层从问一句答一句到有条理的执行任务4.1 为什么要区分MCP和SKILL聊到这儿可以给MCP和SKILL做一个清晰的定位区分了。MCP解决的是AI有没有能力操作编辑器的问题而SKILL解决的是AI清不清楚做某类任务的完整步骤的问题。打个比方可能更好理解MCP相当于给了AI一整套工具箱里面有扳手、螺丝刀、电钻但它不会告诉你修一台发动机应该先拆进气道还是先拆火花塞。SKILL就是那本老师傅传下来的工序手册里面写着第一步做什么、第二步做什么、每步做完检查什么。没有工具箱AI空有流程也动不了手没有工序手册AI拿着工具也不知道从哪儿下手。在我没引入SKILL之前AI的表现就像那种什么都会一点但做事没章法的新人你指一步它走一步你忘说了它就在那儿干等。而且它很容易在任务进行到一半时忘记最初的目标——比如创建完节点之后就开始纠结于节点的参数微调把完成整个拾取系统的目标抛到脑后。SKILL的引入就是为了给AI一个任务执行的骨架让它按流程走完而不是东一下西一下。4.2 SKILL的构成与落地实现SKILL的具体实现方式在不同的AI工具里略有差异但核心结构是共通的一个包含触发条件 角色定义 执行流程 校验标准的指令文件。在Claude Code和Cursor这类工具里我习惯在项目下维护一个.ai/skills/目录每一个Skill对应一个Markdown文件。典型的Skill文件长这样# Skill: godot-2d-platformer-module ## 触发场景 - 用户要求实现2D平台跳跃相关的功能模块 ## 角色与职责 你是资深Godot开发者负责从场景搭建到代码实现的完整功能开发。 ## 执行流程 1. 通过MCP调用 get_scene_tree 读取当前场景结构确认现有节点。 2. 规划所需节点层级列出新增节点的类型、名称、父子关系。 3. 调用 create_node 逐个创建节点每个节点创建后重新读取场景树验证。 4. 编写GDScript脚本用 write_script 写入项目并调用 attach_script 挂载。 5. 配置输入映射、碰撞层等必要属性。 6. 连接关键信号如 body_entered。 7. 自查重新读取场景树确认所有节点路径、脚本挂载、信号连接正确。 8. 输出执行报告注明完成项和未能完成项。这个文件本质上就是一份给AI的标准化作业程序。当用户的任务触发了这个Skill的触发场景AI就会把整个流程加载进自己的上下文然后按步骤执行。关键好处有两个一是AI不会漏步骤每做完一步它都知道下一步是什么二是AI会主动校验做完之后它会重新读取场景树检查节点是否有误而不是扔下一坨代码就不管了。我根据自己项目的实际需求沉淀了这些常用Skillgodot-2d-platformer-module2D平台跳跃功能模块godot-item-pickup物品拾取与背包交互godot-ai-npcNPC对话与行为逻辑godot-ui-hudHUD界面搭建与数据绑定写SKILL文件时有几个关键坑我不能不提。第一触发条件一定要明确不能写得模糊。如果Skill说用户提到游戏功能时触发那AI会把什么功能都往里面套结果就乱了要说清楚具体是哪类需求。第二每个步骤只做一件事步骤之间要有清晰的边界这能显著降低AI卡壳的概率。第三步骤里一定要有校验环节而且校验必须是可执行的也就是说需要用MCP工具去实际读数据不能只是在脑子里检查一下。4.3 闭环如何形成MCP负责能力SKILL负责流程当MCP和SKILL组合到一起一个感知—决策—执行—验证的闭环就形成了流程是这样的用户自然语言需求如做一个金币拾取系统 ↓ AI判定触发 SKILL加载任务执行流程 ↓ SKILL 指导 AI 调用 MCP 工具读场景树 → 规划结构 → 建节点 → 写脚本 → 挂脚本 → 连信号 ↓ MCP 实时返回编辑器真实状态AI 根据反馈推进下一步 ↓ 流程结束AI 自我校验并输出执行报告这个闭环里最核心的一点是MCP返回的实时状态数据是SKILL流程能够持续下去的燃料。AI每走一步都会先通过MCP看一眼编辑器现在的真实状态然后决定下一步动作。比如创建完PickupArea节点之后AI重新读取场景树确认路径Main/PickupArea确实存在——这个动作保证了它在后续挂载脚本时使用的是真实路径而不是猜测路径。感知和动作形成了正反馈循环AI在执行复杂任务时的稳定性大幅提升。我在跑通这个闭环后最大的感受是AI从工具变成了同事。我可以把一个小功能完整地交给它然后去处理别的事情过几分钟回来看结果。它会在做完之后告诉我创建了哪些节点、写了哪些脚本、信号连了没有、还剩哪一步没做。这种体验跟之间一句一句喂命令完全是两种工作方式。5. 完整闭环实战一次从零搭建2D平台跳跃Demo5.1 任务拆解与SKILL编排光说不练假把式。为了验证MCPSKILL闭环的真实效果我做了一次严格的自测从零开始只通过AI对话让AI在Godot中搭建一个最少功能的2D平台跳跃Demo。角色要有左右移动和跳跃能力有地面平台角色站上去能停稳到达目标区域后显示提示文字。整个过程中我不碰键盘鼠标去操作编辑器。动手之前我先做了三件事打开一个空的Godot 4项目把godot-mcp插件挂好启动MCP Server。在AI工具的配置里指向本地的MCP服务验证调用正常。在项目.ai/skills/目录下放好godot-2d-platformer-module这个Skill文件。然后我向AI发出了任务指令使用 godot-2d-platformer-module 这个 Skill在当前项目里搭建一个最小2D平台跳跃Demo。 要求角色可以左右移动和跳跃有地面平台角色落在地面上能站住 到达目标点后显示提示文字。AI收到指令后开始激活Skill并按照流程执行。5.2 过程中MCP返回真实场景数据的处理整个执行过程持续了大约5分钟。我全程盯着终端里AI的输出和后台的MCP日志记录下了几个关键节点。节点结构规划。AI先调用get_scene_tree读取当前场景发现根节点是Main但没有任何子节点。然后它在输出中给出了规划的节点结构Main (Node2D) ├── Player (CharacterBody2D) │ ├── CollisionShape2D │ └── Sprite2D ├── Ground (StaticBody2D) │ └── CollisionShape2D ├── GoalArea (Area2D) └── UI (CanvasLayer) └── Label这个结构规划本身没什么出奇的任何会Godot的开发者都能想出来。但关键在于它是基于真实场景状态做的决策——AI知道场景是空的所以从零搭建如果场景里已经有其他节点它就不会贸然往根节点塞东西而是会规划出一个合理的层级。逐步创建节点。AI调用create_node工具在Main下创建Player节点类型指定为CharacterBody2D位置设为(200, 300)。创建完Player之后它没有急着创建下一个节点而是先调用get_scene_tree查看一下结果。在日志里我能看到MCP返回的数据中确实出现了Main/Player然后AI才开始创建CollisionShape2D子节点。这个做一步查一步的习惯是写在SKILL里的——每次创建节点之后都必须重新读取场景树来校验路径。用中老年人打太极的话说这叫逢动必沉在AI执行流程里这就是逢建必查。没有这一步AI很容易在虚幻的逻辑里自我感觉良好但实际编辑器里根本没有这个节点。编写脚本并挂载。节点结构搭好后AI需要写角色控制脚本。它调用write_script工具把下面的GDScript写入player.gdextends CharacterBody2D const SPEED : 300.0 const JUMP_VELOCITY : -400.0 func _physics_process(delta: float) - void: if not is_on_floor(): velocity get_gravity() * delta if Input.is_action_just_pressed(ui_accept): velocity.y JUMP_VELOCITY var direction : Input.get_axis(ui_left, ui_right) if direction: velocity.x direction * SPEED else: velocity.x move_toward(velocity.x, 0, SPEED) move_and_slide()然后调用attach_script把它挂到Main/Player节点上。脚本本身很常规但注意这里有一个细节AI知道角色是CharacterBody2D所以使用了get_gravity()和move_and_slide()这套API在Godot 4.x里才是正确的。如果AI没有项目上下文很容易在版本API上翻车——我在基础生成阶段就吃过这个亏。信号连接。AI继续创建GoalAreaArea2D并连接到Player节点上的body_entered信号。它知道Player挂的脚本路径因此在脚本中补充了一段回调方法。然后AI创建了UI节点和Label用来显示到达终点的提示。自动校验。最后SKILL里的自查步骤生效。AI重新调用MCP读取了场景树核对Main/Player存在、player.gd已经挂在Player节点上、GoalArea存在且信号已连接。校验通过后输出了执行报告。5.3 最终效果与关键验证点这一次我从发出指令到AI报告完成大约只花了5分钟期间我没有打开Godot编辑器窗口。按F5运行游戏角色可以左右移动和跳跃能从地面跳上平台走到目标区域后屏幕上显示了提示文字——一个最小但完整的2D平台跳跃Demo跑通了。需要强调几个验证点这些是回避不了的关键指标节点路径完全正确player.gd中写的是$CollisionShape2D等相对路径而脚本挂载在Player节点上——这些依赖真实结构。AI因为每步都读了场景树所以全程没有出现路径错误。脚本API没有版本翻车get_gravity、move_and_slide都是Godot 4.x的正确用法。信号连接真实有效不是代码里写个connect关键字就完了AI是通过场景系统连接的真实信号所以运行时能触发。当然这个Demo本身很简单还不足以证明这套工作流在复杂项目中一定好用。但这是一次完整的、零人工干预的、从AI理解需求到编辑器最终状态改变的全流程验证。对我来说这就是技术路线可行的里程碑。6. 演进中的几处关键取舍与避坑建议6.1 工具链选型Godot版本、MCP Server实现方式先说版本问题。整个流程我使用的是Godot 4.x实测4.2及以上版本最稳定。Godot 3.x的编辑器脚本API和4.x差异非常大社区里现成的MCP插件也基本都面向4.x。如果你还在用3.x做项目想跑这套工作流的话我建议先规划一下是否值得升级到4.x。MCP Server的选择上有两个方向实现方式优势劣势适合场景社区开源MCP插件开箱即用、工具集完整、社区维护扩展新工具需要改插件代码大多数个人项目和验证阶段自研EditorPlugin HTTP服务完全可控、可以按项目深度定制工具开发周期长、需要理解EditorInterface有特定自动化需求的生产项目我的建议是先选第一种。不要一上来就自己写MCP Server至少在跑通第一条完整的读场景树→创建节点→挂脚本→连信号链路之前别碰自研。等你对这个协议的交互模式有了手感和体感之后再按需求扩展。6.2 权限边界与安全让AI操作编辑器要设置好护栏让AI直接操作编辑器这件事兴奋之余我还保持着一种警惕。因为AI一旦拥有写权限它就能删除节点、改坏属性、把场景文件搞乱。轻则让你返工重做重则把项目文件结构彻底搞乱。我给自己定了三条铁律也是想让所有试图走这条路的人都能提前知道的AI操作前项目必须处于Git干净状态。我专门写了一个MCP工具作用是创建一个新的Git提交。AI在开始修改场景之前会先调用它做个快照。万一改坏了git checkout一键恢复损失几乎为零。只读工具和写工具分离。把get_scene_tree、read_script这些只读操作和create_node、set_property、delete_node这些写操作分开。在调试和探索阶段我只开放只读工具给AI让它先把项目摸清楚确认理解没有偏差之后再打开写权限。限制操作范围。通过工具参数限制AI只能在特定路径下操作比如只能修改res://scenes/下的场景不能碰res://addons/里的插件代码。这能有效防止AI在一次错误判断中毁掉整个项目。除了这三条如果MCP Server监听的不只是localhost而是局域网地址务必加上Token验证。这已经不是效率的问题了是安全底线。6.3 我踩过的几个具体坑工具链跑起来之后坑并不会消失只是换了新的形态。我把最近踩过的几个典型问题列在下面给各位做个参考。坑一端口冲突。我的开发环境里有个工具也在监听8765端口导致MCP Server启动失败但因为没有日志提示我一开始完全没察觉。AI那边一直报connection refused我还以为是自己配置写错了。排查了半天才发现是端口被占。后来我给MCP Server加了启动日志端口绑定失败时立刻输出明确错误。如果你也遇到连接失败第一件事就是查端口。坑二编辑器热重载导致MCP断开。Godot在重载插件、切换场景或重新编译脚本时有可能会杀掉编辑器进程里的MCP Server。AI那边表现为突然无法调用工具过一段时间又自己恢复。这种时候别急着调配置先看看Godot是不是刚刚重载过。坑三tool脚本的初始化时机。把MCP Server的启动代码写在_ready()里是个大坑。因为tool脚本在编辑器加载时可能执行多次_ready导致重复绑定端口。我的做法是把启动逻辑放在_enter_tree()和_exit_tree()里并加一个幂等保护如果端口已经被绑定就不再重复启动。6.4 后续还可以往哪个方向扩展闭环跑通并不是终点反而是新问题的起点。目前我在探索的方向包括多场景协同操作。现在的MCP工具主要围绕当前打开的场景下一步想让AI能在多个场景之间批量操作比如一次创建一整排关卡节点。资源文件管理。让AI能导入、组织、重命名贴图和音频资源。这是游戏项目里最容易乱的部分如果AI能接管价值会非常大。SKILL版本管理。把Skill文件放进Git仓库每次AI执行完任务后记录结果积累一段时间后回头去优化SKILL里的步骤设计。SKILL不是一次性写好就不动了它需要跟着项目一起进化。做了这一整套东西之后我最大的体会是技术难点的天花板其实不在工具而在你有没有把自己的项目结构想清楚。AI能不能高效地操作你的编辑器很大程度上取决于你的项目结构是不是规整、节点命名是不是清晰、目录组织是不是有意义。换句话说你在教AI做事之前先得把自己做事的逻辑理顺。如果你发现AI执行任务的时候总是跑偏不妨回头审视一下自己的SKILL设计——大多数时候不是AI太笨是你的流程还不够清晰。最后再分享一个小技巧。如果你刚开始尝试MCPSKILL这套闭环别急着写那些复杂的Skill。先从一个最小的Skill开始比如读取场景树并输出节点清单跑通全链路。然后再做创建一个指定类型的节点等这两步都稳定了再扩张到从零搭建一个完整功能模块。步子迈小一点每走一步都把护栏建好这套工作流才能真正成为你开发流程里的一部分而不是一个华而不实的玩具。