摘要
战斗日志（Logs）里，一次攻击通常写成两行：“A(数量) 攻击了 B(数量)”，紧接着“B 受到了 N 点伤害，死亡单位 M”。状态估计（SE）的正式“攻击证据”只接受这种相邻的攻击—伤害配对，才会进一步用伤害数字去约束对手的构筑。
问题是：很多攻击行没能配上——中间夹了别的事件（例如太阳圣盾先挡下伤害、反击后的自伤），或者伤害行被 OCR 读成了“未知”。上一轮只读审计发现：01:39 局已读的 6 条攻击 / 反击行，正式配对数为 0；16:57 局另有 5 条星之子的动作引用也没配上。这些动作原文在界面上完全不可见。
本实验新增一个 SE 私有的消费者：从原始请求的日志行里找出这些未配对的动作，连同其后最多 4 行原文（保留读不清的行），作为不进入预测的说明，复用 App 现有的攻击详情页和原图查看器展示。不关联伤害、不推断实例或攻击时的属性、不增加公共字段。在两份真实保存结果上，只新增了这些说明，其他所有结果逐字段相等。
要回答的问题
能否在不改动正式攻击配对和任何推断的前提下，把未配对的攻击动作和附近原文交给用户核对？
数据与来源
- 两段训练录像的已保存请求和结果：10 月 10 日 01:39 局 49 帧、16:57 局 58 帧。只重放公开 SE 入口，不新增 OCR、视频或模拟，不读取独立留出来源。
- 都是此前看过的训练来源，不是独立测试集。
方法
规则（实施前登记）：
- 每个来源页单独保留，不用时钟、同名、同数值去重或挑配。
- 读不清（UNKNOWN）或无法解析的行必须留在上下文里——上下文直接读原始日志行，而不经过会过滤未知行的处理步骤。
- 最多展开 24 条动作，每条之后最多 4 行；遇到下一条已读的攻击或反击就停；超出预算明确写“未展开”。单行过长时截短显示，但原请求不变。
- 已配对的动作不重复列出；不跨页拼接；不解析身份、不借面板、不调用规则、不数独立事件。
App 展示： 复用攻击详情；攻击摘要里加一个跳转；界面和保存的 HTML 正文各展示一次，普通文本导出也保留。原图链接只连到“说明首行与本次请求中明确帧 ID 完全对应”的那张图；不从日志正文里解析路径——正文里如果伪装写了“日志原图”，也不会产生链接。新说明不带实体 ID，因此不会被属性历史功能误当成生物属性解释。
设置
在两份保存请求上，修改前后各跑一次公开推断入口，对比完整结果。App 用隔离的离屏界面导入、真实点击验证，不启动用户的 App。
结果
| 真实保存输入 | 修改前 | 修改后 | 不变项 |
|---|---|---|---|
| 01:39 局，49 帧 | 未配对说明 0；正式配对 0 | 未配对原文 6 条，两个重复页分别保留 | 其余完整结果逐字段相等，正式配对仍 0 |
| 16:57 局，58 帧 | 未配对说明 0；正式配对 12 | 星之子未配对原文 5 条 | 其余完整结果逐字段相等，包括 12 个候选和织光者攻击 20 的参考 |
附近日志里出现的 821、899、1060 等受伤数字只作为原文显示，不认证是哪次攻击造成的。新说明可用于人工核对，但不代表命中条件已恢复或公式求解增加。
App 验收：生产快照写入 → 严格读取 → 隔离导入 → 实际点击跳转，打开第 32 帧和第 27 帧的日志原图、解码成功；两份请求 / 结果保持不变，两张截图已目视核对。点击前界面已显示 UNKNOWN、自伤和多个受伤者，没有出现“造成 821”之类的新配对。
软件检查：SE 相关 143 项、App 相关 86 项，去重共 229 项通过，其中本轮新增 21 项。功能不计算机制公式，没有新增模拟矩阵。
失败与负结果
- 接线前的回归测试准确复现了“0 条说明”（1 失败、13 通过），接入后 14 项通过。
- 初次补测试时把一条断言放到了另一个测试的末尾，执行到核心失败即停；接线前已移回原处，没有把夹具问题当生产失败。
- 触碰过的生产文件里还有 6 项既有的代码风格问题，已用旧版本逐项复现，记录在案，不宣称全文件清零。
- 24 条预算可能先被重复页占满；遗漏提示会保留。
局限
- 这只是文本窗口：读不清的行内部如果实际另有攻击，也只是显示出来，不认证因果。
- 渲染依赖结果与请求来自同一快照；当前保存读取和原图路径已验收，但不把未来所有调用方的来源一致性说成已证明。
- 部分 App 文件有前一轮未提交的共享改动；可用范围以工作区源码为准，不是当前安装版。全公式组合覆盖和独立准确率目标仍未完成。
结论与下一步
未配对的攻击不再被隐藏，用户可以对照原文和原图人工核对，而正式配对和推断一点没变。外部审阅支持收尾、不再扩大展示。
下一步：对主体可以归属的未配对攻击，检查能否复用已有的历史面板检查，输出条件性的攻击属性参考。先核对最近的状态、英雄变化、日志时序和生命周期；如果这些门槛阻断了，就如实说明，不挑选能解释 821 / 899 / 1060 的属性。（见 E033。）
Comments