s40：AI 怎样公平比较普攻、猛攻和等待

玩家可以看到自己的部队、敌方公开状态和当前合法动作，却未必知道敌人全部装备。AI 也应在这份信息上决定：现在普攻、使用疾速猛攻，还是等待？如果只比较第一击，它会漏掉反击损失；如果读取引擎里的隐藏装备，它得到的建议又不能用于真实对局。

我们采用的设计是：Simulator 根据公开输入返回能支持的行动情景，Game AI 再比较收益、代价和未知项。 新的范围计价对照多赢四局，友军损伤也较少，但等待后跳过更多，压力菜单的计算成本仍超预算。因此默认策略仍保留 v55；局部算得更完整之后，还需要检查整场选择是否更好。

flowchart TD
  O["Public observation<br/>and legal actions"] --> Q["Simulator<br/>public queries"]
  Q --> C["Ordered packets,<br/>cases and unknowns"]
  C --> V["Game AI:<br/>compare value and cost"]
  V --> A["Action + explanation"]
  A --> E["Arena App:<br/>submit and display"]
  E -->|"Next public observation"| O

图 1：公开查询解释动作可能带来的结果，策略负责取舍；下一次比较使用执行后新得到的公开观察。隐藏状态不作为额外输入。

1. 查询可以使用哪些信息？

输入包括当前观察者能够知道的单位信息、动作与同一时刻的公开移动风险。查询不能读取敌方隐藏装备、未发现陷阱、未来随机数，或在内部构造完整秘密状态再运行一次引擎。

同一份观察还必须自洽。行动者和目标应来自当前观察，单位标识不能重复；行动路径和风险报告应属于同一状态版本。缺失、损坏或过期的输入应被拒绝，确实无法知道的结果则保留为未知。格式错误与信息不足不能都填成零伤害。

一个重要验收方法是造两份公开信息完全相同、秘密内容不同的局面。AI 收到相同输入时，应给出相同的查询与决策结果。这个检查比“代码里没有某个字段名”更接近真正的信息限制。

2. 从单包估值走到完整行动

已有诊断暴露过一种失败：查询能够给出疾速猛攻的主伤害，但策略仍沿用旧回退路径，能力得分没有正确反映这份信息。增加一个提供方查询，并不会自动修好消费方的动作排序。

完整比较先分别展开普攻和猛攻：经过什么路径，能否到达，主击伤害多少，目标是否仍存活，是否反击，己方剩多少兵，后续追加击是否还存在。每个候选都带自己的资源成本；不能把“普通攻击两下”简单与“技能一下”按第一击倍数比较。

到达时剩多少兵，决定了还能打多少

玩家关于陷阱和绕路的日记提醒我们：画面上能走到敌人身边，并不代表这支兵能完整地走过去。离开一格时可能先受到警戒反击，进入下一格又可能踩中伤害区域。公开查询原来遇到多个这样的伤害包便停止估算；现在的可选 v6 查询会逐步处理，并把剩余数量交给后面的攻击计算。

下面是一段固定测试：25只兵共250生命，每只10生命，每只贡献2点主伤害。

最终主击为 7 × 2 = 14，而不是出发时的50。之后敌人普通反击5点，己方剩65生命。警戒消耗的是独立次数，不能顺便把目标的普通反击次数减掉。若出发时只有5生命，第一发警戒就会杀死它；后面的火墙、主击和主击幸运掷骰都不会发生。

私有候选 v3 使用这份查询，途中损失只扣一次。旧查询对沿路伤及其他单位的情况仍返回未知；后面的范围版本进一步补上这一项。敌人没有暴露的陷阱也不在输入里，因此算出的仍是已知条件下的情景，不能作为路线安全保证。

例如，s20 的开发场景中普攻第一击后遭反击，100 只兵降到 60 只再打第二击。猛攻可能避免某些反击，但还要考虑专注资源、隐藏装备可能改变的反应和其他合法动作。等待也必须在同一菜单里比较，而不是为了证明新查询有效就从菜单中删去。

第一版候选使用一个容易核对的评分：敌方损血乘以其生命价值，减去己方损血乘以己方生命价值，再扣除专注等资源成本。生命价值沿用原策略对兵种输出能力的估值。整段损血已经包含反击和追加击，因此不会再叠加原来的反击惩罚、击杀奖励或未来输出损失。资源稀缺时的额外成本也保留。

如果沿路损伤已经计入整段情景，就不再扣第二次。路径被空间圈套截停时，候选保留实际停点的移动评分；未知屏障和未投影完整的反应也会明确回退。每个动作都记录采用了哪种评分及原因，方便把一个不合理选择追到具体分支。

范围攻击要给每组兵分别计价

凤凰横扫可能同时打中敌军、友军和可攻击物件。旧评分只有“主目标损血减攻击者损血”，会漏掉旁边友军的代价。新的可选v8查询列出每组兵的前后生命，以及每个物件的前后耐久；私有候选v6按每组兵自己的生命价值计算收益或损失。

同一单位被主击、反击或追加多次命中时，合计使用初始生命减最终生命，只计一次。物件耐久不会算作消灭敌军。技能成本也只扣一次。物件暂时没有直接收益权重，意味着这个候选还不能完整判断拆障碍的战略价值；攻击物件波及其他单位的损失仍可以比较。

路线上的监视横扫也使用这套逐目标计算。时间领域如果先让旁边的监视兵减员，下一发监视便读取剩余数量。公开来源足够时，简单死亡还会更新已有的动态属性；屏障、临时生命、隐藏加成来源或未投影死亡连锁使整个分支保持未知。已算出的前缀不能拿来冒充完整收益。

完整行动的固定输入对照与完整菜单检查验证了这段接入。它仍是条件伤害输入：只按主击幸运的边际概率加权，后续包以未触发幸运为条件，不能称为整个随机过程的期望。默认策略仍为v55；本次候选需要新的换边整局和预算评测，才能判断是否应该晋升。

界面现在也能查看同一份公开报告：打开战场的“攻击序列”，选择普攻方向、物件目标或疾速猛攻，再点击查看预估。上表的固定横扫局面显示敌军损血50、友军损血50、物件耐久减少1；改变进攻方向后，物件可能不在覆盖范围，耐久损失便是0。展开逐包顺序可以看到各目标的前后数值，便于核对变化来自哪一步。

每次查看只查询公开信息，不推进战斗。结果按当前对局、观察版本和行动分别缓存；局面变了，迟到的旧结果就被丢弃。报告把普通与幸运主击分开，把概率未知的反击情景分别列出；无法支持完整结果时明确显示未知，已有前缀只供排查。这条查看、切换方向和关闭面板的流程已在固定局面的桌面与窄屏界面检查，支持呈现和交互正确，尚不能证明完整竞技场对局或候选策略更强。

3. 情景有概率吗？不知道时怎样表示？

隐藏装备可能导致原本不触发的反击发生。查询可以列出“发生反击”和“不发生反击”两个条件情景，但没有信息支持时，不给它们编造 50% 的概率。情景说明的是“如果条件成立，会算出什么”，不是已经知道条件会发生多少次。

幸运则还有另一层问题：主击幸运可能与该次攻击的免反效果相关，不能分别打两个互不相关的折扣。当前可选 v4 保留普通攻击的主击幸运情景，并加入疾速猛攻主击幸运与隐藏 Buckler 反击条件的组合；隐藏分支的概率仍为空。这里 Buckler 指可能改变反击结果的装备来源，不向 AI 暴露对手是否实际拥有它。

当前情景也不是整个随机序列的完整概率树。某些后续包以未触发幸运等条件计算，未建模的反应可能让总量保持未知。策略必须检查查询的支持程度与限制，再决定使用部分值、条件值或保守回退，不能只读取一个总伤害数字。

候选对主击幸运使用公开概率加权；同一幸运结果下，若存在概率未知的反击条件，就选取这些完整情景中的最低收益。这个取舍表达了保守偏好，并不意味着 AI 知道对手有圆盾。如果任何必要分支仍是未知，整个动作继续用原策略评分。

接入时还发现一个边界错误：估算猛攻能击杀目标，并不能排除目标在主击之前反击。带隐藏圆盾的先制反击目标可以先造成损伤。v4 查询保留这个未知分支；新的可选 v5 查询能按先制反击后的剩余兵数重算猛攻，再处理附近队友的协助反击。

下面用一个固定测试解释顺序。攻击方有 3 只兵，每只生命上限为 10，当前共 25 生命；无幸运时，每只贡献 10 点主伤害。假设圆盾开启了反击分支：

如果攻击方开始只剩 5 生命，第一步就会杀死它，后面的猛攻与协助反击都取消。主击幸运的概率也只描述“主击能发生时”的那次掷骰；已经被先制反击杀死的分支没有这次掷骰。因此，其各个幸运标签下都应得到相同损失。缺少必要状态时钟或伤害信息时，受影响分支仍保留未知。

私有候选 v2 使用这份先制查询，v3 再加入上一节的逐步路线；评分方式和资源成本沿用第一版，旧候选 v1 仍使用 v4。它们都没有替换默认策略。

另一个常见误解是把均值代入当成真实期望。若先算平均剩余生命，再向上取整得到存活数量，结果通常不等于逐个随机分支计算存活数量后再求平均。非线性的死亡和数量阈值会改变后续伤害，所以报告必须准确命名它算出的量。

4. 决策预算和界面应该怎样配合？

当前候选按菜单顺序最多查询 64 个攻击动作，超出部分保留原评分，完整菜单仍然参与选择。使用固定次数预算，可以避免机器一时变慢就改变动作结果。后续若增加更深搜索，再根据实际时间限制安排额外计算。查询次数、候选数、平均与尾部延迟需要一起记录。

界面则应回答用户能据此做决定的问题：这个动作能否到达，已知哪里会截停，哪些伤害和反击结果有依据，哪些取决于未知条件。已知风险可以提示，用户仍可能有意进入风险区域；风险提示不应悄悄改变合法动作。

公开预测与执行回执还应分开显示。前者是动手前能知道的范围，后者是实际发生的结果。把执行后读到的隐藏原因补回动作前的训练输入，会让模型学到实战中拿不到的信息。

5. 什么证据足以换掉默认策略？

先用已暴露的开发反例确认修复：完整合法菜单存在，普攻和猛攻的分包正确，资源成本只计一次，等待和免费前置动作仍能使用。这一步能排查实现错误，不能单独证明策略更强。

随后在调权重前冻结新的局面和种子，覆盖换边、兵力差、反击机制、无狂暴、资源不足和不同路线。基线与候选使用同一当前引擎，唯一有意改变的变量是策略。运行到自然终局，并分别统计截断、异常与超时；每局保留可重放结果。

9 月 30 日第一版候选的结果如下。所有对局使用同一引擎、完整合法菜单和正常的 100 回合上限，均自然结束并通过 JSON 回放校验。

开发局面的候选都能在有用的免费前置技能之后选择正收益攻击，减少了一部分实际败局。冻结对照由 16 组配置分别换边组成，共 64 局；本批没有增加胜局，也没有原本胜局变败局。它包含兵力差、专注不足、无狂暴、路线、幸运和不同反击来源，但多数对局较短，仍不能代表复杂混编军队。先制反击边界修正后，用原配置重跑得到相同胜局结果；这次重跑是回归检查，不能算作第二份独立证据。

新增的 v5 查询另有 432 个固定执行场景，交叉检查攻击方残血、目标生死、反击次数、正负幸运、协助反击与隐藏圆盾。公开输入相同的两种隐藏世界得到同一份条件报告，所选分支的双方损血与实际执行一致。这些是单次行动的实现检查，不能当作 432 局对战，也不能把上表的旧结果转给候选 v2。新安装游戏版本的来源核对仍未完成，这组检查也不证明对该版本的规则支持。

逐步路线又增加了96次固定单步执行对照，包含多个警戒、两段火墙、途中死亡，以及警戒目标到达后继续普通反击。警戒信息来自先前真正执行的等待与反击事件，所有事件经过JSON保存和重放。这些检查支持查询与执行的一致性，整场收益由下面的混编评测另行检查。

混编多赢两局，为什么仍保留默认？

后续评测让双方各带3或5队兵，包含近战、射手、协助反击，以及专注不足、只够一次施法和兵力悬殊的情况。16组配置各自换边，由AI从完整菜单决定何时施放狂暴，运行到自然终局。首次评测把部分兵放在不可用边格，28局被拒绝；修正坐标后重跑的64局全部结束并精确回放。原失败记录保留，修订后的结果不算新的64局独立样本。

两场新增胜利来自同一组圆盾反击场景的换边版本。蓝方例子中，掠虫原先攻击羊人，主击794、受到普通反击291；候选改打守护者狮鹫，主击1264、受到普通反击44，之后整场转胜。它没有读取隐藏装备，而是按公开条件下的完整交换价值选择目标。事后用两个旧候选各跑这组局面的两边，四局也都获胜，逐单位终局生命与新候选相同。因此这两场改善不能归功于最新的先制或路线查询；局部版本对照也不增加独立样本。

等待的代价则还没算完整：候选会因所有即时攻击换血为负而等待，但等待期间敌方仍可能射击、堵路或削弱己方。没有同单位同轮重复等待，所有对局也都自然结束，这只能说明没有出现本批死循环。单射手场景的两场胜局还分别少剩142和91生命；候选也没有实际使用疾速猛攻。因此继续保留默认策略，并进一步检查等待后的实际结果。

本批最多每次8个序列查询，候选658次决策的合并p95为17.067毫秒，查询部分p95为1.481毫秒。这里采用三进程并发计时，不能当作64查询预算的串行上界，也不支持真实玩家群体的胜率结论。

能结束战斗，为什么还在走位？

为检查等待，我们把上述评测中的20次等待分别换成当时公开评分最高的攻击，再让原策略继续整局。没有新增胜局，最终双方生命差12次改善、8次恶化。这个事后诊断说明，不能只看到等待变多就统一催促AI进攻。

其中一局暴露了更具体的问题：敌方只剩27生命，己方有三队兵，AI却持续追逐到100回合。检查第6回合发现，守护者狮鹫已经能攻击最后的弩兵，实际执行会立即获胜。然而，移动得分约35，攻击得分约20。原来的移动公式按己方兵力和接近距离给分，没有随着剩余敌军变少而限制收益。

新候选给接敌收益加了一个上限：走近敌人的价值，不超过消灭当前所有存活敌军的生命价值。 生命价值仍用既有的兵种权重；途中受伤继续另行扣除。贴身射手脱离还可能保存己方生命，因此保留原有的撤退评分。这个上限是策略偏好，不是新的伤害规则，也没有让AI读取执行后的结果。

在原始追逐检查点，新候选一次攻击就结束了战斗，完整历史也能保存和重放。随后用实现前固定的16组新配置换边比较，只改变这一项评分，共64局：

64局都自然结束并精确回放，没有非法动作或胜局退步。只有一场原本就会获胜的残局多保留10生命：弩兵直接攻击最后的羊人，提前结束战斗。这个结果支持保留修复作为私有候选，但没有证明整体棋力提高。开发反例与新对照承担不同作用：前者证明具体错误消失，后者检查它是否影响其他局面；不能把两者混成一个胜率数字。

分别计算友军损失之后，整局真的改善了吗？

范围候选逐组计算敌友损失，继承前述移动上限，再用16组新配置换边比较，共64局。 双方使用完整菜单、正常先攻和当前产品默认状态格式，不强制开场施放狂暴。 这些跨种族混编与数量缩放是人工测试，不能代表真实竞技场选兵分布。

第一轮有62局自然结束、1局拖到回合上限、1局队列异常。异常来自默认策略： 击杀额外行动选择等待后，士气把同一队兵排进两个队列。 s20说明了等待结算修正。 修复后按同一配置和种子重跑，64局都能保存并精确回放，63局自然结束； 默认策略的凤凰镜像残局仍有一局拖到第100回合。原结果保留，重跑不算第二份独立样本。

候选没有失去任何基线胜局。旁伤较少支持继续研究逐组计价，但候选也继承了前序 移动改动，四场改善不能全部归因于范围查询。等待后跳过反而增加，疾速猛攻 也只有一次实际选择；这些问题仍需逐行动分析。本批无非法动作、同单位同轮 重复等待或付费猛攻零主伤，但尚未通过全部自然结束的门槛。

预算也要单独检查。整局单次最多只做6个查询，候选完整决策的串行p95为19.057ms， 查询小计p95为3.918ms。p95表示95%的本次样本耗时不超过该值；它不是最坏情况。 我们另用五队混编和一个70敌队的大菜单，各预热10次后串行测100次，预算事先 固定为完整决策p95不超过100ms、查询小计不超过20ms。

压力场景超出了合法竞技场选兵规模，用来检查查询上限与大菜单成本，不能当作 正常竞技场延迟。64次查询之后剩余6个攻击确实回退，完整菜单仍参与选择。 次数上限有效，却不保证时间足够短：基线在同一压力菜单的p95也达770.252ms， 原有菜单扫描与重复查询都需要分析。因此保留私有候选，下一步同时检查等待 机会成本与串行重复计算，不扩大预算来掩盖失败。

保持动作不变，怎样减少重复计算？

耗时分析发现，程序为每个可能受击的目标都重新扫描全场，判断射手是否贴身。 同一份只读伤害说明里，射手有没有相邻敌军不会随目标改变；现在扫描一次， 其他目标复用这个结果。每个目标的位置与属性仍分别检查，下一次查询重新计算， 不会沿用上一局或上一行动的答案。

范围查询还要分别试算普通、幸运和不同反击条件。原来每个情景都深拷贝整份 观察，包括不会修改的英雄和显示资料；现在只复制会被试算改动的兵种面板、 状态和场地记录。状态仍完全复制，因为邻军死亡可能改变剩余兵的防御加成。 一个情景里的伤亡不能改写原始观察，也不能改变另一个情景的初态。

普通与压力输入的完整报告、评分和所选动作均与优化前一致。随后按原协议 重跑64局，全部完整事件记录相同，共1740次行动；这证明本批行为没有改变， 不能算新增64局棋力证据。速度另外在运行重型回归前，按同样的10次预热与 100次串行计时测量：

压力场景明显变快，但仍超过100ms／20ms的固定预算。查询上限、完整菜单与 策略权重都没有修改，原始失败结果保留。局部机器负载可能影响计时，这份 测量不是普遍延迟上界；接下来还要减少重复规则计算，并继续分析等待的机会成本。

6. 只改名字，为什么规划样本也变了？

另一条规划路径需要先生成多种可能的敌方配置，再用公开观察逐步排除不符合的配置。每一种配置构成一个“候选世界”。这样可以试算后续行动，同时保留对敌方技能和装备的不确定性。

这里出现过一个容易忽略的问题：虽然测试固定了随机种子，生成器还把整份游戏目录的文件摘要作为随机输入。因此，只更正一个兵种的中文名称，也会改变所有候选世界。部分测试随之找不到与公开开局一致的配置，名称维护意外改变了规划评测。

现在，Game AI 只用事前固定的种子和固定生成算法，依次生成选兵、随机选项和战斗规划所需的种子。Simulator 另提供明确的机械规则版本，检查这些配置是否兼容。比如，更正兵种名称后，候选的选兵和装备保持原样；修改兵力、属性或选项规则时，才需要更新机械版本。Arena App 恢复存档时保留原有采样版本和顺序，完整旧存档仍受原有回放兼容性检查约束。

新算法在查看结果前确定，原来的两个局面种子和采样种子没有改。四组“局面 × 观察方”全部找到一致开局，也全部能按同一种子重放五步混合历史。这五步实际是等待、移动、施法、跳过、跳过，攻击覆盖由另两组检查承担。原测量中，较小预算的两步攻击有一方无法匹配；较大预算的三步历史双方都能通过逐步条件化匹配，但还没有原始单一种子重放证明。

凤凰的新伤害抽样接入后，之前同一份小预算检查变成双方都无法匹配。候选、种子和每事件32次尝试都没有改；当时的受控逐动作对照也没有发现筛选误删有效匹配。固定搜索范围未覆盖这段历史，程序报告“未找到”，不生成完整轨迹。混合历史和另一组高预算检查通过，也不能保证扩大预算就能覆盖所有新历史。

接入有序单位横扫后，程序还必须考虑侧目标消耗的随机数和逐目标受伤反应。只抽“主击＋反击”的快捷筛选无法表示这条路径，因此这条候选世界规划路径遇到凤凰主击或反击时，会执行完整战斗转移，再对照公开检查点。前述公开范围评分则只读取公开数据，不重建隐藏世界；两者是不同规划入口。

这组检查说明名称校正不再扰动采样，同时保留了搜索预算不足的真实限制。默认策略仍为 v55；后续要继续补齐未投影的规则与复杂完整对局，用固定协议评估评分收益。

7. 只有部分截图时，怎样提供场景建议？

前面的行动规划要求当前公开观察和合法动作。真实游戏截图往往只露出一支部队，玩家也可能先记下兵数，稍后才补英雄。为了让这些记录立即有用，桌面战场笔记增加了 AI 场景分析：先显示已记录部队的比较和打法建议，再列出详细指标。它不要求先填英雄，也不会把未识别的敌军补成默认阵容。

感知模块负责读图，Game Knowledge 保存游戏基础资料，State Estimation 把本局读数整理成带时间和未知项的估计，Game AI 计算比较与建议。桌面 App 负责展示和取消任务。这一版是普通代码实现的估计与规则建议，没有调用语言模型。

flowchart TD
  P["Perception readings"] --> N["Battle Notes<br/>current match"]
  N -->|"JSON / process boundary"| E["State Estimation"]
  K["Game Knowledge<br/>base attributes"] --> E
  E -->|"Public function / core process"| A["Game AI comparison<br/>and conditional advice"]
  A -->|"JSON / process boundary"| N

图 2：App 将当前记录交给独立计算进程；估计与评分在该进程中通过公开函数衔接。结果只用于显示，不回写成已确认的游戏事实。窄屏可横向滚动查看图。

例如，输入是我方5只天使、敌方40只活化盔甲，双方英雄未知。程序查基础资料，分别算生命容量、杀伤潜力与抗压指数。生命容量为数量乘生命上限；杀伤潜力为数量乘平均每只杀伤，再乘“攻击+20”；抗压指数为生命容量乘“防御+20”。后两个系数最低取1，避免异常负面板形成负权重。这里的生命容量不扣首只受伤，另外两项也不是实际交战伤害。

每个指标用“我方减敌方，再除双方合计”表示相对差，三个差值等权平均后乘100；零合计项记0。这个合成输入得到 +24.5分，只说明所选指标偏向我方，不能解释成24.5%或任何胜率。建议指出我方有射手、敌方有近战兵，可以检查保护空间；具体站位、射程和接敌损失仍需核对。

窗口同时提供基础资料和最近关联面板两种比较。面板覆盖已有读数，未读属性沿用基础值并说明来源；同一时刻的同优先级读数冲突则保留未知。如果其中一队数量未知，综合分直接显示“证据不足”，已知小计仍可查看。阵营未核对，或同种兵出现在多个槽位时，面板不会自动绑定到其中一队。

时间处理决定这些结果能否可信地复用。旧截图的晚到审核不能覆盖较新的截图；换局、改变兵数或加入读数都会使旧结果失效。没有首次到达时间的旧存档，只能按本次分析时已经可用处理，不能倒填到更早的决策。多张书页仍只取最新可用一张调用既有魔耗模型，重复截图不增加独立证据量。多个兵团有相同攻击增量，只能提出共同加成的解释，不能据此指定某件宝物。

数值测试检查增兵后的分数变化、交换双方后的正负反转，以及冲突和未知处理；真实后台进程与桌面测试检查无英雄分析、换局、迟到回调、取消和关闭窗口。960与560像素宽的原生窗口已检查可读性和横向溢出。这些验证证明计算和信息传递按设计工作，没有测出实战建议的胜率收益。

我方装备也会影响敌方读数，怎样分开看？

假设我方笔记记着已穿戴第六指戒，敌方活化盔甲面板显示士气+2。该戒指对敌方单位的士气贡献是−1；这个配置已与当前安装游戏中的宝物条目及公开规则输出核对。在简单加性条件下，去掉这个已知项后的结果就是+3：

这两个例子使用合成读数，目的是检验计算与显示。条件值不能称作“敌方裸属性”：敌方自身装备、技能和状态仍可能包含在里面，而且当前装备未必在旧截图时已经穿戴。如果士气或幸运被某个效果固定，减法也无法恢复原值。已知覆盖会让结果保留未知；其他未观察到的覆盖仍需要核对。

实现上，State Estimation 复用 Simulator 的公开装备组合查询，包括已有的套装处理；App 不另写一份宝物公式。已记录的已穿戴装备只是已知子集，空记录不表示没有影响，槽位冲突也不能悄悄变成背包物品继续计算。窗口在场景评分与建议之后列出原读数、已知贡献和条件值，当前评分继续使用原读数。修改装备会立即清掉旧结果。

目前自动解释我方装备影响的范围是士气、幸运、先攻和移速。实际后台进程验证了第六指戒的+2→+3、装备修改失效、原记录不回写以及旧接口兼容；这仍没有证明完整敌方装备可以从面板唯一还原。

能配出一组装备，为什么还不能说猜中了？

独立分析窗口现在也能提出敌方装备候选。输入至少包括英雄、一个已记录兵种和两项英雄数值；已经记录的技能和装备作为本次假设保留。程序先试单件与套装组合，再扩展少数接近读数的组合。每组装备都交给 Simulator 的公开接口，计算允许的成长结果、最终加点、百分比与取整；不会直接把单件数值相加当作整套效果。

一个合成对照使用白骨靴子与胸腔盔甲，正向算出英雄攻击5、防御18、法强10、知识10、魔法上限100。第一次搜索只靠单件排名引导组合，漏掉了这组两件装备，最小差值为3。加入同套装的两件组合后，302次查询找回了零差值解释：

第二行仍有未解释的攻击差值，界面会直接标出。第一行也只是通过当前模型的解释：未记录技能、额外属性奖励、敌方影响和战中状态仍可能改变答案；搜索最多做320次公开投影，并未穷尽所有装备组合。当前魔法值也不会被当作魔法上限。这个例子参与了算法修正，不能当成独立实战准确率。

若两种候选在一个未观察字段上给出不同预测，建议会提示优先补看该字段。读到同一状态下的数值，可以比较这两种解释，却仍不能排除搜索范围之外的构筑。候选不会写回笔记，也不会补进当前场景评分；换局或修改技能、装备、读数就会使旧结果失效。下一步是把同状态的真实录像、技能和伤害信息纳入共同约束，再用已核对的对手构筑验证。默认行动策略仍为v55，这个辅助窗口不替玩家执行动作。

真实录像里，搜不到也可能是程序漏了

随后把三段真实录像的固定读数送入同一接口。两局的敌方英雄仍未识别，程序保留未知，不能把肖像最相似的第一名直接填进去。第三局有“黛莉娅阿姨”候选，画面显示攻击18、防御17、法强4、魔法上限40。这里测试的是“假设英雄候选正确，能否解释这四项数值”，没有敌方真实装备答案。

这次发现了一个搜索问题：程序只把单件排名靠前的八件宝物用于后续组合。如果这些组合已经试过，或者槽位不合法，搜索会提前停下，尽管还剩查询预算。因此，在仍有差值时，新增一步：给当前最接近的几组装备尝试其他单件宝物，直到原有预算用完；每次仍完整计算成长、套装和取整。

查询上限仍是320，原图和读数也没有改。两个解释使用不同宝物和不同成长分配，说明旧搜索确实漏解；它们并不证明敌方穿着其中任何一套。这三段录像已参与开发，不能从这张表计算实战准确率。没有完全拟合时，界面现在会先提醒搜索可能漏解，再提示核对未记录的技能、状态和读数。

同一批录像还提供两张较晚的法术书，魔耗模型分别拟合了10项和8项完整读数，但书页比对应战斗图晚约16秒和441秒，暂时只作单独分析。行动条也只含可见队伍，不能保证军队完整。下一步需要补齐对象、时间与真实构筑，才能把这些局部解释联合起来。

让同一组构筑同时解释属性和费用

装备模型能解释英雄数值，魔耗模型也能解释书页，并不意味着两者猜的是同一组技能和装备。为此，新增了联合验证器：先声明双方各自的英雄、技能、宝物、部队和原始法术等级，再通过同一次来源组合计算英雄属性、显示等级与费用，逐项和读数比较。

一个合成例子说明了它的用途。两种敌方配置都有攻击5、防御7、法强11、知识9，但只有其中一种带“反术法师”。其他条件固定时，我方一级闪电弩箭的费用不同：

这一条费用读数能区分这两个候选，却不能鉴定技能。如果我方同时有减耗鞋和升级德鲁伊，它们又能抵消反术法师的加耗，使费用回到6。联合验证器会保留这种多解，不把其中一种称为确定答案。

法术等级也要从来源向前计算。例如，原始三级加上学派效果可能显示四级；直接把画面四级当成选秀四级，会重复计算加成，甚至构造游戏选项里不可能出现的卡。验证器分别保存原始声明与显示预测，不用后者覆盖前者。

在这个验证器之上，程序现在可以组合指定的技能假设，再逐个筛选。一个合成开场例子从8种组合开始：英雄属性和第一项魔耗读数留下2种；它们对另一法术的显示等级分别预测为2级、3级，因此程序建议补看这个等级。加入新的同状态2级读数后，只剩1种。这个结果只说明传入的候选池中还有谁吻合，池外构筑仍可能给出相同读数。

补看建议也不能按装备解释的数量投票。同一组数值可能对应很多套装备；再找到十套相同预测的装备，并不让这个预测更有根据。程序先把相同的预测向量合并，再比较每个字段能区分多少对不同预测，以及看完后最坏还剩几种。没有实际构筑频率时，这些计数只用于安排核对顺序，不称为概率或预期信息增益。未解析和超出预算的候选也会单列保留。

候选从哪里来、当时知道多少，同样影响结论。现在每组候选都列出双方的来源，把实际读数和模型假设分开；不清楚何时可用的资料保留未知。来源检查在相同构筑去重之前完成：后来补录的一组装备，不能因为碰巧与早先候选相同，就混入更早的分析。新增技能假设也要单列依据，不能借用种子候选的较早时间。

这套计算现已提供独立的公共 JSON 接口和进程入口，其他模块可以复用，不必复制公式或导入内部实现。App 的“联合开场预测”页使用同一入口：导入本局开场资料，明确蓝红双方哪边是我方，再查看吻合候选、逐项差值和补看建议。不同局的文件被拒绝；换局或笔记变化后，旧结果失效。

现在也可以点击“从本局记录生成”：选择一张已有法术书、指定其阵营，再明确把当前双方笔记与该书页作为同一个尚未行动、施法的开场假设。程序据此生成来源候选，不再要求手写完整文件。书页保留原获取时间；当前笔记没有首次记录时间，只按现在提出的声明处理。这个关联仍由使用者给出，程序没有自动证明两张截图属于同一状态。

候选生成先枚举规则允许的成长与最后加点，再尝试法术卡允许的原始等级。除了已记录技能，它还组合反术法师、阻碍和炽热艳阳，并可带上当前装备搜索提出的解释。成长按自身属性差值安排尝试，每项法术最多保留两条等级组合路径；试算额度分给不同来源组合，最后再完整联合核对。未知原始等级会增加可行解释，不能沿用前面原始来源已经给定时的筛选数量。

这些输入用于开发和回归，没有真实对手构筑标签。生成最多做256次前向试算，再核对最多32组来源；没有覆盖全部技能、装备、成长和原始等级组合。自身来源排序也未完整考虑跨侧影响，排在后面的成长仍可能正确。App显示具体来源、差值和补看字段，保留搜索不完整的说明，候选仍不加入当前场景评分。

目前这一步只处理已明确关联的开场状态，部队存活且尚未行动、施法。缺少关联、读数互相冲突或报价未支持时，结果会说明哪里无法比较。合成验证、顺序筛选和实际 App 后台进程检查支持这些实现行为；真实录像中的状态关联与构筑真值仍需补齐。之前熔岩录像的两组装备解释已恢复成合法来源，较晚书页仍未合并，记录内场景评分继续使用原模型。

英雄属性相同，兵种面板还能区分什么？

有些技能改变部队，却不改变英雄面板和当前法术费用。因此，联合核对的下一步是把兵种面板也作为约束：同一组双方来源先预测英雄与魔耗，再预测指定兵团的攻防等属性，逐项比较。新比较器已在估计模块内部实现，公共接口和 App 尚未接入这一项。

一个合成例子固定英雄攻击5、防御7、法强11、知识9，以及相同的法术书。两种来源只在敌方是否拥有战斗魔法上不同，当前规则模型给剑士的数值如下：

这个读数可以区分传入的两种解释，但不能据此鉴定战斗魔法。比较器还保留原始属性与计入状态后的有效属性：另一个战斗狂暴例子中，剑士原始攻击为9，有效攻击为11。如果不知道游戏面板采用哪种显示方式，就先保留两者，不自动挑较符合读数的一种；模型出现小数时，也不擅自猜测界面怎样取整。

真正的难点仍是对应关系。对现有四张真实面板，只读取已保存的算法结果，不用人工参考补空值；由于缺少明确的开场状态、阵营和兵团关联，四张都没有进入构筑筛选。其中天使截图已经显示11/12数量、180/225生命及状态图标，不能直接拿来检验“满编、尚未行动”的开场假设。下一步需要先补齐这些关联，才能把兵种约束接到候选场景与建议中。这里验证了比较逻辑，还没有测出真实构筑预测准确率。

多种解释留下来之后，AI怎样给建议？

剩下几组吻合构筑时，只选最乐观的一组给分，会让建议隐藏重要的不确定性。联合页现在增加“候选场景与建议”：每组来源各自通过公开规则生成条件面板，AI再比较生命容量、杀伤潜力和抗压指数。界面显示评分的最小值与最大值，并列出每条建议适用的候选；没有把候选数量当成发生概率，也没有用这些数值覆盖原笔记。

下面是一个有意缺少敌方军队读数的合成例子。双方英雄、成长和我方书页条件固定，我方有一份满编剑士。两组来源都能解释已给读数，但对敌军的声明不同：

因此本批范围是−31.697到0分。这个范围只说明所试两组来源怎样改变指标，不能解释成“真实评分一定在这里”。界面会注明，压制弩兵的建议只适用于第二组；第一组没有声明弩兵，也不证明真实敌军没有射手。装备效果由同一规则提供方投影，AI没有另写一份加成公式。

选择具体候选还能查看双方的部队属性、开场魔法值和每个法术的首次费用。预算不足的法术会单独提醒，费用无法计算则保持未知。预算足够只表示魔法值能支付这一笔费用；是否有合法目标、现在能否施法、第二次施法是否更贵，都还需要当前行动状态，不能从这个表推导整场轮转。

这条路径最多试算32组吻合来源，失败和预算外来源单列保留。当前没有真实布阵和地形输入，模型明确使用满编存活部队、默认布阵与沙地，停在首个单位激活之前；这些条件可能影响属性，因此分数只用于比较声明的场景。它不会给出具体走格指令，也没有测出实战胜率收益。实际后台进程与界面检查覆盖了多来源评分、阵营翻转、取消、改笔记和换局失效；下一步仍需真实状态与对手构筑真值，才能评估哪些建议在实战中有效。

日志里失去19魔力，能猜出什么？

战斗日志还提供了一种线索：一行说角色失去多少魔力，下一行说它施放了什么法术。现在战场记录的日志页可以点击“费用条件分析”，比较哪些模型能解释这个数字。Perception负责读取原文，估计模块提出条件并调用Simulator报价，App显示多种解释；这一步暂不修改开场候选或AI评分。

程序先检查两行是否同玩家、同角色、同日志时钟，而且损失在前、施法紧随。同一秒出现多条同类记录，或中间夹着未知行，就不配对。即使满足这些条件，也只是假设两行属于同次施法；字面魔力损失本身没有证明这就是施法支付。

例如开发截图中，咕噜失去19魔力，紧接着施放寒冬循环。普通施法模型在假设等级1至4下都给出未修正费用21，其中两种解释是：

“净固定”把加耗与减耗抵消后的结果合为一个数，它并没有指出具体装备或部队。等级也是尝试的条件，并非从日志读出的事实。因此19不能单独确定阻碍技能；还应补看当时等级、施法次数、状态和角色归属。同一条日志滚动到下一张图，也不会变成一次新的独立证据。

这次接入也发现了旧费用模型的一个构造错误：程序想用黑冰表示固定加耗1，却没有给黑冰的来源提供专注，实际效果成了0。修正来源状态后，每个声明的固定修正都逐项与公开报价核对。旧书页估计因此可能改变数值；历史测量保留原版本含义，不能把新旧概率混用。

实际App进程已处理14份已有开发图结果，并检查宽窗与窄窗呈现。其中“阿丹失去25魔力”的下一行法术未知，程序保留缺配对；“精湛生命回溯”没有精确对应资料，程序保留未知名称。它们验证了多解和未知如何进入界面，尚无真实构筑标签可测鉴定准确率。后续要把视频时刻、对象和行动可靠地关联起来，才能让这些局中线索进一步约束打法建议。

返回 s00 总览；结算细节见 s20；观察与真实界面的后续交接见主动查询与逐步执行提案。