“贴图不要太大”“命名应当规范”“无用资源需要清理”——这些要求很容易写进文档。但当资产数量增加，靠每个人记住每一条要求，就很难持续得到一致的结果。
资产检测工具要做的一件事，就是把这些描述变成可以重复执行的判断。设计规则时，我更关注规则能否被理解、定位和维护，而不只是能否输出一个红色的错误。
先把一句话拆开
以一个虚构要求为例：“演示目录中的二维贴图，最大边长不超过 2,048 像素。”至少有三个部分需要独立表达。
| 组成 | 需要回答的问题 | 示例 |
|---|---|---|
| 范围 Scope | 哪些对象参加检查？ | 演示目录内的二维贴图 |
| 条件 Condition | 怎样算符合要求？ | 宽、高的较大值 ≤ 2,048 |
| 响应 Response | 发现问题后如何处理？ | 记录对象、实际值与期望值 |
这里还有一个容易忽略的问题：“边长”究竟指源图尺寸，还是某个平台和配置下使用的尺寸？同一句自然语言可以对应不同检查。规则必须明确数值的来源，报告也应展示这一口径。
scope: DemoTextures / Texture2D
measure: max(SourceWidth, SourceHeight)
expect: value <= 2048
report: asset + measuredValue + expectedValue
action: review让结果携带足够的证据
“贴图不符合规范”不足以帮助使用者处理问题。更有用的结果是：“T_DemoStone_BC 的源图最大边长为 4,096，本规则要求不超过 2,048。”这给出了对象、实际值与预期值，使用者无需重新猜测检测逻辑。
检查结果还应区分“符合”“不符合”与“未能检查”。如果对象没有成功读取，或所需信息当前不可用，就不能把缺少结果当成通过。跳过检查也应留下原因，避免报告看起来一切正常，却漏掉了关键对象。
把检查与修改分开设计
发现问题，并不代表工具已经知道唯一正确的修改方式。贴图尺寸超出阈值，可能需要调整使用策略，也可能需要重新制作源图。自动处理应只覆盖目的明确、影响范围可理解的情况。
一个可维护的处理流程，可以先显示目标对象与拟修改内容，再执行动作，最后重新检查。只有复检符合条件，才能说明这个问题在当前检查口径下得到解决。动作执行完成，与检查结果通过，是两个不同的信息。
对于不适合自动处理的问题，清晰的定位和解释本身就有价值。不要为了让每条规则都有修复按钮，隐去需要制作人员判断的部分。
把规则当作持续维护的内容
规范会变化，目录和资产类别也会变化。规则应有稳定的标识、明确的适用范围，以及能够解释例外的记录。调整阈值后，用少量符合、不符合和信息缺失的样例重新检查，比只观察报错数量更有意义。
这也是我介绍 ResourceToolkit 时希望先讲清楚的设计方向：让规范有明确的表达，让结果有可追溯的依据，让处理后的状态能够再次验证。规则数量可以逐步增加，使用者对结果的信任需要从第一条规则开始建立。
首页的交互示例展示了阈值、判断与复检之间的关系。它只修改浏览器里的虚构数据，不代表 UE 中的真实资产处理行为。