《英雄无敌：上古纪元》的战斗里，一队兵可能先攻击、遭到反击，再用剩下的兵打第二次。助手若只知道技能名字和第一击伤害，就可能建议一个会让己方主力先死掉的动作。我们需要把游戏资料、规则执行、行动比较和用户看到的解释接成一条能够检查的流程。

S 系列记录这套系统的重要设计。本文先回答谁负责哪一步；s20解释战斗如何结算，s40解释 AI 如何在有限信息下比较行动。它们是持续维护的设计文档，每篇都明确采用的决定与尚未完成的工作。

flowchart TD
  A["Game files<br/>and observations"] --> K["Game Knowledge"]
  K --> S["Simulator"]
  K --> R["Reference App"]
  S --> Q["Public observations<br/>and queries"]
  Q --> I["Game AI"]
  I --> U["Arena App"]
  U -->|"Submitted action"| S

图 1：Game Knowledge 管资料，Simulator 执行规则，Game AI 比较动作，Arena App 组合成可玩的产品。Reference App 是另一种资料浏览入口。

1. 从一个真实问题走完流程

玩家发现：兵种技能“疾速猛攻”不会因为身上有“狂暴”，就获得普通攻击的追加一击及该技能不适用的伤害加成。我们先在资料层记下玩家亲测结论，再查安装文件中对应的能力、标签与倍率，明确哪些信息来自玩家，哪些来自配置。

接着，Simulator 修改该能力的执行。这里必须保留单位身上的真实状态：某项攻击不吃一个加成，并不意味着把整个狂暴状态删除。其他攻击和后续行动仍可能需要它。

执行正确后，公开查询还要能向 AI 说明这次行动的伤害与反击风险。查询完成也不代表 AI 已经会用：策略必须把新结果纳入动作比较，界面再说明为何选择这一招。每一层都有自己的交付条件，不能以最底层的一次修复代替整条流程验收。

2. 为什么按责任划分模块？

如果界面、AI 和引擎各写一份伤害公式，某次修正规则后，三份公式很容易变成三个答案。我们让计算规则归 Simulator，让其他模块通过公开入口查询；显示名称和事实目录则归 Game Knowledge。

模块 一句话职责 检查重点
Game Knowledge 维护实体、游戏资料、名称和已审核来源 身份对应是否有依据，数值是否来自正确版本
Simulator 按规则结算动作，并提供公开信息可支持的查询 顺序、随机性、状态更新与回放是否一致
Game AI 用决策时允许看到的信息选择动作 有没有偷看，比较是否完整，改动是否真正有益
Arena App 组合对局、界面、保存与恢复 用户看到的状态是否正确，操作是否可完成
Reference App 让用户查阅和审核资料 是否显示同一套正式名称和事实

Reference App 的兵种页现在沿着三个问题组织：先按种族或等级找到单位，再把三个选择固定到同一屏幕，最后查看阵营×等级的统计表。数据使用已审核的 0.80.49／build25061458 单次竞技场选秀数量。每个形态的总生命先算“数量×单体生命”，同级三个形态再等权平均；攻击、防御比较值分别为“数量×（基础属性＋20）”。这些值用于查看差异，不是战斗胜负预测。表格保留每个形态的明细，避免平均值掩盖分支差异。

魔法页另设限制速查，明确分开整个法术无效、魔法伤害被免疫、只有治疗部分无效三种情况。原始数量、基础属性与限制资料由 Game Knowledge 提供，筛选和计算属于 Reference App；日记引出的选兵建议由 Game AI 维护。三槽选择会在筛选和界面缩放时保留。

Perception 是图片输入一侧的模块，负责报告画面中读到了什么。它的结果可能有遮挡、读错或不确定；解释这些观察、判断状态并执行商业客户端操作，还需要后续环节。P 系列记录这部分工作。图 1 描述当前本地模拟产品的主链，不能据此认为从游戏像素到自动操作已经全部接通。

这也限定了 AI 的工作方式：当前策略使用程序生成候选、查询规则并评分；大语言模型不负责控制每次战斗结算。未来若增加需要语义判断的模型，应明确它被调用的输入、输出和失败处理。

3. 名称统一到哪里，事实又怎样核对？

同一实体应在资料库、日记整理、Simulator 展示和两个 App 中使用游戏当前中文名。例如类型 Embodiment 显示为“化体”；特定召唤单位 Avatar 显示为“化身”。程序用稳定实体 ID 连接两者，不能因为中文看起来相近就合并。

已下载并分析过的网页资料可以直接更正名称，不需要为了旧译名再保留一整套显示层。旧名称只在必要的搜索兼容入口或玩家原话中局部出现。Perception 的原始截图、录像和 OCR 原读数保留：它们用于检查“图上是什么、识别器读成什么”。对应实体的显示名称仍使用正式名称。

游戏更新后，名称与战斗规则分别核对。0.81.02 的名称复查沿用1,023条已审核实体与游戏文本 ID，确认八处新译名，并已同步资料库和桌面 App，例如“法术免疫 I–V”和“延黑”。缺少可靠对应的三条仍保留原名。名称更新有精确文本依据，却不能证明新版战斗规则也已全部实现。

规则来源也要说清楚。例如玩家在上一次安装版本明确确认“奈拉之吻消失后，下一支敌方单位跳过行动”是 Bug。这条观察保留为已确认；0.81.02 中是否仍出现、完整触发细节、引擎是否模拟它、根因是否查明，需要分别核对。未完成代码检查不能否定原观察，也不能据此给所有状态移除增加跳回合规则。

4. 当前哪些已经做到，哪些还没有？

截至本次审阅，确定性战斗、公开查询、策略、Web 对局和 Reference App 均已有实现。疾速猛攻的狂暴例外、已知空间圈套导致的移动中止已有针对性修正。攻击序列公开查询提供显式选择的 v4 情景输出，私有候选策略已比较完整攻击与反击损失。预先固定配置、换边运行的64局对照中，两种策略各胜20/32，最终逐单位生命也相同，因此默认策略仍为 v55。开发场景的改善不替代独立对照。

接下来继续补足查询尚未知的反应、路线和状态分支，检查复杂混编与长期资源选择，并将玩家日记中的规则问题逐项对应到实现和回归。普通双击第二包、协助反击与致死先制反击的受伤集能漏算已经修正；凤凰普通横扫仍缺执行，奈拉队列连锁与妖精巨龙首击零伤的完整触发条件尚未定位。商业客户端独立取证和完整像素输入闭环仍各有缺口。

验收因此分层进行：资料核对说明规则依据；执行与回放测试说明实现是否自洽；公开信息隔离测试说明 AI 是否遵守信息限制；完整对局与真实界面检查说明产品是否可用。这几类证据互相补充。

界面验收也要经过实际动作。例如兵种因低落士气被迫跳过时，移动按钮已经不可用，但悬停仍可能按速度显示“本轮可达”。这会让一个几何上可达的位置看起来像当前合法行动。现在普通路径提示会先检查被迫跳过状态；英雄法术的目标提示继续使用自己的合法菜单。保存恢复则要真正重启服务，再比较行动单位、兵数、法力与日志，并继续到终局。

5. 让博客真正承担设计文档

S 系列正文维护“为什么这样设计、输入输出如何流动、当前采用什么决定”。代码仓库继续维护精确公开类型、字段语义和兼容测试。改变接口时先更新双方约定，再同步对应文章，避免博客和代码分别讲两套设计。

编号按主题留出空间：s00 是总览，s20 是规则执行，s40 是决策。后续可以在各组内增加具体算法或任务文章；只有实际需要解释的新设计才开篇，不为凑编号建立空页面。

每次更新至少检查：开头的结论是否仍成立；图的箭头是否与实现相符；例子是否来自当前规则；已完成与待验收是否分开；旧文章是否应指向新决定。失败实验保留有解释价值的结论，日常开发流水不必塞进正文。

下一篇：s20：一次攻击怎样正确结算并回放。跨模块公开接口的变更流程见模块边界设计。