摘要
游戏中有一个英雄技能“战技”：生物选择“等待”（推迟本回合行动）后，会获得一定比例的攻击加成。在一段训练录像（10 月 10 日 16:57）的已保存 58 帧中，第 32 帧的我方圣骑兵面板显示攻击 28、防御 24。SE（状态估计）已有的参考只算到 22/24（基础 + 英雄等），剩下 +6 攻击无法解释。但第 4 帧已读到英雄的战技是“高级”，第 12 帧的 Logs 战斗日志里也读到了“圣骑兵进行等待”——这两条已有信息都没有参与对照。
本实验让 SE 在同帧对照中消费这两条信息，并且不自己写等待公式，而是交给 Simulator（项目的规则模拟器）执行一次合法的等待动作。结果攻击从 22 变为 28.6，与面板的 28 差 −0.6，防御差 0。等待能解释主要增量，但不是精确匹配：模拟器输出小数，而客户端面板的取整规则还没被核实，所以没有把 28.6 截断成 28。
要回答的问题
已读的战技等级和等待日志，能否通过公开规则解释生物面板中原先无法解释的攻击增量？在什么时序前提下才允许使用它们？
数据与来源
只使用已保留的 16:57 训练局 58 帧自动结果和已有原图，没有新 OCR、没有重跑视频。
- 第 32 帧原图已目视确认 28/24，右侧 HUD 3/2/29。
- 第 12 帧日志的等待行由自动日志候选识别，归为我方、兵种唯一识别为圣骑兵，不是手写参考值。
- 公开基础值攻 12/防 17，与本机游戏安装资源中的单位文件一致；“基础攻击可能是 18”的猜想被否定，不改游戏知识库。
方法
- 新的私有组件复用公开的技能效果查询、战斗引擎和观察投影：按已读技能取比例，经合法的初始化和等待动作触发，不在 SE 里写等待公式。
- 只消费较早的、可归为我方、兵种匹配的等待日志。
- 保护条件：技能等级未知、未来/敌方/未知方日志、英雄身份断点、死亡/召唤/复活、后续可见的回合边界、未计入的状态、预算超时，都会阻止使用。
- 按外部审阅意见修正时序：等待只能使用在等待之前已读到的战技等级（第 4 帧），不能用之后才首次读到的等级（初版用了第 13 帧）；之后等级明确改变、未知、槽位替换或先变后恢复，都阻断持续参考。
- 身份断点补修：即使之后又读到原英雄的知识/技能，也不能恢复断点之前的等待；只有断点之后新读到的等待事件可以使用。
- “同方兵种唯一”仍是用户给的前提；没有消费用户手工对象绑定，说明文字中写明这一点。
设置
测试单进程运行；真实回放通过 App 的实际脚本和严格校验进入公开 SE，并在离屏 Qt 中显示。
结果
| 比较 | 修改前 | 修改后 |
|---|---|---|
| 原始面板、英雄、技能、日志 | 保留 | 完全保持 |
| 部分基础参考 | 22/24，剩余 +6/0 | 保留 |
| 已读战技与等待 | 未使用 | 合法等待 22/24 → 28.6/24；与原图 28/24 差 −0.6/0 |
| 攻击条件、敌方排除、其他结果 | 原输出 | 完全保持 |
58 帧的完整结果只有 3 条已有同帧对照说明改变：圣骑兵新增数值；另两个生物（深渊使者、修道院长）记录了等待但因状态阻断而不给数值。修正时序后，圣骑兵说明明确引用第 4 帧的战技高级。
测试： 新文件 34 个节点，包括 2 种生物 × 战斗魔法高级/专家 × 战技高级/专家的 8 组合法等待，另 4 组宝物“寻真之器”与等待的实际触发，以及小数差异、身份/时序/状态/预算负例。旧版函数加载后 9 个新正向场景全部失败，说明组件确实缺失。最终 SE 158 项、App 51 项，共 209 个不同软件节点通过。这些是规则触发的软件场景，不是真实录像准确率。
常驻进程： 按 App 原有的 0.2 秒推断预算和 1 秒续算计划，第二次请求返回了等待说明且已完成；不是全帧延迟或 p95。
后续有效期检查： 通过公开引擎跑一段 4 动作序列验证等待加成何时消失：
| 时点 | 回合 | 蓝方射手有效攻击 |
|---|---|---|
| 初始 | 1 | 6 |
| 红方等待 | 1 | 6 |
| 蓝方等待 | 1 | 7.8 |
| 蓝方攻击后（红方尚可行动） | 1 | 7.8，保持 |
| 进入下一回合 | 2 | 6，清除 |
所以不能加“等待后攻击即失效”的规则；加成在下一回合清除。全量核对保存 JSON：58 帧中有 14 页已读日志、55 条（含重复页）等待候选，第 2 回合标题首次出现在第 43 帧；第 32/38/40 帧的面板都早于此，不能把之后读到的标题当作这些面板已进入第 2 回合的证明。
失败与负结果
- 第一次回放在完成 SE 差异断言后，HTML 脚本漏传一个字段而失败；改用实际保存读取器后通过。
- 初版等待用了之后才读到的技能等级（外部审阅指出），7 个新场景修复前 5 失败。
- 初版只用 HUD 身份断点，漏了准备页身份变化；补修前两个场景 1 失败 1 通过。更早一组 4 个失败中有测试构造问题（重复等待被去重、矛盾 HUD），没有全部算作产品缺陷。
- 有效期探针的前几次尝试因布阵校验、字段名、参数类型用错而失败，不计入成功验证。
- 先只看了 7 个关键帧就说“整个 58 帧没有回合标题”，过于概括，后经全量检查纠正。
局限
- 28.6 与 28 的差异来自取整规则未知，没有认证客户端面板取整。
- 没有认证日志和面板处于同一回合；无图标只是没看到图标，不证明没有等待加成。
- 有效期的规则分支只核实到项目的 Simulator 层，依据的旧安装版本不能当作对当前商业游戏的重新认证。
- 整场独立实战准确率、安装版体验和全公式组合覆盖都未验收。
结论与下一步
已读的战技等级 + 较早的等待日志，经公开规则执行，能解释大部分原先无法解释的攻击增量，并且所有时序前提都写在说明中。外部审阅确认时序问题已解决、没有新的阻塞，支持停止等待专项。下一步回到已有真实输入中可见字段的漏读和误读，而不是继续扩建等待逻辑。
Comments