为什么“让 AI 看懂项目”是 MCP 工作流的第一块基石

我见过太多人用 MCP 时的第一个反应是：让 AI 帮我生成一个关卡。结果 AI 生成了，但生成的是个四不像——材质引用全乱、关卡里的资产路径驴唇不对马嘴、光照参数看着合理但完全不符合项目风格。问题出在哪儿？不是模型不够聪明，而是你根本没让它看懂你的项目长什么样。

MCP 协议里有两种核心能力：Tools 和 Resources。Tools 是让 AI 动手干活的（比如“创建这个Actor”），而 Resources 是让 AI 睁开眼看的（比如“这个项目的关卡列表”“这个材质的参数范围”）。上一讲我们聊了 Tools 的设计哲学，这一讲我们把焦点放在 Resources 上——如果说 Tools 是手，Resources 就是眼睛。没有眼睛的手，只会瞎抓。

可以这么说，Resources 是 MCP 工作流里最容易被忽略、却最决定成败的一层。它会告诉 AI：你的项目里有多少资产、每个资产属于什么用途、关卡里的布局逻辑是什么、材质参数通常在什么区间浮动。没有这层信息，AI 就像一个空降到你团队的新策划，能力很强但完全不懂你的项目语汇。有了它，AI 才能从“写代码的”变成“懂项目的人”。

这篇文章我会聊三类核心 Resources 的映射方案：Content Browser 资产索引、世界大纲（World Outliner）的层级上下文、材质与光照参数的规范化呈现。顺着这条线，再讲讲大型项目的索引策略与性能雷区，最后给你一张“哪些信息打死也不能暴露给 MCP”的安全清单。这不是理论课，是实战手册，看完你能直接回去搭自己的 Resource 层。

第1层：Content Browser 资产索引——从文件路径到项目语汇

最基础的 Resources 映射，是把 UE 的 Content Browser 变成 AI 能读的上下文。这看起来简单——不就是把资产列表导出来吗？但坏就坏在“简单”上。很多人直接把磁盘路径抛给 AI：/Game/Maps/Level_01、/Game/Props/Chair_01——然后用人类的直觉期待 AI 能理解这些延续了两代人的命名习惯。

它理解不了。AI 会把 Chair_01 当成“编号 01 的椅子”，但不理解这个项目的命名规则里 _01 代表的是“低模版本”而非“序号”。这是典型的语境缺失。Resources 要做的不是罗列文件，而是把资产的语义信息提取出来。对于 UE 项目，我推荐三层资产索引设计：

第 1 层（基础层）是给 AI 认路的，第 2 层（语义层）是让 AI 理解资产间的组织逻辑，第 3 层（规范层）才是让它不犯蠢的关键。这三层合在一起，AI 才能回答“帮我在厨房里摆三张餐椅”这种看似简单、实则包含大量隐性语境的指令。

为了让你感受这层设计的价值，可以看看《模拟人生 4》的资产组织逻辑。Maxis 的资产目录并不是简单按“椅子”“桌子”分类，而是按生活行为区域（烹饪区、用餐区、社交区）来组织——一张餐椅在“厨房”和“餐厅”里出现时，材质和风格有不同的变体。这样的语义分级，在 MCP Resource 层也应该学起来：资产的语义层不应该是“物理类型标签”（椅子/桌子/灯），而应该是“功能区域标签”（用餐区/烹饪区/入口过渡区），AI 才能理解“给我造一个方便四口之家吃早餐的角落”这种真实需求。

当然，把资产目录映射成语义结构不是一招鲜。我个人用了一个很土但有效的办法：把一段项目专用的话术（叫它“项目公用上下文”也行）挂在 Resource 响应的最前面，用两三句话描述这个项目的世界观、美术风格上限和常用摆件套路，剩下的空间留给资产数据。这让 AI 的产出至少方向正确，比塞给它几百个资产的路径有用得多。

第2层：世界大纲的层级上下文——让 AI 理解你在造什么世界

Content Browser 给 AI 的是“有什么”，世界大纲（World Outliner）给它的则是“正在发生什么”。后者比前者重要得多，因为游戏开发里 80% 的上下文不在资产里，而在关卡的组织方式里——哪个房间是玩家的出生点、哪片区域是敌人巡逻路线、哪栋建筑是剧情触发点。

但世界大纲是 UE 里最容易让 MCP 设计者抓狂的部分。它的层级树有几百上千个 Actor 节点，不会像 Content Browser 那样自带 Type 标签。很多人直接把大纲树转成 JSON 塞过去，结果 AI 看到的是一个由几千个节点组成的怪物结构——别说理解了，它连阅读都会有耐心问题。

我的方案是按叙事功能重写层级，而非按物理结构导出。把世界大纲里的 Actor 按“房间-区域-交互点”三层重组，而不是原样保留引擎的父子层级结构。打个比方：如果 Data 里有个厨房，我会把它重新组织为“区域:厨房 -> 家具:厨柜/灶台/冰箱 -> 交互点:抽屉01/水龙头”，而不是“Actor_KD_SM_KitchenCabinet_001 -> 子节点1 -> 子节点2”。这样 AI 才能理解“灶台左边的抽屉里有把菜刀”这种具体指令，而不是在几千个节点里迷失。

这里有个真实案例可以参考——《Overcooked》（煮糊了）系列。它的关卡设计本质上就是一个精心编排的“走位乐谱”。每一关的厨房布局、厨具摆放、配菜流程，都是为了让玩家形成特定的移动路线和协作节奏。如果开发者用 MCP 辅助关卡设计，世界大纲的资源呈现就必须以“移动路径”为核心组织信息，而不是罗列“灶台在哪个坐标”。信息的组织方式决定了 AI 的产出方向。你给 AI 一列坐标，它还你一堆没有灵魂的摆件；你给它一张“动线图”，它可能会给你一份惊喜的关卡原型。

要落实这件事，需要的 MCP Resource 设计就清楚了：给 AI 的不是“节点+坐标”的清单，而是一份“区域语义地图”，包含区域命名、连接关系（门/走廊/通道）、各区域的交互对象以及它们的状态（可破坏/可互动/仅装饰）。这样一来，AI 不再是个读坐标的，而是个读地图的。

第3层：材质与光照参数的规范化——让 AI 调出对的味道

如果说前两层是给 AI 认路和认世界，这一层是给它戴上“美术滤镜”。传统做法是把材质参数直接导出来：Roughness=0.6, Metallic=0.1, BaseColor=#4A3B2A。AI 看了也白看，因为它不知道这个项目里 Roughness=0.6 意味着什么——是哑光木地板？是旧金属？还是一块被雨淋过的石头？

材质与光照的参数化，需要加一层风格标签。对每一个材质实例，除了原始参数，还要标注它在项目美术语言里扮演的角色：是“主基调材质”还是“局域点缀色”？项目整体是低多边形风格还是 PBR 写实风？SKY 光照强度通常在什么范围（清晨/白天/黄昏）？这些信息才是 AI 能用来做判断的上下文。

我打磨了很久才总结出一个可复用的模板，通常包含四段信息：

案例可以看《RimWorld》的材质体系。RimWorld 的地板和墙壁用简单的色调偏移区分不同材料（木材、钢铁、玻璃钢），但给玩家的情绪感知是完全不同的——木材温暖但脆弱，钢铁冰冷但坚固，玻璃钢稀有而高科技。如果 MCP 只是把“钢铁地板，Roughness 0.4, Metallic 0.8”交给 AI，它永远不会理解为什么一个晚期的殖民基地不该全是钢铁地板（会失去“边境求生”的粗粝感）。但如果 Resource 里标注了“材质除了数值还有情绪标签——钢铁=冰冷/坚固/工业化，木材=温暖/易燃/原始”，AI 就能在建议时做出正确取舍。

这一步最容易被低估，却是 AI 生成的东西能不能“融入”项目的关键。技能可以教，审美没法教——但审美可以写成规范让 AI 去遵循。你要做的不是把美术功底喂给 AI，而是把美术的决策规则喂给它。这是 Material Resource 设计的核心哲学。

第4层：大型项目的索引策略——别再让 AI 读十万个资产了

如果你只做 20 个场景的小项目，前面三层足够了。但大型项目——比如 10 万+ 资产的团队项目——你得先解决一个问题：MCP Server 在响应 Resource 请求时，能不能活下来？直接把十万个资产全部序列化成 JSON 塞给 AI，先不说 AI 读不读得完，光序列化耗时就能让你的编辑器卡死三分钟。

这引出一个核心原则：Resources 不是全量转储，而是按需取用的上下文窗口。大型项目的 Resource 设计应该是金字塔式的：塔尖是高度概括的项目全局信息（世界观、美术风格、命名规范 — 几百字），塔中是主题分组的概要（每个系统/区域的资产清单和关键属性 — 几千字），塔底则是按需展开的详细资产数据（当你需要操作某个具体资产时才注入）。AI 先读塔尖和塔中，等需要具体造一个厨房时，再按需拉取厨房相关的资产细节。

至于 MCP Server 的性能，有几个真招：缓存资产元数据，不要每次请求都扫磁盘；建立增量索引，只更新变动的资产而非全量重建；数据压缩，把字段名缩短（但别缩到 AI 看不懂的程度）。这些优化做到位，即使百人团队的 UE 项目也能在几百毫秒内给出精准的资源上下文。

这里拿《城市：天际线》来对照就很形象。这个游戏有成千上万的建筑和道路资产，但玩家并不需要同时看到所有信息——游戏 UI 是按类目分层的：道路、区域、公共服务、美化。这和大型 UE 项目的 MCP Resource 设计如出一辙。如果你把十万个资产像一个垃圾场一样全倒给 AI，AI 就像《城市：天际线》里满屏信息溢出被逼疯的市长——唯一的选择是闭嘴。

至于哪些资源可以被排除在索引之外，我的经验：临时目录、测试资产、废弃关卡、第三方插件内部的资产以及所有非美术类工程文件。它们让你的索引变大、变慢，但对 AI 理解的提升几乎为零，反而是纯粹的性能负担。

一张可调参的表：让 Resource 层成为可维护的系统

很多开发者在搭 MCP Resource 层时把它当成一次性的“配置活”，写完就完。这不对。Resources 应该像游戏里的经济系统一样，要有可监控、可调整的参数，并且要随项目演进而演进。下面是我推荐的一张参数配置表，你可以根据自己的项目规模做加减法：

这套参数不是一个“照着填就行”的空壳，它背后是一个更核心的设计问题——你的 MCP Resource 设计是否需要专职维护者。独立开发者的答案自然是“尽量不需要”。所以参数化不是让你给自己找活干，而是让这套系统在你不写文档的情况下也能自解释、自演进。把项目约定写进 Resource 参数，而不是写进没人读的文档——这才是真正可维护的上下文。

初级用户速览 + 进阶用户深潜

初级路径：如果你的项目在 5000 个资产以内，不想折腾索引策略，那你只需要做一件事——把你最常用的资产、材质和关卡手动整理成结构化文本，挂为 Resource 的初始上下文，然后照着上面的三层结构（基础/语义/规范）给自己打样。别想着一次做完美，先跑通一两个用例（比如让 AI 帮你摆个厨房），理解它哪一步因为缺上下文而犯错，再回头补 Resource。这套流程，一晚上就能落地。

进阶路径：如果是大项目或是团队协作，你需要认真设计金字塔式索引体系，为 AI 建立“项目记忆”。同样重要的还有排除规则和增量更新策略。但更进阶的是把 Resources 和 MCP 的另一个机制做联动——把改变了的状态回写到 Resource 层。比如 AI 生成了一面墙，这面墙就要出现在新的资源上下文中，这样它下次跟别的 AI 协作时知道你做了什么。说白了，你的整套 MCP 架构的“元数据管理”就把 Resources 当数据库，而不是只当“一次性读取的信号”。这需要更多的工程投入，但回报是稳定的产出质量。

两条路径不冲突——先走初级路径拿到手感，碰到瓶颈再往进阶走。没人逼你第一次就造出完美的资源索引系统。

安全边界：什么信息打死也不能暴露给 MCP

把项目上下文喂给 AI 是好事，但喂多了就是事故。MCP Resources 设计里最容易被忽视的是安全边界。我总结了三类绝对不该暴露的信息：

我自己的翻车经历：给一个项目搭 MCP 时，图方便把项目的完整 UAsset 元数据导出在一个 Resource 里。后来发现 AI 推荐的解决方案里总带着一些我不记得写过的注释文本——原来是这些文本里嵌了一些内部沟通的记录，被 AI 当成了“项目规范”用来指导后续操作。倒没造成损失，但那次之后我定了一条死规矩：Resource 白名单制，只有显式声明的目录和数据类型才能被 MCP 访问，其他的一律不给你读。

更稳妥的做法是在 MCP Server 层做两层过滤：第一层是文件级别白名单（只能读到指定目录），第二层是字段级别脱敏（即使读到了，也把敏感字段替换成占位符）。别依赖模型自觉——给 AI 能读到的资料里不该有它不该知道的秘密。

五个真问题

Q1：MCP Resources 和 MCP Tools 到底是什么关系？Tools 是让 AI 动手指的（调用引擎功能），Resources 是让 AI 睁眼睛的（提供项目上下文）。没有 Resources，Tools 像盲人摸象；没有 Tools，Resources 只是摆设。两者缺一不可，但重要性上，Resources 是更底层的地基。

Q2：把整个 Content Browser 导出给 AI 不就行了？还设计什么语义层？全量导出等于没导出。AI 和人类一样，面对海量信息时会走神。语义层是给 AI 的“项目导览地图”，是效率和质量的核心。

Q3：如果我敲一段 Prompt 足够详细，AI 能自己“脑补”出上下文吗？能勉强工作，但会把你的资源风格带偏。项目里没说出来的隐性规则——比如“低多边形风格但保留布料垂坠感”——AI 猜不到，也不该让它猜。Resource 层就是把这些“没写在文档里的约定”显式化。

Q4：MCP Resource 会不会拖慢编辑器启动速度？会，如果你在启动时加载全量索引。我的做法是懒加载：先加载全局概况，等 AI 提出具体请求时再索引对应区域。启动速度和响应速度可以兼得。

Q5：多人团队用 MCP，Resources 怎么同步？两个方案：一是让每个人本地维护一份，适合小型团队；二是将索引放在共享盘或版本控制里，并加缓存，适合中型以上团队。别用纯远程实时同步——MCP 对延迟很敏感，同步开销会让体验变差。