摘要

在《英雄无敌：上古纪元》里，打开法术书能看到每个法术当前的显示价格（报价）。我方英雄的技能、装备会改变价格，敌方的某些技能（例如让我方法术变贵的效果）也会。所以同一法术在不同时间的报价变化，是推断双方构筑的线索之一。

状态估计（SE）原来对每个法术只保留最新一次读数；旧的历史功能只在后一页等级读不出时才保留前一页的等级。结果是，已经读到的价格变化完全没有进入历史核对。

本实验新增一个历史模块：在同一合法归属段内，对每次直接读到的等级和费用的变化端点，分别使用此前同英雄准备页上的来源，调用已有的公开费用查询做条件核对。在一段训练录像（10 月 10 日 16:57）的 58 帧保存结果上，只新增 11 条不进入预测的历史说明，原请求和其余完整结果逐项相同。例如审判 28→42→28→42→56、力量之歌 4→6→4→6→8 的端点和来源都保留下来了。

一个重要的边界：书页报价不是实际支付。额外的软件探查发现，公开费用查询在施法次数已经耗尽时仍会给出报价（例如 4 / 6 / 8），所以不能用“合法施法参考”排除这种显示报价。

要回答的问题

同一法术的多次书页报价能否各自引用当时之前的配置来源做核对，而不被最新值覆盖？这样做会不会改动原有观察、候选或排除？

数据与来源

  • 一段用户选入训练集的录像（10 月 10 日 16:57，前 23 分钟）已保存的 58 帧请求，没有再做 OCR 或处理视频，没有读冻结或留出数据。
  • 其中 7 帧书页经已有的角色线索候选归属到我方同一英雄。
  • 第 9、10 帧原图已目视核对（不是独立测试集）。

方法

  1. 只在同一合法归属段内关联：不同英雄、角色不明、外来书页、重复法术或字段都不跨段关联；以后回到同一英雄也单列一段。
  2. 对直接读到的等级和费用的变化端点，分别采用此前同英雄准备页的来源，调用既有的公开费用查询和施法配置参考；不复制费用公式。
  3. 未知等级不补旧值；零和缺失不同；相同报价不单独生成变化，但稳定区间两端的原帧仍保留。
  4. 输出用已有的说明格式（不进入预测、来源 ID 为空），不写当前模型、不写命名预测或排除；每个法术仍以最新直接观察为当前值。
  5. 不改 Perception / 规则模拟器 / AI / App 的生产代码，不加字段。

设置

公开 SE 入口前后对比；App 的实际后台循环（刷新预算 0.2 秒、空闲续算 0.15 秒）验证能否在有限预算下完成。重任务限 8 核串行。

结果

真实保存输入： 原请求及完整结果中，除了新增 11 条非预测历史说明之外全部相同。审判 28→42→28→42→56；力量之歌 4→6→4→6→8；其他 9 个法术同样保留了变化端点和来源。修改前公开入口 6.468 秒、修改后 6.050 秒（冷单次，不作性能增益统计）。

原图核对： 第 9、10 帧的审判 28 / 42 与保存读数相符（媒体时间 377.8 秒 / 427.7 秒）。第 10 帧明确显示“敌方回合”，审判上覆盖着冷却数字 3；我方 HUD 魔力 250→222，净差 −28。仅凭两张图不能认证实际支付了 28，也不能认证唯一一次施法。第 10 帧力量之歌的保存等级为未知，仍保持未知，不因目视看到 4 级就加入“直接读取”。

后台预算： 最终版本第 4 次刷新完成，含启动的 58 帧共 13.293 秒，与无预算基准的完整输出相同；最长单次调用 2.641 秒。这是协作软预算，不是热单帧 p95 达标。冻结 App 严格校验、预测集合隔离、界面说明可见和中文截图目视都通过（说明正文较长，不算界面最终验收）。

额外探查（审阅发出后完成）： 在规则模拟器里，同一法术施法前 / 一次合法施法后 / 两次合法施法后报价分别为 4 / 6 / 8；该法术最多施放 2 次，第二次之后合法施法动作为 0。这证实公开费用查询在次数耗尽时仍会给出报价，但不证明录像里某帧的实际次数、界面规则或实际支付。据此只在说明里补了一句“不能用合法施法参考排除次数耗尽后的显示报价”，数值全部不变。

软件检查： 最终 372 个不同节点通过、12 个因符号链接权限跳过（79.45 秒），包括原有 30 个合法双施法组合和新增 4 组“合法动作后同一法术报价”——都是规则模拟器的软件例，不是录像准确率。新历史模块共 24 个场景（配置变化、未来、同帧、身份冲突、未知、请求隔离、隔段、失败回退、稳定端点、当前未知等）。

失败与负结果

  • 修改前新测试 10 失败 / 10 通过，失败都是“已有价格变化没有新历史行”；旧的保护负例保持。
  • 第一次实际后台没算完： 21 次请求后仍未完成，全部结果和控制台输出保留。性能剖析显示热请求 0.665 秒中历史部分 0.326 秒、67 次来源查询 0.194 秒、12 次价格查询 0.103 秒——重复的历史查询占满软预算，后续组件没及时完成。修正为每个观察主体的来源和施法参考在本请求内只算一次、每个来源页的公开固定项本请求内复用；没有跨请求缓存、没有加预算、没有删报价。之后第 4 次刷新完成。
  • 一个实验脚本有导入格式告警，已修。
  • 界面截图器第一次误用了错误的界面对象而失败，一次探查命令传错了参数；修正验收脚本后通过，没有改 App 生产代码。

局限

  • 书页报价不是支付，也没有自动读取“是否可施放 / 次数是否已耗尽”。最后一类较大的报价（例如 ×2 类）可能涉及不可施法时的界面显示语义，原因未认证，不判为敌方加价。
  • 当前施法配置参考只给合法参考，历史核对以“配置延续”为前提。
  • 只有一局训练录像，不是独立测试集；安装版的实时代码没有更新，用户只能导入新保存结果核对。

结论与下一步

同一法术的多次报价现在都会保留下来，并各自引用当时之前的来源做条件核对，原有结果不受影响。外部审阅支持限定收尾，并强调：这种一致性只有在“报价遵循可施法费用口径、配置和施法状态前提成立”时才有约束意义，未知的可施放性和次数不能当作已认证状态。

下一步只做一件事：复用已有的日志“失去魔力 / 施展法术”合法配对和 HUD 魔力历史，核对实际支付候选与历史书页报价。缺少同英雄、同法术、事件时序关联就保留未知；HUD 净差不单独认证支付；不重写配对或费用公式。