上古纪元：读懂、推断、模拟一场战斗

先知道模拟器为什么要做、做到哪里。

1. S00从游戏规则到可用的战斗助手Simulator、资料库、界面与 AI 各负责什么；一次规则修正怎样传到决策，以及 S 系列如何维护设计。

一次攻击怎样结算，生物和魔法怎样共用机制，以及怎样测试规则之间的相互触发（原生审计、模糊测试、覆盖率）。

1. S20一次攻击怎样正确结算并回放为什么双击不能把第一击乘二；按伤害包更新状态，记录处决与死亡归因，并用规则版本门控让旧存档按自己的规则逐字节回放。
2. S21让生物和魔法共用机制，而不是共用一串特例从反伤触发天堂之刃，到把 157 个生物导出成一份可核验的定义：Simulator 怎样用强类型配置、注册表和共享机制减少重复修补，又怎样诚实地列出仍写死在代码里的特例。
3. S22怎样测试一个规则会相互触发的战斗模拟器用受控场景、预览差分、带复现存档的崩溃模糊测试、机制组合与行覆盖统计及并行成对测试，寻找规则组合中的错误，并区分程序自洽与真实规则一致。

比较行动、验证简单规则，再到当前最强的公平搜索 Public Quick。

1. S40AI 怎样公平比较普攻、猛攻和等待只用玩家可见信息比较行动：公开攻击情景查询、不确定性与4秒预算，以及怎样用足量配对排位和独立留出来源判断一个新策略是否真的更好。
2. S41规则型 AI 的独立验证：从威胁圈到英雄无敌三式从 v59 错题诊断、题库与排位的背离、排位噪声底，到威胁圈 T 与“打得到就打”的 H3：用冻结协议、随机对照和新来源留出，判断一条简单规则是否真的让 AI 变强。
3. S42只用玩家可见信息的搜索：Public Quick研究搜索 quick 明显强于规则 AI，但它读取对手隐藏构筑。本文记录怎样只用公开战场、自己的构筑和攻击悬停预览重建一个可搜索的局面，在 4 秒实时预算内对英雄无敌三式规则 AI 取得 +0.53 的来源优势，以及这条路线的边界。

训练路线，以及没有成功的尝试。

1. S50学习型 AI：从行为克隆到结构化动作特征回顾此前 PPO、行为克隆与交叉熵搜索为什么都没有通过独立验收，再用生物配置导出和每动作 351 维的结构化特征重新检验：一个小模型能否学会规则 AI 的落点选择。

搜索 AI、规则 AI 与对局评估：候选、视野、估值和排位。

1. 0000实验 0000：从可审计战术 AI 到自对战学习的路线图2026-10-06 写下的研究路线：先把战术搜索做成可检查的五层结构，再按固定顺序引入学习；这是一份规划记录，没有训练或棋力结论。
2. 0001实验 0001：下一阶段 AI 算法的外部讨论与本地判断一份从 2026-10-12 起持续追加的方向讨论记录：每轮把本地实验结果交给外部 GPT 审阅，再由本地核对取舍；记录本身完整，但其中多数路线以负结果结案。
3. 0002实验 0002：算法调研外部审阅的核对与修订计划对一份 16 页战斗 AI 算法调研的外部审阅逐条核对：两项信息泄漏风险当天实测为 0 处泄漏，几处报告错误列入修订，并定下不需要训练网络的五个后续实验。
4. 0003实验 0003：反击配合视野——定位一个循环并做有界原型确认一处 100 回合平局循环来自“两支友军都不愿先吃反击”的短视评分；有界原型能自行打破循环，但在 36 道开发题上同样是 31/36，并新增两处参考偏差，未上线。
5. 0005实验 0005：完整攻击序列候选——已接入，暂不替换默认 v55把“主击、反击、追加击”整段伤害计入评分的实验候选接入完整对局；12 个开发场景胜局 0/12→4/12，但 64 局冻结对照 20/32 对 20/32，没有显示优势，默认 v55 保留。
6. 0006实验 0006：随机机会与根动作价值归因对两个已保存的搜索案例逐项拆账：负士气等随机检查与执行一致，但发现一局里相同可见历史下后续攻击选择只因随机数状态不同而改变，属于局部风险证据，未修改 AI。
7. 0007实验 0007：增量搜索——先用少量样本筛选，完整确认后再改选离线控制器要求两样本筛选出的改选必须经四样本完整确认才发布；固定审计发现低样本会漏选和反转，但四秒内确认覆盖仍只有 12/27，最终动作与对照完全相同。
8. 0008实验 0008：保留 quick 的协同攻击比较与单方交叉对战新控制器只在 quick 选择移动或等待时提出“耗掉反击再由友军跟进”的协同攻击并同口径比较；36 个开发初态的 72 组单方替换中 1 组平转胜、71 组胜负相同，未发现退化。
9. 0009实验 0009：协同攻击在新压力场景、不同对手与整军规模下的检验8 个新压力模板 × 双方颜色 × 三种伤害配方对三种对手共 288 局续玩：144 组相关比较中 9 组负转胜、135 组胜负相同、无退化；14 堆完整开局比较约 0.39 秒。
10. 0010实验 0010：协同攻击的截止时间修复与多样本复查修复“校验刚结束就超时仍接受改选”的预算边界；对 48 个既有压力开局中 10 对实际比较改用 1/2/4 个随机样本复查，选择全部相同。
11. 0011实验 0011：协同候选在多个随机世界中的覆盖复现了“首个假想世界里触发士气额外行动导致漏掉协同候选”的问题；改为在四个世界中取候选并集后，24 个相关变体中 4 处由移动改为攻击；成对续玩里新首步四组都较快取胜，旧首步两组 100 步未结束。
12. 0012实验 0012：动态属性刷新时保留未变部队，让已有缓存命中Simulator 在部队属性重算结果完全不变时保留原对象，使后续缓存可以复用；14 堆法术比较节点中位耗时 1.9304→1.7078 秒（约 −11.5%），结果完全一致，但完整 deep 开局仍约 65.9 秒。
13. 0013实验 0013：等价的专注范围法术选点——减少重复结算范围伤害法术的不同落点若命中完全相同的单位集合，搜索只保留足够的代表；27 个状态的完整比较转移 12,867→10,953（约 −14.9%）且评分全同，但四秒内的确认覆盖没有提高（13→12/27）。
14. 0014实验 0014：公平搜索方案——从当前公开观察重建局面2026-10-10 的方案记录：探针显示“按公开历史逐事件重放”在一两回合内就耗尽 4096 次试验预算，因此提议改为从当前一帧的公开观察直接重建可搜索局面，等待用户决定是否开工。
15. 0015实验 0015：战技候选 v7——近战兵种的备用攻击为黑龙、刺客等兵种的“战技”备用攻击补上公开规则支持，并做了只在战技更优时才使用的私有候选 v7；镜像自对战 200 局 v7 与 v6 各 100 胜，看不出强弱差别，不晋升默认。
16. 0016实验 0016：固定预算消融——搜索能给公平 AI 加多少在战术题库和镜像排位上比较公平 AI 与几种“真实走一步”的搜索变体：题库上多对 5–9 题，镜像排位中全菜单走一步对公平 AI 得 90.0%，但只在公平 AI 前 3 候选上走一步仅 66.3%。
17. 0017实验 0017：狂暴类法术评分复用已有结算回执搜索已真实执行过一次强制攻击法术时，评分直接复用该转移，不再预览重算；27 个状态少做 696 次施法结算、总耗时约 −5.9%，评分与选择全同，但四秒确认量没有增加。
18. 0018实验 0018：英雄与法术状态下协同攻击的离线兼容性和成本把协同攻击比较扩到有英雄和法术的局面：27 个冻结状态全部在四秒内返回合法动作、回放一致，只有 1 处进入比较且仍保留原移动；一个 14 堆、314 个施法选项的节点完整比较 3.0553 秒。
19. 0019实验 0019：英雄协同扩大检查与短视评分反例123 个输入上多世界候选发现与单世界最终动作全同、续玩无收益无退化；但定向反例显示被拒绝的攻击在 8 个随机后续中全胜、等待仅 3 胜，而深度 2/3/4 的选择在等待与攻击间反复。
20. 0020实验 0020：增量根动作比较的离线原型与证据边界先完成 quick、再逐对比较挑战动作的离线原型：10 个保存检查点各完成 8–12 对比较，只有 1 处改选；新旧动作各续玩 9 组，全部获胜，没有胜负改善证据。
21. 0021实验 0021：增量搜索中复用随机样本与提前加深扩大随机样本时复用已算好的精确值，使前两阶段转移 5,341→4,609 且结果全同，但四秒内比较数仍是 258 对 258；另试“先加深”日程，完成深层比较的状态 13→18/27，却暴露出两样本临时改选再反转的问题，未改默认。
22. 0022实验 0022：生命周期规则修复前的完整对局基线修复尸体禁疗等生命周期规则之前，用七个固定场景各跑一局完整对战作基线：7 局全部自然终局、448 次决策全部精确回放，但原测试集的地形覆盖检查没有通过；同时在一局正常对战里复现了“尸体上的禁疗被提前解除”的缺陷。
23. 0023实验 0023：生命周期修复后的小规模换边回归在修复尸体禁疗计时后，用 3 个固定种子各换边打两局，比较当前公开战术 AI v54 与保留基线 v51：6 局全部自然终局并精确回放，3 比 3，没有显示提升；仪式与放逐动作一次都没有出现。
24. 0024实验 0024：按公开“清除范围”估值的生命周期候选 AI让候选 AI 用 Simulator 公开的复活/清除结果区间给复活与放逐类法术估值，在 14 个定向场景和 12 对换边整局上与 v54 比较：整局 12 比 12，没有胜率提升；候选在自然对局里实际选了 5 次复活，基线 0 次。
25. 0025实验 0025：14 个冻结的生命周期决策场景用 14 个受控开局检验尸体复活与仪式召唤物清除：引擎结果全部正确并精确回放，两版公开 AI 都没选必然无效的复活；但 AI 不给可能有效的复活和清除估值，而且有无隐藏保护的两个世界公开信息完全相同，原定“必须区分”的要求无法实现。
26. 0026实验 0026：规则 v366 下的生命周期完整对局回归规则升级到 v366 后，按原协议重跑生命周期候选的 24 局换边整局、14 个定向场景和 6 局 v54/v51 对照：全部自然终局并精确回放，胜负仍为 12 比 12 和 3 比 3，24 局胜者与事件数与 v365 历史批次一致；没有新策略或默认替换。
27. 0027实验 0027：攻击序列候选进入混编对局——目标选择改善，等待仍偏保守把基于公开攻击序列查询的候选 v3 放进 16 组双方 3–5 队的混编对局（64 局），与默认 v55 比较：胜局 10 对 8、造成伤害更多，但新增胜局来自同一配置的两个版本，且旧候选也能拿到；等待次数翻倍、从未使用疾速猛攻，默认保持 v55。
28. 0028实验 0028：搜索视野末端补上敌方回应——固定 12 对诊断在搜索叶子之后最多再追加两次行动，让敌方至少回应一次，检查 12 对固定的根动作比较：只有 3 对完整算完，其余因追加上限或时间上限而未知；两个“等待改攻击”的例子在续玩中胜负不变、剩余生命一增一减。方案不接入默认 AI。
29. 0029实验 0029：用剩余敌军生命给“靠近”收益封顶复盘发现 AI 在能一击制胜时仍选择追逐移动，于是给靠近敌人的移动收益加上“不超过敌军剩余生命价值”的上限（候选 v4）。冻结的 64 局里 64 局自然终局，胜局 14 对 14，只有一局提前结束；默认 v55 保持。
30. 0030实验 0030：公开攻击序列查询的延迟预算测量 Simulator 公开攻击序列查询的本地耗时，暂定单次查询 p95 预算 2 毫秒：三个场景 p95 为 0.026–0.159 毫秒，六个进攻面一次扫描 p95 1.316 毫秒，均在预算内；这只是本地抽样，不是所有局面的上限。
31. 0031实验 0031：公平 AI v59——“双方皆可施放”的负面状态按极性估值用户指出 AI 第一回合像没放魔法；重放后发现 AI 其实施了暗影增幅，但同时暴露一个估值错误：目标阵营为“任意”的负面状态（狂暴）被当成对己方有利。v59 按公开状态标签定正负，狂暴对己方改为负分，原场景选择不变。
32. 0033实验 0033：狂暴普攻与疾速猛攻的完整对局基线在一个真实施放狂暴的窄场景族里，比较默认 v55、首个非免费动作改普攻、改疾速猛攻三条分支并打到终局：36 局全部自然终局，v55 每次先等待再跳过、12 局全败；改攻击后有 3 局转胜，但普攻与猛攻孰优随等级而变。
33. 0034实验 0034：仪式召唤物清除的受控完整对局覆盖自然对局里从未出现放逐，于是用合法脚本前奏造出一个“远处召唤物可被清除”的决策点，再交给公开 AI 打完：12 局全部自然终局并精确回放；候选 AI 实际放逐 2 次，一次清空召唤物、一次被隐藏保护挡住白白耗费资源。
34. 0035实验 0035：每回合法术输出偏好——首批 48 局完整对局候选策略每回合开头决定是否“偏重直伤法术”，最多替换一次公平 AI 的非直伤施法。12 个来源 48 局全部自然终局：开发集无变化，保留集 9 胜 7 负→11 胜 5 负，2 个来源改善、0 个退化，达到“值得另做独立确认”的工程门槛；改善都来自蓝方使用审判。
35. 0036实验 0036：搜索截断路径、等待消融与叶子续玩追踪搜索在深度 2/3/4 时“等待/攻击/等待”来回翻转的具体路径：原因是不同样本在不同单位处截断，一个士气额外行动的样本把平均值拉向攻击；单独去掉“立即恢复的等待”无效；16 条叶子续玩全部终局，其中 4 对评分偏好与续玩胜负相反。没有找到可直接上线的修复。
36. 0037实验 0037：搜索缓存不能把剪枝界限当精确值查 deep 档延迟时发现一个独立的正确性错误：子树被剪枝时本层只得到上界或下界，旧代码却把它当精确值缓存。用可手算的小树复现后修复，同批又让静态分数已关闭窗口时提前返回；开局 deep 决策 90.481→75.603 秒、选择不变，但仍超过一分钟，延迟未达标。
37. 0043实验 0043：战术首步的成对续玩——回合得分与整局结果取 quick 与改进版在 36 道战术题中给出不同首步的 7 处，从同一状态分别强制旧/新首步，再用三种固定策略续玩到底：42 条分支 41 条自然终局，每种续玩各有 1 对结果改善、6 对不变、0 对退化；还发现一局 399 步无伤害的追逐循环。
38. 0044实验 0044：用可精确求解的小战术题检查 AI 的单步选择从 90 个随机小局面中按结构筛出 36 道有唯一精确答案的一回合战术题；公平 AI 答对 24/36，搜索 quick 答对 31/36，公平 AI 在最优是“不打”的 10 题上全错。
39. 0045实验 0045：搜索 AI 为什么选错——候选覆盖、视野与参考求解诊断在 36 道开发战术题上逐项隔离根候选、搜索视野、路径加分与贴身扣分；没有一种变体整体替代原 quick（31/36），去掉固定贴身扣分的回合末变体达 32/36 但仍新增错误，未改默认策略。
40. 0046实验 0046：本地技巧库——把对战经验写成带反例的条件卡整理 23 张带适用条件、反例和证据类别的技巧卡与两道公开决策题，作为诊断资料；它们没有接入在线 AI 评分，也不构成战术修复。
41. 0048实验 0048：补上“目标已无法反击”的攻击候选复查 16 个搜索叶子发现，旧候选生成漏掉了目标反击已耗尽的普通攻击；补入后 16 条持续续玩中 4 条负转胜、24 组阵型对照中 1 组负转胜，但一个复杂节点耗尽预算，候选扩展仍只在离线使用。
42. 0051实验 0051：逐案审阅 16 组配对对局，寻找可检验的战术假设只读审阅旧训练中 7 改善、3 退化、6 不变的 16 组配对对局（10 个来源，650 秒），得到一项由 3 个来源局部支持、尚未验证的开局等待假设；零新对局、零学习。
43. 0055实验 0055：本地攻击预览是否兑现了它自己的承诺在固定 16 个旧根、32 个候选上检查本地 Arena 两条攻击预览路径：176 次请求约束和 34 次真实悬停显示全部符合各自合同，30 个有值、2 个 reach 攻击按合同返回未知；一次仪器错误已保留并修正，未发现泄漏，也无新比赛。
44. 0063实验 0063：公平 AI v59 在战术题上错在哪里对精确战术题库里 v59 答错的 12 道题逐项拆解评分，12/12 都能归因于公开信息下的估值缺陷（其中 5 道由反事实重排证实），达到事前 go 线；主要问题是反击暴露判定和反击损失低估，以及等待/移动缺少机会价值。
45. 0065实验 0065：v60a 在排位里改变了哪些决策只读重演 0064 的 80 局排位：v60a 在 64/80 局与 v59 选择不同，首次分歧多在第 1 回合，且全部是放弃“先移动再近战、会吃反击”的攻击；“这类决策在对局中太少”的假设不成立。
46. 0066实验 0066：镜像排位的噪声底有多大给默认 AI v59 加入同改选率（约 13%）的随机扰动，在同一 40 来源排位上重复 8 次：来源差从 −0.0375 到 +0.175 摆动；v60a 的 −0.0375 与随机扰动分不开，要检出 +0.05 约需 600 个来源。
47. 0068实验 0068：英雄无敌三式规则 AI 与威胁圈推进按英雄无敌三 AI 的简单准则写了两个规则 AI：威胁圈推进 T 与“打得到就打”的 H3。第 3 次运行在 600 个来源上 T +0.103 [0.055, 0.153]、H3 +0.155 [0.105, 0.203]，都优于默认 AI v59 和随机扰动对照，通过。
48. 0069实验 0069：为每个合法动作编码结构化特征只实现编码器与决策数据生成器，不训练：在公开特征后为每个合法动作追加路线风险、攻击序列、落点几何与生物静态特征；实测每动作 351 维、82 个移动行全部可区分，10 项测试通过。
49. 0071实验 0071：H3 规则 AI 的独立留出验证在 320 个新来源上复测英雄无敌三式规则 AI H3：对默认 AI v59 来源差 +0.141，95% 区间 [0.081, 0.200]，通过；同批来源上 H3 − T = +0.116 [0.047, 0.184]（探索性）。H3 作为 Arena 可选 AI 交付。
50. 0072实验 0072：H3 规则 AI 的跨对手检查让 H3 在 96 个新来源上分别对研究搜索 quick 和威胁圈规则 T：对 quick 来源差 −0.667 [−0.79, −0.53]，32 胜 156 负；对 T +0.104 [0, 0.21]。H3 明显不如使用特权信息的搜索，仍优于 T。
51. 0073实验 0073：默认 AI v59 对研究搜索 quick作为实验 0072 的对照，在同样 96 个来源上让 v59 对研究搜索 quick：来源差 −0.677，与 H3 的 −0.667 相当，配对差 +0.010 [−0.073, 0.104]；两个公开信息规则 AI 对搜索同样大幅落后。
52. 0074实验 0074：研究搜索 quick 的信息消融（遮蔽对手法术书）把研究搜索 quick 看到的对手法术书换成已公开施放过的法术，在 64 个新来源上对 H3：原版与遮蔽版 128 局逐局结果相同，都是 +0.766 [0.64, 0.88]；第 1 次运行因“吞噬圣杯”引擎错误中止，修复后重跑。
53. 0076实验 0076：搜索 AI 走 Arena 实时 4 秒路径阶段一确认原版 quick 在实时 4 秒路径上五项工程检查全部通过；阶段二让只用公开信息的 Public Quick 在 64 个新来源上对 H3 打 128 局，98 胜 30 负，来源差 +0.531 [0.359, 0.688]，通过；4 次决策超过 4.4 秒。
54. 0078实验 0078：只用公开信息构造当前局面的快照不重演历史，只用当前公开观察写出一个可搜索的战斗局面：经 12 轮开发迭代，381 个开发点中 347 个可构造、311 个合法动作与真实菜单完全一致；用悬停攻击预览校准后攻击预览一致率 96.4%（同批拟合）。
55. 0079实验 0079：Public Quick 原型的开发试打在 8 个开发来源上让 Public Quick 原型对 H3 打 16 局：0 崩溃、0 非法动作；首轮约一半局在出现召唤后整局回退 H3，补上召唤单位后 Public Quick 决定 94.9% 的决策，核心最长 5.79 秒超过 4 秒。不作棋力结论。
56. 0080实验 0080：压缩 Public Quick 的耗时尾部一次有界修复（快照状态修复按错误类型搜索、实时执行器截止前留 0.25 秒）后，在开发来源上空闲与受控 CPU 压力各打 32 局：每步最长 3.888/3.903 秒，0 次超过 4.0 秒，验收通过。
57. 0081实验 0081：Public Quick 的生产集成验证把 Public Quick 移入生产模块、接入 Arena 实时 worker 后，在 32 个新来源上对 H3 打 64 局：49 胜 14 负 1 双输，来源差 +0.531 [0.313, 0.719]，每步最长 3.776 秒，四项检查全部通过。
58. 0084实验 0084：有限交换评估（只读诊断）把 Public Quick 前 5 名候选各执行一次，再由双方 H3 推进到我方下一次行动，按“削弱敌方未来输出 − 己方输出损失”比较：40% 的点会改变选择，集中在射手贴身与攻击/等待，进入实验 0085 的比赛筛查。

选兵、宝物、布阵和对手构筑推断。

1. 0100实验 0100：本局预测、评分与打法建议在 Battle Notes 中接入“AI 场景分析”：按本局记录的双方兵种与数量计算三项对比分与条件建议，并加入已知装备的条件贡献和敌方装备子集搜索；合成反例找回零差值解释，相关回归通过，但评分未校准成胜率。
2. 0101实验 0101：自对战中推断对手构筑的第一个闭环两个 AI 在 Simulator 中对战，每方只凭公开事件推断对手的隐藏装备来源，赛后再与封存真值对照；公开战术 AI 下真来源 10/10 得到支持，实验性信念策略只有 6/10，暴露了随机条件化预算不足的问题。
3. 0102实验 0102：Arena AI 改用“法术保险”布阵把防范围法术的布阵策略设为 Arena 网页与终端 AI 的默认布阵；381 局换边 A/B 得分率 55.6%（Wilson 95% 区间 50.6%–60.6%），按验收条件通过，并修掉回退与耗时问题。
4. 0103实验 0103：把视频里的防范围法术站位接进 AI实现只看己方部队和公开地图、用假想敌方施法评估 24 种站位的“法术保险”布阵；最坏落点命中队数明显下降，一对换边对局候选方两边都赢，但只有一个种子对，不是胜率验收。
5. 0104实验 0104：选兵时偏好通用抗法术兵种在选秀评分里给前两种通用魔法免疫兵种加分（3 分、1.5 分），只用己方已知信息和 Simulator 公开查询；实现与回归通过，实际选秀里确实改变了选择，但胜率提升尚未证明。
6. 0105实验 0105：抗法术选兵的第一批成对筛查固定 4 个种子、红蓝交换共 8 局，对比新抗法术选兵评分与去掉该项的对照：双方各 4 胜，没有一对改变胜负方向；证明整条链路用上了新评分，没有证明胜率改善。
7. 0106实验 0106：完整构筑、真实菜单留存与换边推断诊断用 6 份完整选秀来源预先排定 8 局换边对战，全部自然终局并精确回放；24 处生命残差解释了 23 处，剩下 1 处是复现出的 Simulator 错误；敌方构筑推断仍会在中途失去支持。这是开发诊断，不是基线验收。
8. 0107实验 0107：法师怎样拿宝物、什么时候重置在真实选秀规则上离线比较 5 种拿宝物/重置的启发式策略；独立验证 3750 条轨迹中，“补法力短板的有限追套”把有奇术构筑同时达到 200 法力与 20 咒力的概率提高约 19 个百分点，积极追套反而更差。
9. 0109实验 0109：法师选宝物实用指南——这手拿什么，什么时候值得刷把实验 0107、0108 的条件规划结果整理成可操作的选宝物检查顺序：同样三张史诗宝物，答案随库存、同槽旧装备和蓝量需求翻转；重置要按当前三张算临界价值。均为 Simulator 内的面板与声明效用，不是胜率。
10. 0110实验 0110：把联合开场预测接进场景建议实现公开函数、命令行和 Battle Notes 界面，把“与观察吻合的敌方来源候选”逐个建场、算条件指标并生成可追溯的开局建议；软件验证通过，但建议的实战收益和真实对局关联尚未验证。
11. 0112实验 0112：战士构筑为什么赢法师构筑（只读诊断）重放实验 0111 已有的 320 局，把敌方兵力下降逐事件记给英雄或部队：战士开局静态兵力高约 47%，法师的法术补回一部分；法师约 70% 法力打完未用，限制是每回合施法次数。只做描述，不跑新对局。

模仿学习、PPO、CEM 与整局策略学习。

1. 0201实验 0201：Masked PPO 的整局工程预检实现只吃公开特征的小型策略/价值网络、独立 GPU 学习进程和多进程采样；首次运行因路径类型错误在首步前退出，修复后 4 局模仿 + 4 局网络对局全部自然终局并完成一次 PPO 更新，925 次转移回放核验通过。只是工程预检，不是棋力结果。
2. 0202实验 0202：Masked PPO v2——公开语义表示与首轮有限训练加入公开单位/状态/法术/动作目标语义后，按冻结协议完成 128 局模仿采集和 600 局 PPO 训练（全部自然终局）；开发评测在第 5 局因公开恢复查询故障中止，GPU 输入缓存未通过默认数学门槛而保持关闭；CPU 8 进程吞吐约 1.53 倍。没有棋力结论。
3. 0205实验 0205：从“改一次动作”转向整局策略学习方向决策记录：撤下尚未启动的一次覆盖价值回归实验，改为每回合保持战略倾向、按完整对局胜负用 CEM 优化不超过 20 个参数的整局策略，并写下首轮来源、预算和推进门槛。只是方向与约束，不含训练结果。
4. 0206实验 0206：Simulator / 状态推断 / AI 的监督基线协议冻结“逐局监督”的验收协议：精确回放、双方公开快照逐数值记录、伤害与生命对账、保存决策时真实菜单，并把敌方真值只留在事后审计；随后 20 局自然终局的监督检查点已达成，但都不是留出评测。
5. 0207实验 0207：第一批战斗监督记录逐操作复核 2 段旧失败对局和 4 场新的自然终局对局：88 个操作、1414 项数值变化的伤害与生命账全部对齐；发现推断在士气额外行动后失去支持、AI 有可疑的等待/跳过选择，并修复了“失败菜单被遗忘”的状态推断缺陷。
6. 0208实验 0208：20 局监督——结算可以对账，AI 仍有明确战术缺口20 局自然终局、1310 个操作、39891 项公开数值变化全部精确回放；103 处非伤害生命残差、205 次施法扣蓝和专注流水全部对上来源；同时找到“奈拉之吻”行动代价未进入决策、布阵过于集中等明确缺口。不是胜率验收。
7. 0209实验 0209：20 回合双输规则下的 24 场基线新规则上线后先跑 24 场固定基线（16 场两兵组对两兵组、8 场完整 Arena），全部单方自然胜负、0 双输/未知/故障；1314 次决策与 24 对终局奖励独立核验通过，冻结门槛通过。不训练、不声称棋力提升。
8. 0211实验 0211：模仿模型为什么从不选“移动”——冻结模型的只读归因对 0210 训练出的行为克隆模型做一次只读诊断：教师选移动的 93 个状态里模型 0 次选移动，移动内部精确 Top-1 仅 11/93；按事先冻结的分流规则，问题归为“移动内部排序差”。诊断完成，未训练、未新开对局。
9. 0217实验 0217：改选一次还是每回合改选——冻结策略的频率对照零训练对照诊断：冻结 0216 的优势模型，比较“整局最多改选一次”和“每回合最多一次”。120 局全部终局，新模型两种频率都是 1 胜 23 负，旧权重都是 11 胜 13 负，频率交互项为 0：单次改选已经有害，退化不能归咎于重复改选。
10. 0222实验 0222：整局坚持一个战术目标——“集火射手”通过保留验收两个固定的整局战术脚本：S 全队集火敌方弩手，M 全队先打敌方侍从。在 12 个选择来源上只有 S 合格；S 在 8 个开发来源 +.4375、在 12 个新保留来源 +.166667（4 改善 1 退化，15 胜 9 负）通过原定门槛。这只是原生无英雄非对称 2v2 对 Fair 的工程结果。
11. 0228实验 0228（提案）：公开观察的小型残差自对战只登记、未开始的方案：保留 Fair 为基线，用至多 32 个参数的小模型在每次付费行动决定“照 Fair 走还是换一个不同类别的挑战动作”，以完整竞技场终局胜负做策略梯度更新，对手包含 Fair、旧持续目标脚本和自己的历史版本。尚无实现、来源、训练或对局。
12. 0230实验 0230：动作排序模型为什么拟合不上——可拟合性诊断接实验 0229 的失败做诊断：同菜单重复输入只占 0.6%（移动决策 0 个）；512 个训练决策 2000 步只拟合到全体 Top-1 0.85 左右且损失震荡；原设置延长到 80 轮，开发移动 Top-1 仅 0.139→0.165；规则 AI 选移动时，模型四成多选了攻击。诊断按计划完成。
13. 0231实验 0231：排序模型背不下 512 个决策，是优化问题还是容量问题在同样 512 个训练决策上比较四种设置：原模型改用学习率 1e-3、全批 512 在第 1400 步达到全体 Top-1 0.95（最好 0.986）；原模型学习率 3e-4 批 64 到 0.947；加宽到 512 和把状态先拼进动作行都没达到。结论：主要是优化噪声问题，不是特征或标签不一致。

规则缺陷的复现、修复与回归检查。

1. 0300实验 0300：自动来源分组的公开装备合规检查让状态估计自动挑出的 5 组宝物候选逐组走一遍 Simulator 的公开装备推导，全部能完整装备、往返校验通过；另一个同槽位反例被整体丢弃。只是内部合规证据，不含数值效果或实战验收。
2. 0301实验 0301：自动来源分组的逐顺序数值支持为 0300 的 5 组宝物候选补齐完整数值效果报告：3 组复用严格同顺序的已存记录，2 组因装备顺序不同重新查询；全部通过往返校验，没有用单件相加或假设顺序无关。
3. 0302实验 0302：魅惑时长缺陷对专注结算的真实影响用 17 条受控战斗历史检查魅惑状态时长上限缺陷如何影响专注资源：13 条符合预期，4 条稳定复现同一缺陷；隔离修复原型能让 17 条全部符合，但尚未成为生产修复。
4. 0303实验 0303：条件化搜索中攻击回调漏筛的修复搜索用的快捷筛选器忽略了攻击过程中的追加伤害和属性变化，在奈拉之吻及 20 局复查中共误删 27 个真实分支；修复后 792 次攻击误删为 0，代价是更多攻击交给完整执行。
5. 0304实验 0304：可定制场景随机回归与 204 场正式复核用可定制的受控战斗刻意触发 7 族特殊规则并逐包查账：204 场全部自然结束且回放一致，96 项场景检查失败，集中在九头蛇横扫和奈拉之吻两个已知缺陷上。
6. 0305实验 0305：奈拉之吻反击后状态刷新的候选修复验证第二击沿用反击前的旧目标对象，导致凭空回血和减速丢失；私有修复原型在 3 个旧规则版本上跑 45 组新旧配对、91 项验收全部通过，后来被 Core383 正式采用。
7. 0306实验 0306：Simulator 当前欠账与重构评估把 Simulator 未完成工作整理成 10 个工作包，并用代码统计评估是否需要重构：结论是需要，但应围绕临时英雄属性来源与生命周期按缺陷分批做；首批提取通过等价性检查，已知 24+4 个数值缺陷仍未关闭。
8. 0307实验 0307：Simulator 当前缺口清单（Core380 检查点）2026-10-02 在规则版本 Core380 上整理 Simulator 的当前缺口：范围攻击预估、物件破坏、新版本保真、生命与顺序、AI、UI 和观察闭环共 8 类仍未闭合；全量回归 68 个旧失败保持、新增 0。
9. 0308实验 0308：恢复当前游戏版本的伤害测试执行257 个“准备错误”其实是旧版本证据门禁挡住了测试；重新审阅当前版本的伤害来源后恢复 71 个案例真正执行，没有放宽任何断言，也没有新增失败。
10. 0309实验 0309：受伤结算的共享实现与新版本文字场景把“生齿不息”受伤增攻等结算抽成一个只处理实际损血的共享函数，并让文字场景可以选择 Core380–385；60 份历史逐事件一致，九头蛇反击时序缺陷仍以 6 个预期失败保留。
11. 0310实验 0310：全军阵亡后召唤技能快照读取错误的修复AI 确认批次在第 115 步因“召唤状态快照变化”中断；原因是一方全军阵亡后读取器只看活体，把寿命加成读成 0。修复后原 115 步重放一致、单步续算成功，764 项相关检查通过。
12. 0311实验 0311：禁疗、复活与召唤物驱散的交叉复核用 52 条只走合法菜单的受控历史交叉检查紫龙驱散、召唤仪式、致命腐烂禁疗与回溯复活：2296 个事件全部续算与回放一致，240 个关键字段符合预期；生产规则未改。
13. 0312实验 0312：Core384 黑龙双格攻击与对象锚点修复黑龙攻击水晶、树人石块等可攻击对象时漏掉后格的问题，并把同一模板接入普通攻击和反击；以新规则版本 Core384 发布，旧版本回放保持不变，最终专项 199 项通过。
14. 0313实验 0313：致命腐烂下的合法复活与尸体清除用 20 条只走合法动作的受控序列检查致命腐烂与驱散、内心之光、回溯复活的组合：1–2 级可被驱散后复活，3–4 级保持禁疗；尸体不能被直接净化。生产规则未改。
15. 0314实验 0314：玩家竞技场心得的逐条规则审计把一份玩家竞技场心得逐条拆成“安装数据 / 官方说明 / 玩家观察 / 策略推断 / 未知”五类证据，对照 Simulator 和 AI 查缺口；修复了反击触发、英雄开局补偿、连锁闪电估值等问题，诊断出的 60 个 AI 坏决策降为 0。
16. 0315实验 0315：生齿不息在护盾、多轮受伤与立即再生下的检查用 10 条受控历史检查九头蛇“生齿不息”的受伤增攻：护盾挡住的伤害不增攻，增攻跨回合保留，立即再生不会抹掉已取得的攻击；34 项聚焦检查通过，生产代码未改。
17. 0316实验 0316：生齿不息与同次反击的最小场景回归用 10 条最小历史精确复现九头蛇受伤增攻晚于反击的缺陷：应有反击 84/88 等，当前引擎只给 80/80；6 个场景以严格预期失败锁定同一缺陷，尚未做生产修复。
18. 0317实验 0317：生齿不息与反魔法、紫龙驱散的交叉复核检查九头蛇受伤增攻在反魔法和紫龙无效化之后是否保留：9 条受控历史中增攻都被保留、下一次攻击均为 84/88；草稿误把反魔法当普通驱散，查配置后改为阴性对照。
19. 0318实验 0318：Core387 九头蛇横扫、免反击与皇家命中减益以新规则版本 Core387 修正三种九头蛇的攻击范围、免反击和皇家命中减益；70 份旧回放逐份一致，五模块按节点合并新增通过净 282、新增失败 0，切换攻击六格半伤等边界仍未实现。
20. 0319实验 0319：皇家九头蛇命中减益的屏障、免疫与持续时间用 9 条受控历史锁定皇家九头蛇命中减益缺失的缺陷（如应为 60、当前为 80），6 个严格预期失败描述同一缺口；隔离原型满足全部断言，但生产代码未改。
21. 0320实验 0320：皇家九头蛇混合目标的逐目标免疫、屏障与有序结算用 8 条混合目标历史检查皇家九头蛇横扫中每个目标的免疫、护盾和减益：当前引擎只伤主目标、无减益、旁盾不消耗；8 个严格预期失败锁定这一组合缺陷，隔离原型通过但未上线。
22. 0321实验 0321：九头蛇范围、反击与命中减益的受控回归用 13 条当前安装版本来源和 21 条完整战斗历史检查九头蛇三种攻击入口：生命账全部通过，范围与资源规格严格复现既有缺口；普攻横扫原型 18 条历史全部达标，但未发布。
23. 0322实验 0322：Core386——每个真实受伤包立即增攻把九头蛇“生齿不息”的增攻从“行动结束按净掉血结算一次”改为“每个真实伤害包后立即结算”，反击数值由 80/60/20 修正为 84/63/21；新规则版本 Core386 上线，旧版本存档按原规则回放，全量回归无新增失败。
24. 0323实验 0323：当前版本凤凰横扫与混合目标测试复核针对当前游戏安装版本重新审阅凤凰横扫的几何、目标顺序、幸运和对象受伤证据，让 186 个因旧版本门禁卡在准备阶段的测试重新执行，三个文件 196 个案例全部通过，坏节点减少 186、新增 0。
25. 0324实验 0324：玩家笔记与竞技场宝物池审计把一批玩家观察逐条与游戏安装数据、Simulator 代码对照：修正了觉醒远程贴身可被反击、亵渎崇拜被延长、等待中死亡的单位复活后排队、暗影增幅重施等偏差，并确认 8 件宝物在竞技场权重为 0 而非被删除。
26. 0325实验 0325：低语力量——开局锁定来源的生命周期回归用合法动作构造携带者死亡、复活、镜像复制与复制体到期等历史，验证“低语力量”提供的法术熟练度在开局锁定、不随单位生死变化；共 32+8 条历史及法力光环补充全部通过，没有修改生产规则。
27. 0326实验 0326：公开范围攻击预估的接入检查只读审计为什么 Simulator 已能正确执行凤凰横扫，AI 却还不能用“只看公开信息”的方式预估范围伤害；列出四个入口的具体缺口、新查询需要表达的内容和首个验收矩阵。没有修改代码。
28. 0327实验 0327：只用公开数据计算一次范围攻击波次实现一个私有的范围波次计算原语：输入只有静态目录和公开观察，按模板顺序锁定受击者并分别记录敌我生命与物件耐久；178 项新测试通过，受影响 Simulator 全量的 68 个失败与基线逐条相同，未接入 AI 或界面。
29. 0328实验 0328：公开恢复查询接受已解析的施法成长差值PPO 训练开发评测第 5 场在第 38 步因公开恢复查询误拒“咒力差值 +2”而中断；局部修正校验后原故障 38 步重放、7 个 +2 恢复查询和既有转移全部核对一致，没有改公式或规则版本。
30. 0329实验 0329：查询内复用施法配置——实现与等价验证在一次公开属性查询内，按校验后的资源组合只构造一次不可变施法配置，每次访问仍先跑全部校验；完整投影、拒绝路径和状态估计整份响应都与修改前逐字段相等，没有测量提速。
31. 0330实验 0330：查询内复用施法配置——提供方评估只读评估状态估计提出的“施法配置重复构造”问题：确认在单次属性查询内、所有校验之后按 8 种资源组合复用不可变配置是兼容的，并列出交付前必须通过的兼容检查；本身不改代码、不重跑计时。
32. 0331实验 0331：尸体仪式召唤物遇上反魔法与天堂之刃用 36 条合法操作历史检查“仪式”召唤出的单位在有无“稳定”、有无己方反魔法时，被天堂之刃攻击的结果；全部通过，另 9 组对照确认攻击前的公开观察与菜单不泄漏隐藏的稳定状态。
33. 0332实验 0332：Game Knowledge 与 Simulator 支持消费者的团队计划一份滚动计划与交付记录：为状态估计、Battle Notes 提供版本化来源查询和有界合成规则支持，已交付 16 个里程碑（公开查询支持图、有限联合求解、来源与装备合规、施法配置复用等）；2026-10-05 晚随用户暂停而中止，后续窗口未执行。
34. 0333实验 0333：负数攻防下的聚合伤害校验修正整局 CEM 训练在第 434 步因防御 −21 的单位被凤凰范围命中而抛错；按当前安装版的数值审计修正聚合伤害边界，使非零负分母可以计算，原故障步重放成功、训练日志核验一致；防御恰为 −20 的零分母情形仍未解决。
35. 0334实验 0334：Simulator 正确性与测试覆盖——目标、验收方法与进度记录2026-10-06 起把工作收敛到“先把 Simulator 做正确”：定义六步验收方法，按批次修复增攻时序、召唤数量、九头蛇、反击波次、致死归因、专注等偏差（Core383–Core417）；整体正确性目标仍未达成，目标已按新规则暂停。
36. 0336实验 0336：Core383——施法中心校验、奈拉之吻刷新与障碍物生命周期新增规则版本 Core383：黑洞复用控制法术的中心校验，奈拉之吻反击后完整刷新目标；障碍物创建/摧毁/到期 6 项检查通过，黑龙打物件漏伤后方单位的缺口以 2 个严格预期失败固定。全量新增坏节点 0。
37. 0337实验 0337：特殊状态在施放、死亡、尸体等待与复活中的去留用 36 条合法操作历史检查觉醒、深渊意志、心智操控、收获和复制体等状态在单位死亡与复活后的去留；30 条通过，6 条以严格预期失败固定复制体复活后丢失“受伤即消失”状态的缺口，生产规则未改。
38. 0338实验 0338：召唤、临时单位、甲壳与驱散的合法历史复核用 54 条合法历史检查召唤队伍、暗影军队临时单位、稳定、四级甲壳与三种清除手段的交互，全部符合预期；另发现原始残骸召唤数量与安装配置不一致，24 个数量案例中 8 个以严格预期失败固定。
39. 0339实验 0339：Core385——两种英雄召唤的数量修正新增规则版本 Core385：原始残骸系数由 2/2/2/4 修正为 1/1/1/2，两种召唤的百分比加成改为 32 位浮点运算后舍入到最近整数、恰好一半取偶；128 条受控历史 2944 次操作逐步核对，五模块全量新增坏节点 0。
40. 0340实验 0340：召唤数量——边界检查、严格失败分类与隔离修复原型新增 80 条召唤数量合法历史（两种召唤 × 四级 × 五档咒力 × 有无 Legion），32 例符合配置候选、48 例复现差异；收紧已知缺陷的失败分类，并在内存中验证修复原型，80 例全部通过、48 例被旧引擎拒绝回放。生产规则未改。
41. 0341实验 0341：召唤法术的咒力组合与重复施法复核用 48 个单次施法场景和 4 条重复召唤历史检查主属性减益、同学派/异学派加成如何合成召唤法术的有效咒力；减益只结算一次、学派加成只出现一次，22 例数量符合配置候选，26 例复现已知数量差异。
42. 0342实验 0342：技能持续时间——合法重施与两回合上限复核手铐、魅惑众生和冲锋三种技能的持续时间与重施，发现魅惑众生忽略两回合上限（R1/R2/R3 连施会延到第 6 回合）；16 条合法历史中 14 条符合预期，2 条以严格预期失败固定该缺陷，后由 Core417 修复。
43. 0343实验 0343：原始残骸复制体——伤害、护盾、净化与死亡用 36 条合法历史检查“繁茂衍生”创建的原始残骸复制体在闪电、反魔法、紫龙驱逐、无效化与甲壳、稳定组合下的行为，新增 39 个战斗测试 36 个通过；另发现复制体脆弱状态在死亡时被错误清除（3 个严格预期失败），并推进了召唤数量算术的原生证据。
44. 0344实验 0344：回合开始时的胜负结算与旧版本回放兼容修复“回合开始时最后一个召唤物到期、一方已无部队却没判负”的规则缺口（新规则版本 Core449），同时让旧版本 Core448 存档按原时序严格回放；738 项软件检查通过，原 0225 的未知结果保持不变。
45. 0345实验 0345：七个原生状态的面板属性查询修复曙光盔甲与狂暴共七个状态只改伤害倍率，却让面板属性查询返回“部分已知”，阻断了截图里凤凰面板的攻防核对；只为这七个 ID 补上精确规则后，凤凰攻 54、防 39 在声明前提下与“无新增来源”相符，297 项软件检查通过。
46. 0346实验 0346：虫巢“众志”加成的计数包含携带者自己两张实战面板读数（攻 43、防 12）都只在“计数包含携带者”时成立，与说明文字“其他的”冲突；按商业游戏实际表现改为新规则 Core450，旧存档按旧口径回放，处理夹具后全量测试通过。
47. 0347实验 0347：确认页英雄卡的百分比加成向下截断三张英雄卡比 Simulator 少 1；第一次把战斗规则改成截断被生物面板交叉核对否定并撤回，第二次只把确认页英雄卡的显示值改为截断，27 张真实卡对上 26 张，战斗规则与版本不变。
48. 0348实验 0348：混乱打击遇到无限反击时保持无限一局随机扰动对局因单位技能流水核对不一致中止：英雄“混乱打击”把麒麟的无限反击变成 0，随后又被状态替换恢复。新规则 Core451 让无限反击保持无限，旧存档按旧行为回放；该种子跑完、30 局旧对局回放一致。
49. 0349实验 0349：化身召唤的“法强 +1、攻防 −1”其实是化身的继承系数核查发现这三项是只作用于化身的兵种继承系数，Simulator 却把它们加到了英雄本人身上，导致全军攻防 −1、法术按法强 +1 计算；用户授权后修复，英雄卡与普通兵种不再变化，化身伤害 34→26 与安装公式一致。

Arena 界面、回放查看器与试玩反馈。

1. 0400实验 0400：对战回放查看器与“双方都输”的结算规则实现可导入、调速、单步和前后跳转的 AI 对战回放，以及新的双输规则（20 回合未决、或只剩临时生物存活时双方都输）；96 场历史评估对战全部逐事件验证导入，浏览器验收 7 组通过。
2. 0401实验 0401：只看可见信息、按需悬停的施法模式整局验收一个可选的施法决策模式只用英雄 / 魔法读数、公开动作菜单、法术预览和事先声明的候选世界决定是否施放雷击；72 局开发 + 保留对局全部终局且严格回放一致，按需检查比固定检查少读 2116 次界面。
3. 0402实验 0402：仿照实机画面改进 Simulator 战斗界面只改 Web 前端展示：六角格改为与规则一致的尖顶几何，加入地貌色调、阵营底座、血条、羊皮纸魔法书和悬停伤害浮窗；几何测试与 Simulator 邻格完全一致，Arena 全套 2521 项通过，可用性仍待用户试玩。
4. 0403实验 0403：观察商业游戏界面，并据此改进 Simulator 的魔法书与选秀卡片第一次直接观察已安装的商业客户端（战斗布局与图标式魔法书），整理差异清单，再分批实现图标魔法书、地图先选目标、可读的选秀卡片和尸体目标；9 月 10 日完整选秀到开战的浏览器流程通过，Arena + 集成 1733 项全过。
5. 0404实验 0404：尸体上的状态计时在界面、预览与存档中的接入把新的 v23 战斗状态（尸体上暂停的状态计时）接入 Arena 的各个消费者，接入中发现并修复两个真实缺陷；四个模块全量测试全部通过，自然存档恢复对局通过，但默认仍为 v20，生命周期总目标未完成。
6. 0405实验 0405：选秀候选生成失败时的“未提交”错误边界当 Simulator 无法生成完整的选秀候选时，Arena 现在返回 HTTP 409、明确说明请求未提交，不发布半成品会话、不泄露私有信息；5 项新测试通过并在真实的种子 61 故障上复现，但候选池耗尽本身（B01）仍未修复。
7. 0406实验 0406：飘字候选附件的保存与展示——消费方只读审阅对“把截图里读到的伤害飘字作为独立附件保存到 Battle App”这一提案做消费方审阅：认可独立、显式、版本化附件的方向，指出必须在保存、重开、导入、HTML 回看四处明确接入，并列出正式合同需写清的六件事；未改任何代码。
8. 0407实验 0407：v23 状态下的两局完整浏览器对局与重启恢复用普通浏览器控件完整打完两局（选秀、布阵、战斗到终局），中途真实重启服务后恢复，独立回放均验证通过；过程中发现战场数量字太小（徽章只有 7.87 像素高），已修复为 16.10 像素。
9. 0408实验 0408：新规则 v366 下的两局浏览器对局验收在规则 v366 下重新完整打两局并真实重启恢复、独立回放均通过；但种子 197 一局在第 55 个事件后暂停，需要手动“重试恢复”一次，原因未查明，只修复了误导性的暂停显示和终局加载显示。
10. 0409实验 0409：低语力量的开局熟练度来源与复活界面验收在魔法书详情里把“低语力量”的熟练度 +1 明确标注为开局加成、提供者死亡后保留；浏览器里击杀并复活低语后，熟练度仍为 2、没有重复叠加，费用因复活的独立来源从 8 降到 6。
11. 0410实验 0410：自然对局中的 v23 Web 存档反复恢复按冻结协议自动打一局自然对局，在 10 个检查点用全新的存储对象恢复存档并逐项比对；第一次因测试脚本把地形名写成小写而在建局前被拒，修正后全部检查点通过，致命腐朽的尸体超过原到期时间仍保持阻断。
12. 0411实验 0411：玩家试玩反馈的第二轮界面修改按玩家试玩反馈调整选秀与战斗界面：英雄选择去掉空侧栏、右键查看不触发攻击、魔法书居中并改为先选法术再在地图选目标、伤害按 500 毫秒间隔逐包显示；Arena 全量 1395 项通过，多项规则类反馈仍未完成。
13. 0412实验 0412：只展示玩家可见信息的战斗体验改进按“对方英雄属性和魔法可见、集能不可见”的玩家观察调整 HUD，并用公开的执行回执叙述移动、伤害、减员和英雄属性变化；之后数日继续修复无伤害减员提示、窄屏布局、定向攻击误标和原始枚举文本，Arena 全量最终 2161 项通过。
14. 0413实验 0413：驱逐能力只展示公开的生命暴露范围（Web v102）把“驱逐”能力预览从精确的消灭数量改为只用公开信息算出的直接生命暴露范围，隐藏保护保持未知；浏览器中有无保护两种场景的预览完全相同而实际结果不同，验收通过，顺带修复窄屏能力弹窗被裁的问题。
15. 0414实验 0414：让战场上的兵种数量看得清棋盘整体缩放后数量字只有 7.87 像素高；改为在按钮外绘制一层不接收点击、字号不随缩放变小的数量层，桌面与窄屏都达到 16.10 像素且不重叠、不影响点击，顺带修复窄屏布阵把红方部队挤出视口的问题。
16. 0415实验 0415：对局暂停时保留原因并如实显示回合状态修复 Arena 网页在 AI 请求失败后暂停时的提示：首个失败原因一直保留、回合标签改为“对局已暂停”；浏览器断网—恢复流程验收通过，但最初那次暂停的根因仍未查明。
17. 0416实验 0416：选秀迁移中把“测试夹具写错”和“规则没做完”分开只修测试：把用过时状态版本、非法混档选秀、借来专长标记的夹具改成合法构造，原断言保留；相关测试转为通过，但其余失败仍在，整体产品门槛依旧未通过。
18. 0417实验 0417：驱逐召唤与多段伤害在战斗日志里的结算反馈战斗日志新增“驱逐结算”说明、逐段伤害拆分，并把生命净变化标成“净变化，不等同伤害”；受控前缀在真实浏览器中验收通过，但不是新的完整对局或原生规则证明。
19. 0418实验 0418：2026-10-11 Arena 试玩反馈修复按玩家试玩反馈修 Arena 网页：敌方布阵数值隐藏、英雄属性按钮、右键查看兵种、AI 思考时可只读查看、完整行动条与魔法书伤害预览，并修掉一个贴身射手导致的 400/500 阻断；无头浏览器回归通过，AI 延迟另行处理。
20. 0419实验 0419：Arena 本地网页的玩家流程复现与三局完整验收在隔离服务上按玩家路径走完选秀、布阵、战斗、存档重启与导出，三局完整对局全部精确回放；途中发现并修好方向攻击无法导出学习文件的问题。
21. 0420实验 0420：Arena 网页界面的自动化整局测试搭建会话层、浏览器层、回放层三层自动测试，由程序随机或按记录点完整局；首轮浏览器 3 整局 0 页面错误、回放 111 步全部一致，会话层 30 局找到并修好 2 个真问题。
22. 0421实验 0421：回放里显示实际存活数量回放把兵堆的开局容量当成当前数量（剑士应为 6 却显示 20）；改为读取存活数量，并离线重建 970 份展示缓存，126424 个数量逐个核对一致。
23. 0422实验 0422：让启动器能安装 Battle Notes 本地预览版启动器只认“正式发布”包，所以总装回旧版 10.10-5；改为同时接受明确标注且已过范围检查的本地预览包，33 项测试通过，实际发现新版 10.13-1。

AI 决策延迟与查询性能。

1. 0500实验 0500：deep 档 AI 决策延迟诊断与第一批修复在不降低搜索预算的前提下消除重复计算，同一开局的完整 deep 决策从 180.301 秒降到约 60 秒量级（当前版本 62.909 秒），动作与评分不变；仍远未达到交互延迟要求。
2. 0501实验 0501：完整 deep 的成本定位与序列化复用粗计时发现状态摘要累计近 30 秒，按兵堆复用规范 JSON 字节后，完整 deep 中位数 61.1108→46.0613 秒（约 −24.6%），决策完全相同；四秒内的确认覆盖没有增加。
3. 0502实验 0502：每个 AI 动作不超过五秒的可玩性验收网页 AI 改为四秒可终止工作进程，返回最近完成的合法选择；fair/quick/strong/deep 各一整局共 273 次 AI 行动，0 次超过 5 秒、最大 4.540 秒，但多数步骤实际采用的是较浅档位。
4. 0504实验 0504：四秒内搜索到底完成了什么新诊断工具逐步记录候选准备和根动作比较；同一局两个状态 12 次测量显示，deep 在四秒内连一个根动作结果都返不回，只减随机样本也不够。
5. 0505实验 0505：复用确定性的有界条件化失败结果公开历史条件化在预算耗尽后每个后续版本都重复同样的失败搜索；记住已验证前缀上的失败后，四条观察序列额外试验 14448→1648、总耗时 1629.232→189.025 秒，报告语义不变，覆盖没有增加。

搜索 AI、规则 AI 与对局评估：候选、视野、估值和排位。

1. 0004失败实验 0004：范围序列候选 v6 的完整对局评测范围攻击计价候选 v6 在 64 局冻结评测里胜局 14/32→18/32、未丢失基线胜局，但“全部自然终局”与压力场景耗时两项晋升门槛未通过，默认 v55 保留。
2. 0032失败实验 0032：射手贴身——“敌人已行动就免除贴身扣分”的改法不成立用 4 个合成局面检查：敌方本回合已行动后，射手被贴身时仍只能近战并会吃反击，下一轮仍受到 10 点伤害。因此不采纳“敌人本回合不能主动攻击就免除 120 分贴身扣分”的改法；这 4 个局面也不证明 120 这个数值合理。
3. 0038失败实验 0038：同一信息下强制共享后续动作——820001 有界对照怀疑搜索在“看不出区别的随机世界”里各自挑最好的后续动作，从而高估某个根动作。把三个同历史世界的后续动作强制统一后，根差从 115.921208 降到 77.841208（降 32.85%），没有达到事先冻结的“减半”门槛，停止围绕种子 820001 的定向优化。
4. 0039失败实验 0039：法术输出候选的独立确认（首批因引擎故障中止）在 24 个全新来源上确认“每回合法术输出偏好”：69 局自然终局后，一局在第 115 步因 Simulator 召唤来源读取错误中止，74 局未开始。已知部分 F 7 胜 16 负、S/D 各 8 胜 15 负，S−F 区间 [−0.5000, +0.5417] 跨零，确认未完成；故障已修复，原批次不补跑。
5. 0040失败实验 0040：修复后的法术输出候选独立确认修复引擎故障后，在 24 个全新来源上完整跑完 144 局：原公平 AI 25 胜 23 负，两种候选各 24 胜 24 负，来源级 S−F 均值 −0.020833，区间 [−0.083333, +0.041667]，远未达到 +0.10 门槛；关闭该候选和模式消融。
6. 0041失败实验 0041：召唤物的首次行动机会检查“立即召唤”能否让召唤物当回合就产生攻击收益：召唤物确实插入当回合行动队列，但有行动不等于能攻击；4 个开发来源中公平 AI 原本都选了其他法术，强制召唤或强制等待都没有证明它选错，未形成可合入的新评分，关闭此方向。
7. 0042失败实验 0042：召唤候选裁剪与规则校验提速——三个方案都不合入为加快 strong 档决策尝试三项优化：两种规则校验复用收益很小或方向不一致；“每个召唤法术只保留 8 个距离极值位置”的裁剪约快 10%，但在 18 个局面里有 14 个删掉了更好的位置，最大估值差 13.5。三项都不合入。
8. 0047失败实验 0047：搜索里“终局分”和“局面分”混在一起是否误导选择冻结 8 个新来源只取得 3 个检查点，0 个满足“终局与非终局分混合”的准入条件，未拟合新价值函数；232 条续玩中 215 条自然终局、17 条超时未知，并留下 820001 一个非终局排序反例。
9. 0049失败实验 0049：无反击攻击候选在 24 个新来源上的分层验证原计划 96 对持续对照，第 18 对出现“旧控制器胜、新控制器负”而按预定规则停止：17 对自然终局中 10 同胜、6 同负、1 旧胜新负，1 对超时未知，余 78 对未运行。
10. 0050失败实验 0050：只用公开信息的“先等待、再接近射手”计划实现一个可取消的等待→移动两步计划，准入 24 局全部自然终局，但只在 1 个来源启动 1 次、完成 0 次，未达“至少 3 个来源完成”的门槛，按冻结条件关闭；16 个受控方向与 Fair 结果全同。
11. 0052失败实验 0052：开局只等待一次，能否减少前进暴露并赢更多？在 8 个新开发来源上验证“开局前进会进入多个敌近战攻击范围时先等待一次”：24 局全部自然终局，6 个来源成功触发并保住更多早期兵力，但 16 个受控方向胜负全部与 Fair 相同、来源差 0，开发门槛失败。
12. 0053失败实验 0053：能否用公开信息确认“必杀待行动敌军”的机会只读扫描 911 个旧训练决策、400 个合格根和 983 次公开规则查询，现有接口全部只给部分或未知估计，无法确认任何“完整动作必杀”；按接口能力不足关闭，机会数未知而非 0，零新对局。
13. 0054失败实验 0054：玩家能看到的攻击预览，能否成为公平 AI 的输入固定 16 个旧决策根、32 个候选攻击，检查能否找到同一时刻的游戏内攻击预览证据；可绑定证据 0 个，实际可见性与新增信息都未知，按证据关联不足关闭；零新对局，未实现新接口。
14. 0056失败实验 0056：用本地攻击预览找 Fair 漏掉的收尾攻击在固定 16 个旧决策根上比较原 Fair、公开均值对照和本地预览三种选择：7 次预览查询全部有值，但显示下端都低于目标剩余生命，三者在 16 根上全同，0 个来源产生信号，准入失败关闭；零新对局。
15. 0057失败实验 0057：用本场已公开的伤害反馈校准 Fair 的伤害估计在 16 个旧来源 192 个多目标决策槽上回放：收到 32 条可用伤害反馈，但分落在 32 个各只出现一次的组里，没有组达到两条的启用线，0 次改选、0 个信号来源，准入失败关闭；零新对局。
16. 0058失败实验 0058：跨对局学习一个四参数伤害修正在 135 条旧训练公开主击上一次拟合四参数岭回归；原准入审计因仪器比较错误中断，只读修复后的探索性开发 24 局全部自然终局，4 次改选但 16 个受控方向胜负全与 Fair 相同、来源差 0，开发误差反而变差，关闭。
17. 0059失败实验 0059：英雄先手削弱、部队随后集火的配合策略24 局新开发对局全部自然终局，原 v1 来源差 −0.0625（0 改善 / 1 退化）；但正式流程因回放清单重复写入故障关闭，另确认 5 次范围法术命中被漏识别、没有启动配合。修复版 v2 只有软件证据，没有完整对局成绩。
18. 0060失败实验 0060：修复版英雄与部队配合的独立验证接通范围法术回执和导出修复后，在 8 个新来源上重测英雄先手 + 部队集火：24 局全部自然终局、零工程故障，7 个来源启动配合、4 个来源有部队跟进，但 16 个受控方向胜负全部与 Fair 相同、来源差 0，开发收益门槛失败。
19. 0061失败实验 0061：只用公开信息规划己方接下来两次行动新的条件第二步策略在人工支持夹具上完成 8 分支 / 72 次转移，但耗时 3.076 秒；冻结的 2 秒验收中 2 个根超时、2 个自然根的假想世界未覆盖，工程门槛失败，当前实现关闭；零正式新对局，不能称算法理论失败。
20. 0062失败实验 0062：按已公开英雄身份生成对手的假想构筑新的先验生成让两个自然对局根各得到 2 个职业正确、规则合法的对手构筑声明，但开局重建全部失败（0/5、0/6），人工支持夹具 8 分支仍需 3.346 秒、2 秒内超时；工程准入失败，关闭“在线公开历史重建 + 8 分支搜索”路线，且正式结案超出时间预算。
21. 0064失败实验 0064：考虑反击与机会价值的公开估值原型按 0063 的诊断做两个规则型 AI 原型：v60（A+B+C）开发题 32/36 但哨兵回归而关闭；v60a（只修反击暴露位置）开发 26/36、留出 48/68 对 v59 的 44/68，但 80 局镜像排位来源平均差 −0.0375，未达“≥ 0”门槛，关闭。
22. 0067失败实验 0067：v60a 的 600 来源足量排位在 600 个新来源上重测按反击暴露估值的 v60a：来源差 −0.0925，95% 区间 [−0.134, −0.050]，明显比默认 AI v59 差；随机扰动对照组因 Simulator 错误中止，按协议不下结论。
23. 0070失败实验 0070：威胁圈规则 AI（T）的独立留出验证在 320 个从未用过的来源上复测威胁圈规则 AI T：对默认 AI v59 来源差 +0.025，95% 区间 [−0.041, 0.088]，下界不大于 0，未通过；实验 0068 的 +0.103 没有复现，T 不交付。
24. 0075失败实验 0075：研究搜索 quick 的遮蔽世界消融再从 quick 的搜索世界里删掉对手装备与英雄技能状态：对 H3 仍 +0.563 [0.39, 0.72]（原版 +0.609），但配对差 −0.047 [−0.156, +0.078]，下界未高于预设的 −0.05，非劣判定证据不足；第 1 次运行因包装器错误中止。
25. 0077失败实验 0077：只用公开信息建世界、重演公开历史只用公开先验构造假想战斗，再沿公开动作历史逐步重演：381 个决策点中只有 57 个能重演到决策点，中位 4 个动作就断，断点集中在对手用到隐藏能力。该路线关闭，改做公开根节点快照。
26. 0082失败实验 0082：按下一次施法威胁重排候选（只读诊断）估计对手下一次伤害法术对 Public Quick 前 3 名候选的损失：81% 的点被选候选已是威胁最低者，预测又明显偏低（实际/期望中位 2.26）；按威胁重排的方案预计收益很小，不进入比赛，方向转向布阵与叶节点评估。
27. 0083失败实验 0083：防范围法术的分散布阵让布阵少往中间挤、惩罚 2 格内的己方兵组，双方战斗 AI 都用 H3，在 128 个新来源上打 256 局：来源差 +0.023 [−0.102, 0.148]，未通过；被成片命中 136 对 156 次，没有转化为胜负。
28. 0085失败实验 0085：用有限交换值重排 Public Quick 候选在 Public Quick 前 3 名候选里按交换值 Δv 重选，开发冒烟 4 个来源 8 局只赢 1 局（来源差 −0.75 [−1.0, −0.25]），明显变差；不冻结比赛、不消耗新来源，失败结案。

选兵、宝物、布阵和对手构筑推断。

1. 0108失败实验 0108：法师宝物的条件规划（rollout）在 6 个假设选秀局面上先规划、再在独立种子上确认；部分局面给出有用的库存相关建议，但影子替身局面规划选出的方案在确认集效用差 −1.10（区间 −2.16 至 −0.17），调高蓝权重也未证明普遍改善，未升级在线策略。
2. 0111失败实验 0111：选秀 v17——按用户经验让法师集中构筑法师选秀加秘术/战斗魔法、只练 1–2 系；规则确实改变约 2/3 构筑，但 H3 下 128 个新来源来源差 +0.016 [−0.086, 0.109] 未通过，Public Quick 复核 +0.063 [−0.125, 0.25]；附带发现异职业对局战士约 64% 胜。

模仿学习、PPO、CEM 与整局策略学习。

1. 0200失败实验 0200：持续整局策略的 CEM 训练 v0用 18 个参数的整局偏好策略做交叉熵方法训练，预定 576 局；83.889 秒后因一次真实引擎异常（负防御范围伤害校验）整批停止，仅 28 局自然终局，0 代更新。属工程中止，不能据此判定 CEM 无效。
2. 0203失败实验 0203：冻结的 Masked PPO v2 模型复评不重训，在新目录复评实验 0202 的冻结模型：开发 80 局与保留 96 局全部自然终局、回放核验通过；保留集 Fair/BC/PPO 各 32 局 9/6/5 胜，PPO−Fair 来源差 −0.125、0 个来源改善，未达升级门槛，关闭 v2。
3. 0204失败实验 0204：20 回合双输规则下的 Masked PPO 训练新规则（20 回合未决双方都输）下重训 Masked PPO：修复启动计时故障后 600 局训练、80 开发、96 保留全部完成并核验；保留集 Fair/BC/PPO 各 32 局 18/12/10 胜，PPO−Fair 来源差 −0.25、0 来源改善，关闭候选。
4. 0210失败实验 0210：双兵种 2v2 模仿学习课程把问题缩小到每方一近战一射手、无英雄的 2v2，用 32 个独立布局训练模仿 Fair 的网络；训练顺利完成，但开发集教师动作匹配 62.50%（门槛 75%）、来源差 −0.125（门槛 −0.10），移动动作 0 次匹配，开发失败关闭。
5. 0212失败实验 0212：给模仿模型加相对移动几何特征在同一批 1328 个教师标签上，只给“移动”动作加 18 个公开相对几何通道重新做行为克隆：移动内部 Top-1 从 11/93 升到 25/93，但开发集动作匹配 63.44% 低于 75%、来源差 −.125 低于 −.10，两项门槛均未过，候选关闭。
6. 0213失败实验 0213：分层动作选择 BC——来源不够，训练前停止原型实现了“先选动作类别、再选类内动作”的模仿模型并通过 102 项软件检查，但预登记的布局池只有 53 组、旧划分已占 52 组，凑不出 8 个新开发来源，按协议在正式训练前停止；没有关于分层模型棋力的数据。
7. 0214失败实验 0214：分层 2v2 模仿模型，在扩大的布局池上验收扩大布局池后正式训练分层 BC：开发集完整动作匹配 174/275（63.27%），低于 75% 门槛；开发对局 8 胜 8 负、来源差 0，与基线同赢家。动作保真门槛失败，关闭，并停止同一批数据上的 BC 结构微调。
8. 0215失败实验 0215：一次有限 DAgger——更多移动标签，换来更差的对战让冻结的分层 BC 模型自己下 32 局、在它走到的局面上请教师标注，得到 446 个新标签（101 个移动），合并重训后同布局开发对局 1 胜 15 负（旧模型 5 胜 11 负），新旧差 −.25，动作匹配 63.82% 也未过 75%，失败关闭。
9. 0216失败实验 0216：用反事实终局结果学“这一步该不该改”不再模仿教师落点，改为学习“把基线的这一步换成另一动作、之后双方照常下完”的终局得分差：906 个续玩分支产生 206 个标签且有信号，但训练后的模型在 8 个开发来源上 0 胜 16 负，同场未训练包装 7 胜 9 负，差 −.4375，失败关闭。
10. 0218失败实验 0218：非对称 1v1 整局 CEM——课程没有提供信号准备在“侍从对骷髅”的 1v1 小课程上用 CEM 优化六参数策略。准入阶段三个固定脚本打了 96 局全部自然结束，但 16 个来源的赢家在三种策略下完全相同，0/16 来源有终局差异，低于至少 4 个的门槛；CEM 未开始，课程关闭。
11. 0219失败实验 0219：只看公开信息的两秒短程战术比较给基线 AI 加一个 2 秒内完成的短程比较：每步最多 4 个候选 × 2 个假想未来，只在两个世界都明显更好时改选。24 局全部正常结束，6 次改选覆盖 3 个来源，但 0 个来源终局改善，准入失败关闭；还暴露了“已输的终局 0 分”和“未结束的血量代理分”被混在一起比较的设计缺陷。
12. 0220失败实验 0220：只用真实终局结果筛选改选——旧日志覆盖不够零新模拟的只读准入：重读 0219 的 266 份搜索回执，检查有多少决策的全部候选在两个假想世界里都推演到了规则终局。只有 2 个决策、来自 2 个来源，0 个“终局支配”改选，低于 8/3 和 3/2 两道门槛，关闭。
13. 0221失败实验 0221：两个候选、两个世界，2 秒内续玩到终局每个决策只比较基线动作和一个不同类别的挑战动作，在两个假想世界里都续玩到规则终局，限时 2 秒。16 个预定根中 13 个按时完成（成本门槛通过），但只有 1 个来源出现终局支配改选，低于 2 个来源的门槛，关闭。
14. 0223失败实验 0223：把“集火射手”原样搬到 3v3冻结 0222 通过验收的 S（集火射手）和 M（集火近战），加入第三个兵种狮鹫做 3v3 迁移，同时对 Fair 和 M 两个对手检验。56 局开发对局全部终局：S 对 Fair 来源差 −.3125、对 M 差 −.125，两道门槛都失败，84 局保留未开。
15. 0224失败实验 0224：五参数条件目标策略，用整局 CEM 训练让“先打谁”依赖公开局面：四个目标特征权重加一个覆盖门槛，用 CEM 在 3v3 课程上训练三代、1188 局。训练门槛通过（对 Fair +.125），但 8 个新开发来源上对 Fair 差 0（1 改善 1 退化）、对 M 差 0，开发失败，关闭当前五参数路线。
16. 0225失败实验 0225：完整竞技场上下文战术选择——准入阶段的工程故障首次在含英雄、法术、七兵种的完整竞技场里，让一个 63 参数的线性选择器在开局挑选整局战术（Fair / 压制射手 / 保护射手）。准入运行 18.188773 秒后因一处策略包装异常关闭：13 局自然终局、1 局真实异常、5 局随批中止、45 局未开始，零学习更新。根因（回合开始时临时单位到期后的结算）后来在实验 0344 修复。
17. 0226失败实验 0226：修好规则后重跑完整竞技场战术选择——固定选项没有足够收益在修复回合开始结算的 Core449 规则下，按 0225 原协议重跑准入：64 局全部自然终局、零故障，但压制射手 R 来源差 −.3125、保护射手 P −.125，只有 1 个来源出现改善，低于 3 个的门槛。零学习更新，44 个剩余状态未构造。
18. 0227失败实验 0227：完整竞技场里用 CEM 进化动作级偏好在完整竞技场里用 16 个公开特征给每个合法动作打分、用 CEM 以整局胜负搜索参数：808 局、3 次分布更新后，训练来源差 +.125（4 改善 0 退化）过线，但 8 个独立开发来源差 0、0 改善，开发门槛失败，关闭；12 个保留来源未开。
19. 0229失败实验 0229：用结构化动作特征的排序模型模仿规则 AI 的走位用 60,335 个规则 AI（T）决策训练一个只给动作打分的小模型。测试集完整菜单移动 Top-1 为 0.137，低于 0.25 的“可学”门槛，按协议结案；但新增结构化特征比只用旧公开列的消融高出 +0.112，移动类内 Top-1 0.340，表示上的改进是确定的。
20. 0232失败实验 0232：用更稳的优化重训动作排序模型，在新来源上测试按 0231 的诊断改用 Adam 3e-4、批 512，训练两种结构各 8000 次更新，按开发集选中 D-8000；在 0070 的新来源测试集上完整菜单移动 Top-1 为 0.214（0229 为 0.137），仍低于 0.25 门槛，结案。改善主要来自动作类型选择，落点排序没变；能攻击却移动的决策里模型 52.5% 选攻击。

规则缺陷的复现、修复与回归检查。

1. 0335失败实验 0335：防御 −20 的有限准入检查检查防御恰为 −20（伤害公式分母为零）在正常规则下是否可达：用 15 次合法操作就让防御到达 −20，随后一次合法攻击报错，准入未通过；当时商业游戏的零分母语义未认证，没有启动新训练。
2. 0350失败实验 0350：覆盖引导 fuzz 未达到 20% 的预定门槛新的 novelty 随机测试模式每步先试探最多 6 个动作、挑最少见的机制组合；在同一批 40 个种子上它覆盖 812 个机制组合，只比 default 的 773 多 5%，未达 20% 门槛，判为没有明显优势，但与现有模式互补。

AI 决策延迟与查询性能。

1. 0503失败实验 0503：公开查询提速，报告与动作保持一致但仍超预算去掉重复的贴身扫描和整份深拷贝后，压力输入完整决策 p95 从 1003.595 降到 214.794 毫秒、查询小计从 333.407 降到 113.155 毫秒，行为完全不变；仍高于 100/20 毫秒门槛，未通过。

截图与录像里的文字、数字、生物、界面读取，以及挑帧和实时采集。

1. P001不告诉位置的全图滑窗图标检索——英雄头像与主技能图标只给一张完整截图和图标的大致尺寸，用通用 ConvNeXt 视觉向量在全图 236,115 个候选框里找英雄头像和主技能图标；身份常常排对，但得分最高的框经常偏移、残缺或重复，不能直接当检测器用。
2. P002只用图标目录训练的分层通用图标嵌入用 354 个英雄/技能/生物/宝物身份的官方图标训练一个共享表示，再在真实全屏截图上滑窗找图标；只用图标目录和合成画布训练时，真实测试 F1 从通用基线 0.5161 提到 0.7647，后续定位改进 F4/F5 在验证/已看过的开发集上分别到 0.833/0.895，但测试集只有 18 个目标。
3. P003通用目标检测器能否找出游戏图标——零样本对比与冻结主干微调四个 COCO 预训练检测器在 39 张游戏截图上零样本对比，FCOS 最好（mAP50–95 11.89%）；只训练检测头后，8 帧留出集定位 F1 达 97.96%，但留出与训练部分来自同一录像，只是小规模试点。
4. P004B04 游戏图标分类器改编号为 B11（迁移说明）B04 不是一次新实验，而是“已验证游戏图标分类器”研究改编号为 B11 时留下的兼容说明；模型、数据划分和历史测量都没有改变，也没有重新训练。
5. P005战场六边形网格配准（旧编号 B06，已迁至 B15）B06 目录只剩一份迁移说明：战场六边形网格配准的代码与后续实验都已移到新编号 B15，历史结果、数据格式和博客地址保持不变；本页不含新的测量。
6. P006战场格子状态实验 B07——编号迁移说明B07 不是一个独立的新实验：它的代码和小样本数据在 2026-09-08 整体迁入后续的 B16 战场格子与高亮区域实验，旧编号只留一份入口说明，原结果没有重跑。
7. P007选秀生物名称 OCR（旧编号 B08，已并入 B023）B08 目录只剩一份迁移说明：用 OCR 读选择界面上的生物名称、再把名称和图标对应起来的工作，先短暂改名 B021，最终归入 B023；历史数据保持原路径，本页没有新的测量。
8. P008用人工确认的游戏截图训练图标分类器只用图鉴图训练的图标分类器，加入人工确认的游戏内裁图后，在同一批新测试图上从 79.49%（旧模型）提升到 99.22%（1277/1287）；独立的“这张裁图能不能用”判断头少误拒好图，但多放过坏图。
9. P009战场生物检测与身份分类——先找框，再认兵种在已确认是战场的截图上框出每个活体部队并认出兵种；第一轮微调检测器测试集定位 F1 84.25%，但“框对且兵种对”的联合 F1 只有 57.88%；扩充数据后在新对局上联合 F1 51.71%，仍不能可靠地自动维护部队身份。
10. P010战场活体部队检测器对比（FCOS / YOLO26s / RT-DETRv2）在完整战场原图上比较四个检测配方找“活着的部队”的能力：验证集按 AP 选出 FCOS（测试 AP50:95 70.67%），YOLO26s（nbs8）测试精确率/召回率 96.60%/96.80%、常驻推理中位 11.85 ms；RT-DETRv2 明显落后。只有一个随机种子、留出视频很少。
11. P011把战场六边形网格对齐到截图（B15，原 B06）用一张校准图拟合固定的透视变换，人工复核后的 3 张测试图上顶点误差中位数 2.757 像素、53 个参考点中 50 个在 8 像素内；随后比较的三种新边缘评分方法在全部测试图上都更差，没有采用。
12. P012战场格子状态——障碍物、黄/绿高亮区域与白色路径给定已校准的 137 格战场网格，从截图判断哪些格子有障碍、哪些落在黄色/绿色的移动范围轮廓内。障碍试点测试 F1 85.7%，但换三段新录像后降到 65.5%；高亮区域经多轮改进，最后在 10 张保留图上黄色/绿色召回 97.1%/97.5%、零误报，但重叠区和雪地黄色仍是弱点。
13. P013场景理解与 OCR 的系统设计，以及把各个读取器接回同一条视频时间线B020 先定下“场景 + 可处理性 + 关键帧”的总体设计，再在 9 月 10–19 日把 OCR、数字复读、书页、HUD、生物面板和状态图标逐步接进视频流水线；例如 18 张魔法书页 543 个可见字面 535 精确、8 拒识、0 错收，但这些都是开发录像上的接线与回归，不是独立准确率。
14. P014历史标题 OCR 实验入口（已并入 B023）这个目录只是一个旧编号的转向入口：最早的“标题文字 OCR 与图标对应”实验先叫 B08、短暂叫 B021，现在归 B023；本目录没有自己的实验结果。
15. P015用文字识别和小型状态机判断游戏画面处在哪个场景用 OCR 读出截图上的文字和位置，按“哪些字出现在哪里”判断当前画面（主菜单、选英雄、选技能、布阵、战斗……），再用一个只看过去的阶段解码器给出整局进度；两段开发录像 640 张关键帧中高精度 OCR 路线识别出 467 张、173 张保持未知，但没有任何人工确认标签，因此没有准确率。
16. P016文字识别读不出时，靠画面布局判断“这是哪个界面”为 7,435 条截图来源做了场景标注与 OCR/视觉交叉核对；三轮保守放宽“战场”门控后，视觉单独判出的战场从 608 增到 1,219（共 1,435 张），非战场误收始终为 0，但过渡画面放行从 17 增到 41，只作为离线选项，默认不改。
17. P017先读名字再认图标——用文字识别给选择页图标起名并辅助标注竞技场选择页上每个图标旁边都印着名字，读出名字再查目录即可得到身份；生物选择页 1,221 个标题中 1,218 个唯一匹配到目录名（覆盖率，不是准确率），五类选择页 64 个标题中 61 个匹配，并据此完成了 1,277 个待审对象的助手审核。
18. P018小标题与整屏 OCR 对照——从 6 个标题故障到 1,018 个字段的选型先用 6 个历史失败标题比较三种 OCR，PP-OCRv6 原图 6/6；再用 24 张原图 1,018 个参考字段选出整屏配方（972/1,018），追加小切块和 VL 数字复读后到 984/1,018。全部是开发集上的选型，参考待用户确认，不是独立测试准确率。
19. P019场景字段与英雄属性理解——在给定区域里保守地读数字和文字在人工给定面板和字段位置的前提下，从已有 OCR 结果里读出英雄、生物面板和日志字段：9 张开发图 68 个可读字段严格匹配 62 个、数字 0 个错误接受；后续补标与两次扩充都只是开发检查，不是独立准确率。
20. P020战场生物检测（旧编号 B026）——已并入 B12 的迁移说明旧编号 B026 的战场生物检测实验在 2026-09-08 整理时改编号为 B12，原目录只剩一份兼容说明；本文说明这个编号去了哪里、哪些东西保持不变，本身没有新的测量结果。
21. P021自动找到战斗面板与文字区域，再读出里面的字不给人工框，只用整张截图的文字识别结果定位英雄、生物、魔法书和日志面板；冻结后跨录像检查数值 21/42 读对、0 错接；之后的局部原尺寸重读把多组小数字补齐（如生命/攻防 28 项从 20 到 28），但放大图片会把 8 读成 81，半透明面板仍会被错误放行。
22. P022同一帧里，面板说的是战场上哪一个单位——实例候选首轮把现成的战场检测器和生物身份分类器接到 8 张已曝光的面板截图上，产生 71 个身份候选；人工只核对其中 13 个相关目标：9 个场上单位物种 Top-1 都对，另有 3 个框其实是面板立绘，9 个数量牌全部落在身体框之外。尚未实现自动绑定。
23. P023战斗 HUD、计时与行动条的单帧观察从一张战斗截图读出两侧英雄数字、计时和顶部行动条：开发检查中角落计时 30/30、英雄数字整组 32/34（2 组拒识、0 错接受），行动条 448 张卡片 0 漏检 0 多框，身份 0 错误接受；全部是看过的开发材料，不是独立准确率。
24. P024战斗日志的单帧读取与行动证据从截图中找出战斗日志面板、逐行框出并读出原文：44 张候选帧整理出 393 行（328 条两路 OCR 一致），面板开/关简单分类器在 15 张整段留出来源上 86.67%；效果日志 35 行中 33 行结构化正确、2 行拒识、0 错误接受，均为开发回放。
25. P025用前后两帧计时变化判断哪一侧在走只看前一帧和当前帧的左右计时读数，判断屏幕哪一侧的计时在下降：62 个连续区间中 56 个给出侧别候选（覆盖 90.32%），其余保持未知；没有独立行动真值，这是覆盖率不是准确率。
26. P026用脚下的数量牌帮助找回漏检的部队每支部队脚下有一块写着兵数的红/蓝小牌。用它来“担保”检测器打分偏低的身体框，开发复测的漏检从 31 降到 22、误检仍为 33；把“身体+牌”的联合框加进训练则不如原模型（漏检 56）。
27. P027稳定片段与关键帧挖掘——从录像里挑出“画面落稳”的截图用 96 组五帧样本训练一个小分类器判断画面是否稳定，把 30 秒视频的 900 帧缩成 68 张候选；后续多轮供样发现它会漏掉只出现零点几秒的短面板（7 次只留 3 次），固定 5 fps 补采找回 7/7，但也多收了 14 张半透明图。全部是开发数据，不是独立验收。
28. P028读出攻击和法术“释放前”的目标伤害预览（B034）从 3 段录像整理出 50 张审核参考图（30 张含预览、20 张对照）；全图 OCR 数字定位找到 29/30 个完整预览区域、20 张对照图零误报，简单 HOG 分类器在按视频留出的 31 个裁图上 F1 86.96%；技能目标预览没有确认到正例。
29. P029生物身上的状态小图标——先找到图标，再读角标与悬浮说明在已曝光的开发截图上，自动定位生物面板右下状态行的图标（固定参考 132 个框匹配 131 个），局部重读角标数字，并用像素字形规则补上 OCR 一直读错的 ∞（8/8）；但图标是什么效果、角标是否就是剩余回合，至今仍未验证。
30. P030再标十个对局后训练界面元素检测器——面板与槽位能找到，身份分类器不上线新增十个对局的审核标注后训练面板检测器和面板内元素检测器：最新来源上四类面板 42 TP / 0 FP / 0 FN，元素去重后 555 TP / 3 FP / 0 FN；但新训练的英雄头像身份分类器只有 5/10，差于旧匹配器，拒绝替换。
31. P031训练新模型之前，先让旧图标模型在审核过的裁图上考一次复用九月训练的图标身份模型（B11）对 1,540 张裁图推理：311 张有标签的裁图第一候选全部正确，但原接受门槛只接受 82 张、推迟 229 张；改用“只看有效性”的历史策略会接受 10/61 个空装备格，因此不采用。
32. P032读一张手动截图里的界面元素——把已有模型串成一个单图读取器输入一张 2560×1440 的战斗截图，不给任何真值，组合已有面板/元素检测、空槽、等级和身份模型输出界面元素；最新开发组上元素 555 TP / 0 FP / 0 FN、技能等级 60/60，身份正式接受 0 错，但大量身份只能拒判，热启动 p95 约 0.96 秒。
33. P033手动截图里自动找到战斗日志并读出每一行给一张完整截图，程序自动找到战斗日志面板、只对这一块做一次 OCR，输出原始文字、事件候选和无法归属的碎片；最新开发组 136 条事件中正文完全一致 134 条，但玩家名经常漏读，时钟+玩家+正文全对只有 47/136（34.6%）；预热后整图 p95 1.099 秒。
34. P034补回战斗日志里玩家名前被 OCR 漏掉的方块字形日志里玩家名前常有几个显示成方框的字符，OCR 经常漏掉；用亮度轮廓找方框、用颜色定位玩家名起点，最新开发组玩家字段一致从 47/136 提到 131/136（96.3%），三字段全对 129/136（94.9%），对已审核观察没有新增错误。
35. P035从原始截图读英雄、生物和 HUD 数字在手动单图读取路径上加入数字字段 OCR：最新 71 张开发图 363 个审核字段对 351 个、错 1 个、拒读 11 个，但只有 19/27 张图所有字段全对，未达到逐字段 95% 和十场独立对局的目标。
36. P036补审未计分的英雄 HUD 数值把一个读取器在 71 张截图上输出的 441 个未审核数值逐项对照原像素：102 个可见 HUD 侧面的 408 个字段全对，40 个没有 HUD 的侧面没有误报；另 33 个淡出面板字段 30/32 对、1 错、1 拒。全部来自同一个已曝光来源组，参考由助手辅助标注，不是独立盲审。
37. P037小数字读不出来时，只做一种保守的灰度补读（B054）直接把裁图换成放大/灰度版本会让训练字段从 547/562 正确跌到 480 或 522；改为只对“两遍读数一致但分数偏低”的整数做灰度补读后，281 张原图共补回 21 个此前拒判的值且都与参考一致，最新数据整帧全对比例 70.4%→85.2%。
38. P039先找到文字行的位置，再读生物标题和数量固定裁框会截断生物名称和数量；改为先检测实际文字行再读，校准组 276/280 → 280/280，最新组 2 处误读改为拒判，但一个清晰的 7/15 被误拒（最新组 357/363 → 356/363），因此只作为显式可选功能保留。
39. P040透明生物面板后面的小数字——用字形几何复核属性读数生物属性面板是半透明的，背后战场上的小数量牌数字会被 OCR 拼进属性值（32 读成 432）；按前景字形的高度和底边重新取框复核，纠正了 3 处真实误读且没有丢掉任何原本正确的值，但直接用新框替换全部读数的方案因引入新错误被否决。
40. P041生物面板在动画中下移时，按当前文字位置重新定位读取区（B058）用面板标题、阶级和技能文字的实际位置平移 11 个字段的读取框，训练来源局部字段正确数 575→662（漏读 74→3、0 误读）；但最新数据的补充面板出现一处回归（31→30 正确），所以仍是实验开关。
41. P042补全生命值、数量和兵力小数字，同时避免假拒判（B059）从 7 个训练失败种子扩出 45 帧、555 个位置精标后，比较 6 种裁图并只冻结三条保守补读规则；新 45 帧的完整值正确 408→419/441、0 误读，最新数据保持 356/363 不变，17 次值变化全部是已精审的恢复或修正。
42. P043用当前图案交叉核对英雄、技能、装备和兵种身份旧分类器的首选身份常被有效性门槛拒绝；新增“首选候选 + 规范图案匹配一致且位置确实被占用”才接受，最新开发组整图正确接受从 32 提高到 116/130，新误认 0、拒判 10、漏检 4；英雄仅 12/22，仍是首要缺口。
43. P044英雄头像被旋转了——用局部特征对齐修复图案匹配拒判上一轮英雄头像只有 12/22 被接受；逐张看训练拒判后发现游戏头像相对标准图案旋转了约 +9° 和 −22°，加入局部特征对齐后，最新开发组英雄 12→20/22、全部身份 116→124/130，误认仍为 0，但英雄 90.91% 仍不足 95%。
44. P045装备槽“看不清”时不要说成“空”旧的装备占用分类器只会二选一（有装备/空），面板淡入时也硬判为空；新增按槽型比较的局部复核后，新采样中 8 个无法判定的位置声称“空”的次数从 6 降到 0，代价是 2 个清楚的空槽被误拒；371 张旧图中 259/259 空槽、441/441 有装备保持正确。
45. P046按实际检测到的面板位置读取左侧英雄预览选择页上英雄预览面板在左侧，读取器却总是裁屏幕中央，导致漏读真装备、把右侧选项当装备；改为按实际面板位置裁图后，19 张左侧页面声明的界面框从 108 提到 608/741（召回 82.05%），多余角色框 26→0，但 133 个空兵种格仍全部漏框。
46. P047补齐兵种格——包括空格和没填满的一行旧训练数据里 217 个兵种框全是“有兵种”，导致 133 个空兵种格全部漏检；补充空格数据并训练专用检测器后，19 张左侧面板清单从 608/741 提升到 741/741，新选兵图 105/105 位置的空/占用全部正确，但严格定位 mAP50–95 只有约 90%。
47. P048英雄面板淡入淡出时，用当前画面里的格子重新对位再补读英雄面板动画时会轻微缩放和平移，导致整块对位失败、漏读兵种数量。改用当前画面检测到的装备格和兵种格局部拟合位置后，49 张过渡图上可读数字正确 373→475/541、兵种占用 154→196/224，且没有新增误读。
48. P049等目标区域稳定了再精读——跳过淡入淡出和翻页动画的选帧器视频里面板打开、关闭、翻页时的过渡帧读不准；新的选帧器只在目标区域连续两次采样几乎不变时才送去精读，冻结后在其它来源上覆盖 13/15 次已标展示（漏 2 次底部提示），选中的 8 张面板图 80 个数值全对，清楚区间开始到选帧 p95 334 毫秒。
49. P051用小型检测器找完整悬浮提示框，再挑稳定帧读字上一轮固定区域方法漏掉全部底部提示；改训练一个单类“提示框”检测器后，冻结评估 5 次已标展示覆盖 4 次，抽查 12 个文字字段 11 个正确、1 个未读。短暂出现的提示和重复读取仍未解决，未接入 App。
50. P052只看过去的短时加密采样——补回一闪而过的提示框每 100 毫秒检测一次提示框，发现提示但还没稳定选中时，在最多 300 毫秒内请求更近的真实后续帧；此前每次只有一张清楚帧、全部漏选的三次“魔法书”标签全部选中并读对，评估的 12 个文字字段 12 对，但训练里同内容重复读取从 10 增到 11，另有一个极短提示仍漏选。
51. P053用局部变化检测减少同内容的重复读取把“整块平均像素差”换成“小幅对齐后取最大局部残差”，训练回放中同一提示的额外读取从 11 次降到 0，已审展示覆盖不降；评估组新增 1 次重复读取，总读取 24→14，尚未接入默认读取器。
52. P055读日志时先留住后来的清楚帧——读取反馈与有界候选缓存OCR 读一张较淡的日志截图要约 0.4 秒，读完发现有问题时清楚的画面可能已滚走。加入“格式缺损提示 + 最多两张等待原图的缓存”后，同样 114 行日志三项全对从 108 行提高到 113 行，读取次数 40→55；回合标题和一处漏字仍未解决，未接入 App。
53. P056识别日志边缘被截断的残行，减少无收益的重读滚动的战斗日志窗口常把首尾一行截掉一半，导致整页反复重读；用文字带高度和边缘密度标出“可能被截断”的首尾行，训练回放中第二次尝试从 12 次降到 8 次、三字段全对保持 113/114，但出现 1 次队列溢出，且这不能代替完整读取。
54. P057按真实时间播放视频，让“等稳定再读”接上真正的检测和 OCR把区域稳定选帧、有界读取队列和真实的检测/OCR 串起来，按 1 倍速逐帧喂入 8 段录像窗口（2,133 帧）：冻结评估覆盖 9/10 次已标清楚展示，人工精审的有限字段全部读对（但一个回合标题读错），帧到达到结果交付 p95 约 1.2 秒。
55. P058把保存原图挪到后台——减少采样被磁盘写入卡住按真实播放速度回放录像时，采样线程要等每张 PNG 写完才继续，导致大量帧“来晚了被跳过”。改成最多两张待写的后台归档后，晚到跳过 215→47，但实际多处理的帧只有 3 张、读取时延没有改善，书页上 18 个数字字段在当前组合里仍没有输出。
56. P059从完整截图读魔法书图标上的角标在魔法书页的每个法术图标旁找小圆圈并读出三个角标：冻结后评估 6 页可见角标对 129/189，稳定页 106/141，0 个接受错值；左下罗马数字只读对 18/63，是主要缺口，未达 95%，功能默认关闭。
57. P060用当前像素的字形模板补读法术书上的小罗马数字（B077）OCR 常把法术书角标里的罗马数字 I–V 读丢，改用按来源组留一验证选定的字形模板补读后，评估集稳定书页字段 106/141→125/141（88.65%），罗马角标 16/47→35/47，0 个错值；仍未到 95%，剩余主要是圆圈定位失败。
58. P061法术书角标定位修正——用同页多个小圆圈校正搜索位置法术书页上的小角标常因搜索提示偏了十几像素而被判“没找到圆圈”；用同一页已找到的圆圈拟合共同偏移后，稳定评估书页的角标读取从 125/141 提升到 139/141，本批没有接受错值，但新增分支的时延尚未测。
59. P062稳定英雄面板逐位置精审——找出子技能和英雄头像的拒判对两张稳定英雄面板逐个位置建立“应该有什么”的分母，再对照当前读取器输出：82 个已支持位置全部找到，身份 62/69 正确、0 个接受错值，主要缺口是子技能 12/18 和一个英雄头像拒判；48 个背包格尚未实现。本轮只提供数据与诊断，没有发布新算法。
60. P063用真实子技能小图标做补读——先挡住错误父技能，再在分离来源上检验英雄面板上的子技能小图标很小、彼此相似。先精标 135 个真实样本，再加上“独立核对父技能图案”的保护，训练来源留出对照从 99/135 提升到 111/135；三张分离来源截图 21/27 → 25/27、0 接受错值，仍低于 95%。补读以显式选项接入单图工具，默认和 App 不变。
61. P064目标伤害预览数据盘点，以及用战斗日志回找预览的离线检索库盘点旧的伤害预览标注后发现只够做原型和回归，不足以训练或证明 95%；本轮新建一个按日志文字检索录像的离线库，在一段训练录像里精审出 11 帧 19 个预览字面区域和 72 条日志行，并看到“书页关闭”“日志出现时间”都不等于施法时刻。
62. P065用日志、蓝量变化和连续扫描三路找伤害预览小字为了收集“攻击/施法前的伤害预览”训练样本，在已准入训练录像上用日志时间、蓝量变化和连续全图扫描三路采集并人工精审；两段录像合计人工确认 154 帧 193 个两行预览区域，但这只是数据采集，不是检测器精度。
63. P066伤害预览——先找图标再分两行读数字用骷髅和伤害两个小图标模板在整张截图里定位攻击预览，再分别读上下两行数字：两批已曝光训练来源的 193 个已知区域从原方法 170 个读对提高到 189 个，但范围伤害只有 49/53，仍有 4 个已知失败，未替换默认读取器。
64. P067从选秀的子技能选择页补充真实图案从训练录像的子技能选择页精审 12 页、108 个可见位置，把真实图案身份覆盖从 32 类扩到 69 类；只加入 70 个小图参考后，英雄面板子技能留出查询 111→115 正确，三张曝光评估图 25/27→27/27，没有新增误认。
65. P068修复离线采样时视频跳转越过目标窗口OpenCV 跳到 74.1 秒后实际读到的是 146.7 秒的画面，导致 74.6–74.8 秒的采样窗口返回 0 帧；改为检测到越界后从头顺序解码，该窗口恢复为 2 帧，74.6–147 秒的 2136 帧与 FFmpeg 源时间逐帧一致，旧 8 个窗口结果保持不变。
66. P069伤害预览读得对，但“打的是谁”仍是短板精审两段训练录像 12 张图的 17 处伤害预览，字面 17/17 与已有输出一致，新增 15 条“预览→受伤生物”关系；但用当时的身体模型，最近框加身份首选只对 6/15，局部重检尝试也无效。后续更正：本轮误用了较旧模型，换用已有更好模型后为 13/15。
67. P070纠正旧基线，用已精标数据改善战场生物身份识别发现上一轮误用了旧检测基线后改用已有的更强模型，并把 4,588 个已审核的战场身体样本加入身份分类器训练：同 715 张参考裁图 Top1 从 73.01% 升到 93.57%，用真实检测框的联合召回从 70.91% 升到 90.35%，仍未达 95%。
68. P071先修训练标签，再补薄弱的战场生物样本战场生物身份识别的低分不只是缺图：复查 74 条弩兵家族训练样本，发现 11 条身份标错、2 条裁图不可用；修正并补 6 个新样本后重训，验证集参考裁图 Top1 669→681（93.57%→95.24%），完整图联合召回 90.35%→92.59%。
69. P072先审训练标签再重训战场生物身份模型，并做一次留出录像验收（B089）复核 176 个蜂类/九头蛇身体后只纠正 7 条训练标签并重训一次：参考裁图身份 681→689/715，但整图开发无净提升（662→662）；冻结后在两段留出录像 969 个身体上联合精确率/召回率 90.73%/90.92%，仍不足 95%，另发现 11 条测试标签错误单独记录。
70. P073把战场生物候选接进单张截图读取入口把已训练的生物检测器和身份模型接入单图读取工具：12 张近期战斗图的 169 个候选与冻结结果完全一致，30 张图其余界面输出不变；完整读取 60 次热调用 p95 2.196 秒；但面板遮挡规则会排除半露的真实生物，魔法书装饰处仍有低分错误候选。
71. P075从旧模型出发补学生物身体身份，同时保住已有能力以旧身份模型为起点和冻结教师，在旧训练样本上加一项“别偏离旧输出”的约束、新标签不受约束；一次训练即通过预先冻结的选择门槛：参考裁图 689 保持，完整图联合正确 662→664，虫巢之母 14/14，但仍未达 95%。
72. P076在十张近期战场截图上，把每个可见生物都标出来再考一次检测与身份冻结检测器和身份模型，在 10 张近期截图（5 张开局战斗、5 张魔法书遮挡）上逐个标出 104 个可见生物身体：开局图“定位且身份正确”64/70（91.43%），魔法书遮挡图只有 18/34（52.94%），合计 82/104（78.85%）。
73. P077减少法术书侧书签被误认成战场生物打开法术书时，书页侧边的彩色书签会被战场生物检测器当成生物身体。一个只针对紫/蓝两签组合的窄规则在冻结后的 10 张回归图上把书页定位精确率从 19/25 提到 19/21，召回和身份正确数不变；事后更正发现训练中一个“纯书签”框其实含一小段真实生物。
74. P078给法术书边缘露出的局部生物身体补精确定位标注打开法术书时战场生物只露出头、翼、尾等碎片，旧检测器在这类局部身体上很弱；本实验在 7 张训练来源书页图上精标 42 个当前可见身体，导出 6 图 35 个可训练框，并用旧预测显示六图只找到 19/35（书页局部身体 21 个只有 6 个合格）。没有训练新模型。
75. P080魔法书打开时被遮住的部队——补 11 张训练参考并诊断旧检测器打开魔法书时战场大部分被挡住，部队只露出一部分。本轮精标 11 张图 62 个可见身体，用作训练补充；旧检测器在这批困难图上对主体可见的部队找到 21/22，局部被遮的只有 12/40。没有重训，也没有准确率提升的主张。
76. P081被魔法书遮住的部队——建立四个来源的开发参考集为“魔法书打开时露出一部分的部队”建立只用于评估、不进训练的开发集：10 张图、59 个可见身体、4 个来源组。旧检测器找到 35 个、误报 4 个，主体可见的 28/28 全中，局部被遮的只有 7/30，重复验证了上一轮的失败类型。
77. P083书页边缘生物框的质量精审与去重反例精审法术书页旁 16 张训练帧的 161 个生物身体候选框，29 个“误报”里只有 5 个是纯书页 UI；固定几何去重对照中，“包含率去重”只少 1 个误报却删掉 5 个真实恢复，被否决；即使用真值做理论最优匹配，也只能到 85/92。
78. P085法术书页上的生物检测——两个检测器的框按分数统一去重书页遮挡时，局部检测器能找到更窄更准的生物框，但旧流程“整图检测优先”会让旧宽框挡住它。改为两路候选按检测分数统一做 NMS 后，书页开发集从 45 正确 / 5 误报提升到 46 / 4，通过预先冻结的门槛；真实整帧读取（含保存）p95 1.866 秒，显式可选，默认和 App 未启用。
79. P086前景面板优先——打开面板时不再读被挡住的背景用户明确：打开法术书、英雄或生物面板时不关心背后的生物。单图读取入口默认改为只读前景面板，5 张真实截图的前后对照显示四类面板的背景身体/预览/HUD 调用都变为 0、面板内容的读数和接受决定不变；首轮严格逐浮点比较因分数微差失败，已如实记录。
80. P087魔法书页上的法术名称，按原样读出来单图读取原先只匹配魔法书的图案、不读名称文字；新增按槽位裁出名称行再识别后，冻结开发集 148 个名称中 145 个读对（97.97%）、0 错接、3 个低分拒读，48 个空槽没有误输出。
81. P088读出魔法书格子中央的冷却数字用一个遮住数字区的沙漏圆章模板定位魔法书格子中央的冷却标记，再交给 OCR 两次一致读字：训练页 9/9、冻结开发页 5/5 正确，518 个无数字位置零误输出；但正例只有 14 个，0、7 以上和多位数都没有真实样本。
82. P089魔法书逐格“完整观察”审计——单项都很高，合起来是 81%不再分别看各字段的准确率，而是以 14 页、148 个可见法术格为固定分母，要求同一格的法术身份、名称和全部角标数字同时正确。结果 120/148（81.08%）完整验证；还发现一个把“III”读成“II”的错误接受。
83. P090被截断的罗马数字，不再被当成另一个完整数字魔法书角标 III 的右侧一笔碰到裁区边缘，旧逻辑丢掉这一笔后把剩下的 II 高分接受；新规则遇到碰边的合格笔画就整个拒绝。开发 14 页罗马数字从 140 对 / 7 未知 / 1 错变为 140 对 / 8 未知 / 0 错，读对的数量没有增加。
84. P091用法术大圆框帮小角标定位，并只读用户需要的字段用每个法术格的大圆框和其他格子的相对位置，重新找漏读或偏移的小数字圈。按用户澄清后的字段口径，14 页 148 个法术的所需字段同格完整 142→143（96.62%），身份+字段 128→129（87.16%）；实际净收益只有 1 个右下数字。
85. P092图案中心被数字挡住时，用外圈图案认出法术魔法书法术图案的中心常被冷却数字徽章覆盖，旧匹配因此拒判；改为遮住中央、只比较外围可见图案后，训练恢复 8 个、开发恢复 5 个法术身份，无新增错接；开发 14 页“身份+所需文字同槽全对”从 129/148 提升到 134/148（90.54%），仍未达到 95%。
86. P093魔法书里图案与印刷名称联合判断，修正共用图案的版本误认同一个法术的基础/高级/专家版本共用一个图标，单看图案会认错；把同槽的印刷名称和图案联合判断后，14 张开发书页身份错误 9→0、正确 139→142/148，身份加必需字面完整 134→137/148（92.57%），仍未到 95%。
87. P094从完整截图开始评分伤害预览，并暴露“目标关联”尚未实现为伤害预览建立以整张截图为起点的参考与评分：30 张图 31 个预览中，发现 29/31、位置和两行数字全对 27/31、2 个错误接受（范围值的横线漏读成长整数），没有误报；自动把预览关联到受影响的生物仍未实现。本轮只完善了参考和评分，没有提高识别率。
88. P095整图读取输出“伤害预览指向哪个生物”的候选用预览与生物身体框的上下几何关系给出目标候选，27 个明确目标中对应正确 24 个（88.89%）、错误 0、未解析 3；再强制要求数量牌支持只会多拒绝、不减错误（22/27），因此不作硬门槛。只作为显式开启的候选输出，未接默认。
89. P096在三个新训练来源上精审整图伤害预览并定位真实失败用冻结的整图读取器读三个新训练来源的 28 张精审截图：24 个预览全部找到，两行文字 23/24 正确，目标候选 20 正确、4 未关联、0 错绑；唯一文字错误是把 449 误拆成 4–49，并找到两个身体低于阈值漏检等四类具体失败。
90. P097别把正确的 449 拆成 4-49攻击预览里的“横线补救”会把两个数字之间的弯曲连接误当成横线，把正确的 449 改成 4-49；新增“至少一半行要完整贯穿”的形态条件后，新批 24 个预览两行文字从 23/24 变为 24/24，旧两个真实横线恢复和 189/193 的历史成绩全部保持。
91. P098用“上方预览 + 下方数量牌”两个锚点找回漏掉的预览目标两个伤害预览因目标生物的身体检测分数低于门槛而无法关联。第一次“围绕数量牌裁大窗重检”新增 14 个框，其中 2 个是邻居肢体碎片、1 个未知，未采用；改为只接受同时被上方预览和下方数量牌唯一支持的低分整图候选后，三来源 24 个预览的已核对目标从 20/24 提到 22/24，0 错绑。
92. P099读战斗界面上的时钟、集能点和技能数字在 12 张普通战场截图上读出四个计时器、三颗菱形的“集能”点数和技能格中央数字：时钟 48/48、集能 12/12（修正一个颜色范围后）、技能数字 1/1；但没有 3 点正例、技能冷却含义和当前行动者都未接通。
93. P100用行动条首卡和底部头像互相核对“当前行动者”，并扩充技能数字样本（B117）19 张精审截图上，行动条首卡与底部头像一致时 9/10 正确、1 未知、0 错；底部头像身份经一次尺度修正从 3/14 升到 14/14；技能中央数字仍只读对 5/8，逐圈直接 OCR 只读对 2/9 且有 6 条高分误报，未采用。
94. P101技能槽中央的小数字——先确认白色字形，再交给识别器底栏技能槽中央的小数字常被整片文字检测漏掉，直接把裁图交给识别器又会从技能图案里“读出”数字；先用白色字形检查确认这里真的有字后再识别，44 张整图中可读数字 12/19→18/19，1 个未知、0 错，321 个无数字位置 0 误报。
95. P102冻结后的战斗行动 HUD 读取器换来源验证把已开发好的行动 HUD（时钟、集能点数、技能冷却数字）读取规则冻结，在两个未参与开发的来源组 21 张预先固定的截图上验证：时钟 48/48、集能 12/12、无数字位置 117 个 0 多读，但技能数字只有 3 个且都是“1”，不足以证明冷却识别泛化。
96. P103把技能悬浮说明的结构化读取接入单张截图入口复用已有的说明框检测、文字识别和字段提取，把生物技能悬浮说明的名称、类型、正文、消耗、持续时间原文等接入完整截图读取；修复两处接线问题后，7 张真实说明全部得到字段，37 个字段严格正确 36 个，6 张控制图和 21 张冻结控制图均无误报。样本是曝光开发图，不是全项目验收。
97. P104把生物状态行读取接进单张截图读取入口在 65 张开发截图、142 个可见状态图标上，三轮修复把“定位且角标正确”从 18 提到 141（99.30%），错值与多报始终为 0；但数字的“剩余回合”含义、效果身份和单位归属仍未知。
98. P105状态悬浮说明接进单张截图读取，并与同帧图标建立候选关系16 张有状态悬浮说明的开发截图上，只靠完整提示框检测时标题+正文仅 8/32 正确；补上“在已登记的提示带里搜索”后达到 32/32，8 个有人工位置参考的图标关联 8/8 匹配，19 张控制图零误报。另修复了一个会错误接受截断正文的缺陷。
99. P106读完整条行动卡，并在行动条切换的瞬间跳过把已有的边框扫描、头像匹配、颜色和数量读取组合成“读整条行动条”：11 张稳定截图 141 张卡全部找到、数量对 137 张、0 个错值，但同卡三项全对只有 110 张（78.0%）、整条全对 2/11；首位空缺的切换帧改为明确跳过。
100. P107行动条卡片的身份与数量补读对行动条上旧方法认不出或读不全的卡片做补读：训练图身份 114→141/141、数量 137→141/141；冻结后在旧校准图上数量只有 132/148，修正后 147/148（已不算独立验证）。整张截图读取仍需约 19 秒，远未达到 3 秒目标。
101. P108行动卡批量匹配——观察结果不变，整图读取从约 19 秒降到 1.5 秒把行动条卡片的掩码模板匹配搬到 GPU 批量计算，再用原 CPU 算法复核前几名，保证返回结果与原来逐项一致；37 张已曝光原图输出完全相同，驻留路径 18 次热调用 p95 1.505 秒（原约 19 秒），但不是新的独立准确率或 App 端到端验收。
102. P109行动条读取规则冻结后，换一组较新录像验证把行动条（回合顺序卡片）读取配置冻结后，在一组未参与调参的较新录像上检查：20 张稳定图 254 张卡全部找到、身份全对，同卡身份/数量/队色三项完整 251/254（98.8%），0 错值；但 1 张卡片滑入中的瞬态帧被错误放行。
103. P110当前行动者的首卡身份复用同帧行动条的内区补读行动者模块读不出行动条第一张卡的图案时，改为复用同一次读取里行动条对同一张卡的内区补读结果；在曝光开发数据上首卡图案正确 21→23/23、0 错，行动者核对 15→17，等待帧误核对 0。这是窄修复，不是新的独立准确率。
104. P113识别底栏当前生物的技能图标用带圆形掩码的多尺度模板匹配，在 123 个主动技能图标中认出底栏技能槽的身份；规则在训练开发集上冻结后，先标注再匹配的 54 槽验证中目录技能 43 对、0 错、8 未知，非目录图标 0 误接受。
105. P114从对局截图推断对方的技能、魔法和装备把截图读取结果交给状态估计，用可见的日志、HUD 和行动卡按规则推出对方构筑的候选：9 局测试中对方英雄 9/9、对方法术 9/9、0 误报；训练 15 局法术 20/20、规则候选组 12/14。数据是助手精标的已曝光开发局，不是盲测。
106. P115识别战场 HUD 上的英雄头像（重点是敌方英雄）旧匹配器在战场 HUD 头像上几乎全部拒判（敌方英雄测试 11/78 正确）；新方法先用训练局里已审的 HUD 头像样例匹配、再退回游戏原画多尺度匹配，门槛只在训练集上选定，测试集跑一次：156 张中 125 正确、31 拒判、0 错，敌方 53/78。
107. P116游戏感知的关键帧选取——先标“界面事件”，再训练选帧器在 28 个训练录像窗口上逐段标注 UI 事件，训练一个在线选帧器：开发交叉验证召回 98.2%，但一次性留出只有严格 95.3%、宽松 96.9%，复核后的真实污染 0.7%；未达 98% 召回目标，但经用户同意接入生产，决策延迟中位约 0.7 秒。
108. P117生物面板状态图标是什么效果——已审样例库加高阈值生物面板上的状态图标是一套风格化符号，与法术原画不对应，目录模板用不上；改用已审样例库做颜色相关匹配，事后定的 0.88 阈值在 33 个新测试图标上 16 对 / 0 错 / 2 未判 / 15 正确拒识。21 类符号中只有 7 类有可信名字，生产未接线。
109. P118HUD 英雄头像——认出训练局里没见过的英雄当样例匹配认不出新英雄时，再用一个自监督视觉模型（或无 Torch 的颜色布局特征）与原画匹配“互相确认”：测试 9 局逐帧头像 125/156 → 142/156，敌方 53/78 → 70/78，全部 0 错；合计敌方 78/86（90.7%），仍未到 95%。
110. P119生物面板上的士气、幸运、先攻和速度小数字（B138）测试局 25 个生物面板上幸运原来只读对 15 个（另 10 个读对但分数低于 0.90 被拒）；改用“两遍一致即可接受的较低门槛 + 训练局字形原型”后，四个字段在冻结后的唯一一次测试中都是 25/25、0 错，并已接入截图路由器。
111. P123从训练录像和更早录屏里扩充战场英雄头像样例战场顶部英雄头像的识别依赖一个“已审核局内裁图”样例库，测试集剩下的未知都是库里没有的英雄；13 个训练录像里没有新英雄，用户允许使用更早的录屏后找到 28 局、8 个目标英雄中的 5 个，新增 39 张候选样例；训练侧留一局评估 1,991 张裁图 0 错，未知从 152 降到 69。
112. P124从一张战场截图读出每个兵堆的位置、阵营、数量和兵种把数量牌、行动条和生物身体识别组合起来，逐个兵堆读出格子、红蓝方、数量和兵种：开局测试 224 个兵堆全对 204（91.1%），中后段测试 362 个只有 76.8%，加入数量牌探测和同局历史后提高到 79.8%；仍远低于 95%。
113. P125把旧录像整理成按局截图包并逐张精审把 48 段较早的原生分辨率录像按局切分、选帧、由 13 个标注助手逐帧像素精审，最终得到 111 个截图包、1,785 张图（训练 75 局、10 月测试 10 局、旧录屏测试 26 局），并发现场景标签、确认页法术数等若干系统性问题。
114. P126请第二位独立复核者重标测试数据，看原标注有没有系统性错误第二位复核者不看任何现有答案，只从原图重标 10 局测试数据并逐字段比对：约 900 个可比字段里原标注只有 3 处错误（2 张场景、1 个能力名），面板数字 297/297 一致；复核者自己在被遮挡单位上也错了 2 处。
115. P127离屏真实 App 按键回放——每次发版前的端到端门槛（补记）在不开游戏的情况下启动真实的战斗记录 App，只把“截屏”换成按顺序返回测试局截图，逐次按截图键并计时。多次发版门槛中 13 个测试局 182 次按键 0 失败、敌方英雄 13/13、敌方法术 11/11、0 误报；它还抓到过一次每次刷新 94 秒的性能回退、一次读到第 41 张就停止的存储错误和偶发原生崩溃。原实验没有书面报告，本文由脚本与交接记录补记。
116. P128对方技能/装备推断怎么验收——用我方构筑做对称检验对方构筑看不到，就把我方当成“对方”来检验推断：测试 10 局的 14 个候选组全部包含真实项，4 个单选断言全对，达到事先定的标准；但真实构筑只有 15/231（6.5%）被任何候选提到——大部分技能装备不在截图里留下痕迹。
117. P129不按截图键，自动挑关键帧分析——流式选帧、阶段门与行动条提速战斗中不再依赖玩家按截图键：流式选关键帧、选秀阶段直接丢弃、有界队列送去读取；行动条兵种匹配在读数不变（51/51）的前提下从约 265 秒降到 103 秒；两局测试里自动模式比手动截图早约 1.5–3 分钟认出敌方英雄，还多找到 2 次敌方施法，但有界队列会丢帧。
118. P130战斗前“最终确认页”读取——错误从 8 降到 0，漏读从 1,217 降到 104在 69 张训练池确认页上，修复技能小图标配对、空槽判定、法术栏重新居中等问题后，逐字段对/错/漏从 4,328/8/1,217 变为 5,421/0/104（另 28 个像素不可区分的并列）；测试池只读一次，按更正后的标注解析为 2,442 对、0 错、229 漏。
119. P131旧录屏测试局标注的独立二审26 个旧录屏测试局（444 张截图）原本只有一位标注者精审过。两位不看原标注的 AI 助手复核者从像素重标后逐字段比对，只发现 1 处取值冲突（裁定原标注正确）、8 处原标注留空由复核补全；可作测试真值使用，但二审者也是助手而非人工。
120. P132用精审截图训练场景分类器用约 1800 张逐帧审过的截图训练“这张图是哪种画面”的分类器：全局缩略图上训练的模型没有超过现有参考库（测试准确率 0.923 对 0.926），但新加的“预览弹窗骷髅图标”检测器让组合分类器测试准确率从 0.926 升到 0.970；开战瞬间与布阵、两类预览之间仍未达 95%。
121. P133把一晚上的实战录像做成按局测试截图包175 分钟录像经 5 fps 场景扫描切出 3 局，每局导出 20 帧，由三个助手各盲标一局，接收 56/60 帧，打成 3 个测试包并全部通过校验；标注是盲标的模型目视核对，不是人工真值。
122. P134把一场实时对战电脑的录像做成训练截图包（补记）用户 10 月 9 日用战斗记录 App 实时对战电脑后，要求把这段录像当作训练数据：录像无损剪到第 10–136 秒，复用旧录像截图包流程扫描、选帧和像素精审，得到 1 个 8 张截图的训练包（只覆盖第 1 回合，无战斗日志）。原报告缺失，本文按代码和保存数据补记。
123. P135实时模式漏掉短暂日志的原因，与按键到简报的时延分解自动模式漏掉只停留约 3 秒的战斗日志，不是选帧规则漏了，而是选帧服务每帧都开全核线程池、被挤掉帧；改为单线程预测后每帧 28.5→8.9 毫秒，同段回放找到 5 个日志关键帧和敌方两个施法。安静机器上按键到第一次简报 p50 3.34→1.85 秒，p95 仍约 4.8 秒。
124. P136测试局逐场景、逐字段准确率用当前截图路由器把 39 局测试截图包（626 帧）逐字段对盲标真值：英雄栏 96.9%、生物面板 97.0%，给出的值几乎不错（英雄栏 1 错、生物面板 0 错），差距几乎都是漏读；英雄身份 94.4% 和攻击预览场景 90.9% 低于 95%。
125. P137只有一两个法术的法术书页法术书定位原来要求同一排至少 3 个法术标题，只有 1–2 个法术的稀疏页会被当成战场；降到“同排至少 2 个”后，训练集法术书 156→161/167 且其他场景 0 误判，测试集只评一次：79/82，仅 1 帧输出改变。
126. P139一局打电脑录像的战斗日志读取——28 条关键字段全对、OCR 成本实测，以及“第 4 回合”标题的行匹配修复在一局选入训练的打电脑录像上，当前日志读取器 28/28 条选定字段读对，但每张图 CPU 约 70 秒，且“第 4 回合”标题被拒。计时显示 99.7% 以上的时间都在 OCR，没有可安全删除的冗余；标题失败的真因是第三次 OCR 读对了字、却因右边差 16.667 像素超过 16 像素被行匹配丢掉，受限的居中匹配修复后三个标题全部保留，公开 SE 结果不变。
127. P140训练数据覆盖盘点——日志句式、状态、能力和法术各有多少截图样例从游戏安装文件生成目标清单（日志句式 37、法术 88、生物能力 491、状态 400），扫描 51 段录像的生物面板和日志画面 4,210 帧并自动匹配文字：日志句式 29/37、状态名 86/131、能力名 316/491、法术名 31/88 有样例；事后发现采集没有按数据池过滤，混入了两段冻结评估录像。
128. P141读取我方英雄窗口（战斗英雄面板与选卡页）选卡页和战斗中的英雄面板上都有同一个英雄窗口，只是位置不同；用固定的分类图标条配准后复用确认页读取器，一局训练回放中“我的信息”从英雄、技能、装备全空变为读出英雄、5 项技能、9 项子技能和 9/14 件装备——这是功能验证，不是准确率。
129. P142打开的法术书属于哪一方——用书上印的魔力对照英雄界面（B161）252 张法术书画面中 248 张读出了书上的魔力；其中 241 张只与一侧英雄界面的魔力相同且我方一侧已知，这 241 张全部指向我方；两侧魔力相同的 4 张保持未知。规则已接入感知、状态估计和 App。
130. P143战斗界面布局表草案与五个实机问题为了让模拟器里的 AI 能像真人一样点鼠标、按快捷键，从录像和游戏安装文件里量出底栏按钮、法术书格子的原生位置，并回答五个界面行为问题；其中“延展模式点相邻敌人”的结论与模拟器现有假设不同。事后发现开发时用了测试池录像，相关录像对这些字段不再是盲测材料。
131. P144生物面板上的状态图标是哪个效果——与游戏安装图标做模板匹配（B163）用悬停提示自动产生弱标签，在 379 个“传播标签”图标上，两阶段带遮罩匹配给出正确等价类 362 个（95.5%）、每个图标 8.7 毫秒，并接入路由器；但阈值和尺度是在包含测试池甚至冻结评估录像的数据上选的，这个数字不是盲测成绩。角标数字最终确认为剩余回合。
132. P145为生物状态图标准备一套待人工审核的“金标准”数据从 46 段录像中按来源隔离选出 600 张生物面板帧（开发 350 / 测试 250），机器预标 36,000 个字段并做成离线审核网页与合并、评分工具；但已审核字段为 0，这还不是金标准，也不是识别准确率。
133. P146远程攻击的距离百分比与治疗预览确认读取器能处理两种特殊的目标预览：远程射击的距离百分比原本就能读；治疗/复活预览以前被误读成“击杀 0、伤害 10”的攻击预览，现在按绿色数字识别后跳过。回归 196 个攻击预览，判为绿色的 2 个都是真治疗预览，其余 194 个没有误删。
134. P147实时模式下让更多抓到的帧送进选帧服务实时回放中只有约 74–79% 的抓帧送进了选帧服务，原因不是服务慢，而是两个各走各的取帧时钟和 GUI 线程卡顿；加一个 8 帧待发队列并给存储读取加缓存后，送达率在 300 秒回放中提到 96%，后续重测达到 98.4%。
135. P148为战斗日志建一份可审核的逐行参考数据（B167）从 42 段录像选出 400 页战斗日志，去重得到 4323 行、30697 个机器预标注字段，并与生产日志读取器逐页对比（例如时钟一致 3175/4247、逐字原文一致 1630/4323）；人工审核数为 0，这些数字只是机器预标注之间的一致率，不是准确率。
136. P149训练录像里到底录到了哪些游戏内容——覆盖清单与补录清单从 49 段训练 / 测试录像里按画面变化抽出 18,617 张原生截图并全部 OCR，对照游戏安装数据里竞技场可出现的法术、状态、生物能力、英雄技能、日志句式，统计训练集已有文字证据：法术名 63/64，但法术各等级说明只有 43/256、备用攻击 1/71，并按“怎么录”整理出补录清单；全部是机器预标注，人工审核为 0。
137. P150攻击预览种类数据集的采集计划（已备好工具，尚未运行）计划在 49 段准入录像的战斗画面上以每秒 2 帧扫描（108,994 个请求点），找出攻击 / 治疗预览并区分近战、远程、法术、治疗等种类；整帧 OCR 估计需 32,698 秒、超过 7,200 秒预算，因此设计了先找数字区域再拼图 OCR 的方案。只写好了工具和 13 项测试，全量扫描、OCR 和对比都没有执行。
138. P151战斗底栏状态时间线——工具已备、数据未跑计划以每秒 5 帧记录战斗底栏的按钮发光、法术书沙漏、等待变灰、能力槽冷却数字和悬停提示，生成时间线与审核页；工具和 11 项独立测试已完成，但用户叫停后实际数据采集、OCR 与审核都没有执行，没有任何识别结果。
139. P152三段录像的无损帧库试点（计划与工具，尚未运行）为了以后能删除或压缩大部分原始录像，计划先在三段录像上试做“只保留有用帧”的无损帧库：按画面变化选帧、无损 WebP 编码并逐像素核对、清单记录来源时间，并估算全量建库的空间与耗时；工具和 7 项测试已完成，但试点和估算都没有运行。
140. P153底栏单位能力槽的身份——轮廓模板加整排解码不用模型，用灰度梯度轮廓模板匹配加“备用攻击在前、能力在后”的整排约束，从底栏认出当前单位的能力槽身份；与行动条交叉核对，底栏亮着时 47/47 与正在行动的单位一致，并发现底栏显示的是“行动顺序里第一个我方单位”（197 帧中 191 帧符合）。没有标签，不是准确率。
141. P154用训练截图补充战场 HUD 英雄头像样例战场上方 HUD 的英雄头像有 3 处真漏读。从训练截图包按“整段录像留一”评估并补进 3 张已目视核对的样例后，训练侧 119→121 对、0 错；测试 87/0/3 不变，没有新增误认。另有 2 个候选因与旧样例同局（会造成评估泄漏）而不采用。
142. P155训练池里 7 张没定位到的生物面板——放宽一个锚点后找回 5 张7 张生物面板因“数量”或“生命”分数读不全而无法定位；新规则允许二者恰好有一个就定位，训练池找回 5 张、面板字段 1,857→1,902 对且无新增错误；测试池 626 帧上新规则一次都没触发。
143. P156用生产版的日志一致规则重新计算一份日志评估前一份 400 页战斗日志评估报告时钟只有约 75% 与预标注一致，但它用的是严格规则，没打开生产路由实际使用的宽松一致规则；用已保存的三次读取原文离线重算后，test 上时钟 97.2%、声明种类 98.2% 与预标注一致，差距主要是拒识。这些仍是与机器预标注的一致率，不是准确率。
144. P157用战斗日志和悬停说明给战斗规则找实机证据在 51 段录像已有的整帧 OCR 里按关键字搜日志行，检验模拟器对两个生物能力的三条推断：一条有 3 处支持（狡诈卧底命中后对方不反击），另两条（剧毒长矛首击是否加成、第二次叠加）找不到可用证据。
145. P158只有一个法术的书页，以及右页整体偏高的书用羊皮纸像素占比区分魔法书和生物面板后，“一个法术名就算书页”不再误报（训练 167 本书找到 165、其它画面 0 帧）；再按页估计垂直偏移，接收右页整体偏高的书。训练法术书场景 153→162/167，测试 79→81/82。
146. P159回合最后一个单位的攻击预览，以及用图标和字宽核验预览读数回合最后一个单位行动时，攻击预览因行动条“当前回合卡少于 2 张”被整帧拒绝，放宽条件后多读出预览；同时为每个读数加一道“图标在不在、字宽对不对”的核验，训练集保留 70 个全对，测试集（只跑一次）从 56 个输出 6 个错变为 51 个输出 0 个错，代价是 7 个真实预览变成未知。
147. P160先攻相同时谁先行动？——行动条上的初步观察在训练截图包的行动条上找“双方同兵种紧挨着”的 83 处卡片对目视检查：同一回合里两对方向相反、同一对连续三个回合同一方在前，说明同兵种相邻不等于先攻平局，也不支持“奇偶回合交替先手”是唯一规则，但还不能推翻它。
148. P161把让 App 闪退的那一局录像加入训练集战斗记录 App 某个候选版本在 10 月 10 日 01:39 开始的一局里原生崩溃；这段 44.4 分钟录像被登记为训练来源，扫描 13,322 个采样、切出 1 局、选 20 帧并经助手目视复核 20/20 接受，打成训练截图包。
149. P162把用户用候选版本 App 实打的两局加入训练集（B181）10 月 10 日用户用战斗记录 App 第 13 个候选版本打了两局：一局有录像，扫描 6896 个采样、选 20 帧、目视复核 19 张接受；另一局没有录像，只从 App 截下的 50 张图中均匀挑 20 张。两份训练包检查 118/118 通过，并顺带修了一个让录像停不下来的 App 问题。
150. P163行动条卡片标注集与读取器逐字段评估为两段录像 200 个时刻、2348 张行动条卡片做了逐卡标注（模型目视核对，非人工审核），逐字段对照读取器：兵种、颜色、回合组在两段录像上全部正确；数量在开发录像 970 对 / 10 未读，在另一段录像 1010 对 / 5 错 / 68 未读——错的 5 个都是“9”被读成“79”，另有一例被英雄窗口挡住却读出了值。
151. P164战斗中生物面板的模型目视标注（读取器对照尚未写入报告）从两段训练录像的 91 段生物面板时间段里选出 115 帧原生截图，由模型逐字段目视标注（16:57 段 348 项、01:39 段 1,140 项，另有 277 个状态图标）；第一次取帧因视频跳转错误取错了 59 帧，已重取。报告里读取器的逐字段对照还没有填写。
152. P165战斗中法术书的目视标注与读取器逐字段评估在两段训练录像的法术书画面上，目视标注 140 帧的每个格子，再与生产读取器逐字段比较；已评分的 63 帧中，书完全打开时法术名/等级/消耗没有读错的值，但漏检 2+23 格，翻页动画帧整页不读。数字是读取器与模型目视标注的一致性，不是准确率。
153. P166英雄窗口与“全部确定”页的逐字段标注和读取器评分（补记）为三段训练录像的英雄窗口和开局确认页选出 23 帧、目视标注 1,698 个字段，并对生产读取器逐字段打分；已保存的评分覆盖其中 16 帧：静止画面上开发录像 335 项、检验录像 350 项全部正确，悬停说明遮挡时读取器按设计整页拒读。原报告缺失，本文由代码和保存数据补记。
154. P167一局对电脑对局的“有价值画面”时间线逐个 0.5 秒帧目视一段 765 秒的对电脑录像，标出 118 段有价值画面（法术书、日志、生物面板、攻击预览等），用作 App 回放的对照真值；顺带发现生产预览线索在战斗中有 13 帧落在景物上，绿色治疗预览完全看不见，场景门把 4 帧误标成生物面板。全部是模型目视核对，不是人工审核。
155. P168攻击预览数字的标注集——选帧、盲标与读取器运行（评分尚未填写）为两段训练录像的攻击预览建立逐牌标注集：191 帧（167 帧有牌、189 块牌、24 个负样本），先盲标再看读取器；生产读取器已在全部 191 帧上跑完，但报告的评分部分在记录时仍未填写，因此本文没有正确率数字。
156. P169底栏能力槽与冷却数字——标注集、读取器逐字段评估和一个冷却数字原型在两段训练录像 263 帧、398 个能力槽上目视标注身份、外观和冷却数字，评估生产的能力槽读取器：身份只错 1 处（16:57）、未读 1 处（01:39）；新做的冷却数字原型 0 读错 0 误报，但独立录像 11 个数字只读出 8 个；还发现“底栏亮着”不能用来判断“轮到我方”。

截图与录像里的文字、数字、生物、界面读取，以及挑帧和实时采集。

1. P170实际 App 四张截图的保存回执审计——数据是在识别端丢的，还是在关联端丢的用户反馈 App 读完四张截图后很多内容显示为空。只读已保存的生产回执（不重跑任何识别）发现：准备页已读出 6 个主技能、9 个子技能、8 件装备、7 个军队候选，开局图 13 张行动卡全部有身份/颜色/数量（含 6 张蓝方卡），空白发生在下游的关联与显示环节；同时明确了“空槽”在旧数据格式中无法表达。
2. P171用 App 读取选中录像之前的元数据预检（补记）原实验没有书面报告，本文根据保存的脚本与结果补记：在不解码任何图像、不运行任何模型的前提下，核对 6 张参考帧 215 个目标字段和 4 帧 App 序列的元数据一致性，全部通过；真正的 App 读取运行没有在这一步执行。
3. P172单帧战场部队的开发参考，以及这些信息能否走到 App在 4 张已曝光截图上手工标注 42 个可见部队、26 张行动卡和 2 张生物面板，保留 4 处不可读数量等未知；同时只读核对源码，发现行动卡和面板已有通往 App 的公开路径，而战场身体、脚下数量牌和身体—卡片关联只存在于私有候选中，默认流程和 App 都不消费。
4. P173行动条卡片身份匹配的两线程并行候选与分段计时一张战场截图的读取有约 99% 时间花在给行动条 13 张卡逐一做模板匹配排名。私有候选用 2 个线程并行这一步：第一次测量因一个数据库辅助文件的修改时间变化在首请求前停止；按修正协议再测，同一常驻进程的读取从 20.15 秒降到 12.38 秒（1.63 倍），输出逐字节一致。只有一张图的开发诊断。
5. P174行动条兵种匹配——把模板一次性存成连续 RGB 数组的小型微基准行动条卡片匹配几乎占满战场读取时间，而每次匹配都把同一个“非连续”的 RGB 模板交给 OpenCV；改为构造时一次存成连续数组后，3 个合成检查证明结果逐位不变，唯一一次小型微基准中热匹配耗时减少约 3.37%，真实游戏和端到端收益未知。
6. P175为性能测量的“冻结输入守卫”加一个精确例外的适配器一次战场行动卡排名加速的性能测量，因为参考数据库的 SQLite 共享内存文件 mtime 变化被冻结守卫拦下；本实验只做静态接通：独立适配器把原测量流程与“只放过这一个文件”的新守卫连起来，静态核验通过、10 项反例测试通过，真实测量请求仍是 0/3，尚未运行。
7. P176一次被数据库共享内存文件拦下的测速——只准备新协议，未测量一次严格冻结的测速实验在发出第一个请求之前就停止了，原因是游戏知识数据库旁的 SQLite 共享内存文件修改时间变了；本实验只准备一个“仅这一个文件可以变”的新协议，静态检查通过、28 个反例测试通过，真实请求仍为 0/3，没有任何性能结论。
8. P177因果回放的管道冒烟测试——只验证“看不到未来”，不读任何内容为“按时间顺序回放截图、不许偷看未来”的因果回放搭好数据边界：从两个开发会话选出 18 个窗口、37 张截图，传输与时间前缀检查全部通过（0 违规）；但没有接任何语义读取器，语义冒烟测试未运行，不能说明状态跟踪可靠。
9. P178用关键帧信号剪掉对局录像里的等待用已有的“画面稳定”模型找出 45 分钟对局录像里的重复等待并跳切删除，同时保护行动切换前后的片段：首版 45:09 → 28:49.8（删 36.15%），按反馈缩短上下文后为 22:14.9（删约 50.72%），未达到希望的 10–20 分钟；激进到 19:58 的方案因跨行动误删未交付。
10. P181敌方英雄头像认不出——把长方形裁图补成正方形再匹配一组开发截图里双方英雄身份都被判为未知：头像裁图是 194×226 的长方形，匹配前被拉伸成正方形。对称补边成正方形后，6 个裁图的最高分从约 0.69–0.71 升到 0.82–0.96，全部通过原有 0.75 / 0.08 门槛；这是开发数据上的诊断改善，不是独立准确率。
11. P182复用已有的英雄头像模型——10 张 HUD 头像的开发探针已有的学习型英雄头像模型把 10 张 HUD 头像全部排对第一，但在现行“两个门槛同时满足”的接受规则下 10 张全部被拒；查明历史上这两个门槛是分开验证的，只用原有效度门槛离线重放后 10/10 接受且正确。样本很小、没有负例，不能证明广泛可用。
12. P184保存会话中“左上英雄名字”的来源链核查一张界面截图显示左上英雄名字，而读完下一张截图后名字变成了未知；只读核查保存的会话发现：截图时显示的是 297 秒准备页的候选，420 秒战场头像匹配分数 0.709 / 0.690 低于 0.75 门槛所以身份未知，但 HUD 数字已正确归到双方；不是界面没接线，也没有证据表明选错英雄。
13. P185英雄面板截图读取——四张图的私有读取器与公开输出格式草案用现有组件读四张英雄面板截图，冻结后每张只读一次：可评分字面读数 83/103 正确、18 个未知、2 个错误，完整状态 0/4 通过，装备占用和阶段没有实现。之后只修了经验值“X”前缀的编码，并写出一份尚未批准的公开输出格式草案。
14. P186英雄覆盖面板的最小观察格式提案这是一份未获批准的格式提案，不是像素读取成果：0 张原图读取、0 次 OCR。它说明英雄覆盖面板为什么不能塞进现有的六类截图格式，列出最小字段语义，并用现有公开类型做了一个合成示例，10 项往返回归通过。
15. P187日志“三读两同”候选规则的安全审计一个日志读取候选规则：三次 OCR 中两次完整一致、第三次无法解析时就接受。24 个合成案例显示旧规则会接受 18 个不该接受的情况中的 12 个；更窄的“只差时间戳右括号”守卫 0 个误接受，已保存的 13 个提升行全部符合守卫条件。
16. P188战斗日志难例——三次读取中两次一致就接受6 张已有日志截图（40 行可见日志、3 张负例页）上，基线因时间戳右括号偶尔丢失拒读了 16 行；只用已保存的三次 OCR 结果、规定“恰好两次解析一致、一次解析失败”即接受，正确输出行 24→36，错误 0，新增 OCR 调用 0。这是已曝光来源上的开发评估。
17. P189日志读取结果的完整性检查 v3——不让隐形换行符和空格把错字藏起来在旧版检查器上叠加两道保护：拒绝原始读数里藏有各种换行/分隔控制字符的日志行，以及只靠删空格才“对上”的升级读数；64 个合成用例中旧版误收的 42 个无效用例全部被拒，6 份已保存结果全部仍然有效。这是软件完整性检查，不是 OCR 准确率。
18. P190不看图片，只审计“候选版本是否诚实地改写了日志读取结果”为日志读取的一个私有候选版本写了一个只比较两份保存 JSON 的校验器；第一版把 6 页中的 2 页判为无效，查明是校验器没考虑生产代码已有的 Unicode 规范化（8 行），另立兼容版后 6/6 页通过、13 次提升和 29 行未变行全部验证；全程 0 次图像读取和 OCR。
19. P191战斗日志读取失败的原因诊断（只看已保存的读数）不做任何新识别，只分析 40 行已保存日志的三次 OCR 尝试：所有“不完整”读数都是时间戳前缀缺右括号，没有一行出现互相矛盾的完整读法；3 行被拒都只有一次完整读法，放大 1.5 倍的读法不完整最多（11/40）。
20. P192已保存日志读取结果的只读检查命令做了一个只读命令，检查已保存的日志读取 JSON 在结构和证据上是否完整，并给出明确的退出码。对 6 对已有结果做一次检查：全部通过（退出码 0），保留 42 行原始框和 126 次读取尝试；这只是完整性检查，不是 OCR 准确率。
21. P193战斗日志评分器的完整性复核旧的日志读取评分器会给“拒绝输出”的行记字段分、把未知参考当成必答、只按纵向位置匹配。修正版在 33 个合成案例上全部符合新要求（旧评分器 12 个字段结果、19 个整页状态不一致，1 例直接崩溃）；用它重评已保存的输出，基线 24/39、候选 36/39 整行正确不变，只有一页状态从“未知”改为“错误”。
22. P194日志三遍读取的资格检查——别把有含义的空格删掉旧资格检查在比较三遍 OCR 读数前删除全部空白，会把“A B→AB”“90→9 0”这类差异当作一致。新检查改用现有日志语法逐字段比较：52 个合成案例中挡住 18 个旧检查仍接受的不合格输入、16 个合格对照全部保留；已保存的 13 条私有新增输出全部仍合格。这是软件收紧，不是新识别精度。
23. P195战斗日志“一行就是一行”的约束恢复——软件检查与历史测试回放日志读取在文字规范化之前就删掉了首尾的换行类字符，可能把跨行文字当成一行解析。修正后在规范化前拒收十种分行符；30 个合成反例全部拒收，223 项新回归和 Perception 全套 6,147 项通过；冻结的历史测试在当时的解析器上 125/125 通过。这些都是软件兼容结果，不是 OCR 准确率。
24. P196实验重编号的只读迁移计划为四个早期视觉实验目录改编号（B04→B11、B026→B12、B06→B15、B07→B16）制定一份只读迁移计划和检查工具：保留所有历史输出、冻结配置和已发布网址，只打印计划、不移动任何文件。这是计划，报告中没有执行迁移。
25. P197读日志时不再加载用不到的数字模型，以及一次无效的放大尝试单独读战斗日志时，原代码会先加载一个日志根本用不到的数字识别模型；改为第一次真正需要时才加载后，四张图的输出除耗时外完全相同。另试了把日志区域放大到 2 倍、3 倍再读，完整 11 行页反而从 6/11 降到 3/11 和 2/11，没有采用。
26. P200生物面板幸运/先攻的裁图设计与合成反例（仅设计，未实现）幸运和先攻的回退读取框把上方图标也框了进去，两遍 OCR 分数只有约 0.65–0.87；本轮只写出“只切掉图标行”的最小设计并生成 16 个合成反例图，没有实现算法、没有运行 OCR，也没有新的准确率或速度结果。
27. P202准备页读取的热路径——延迟加载整图 OCR 与下一批批量模板计算方案准备页读取在 6 次冻结请求下做性能对照：唯一改动是“整图 OCR 模型首次用到才加载”，冷请求 13.05→11.69 秒（−10.41%），响应严格相等；热请求仍约 4.5–4.7 秒，主要耗时在约 2 万次模板匹配上。下一批“同类固定槽位批量模板计算”只写了预执行协议，尚未运行。
28. P205战场数量牌读取的原方法基线——八个已曝光来源用冻结的原数量牌读取方法，在 8 张已曝光的原生截图上一次性测量：98 个可读数量中 95 个读对（96.94%），0 个未知、2 个没找到牌子、1 个读错（150 读成 4150）；8 张图中只有 5 张所有可读数量全对。这是已曝光开发数据上的测量，不是盲测。
29. P206战场脚下数量牌的 CPU 基线（A25）在 4 张开发图上冻结协议后只跑一次：选定的几何配方提议 40 个数量牌、0 漏提议，38 个可读数量中 35 个读对、2 个未知、1 个错误（38 两遍都读成 384）；所有可读数量全对的整图只有 1/4。
30. P207数量牌重复提议的精确去重——只在已保存的几何上验证同一块数量牌有时会被规则提议两次。一个只合并“颜色、血条竖直位置、全部字形框都完全相同”的去重规则，在 8 张已保存几何、102 个提议上只删除了已知的那一个重复（102→101），可读覆盖 96/98、不可读覆盖 5/7 都不变；它不能找回原本漏掉的牌。
31. P208数量牌读错时，到底是哪一步丢掉的？对上一轮四个数量牌失败逐步追踪原有的几何代码（不跑 OCR）：50 在绿色边框分组时被丢、26 被“字形高度 ≥7”门槛丢掉、215 因两个原始候选从不互相去重而重复，150 被读成 4150 的原因仍未证明；并冻结了一个只针对重复问题、尚未执行的去重候选。
32. P209从玩家头像判断“哪一边是我方”——一次冻结参考后的单次评估用玩家个人头像（兔子）在战斗画面顶部的位置来判断我方在左还是右、是红还是蓝：先冻结 8 张原生截图的人工参考，再只跑一次，6 张战场全部给出正确候选，2 张准备页按设计拒绝；全部是已曝光的开发数据，没有覆盖头像缺失、遮挡等情况。
33. P210战场数量牌的公开单图入口——一次性接线验收为“读一张截图上所有可见数量牌”新增公开命令行入口，并在代码冻结后对两张原图各只调用一次：两次都成功，各找到 7 块牌、14 次读数，结果与旧导出逐项完全相同（包括一个已知的错误读数 384）。这是接线验收，不是新的准确率实验。

截图与录像里的文字、数字、生物、界面读取，以及挑帧和实时采集。

1. P211飘字跨越了行动头像切换——不能用“当前行动者”认领残留伤害数字在一段训练录像的 15 张原生图上读取“当前行动单位”：9 张给出一致候选、6 张未知；一个 -27 伤害飘字在行动头像从巫妖变成盗墓贼前后都可见，说明不能按截图里的当前行动者认领飘字。另用固定区域补读脚下数量牌得到 8→3→3 和 12/12/12，但仍不能确认是同一支部队。
2. P212相邻两行伤害飘字挤在一起时，用中间的空白行把它们分开伤害飘字的读取框上下边距常包住另一行文字，被保护规则判为“共享文字”而拒读。新规则只在框内确有另一条墨迹带、且中间有完整空白行时缩小上下边距：旧 34 张图结果不变，新 11 张图上预先登记的 14 个字面从接受 3 个变为 5 个。
3. P213伤害飘字只闪现一瞬——用廉价探针在视频里挑出值得读的帧在三个固定的 10 帧/秒开发窗口里，用不跑 OCR 的图标探针扫描 150 帧，31 帧有信号，每窗最多挑 2 帧；6 张挑中的图在修复一个“背景边距相交”误拒后，三个窗口各至少读到一条伤害字面。探针每帧约 30 毫秒，但尚未接入 App。
4. P214从部队身体出发，在脚下局部窗口里找回数量文字原来的“找红/蓝色块”方法在四张图上都没找到某个部队的数量牌；改为在身体脚下的局部窗口里先检测文字框再 OCR，四张图中三张读出 8/3/3、邻牌 12/12/12，三个真实反例都没被误接纳。首轮因坐标取整约定不一致漏判两处，修正后保留为“未绑定的数量文字候选”，不认证属于哪支部队。
5. P215目标兵堆在几帧之间是不是同一个？——身体候选对应与脚牌补读失败在一段训练录像的 4 张原图上，每个参考格 70 像素内都只有一个身体候选（最近的另一身体至少 138.28 像素外），形成可检查的单帧空间候选；但已有的“身体引导脚牌补读”4 次请求全部没找到牌，原因是蓝牌与地面连成一块被尺寸规则拒绝。没有确认同一兵堆或死伤。
6. P216把读到的数量文字连到同一帧里的数量牌和兵堆身体上一轮读到了战场上的数量数字，但不知道它属于哪个兵堆。本轮在 5 张保存截图上把“数量文字 → 数量牌 → 兵堆身体”连成几何候选链：旧的规则路径形成 9 条唯一链，加上已有的学习型数量牌检测器后为 10 条，补上了一块旧路径漏掉的牌；这只是检测集合内的唯一，不认证真实单位或跨帧身份。
7. P218日志“第 N 回合”标题漏读——是新缺陷还是旧结果过期？一份保存结果里有两张日志截图的回合标题是“未知”。重读三张原图发现当前读取器已能读出（既有的居中匹配修复），问题是旧结果没包含这次修复；更新后两次施法的回合从“第 1 回合或更晚”确定为“第 1 回合”，72 行中 69 条正文完全不变。没有新增算法。
8. P219生物数量 340/385 不再被裁成 340/38生物面板的数量 340/385 被读成 340/38：整图 OCR 其实读对了，但固定的局部裁框右边界在 x=764，而文字到 x=777 才结束。只为数量字段在严格条件下向右保全完整文字后，4 张训练图 44 个面板字段从 43 对 1 错变为 44 对，遮挡对照仍保持未知。
9. P220法术书小等级数字漏读的修复法术书格子右下角清楚可见的等级 4 被低分拒为未知；只给等级局部图加 4 像素边缘复制，同一裁图分数从 0.568 升到 0.99998、读回 4；3 张完整重读的 99 个字段只有这一个变化，混合等级控制 30 字段不变。这是开发曝光样例上的限定修复，不是独立准确率。
10. P221可见的敌方英雄 HUD 为什么整侧被丢掉一张截图左侧英雄 HUD 清楚可见、OCR 也全部读对，却因旗帜颜色取样框包含了蓝灰阴影，红/蓝票为 668/189、红票未达 80% 门槛而整侧被丢弃；把取样框收窄到直线彩色饰边后为红 888/蓝 0，左侧四个字段恢复，SE 由此能把生物攻击 −6 分解为英雄 −1 加其他 −5。
11. P222读取战斗结算页——双方每堆的开战数量和总损失战斗结束弹出的结算页列出双方每个兵堆的数量和损失，但 App 一直把它当菜单跳过。在 3 个训练结算页上做读取器：稳定帧 168 次卡片读数中数量 168/168、损失 168/168 无错读；兵种因红色骷髅挡脸，在严格门槛下只读出 23 张、145 张未读。
12. P223采集审计——战前准备、布阵和战斗中有价值的画面有没有被及时抓到用逐 0.5 秒标注的时间线审计 App 的画面采集：改动前战斗生物面板只读到 8/24、法术书 7/22，盲区来自固定间隔和读取预算；把信息页改走旁路、每次打开读一次、2 Hz 场景线索和“等静止再读”后，16:57 训练局最终所有页面类型全部读到（生物面板 24/24、法术书 22/22）。
13. P224参考目录缺的子技能图标，用游戏安装资源补上一张确认页的子技能槽读成未知，导致规则模拟器复现英雄卡时知识差 2（15 对 17）；原因是参考目录停在 8 月更新前，缺十余个竞技场子技能的模板。用安装资源图补齐后，该槽读出“属性加成”，英雄卡完全吻合；27 张确认页中其余 26 页所有字段不变。
14. P225数量牌上的血条——读出顶部那只生物还剩多少生命数量牌上方的颜色条表示顶部生物的生命比例。离线测量在身份把关后 23 个比较中 22 个误差在 ±0.10 内；但自动链拿不到任何低于 40% 的样本，因为数量牌检测本身依赖绿/黄色血条做锚点；唯一的大错值来自光晕叠加极低血量。不建议接入生产。
15. P226攻击预览局部重读——整帧 OCR 漏掉时，按图标位置补读实时回放中 54 次攻击预览读取有 9 次没读出；改为先找骷髅和拳头图标、再逐行局部读数字后，3 次真预览（含一个四块牌的范围法术里的 2 块）和 1 次漏短横的读数被补回，4 次线索误报仍正确拒绝；全场 2 fps 扫描没有出现假数字对。读数核对是模型目视，不是准确率。
16. P227同一局里多次读取确认页，结果是否自洽？没有人工真值时的一个廉价错误信号：同一局、同一页面类型、同一英雄的同一字段，多次读取应该相同。在 14 个有重复读取的会话里（每个约 45–50 个字段被读两次以上），修正口径后冲突为 0；这只说明读数稳定，不是准确率。
17. P228每次行动后读一次行动条——用卡片左移检测“行动结束”行动条的每张卡上写着该部队的数量，每次行动结束整条左移一格。检测这个左移并立即读一次行动条，就能按行动算减员。在一段训练录像的离线回放中，66 次行动结束全部读到，“行动结束→读完”p95 从 9.25 秒降到 5.53 秒；随后又接入了实时攻击预览和英雄施法补读。全部是离线回放，实时模式尚未验证。
18. P230实时 App 三层金标准——一局 3 分钟里采到了什么、读对了什么、推断用对了什么给一局实时对局的 180 秒逐帧标注三层参考答案：47 个应采集区间 App 只采到 21 个；读出的值除战场数量牌外没有错（判官 26 读成 126 两次）；状态估计找到 2/2 真实减员，但只有按画面时间排序时魔法净变化才对（14 行→1 行，来回跳 25→0）。
19. P231实时节奏回放——在离线录像上复现实时模式的排队与丢页把录像当作“游戏窗口”按真实时钟喂给 App 的实时路径后，同一个 3 分钟窗口的采集从实玩的 21/47 提升到最终配置的 42/47、读值 0 错、减员推断全对；其中两项改动（战场间隔 20 秒、预览 4 Hz）和预览挑帧是负结果已撤回，后两次运行被自身负载污染。机器上没有游戏，结果偏乐观。
20. P232战斗结算页读取——生产路由在真实训练帧上的检查把三局真实结算页交给生产路由和真实 OCR 读：12 张面板帧、126 张稳定帧上的卡，数量和损失全部与参考一致，兵种在门槛下 0 错但只认出 15/126；逐帧检查 232 帧没有发现“损失行还没画出就记 0”的风险。参考是模型目视核对，只有 3 局。

把读到的观察累积成对局状态、减员和对手构筑的推断（SE）。

1. E001敌方构筑候选怎样展示才不误导——私有呈现原型与有限联合域证明推断对手装备/技能时，接口只返回两条启发式示例，不构成统计总体；本原型规定只完整展示一条零残差的条件方案、所有逐项“概率”一律为空，并用一个 4 个假设的合成域演示：逐项边际最高的装备和技能拼起来，可能根本不是任何合法完整方案。这是消费方审阅原型，没有准确率或校准声明。
2. E002超过 64 次读取的长局历史——私有累积函数的首批 65 条实验状态估计原有的观察累积接口最多接受 64 次读取，第 65 次整体拒绝。新的私有纯函数在 2/64/65 条读取、六个截止时刻上 21/21 通过：≤64 条时与旧接口结果完全一致，65 条时保留未知、冲突和撤销记录；3 个容量反例都整体拒绝。公共接口和 App 尚未接入。

把读到的观察累积成对局状态、减员和对手构筑的推断（SE）。

1. E003两次生物面板攻击读数（19→21）能推出什么——以及“开战时”标注的修正在一局打电脑录像里，同名生物面板先后读到攻击 19 和 21，中间日志显示它获得了“升华”。逐步补入真实的准备页、日志和战场图后，状态估计学会了对手是电脑、我方在左侧、两张面板属于我方，但仍无法认证两张面板是同一兵堆、也无法把 +2 归因给升华；本轮实际修正了一处把“首次读到”误称为“开战时”的标注。
2. E004固定区域里的身体空间候选——为什么“同一格有一个身体”还不等于“同一支部队”在 4 张保存截图上，两个人工参考格各自在 70 像素内只有一个身体候选（最近的竞争身体至少 138.28 像素外），状态估计据此只输出“条件空间对应”，不认证同一部队、数量差或伤亡；顺带运行的已有脚牌补读 4 次请求 0 次找到牌。
3. E005同一帧里，把数量文字、脚牌和生物身体连起来状态估计侧只消费已保存的几何观察，把“数量文字 → 脚下数量牌 → 生物身体”连成当帧候选链：用旧的学习型数量牌检测器补上一块漏检的牌后，10 个已接受的数量文字中形成唯一检测链的从 9 增到 10；但唯一只限当前检测集合，不认证真实单位或跨帧身份。
4. E006不读战斗日志，只看飘字能把伤害关联到什么程度在两段训练录像的三个窗口（150 个探针帧）上，按固定几何规则把相邻帧的同类飘字图标连成“可能连续”的视觉轨迹：53 个图标观察、41 条候选边、12 个视觉分量；但三个窗口都缺少可靠的动作边界和单位身份，没有得出任何伤害事件，也没有调用规则模拟器。
5. E007让状态估计自动分析日志里的施法费用敌方施法时日志会写“失去多少魔力 + 施放某法术”，以前只能在一个独立按钮里手动算费用条件；现在状态估计自动消费已配对的支付和同一次施法的等级证据，58 帧真实保存结果中只有一处（连锁闪电 22 魔力、同次命中三个目标）把相容条件从 8 种缩到 6 种，其余结果逐项不变。
6. E008用同一帧的英雄属性栏解释生物面板上的攻防状态估计原来只从生物面板攻防里扣掉基础值和英雄攻防，没有计入已读的战斗魔法技能；补上之后，一张真实截图上深渊使者的 40/37 被解释为“基础 30 + 英雄 3/2 + 战斗魔法 7/5”，净差为 0。58 帧请求中新增 5 条条件解释，其中 3 条因状态效果未计入而不做来源匹配，另 1 条攻击 +6 仍未解释。
7. E009修正状态估计里两处“从扣蓝数字硬推装备/技能”的错误自动状态估计会把敌方单次施法的魔力差价直接当成“必有魔法拖鞋或魔力弹性”，把两次施法的价差直接当成“奇术专家”；用合法构筑实际施法复现了两个反例（德鲁伊减耗、高级奇术），改为保留扣蓝事实和可能条件、不再强制来源。271 项软件检查通过，非准确率。
8. E010让英雄属性变化进入生物属性历史SE 解释生物面板属性变化时，原来没有使用已读出的战斗中英雄 HUD 历史；先写 13 个场景测试复现（旧实现 12 失败），修复后在一局对电脑录像的 8 帧保存输入上，生物攻击 19→21 被分解为“英雄 +2 + 其他净变化 0”，其他输出完全不变。这是条件解释，不是准确率。
9. E011让战斗日志里的攻击行复用已读到的攻防数值作为条件参考日志自动读到“敌方织光者攻击我方巫妖造成 314 伤害”，生物面板也读到了织光者攻击 20，但旧代码把两者分开放；现在 SE 在攻击候选旁附上“攻击 20”的有来源条件参考。三份真实保存输入前后对照：只新增这一条说明（01:39 那局为 0 条），其余结果完全相同。
10. E012已保存战斗日志与历史属性引用的只读审计原本怀疑“状态变化让不相关的历史属性被错误作废”，审计两局已保存结果后没有找到这样的错误；真正的断点是：一局 6 条已读的攻击/反击动作因为中间夹着别的受伤行（太阳圣盾受伤、凤凰自伤），按“只配对相邻行”的合同无法关联到伤害，候选为 0。
11. E013状态时间没读出来时，第二次施法的记录被当成重复删掉了检查状态估计能否区分“重读的旧日志”和“新发生的状态变化”：原假说没有复现，但发现另一个真问题——状态行的时间都未读出时，两次施法的同字面记录被按 (无时间, 同文字) 去重，导致旧攻击力参考 9/12 被继续沿用；最小修复后保留每条无时间观察，4 组再次施法和 4 组再次等待组合都正确停止沿用。
12. E014真实施法两次，检查对手构筑推断是否保留正确的耗魔解释在规则模拟器里让英雄合法地连续施放两种法术，用实际扣蓝去考状态估计的耗魔解释：30 种构筑、10 个跨回合分支、12 个逐来源去除、4 个观察负例和 1 个抵消对照共 57 项全部通过；本批未发现生产错误，但随后的探针找到了一个自动推断的反例。
13. E015用已读的我方技能栏收窄“对方施法费用”的解释对方施法实付的魔法和资料上的基础费用不同，可能来自对方的技能装备，也可能来自我方技能对该学派施加的加耗。读到我方完整的 24 个技能位后，用公开规则把我方加耗算清楚：四个法术的相容条件数从 4/36/6/32 收窄到 4/16/3/12，其余结果完全不变。
14. E016用我方已读的技能页约束我方法术书费用解释状态估计原本用“通用第二次施法倍率 2”解释我方法术书上的 11 个费用读数，却没有用更早一页已读到的“专家奇术”（规则模拟器给出倍率 1.5）；接入后该解释变为“已读配置下无一致解释”，其余完整结果不变；334 项软件测试通过。
15. E017我方法术减耗来源按书页时间顺序使用状态估计解释我方法术书报价时，原来对所有书页用同一个累计的减耗汇总，可能借用较晚页面的装备；改为每页只用此前已读的同一英雄页面。真实 58 帧样例里 11 个报价全来自同一页、来源都更早，结果数值不变，只多一条来源说明；软件回归 348 项通过。
16. E018把已经算好的战斗魔法加成用进属性变化解释状态估计解释生物攻击力前后变化时，只扣除英雄攻击的变化，却没有用同一次请求里已经算好的“战斗魔法”加成，导致 +1 被列为未解释；修复后两段训练录像的两个例子分别分解为“战斗魔法 +1、其它 0”和“战斗魔法 +1、其它 +1”，其他结果完全不变。419 项软件检查通过，非准确率。
17. E019生物面板上读到的杀伤范围进入状态估计的属性历史面板上的杀伤范围（如 2–3）早已被识别，但状态估计的属性历史只收标量攻防，没有消费它；补上后两段真实保存输入的 28 个杀伤候选全部以原范围和准确来源帧出现一次，其余结果不变。真实数据里没有出现可比较的范围变化。
18. E020把已读到的生物面板数量写进状态估计的条件历史生物面板上已经读出的数量（如 52/52、340/385）此前没有进入状态估计的属性历史；修复后在两份真实保存请求上按帧列出数量字面与来源，已知阵营的相邻面板给出条件性净差（52→52，净差 0），未知阵营逐条保留不合并；其他结果完全不变。237 项软件检查通过，真实输入里没有出现数量变化。
19. E021属性参考计算超时后，如何正确标记“未完成”并让后台续算属性来源和等待参考在时间预算耗尽时只写一句说明，却没有设置 App 续算依赖的“未完成”标记；修复后两份真实保存请求（58 帧 4 行、49 帧 8 行）都正确标记并在恢复后得到与正常结果完全相同的输出，另给常驻服务加了每请求最多 4 次空闲尝试的上限。
20. E022面板属性参考漏传了已读到的主技能——一处规则查询输入修复状态估计用规则模拟器计算“战斗魔法”带给生物的攻防加成时，只传了战斗魔法本身，漏掉了同样已读到的其他主技能，导致需要跨技能条件的联动没有触发；修复后 49 帧真实保存结果中只有 10 条说明文字变化（8 张生物面板从“无相符来源”变为“无新增来源即相符”），另一段 58 帧结果完全不变。
21. E023用公开规则筛选“哪种来源能解释面板上的攻防”一张生物面板的防御比准备页推算少 2；用规则模拟器的公开接口对 8 种有限的来源组合算出有效攻防，只有“寻真之器”给出与面板一致的 19/17，其余 7 种不符。结论只在“准备页仍适用、无其他未计入来源”等前提下成立，且候选不穷尽。264 项软件检查通过，非准确率。
22. E024已读的“内在光辉”状态图标参与属性变化的条件解释一堆修道院长攻防 43/54→37/48，英雄只解释了各 −1；把已读到的状态图标“内在光辉”（公开基础参数攻防 +5）消失作为条件贡献后，剩余算术为 0。49 帧真实样例只改变 1 条说明，58 帧样例完全不变；新增 32 项场景测试，相关共 270 项软件检查通过。
23. E026没有英雄界面的战术画面上，用先前准备页的英雄属性解释生物面板SE 原来只用同帧英雄界面解释生物攻防，忽略了更早准备页读到的英雄属性；修复后真实 8 帧输入只新增一条条件说明：生物攻击 19 = 资料基础 6 + 准备页英雄 11 + 战斗魔法 2，净差 0；防御部分参考 19 对实读 17 仍差 −2，未归因。
24. E027把攻击预览的条件数值计算接进状态估计游戏的攻击预览显示了一次攻击的预计伤害范围；把已读到的攻击力、数量、技能和等待状态交给规则模拟器，在明确假设下算出四组参考伤害，最后一组 845–1267 与保存的预览数值相符；只看前 25 帧时不借未来的防御读数，01:39 局 49 帧没有产生虚假匹配。
25. E028用规则模拟器核对一次已保存的攻击预览数字一张攻击预览显示伤害 845–1267；用已保存的攻击 40、杀伤 40–60、数量 12、已读的近战特长，加上实际执行的一次“等待”（战技高级使攻击 40→52），在规则模拟器的公开伤害函数里四种组合中只有最后一种算出 845–1267。这是条件相容，不是唯一因果；目标防御 25 来自预览之后才读到的面板。
26. E029攻击预览读出来了，却没送到状态估计——一个过滤列表的修复一局训练录像的识别结果里有 3 张攻击预览被正确读出，但 App 组装状态估计请求时的类型过滤把它们全部丢掉了；修复后两段录像重新组装请求，第一段新增 3 条预览说明、第二段 0 条，其他结果完全不变。
27. E030法术等级没读出来时，用上一页的等级做费用对照魔法书第 9 帧读到“力量之歌”4 级、费用 4，第 10 帧费用变成 6 但等级没读出来；状态估计现在在历史说明里写出费用 4→6（+2），并给出“若仍是 4 级，规则模拟器公开定义的基础费用为 6，差额从 −2 变为 0”的条件参考，当前未知等级保持未知。
28. E031法术等级“此前读到”与“当前未知”并存的条件说明一张法术书页上力量之歌等级没读出来（未知），而上一帧同一英雄同一法术读到 4 级。状态估计新增一条带来源的条件说明“此前帧保存的等级候选为 4，若期间未变化”，当前值仍保持未知；在 58 帧真实保存输入上，只有第 10 帧前缀多出这条说明，其余结果完全不变。
29. E032把没能配对的攻击日志原文也展示出来战斗日志里的攻击行，只有紧接着出现对应伤害行时才会被正式配对；没配上的攻击以前完全不显示。现在状态估计把这些未配对动作及其后最多 4 行原文（包括读不清的行）作为非预测说明展示，01:39 局新增 6 条、16:57 局新增 5 条，其余全部结果逐字段不变。
30. E033未配对攻击也显示攻击方已读到的属性与阻断原因攻击日志没配上伤害行时，攻击方此前已读到的生物面板属性也被一起隐藏了；现在复用已有的身份、状态、英雄变化和生命周期门槛，为未配对动作补上属性核对说明——01:39 局凤凰显示最近面板攻击 54 但因状态未解释不能沿用，16:57 局星之子显示窗口内没有面板。没有新的真实数值正例。
31. E034用等待日志和战技等级解释生物面板的攻击增量一张生物面板显示圣骑兵攻击 28，已有参考只能解释到 22；把已读的“战技高级”和较早的“进行等待”日志交给规则模拟器执行一次合法等待，得到 28.6/24，与面板 28/24 相差 −0.6/0；这是条件解释，没有把 28.6 截成 28 来制造“精确匹配”。
32. E035用战斗结算画面核对整场减员时间线战斗结束时的结算画面列出双方每堆的开局数量和总损失，可以核对状态估计整场累计的减员：16:57 局 14 堆开局全对、净减员 8 堆一致、6 堆缺最后一下、0 堆对不上；01:39 局只有 3 堆一致，11 堆缺尾，其中 9 堆是战斗中途整堆消失却没被记录。结算数字是模型目视参考，不是人工审核。
33. E036把兵堆减员与战斗日志的死亡行做条件关联把状态估计记下的每一段减员（同一堆相邻两次读数），和战斗日志里该兵种的死亡行按数量链对齐：信息页读得更全的一次回放中，减员区间 24 段由一行日志直接解释、1 段需要多行、2 段由“被摧毁”行解释、9 段没有日志；时间检查 28 行一致、0 矛盾，故意错开开始时刻 5 秒就出现 6 行矛盾。只有一局，是条件关联不是认证。
34. E037用真实对局面板审计规则模拟器——哪些差异它解释不了对 6 份保存请求和 40 个 App 会话（可重建 29 个）只读审计：英雄卡对不上 4 局，其中 1 局是感知缺模板漏读，另 3 局与 RC13 的法强 27/28 一起交给规则侧，后查明英雄卡显示的是截断值；另列出虫巢计数和幸运统一低 2 等规则差异候选，全部只登记不判定。
35. E038同一法术多次书页报价的来源时序对照我方法术书上同一法术的显示价格会变化（例如审判 28→42→28→42→56），以前只保留最新一次；现在状态估计按每次报价自己的帧、等级和此前同英雄配置分别做条件核对，58 帧真实保存结果只新增 11 条非预测历史说明、其余逐项不变；书页报价不是实付，次数耗尽时公开查询也会照常报价。
36. E039120 个子技能逐项盘点——在模拟场景里，状态估计能列出几个来源？用项目规则模拟器为 120 个竞技场子技能各造一个敌方构筑场景，统计状态估计能否把它列为来源：开局层列出 30 个，战斗层列出 27 个，两层任一列出 34 个；63 个“看得见却没列出”，其中战斗层 56 个无反应里有 38 个只体现在状态图标上。还发现并修复了 3 个英雄特长译名不一致的真错误。
37. E040数量牌认错兵种造出的“假兵堆”——单独列为可疑兵堆四局录像里共有 29 个只靠战场数量牌认错兵种而出现的假兵堆；新规则（阵营已由行动条认满 + 自己无任何依据 + 每次读数都与同方真兵同数）把 29 个全部移到“可疑兵堆”，60 个真兵堆 0 个被错分，1,329 个逐帧前缀重放中真兵堆也 0 次被分出。
38. E041兵堆离开行动条时给出条件性的“已被消灭”读数有些兵堆在战斗中途被整堆消灭却没读到日志，减员时间线要到结算才补 0（晚约 20 分钟）；新规则在“完整读取”的行动条上连续 3 次看不到某堆时补一个条件性 0。01:39 局 10 堆全部是真消灭、0 误判，结算对照从 MATCH 2 变为 MATCH 12；扰动重放中活堆被判死 0 次。计数来自模型目视标注，不是准确率。
39. E042结算画面的兵种——用第一帧的干净头像，并让状态估计配对两次读取战斗结算画面稳定后，红骷髅挡住了阵亡兵堆的头像，4 张卡对不上自己的兵堆；改为在“还没画损失行”的第一帧上用较低门槛 0.63/0.09 认兵种，并由状态估计把同一次结算的两次读取配对，三局全部 14/14 对上且与参考一致。只有 3 页 42 张卡，第一帧上没有反例，门槛余量很小。
40. E043阵营颜色判定——没有玩家头像时，背景色不能再覆盖英雄旗帜颜色官方 AI 对局录像里没有玩家头像环，固定框里只有偏红战场，状态估计把两侧都判成红方，红方部队全被记成敌方。改为按（左色, 右色）配对投票并要求明确多数后，该局结算画面 14 行由 0 MATCH 变为 11 MATCH；另外三段录像结果逐字节不变；经两轮审阅修正，全部合成场景都不再给出错色。
41. E044“读数超过表值就改判兵种”对召唤物失效——改判须该兵种上过同方行动条战场数量牌读数超过某兵种开局表值时，状态估计会改判成表值恰好相等的另一兵种；召唤的星之子 66 因此被错改成狮鹫。新规则要求改判后的兵种在同一方行动条上出现过：四局开发数据的改判从 21 次（18 对、1 错、2 两边都错）变为 19 次全对，原 18 次正确改判全部保留。

Battle Notes 桌面程序：输入、存储、回看、发版。

1. A001攻击证据页的核对摘要与原图入口在战斗记录 App 的攻击证据页顶部集中显示每条日志攻击的命中条件、缺口、查询状态和已读攻防，并只按明确唯一的帧编号跳回原图；两份已保存的真实分析（58 帧与 49 帧）导入后输入与推断结果完全不变，127 项受影响测试通过。这是核对工具，不是准确率提升。
2. A002属性对照页没用上已经算好的面板解释状态估计早已算出“攻 30+3+7=40”这样的逐帧属性分解，但战斗记录 App 的属性对照页按阵营过滤正负号，把我方的正差值显示成“无变化”，点击说明也没接上这些解释。修复后两份真实保存结果分别显示参考净差 +9/+5 和 +15/+4，并能点开看到条件公式；没有改动任何推断结果。
3. A003属性对照页——把已有的变化解释放到最前面，并能打开对应原图战斗记录 App 的“属性对照”页本已接入状态估计的攻防变化解释，但单侧详情约 17,568 字，解释埋在大量状态说明中，也无法打开原图。本轮只摘录已有解释原文到详情顶部、按帧编号精确接入原图查看器；两份真实保存结果的导入点击验证通过，未改变任何数值或推断。
4. A004战斗记录 App 2026.10.13-1 本地预览构建按用户要求冻结一个可试用的本地预览版：明确列出 18 个 App 源码文件和 6 个测试文件覆盖到冻结副本，包内 Core 200 项、App 208 项、费用回归 8 项软件检查通过，两份真实保存输入经实际界面导入—仅重算 SE—再导入通过；它不是正式发布，也不是独立准确率验收。
5. A005在已保存的分析结果上人工更正读数、重算 SE 并可撤销导入旧分析结果后原来只能看、不能改；本实验让用户更正某一帧的一个已有英雄/生物数值，经真实 SE 进程重算并另存新快照，也可撤销。在一局 49 帧的已保存结果上做了两次有意的演练（9→10、18→19），只改目标字段，撤销后请求和 SE 结果完全回到基线；这是链路演练，不是修好了两处识别错误。
6. A006旧保存分析补回漏掉的攻击预览，再重算状态估计旧的保存结果里，原始读取已读到攻击预览，但当年交给状态估计的请求把它们漏掉了。用户点击“仅重算 SE”时，从同局原始读取记录补回缺失的预览任务：一份 58 帧结果补回 4 个，得到 3 组伤害范围；另一份 49 帧补回 0 个、结果不变。同时修复了一个保存路径写法导致人工更正被误拒的问题。
7. A007已保存的分析结果只重算状态估计，不重新识别旧分析导入后只能看当时的推断，修好的解释用户看不到；新增“仅重算 SE 解释”按钮，复用全部已保存识别结果、另存新快照。真实 8 帧保存样例经生产按钮链路约 2.1 秒完成，只有推断说明改变，观察和 8 条攻击证据原样；累计 143 个软件检查通过。
8. A008战斗记录 App 2026.10.14 预览候选——发布计划（未构建）这只是一份计划：冻结一个源码提交作为预览候选，列出要包含与不包含的改动，以及构建、包内验证、完整发布门禁、安装四个都需要用户批准的步骤；文档写成时没有构建、安装或启动任何程序。
9. A009实时模式下按画面出现的时间给状态估计排帧用户实时玩的三局里，简报中同一条“我方魔法 +43”重复了 6 次；原因是主读取取的截图比旁路读数晚 15–37 秒，按截取顺序排帧让 HUD 数值来回跳。改为按画面时间排序后，三局的魔法来回跳从 68 / 3 / 20 次降到 1 / 0 / 0，可疑读数从 28 / 13 / 9 降到 3 / 1 / 1；没有金标准，这是输出对比不是准确率。
10. A010准备页被整页拒收——笔记目录缺少 8 月更新后的“属性加成”子技能一局打电脑录像的 3 张准备页都被 App 整页拒收，导致状态估计拿不到我方英雄、减员时间线为空。原因是读取器正确读出了“属性加成”子技能，但 App 的笔记目录（8 月底游戏更新前的资料）里没有它。只放行 9 个已知未收录子技能并按未知处理后，三页恢复；但随即暴露出第二个缺陷：头像环颜色把双方阵营判反了。
11. A011实时模式里每次主读取的 App 端开销为什么越来越大在一局实玩会话里，一个主读取周期从约 6 秒拉长到约 17 秒，而识别进程自己只用约 1 秒；原因是每次主读取后 UI 线程都把整局读取重新组装、纯 Python 编码、深拷贝和校验好几遍，这期间识别进程有 43% 的时间空闲却拿不到旁路任务。提出并随后实施了两项最小修改（C 编码器快速路径、旁路读取不再等主读取的 App 端工作），实时效果尚未测量。
12. A012战斗记录 App 10 月 15 日预览版——计划与实际发布整理相对上一安装版的全部实时识别、结算页和状态估计改动，列出构建前验证和需用户批准的步骤；当晚应用户要求以“本地预览、范围内检查”状态发布，包内冒烟与 8 个 App 测试文件通过（一项负载下的时序测试首次失败、重跑通过），完整发布门禁和实玩尚未做。

截图与录像里的文字、数字、生物、界面读取，以及挑帧和实时采集。

1. P038失败实验 P038：生物面板局部字段可见性与标题完整性补审 87 张训练帧的生物面板字段，新发现 5 个被错误接受的读数（背景数字拼接、裁框切掉末位、标题丢字）；为此试验的新裁框几何让正确数 115→105、错误 2→8，被拒绝，没有改动任何生产路径。
2. P050失败实验 P050：给底部悬浮提示单独挑“稳定帧”想在录像里自动挑出底部小提示框已经淡入稳定、可以读字的那一帧。冻结后在两个来源组 530 帧上一张都没选中，细审的 4 次提示展示全部漏掉；失败原因是搜索区太小和框没被提出来，不是淡入。方案停止推广。
3. P054失败实验 P054：连续录像中的日志变化——没测成持续追加，却发现去重会过早确认原想验证日志开着时新事件是否都被保留，但初筛没找到持续追加的片段，完整事件覆盖和等待统计没完成；改看滚动历史后发现：较淡帧读错 4 个玩家名，200 毫秒后同内容的清楚帧却被判为重复跳过。
4. P074失败实验 P074：为缺样的生物身体补真实样本后重训从已准入训练来源补了 14 个战场生物身体标签（虫巢之母 11、地狱九头蛇 3），从头重训一次身份模型；两个缺样类别有恢复，但其他类别退步（参考裁图 689→686、完整图联合正确 662→661），未过预先冻结的不退步门槛，保留旧模型。
5. P079失败实验 P079：为魔法书边缘单独训练局部身体检测器——训练集拟合了，留出图没过门槛冻结骨干、只训练检测头的“书边局部检测器”在 5 张训练图上召回从 50% 升到 90%，但在唯一一张来源留出图上一个漏检也没补回、反而多 2 个误报；同一权重在普通整图上丢了 14 个身体。未采用。
6. P082失败实验 P082：扩大训练覆盖后重训“法术书两侧生物身体”局部检测器打开法术书时两侧露出的生物身体常被漏检；加入 16 张新书页、92 个身体重训局部检测器后，四个来源的开发集正确定位从 35/59 提到 41/59、原合格零丢失，但误报从 4 增到 6，违反预先冻结的“误报 ≤4”门槛，候选未采用。
7. P084失败实验 P084：用“完整局部视图”训练被法术书遮挡的战场身体检测（B101）加入以身体为中心、不切断邻体的局部训练视图后，四来源开发集从 41 TP/6 FP 提升到 45 TP/5 FP、零丢失；但预定门槛要求误报 ≤4，未通过，且旧 54 图整图回归 7 恢复/13 丢失，因此不采用。
8. P111失败实验 P111：在训练录像中挖掘行动条滑动瞬态想在 683 张训练帧里找到行动条卡片“正在滑入/移出”的瞬态，为“卡片没就位就跳过”规则定门槛；固定网格 ±1 像素规则会误拒 9 张稳定帧，而可确认的同类动画只有 1 次（3 帧），样本不足，按协议不实现新规则。
9. P112失败实验 P112：技能图标中央数字是不是剩余冷却？——暂停的部分诊断想用训练录像的连续时间线证明底栏技能图标上的白色数字就是“剩余冷却回合”，但 593 帧里只有 17 帧带数字、只覆盖 1 个生物 2 个技能，证据不足；扩展到全部训练录像的 1 fps 时间线没跑完就因新任务暂停，生产输出保持不变。
10. P120失败实验 P120：只看对方英雄属性能猜出它的装备吗？——用我方做对称验证把我方英雄当成“对方”，只给推断模块对方能看到的信息，再用我方面板核对。22 局里首选解释的装备只有 30/110（27%）是真的，只靠英雄属性无法辨识装备；附带的幸运/士气→技能规则触发即正确，先攻/速度没有可用信号。
11. P121失败实验 P121：录像里能找到对方英雄面板吗？在 22 段录像的 147 个英雄面板/最终确认片段里搜索英雄名，读到的全部是我方英雄，7 段“英雄面板”其实是场景误分类；用户随后确认游戏中根本看不到对方英雄面板，这条获取对方信息的路线作废。
12. P122失败实验 P122：用战斗日志里的伤害反推对方技能从 22 段录像的日志中收集 1549 条事件，只找到 14 次带伤害的英雄施法（对方仅 5 次）；一种法术的伤害与公式完全吻合，其余比值在 0.25–3.4 之间散开；生物攻击伤害比值 0.16–1.75，无法判断加成，路线不采用。
13. P138失败实验 P138：放宽生物面板外观门槛——找到候选规则但未采用被拒读的生物面板能否用“文字亮度”放行？训练数据上“文字亮度 ≥175 也通过”能多读 8 个被拒面板中的 5 个、17 个淡出负样本全拒，但离最亮负样本只差 12 个灰度级、负样本太少且没覆盖亮背景，最终未采用、未改生产代码。

截图与录像里的文字、数字、生物、界面读取，以及挑帧和实时采集。

1. P179失败实验 P179：只看过去的敌方英雄分析视频——技术检查都通过，视频却没用用一局真实录像，从屏幕上读到的敌方攻 4 / 防 6 / 法强 14 出发，用规则模拟器枚举合法选秀，做成随时间更新的“敌方构筑分析”审阅网页和 22 分钟顶部分析视频；10,824 份完整声明中始终有 17 份同样相符，大量后续读数和伤害对照都没能把歧义收窄到可用的判断，用户否定了视频的实用性，交付撤回。
2. P180失败实验 P180：只用头像内圈画面能否认出敌方英雄？（补记）把 HUD 英雄头像裁成去掉边框的内圈方块再与 77 位英雄原画匹配：两个原本认不出的敌方英雄仍然一个都没认出，4 个原本认对的对照里 3 个反而掉到接受门槛以下，所有对照的最高分和领先幅度都下降。纯负结果；原报告缺失，本文按脚本与保存的结果补记。
3. P183失败实验 P183：16 张英雄头像的一次性固定策略影子运行——初始化超时在严格的资源窗口里对 16 张英雄 HUD 头像裁图做一次性的固定策略评估（一个 CPU 进程、内存 2 GiB、初始化 20 秒），结果唯一的一次运行在初始化阶段超时（20.031 秒、退出码 124），模型没加载完，没有任何可评分结果；按规则不重试。
4. P198失败实验 P198：数量牌、生物身体与数字的联合识别——一周的算法对照台账目标是从战斗截图中可靠地得到“哪个生物、脚下数量牌在哪、数字是多少”。学习式数量牌检测器把 4 张比较图的找到数从 27/40 提到 37/40，局部入口让 7 张图的牌从 33/58 提到 56/58，但几十轮身体补训、去重、尺度、可读性分类和遮罩尝试都没有带来可采用的整体提升，生产默认一直未换。
5. P199失败实验 P199：用更细的局部输入判断“画面是否还在过渡”，没有带来改善（P914）更高分辨率的局部纹理质量模型对清楚帧 0 误拒，却放行 5/15 个过渡帧，与旧稳定门组合后毫无额外收益；后续三帧模型、底栏局部采样、分区域采样各有局部补回，但都伴随半透明坏图或过多候选，全部不接入默认流程。
6. P201失败实验 P201：数量牌“干净裁剪”候选在 OCR 之前就被否决，另得 8 张新参考图一个只保留数量牌彩色牌面的裁剪规则在 40 个已有候选中只保留 14 个，两张雪地图全部拒绝，理论上最多读对 14/38（36.84%），已低于现有基线 35/38，第二阶段被否决；同时新增 8 张原图共 105 个数量牌的完整参考。
7. P203失败实验 P203：准备页固定槽位的批量模板匹配，在合成预检阶段被拒想把准备页同类槽位的模板相关计算合并成一次批量运算来提速；合成计时中批量加精确复算 2.741 秒，比原算法 1.614 秒慢约 69.8%，而且“初筛间隔大于0.001 就安全”没有误差上界可证明，构造的反例能让候选接受错误身份。真实请求一次也没运行。
8. P204失败实验 P204：准备页空槽判定——区分“没学/没装备”和“没读出来”想在准备页上用像素比对可靠地判断技能/装备槽是空的；非空槽始终 47/47 正确、错误判空始终为 0，但空槽只认出 2/12→6/12，未参与调参来源的两个空技能槽一直是未知，新判据还带来校准槽和缩放控制回归，结论是不接入公共读取器、停止这批研究。

截图与录像里的文字、数字、生物、界面读取，以及挑帧和实时采集。

1. P217失败实验 P217：一条漏读的反击日志——正文找回了，完整事件仍无法确认战斗日志里一行“观世者(8)反击了凤凰(10)”被判为读取冲突。对这一行做三个尺度的局部 OCR 后，正文、时钟和括号数三次一致，但玩家名三次各不相同，原共识规则再次拒绝；数据格式又要求玩家名非空，因此以“已定位、未修复”结束。
2. P229失败实验 P229：数量牌“26”被读成“126”——用白色笔画核验，最终没有合入一块判官的数量牌在两张原生截图上被读成 126（实际 26）：OCR 把牌左侧灰色链锤当成了“1”，两遍一致且分数够高。新增“每一位数字必须有白色笔画支撑”的检查后，实时截图的 2 处错读变为未知、无正确读数受损；但独立审查发现被扣下的牌会被补找重读成另一个错数，且拒绝只靠一列亮度 224 对阈值 225 的余量，补丁未合入。
3. P233失败实验 P233：行动卡数量被窗口挡住时，能否用卡框下沿发现？英雄头像窗口挡住行动卡上“24”的下半截，读取器两次都读成“2”，会让推断模块算出一次假减员。尝试用卡框下沿的亮线/暗带判断“被挡住”：2,340 张数量已知卡和 8 张被挡卡的两个指标完全重叠，分不开；不改读取器。

把读到的观察累积成对局状态、减员和对手构筑的推断（SE）。

1. E025失败实验 E025：已读到的状态效果，能否直接算进当前攻防解释？在 3 张真实生物面板的 11 个状态候选上查询公开规则：3 个 known、3 个 partial、5 个 unknown，且返回值都是“安装基础量、不含运行时缩放”；没有一个可以安全地直接扣除，结论是缺口在规则提供方的原生状态查询，而不是状态估计漏调用。

一段录像最终应该留下哪些观察？先看目标，再沿处理流程往下读。

1. P02第 1 章从一段游戏录像开始一张战场截图里同时有生物、数字、说明和日志。先看这些结果怎样汇到一条可审核的时间线上，再逐个理解它们从哪里来。

减少重复工作，也保留短暂出现的文字与面板。

1. P22第 2 章挑出值得看的帧既然目标是读懂有用内容，就不必逐帧重复工作。先留下清楚、少重复的候选图，再把识别任务交给后面的模块。

先确定这是什么画面、面板在哪里；文字怎么读，在下一部展开。

1. P41第 3 章用文字判断当前页面留下候选帧后，先判断当前页面。这里把文字当作已有的线索，比较文字组合与位置；具体如何读取这些字，在 p61 展开。
2. P41第 4 章没有明显文字时，看画面加载插画和普通战场不一定有足够的文字。现在补上颜色与轮廓，比较它们能否帮助判断场景，以及为什么小提示仍容易漏掉。
3. P43第 5 章不先给框，自动找到面板知道页面类型，还要找出可以读取的面板。程序根据文字的位置定位区域，再检查淡入、翻页和遮挡；这一步不保证里面的每个字都已读对。

共用文字读取方法，再分别检查时钟、属性、日志、预览和状态回合。

1. P61第 6 章把文字和小数字读出来场景和面板模块都需要文字。现在打开这个共用工具：先读整图，再放大小块补读，分别检查读对、读错和没读出。
2. P63第 7 章行动条、英雄数字与计时有了共用文字读取方法，先看两侧英雄信息区和上方行动条。位置较固定不等于可以跳过验收：卡片、颜色、数值和时间仍要分别检查。
3. P64第 8 章给面板里的数字一个含义详情面板里也有很多数字。读出一个 24 还不够：还要记录它是攻击还是防御、来自哪个区域，以及哪些对象关系仍然不知道。
4. P66第 9 章从日志看已经发生的事仅凭身体和面板，很难知道刚才发生了什么。日志提供另一种线索：保留原文，按明确句式读出行动、效果名称和记载时长。
5. P67第 10 章区分伤害预览与实际结果日志记录已经发生的事，鼠标悬停时显示的伤害却可能只是预计结果。先分清这两种文字，再讨论它们怎样帮助比较行动选项。
6. P68第 11 章从状态图标读到法术效果日志和预览都不一定写明当前状态还剩多久。本章检查图标旁的数字与悬浮说明；图标身份、剩余回合和短画面覆盖仍有未完成部分。

文字之外，图标、部队身体和数量牌也需要自己的位置与身份判断。

1. P81第 12 章从裁图认出图标文字不是识别身份的唯一线索。先假设图标位置已经给定，直接比较裁图里是什么，以及它是否清楚到可以采用。
2. P82第 13 章在战场上找到每支部队固定槽位让分类简单了一步，战场却没有这种便利。生物会移动和遮挡，因此必须先找到身体，再尝试认出种类。
3. P83第 14 章把脚下的数字连回身体身体框找到了，部队还剩多少个却要看脚下的小牌。把身体与数量牌分开检测，才能分别检查漏框、错读和配错对象。
4. P87第 15 章读懂底部操作栏的外观与数字底栏位置固定，但空槽、灰暗图标和中央数字仍会混淆。先检查画面内容，不把亮色当成技能可用。

名称属于哪张卡？面板对应谁？高亮位于哪些格子？这些关系单独检查。

1. P101第 16 章把名称连到旁边的图标位置、文字和图标都有了候选，接下来检查它们能否配在一起。选择页卡片较规整，适合作为名称—图标关联的第一个例子。
2. P104第 17 章这是哪一支部队的资料？选择页配对不等于战场部队已关联。相同生物可能有多支，身体、行动条头像和面板必须保留各自的依据。
3. P105第 18 章给战场位置标上格子坐标除了行动说明，还需要知道目标在什么位置。先用少量已确认角点标定六边形网格，再检查当前截图能否进一步改善位置。
4. P106第 19 章读出高亮范围与障碍线索格子有了坐标，就可以把黄色、绿色高亮转成一组格子。可见高亮、障碍候选与真正可执行的移动规则仍要分开。

多帧可以提供变化线索，但不能把后来才看见的信息提前使用。

1. P122第 20 章从计时变化得到线索一帧显示当前读数，两帧才能显示变化。先从计时下降这个简单例子出发，说明时序线索怎样产生，什么时候应当保留未知。
2. P122第 21 章读出结算画面，核对整场减员计时变化是相邻帧给出的线索；战斗结束时，游戏还会一次性列出双方每堆的开局数量和损失。读出这一屏，就能给整场减员时间线做一次外部核对，也能补上最后一击后没来得及读的减员。
3. P123第 22 章让录像自己找图，再逐场检查结果已有读取器在单张截图上能给出候选。现在交给程序三段录像，看它能否找到第一局开场、采到短面板，并把读数与漏项放进逐场报告。
4. P123第 23 章实时模式：读取排队与画面时间顺序离线回放会等每次读取做完，实时对局不会。用户实玩三局后发现：读取排队让画面晚到，按完成顺序拼时间线会制造假变化。这一章讲读取调度和按画面时间排序。
5. P124第 24 章回放时也不能偷看未来把许多帧连起来后，评估更容易无意间泄漏答案。最后检查一个基础条件：判断某一时刻时，只能使用当时已经可用的画面。

正文无需依赖这些研究。这里保留图标检索、检测器比较，以及身体—数量牌融合的有效与失败尝试。

1. P901附录 A枚举方框，寻找相似图标回到一种最直接的图标搜索方法：在整屏试许多裁框，再与图鉴比较。它能给出身份建议，却也说明了为什么认得像不等于框得准。
2. P902附录 B用图鉴训练特征与裁图质量保留枚举方框的搜索方式，只改变怎样比较裁图。这里逐步研究图鉴训练和裁图质量评分，不要求先记住 A–F 的实验代号。
3. P903附录 C让检测器自己学习找图标前两篇由代码枚举方框，这篇换成学习式检测器提出位置，再用图鉴建议身份。它是小规模选择页实验，不等于战场生物已经解决。
4. P904附录 D比较几种找框的方法生产身体检测之外，还用同一批参考比较过其他检测器。本章是尚未替换默认模型的对照记录，只比较框，不把它当成生物身份和数量都已识别。
5. P912附录 E试过哪些办法，为什么还会漏身体、数量牌和网格位置有关，但加线索也会带来错误。这篇汇总已有融合与数字试验、失败原因，以及下一轮如何补数据和公平比较。

每组一份当前状态：做到了什么、缺什么、下一步。章节讲方法，报告讲进度。

1. P00从游戏画面到战斗简报，Perception 全流程做到了哪里截至2026年10月15日：采集、Perception、SE 与 App 的全流程现状；安装版实时三局、离线回放计数与结算核对，以及尚未完成的独立验收。
2. P20输入与选帧——录像里该读的画面有没有被及时留下？从录像挑出值得读的画面：九月的选帧研究与十月的App采集审计，三段对局上按有价值画面计数的结果与实时排队问题。
3. P40场景与布局——先认页面，再决定哪块区域能读先找到页面和面板，再决定哪些区域可读：场景分类、前景条件与局部许可的开发结果，以及生产场景门在App采集链路中的表现。
4. P60文字与数值稳定书页的名称、耗蓝、当前阶数与冷却，以及日志、预览和状态文字的真实覆盖与缺口。
5. P80图标与视觉对象——固定格、行动卡、数量牌与底栏固定格直接分类，战场对象先找再读。准备页子技能17/17但整页0/2；B182行动卡兵种颜色无错；实时局数量牌170对2错（26读成126，修复未合入）。不是独立准确率。
6. P100哪个数字属于哪支部队——对象与空间关系把数量牌、身体、行动卡和面板连到同一支部队；同类不等于同一队，只靠一块牌的兵堆单独列出。
7. P120组合与观察输出——一帧一份可追溯的记录让各组输出带来源、未知项和画面时间；结算画面成为新请求，实时读数按画面时间排序后再交给状态估计。
8. P140数据、标注、验收与交付录像按对局隔离、标注分三级、评估分采到/读对/SE用对三层；10月保留的四段录像、逐字段金标准、实时三层核对与磁盘规则。
9. P900哪些办法试过，为什么还没采用研究总目录：把改进、退步和未运行的想法分开，保留原图和同条件比较；含 10 月新增的两个负结果。

稳定接口、薄观察合同与界面查询流程。

1. ·游戏智能体的模块边界：稳定接口，独立实现Perception、Simulator、AI 如何各自改进；哪些变更必须共同讨论，以及设计文档怎样保持有效。
2. ·Perception 薄观察接口：只传看见的证据已实现的 v1 如何保存对象、数值、来源、坐标和时间，又如何防止未知值、旧帧和内部数据混进 AI。
3. ·让 AI 主动查看界面：查询也要一步一步执行待实现提案完整流程仍在设计中；已有顺序探查、条件耗蓝分析和空闲窗口内的付费日志读取，保留成本与信息缺口。

已经读到的属性怎样真正进入推断。

1. ·已经看见的属性，怎样真正进入战斗分析从漏掉英雄贡献、错误推断施法费用，到把整场减员接成时间线：一条贯穿图像读取、历史关联、公开规则与保存回看的修复链。

1. ·上古纪元竞技场：哪些阵营更容易抽到这五项技能？比较法师与战士抽到奇术、秘术、抗性、原始魔法、战斗魔法的单次概率；保留 2026-09-03 发布表，并按 2026-09-06“英雄开局无技能”更正后的分母给出当前结果。