E018：把已经算好的战斗魔法加成用进属性变化解释

摘要

战斗中打开生物面板能看到它的攻击、防御。这些数值是“生物基础值 + 英雄攻防 + 技能（如战斗魔法）+ 状态效果 + …”叠加的结果。**状态估计（SE）**会比较同一兵种前后两次面板，尝试解释变化来自哪里——这能帮助发现对方施加的效果或隐藏的构筑。

问题是：一段训练录像里修道院长的攻击从 29 变成 30，同期英雄攻击没变（3 → 3），SE 就把 +1 全部列为“其它净变化”。但同一次请求里，SE 早已算出“战斗魔法专家”给生物的攻击参考从 6 变成了 7（因为英雄法强从 27 涨到 28）——历史解释只是没用上这个已经算好的数字。

修复后，历史解释直接复用已算出的组件：两个真实例子分别分解为“英雄 +0、战斗魔法参考 +1、其它 +0”和“英雄 +0、战斗魔法参考 +1、其它 +1”。只有这两条说明文字改变，其他所有结果完全相同。

要回答的问题

能否在不新增公式、不改变观察和命中条件的前提下，让属性历史解释用上同一请求里已经算出的战斗魔法组件？

数据与来源

两份已保存的截图请求，来自 10 月 10 日两段已授权保留的训练录像：16:57 那段 58 帧，01:39 那段 49 帧。没有新 OCR、新视频或安装。

方法

根因

SE 主入口先生成生物历史解释，之后才计算“准备页参考”和“当前面板参考”这两个组件。历史解释只有 HUD 的英雄攻防历史，不知道后面已经算好的战斗魔法贡献。这是 SE 内部装配顺序的遗漏，不是 OCR 漏读。

修正

准备页参考和当前面板参考把已算出的组件和来源写入一个本次请求内的私有字典。
新的历史组件比较：同方、同英雄、同一身份连续段、生物资料基础不变的两端都有已知参考时，依次列出英雄变化、战斗魔法参考变化和剩余净变化。不增加规则查询，不复制伤害公式。
调整计算顺序，但保持原有输出顺序；资料不全时仍走原来的英雄差值解释。
不变的边界：同方同兵种视为同一堆只是用户给定的前提；显式区分实例的模拟数据不进入这条历史；身份断点、生命周期和未知组件仍然阻止传播。战斗魔法参考只是部分组件，不包括所有宝物交互、特长和状态；剩余为 0 也可能是抵消，不能证明唯一原因或敌方无技能。

设置

用 SE 公开入口在两份请求上修复前后各跑一次，不手工替换任何识别数值；再用 Battle App 的保存/严格读取/文件夹导入/界面点击流程核对实际显示（禁止启动识别提供方）。

结果

训练来源	旧历史解释	修复后分解
16:57，修道院长（342.7 秒 → 496.0 秒）	生物攻 29 → 30，英雄攻 3 → 3；其它 +1	法强 27 → 28、知识 20 → 20、战斗魔法专家；攻击参考 6 → 7；英雄 +0、战斗魔法参考 +1、其它 +0
01:39，凤凰（423.2 秒 → 571.0 秒）	生物攻 52 → 54，英雄攻 9 → 9；其它 +2	法强 29 → 31、知识 17 → 17；已读战斗魔法专家与“战斗法师权威”，参考 11 → 12；英雄 +0、战斗魔法参考 +1、其它 +1

第二例必须用上已读的子技能，只按专家基础比例会算成 7 → 7。两例的晚端都还有未完全解释的状态效果，所以不能说“战斗魔法就是唯一原因”。

比较：58 帧请求只有修道院长、49 帧请求只有凤凰的一条历史说明改变；所有观察、攻击证据（含命中条件）、排除项、候选和其他单位结果完全相同。

App 实际点击“属性对照 → 我方生物攻击”，完整说明等于生产呈现函数的输出，截图已目视。两份新的可导入结果另存，原分析保留。源码消费已验证；安装版 App 没有更新。

软件测试

新测试文件最终 19 项：5 个真实保存帧直接复用（真实前缀不借未来读数）、4 项软件扰动（未知技能档位、未知法强、未来准备页、换英雄打断）、8 种在规则模拟器里实际触发的规则组合（如英勇攻击触发与到期、战斗魔法高级/专家、相关宝物有无；8 组前后值独立手算）、2 种合法施法组合、1 个同阵营同兵种的原体/镜像实例负例；审阅后补了“旧准备页攻击与当前 HUD 冲突时只写入一次并用当前值”和“英雄 A → B → A 不跨身份断点合并”。合并去重后 419 项不同软件检查通过。这些测试的触发事件没有转成日志参与因果归属，不代表覆盖全部机制。

失败与负结果

首轮新测试 7 通过 9 失败：8 项是测试里用错了序列化方法，1 项错误假设某个更早前缀已有阵营关联（实际要到 F008 才有）。修正测试工具和前缀，没有为迎合错误预期改生产代码。
用修复前的历史消费者跑同一批新测试：11 失败 5 通过——证明消费缺口存在，但不代表 11 个独立实战缺陷（部分是新输出要求）。
两次重放耗时（约 5.00 秒含规则初始化、0.82 秒）只是本次耗时，不是性能基准。

局限

两个例子都来自已曝光训练材料，不是独立准确率。
时间前提按早端/晚端分别表达，不认定整段历史持续有效。
外部审阅支持收尾，但没有独立运行仓库或核验商业游戏；最后两项补强是本地依据审阅意见做的。
全实体/逐公式组合、独立真实准确率、完整命中解释和安装版都未达标。

结论与下一步

“已经算出来的组件没被下游用上”是一类容易被忽略的错误，修复只改变了一条说明文字，却让属性变化的解释从“+1 原因不明”变成可追溯的条件分解。下一步建议：在现有时效和状态门槛下，让多次已读面板的来源筛选共同约束同一候选集，帮助用户看到候选如何收缩；先检查已有入口，避免重建一套跟踪平台。