5.5 全书速查与总结

一页选型卡

需求 → 方案：
批量处理/检查       → EUW（蓝图或 Python）
视口点击/拖拽交互    → EdMode
资产批量编辑          → 属性矩阵（先看官方够不够）
菜单/工具栏入口       → UToolMenus 注册命令
独立工具窗口/分发     → 完整插件（Slate 或 EUW）
跨项目复用            → 工具仓库 + 插件
自动化/CI             → Commandlet / -ExecPythonScript

API 速查

常见错误模式 TOP 10

1. 批量操作没用 Transaction（不可撤销）
2. 绑定函数里做重活（UI 卡）
3. 扫磁盘而不是查 AssetRegistry（慢）
4. EditorOnly 代码放 Runtime 模块（打包炸）
5. UObject 原生指针绑委托（销毁后崩溃）
6. GetAsset() 一次加载上千资产（卡死）
7. 工具强依赖项目资产路径（不可复用）
8. 没有默认值/预览（用户不会用）
9. 全局委托忘解绑（编辑器持续变慢）
10. 没日志（出问题无法复盘）

思维框架

工具开发的三个根本问题，每次开工前问自己：

1. 给谁用（决定 UI 形态和精密程度）
2. 主路径几步（决定体验）
3. 错了怎么回（决定信任）

与本系列其他书的联动

• 工具的 UI 基础（UMG）见《UE5 蓝图与 C++ 混合开发实战心得》
• 工具检查的技能/配置数据标准见《UE5 GAS 完全实战》
• 性能分析通用方法（Insights/stat）见《UE5 性能优化实战》
• 自动化构建后可直接配合第三书的发布清单

最后

写工具有一种特殊的成就感：它不像游戏功能藏在玩家看不到的代码里，工具**每天被同事看见、使用、议论」。一个让策划每天少加半小时班的工具，价值不亚于一个精美的游戏系统。技术上工具是「小」的，但它对人效的杠杆是「大」的——这是我认为 UE 程序员最值得投入的方向之一。

心得：全书其实只想传递一句话：工具是产品，用户是同事。用做产品的心态做工具——找用户需求、打磨体验、迭代、收集反馈——工具自然会成功。大多数「没人用的工具」都是因为被当成「技术练习」而不是产品。