自由学习记录（183）

一个 Node 进程能不能同时连接多个 UE，要看它内部有没有"多 bridge session / 多 endpoint / 多 UE instance"管理能力。

否则 Codex 说"创建一个 Actor"，Node 不知道应该创建到哪个 Editor 里。

复制代码

npx -y unreal-engine-mcp-server

通常不会每个 UE 项目都完整重新下载一遍。

npm/npx 会使用用户级缓存，Windows 下一般在类似这里：

复制代码

C:\Users\<你>\AppData\Local\npm-cache

每个项目会各自生成自己的：

复制代码

项目/mcp/node_modules
项目/mcp/package-lock.json

这种方式确实会让每个项目都有一份自己的依赖目录。好处是稳定、可复现、不同项目可以锁不同版本；坏处是占空间，看起来像"每个项目都装了一遍"。

第三种：你全局安装：

复制代码

npm install -g unreal-engine-mcp-server

然后所有 UE 项目都调用同一个全局命令。这种方式最省事，但我不推荐作为长期工程方案，因为不同项目会共享同一个 server 版本；全局包一升级，所有项目行为都可能变。

更合理的选择是这样：

个人实验、临时验证：用

复制代码

npx -y unreal-engine-mcp-server

接受它偶尔联网/缓存解析。

↕ MCP 协议连接，一般是 stdio 或 HTTP

stdio = standard input / standard output，来自操作系统和 Unix 命令行传统，不是 MCP 发明的。

在操作系统里，一个进程通常天然带三条标准流：

stdin：标准输入，别人可以往这个进程里写数据。
stdout：标准输出，这个进程把正常结果写出去。
stderr：标准错误，这个进程把日志、错误、调试信息写出去。

所以 MCP 里的 stdio transport 可以理解为：

MCP Client 启动一个本地 MCP Server 子进程，然后通过这个子进程的 stdin / stdout 传 JSON-RPC 消息。

一个固定端口，那么它天然只能稳定指向一个 UE Editor 实例。第二个 Editor 要么抢不到门牌号，要么需要另一个门牌号。

model 决定模型名，model_provider 决定请求走哪个 provider；[model_providers.<id>] 负责定义这个 provider 的 base_url、认证和 wire API。Codex CLI 和 IDE extension 共用同一个 config.toml。OpenAI Developers+2OpenAI Developers+2

复制代码

requires_openai_auth = true

含义更接近：这个 provider 仍然使用 Codex 当前 OpenAI 登录认证去拿 bearer token。它不是"填 tabcode key"的配置。如果 tabcode 是第三方转发服务，通常更应该用：
TOML

复制代码

env_key = "TABCODE_API_KEY"

如果另一个 UE 项目也启用了同一个 MCP Automation Bridge，并且默认也监听 8090,8091，它会和当前这个 UE 项目抢端口。
如果另一个项目也想用 chat-host，默认 8092 已经被当前这个 ZMDRender 的 chat-host 占用。
如果另一个项目复用了同一份插件源码或复制了当前插件目录，那源码逻辑当然会带过去；如果是独立插件副本，不会自动受影响。
API key 环境变量如 OPENAI_API_KEY 是系统/进程环境级概念，不是项目私有。设置了以后，任何使用同名 env var 的项目都能读到。

作者脑子里其实已经有了大量"隐含结构"：

哪部分是 temporary workaround

"讲结构"比"展示结果"慢很多。

改项目文件夹名称

比如：

原本：

复制代码

D:\UEProjects\ContentExamples

改成：

复制代码

D:\UEProjects\MyProject

这个会影响 Launcher 扫描到的名字。

三、改 .uproject 文件名

文件夹里会有：

复制代码

ContentExamples.uproject

改成：

复制代码

MyProject.uproject

这是最核心的一步。

删除旧缓存（非常重要）

删除项目里的：

复制代码

Binaries
Intermediate
Saved
DerivedDataCache
.vs

这些都会缓存旧名字。

不要删：

复制代码

Content
Config
Source
Plugins

如果是 C++ 项目（你这个大概率是）

因为你装了 MCP 插件，而且看起来像有源码项目。

那么还必须改：Source 文件夹名

例如：

复制代码

Source/ContentExamples

改：

复制代码

Source/MyProject

以及：

复制代码

Source/ContentExamples.Target.cs
Source/ContentExamplesEditor.Target.cs
ContentExamples.Build.cs

全部改名。

修改 Target.cs例如：
C#

复制代码

public class ContentExamplesTarget : TargetRules

改：
C#

复制代码

public class MyProjectTarget : TargetRules

还有构造函数名字一起改。

修改 Build.cs
C#

复制代码

public class ContentExamples : ModuleRules

改：
C#

复制代码

public class MyProject : ModuleRules

修改 .uproject

打开：

复制代码

{
    "Modules": [
        {
            "Name": "ContentExamples"
        }
    ]
}

改：

复制代码

{
    "Modules": [
        {
            "Name": "MyProject"
        }
    ]
}

改 Source 里的 API 宏

如果代码里有：

复制代码

CONTENTEXAMPLES_API

改：

复制代码

MYPROJECT_API

这是 UE 的 DLL 导出宏。

七、重新生成 VS 工程

右键：

复制代码

MyProject.uproject

选择：

复制代码

Generate Visual Studio project files

然后重新编译。

八、Launcher 名字来源

Epic Launcher 里的项目列表：

主要来自：

复制代码

.uproject 文件名

不是 Display Name。

所以你只改 Config 不够。

九、窗口标题来源

你右上角那个：

复制代码

ContentExamples

通常来自：

复制代码

Project Name

最终还是跟 .uproject 和模块名绑定。

十、额外：只改"显示名称"

如果你只想改编辑器显示名：

打开：

复制代码

Config/DefaultGame.ini

加入：
INI

复制代码

[/Script/EngineSettings.GeneralProjectSettings]
ProjectName=MyProject

但这不会彻底改内部项目名。

只是 UI 显示。

你现在这种情况，本质上是：

官方示例项目被复制后，

"资产内容"和"项目身份"还没分离。

UE 的项目名不是简单 UI 标签，而是：

模块名
编译目标名
DLL 名
API 宏
Launcher 索引
Editor Window Title
Saved 路径
Build Target

这一整组系统身份。

所以 UE 的 rename 比 Unity 更"工程级"。

网页通常走 OpenAI 自己的支付系统，可能会要求你重新输入卡信息。Google Play 里的卡不会自动同步到 OpenAI 网页支付。

OpenAI 说明，网页 ChatGPT billing、API billing、App Store/Google Play 订阅是分开的；Android 订阅由 Google Play 管理。OpenAI Help Center+1

Market Buy 体验一次。

Market Order 是"按当前市场价格立刻成交"。你在买入区域选择 Market，输入你想花多少 USDT，比如 100 USDT，然后点 Buy BTC。这样你就会用模拟资金买入一小部分 BTC。买完之后，你的账户里会少一些 USDT，多一些 BTC。

练习 Limit Order / 限价单 。

Limit Order 不是立刻成交，而是你指定一个价格等待市场打到那里。比如当前 BTC 是 80,228 USDT，你挂一个限价买单 79,500，意思是："只有跌到 79,500 附近，我才买。"如果价格一直没跌到，你的单子会挂在那里，不会成交。反过来，你也可以挂一个限价卖单，比如 82,000，意思是："涨到 82,000 附近，我才卖。"

Open Orders / 当前挂单 。

如果你挂了限价单但没有成交，通常会在下方的 Open Orders 里看到。你可以取消它。这个区域是理解交易系统的关键：不是你点了 Buy 就一定成交，订单类型决定它是立刻成交还是等待成交。

BTC/USDT 的意思是用 USDT 给 BTC 定价。价格 80,228 表示 1 BTC 约等于 80,228 USDT。

例如你有 0 个 BTC。

你买入 1 个 BTC：

0 BTC → +1 BTC

这叫开多。你现在有正向资产敞口，BTC 涨，你赚钱；BTC 跌，你亏钱。

然后你卖掉这个 1 个 BTC：

+1 BTC → 0 BTC

这叫平多，不是做空。你只是结束了上涨方向的仓位。

"做空"为什么叫空？

"空"最核心的逻辑来自"卖空"。

你卖出了一个你本来没有的东西。你的库存是空的，但你先卖了。于是你形成了一个负资产头寸。

比如：

你借来 1 个 BTC，按 70,000 美元卖掉。

后来 BTC 跌到 60,000 美元。

你用 60,000 美元买回 1 个 BTC 还掉。

你赚 10,000 美元差价。

这里的重点不是"卖"本身，而是你卖出后留下的是：

-1 BTC 的义务。

你不是单纯清仓，而是变成"欠一个资产"。所以叫空头、空仓、做空。

因为日常交易里只有两种动作：

买东西。

卖东西。

但金融市场多了一层东西：

仓位可以是负数。

现实生活里，你不能在没有苹果的情况下卖苹果；但金融市场里，你可以借苹果卖，也可以签一个未来交付苹果的合约，还可以用衍生品模拟这种效果。

一个"卖出"，既可能是平多，也可能是开空。

一个"买入"，既可能是开多，也可能是平空。

涨了赚钱，就是多；跌了赚钱，就是空。

头寸就是 position，

买了 1 个 BTC，期待它涨，这是一个 多头头寸 / long position。

借 BTC 卖出，或者开空单，期待它跌，这是一个 空头头寸 / short position。

"我长期持有 BTC，不打算卖。既然放着也是放着，可以借出去收一点利息。"

这就类似股票市场里的"融券"。某个机构长期持有一只股票，不想卖，但可以把股票借给做空者。做空者卖掉股票，之后再买回来还。原持有人收借券费。

普通人通常不会直接找到某个 BTC 持有人说："借我 1 个 BTC。"

实际流程通常是平台完成的。

在交易所开杠杆账户，平台背后可能有一个借贷池。这个池子里的 BTC 来自：

平台用户存入的 BTC；

愿意赚利息的出借用户；

机构客户；

平台自有库存；

外部借贷市场或做市商。

你点击"借币做空"时，看到的是一个按钮；但背后是平台在撮合借贷、控制抵押品、计算利息、设置强平线。

所以表面上是你向交易所借，底层可能是你向一群资产出借者借。

例如期货、永续合约、差价合约。这种情况下，通常不是有人真的把 BTC 借给你，而是你和另一个多头形成对赌结构。

你开空，他开多。

BTC 跌，你赚钱，他亏钱。

BTC 涨，他赚钱，你亏钱。

现货借币做空：真的借 BTC，卖掉，之后买回 BTC 归还。

合约做空：不一定借 BTC，只是建立一个价格下跌时盈利的合约头寸。

你前面说的"提前欠着一个 BTC"，更接近第一种，也就是现货借币做空。

别人为什么敢把 BTC 借给你？

因为你必须提供抵押品。

比如你想借 1 BTC，当前价值 50 万 CNY。平台不会让你空手借。它可能要求你抵押 60 万、70 万，甚至更多等值资产，比如 USDT、CNY、其他币。

如果 BTC 跌到 40 万，你赚钱，没问题。

但如果 BTC 从 50 万涨到 60 万、70 万，你亏损扩大。平台会要求你追加保证金。如果你不追加，平台会强制平仓：

它会用你的抵押品在市场上买回 BTC，替你还给出借方。

所以出借方真正依赖的不是你的信用，而是：

抵押品 + 平台风控 + 强制平仓机制。

这也解释了为什么做空有"爆仓"。

如果你借了 1 BTC 卖掉，拿到 50 万 CNY。

结果 BTC 不跌反涨到 80 万 CNY。

你要买回 1 BTC 就需要 80 万 CNY。

你原本卖出只拿到 50 万，中间差额 30 万就是亏损。

如果你账户里的保证金不够覆盖这个亏损，平台就会提前强平，避免你亏到还不起 BTC。

所以做空的风险比普通买入更危险：

买入 BTC，最多亏到接近 0。

做空 BTC，如果价格不断上涨，理论亏损可以无限扩大。

因为 BTC 可能从 50 万涨到 100 万、200 万、500 万，但不会低于 0。

mjs = JavaScript file treated as ES Module

overflow-visible! 复制代码

复制代码

const xxx = require('...');
module.exports = ...

在你的项目里，self-test.mjs、chat-host.mjs、verify-ai-workspace-principle.mjs 很可能是给 MCP / Codex / Node.js 工具链用的自动化脚本。它们不是 UE C++ 源码本体，而是"项目旁边的工具脚本"。

.ps1 的核心含义是：

overflow-visible! 复制代码

复制代码

ps1 = PowerShell script file

更接近 Windows 下的"批处理脚本"，但比 .bat 强很多，有对象管道、模块、错误处理、权限策略等。

启动另一个 Node 程序：

AI 不需要直接打开 UE，也不需要直接改 .uproject。它先启动一个本地 chat-host，这个 host 再作为"可通信的桥"。

.mjs 不是"又一个 UE 插件"。它不在 Unreal Editor 进程内部，也不能直接调用 GEditor、UWorld、AssetRegistry、UObject、FAssetToolsModule 这些 UE 内部对象。它能做的是：启动进程、开端口、收发 JSON、做 MCP 协议、组织请求、等待 UE 插件回应、把结果再转回给 Codex 或测试脚本。Node 官方文档里 .mjs 代表 ECMAScript Module 文件，也就是用 import/export 组织 JavaScript 模块；你截图里 node:http、node:net、node:child_process 正说明它在做网络通信和子进程控制。Node.js

UE Bridge 插件则相反。它在 Unreal Editor 进程内，通常由 C++/Blueprint/Python/Editor subsystem 之类组成。它的价值是"把外部请求落到 UE 的真实编辑器能力上"：创建 Actor、查找资产、改组件属性、保存包、调用 Editor Utility、读当前关卡、操作 Content Browser、触发编译、执行撤销事务等。外部 Node 层本身做不到这些，因为它不拥有 UE 内存空间，也没有 UE 类型系统和 Editor API 上下文。

为什么不把所有东西都写进 UE 插件？因为 UE 插件不适合承担所有外部协议和工具链职责。比如 MCP host、stdio/HTTP transport、Node 包生态、VS Code/Codex 集成、自动测试、跨项目路径解析、环境变量、CLI 启动，这些放在 Node 层更轻、更快、更容易迭代。UE 插件一改就可能要重新编译、重启 Editor、处理模块加载顺序，还要面对 UE 的生命周期和崩溃风险。

为什么不把所有东西都写在 Node？因为 Node 无法直接操作 UE 内部对象。它不能凭空知道当前选中的 Actor 是哪个，不能直接打开 UWorld，不能用 UE 的 Undo/Redo transaction，不能通过 UE 反射系统安全地改 UProperty，也不能直接调用 Editor-only C++ API。它必须通过 UE 内部的 Bridge 插件来"落地执行"。

不是说 UE 里的 agent 不存在，也不是说 UE 里的 agent 不是重点。

当前实际关系更像这样：

VS Code Codex -> Bridge WebSocket 诊断/验证入口 -> UE 插件里的 MCP AI Workspace / local operator -> 同一套 Bridge/UE Editor API 能力 -> 场景、Actor、相机、灯光、验证结果

所以这里确实没有"另一个 MCP resource 中转层"。我没有通过一个独立 MCP resource server 去读 UE 状态，而是直接用项目里的 Bridge 自动化通道驱动和验证 UE 内部 workspace。

关键点是：

UE 里的 agent / MCP AI Workspace 才是产品 focus。
VS Code 里的 Codex 只是开发者、调试者、验证者。
我用 inspect_editor_ui + submitProbeText 不是为了绕开 UE agent，而是为了自动把"理念 / continue"提交进 UE 里的 workspace 路径，并读取它产生的机器诊断。

证明 UE 内部 workspace 不是只响应第一句，而是能在已有状态上推进第二阶段。

continue 能工作，主要靠的是 UE 场景状态本身，不是靠一个完整的 agent memory。

现在的机制更像这样：

第一次"理念"执行后，UE 场景里出现或更新了这些带标签的对象：

MCP_Preview_KeyLight MCP_Preview_WarmAccentLight MCP_Preview_CompositionCamera MCP_Preview_LookPostProcess

第二次 continue 时，UE 插件重新观察当前场景：

这些 MCP_Preview_* 是否已经存在？是否有相机？是否有后处理？场景里最大的 static mesh subject 是谁？

如果发现四个 preview 对象已经存在，就判断这是"下一阶段"，于是做 subject-aware framing：

找到主体 -> 重新定位相机 -> 对准主体 -> 验证 forward dot

所以它保持上下文的来源是：

场景里已经存在的 MCP_Preview_* actor + 当前选中对象/静态网格 bounds + workspace 当前操作文本

而不是：

一个真正的长期计划数据库一个多轮 agent memory 一个持久化 task state machine

目前有一点点进程内状态，比如 workspace 会保留 LastOperationText，诊断 snapshot 也会发布当前状态；但真正决定 continue 下一步的关键，不是聊天记忆，而是 UE 世界里可查询、可验证的状态。

空间的摆放管理

股票背后通常有公司资产、现金流、利润、股东权益。债券背后有债务人信用、还本付息义务、破产清偿顺序。银行存款背后有银行负债、监管、准备金、存款保险等制度。法币虽然不再直接兑换黄金，但它有国家税收体系、法律偿债地位、中央银行、财政能力和强制结算网络作为信用基础。美联储曾明确解释，现代 fiat money 不可兑换为商品，价值来自信任，尤其是他人愿意接受它作为支付手段并相信其价值相对稳定。Federal Reserve

而很多加密货币的问题在于：

它既不是公司股权，不给你分红；也不是债权，不承诺还本付息；也不是国家货币，没有税收和法偿体系托底；也不是实物商品，没有工业消费需求。

所以你说"背后没有实际资产和信用"，对大量 crypto token 是成立的。尤其是 Meme 币、治理币、游戏币、空气项目币，它们很多时候背后只有一个叙事、一个社区、一个合约地址和一个价格曲线。

但为什么我不把它说成"唯一最大问题"？因为金融资产的价值不只来自"资产抵押"。有些东西即使没有现金流，也可能长期有市场价值，比如黄金、艺术品、收藏品、域名、奢侈品、游戏皮肤。它们的价值来自稀缺性、共识、文化、网络效应、流动性和可转售预期。BTC 支持者通常就是把 BTC 放在这一类里：不是公司，不是债券，而是一种稀缺的、可转移的、抗审查的数字商品或数字黄金叙事。

问题是，这种价值基础比股权和债权更"反身性"：

大家相信它有价值，所以它有价值；如果相信的人减少，价格锚就会很弱。

BTC：没有公司资产，也没有发行人信用。它的价值主要来自稀缺性叙事、网络共识、流动性、抗审查属性、机构化交易入口和"数字黄金"想象。它的问题不是"背后有公司不赚钱"，而是它根本不是公司。

ETH：比 BTC 多了一层网络使用价值，因为以太坊上有 Gas、智能合约、DeFi、NFT、稳定币结算等活动。但 ETH 持有人并不等于拥有以太坊基金会股权，也不等于拥有协议利润的法律索取权。它更像网络原生资产，不是传统股权。

稳定币 ：它们反而声称有资产支持，比如美元、短期国债、现金等。但风险转移到了储备真实性、赎回机制、监管、发行人信用和挤兑风险。ECB 最近也指出，稳定币通过锚定法币并用流动储备支持，暂时承担链上"现金"的角色；这说明稳定币的稳定性恰恰依赖外部法币和储备资产，而不是纯粹来自链上本身。European Central Bank BIS 也强调，稳定币是在把公帮信用引入加密生态，但又运行在传统结算系统之外，因此存在结构性张力。Bank for International Settlements

山寨币 / Meme 币 / 空气币：很多几乎没有资产、没有收入、没有真实使用需求、没有法律信用，价格主要靠叙事、社群、做市、交易所流动性和后续买盘。

金融资产的价值，最终不是停在价格曲线上，而是要问：它凭什么能让别人把食物、能源、房子、劳动力、技术、土地、时间、服务交给你？

CME Group Inc. is an American financial services company based in Chicago, Illinois. It operates financial derivatives exchanges, including the Chicago Mercantile Exchange, the Chicago Board of Trade, the New York Mercantile Exchange, and the Commodity Exchange. The company owns 27% of S&P Dow Jones Indices.

hover 的视频预览，不是视频卡片。

这两层是分开的。你现在这份脚本里，卡片用的是 searchCardWidth，而 hover 预览目前基本还是让 YouTube 自己决定，只是做了 width: 100%、height: auto 这类跟随式处理，所以它看起来会有一个"缩不下去"的有效下限。这个下限更像是 YouTube 预览组件自己的约束，不是卡片宽度参数本身。

我查到的一个相关实现也是把 hover 预览单独做成尺寸设置，不是绑在卡片列数上的：
https://greasyfork.org/en/scripts/2818-youtube-animated-thumbnails-preview-videos/code

所以更准确的做法是把它拆成两套参数：

卡片布局宽度
hover 预览尺寸

这样你缩卡片不会连带把悬浮预览一起压坏。

脚本其实把 Shorts 卡片和 hover 预览用的是同一套"按卡片铺满"的约束，但 hover 预览更像是一个独立播放器层，它需要单独裁切，不然两边就会露黑边。

"literal bool" 并不是一个特殊类型，而是 UE 蓝图里的一种 字面值（Literal）节点。它的作用是：

创建一个固定值：
- Make Literal Bool 就是创建一个固定的布尔值（true 或 false）。
- 类似的，还有 Make Literal Int、Make Literal Float 等，用于创建固定的整数、浮点数等。

区别于变量：

普通变量可以被修改、可以绑定到其他蓝图逻辑。
Literal 节点直接输出固定值，不会被蓝图运行时修改。

ethos

偏"精神气质、价值底色、群体文化"。比较高级，常用于品牌、组织、艺术风格。

例：这个团队的理念是开放协作。

The team's ethos is open collaboration.

ideology

偏"意识形态、政治/社会思想体系"。不要随便用来翻普通的"理念"，因为它带有政治或系统性价值观意味。

例：政治理念。

political ideology

mutex = mutual exclusion，互斥锁 / 互斥体。

它不是 UE 独有词，而是操作系统和并发编程里的概念：

当多个进程或线程可能同时改同一份关键资源时，系统会放一个"锁"。谁拿到锁，谁可以操作；其他人必须等。

在你截图这段里，关键不是"LiveCodingConsole.exe 还活着"，而是：

UE 的 Live Coding 编译链路里有一个 mutex，用来防止多个编译/热重载流程同时改当前项目的 C++ 二进制。

UE 官方文档里 Live Coding 的定位就是：在 Editor 或运行中的应用不关闭的情况下，重新编译 C++ 并 patch 当前二进制；它基于 Live++，也就是一个运行时热补丁机制，不是普通的离线全量编译。Epic Games Developers+1

所以这里的逻辑是：

你现在的插件 DLL / module 已经被 UnrealEditor 加载了。

Agent 想编译新的 C++。

但 UE 检测到 Live Coding 相关的互斥锁还处于占用状态。

于是普通 UBT 编译入口不敢继续写 DLL / PDB / intermediate 文件，避免出现"Editor 正在使用旧二进制，同时编译器又在覆盖它"的状态。

"survival" 是生产意义上的生存：没有文档，TA 会被自己的复杂性淹死。

"organization is critical" 则更偏 信息架构。TA 的工作很容易变成一堆散乱实验：一个材质球、一个蓝图、一个 Python 脚本、一个测试关卡、几个贴图、几个临时节点、几个视频教程笔记。短期看没问题，长期看就是灾难。

所以他说 organization critical，意思是 TA 必须能把东西分层：

视觉目标层 ：我要什么效果。
技术方案层 ：用 shader、后处理、Niagara、Blueprint、C++、Python、MCP、Editor Utility 还是 DCC 脚本。
资产规范层 ：贴图、模型、骨骼、UV、命名、目录结构。
运行时层 ：性能预算、平台差异、LOD、shader variants、memory、draw calls。
工具层 ：给美术/关卡/动画怎么用。
文档层：别人如何复现、修改、维护、扩展。

这句话背后的重点是：TA 不是只会"做一个看起来很酷的东西"的人，而是能让酷东西进入生产管线的人。

1. 探测和 fallback 在做什么

探测：构建脚本或 C++ 代码先去"猜环境"。

例如类似这种逻辑：

if (Directory.Exists("UE5.7的新模块路径")) { Add("新模块"); } else { Add("旧模块"); }

或者：

#if __has_include("新头文件.h") #include "新头文件.h" #else #include "旧头文件.h" #endif

fallback：如果首选路径失败，就走备用路径。

例如：

if (LoadObject(NewPath) == nullptr) { LoadObject(OldPath); }

这类代码本来是为了"一个插件同时支持很多 UE 版本/很多项目环境"。

但在你的项目里，目标已经是 UE 5.7，所以它们会变成：明明知道正确答案，还要每次先猜一遍，然后保留一堆不会走的路。

2. workaround 压住问题在做什么

workaround 就是"不修根因，先绕过去"。

比如构建脚本里有这种意思的逻辑：

// UE 5.6+ 把变量 shadowing 当成错误 // 先把它降级成 warning，让项目能编译 ShadowVariableWarningLevel = WarningLevel.Warning;

这不是修代码里的变量遮蔽，而是告诉编译器："别把这个当错误，先让我过。"

再比如旧 UE 里某些宏缺失，于是构建脚本强行定义一个：

GlobalDefinitions.Add("__has_feature(x)=0");

这也是 workaround：不是代码本身需要这个功能，而是为了绕过旧引擎头文件和 MSVC 的冲突。

直观区别

"探测和 fallback"像是：

先看看门 A 在不在；不在就试门 B；再不行试门 C。

"workaround 压住问题"像是：

门关不上，但先拿胶带贴住，让它看起来能用。

在你的场景里，我们知道只走 UE 5.7，所以更直接的写法应该是：

走 UE 5.7 的门。门有问题就修门，不保留 A/B/C 老路线。