1.1 为什么要写编辑器工具：算一笔 ROI 的账

一笔账

策划每天要给 50 个怪物的「等级」属性 +1。手工操作：打开资产 → 找到属性 → 改 → 保存，每个约 20 秒，50 个就是 17 分钟。一天一次，一个月 8.5 小时，两个人做就 17 小时——一个工具写两小时，一次结清，之后零成本。这就是编辑器工具的 ROI：把重复劳动变成一次性的代码投入。

但工具的价值不止省时间，还有三个隐性收益：

  1. 消除人为错误。人手工改 500 个资产，错 2% 就是 10 个错误，混进版本里很难查。脚本错的要么是 0 个，要么是全错（一眼就能发现）。
  2. 知识沉淀。一个「批量检查配置一致性」工具，实际是把团队的规范写成了可执行的代码——规范文档没人读，但工具会跑。
  3. 解放策划的创造力。策划不用因为「操作太麻烦」而在设计上妥协。

什么值得做成工具

不是所有重复都值得工具化。判断公式：频率 × 单次耗时 ÷ 工具开发时间。经验阈值：

场景 值不值
一次性导出一批数据（用一次） 通常不值，除非数据量大到手工易错
每天做的批量操作（配置、检查、导出） 值
每个新人都会踩的流程（导入设置、命名修正） 值（且顺带标准化）
需要多人协作一致性校验 值（检查工具）
复杂艺术性操作（调灯光、摆场景） 不值，工具替代不了审美

工具的三种用户

写工具前先想清楚「谁用」，这决定了 UI 复杂度：

  1. 自己/程序员：控制台命令就行，没 UI 也行
  2. 策划/美术：必须有界面，每个输入都要清晰提示，一次错操作要能撤销
  3. CI/自动化流程：命令行可运行、无 UI、可日志输出——完全不同的设计（第五章详述）

给非程序员做工具时，默认他们不会读说明文档。界面上的每个参数要有合理的默认值，「一键执行」按钮要显眼，危险操作（删除、覆盖）要有确认。这条心法是从血的教训里来的：曾有个「批量重命名」工具，预览列表和实际执行是两个按钮，策划没点预览直接执行，一下重命名了半个项目目录——后来所有「写操作类」工具都强制先预览。

工具的维护成本

工具写完那一刻成本最低。之后每次引擎升级、每次项目结构调整，工具都要维护。降低长期成本的三个习惯：

  • 用稳定 API：Asset Registry、Subsystem、Editor Utility Library 这些公开接口稳定性高；内部编辑器私有类（FLevelEditorModule 的内部窗口）升级时容易炸
  • 工具自身要有测试：至少跑过一遍真实数据；关键工具加自动化冒烟测试
  • 留日志：工具执行了什么、改了哪些资产，输出到日志。出问题能回溯

心得：团队里最容易低估的工具价值是「检查类工具」（不是生成类）。批量生成省的是时间，一致性检查省的是线上事故。我们项目上线前必跑的三个自研检查工具：资产引用缺失检查、配置表 ID 冲突检查、蓝图编译警告清理——每个都拦截过真实事故。