摘要

开局准备页上有许多固定位置的槽位（技能、装备、兵种等），读取器对每个槽位把所有规范图标模板（多个参考变体、五种尺寸、合法位移）逐一做相关匹配，然后取前三名并按 0.75 分数与 0.08 领先门槛决定是否接受。这一步是准备页读取的耗时热点之一。

本实验的唯一候选是：把同一类槽位的全部模板放在一起做批量相关计算，再只对前四名用原算法精确复算，以期结果完全相同而更快。真实运行之前先做了合成预检，结果候选既更慢，又没有办法证明与原算法等价，于是按停止条件拒绝。真实的公共接口请求为 0，原图读取为 0，生产代码已恢复原样。

要回答的问题

批量计算能否在结果严格相等的前提下，让准备页的模板匹配更快？

数据与来源

  • 合成预检：固定种子 11、23、37、53，7/8/10/14 个槽位、16 个身份，多尺寸多参考，另含常量/并列、小模板库、NaN、跨槽伪峰和输入不可变等情况。
  • 原计划的真实对照：沿用一批已曝光的开发截图，两批共 155 个已知字段；基线和候选各最多 3 次调用（冷 B1、热 B1、热 B2），总上限 6 次、零重试。这部分没有执行。

方法

候选算法：

  1. 对同类槽位的全部规范模板做一次批量浮点相关计算，只取完整落在单个 96 像素槽位内的响应。
  2. 对初筛前四个身份，用原算法精确复算，恢复公开的分数、差值和偏移。
  3. 如果第四与第五名的初筛分数差 ≤0.001，就回退到原算法全部重算。0.001 只是计算安全边界，原 0.75/0.08 接收阈值不变。

验收：完整的公开响应（除计时字段外）必须严格类型和数值相等，不事后增加任何容差。

设置

一次组件计时：固定种子 11、116 个身份、14 个 80×80 槽位、每个参考五种尺寸；OpenCV 线程 24、优化开启（配置未改动）。这是合成核心计时，机器不是独占状态，不能推出真实接口或 App 的时延。

结果

指标 原算法 批量 + 精确复算
合成组件耗时 1.6141608 秒 2.7405050 秒（慢约 69.78%）
27 个合成案例的完整排名结果 — 与原算法完全相等

计时只做了一次，没有为了得到好看的数字追加预热或重测。

失败与负结果

  1. 没有性能收益。 候选反而慢了约 70%。
  2. 没有可证明的等价性。 “第四第五名初筛差 >0.001 就安全”只是经验条件：OpenCV 的合并计算对每个身份的误差没有可证明的统一上界，复算前四名不能保证被排除的身份不会成为原算法的前三名，或跨过 0.75/0.08 门槛。
  3. 构造的逻辑反例。 设原真实分数为 0.99、0.80、0.69、0.65、0.60、0.40，只在批量阶段把第一个身份的分数人为注入为 0.20：初筛边界仍大于 0.001，于是候选接受第二个身份，而原算法接受第一个。这是对安全判据逻辑的反例，并非观测到 OpenCV 实际产生了这么大的误差，不冒充真实像素误读。归档后 28 项合成测试全部通过，其中一项明确断言这个反例存在。

另外需要坦白：预执行方案里本来没有“精确前四复算 + 0.001 回退 + 单槽边界”这些细节，它们是在合成计时前才加入的新策略。负责人随后指出没有误差上界就不能用它证明安全，本实验按这条更严格的核查停止，没有事后补容差。

局限

  • 计时来自合成核心，不能代表真实接口或 App。
  • 真实截图上的等价性从未测试，因为预检已失败。
  • 预先写下的输入冻结文件只是未执行的草稿，不能当作运行结果。

结论与下一步

候选既无性能收益，也无普适等价证明，按停止条件拒绝；所有公开阈值、候选、分数语义、155 个标签和旧测量都不改。被拒的实现以只读历史素材形式保存，只用于合成回放；运行入口显式拒绝再次执行，防止误用这批预算。任何新的提速策略需要单独派工和协议，不能借这次失败现场换算法继续调参。