开篇先交代一下背景。我本来是个挺传统的Unity开发者，从Unity 4时代一路做到Unity 6，Blueprint和C#脚本写了好几年。但2025下半年开始，MCP这个词越来越高频地出现在我关注的工具链和CI/CD讨论里，一开始我以为是某种新的云服务协议，真正动手试用之后才发现——这东西改变的不只是开发流程，而是"人和游戏引擎对话"的方式。到了2026年，从Unity MCP到UnrealClaude，用自然语言直接驱动编辑器干活，已经成为我日常工作流里绕不开的一环。这套工具链的搭建过程、踩坑经历、选型心得，我觉得值得单独写一篇完整的实战记录，给正在观望或者刚开始折腾MCP工具链的朋友一个参考。
我这篇文章想讲清楚三件事：MCP协议在游戏引擎场景下到底怎么起作用；Unity和Unreal两大引擎分别怎么接入Claude这条工具链；以及我实际用下来的效率提升和坑。内容以Unity MCP和UnrealClaude为主，也会顺手提一下Claude Code的安装配置、MCP Server的搭建思路，还有几个网上讨论特别多的问题，比如UE的D3D Device Lost、内存溢出、Unity License失效这类。整体偏实操，跟着做基本能跑通。
1. MCP到底是什么：游戏引擎能听懂人话的底层机制
1.1 一句话说清MCP协议
MCP（Model Context Protocol）本质上是给大模型和外部工具之间搭的一座桥。你看Claude这类模型本身的能力边界在"对话"和"推理"，它没法直接操作你电脑上的文件、软件、引擎。但通过MCP协议，Claude就能调用一个个预先封装好的工具，比如"读取当前Unity场景里的所有GameObject""给某个Actor添加组件""搜索材质球并替换"。
我用一个比较生活化的类比：MCP Server像是给Claude配备的"手"，每个工具就是一根手指，而MCP协议规定了手指怎么动、动了之后怎么把结果反馈给大脑。没有这层协议的时候，你想让Claude帮你操作Unity，就得靠复制粘贴代码、手工导入导出、或者写一堆复杂的插件桥接。有了MCP，对话就是操作，自然语言就是指令。
这个协议本身是Anthropic在2024年底开源出来的一套标准，真正火爆其实是从2025年开始，各大编辑器、设计工具、数据平台陆续接入。游戏引擎这边，Unity和Unreal属于跟进比较快的，社区也出现了大量第三方MCP Server实现。到了2026年，"MCP"已经成了游戏AI工具链的一个基座协议，地位有点像前几年的"插件经济"。
1.2 为什么Unity和Unreal都需要MCP
很多人第一次听说MCP在游戏引擎里的应用，第一反应是"这不就是个自动化脚本工具吗，我以前用Python写Editor脚本、用蓝图封装工具函数也能达到类似效果"。这话对了一半，但忽略了一个核心差异：传统脚本是"人写逻辑给机器执行"，MCP工具链是"人和AI对话，AI理解意图后再调机器执行"。
举个具体场景。我以前做战斗系统优化，需要批量检查场景里所有挂载了Animator的角色，找出没有配置Avatar Mask的，再统一修复。如果用传统方式，我得打开编辑器，写一个EditorWindow，遍历场景、筛选、弹窗确认，前前后后怎么也得半小时。用MCP工具链，我只需要对Claude说"帮我把当前场景里所有带Animator但缺少Avatar Mask的对象列出来，然后批量加上默认的Mask"，几分钟搞定，而且我可以边看结果边追加修改条件，交互方式完全变了。
Unity和Unreal都需要MCP的原因，还在于这两款引擎自身都足够复杂、足够封闭，传统自动化方案的学习成本和维护成本都很高。Unity有完整的Editor Scripting API，Unreal有Python Editor Script Plugin和蓝图脚本，但这些都需要开发者专门去学。MCP把这个门槛大幅拉低了——你不必记住每一个API的确切名称和签名，只要描述清楚你想做什么，Claude会通过MCP Server帮你调用正确的接口。
另外一个很现实的原因是跨平台统一。我一个项目组里有人用Unity，有人用Unreal，如果都接入MCP，那AI辅助开发的这一层就可以做得非常统一。团队里其他人可能不会写复杂的Editor工具，但他们会跟Claude说"帮我做一个自动给所有Static Mesh设置碰撞预设的工具"，这个能力往前推两年根本不敢想。
1.3 2026年的工具链全景：Unity MCP、UnrealClaude、Claude Code的分工
目前我日常用的这套AI游戏MCP工具链，主要由三块组成：
第一块是Claude Code。这是Anthropic出的命令行AI编程工具，2025年推出后快速迭代，到2026年已经相当成熟。它可以在终端里直接读取项目文件、执行命令、修改代码，也支持配置MCP Server。无论你是用Unity还是Unreal，我都建议先把Claude Code装好，它是整个工具链的"中枢神经"。
第二块是Unity MCP Server。社区里有好几个实现方案，核心思路都是通过一个本地服务进程暴露Unity Editor的操作接口，Claude通过MCP协议连上去之后，就能读取场景、操作对象、调用菜单命令、执行C#脚本。我用的方案会在第2章详细讲，包括Python依赖、本地网络端口配置这些细节。
第三块是UnrealClaude。Unreal这边接入MCP的方式和Unity不太一样，因为UE没有Unity那么开放的C# Editor API，底层是C++和蓝图。UnrealClaude这类项目通常走的是Python Editor Script Plugin + MCP Server组合，或者在蓝图里直接搭一个MCP通信节点。第3章我会详细拆这个。
这三块各自干自己最擅长的事：Claude Code负责理解你的人类语言指令、调度工具；Unity MCP / Unreal MCP把指令翻译成引擎能执行的操作；引擎本身负责渲染、物理、资源管理等底层工作。配合起来，就是一套能听懂人话、能上手干活、还能实时反馈结果的游戏开发辅助系统。
2. Unity MCP实战：从环境准备到自然语言驱动场景
2.1 环境准备：Unity版本、Python依赖和网络配置
先说结论，如果你打算用Unity MCP工具链，Unity版本建议2022.3 LTS以上。我自己在Unity 2021.3上试过，虽然能跑，但部分MCP Server的实现依赖新版Editor的Scripting API，老版本会有接口缺失的问题。如果项目能升到Unity 6，体验会更好，因为Unity 6对Editor扩展和异步API的支持更完善，MCP Server跑起来明显更稳定。
Python环境也是必须的。大部分Unity MCP Server项目的控制端都是用Python写的，至少需要Python 3.10以上。我建议用conda或venv单独建一个虚拟环境，不要直接装到系统Python里，不然日后装其他包容易冲突。装依赖就一句话：pip install -r requirements.txt。如果你用的是我下面推荐的stormy-ua/mcp-unity这类方案，还会用到websockets、unityped这些库，用作Unity Editor和MCP Server之间的通信通道。
还有一个隐藏配置很多人会忽略——防火墙。MCP Server和Unity Editor之间要建立本地WebSocket连接，如果你的机器开了严格防火墙，Unity Editor的入站连接可能直接被拦，现象就是MCP Server显示连接成功，但Unity侧收不到任何指令。解决方法是把Unity Editor和Python进程都加入防火墙白名单，或者开发时直接用回环地址，不走防火墙过滤。
2.2 MCP Server搭建：选现成方案还是自己写
Unity MCP Server目前社区里没有唯一官方标准，我盘点一下主流的几条路。
第一条路，直接用现成的开源项目。stormy-ua/mcp-unity是我最先用的，支持Scene读取、GameObject操作、组件修改、Prefab管理，还有不少实用工具函数。安装方式很简单，把仓库里的com.stormy.unity-mcp包导入Unity，再用pip装好Python依赖，运行启动脚本就完事了。
第二条路，基于官方MCP SDK自己封装。如果你对Unity Editor API足够熟悉，想把MCP Server封装得更贴合自己项目的需求，可以用mcp Python SDK写一套自定义Server，通过Unity的HTTP或WebSocket接口中转指令。这种方法的好处是可控性高，能把你们项目自定义的编辑器工具也暴露给Claude用，坏处是开发和维护成本高。
第三条路，用Blender MCP的框架改。没错，Blender MCP在2025年社区里做得很成熟，后来有人把它的通信协议改一改，适配到了Unity上。这个方案的连接稳定性不错，但功能覆盖度不如专门的Unity MCP实现，适合只想要基础场景操作能力的场景。
我目前的生产环境是第一条路为主，第二条路为辅——用mcp-unity做日常操作，然后封装了一组自己的专用工具暴露给Claude，用来处理我们项目里的一些定制化编辑器逻辑。刚开始别贪大求全，先把现成方案跑通，后面再慢慢扩展。
2.3 用Claude Code连接：从安装到配置MCP Server
跑通Unity MCP的工具链，最后一个环节就是让Claude Code连上MCP Server。我先说Claude Code本身的安装，这块很多新手会卡。
Claude Code的安装现在走的是npm或原生安装器两条路。我推荐直接按官方文档来，在终端里执行安装命令后，会自动下载最新版本。装完之后你会发现它在终端里是一个交互式界面，可以直接对Claude说"读取当前目录下的某个脚本"或者"给我解释一下这个函数的逻辑"，但它默认没有操作Unity的能力，必须配置MCP Server。
配置方式很直接：在Claude Code的配置文件里加入MCP Server的启动命令即可。比如我的配置是这样的：
claude mcp add unity-mcp -- python /path/to/mcp-unity-server.py或者直接在配置文件里声明：
{ "mcpServers": { "unity-mcp": { "command": "python", "args": ["/path/to/mcp-unity-server.py"] } } }配置完重启Claude Code，你会在工具列表里看到Unity MCP暴露出的那些方法。验证是否连通的方法很简单：直接问Claude"当前场景里有哪些物体"，如果它把你场景里的GameObject列出来了，说明链路已经通了。
这里有一个值得注意的细节：Claude Code和MCP Server之间是本地通信，理论上不需要联网，但Claude Code本身的大模型推理还是需要网络请求的。所以你要确保网络畅通，而且API Key有效。如果你所在团队有内网部署的模型网关，也可以把Claude Code配置成走内部模型，但不在本文讨论范围内。
2.4 自然语言驱动Unity可以做的具体操作
我挑几个我项目里实际用得很频繁的操作，让大家感受一下这套工作流能干什么。
批量处理材质和贴图。以前美术给了一批新贴图，我需要批量替换场景里的旧材质。用MCP工具链，我只对Claude说"把Assets/Textures/Characters目录下的贴图对应替换到场景里所有角色的Body材质上，保持原有的平铺和偏移参数不变"。Claude会先列计划，再通过MCP Server逐批执行，中途有不确定的还会停下来问我。整个过程我只需要盯着看，基本不用动手。
编辑器操作和场景搭建。原型阶段我要快速搭一个测试场景，摆几个Cube、调一下灯光、加个简单的地面。以前至少拖拽好几分钟，现在直接一句话"帮我在当前场景里创建3个不同大小和颜色的Cube，摆成一个三角形，中间放一个点光源，颜色偏暖"。Unity MCP Server会把指令翻译成一次次的Editor API调用，我在编辑器里能实时看到对应操作。
UI构建和调试。热词里有人搜"unity 3dui 滚动选人""unity ui 动态画线"，这些其实都能通过MCP工具链去辅助实现。比如让Claude帮你生成一套3D滚动选人UI的框架代码，再调用Unity的UI接口创建对应节点，最后把Canvas参数调好。AI在生成代码上的能力大家已经很清楚了，关键是MCP让AI能直接把代码跑进编辑器、看见运行结果，然后根据结果继续调整——这个闭环才是真正提高效率的地方。
系统托盘和平台打包配置。还有人搜"在Unity中实现系统托盘"，这个需求在PC独立游戏里很常见。如果配好MCP，你可以让Claude查一下项目里是否引用了WinForms或相关原生插件，然后自动生成实现系统托盘图标的代码，编译并告诉你结果。打包方式也一样，把"minimum API level提升到API 35"这种Android构建需求丢给Claude，它能帮你改Player Settings并重新构建验证。
3. Unreal + Claude工具链：从安装UE5到UnrealClaude落地
3.1 UE5安装和一个高频崩溃问题排查
讲UnrealClaude之前，先说说UE5本身的安装和稳定性问题，因为很多人在第一步就被劝退了。
UE5的安装主要走Epic Games Launcher，也可以从源码自己编译。我建议绝大多数人直接装Launcher版本就行，省时省力，更新也方便。安装过程中有一个经常被吐槽的点——下载速度慢。这个往往和网络环境有关，国内用户尤其容易遇到。我个人建议选好版本后一次性下载完整包，不要中断，中断后再续传偶尔会碰到文件校验失败的情况。
装好之后，不少新手会遇到一个让人特别崩溃的报错：unreal engine is exiting due to d3d device being lost，翻译过来就是D3D设备丢失，引擎直接闪退。这个问题的原因通常是显卡驱动崩溃或GPU资源被过度占用。我排查的思路是：先更新显卡驱动，然后把UE的渲染器从DX12切到DX11（在Project Settings里改而不只是命令行），再关掉光追相关特性，基本能解决80%的情况。如果还不行，检查是不是超频导致的GPU不稳定，把超频恢复默认试试。
还有一个我遇到过的报错是unreal engine ran out of memory allocating 528384 bytes，这个看着吓人，其实内存分配才0.5MB。这通常是显存不足的表现，尤其是在场景资源很重、纹理串流池设置过大的情况下。解决办法是把RHI的Texture Streaming Pool Size调小（r.Streaming.PoolSize），或者减少场景里同时加载的高精度网格。
3.2 蓝图节点搭建MCP服务器：BP真的能做
聊完环境，进入Unreal侧的MCP搭建。很多人觉得MCP Server这种偏底层的通信组件，必须用C++写。但实际情况是，用蓝图（Blueprint）也能搭一个能用的MCP服务器，这正是社区里"BP搭建MCP服务器"这个方向被讨论的原因。
蓝图搭MCP的思路其实不复杂：用蓝图里的WebSocket节点创建一个本地WebSocket Server，然后接收外部传来的JSON格式指令，解析后调用Unreal的蓝图API做对应操作，最后把结果返回给客户端。难点在于指令解析和Unreal反射系统的对接——蓝图里处理JSON对象要做大量的类型转换，写起来比Python麻烦得多。
我尝试过的方案是先用蓝图搭一个简单的Echo服务验证连通性，后面再逐步加入关卡操作、Actor生成、蓝图变量读写等功能。如果团队里没有C++开发人力，或者你只是想快速验证MCP在UE里能跑通，蓝图方案完全够用。但如果想要完整的UnrealClaude体验，还是建议走Python Editor Script Plugin + MCP的组合，功能覆盖广很多，也更好维护。
3.3 UnrealClaude工具链与Cesium扩展案例
UnrealClaude代表的是一条更成熟的路线。它利用Unreal Python API（unreal.EditorAssetLibrary、unreal.EditorLevelLibrary这些模块）封装出一套MCP Server，让Claude能够读取资产列表、操作关卡Actor、修改组件属性、执行Python脚本。这样Claude不仅能做查询类工作，还能实际改动场景内容，配合Claude Code就能形成完整的"人-AI-引擎"闭环。
我在一个智慧城市可视化项目里把UnrealClaude和Cesium for Unreal做了结合，用来绘制地理围栏。传统流程是在Cesium场景里手动添加Geofence图层，或者用Cesium的C++ API编写绘制逻辑，学习成本很高。但有了UnrealClaude，我只需要描述需求："根据这个GeoJSON数据，在Cesium场景的指定高度绘制一个多边形围栏区域，并设置半透明材质和描边颜色"。Claude通过MCP Server自动找到Cesium的Actor、调用CesiumGeoreference把经纬度坐标转成UE世界坐标、用蓝图节点或Python API创建多边形Actor并设置好视觉参数。整个过程我只写了那段自然语言描述，其他全是工具链自动完成的。
类似的应用场景还包括：批量创建大量带有地理标签的Marker点、根据不同LOD级别切换可视化图层、把新的3D Tiles数据集动态加载进场景。这些在以前都是需要专门开发工具才能完成的工作，现在一个自然语言指令就够了。
3.4 Unreal里提升工具链效率的蓝图习惯
用UnrealClaude过程中，我总结了一些和蓝图配合的小习惯，能让工具链跑得更顺。
首先，命名规范很重要。Claude在操作UE的资产和蓝图时，主要靠名称来定位对应资源。如果你项目里的资产命名混乱（比如一堆"NewBlueprint_5"），Claude定位起来会非常费劲。我建议项目里统一用前缀和语义化命名，比如BP_Player、SM_Rock_01、VFX_Fire_01这种，训练成本不高，但AI工具链的效率提升非常明显。
其次，善用蓝图函数库。你可以把项目里的常用操作封装成蓝图函数库，然后在MCP Server层暴露这几个函数。这样Claude调用时就不用从零拼接蓝图节点，而是直接调用你们项目里已经封装好的业务逻辑，准确率高很多。
还有一个容易被忽略的点——经常保存并生成快照。AI操作不可避免会出现误操作，比如删错Actor、改错参数。我通常每执行一批指令就手动保存一次关卡，必要时对资产也做版本管理。不要把底牌全部押在AI的准确率上，保留回退路径是资深开发者该有的基本功。
4. 常见问题与排查技巧实录：从License到API Level到D3D崩溃
4.1 常见报错速查表
我把自己和身边同事在MCP工具链上遇到的典型报错整理成一张表，方便大家对照排查。
| 报错信息/现象 | 可能原因 | 解决思路 |
|---|---|---|
| no valid unity editor license found. please activate your license. | Unity许可证未激活或过期 | 打开Unity Hub重新登录并激活；检查是否用了个人版且超出商业使用阈值 |
| unity 提高 minimum api level 后构建失败 | Android API Level与插件不兼容 | 用MCP或手动将Target API Level调整为项目插件支持的范围，必要时升级插件 |
| unreal engine is exiting due to d3d device being lost | 显卡驱动崩溃或GPU资源耗尽 | 更新驱动；切换DX11；降低渲染特性和分辨率 |
| unreal engine ran out of memory allocating 528384 b | 显存不足 | 调小纹理串流池，减少同屏高精度资产数量 |
| vscode配置claude code后不识别MCP工具 | 配置路径或命令错误 | 检查配置文件的command和args是否和实际路径一致，重启Claude Code |
| unfortunately, claude is not available to new users right now | 模型服务限流或地区不可用 | 更换网络出口，或等待服务恢复；检查API Key配额 |
| Unity MCP Server连上但场景操作为空 | Unity侧没开启MCP插件/端口被占用 | 检查Unity菜单是否有MCP工具窗口，确认端口未被其他进程占用 |
4.2 Unity侧两个高频问题的排查实录
License激活失败。"no valid unity editor license found"这问题我见过太多次。大部分情况是Unity Hub登录过期，或者电脑上同时登录了多个账号导致License混乱。我一般让同事先退出Hub重新登录，再在菜单栏Help -> Manage License里激活。如果还不行，就到Unity官网手动激活并下载License文件导入。有一个容易被忽略的点：如果你公司用了代理服务器或者网络环境比较特殊，Unity Hub的License验证请求可能被挡，这也会导致明明激活了却一直报无许可证。这时候先关掉代理再重新激活，成功率会高很多。
Android API Level提升到API 35带来的兼容问题。最近很多项目要求把Target API Level提到API 35，Unity这边如果内置的Android SDK版本不够新，就会报Gradle构建错误或者某些插件不支持。我的排查思路是：先在Player Settings里把Target API Level设回项目原本能构建的等级，确认能正常打包；然后逐步升级API Level，每升一级就跑一次构建，定位是哪一个环节开始报错的。遇到插件不支持的情况，看有没有新版本插件、或者有没有替代方案。用MCP + Claude的最大优势是，这个排查过程可以让Claude帮你分析Gradle的报错日志，甚至自动修改配置重试，省去很多来回操作。
4.3 Unreal侧的内存和渲染问题
D3D Device Lost和Out of Memory是UE边缘开发里绕不开的坎。尤其当你开着UE编辑器，同时挂着UnrealClaude让它不停创建Actor、加载资产，画面卡顿甚至闪退的概率会明显上升。
我的建议是：跑AI工具链时，把编辑器视口中的实时渲染等级调低（View Mode改成Unlit，或者关闭实时光照），同时关掉不必要的GPU特性，比如Temporal Super Resolution这类吃显存的后期效果。如果机器内存本身紧张，尽量让Claude的批量操作切成小批次完成，不要一次让它在场景里生成几百个Actor——不是说功能上做不到，而是引擎扛不住。
对于已发生的Out of Memory崩溃，启动项目时加-dx11命令行参数，或者调低r.Streaming.PoolSize是最快的急救方法。如果想根治，还是要从资产层面控制：减少重复贴图、压缩纹理格式、使用Nanite自动处理高模网格。
4.4 MCP Server连接类问题的通用排查思路
如果你遇到MCP Server连不上、工具列表为空、Claude Code无法调用MCP工具这类问题，我提供一个通用排查路径。
第一步，确认MCP Server进程是否真的起来了。到终端里看看有没有报错输出，用ps或任务管理器确认进程存在。第二步，确认端口监听状态。大部分MCP Server用的是本地端口，用netstat -ano或lsof -i看看对应端口有没有监听，没有监听就说明Server没正常启动。第三步，用最简单的测试（比如curl一个本地请求）看看Server是否有响应。如果Server本身没响应，问题大概率在依赖缺失或配置错误；如果Server有响应但Claude Code调不到，问题在MCP配置的command/args路径上。最后一步，重启Claude Code和MCP Server，这个看起来笨但确实能解决不少诡异的缓存问题。
5. 工具链选型与未来扩展：不只是Unity和Unreal
5.1 Unity MCP vs UnrealClaude：怎么选
做方案选型时，有人问我是不是引擎一换，工具链全部重来。我的经验是：MCP这套东西的迁移成本没有想象中高，但还是有几个区别需要提前知道。
Unity MCP的优势在于Unity的Editor API本身就非常友好，C#脚本可以直接操作编辑器的一切，所以MCP Server能覆盖的功能非常广。加上Unity的Prefab、AssetDatabase这些系统天然适合程序化操作，AI工具链的准确率高，出错少。
UnrealClaude这边，UE的Python API虽然能实现大部分编辑器自动化，但终究不是UE的嫡亲语言，很多C++才能做的事Python调不到。蓝图层面的MCP服务器方案更是只能覆盖简单的操作。如果项目是重度C++开发的Unreal项目，想用MCP做深度自动化会比较吃力。
选型建议：如果你的团队以Unity为主，Unity MCP能马上落地见效；如果团队是Unreal，先用现成的Unreal Python Editor Script Plugin把查询、资产整理、批量生成这类操作自动化，比追求一步到位接完整MCP更实际。等业务稳定了，再考虑把UnrealClaude这种更深层的方案引入进来。
5.2 MCP工具链和传统脚本自动化到底差在哪
我之前说过很多人觉得MCP和传统脚本自动化差不多，这里再展开讲透彻一点。
传统脚本自动化的核心是"确定性执行"：脚本写死每一步动作，遇到判断条件走固定分支，产生错误也不会主动修正。MCP工具链的核心是"意图理解 + 动态规划"：你给出一个模糊目标，让模型拆解成步骤，中间发现卡住了还会换一条路。这不是简单的把传统API封装一下，而是把"工具调用的决策权"从人转移给了AI。
举个例子，传统脚本可能会写"遍历场景所有物体，凡是名字包含Door的就隐藏"。MCP工具链则允许你跟Claude说"把这个场景里所有看起来像门的东西都隐藏掉，但保留门上的把手和窗户"。Claude会自己读取场景物体的名称、层级、组件，甚至渲染Mesh来判断哪些算"门"，然后根据判断结果执行。这已经超出了纯粹的工具调用，更像是一个初级开发者在帮你干活。
另外一点，传统自动化脚本只能做你已经预想到的事情。MCP工具链因为背后是大模型，它能处理你事先没有设计过的场景——提问的艺术比预先编写的逻辑更有生产力。
5.3 2026年MCP在游戏开发圈的生态扩展
到了2026年，MCP在游戏开发圈已经不局限于Unity和Unreal。我观察到几个有趣的方向。
Blender MCP早就有了，通过它可以让Claude直接操作DCC工具来建模和改UV，很多美术已经开始用AI辅助做资产草稿。Cocos Creator MCP在我逛社区时也看到了好几个实现，随着小游戏和侧边栏生态热度上升，这套工具链被不少微信小游戏开发者用来快速搭原型。MasterGo MCP和蓝湖MCP这类设计协作工具的接入，让UI切图和标注环节也能和Claude对话，设计和开发的边界被进一步模糊。连MATLAB MCP都出现在工程仿真和游戏寻路算法验证的场景里——这个词条能上热搜，说明不少人在认真尝试。
我的判断是：未来MCP协议会成为游戏引擎和AI之间的默认接口标准，就像HTTP之于Web一样。引擎厂商也有意识到这一点，Unreal 5.6之后对AI工具链的支持松动了，Unity 6.3的编辑器扩展机制也明显为外部AI调用留了空间。现在是谁先跑通这套基础设施，谁就能在AI辅助开发这条路上攒下更多方法论。
5.4 我目前的生产环境配置参考
最后给一份我个人目前在用的生产环境清单，权当参考，不要照抄，每套环境都有自己的特殊情况。
- PC端：Windows 11，NVIDIA RTX 4090 24GB，64GB内存，i9-13900K。这个配置跑UE5和Unity 6编辑器都不紧张，同时带MCP Server和Claude Code完全没问题。
- Unity侧：Unity 6 LTS + Unity MCP Server（社区方案），Python 3.11虚拟环境，通过Claude Code接入。
- Unreal侧：UE 5.4/5.5 + Python Editor Script Plugin + 自封装MCP Server，Cesium for Unreal 1.28以上版本做GIS扩展。
- 模型接口：Claude Code默认走Anthropic官方API，但我也在评估私有化部署的模型网关，毕竟游戏开发涉及到的项目资产数据有些并不适合离开本地环境。
这套组合跑了差不多两个季度，整体稳定，偶尔MCP Server进程会卡死，重启就能恢复，没有遇到过数据损坏或工程不可逆破坏的情况。当然，我始终保留着版本管理和手动操作的习惯，AI工具链再顺手，也只是加速器，不是替代者。
