UE5+AI实战：用MCP打通蓝图与C++开发全流程

前言：AI驱动的虚幻引擎开发工作流

这篇文章基于一位UE5开发者的真实工作录像，完整展示了如何将AI编程工具（OpenCode）与虚幻引擎的MCP（Model Context Protocol）结合，实现C++代码编写与蓝图操作的自动化。这不是一个精心准备的Demo演示，而是一次原汁原味的实战开发过程——包括遇到的编译错误、时序Bug和MCP调用的种种坎坷。

整个工作流的核心思路是：将核心业务逻辑全部写在C++中，蓝图只负责UI表现和资源绑定，而AI则作为主力编码者和蓝图操作者参与全流程。

文档驱动的上下文管理：解决AI记忆断层

由于使用的是开源的OpenCode工具，在索引、历史上下文等功能上不如闭源商业产品完善，开发者自建了一套文档驱动的上下文管理体系：

log.md：记录开发时间线和每次会话的工作内容，AI每次启动时读取最近几条了解项目进展
Coding Reference：随手记录代码清洁度问题、待办事项和技术路线
MCP技能文档：记录已使用过的MCP接口签名，避免每次都重新调用ListToolsets查找

这套体系解决了一个关键问题：AI的上下文窗口有限，必须用结构化文档来弥补记忆断层。每次会话结束时，开发者都会让AI总结本次用到的MCP接口并更新技能文档，形成持续迭代的知识积累。

项目参考与工作流

实战任务：快捷栏UI组件的C++重构

项目现状与问题诊断

本次任务是重构游戏中的快捷装备栏——从临时的2槽展示扩展为4个装备槽，并增加耐久度、激活态、额外属性和背包格子加成等信息展示。

项目采用插件化架构，所有游戏业务逻辑写在独立的GameLogic插件中，而非项目主模块。这样做的好处是修改单个文件时只需重编该模块，不会波及其他部分，编译时间显著缩短。

原有的快捷栏实现存在明显问题：为了快速跑通功能，开发者在蓝图的Tick中每帧获取数据，这显然不合理。AI通过MCP读取蓝图的JSON结构后，也准确识别出了这个问题，同时发现了变量未标记、尺寸配置不当等细节。

AI调研与方案制定

AI的工作流程非常清晰：

读取C++代码：通过文件系统直接读取源码
读取蓝图结构：通过自定义MCP工具导出蓝图的JSON表示，分析节点连接和变量配置
交叉分析：结合C++和蓝图两侧的信息，理解当前架构
提出方案：列出优化点和实现路径，等待开发者确认

开发者强调了一个重要原则：一定要让AI先做方案再写代码，分文件修改，修改前必须读取确认当前代码状态。这不是多余的步骤，而是避免AI"幻觉"导致代码覆盖的关键保障。

在需求讨论阶段，AI会主动提问：背包的额外格子数据从哪里读取？激活态的切换规则是什么？开发者可以选择直接告知，也可以让AI自行检索代码库。这种渐进式需求澄清的方式，特别适合需求还在变化的真实开发场景。

MCP调用与蓝图操作

C++编码：AI效率最高的环节

C++代码编写是整个流程中效率最高的环节。AI在明确方案后，迅速完成了以下工作：

新增快捷栏数据结构体，包含耐久度、激活态、额外属性等字段
重构数据驱动链路，从蓝图Tick轮询改为C++侧的事件驱动
通过BlueprintImplementableEvent暴露接口给蓝图层处理UI表现
统一使用项目自定义的日志插件，按模块和级别输出

编译过程中遇到了一个典型错误：TObjectPtr不支持!运算符，需要改用!= nullptr进行空指针判断。开发者提到一个实用技巧：把这类规则写入AI的Skills配置，避免下次犯同样错误。这就是经验的沉淀——每一次编译失败都是优化AI行为的机会。

整个C++编码过程非常快速利落，与后续蓝图操作形成了鲜明对比。

MCP操作蓝图：潜力巨大但仍需打磨

MCP的工作机制

虚幻引擎的MCP提供了数百个工具接口，涵盖蓝图创建、节点操作、控件添加、属性设置等功能。AI需要先调用ListToolsets获取可用接口列表，然后逐个调用完成操作。

在本次实战中，AI通过MCP完成了：

在UMG蓝图中添加TextBlock、Border、ProgressBar等控件
设置控件为变量（等同于手动勾选"Is Variable"）
配置控件的样式和可见性
编译蓝图使变量生效
创建和连接Event Graph中的节点

MCP蓝图编辑过程

当前的痛点与局限

然而，MCP操作蓝图的效率远低于C++编码，主要原因有三：

1. 缺乏文档，接口发现成本高

官方MCP没有提供详细文档，数百个工具接口需要AI每次调用ListToolsets去"猜"。这不仅消耗大量Token，还拖慢了整个流程。开发者的应对策略是每次会话结束后手动整理接口签名到技能文档中。

2. Token消耗巨大且无法缓存

每次MCP调用都会产生大量Token消耗，而且由于需求是动态变化的，这些消耗无法像固定文档那样被缓存复用。

3. 蓝图节点系统的复杂性

蓝图的Graph系统——节点连接、引脚匹配、执行流控制——与常规代码编写的思路完全不同。即使是人类开发者，编写操作蓝图Graph的工具代码也相当棘手。

开发者坦言：手动操作蓝图可能2-3分钟就能搞定的事情，用MCP花了45分钟。但他看重的是边际效率递增——第一次45分钟，下一次30分钟，再下一次20分钟，因为技能文档在不断完善。

迭代调试过程

调试与迭代：真实开发中的"最后一公里"

MCP完成蓝图操作后，启动测试发现快捷栏并未正确渲染。排查发现是初始化时序问题：组件在构造函数中就尝试获取数据，但此时游戏世界还未完全就绪，导致数据为空。

开发者做了一个务实的决策：直接改用Tick轮询，而非花时间设计精确的事件驱动机制。理由很充分——这种UI查询逻辑只跑在客户端，每帧查询在当前开发阶段完全可以接受，回头在待办清单里记一笔就行。

这体现了AI辅助开发中的一个重要心态：不要追求一步到位，先让功能跑通，再逐步优化。AI擅长快速迭代，而不是一次性产出完美代码。

关键经验总结

工作流最佳实践

C++为主，蓝图为辅：核心逻辑写C++（AI效率极高），蓝图只处理UI表现和资源绑定
先方案后编码：让AI先输出完整方案，确认后再动手，分文件逐步修改
会话结束必总结：提取MCP接口签名、编码规则、踩坑经验，更新到技能文档
控制并行度：最多同时开2-3个会话，再多人脑上下文就溢出了——"AI有上下文限制，人脑也有"

工具选择与模型建议

开发者反复强调：一定要用好的模型和好的工具。不要用免费工具体验差就否定整个AI编程方向。开源工具需要自己搭建很多基础设施（上下文管理、索引、文档），但胜在可控和可定制。

对未来的展望

当前MCP操作蓝图的效率还不够理想，但随着接口文档的完善和技能积累，效率会持续提升。更重要的是，这套工作流已经证明了AI可以真正参与到UE5的全栈开发中——不只是写C++代码，还能读取蓝图结构、操作编辑器、触发编译、提交代码，形成完整的开发闭环。