AI+UE实战：MCP连接与打包排错全记录

在AI辅助游戏开发的热潮中，如何让大模型真正“动手”操作虚幻引擎，而不是停留在写写Python脚本的层面？B站UP主永骤的实战课程给出了一个具体路径：通过MCP（Model Context Protocol）打通AI Agent与UE编辑器，并用自然语言驱动蓝图创建、属性挂载乃至打包排错。这篇文章将拆解其中的关键步骤、耗时痛点与避坑经验，帮助你判断这套工作流是否值得纳入自己的开发流程。

核心理念：AI是工具，人负责拆解与验收

永骤在课程开篇强调，AI时代游戏开发者的核心竞争力不再是写代码，而是用工作流指导AI定义目标、拆解任务。他提出三个原则：C++代码基本交由AI编写，UI、声音等蓝图有优势的部分保留蓝图；人工负责随机代码审核与最终效果验证；最重要的，人工拆分整体任务并做最终验收。

这一原则直接回应了“一句话生成游戏”的幻想——复杂多任务如果一次性丢给AI，极大概率逻辑混乱、修改困难、Token成本失控。因此工作流需要升级为“规划、执行、验证”的分布式流程，这也是后续MCP实战中反复出现人工干预的原因。

MCP插件：打通AI与UE的桥梁

MCP的本质是为大模型提供操作UE的“手段”。课程中需要启用两个插件：UnrealMCP和MCP Client Toolset。前者将生成Actor、配置光照、创建材质等功能打包成标准工具集，据资料显示有多达50多个工具集、总共800多个工具；后者是适配器，负责处理AI客户端与MCP之间的连接。两者互补，但不会自动关联。

在编辑器偏好设置中勾选Model Context Protocol下的Auto Start Server自动启动服务器，是使用MCP的前提。随后在AI IDE的MCP设置页面中手动粘贴JSON配置，才能建立连接。第一次连接时出现了“显示已连接但实际未生效”的情况，需要关闭UE编辑器重新打开、并在IDE中重新连接一次，对勾才真正勾上。

Model Context Protocol（MCP）是由Anthropic提出的一种开放协议，旨在标准化大语言模型与外部工具、数据源之间的连接方式。在传统AI辅助开发中，模型只能通过生成代码间接影响项目；而MCP允许模型以结构化方式调用外部工具（如UE编辑器中的API），实现对编辑器内资产、场景和属性的直接操作。MCP采用客户端-服务器架构：AI IDE作为客户端，通过JSON配置连接到运行在UE中的MCP服务器，服务器再将模型请求转换为具体的编辑器操作。这种设计使得AI能够“动手”而非仅“动嘴”，但也要求客户端与服务器之间建立稳定的双向通信，任何配置错误或插件冲突都可能导致连接失败。

实战踩坑：让AI创建蓝图子类

课程用一个具体任务测试MCP：让AI在UE中创建名为MCP Character Base的C++类，并生成蓝图子类BP Player。前半句编译不需要MCP，后半句创建蓝图子类才是MCP发力的地方。

实际执行时，AI尝试了接近一个小时，一直卡住。根本原因是项目没有与UE5引擎文件夹在IDE中建立关联，AI虽然连上了项目MCP，但不了解UE5本身的参数上下文，导致找不到类名而中止。解决方案是安装VS Code（利用其安装时产生的依赖环境），然后只保留Config、Content、Source和Uproject四个关键文件，重建干净的项目结构，再通过右键菜单中的Generate or Refresh Project刷新，生成Code Workspace文件。从这个入口打开项目后，左侧文件夹结构中出现了UE5，说明工程项目与引擎文件夹成功关联。

在Unreal Engine项目中，C++类与蓝图子类的关系是：C++类定义基础逻辑和属性，蓝图子类则继承该C++类，并可在编辑器中可视化地扩展和调整默认值。要让AI通过MCP创建蓝图子类，AI必须能够访问引擎的类层次结构和项目上下文，否则无法解析“MCP Character Base”这样的类名。IDE中的“Code Workspace”文件（通常由VS Code生成）记录了项目与引擎文件夹的关联关系，使得AI能够索引UE5的源代码和API。缺少这一关联时，AI虽能连接到项目MCP服务器，却无法获取引擎层面的参数信息，导致任务卡死。因此，建立正确的项目结构并刷新生成Code Workspace是MCP任务成功的前提。

耗时与成本：MCP的适用边界

完成关联后，再次让AI创建蓝图子类，任务耗时28分钟49秒。过程中AI遇到了DLL加载问题、资产注册表冲突、API选择等多种障碍。这个案例说明MCP并非所有任务都慢，但首次使用确实耗时显著。

随后测试给角色添加弹簧臂和相机，AI同样需要理解自然语言指令，并在检测到编辑器占用时建议使用Live Coding或关闭编辑器。在旋转方向上遇到摄像机不跟随的问题，本质是控制器角度与相对角度的差异，AI对UE内置参数的理解有限，只能给出概率性建议。

UP主据此判断：在实际开发中大部分时间不会用MCP操作UE内容，因为让AI生成简单蓝图函数也需要十几分钟，而生成代码的Token成本少、速度非常快。

打包排错：AI读日志找根因

课程最后测试打包。在项目设置中将构建配置改为Shipping、勾选For Distribution，选择短且无中文的输出路径。第一次打包失败，将log文件路径发给AI Agent，它排查出MSVC工具版本不匹配，并自动修改了build和configuration xml。第二次打包仍失败，日志显示log http listener无法绑定端口。AI分析后指出根本原因是两个MCP插件会在任何目标中加载，包括打包阶段。最简单的解法是在插件列表中禁用这两个插件，重启后打包成功，双击exe即可进入游戏。

Shipping构建配置是UE中用于发布最终版本的打包模式，它会剥离调试符号、关闭控制台命令并优化性能，因此插件加载行为与开发阶段不同。MCP插件（UnrealMCP和MCP Client Toolset）默认会在所有目标中加载，包括打包后的独立程序。打包阶段，这些插件可能尝试启动网络监听或绑定端口，与打包工具或系统服务发生冲突，导致“log http listener无法绑定端口”的错误。解决方法是在插件设置中禁用这些插件，或通过修改.uproject文件将插件限制为仅编辑器目标加载，从而避免运行时冲突。这体现了AI排错时能定位根因，但最终修复仍需开发者理解UE的插件加载机制。

启示：Vibe Coding的两种用法

永骤将这种自然语言驱动的开发称为Vibe Coding，并区分两种形式：一种是纯粹黑箱，完全信任AI输出，适合快速原型或个人尝试；另一种是把AI视为协作伙伴，开发者需要审查、测试并理解AI生成的代码，对结果负责。课程采用的显然是后者。

对于想要尝试MCP的开发者，建议先明确任务边界：简单代码生成用AI效率更高，涉及编辑器内资产操作时再考虑MCP，并做好人工兜底的准备。打包阶段的插件冲突也提醒我们，AI排错能力虽强，但最终决策仍需开发者结合工程知识判断。