游戏生产AI落地武林秘籍·第一式「手到擒来」：让 AI 理解项目资产

系列导读：「游戏生产AI落地武林秘籍」是一个面向游戏技术美术（TA）和工具开发者的实践系列，记录我来时路，都是我的血泪史。

一、缘起：不让AI两眼一抹黑

我们的项目是一个大型开放世界游戏，资产库规模在 十万级，涵盖乔木、岩石、灌木、建筑等十多个大类，每个资产还有移动端变体、LOD、Impostor、子资源。

要让 AI 参与游戏生产，它首先得”认识”这个项目里有什么。但现实是——

1
2
3

"放一棵江南风格的矮灌木"
  → AI 看到的是 shrub_a1_01a、shrub_a1_02b
  → 哪个是矮的？哪个是应该用在这个场景的？不知道。

人不比 AI 好多少。美术找资产同样靠翻文件夹、猜文件名、问同事，凭借记忆去检索。
芬兰 Aalto 大学 2024 年的硕士论文[^1]记录了同样的困境：HypeHype 平台 5000+ 资产库中，搜”forest”找不到描述里写”woods”的资产；

所以，让资产变得可被理解，是 AI 参与生产的前提。
但，AI 理解人的东西，是需要人来教的（标注）。
这些标注是一个很耗时的事情，美术并没有义务来协助你做这件事情。
所以我还需要一个 SOP，让美术边搜东西，边标注资产。试图以此形成一个正向螺旋。

二、资产与理解的距离

实际上，不管是人还是AI，要理解一个资产，都存在三种不同的距离。

1. 这个资产代号是什么？（语义）
2. 这个资产长什么样？（视觉）
3. 这个资产是干什么用的？用在哪里？怎么用？（逻辑）

BTW：大家用绝大多数优秀的搜索能力，都能检索到和这个文章相关的一切字符，即使这个字符可能只是文档中的一个备注，但是你知道，脑子就是这样，你可能只记得角落里的某个触动你的“刺点（罗兰巴特《明室》）”，可就是想不起这个东西的标题。我所知道的所有游戏引擎的搜索框就是这样，只能搜索到文件名，搜索不到文件里某个蓝图备注，也不支持更复杂的搜索逻辑。
这是产品设计的问题，这还不是“距离”。一个优秀的搜索框，应该像Everything一样（是的，我在实名表扬它），能搜索这个系统里的一切！所以，我们的搜索能力，理论上应该能用印象去模糊地检索到这个资产，这也是我要做的。

第一层：语义距离。 文件名、路径、标签里的字面匹配——搜”rock”能找到 rock_granite_01，但搜”石头”或是“岩石”就搜索不到。即使这几个字的意思几乎很接近，又或只是中英文的区别。

第二层：视觉距离。 想要表达某种特定形式的建筑，但是奈何语文老师去世的早，无法精确地表述出“庑殿”、“闇栔”、“甍”、“甓”这样的词语，但你知道，就是那个东西！此时语言的贫瘠竟是如此的真实。

第三层：逻辑距离。 搜”可以放在角落的破旧物件”——这不是在描述外观，而是在描述用途和状态。视觉检索帮不了这个忙。这里面是包含一定的推理思考，比如你怎么知道这个家里的角落里可以放一个扫帚，而不是放一把杀猪刀，这是需要理解需求，并从需求出发去思考的。

三层各有盲区，也各有强项，需要应用在不同的场景。

三、框架心法

先讲一条工具设计上的”心法”：用户愿意为工具等待，但等得越久、期待就越高。 搜了 1 分钟却给一个糟糕的结果，是用户最不能接受的。所以整个框架是围绕响应速度分层搭起来的——快的先出、慢的后补，绝不让用户干等。

顺着第二节那三种”距离”，我把检索拆成三层，让每一层各去够一种距离：

• 第一层·基础检索（最快，< 100ms）：在 UE 原生检索逻辑上做优化，靠文件名 / 路径 / 标签做字面与规则匹配。它是”保底”——不依赖任何 AI 模型也能用。
• 第二层·向量检索（即时，< 100ms）：这一层其实跑着两条并行的路——视觉向量去够「视觉距离」（搜图找图），文本 / 描述向量去够「语义距离」（同义词、中英、换个说法都搜得到，补上第一层字面匹配跨不过的那道坎）。两路各自召回，再融合排序。
• 第三层·逻辑检索（精排，后台异步）：用 CLI 与 MCP 把外部 LLM 接进来，去够最难的「逻辑距离」——理解用途、状态、意图这类需要推理的查询。

一句话理顺命名：三层框架对应三种距离，但「语义距离」是被第一层（字面匹配）和第二层（文本向量）接力补上的——这也是为什么明明叫”三层框架”，技术上却跑着「SQL + 视觉 + 描述 + LLM」四条路。后面第五节的 NeuroBrowser 就是照这套心法落的地。

四、华山论剑·技术选型

框架设计好了，接下来就是最关键的问题：用什么模型？

这不是一个能靠直觉或论文排行榜回答的问题。游戏渲染图和自然图像之间存在 domain gap——我们的缩略图是引擎内渲染的（天空球 + 多方向光 + 风格化材质），和 CLIP[^2] 训练用的 Flickr / LAION 数据集长得完全不一样。学术排行榜上的分数肯定不能直接迁移。

所以我做了两个 benchmark：视觉编码器选型%% （对应第1小节） %%和描述/文本 Embedding 选型%% （对应第3小节） %%。数据集用的是 100 张项目真实缩略图 + 5 组美术标注的 Ground Truth（每组 1 个中文描述 + 3 张正确图片）。

另外，描述Embedding是不具有初始数据的，这些数据直接让美术去标注也不是非常合适，所以我直接用大语言模型去生成了最初的所有资产的描述，然后再用这个描述去做文本语义的Embedding（未来新资产入库的时候，也可以考虑使用这套方案，然后美术再基于LLM生成的描述数据去修改），所以还对不同的多模态LLM进行了一波评测%% （对应第2小节） %%。

1. 视觉编码器：14 个模型两轮横评

图像 -> 语义向量

1
2
3
4
5
6
7
8
9

flowchart LR
    A["🖼️ 资产缩略图"] --> B["视觉模型"]
    B --> C["1024-dim 向量"]
    C --> D["FAISS 检索"]

    style A fill:#4a90d9,color:#fff
    style B fill:#e8793a,color:#fff
    style C fill:#50b86c,color:#fff
    style D fill:#9b59b6,color:#fff

第一轮从 Aalto 论文推荐的 4 个模型起步（最小测试），核心发现是：不支持中文的 CLIP 面对中文 query 完全失效，Recall@10 只有 13.3%，基本等于随机。而加了 xlm-roberta 多语言文本塔的版本以 66.7% 遥遥领先——5 到 10 倍的差距。

第二轮按这条线索扩展到 10 个新模型，覆盖 4 个 Tier：2025 SOTA（FG-CLIP 2 系列）、中文原生训练（Chinese-CLIP 系列）、多语言新秀（MEXMA / NLLB / AltCLIP）、以及第一轮最强方案的家族放大版。

结果出乎意料：奇虎 360 的 FG-CLIP 2 large（0.9B 参数，双语原生）以 P@3=73.3%、R@10=93.3% 双料夺冠。5 个 query 中有 4 个在 Top-2 就全中正确答案——这是工业可用的水平。比第一轮最强方案提升了 26.6 个百分点。

更意外的是，FG-CLIP 2 large 反而比参数量更大的 so400m（1.0B）在 P@3 上强 20 个百分点——不是越大越好，训练步数和缩略图尺寸适配可能更关键。

性价比方面，Chinese-CLIP ViT-L/14@336 在 R@10 上与 FG-CLIP 2 large 并列第一（93.3%），维度更小（768 vs 1024）、加载最简单、生态最成熟，是稳健备选。

所以我最终选择了 FG-CLIP 2 large 作为图像语义的编码器。

⚠️ 先泼一盆冷水：上面这些百分比都建立在 5 组 GT × 3 张正确图 = 15 个数据点 上，单个结果错位就是 ±6.7pp 的抖动。所以”73.3% 双料夺冠””比第一轮提升 26.6pp”这种话，方向是对的，但领先幅度大概率含运气成分，得等 GT 扩到 30+ 组才能当成定论。这条警告对下面第 3 小节的文本 benchmark 同样成立——别被任何单个高分冲昏头。

2. LLMs生成评测

缩略图 → 中文描述

如上文所述，我需要为文字语义准备第一波初始化文字内容，所以我打算直接用大语言模型去生成了最初的所有资产的描述，然后美术再基于这个文字的基础上进行一些修改，来使其更贴合“生产内容”场景。但是，要对资产进行理解，并生成描述也也不是一个简单的事情，不同LLMs在生成时间、效果、稳定性上都存在差异。为此我也做了一个测试：

1
2
3
4
5
6
7
8
9

flowchart LR
    A["🖼️ 资产缩略图"] --> B["多模态 LLM"]
    B --> C["中文描述文本"]
    C --> D["文本 Embedding"]

    style A fill:#4a90d9,color:#fff
    style B fill:#e8793a,color:#fff
    style C fill:#50b86c,color:#fff
    style D fill:#9b59b6,color:#fff

我拉了 13 个主流多模态 LLM （2026 年 5 月末）对同一批 100 张资产缩略图生成（生成这个缩略图也有讲究，这里最好是一个高分辨，有能力的话，甚至可以考虑多角度缩略图。我这里采用的是2048*2048的单缩略图，且最好不要过曝也不要欠曝）描述，从成本、速度、质量、稳定性四个维度横评：

• 评测的时间仅供参考，和不同API提供商也有关系。这仅仅是我的环境。
• 另外，LLM的生成成本也和提供的提示词有关。复现的成本也会有区别。
• 我在测试的时候使用固定提示词，且每一个图片一个独立地上下文进行的测试。

几个关键发现：

1. 成本差距惊人——最便宜和最贵差 20 倍。 gemini-3.1-flash-lite ¥0.026/张 vs gpt-5.4 ¥0.567/张。按 10 万张全量算，前者 ¥2,607，后者 ¥56,700——差十几张 RTX 4060 Ti 的钱。更意外的是 claude-opus 居然比 sonnet 还便宜（¥0.221 vs ¥0.258），sonnet 竟被 opus 反超。

2. 描述长度差异巨大，但不是越长越好。 Claude-haiku 平均 298 字最长、方差最小（min 186 ~ max 435），结构化最好（”形状结构 / 材质纹理 / 颜色色调 / 细节特征”四段式）；qwen3.5-plus 仅 154 字最短。但后续 Embedding 检索验证了一个反直觉结论——对人类最可读的描述 ≠ 对 Embedding 最友好的描述（详见下节）。

3. 千问——笑里藏刀的暗器：标签泄漏直接污染 Embedding。 qwen3.5-plus 会泄漏 <skill> 标签（某张图输出 38 字垃圾 skill\nname visual verdict\n/name\n/skill），qwen3.6-plus 会泄漏 <think chain-of-thought（最长 1347 字的推理过程直接写进输出），稳定性只有 ⭐⭐。这些残留标记直接进入描述文本，在后续 Embedding 检索中变成噪声。全量生产前必须加清洗步骤（正则去标签 + 截断到 800 字）。

4. Kimi-k2.6 是国产首选——0 异常、速度最快。 10.2s 纯查询时间全场最快，0 异常输出，稳定性满星。如果对 trust_remote_code 有顾虑或需要纯国产方案，kimi-k2.6 是最稳选择。其折扣版 kimi-k2.6-yd 偶发 1 张 2448 字疑似 think 泄漏，加最大字数过滤后可用。

5. 免费模型可用但偏弱。 Mimo-v2.5-free 零成本但偶发 timeout（120s）和 token 循环异常（30K-44K 陷入循环），水体类识别也有失误，稳定性仅 ⭐⭐⭐。适合做 PoC 验证，不适合全量生产。

6. 描述质量与渲染图质量正相关。 渲染图质量越高，描述质量越好。

3. 文本 Embedding

视觉编码解决了”搜图找图”的问题，但这种搜索能力还是太浅层了。
如果要让AI深度理解这款游戏的资产，更重要的是突破表层的图像语义，了解这个资产属于谁？它意味着什么？

而这些内容，是真正地需要美术去一点点教会AI的，并且也是最”落地”的，那怎么去教呢？

我的答案就是——让 AI 先给每个资产写一段描述，再对描述做语义检索（日后美术可以针对这一段描述进行修改，然后重新embedding进向量库）。
所以我请上轮的4个玩家又做了一个交叉评测：7 个文本 Embedding 模型 × 4 个描述源 = 28 种组合，加上 FG-CLIP2 视觉 baseline + RRF 融合，总共 53 组实验。

七个 Embedding 候选（均为我环境里 8GB 4060Ti bf16 跑得动的模型；Qwen3-Embedding-4B/8B 因 bf16 权重 ≥8GB，排除）：

四个描述源从上节 13 个模型中选出：claude-haiku-4-5（人类阅读质量最高）、kimi-k2.6（生产首选）、glm-5v-turbo（国产稳定）、gemini-3.1-flash-lite（性价比之王）。

⚠️ gte-Qwen2-1.5B 结果不可用，已从排名排除。其 2024 版自定义 modeling_qwen.py（bidirectional attention + 旧 KV-cache API）与 transformers 5.9.0 三处不兼容。本次用原生 Qwen2Model（causal attention）应急加载，但 gte 的核心是 bidirectional——causal 下 last-token pooling 严重退化（R@10 仅 20–60%），不代表真实质量。其 C-MTEB 67.7 提示真实水平应是中游偏上。

剑走偏锋：对人类最可读的描述 ≠ 对 Embedding 最友好的描述

6 个公平模型 × 4 描述源 = 24 组单路文本检索，按 R@10 排序（gte-qwen2 排除）：

⭐ e5-large + gemini 单路 R@10=93.3%，追平 FG-CLIP2 图像单路天花板——最大意外（e5 的 C-MTEB 仅 58.8，本是候选里最弱的）。但这是 15 个数据点上的单组合，完全落在 ±6.7pp 噪声带内，大概率部分是运气，必须扩 GT 复核才能当真。

最扎眼的数据在最后一行——bge-m3 + claude-haiku 的 P@3 只有 26.7%，全场最差。
而上节里 claude-haiku-4-5 可是”人类阅读质量最高”的描述模型——avg 298 字、方差最小、结构化最完美（”形状结构 / 材质纹理 / 颜色色调 / 细节特征”四段式）。

把四个描述源在六个 Embedding 模型上的平均表现拉出来看更清楚：

人类可读并不意味着Embedding友好

人类阅读排名第 1 的描述，Embedding 检索 P@3 排名第 4（垫底）；人类阅读排名第 4 的最短描述，Embedding 检索排名第 1。

推测原因有三个：

1. 描述太长 → 关键 token 被截断切掉。 bge-large-zh 的上下文只有 512 token，298 字的中文描述大概率被截断，关键信息丢在尾部。
2. 模板套话稀释了语义关键词。 “形状结构 / 材质纹理 / 颜色色调 / 细节特征”这些模板词在每个描述里都出现，对 Embedding 来说是噪声——它们不区分资产 A 和资产 B，却占据了向量空间。
3. CLS pooling 对长文本敏感 → 主旨向量被均化。 越长的文本，CLS token 需要编码的信息越多，反而把最关键的语义特征（”客栈”、”破旧”、”青苔”）给稀释了。而 gemini-3.1-flash-lite 的描述最短（avg 165 字），反而让 Embedding 聚焦在最核心的语义关键词上——少即是多。

描述源的选择比 Embedding 模型更重要

这个发现有一个重要的推论：同一 Embedding 模型上换描述源，P@3 能差 20~40 个百分点；换 Embedding 模型在同一描述上，差距通常只有 ±7pp。

换句话说，描述源是杠杆，Embedding 模型是微调。投入应优先放在描述源迭代（prompt 工程、描述清洗、混合多模型描述），Embedding 模型选哪个都差距不大——看每模型平均：

7 款模型没有一个在平均意义上明显拉开差距

全部落在 GT 噪声带（±7pp）内。注意 C-MTEB 排名（stella 68.6 ≫ e5 58.8）与本域实测（e5 ≈ stella ≈ 70%）严重不一致，再次印证「通用 benchmark ≠ 你的域」——选型必须以本域 GT 为准。

融合：双剑合璧，1+1 > 2

单路文本 Embedding 的 R@10 最高冲到 93.3%（e5-large + gemini，追平 FG-CLIP2），但这是 15 个数据点上的单组合、落在噪声带内，不可据此认为文本已追平视觉。更稳健的判断是：平均意义上文本单路 R@10 在 68–73% 区间，文本不能替代视觉，但可以补充视觉。
用 RRF（Reciprocal Rank Fusion, k=60）把视觉和文本两路融合后：

选型结论

一句话总结：中文能力是硬门槛不是加分项；描述模型和检索模型必须分开选型，以 Embedding benchmark 为准；学术排行榜只能作参考，必须用自己的数据跑分。

📒 顺便把一次性落地账也算清楚。 除了上面反复出现的描述生成（gemini ¥0.026/张，十万张约 ¥2,600、跑了 8 个多小时），真正铺开还有几笔一次性成本别忘了——缩略图全量导出 ≈ 33 小时（CPU 单线程，一次性夜里跑，后续只走增量）、视觉编码 ≈ 3.3 小时、文本编码 ≈ 20 分钟（都在一张 4060 Ti 上）。再加上美术后续的增量标注，但那是”边用边标”摊薄掉的、可选的人力。算下来真正花钱的就是描述生成那点 API 费，本地编码全是电费——这也是为什么我敢在十万级资产上一次性全量铺开。

五、造一把趁手的兵器：NeuroBrowser（给碳基生物用的）

这把兵器就是 NeuroBrowser——我的一个跑在 UE4 编辑器里的资产搜索面板。它直接嵌入编辑器的 Slate 插件面板，和 Content Browser 并排着（仿照UE原生内容浏览器的体验）。美术开箱即用的体验。

设计哲学：三层检索、渐进呈现

回到 [[#二、资产与理解的距离]] 里提出的三层距离，NeuroBrowser 的检索架构也是三层：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

flowchart TB
    Q["👤 用户查询"] --> SQL["📋 SQL 检索<br/>FTS5 + 标签过滤<br/>&lt; 5ms"]
    Q --> VIS["👁️ 视觉检索<br/>FG-CLIP-2 large<br/>~30ms"]
    Q --> DESC["📝 描述词检索<br/>Qwen3-Embedding-0.6B<br/>~30ms"]
    SQL --> RRF["🔄 RRF 融合排序"]
    VIS --> RRF
    DESC --> RRF
    RRF --> RESULT["⚡ 即时结果 &lt; 100ms"]
    RRF --> LLM["🤖 LLM Re-rank<br/>300-600ms"]
    LLM --> REFRESH["🔄 精排刷新"]

    style Q fill:#4a90d9,color:#fff
    style RRF fill:#e8793a,color:#fff
    style RESULT fill:#50b86c,color:#fff
    style LLM fill:#9b59b6,color:#fff

第一层：SQL 检索（< 5ms）。FTS5 全文检索 + 标签过滤 + 数值范围（三角面、LOD、材质数）+ 逻辑组合（AND/OR/NOT）。这一层不依赖任何 AI 模型，是保底——即使 Python 后端没启动、模型没加载，关键词搜索依然可用，而且比 UE4 原生快 50 倍以上。

第二层：向量检索（< 30ms）。视觉（FG-CLIP-2）和描述词（Qwen3-Embedding-0.6B）两路独立检索，各自返回 Top-K，然后通过 RRF 融合排序。三路权重用户可调——搜”青苔石头”时视觉权重高，搜”角落破旧物件”时描述权重高，搜”三角面 < 5000 的大石头”时 SQL 权重高。

第三层：LLM 精排（300-600ms，后台异步）。见下一个段落。

关于这个插件的设计

1. 重本地、轻服务器。 所有索引（SQLite + FAISS）和模型都跑在美术本地机器上。搜索完全离线可用，断网也能正常工作。Python 后端（FastAPI）跑在本地 localhost，不依赖任何云端服务。唯一走云端的是描述/标签的团队同步——多人协作时，你改的描述别人也能看到。也支持纯本地运行，这样如果用户本地有数据更新，也可以快速更新数据库。

2. 不修改引擎源码。 整个插件基于 UE 4.27.2 的公开 Slate API 实现——缩略图用 FAssetThumbnailPool，拖拽用 FAssetDragDropOp，资产查询用 IAssetRegistry。不碰引擎 Private 目录，不 fork 引擎，后续升级无负担。对引擎接口要求少，可以支持更多引擎版本。

3. 资产族折叠——10 万变 3 万。 同一个资产往往有 PC 版 + Mobile 版（_ios）+ LOD 变体 + 材质变体（_01a/_01b）。如果全部平铺展示，搜索结果里同一个逻辑资产会出现 5-8 条——这不是”搜到了”，这是”搜炸了”。NeuroBrowser 按”资产族”聚合：_01a/_01b 材质变体折叠为子项，_01/_02 不同 Mesh 分开显示，_ios 移动端隐藏在 PC 端后面。十万级资产文件 → 数万个资产族，搜索结果干净一个数量级。

4. 标签语义配置化，方便修改。 文件名里编码了大量的项目约定——用简写区分不同区域 / 场景风格、建筑与资源类别，再配上技术变体后缀（积雪版本、移动端版本等）……30 多个场景标记 + 10 多个技术变体后缀，累计上百种规则，这些逻辑本身是带有语义的，和美术对齐了这些语义后也成为了搜索内容的一部分。另外，这些规则全部通过 tag_rules.json 配置文件管理，不写死在代码里。美术/TA 可以自己加规则，不需要改代码重新编译。

5. 描述是活的，不是死的。 LLM 生成的描述只是初始值——美术可以在资产详情面板里直接修改描述和标签。改完之后，旧的 Embedding 自动标记为 stale，后台三重更新机制（惰性 + 定时 + 手动触发）会异步重建。描述/标签通过云端在团队间同步，你改的描述，同事下次搜索就能用到。

6. 使用分析闭环。 NeuroBrowser 内置了 NeuroBrowserAnalytics 模块——Tab 焦点、拖拽到视口、Viewport 放置归因，全部异步记录到 JSONL。配套的数据分析仪表板可以看”哪些资产被搜得最多”、”哪些搜索没找到结果”、”用户最常拖哪些资产到场景里”。这些数据是后续优化搜索权重、补全描述盲区的依据。

7. 支持多种搜索模式。 用户可调整各路检索权重，支持逻辑精筛选（按标签精筛、按模型面数大小筛选等）。

8. 正向螺旋——回到开篇挖的那个坑。 还记得开篇说的吗：要让 AI 理解资产，得有人来教；但美术没义务专门替你做标注。我的解法不是”逼美术标注”，而是把标注嵌进他们本来就要做的搜索动作里——美术搜资产、用资产的过程中，顺手就能改一条描述、补一个标签。这些改动通过云端共享数据库实时同步给全队：你今天纠正的一条描述，同事明天搜索时就直接受益。用得越多 → 描述/标签越准 → 搜得越准 → 越多人愿意用——这就是开篇许诺的那个”正向螺旋”，现在它真的转起来了。

功能Demo演示

六、再做一把不趁手的兵器：MCP、CLI（给硅基生物用的）

还记得我们做这件事情的初衷吗？
我们要教会 AI 去认识、理解资产。现在我们有了图像语义、文本描述，还有一大堆的语义标签，我们足以让AI理解每一个资产的具体用途，甚至开放了缩略图给多模态，它如果想仔细对比两个模型，甚至可以开一个子Agent去看图仔细对比两个资产。（当然，并不是开放的接口越多，对于LLM越好，而这就是另外一个故事了）。

七、落地之后：把「行为构成」摊开看

兵器造好了，得看它真上了战场是什么成色。第五节里吹过的那个「使用分析闭环」现在真转起来了——NeuroBrowser 自带的埋点把上线以来每一次操作都记成了 JSONL，下面这张「行为构成」就是这段时间的体检报告：横轴是次数，每一根条都是一个动作。

在部署的第一周时间，测试的6 个用户开了 130 个会话，发起 1403 次搜索、选中资产 681 次。从数据上说，NeuroBrowser和UE的Content Browser目前在使用量上几乎平分秋色，虽然UE Content Browser使用数据更好看一点。从使用习惯上看，它没变成「替代品」，而是变成了「发现层」。 原生内容浏览器面板被打开了 1814 次，NeuroBrowser 被打开 1517 次，老的搜索习惯还在；

另外，「真正把资产放进场景」这一步：从原生 Content Browser 放进去 892 个，从 NeuroBrowser 拖进去的只有 118 个，差了将近 8 倍。也就是说——大家在 NeuroBrowser 里「找」，找到之后还是切回原生 CB 去「放」。 它现在更像一把放大镜，还不是那把能单挑的兵器。我觉得这可能是逻辑设计上的问题，因为我还没有完全去模仿UE原生的路径（目前不能完全地看到除了选定资产以外的资产导致的），这个可能后面还要调优。

目前，作为刚刚上线的功能，能有这水平，我个人还是比较满意的。后面再根据数据一点点调整吧。

后记

本武功秘籍，想要学会，必须和你的武器（AI）达成人剑合一的状态，所以请把本文档下载下来，给你的人工智障也看看。 并说“给俺也整一个”，你或许可以获取就同款工具。

预告：第二式将聚焦「AI 如何去理解场景」（自己挖的坑，如果没做出来，可能会换个招式），敬请期待。

[^1]: FatemiJahromi, S. A. (2024). Enhancing 3D Asset Retrieval with Semantic Search. Aalto University. 链接
[^2]: Radford, A. et al. (2021). Learning Transferable Visual Models From Natural Language Supervision. OpenAI. CLIP 通过对比学习让图文共享同一向量空间，是本次方案的基础能力。