摘要
结论先行：Simulator 复用的单位是“边界清楚的机制”，生物、法术、状态只是用强类型配置去选择机制和填参数；凡是做不到配置化的地方，必须被显式列出，而不是假装已经数据驱动。
《英雄无敌：上古纪元》Arena 里有 141 种可上场生物、数百种法术与状态，同一种效果（扣血、施加状态、反伤）会从普通攻击、反击、主动技能和法术等多个入口进入。若每个入口各写一份，修好一处另一处仍会出错。本文描述当前 Simulator 的做法：内容层用冻结的定义对象（UnitAbilityDefinition、UnitPassiveDefinition、StatusDefinition 等）描述“是什么”，机制层用共享处理器描述“怎样执行”，调度层决定“何时执行”。
2026-10-07（Core407）的反伤案例中，把反伤接入已有的天堂之刃追加处理器后，四类攻击入口的漏算一次修复（敌人最终生命 835 → 800 或 760）。2026-10-15 新增只读导出 export_creature_definitions：157 个生物（141 Arena、13 旧网页来源、3 仅召唤）各得一份确定性的定义；103 个主动技能中 62 个由类型化效果程序执行、20 个只施加状态、21 个仍是专用解析代码；另有 18 项按生物 ID 写死的机制连同代码位置被列出，并由扫描源码的守卫测试防止新增“隐形特例”。
局限：导出是现有注册表的视图，不是新的规则真值；软件测试证明导出与引擎一致，不证明与商业游戏一致；英雄／军队上下文、状态内容和少数安装数据中的效果尚未导出。
1. 问题：为什么“共用一个函数”不够？
结论：需要复用的是带有准入、记账和顺序约定的完整机制；只复用一个伤害公式，问题会换个地方重新出现。
一支部队受到攻击后，可能反伤敌人、恢复自己的生命，再触发另一个魔法。普通攻击、反击、先制反击、警戒和主动技能都可能走到这里。2026-10-07 发现的缺陷很典型：携带“复仇”和“天堂之刃”的单位反伤敌人时，旧实现漏掉了天堂之刃的追加伤害。公式本身没有错，错在“反伤之后应该调用谁”这件事散落在各个入口里。
另一个更长期的问题来自 2026-10-15 用户的要求：每个生物都应当能用一份配置描述。理由有两条：一是代码复用，新生物若只组合已有机制，就不应该再写新分支；二是机器学习，学习型 AI 若只看到生物 ID，就只能逐个记忆，若能看到“基础数值＋机制类型＋绑定参数”，不同生物之间才可能共享知识。
这两件事的共同前提是：先知道现在到底有多少是配置、有多少是代码。本文前半部分说明已有的共享机制设计，后半部分说明怎样把全部生物的现状导出成一份可核验的清单。
2. 方法：内容、机制和调度三层，加上四类注册表
结论：内容层只选机制和填参数，机制层只执行一种语义，调度层只管顺序；三层之间通过有版本号的注册表连接。
2.1 三层职责
内容配置回答“这个东西是什么”。一项法术包含目标类型、消耗、熟练度参数和效果种类；一个生物把主动能力绑定到这些效果，并给出消耗和倍率。装备、英雄特技和持续状态也有各自的强类型定义。“强类型”指字段含义和允许值明确，错误配置在构造时就被拒绝。
机制回答“这类效果怎样执行”。伤害要处理屏障、实际扣血和受伤状态；治疗要区分补回残血与复活；位移要检查落点和经过的场地。多个内容复用同一机制，只是参数不同。
调度回答“现在执行哪一步”。伤害之后先反伤还是先反击，来源死亡后哪些已开始的效果还能继续，都属于顺序问题。两个效果各自的公式正确，不代表交换顺序后仍然正确。
flowchart LR
GK[Game Knowledge: reviewed facts] --> C[Content definitions and bindings]
C --> R[Versioned registries]
R --> M[Shared mechanisms: damage packet, status apply/remove, heal, move]
M --> S[Scheduler: windows, order, RNG, transaction]
S --> O[Next state, events, receipts]图 1：规范事实由 Game Knowledge 保存，Simulator 定义是对已审阅事实的可执行绑定；注册表把内容交给机制，调度把机制放进一次有顺序的动作。箭头表示依赖和执行流，并非每一步都是独立模块。
图 2（2026-10-07 原图）：配置告诉执行器采用什么语义；时序决定何时读取状态。
我们没有把所有生物、魔法和装备塞进一个充满可选字段的大类。它们处于同一内容层，但允许不同的声明结构。
2.2 四类注册表
当前有四个与生物直接相关的注册表，每个都有自己的 schema 版本号，并被写进带哈希的规则清单（ruleset manifest）。
- 主动技能定义
UnitAbilityDefinition：描述技能本身，例如目标类型、目标与效果作用范围的策略编号，以及可选的五类类型化程序——效果程序、位移程序、资源程序、执行程序和尸体程序。 - 主动技能绑定
UnitAbilityBinding：把某个生物绑定到某个技能，并给出这个生物特有的参数（所需集能次数、倍率、安装版槽位序号等）。同一技能被多个生物使用时，定义只有一份，参数在绑定里。 - 被动定义
UnitPassiveDefinition与被动绑定：被动是“满足条件就自动生效”的规则，例如受到射击攻击时最终伤害乘以某系数。每个被动定义通常只填一个具名规则字段（如受伤触发、回合开始治疗、死亡转化），并带有自己的触发事件。 - 状态定义
StatusDefinition：描述一种持续效果的语义——正负极性、生命周期、参数键、修正种类、免疫与禁用规则、是否可驱散、是否可缩短持续时间，以及叠加策略。
主动与被动的区分很重要：主动技能都在本单位自己的行动窗口中使用，唯一的门禁是 BattleEngine.unit_ability_activation_block_reason（集能不足、被状态禁用、资源来源不可用等）；被动没有“使用”这一步，由各自规则声明的触发事件驱动。把两者混成一类，会让“何时生效”变成需要靠代码分支猜测的事情。
2.3 类型化效果程序
效果程序是一串有类型的操作，例如造成伤害、施加状态、移除状态、减少反击次数。每个操作有自己的规格类、计划类和回执类，伤害公式也是有类型的规格（按普通攻击缩放、固定值、按集能缩放的固定值）。数值可以来自绑定参数，或来自行动时快照的部队数量等。
它不是一门通用脚本语言。设计上刻意保持封闭：新内容若能用已有操作表达，就只加配置和绑定测试；若引入新触发时机、新目标语义或新状态转移，才新增一个有名字的操作或机制，并配上交互测试。复杂的多阶段攻击、死亡转化等，宁可保留可审查的专用处理器，也不塞进配置里的任意脚本。
2.4 状态与叠加策略
同一种状态被再次施加时怎么办，是最容易出错的地方之一。StatusStackPolicy 只有三个值：
refresh_matching_source：同一来源再次施加时刷新已有层；extend_matching_source：同一来源再次施加时延长持续时间（可带安装版的最大持续时间上限）；independent：每次施加都是独立的一层。
状态定义还默认“失败即关闭”：新状态必须显式声明可缩短、可驱散，才会被相应法术处理，避免未来的光环或无限期效果被意外移除。
2026-10-15 的一次修复说明了叠加策略为什么必须精确。研究用搜索 AI 试探“吞噬圣杯”时，两个敌人身上来自同一光织者的“内在光辉”（施加于第 5 回合和第 4 回合）被复制到施法者，它们是同一个状态编号；旧实现按单位顺序先复制第 5 回合那份、再复制第 4 回合那份，于是被判为“同来源延长时间倒流”，合法菜单给出的动作却执行报错。修复后，同编号快照按施加回合从早到晚复制，其它顺序不变（来源：simulator/docs/HANDOFF.md，2026-10-15 上午条目）。
2.5 英雄覆盖：在上下文里求值，不改全局定义
以“绝望”为例：当前 Simulator 中，英雄 necro_hero_15 的特技配置忽略这一法术的选取免疫，并提供额外 4 点咒力及无冷却。这是当前实现的绑定描述，本文没有在商业客户端逐条重新认证。
不需要为这个英雄复制一套“绝望执行器”。每次施法时，从基础法术定义和英雄特技求出有效的目标条件、咒力与冷却，再交给原来的目标筛选和效果机制。两个常见错误要避免：一是开战时直接修改全局法术定义，导致另一方或下一场继承特权——定义是不可变对象，双方和跨局隔离有测试；二是把“忽略选取免疫”理解成“忽略一切免疫”——ignore_cast_immunities 只作用于选取（cast）通道，阶级、机制、效果、伤害通道各自独立。
2.6 伤害包：共用扣血，不等于所有效果都当扣血
一次独立处理的伤害称为一个“伤害包”。共享函数 resolve_damage_packet 接收已经算好并获准执行的伤害，负责拦截、生命上限截断、实际伤害账本、受伤接收和受伤后的状态处理，返回扣血后与状态变化后的两个快照。它有意不负责目标准入、免疫、倍率和后续订阅者顺序。
还要区分“实际扣血为 0”和“没有发生伤害事件”：屏障完全挡住一个包，与允许零生命损失却仍有受伤事件的状态并不等价。直接清除召唤物也不是伤害——先造成 75 伤害再移除剩余召唤物，账本应记录 75 伤害和一次清除，而不是把归零的全部生命都写成伤害。
3. 方法：CreatureDefinition 只读导出（2026-10-15）
结论：先做一个“视图”，让每个生物的配置与写死部分都能从一个入口读出；运行时行为一行不改。
3.1 为什么先做只读导出
用户提出“所有生物都用配置描述”后，simulator1 把方案送 GPT 审阅（r10，回复已核验并保存在项目的讨论记录里）。GPT 的主要意见是：
- 赞成混合架构“配置＋注册 handler”：简单的加减属性、免疫、施加状态用通用效果程序；多阶段攻击、死亡转化、特殊行动调度继续用专用 handler，多个生物复用同一机制时由 handler 接收不同绑定参数；不要为了消灭少数没有效果程序的技能去发明一门复杂的规则 DSL。
- 统一描述必须保留作用对象（receiver scope）。此前化身召唤的错误，正是把只作用于召唤物的继承修正当成了英雄自身修正。
- 第一项交付应是不改变运行时行为的只读导出，而且导出必须是当前注册表的视图，不能成为需要人工同步的第二套规则真值；所有写死的特殊行为都要能在清单中定位。
- 对机器学习：仅有生物向量不够，学习型 AI 更需要合法动作的结构化表示，学习“观察×合法动作”的打分，而不只是扩大生物嵌入。此前行为克隆在移动动作上 0/478 的正确率就是警告。
据此确定的优先级是：先完成当时正在进行的 0068 评测与 Core452 修复，再做只读导出，之后才是逐项替换写死机制和从配置生成特征；通用效果程序重写与图编码暂缓。
3.2 接口
新模块 simulator/src/olden_era_ai/simulator/creature_definitions.py（提交 f6302c4c7）由 Simulator 拥有，加入 olden_era_ai.simulator 的公开名称，但不加入 rules_query。公开名称有：
export_creature_definitions(catalog)：返回整份文档；只接受当前版本的BattleCatalog，旧存档读取用的 Core448–451 目录子类会被拒绝，因为技能与被动注册表是全局、当前的，用旧目录导出会贴错版本标签。creature_definition(catalog, troop_id)：返回单个生物，与整份文档中的对应项由同一构造函数生成；未知 ID 抛KeyError。creature_definitions_canonical_bytes与creature_definitions_sha256：规范字节与内容哈希。HARDCODED_TROOP_MECHANICS：写死机制清单，每项的生物 ID 和参数在调用时从真实常量读取。
导出函数是纯函数、不缓存，返回新建的普通字典与列表，不与注册表对象共享引用。仓库中不提交生成的 JSON 文件，以免它变成第二个真值来源。
3.3 每个生物包含什么
| 部分 | 内容 | 来源 |
|---|---|---|
| identity | ID、阵营、阶级、可用性（arena／legacy_web_source／summon_only）、升级族、原生地形 | 目录模板与当前补丁数量表 |
| base_stats | 33 个模板字段，名称与值原样 | TroopTemplate 全部字段减去放在别处的 10 个 |
| installed | 安装版攻击模式 ID、移动方式、补丁前数量（仅 Arena） | 带哈希的游戏快照 |
| abilities | 槽位序号、是否已对照安装数据审阅、完整定义、绑定参数、执行方式摘要、激活前置状态 | 主动技能注册表 |
| passives | 完整定义、规则字段、触发事件、是否与安装免疫重复 | 被动注册表 |
| immunities、attack_geometry | 免疫规则；已审阅的普通／范围攻击模式、攻击方增益、备用攻击 | 模板与 Game Knowledge 门面 |
| summoned_by | 能召唤出它的法术、技能、场地效果、死亡转化 | 各注册表反查 |
| hardcoded_mechanics、known_gaps | 本生物涉及的写死机制及参数；已知缺口 | 写死清单与自动计算 |
| provenance | 模板来源、补丁覆盖、技能来源字段 | 模板与补丁表 |
技能的执行方式分三类：有任一类型化程序则为 typed_program；技能解析器是 apply_status.v1 则为 status_definition（只施加一个状态）；其余为 resolver_code（专用代码）。
文档顶层还记录 schema 版本 creature-definitions.v1、从目录实时读取的规则版本、五个目录哈希、各注册表 schema 版本，以及“约定”字段，写明哪些东西没有导出。目录哈希只并列记录，不作为内容哈希，因为它们不覆盖 Python 绑定注册表和代码合成的模板。
3.4 确定性与哈希
规范字节是排序键、紧凑分隔、UTF-8、禁止 NaN 的 JSON。序列化遇到数据类、枚举、布尔、有限浮点、列表、集合（排序后输出）和字符串键映射时有明确规则，遇到其它类型（包括路径）直接报错。内容哈希是去掉 content_sha256 键后规范字节的 SHA-256。机器相关的绝对路径和时间戳一律不输出。
3.5 写死机制清单与守卫
“写死”指运行时行为按生物 ID 选择，而不是由注册表数据驱动。清单把它们分为五种：Simulator 分支、按生物键控的 Simulator 常量表、Game Knowledge 中按生物键控的已审阅事实、公开投影拒绝、代码合成的模板。每项给出 模块:限定名 形式的代码位置。
两个守卫测试防止清单过时：T17 用 ast 扫描 simulator/src 与 game_knowledge/src 中等于某个生物 ID 的字符串常量，按（文件、作用域、生物 ID）记录，要求每处要么在某项机制的代码位置中，要么在测试内的分类表中（注册表数据、校验固定值、哈希载荷、选秀表、探针夹具、仅审计、非战斗、标签而非身份）；出现未分类的新字面量或分类表里的陈旧条目都会失败。T18 检查九个按生物键控的常量只在清单列出的位置被引用。
4. 验证设置
结论：检验分三层——机制层用固定预期，导出层与运行时对象逐项比对，再加少量真实行为抽查；都不涉及商业游戏实测。
- 规则版本：反伤案例在 2026-10-07 的 Core407 下完成；导出在 2026-10-15 凌晨按 Core452 实现并提交；本文第 5 节的注册表计数在 2026-10-15 当天的工作区（规则版本标签
battle-core.v453-2026-10）上读取。 - 反伤案例：普通护卫在两个回合中合法施放两个法术，关闭普通反击以免混淆反伤与反击；咒力固定为 7，敌人起始生命 1000。
- 导出一致性：测试不使用黄金文件，而是与运行时对象比较——目录模板、注册表、新建的单位、带哈希的规则清单、Game Knowledge 门面。新建单位时，每个生物单独放在蓝方，对面放一个固定对手（骷髅；测骷髅时换天使），无英雄。
- 行为抽查：B1 对每个技能绑定构造“集能恰好够”和“差一次”两种开局（对手为先攻 1、无技能的活化盔甲，保证该生物先行动）；B2 检查受到远程与近战普通攻击时的伤害倍率；B3 用新建吸血鬼打新建农民（1000 伤害、近战）和骷髅（有吸血免疫）。
- 门槛：导出与运行时对象逐字段相等，不允许任何不匹配；两个已知缺口集合被固定为确切的 7 个和 13 个生物，变化必须人工复核。
5. 结果
结论：反伤一次修复覆盖四类入口；导出与引擎逐项一致，并把仍靠代码实现的部分量化出来。
5.1 历史结果：反伤触发天堂之刃（2026-10-07，Core407）
二级复仇在咒力 7 时造成 60 + 15 × 7 = 165 反伤；一级天堂之刃追加 35，二至四级追加 75。
| 场景 | 反伤 | 追加 | 敌人最终生命 |
|---|---|---|---|
| 旧实现，四个熟练度 | 165 | 遗漏 | 835 |
| 一级天堂之刃 | 165 | 35 | 800 |
| 二至四级天堂之刃 | 165 | 75 | 760 |
修复放在共享反伤处理器中：一个正数、符合条件的反伤包结束后调用已有的天堂之刃处理器，普通、主动、反击、先制和警戒共用同一出口；天堂之刃自身的追加伤害不再触发自己。回执用嵌套关系保存追加子包，不复制进外层普通追加列表，避免伤害账本或集能重复计算。当时按完整测试文件合并结果为 106 个文件 3995 项通过、12 项因 Windows 符号链接权限跳过；74 份受控战斗历史（440 次操作）精确回放，独立 JSON 核算 182 个伤害包、38 个嵌套追加全部自洽。来源：docs/handoff/SIMULATOR_REFLECTION_FOLLOWUPS_2026_10_07.md。
5.2 注册表规模（2026-10-15 工作区读取）
| 注册表 | 条目 | 说明 |
|---|---|---|
StatusDefinition |
289 | 叠加策略：refresh_matching_source 217、extend_matching_source 36、independent 36；schema status-registry.v189 |
UnitAbilityDefinition |
103 | schema unit-ability-registry.v103，效果程序 unit-ability-effect-program.v11 |
| 主动技能绑定 | 156 | 分布在 98 个生物上；95 条有安装数据审阅记录，61 条为 Simulator 本地 |
UnitPassiveDefinition |
49 | schema unit-passive-registry.v37；38 个恰好填一个具名规则字段，11 个没有 |
| 生物×被动对 | 122 | 分布在 91 个生物上；93 对有安装数据审阅记录，29 对为 Simulator 本地 |
来源：simulator/src/olden_era_ai/simulator/statuses.py、unit_abilities.py、unit_passives.py 及导出文档的 counts 字段；审阅与本地拆分见 simulator/docs/creature-definitions-design-2026-10-15.md 第 0 节。
5.3 导出总览
| 项目 | 数值 |
|---|---|
| 生物总数 | 157：Arena 141、旧网页来源 13、仅召唤 3（lava_larva、summoned_avatar、undead_peasant） |
| Arena 升级族 | 基础 57、_upg 42、_upg_alt 42 |
| 技能执行方式（103 个技能） | 类型化程序 62、只施加状态 20、专用解析代码 21 |
| 写死机制 | 18 项 |
| 已知缺口：安装版有非单体攻击模式但无已审阅模式 | 7 个生物（引擎按普通单体路径处理） |
| 已知缺口：安装版有备用攻击但没有执行器接纳 | 13 个生物 |
| 补丁前安装数量与当前数量不同 | 141 个 Arena 生物中 102 个 |
| 技能字母序与安装槽位序不同 | 21 个生物（导出按槽位序） |
来源：simulator/docs/creature-definitions-design-2026-10-15.md 第 0 节；提交 f6302c4c7 说明。
5.4 写死机制清单
| 机制 | 种类 | 类别 | 涉及生物 |
|---|---|---|---|
| attack_vampirism | 常量表 | 攻击效果 | 7 |
| soul_assimilator | 分支 | 伤害修正 | hive_queen ×3 |
| blasphemous_adoration_ally_scope | 分支 | 目标选择 | hive_queen_upg |
| hydra_own_field_object_attack_blocked | 分支 | 目标选择 | hydra ×3 |
| hydra_public_wave_not_projected | 公开投影拒绝 | 攻击几何 | hydra ×3 |
| regal_hydra_on_hit | GK 已审阅事实 | 攻击效果 | hydra_upg_alt |
| phantasm_nightmares_on_hit | GK 已审阅事实 | 攻击效果 | flicker_upg_alt |
| phoenix_wisp_battle_start | GK 已审阅事实 | 其它 | phoenix_upg |
| phoenix_heart_rebirth_spawn | 分支 | 其它 | phoenix_upg |
| summon_swarm_larva | 分支＋合成模板 | 其它 | lava_larva |
| summoned_avatar | 分支＋合成模板 | 其它 | summoned_avatar |
| unspeakable_double_turn_self_dispel | 常量表 | 其它 | 由常量决定 |
| druid_upg_alt_army_spell_mastery | 分支 | 光环 | druid_upg_alt |
| beloved_piglet_transform_target | 分支＋合成模板 | 其它 | undead_peasant |
| creature_specialist_family | 常量表 | 英雄上下文属性修正 | 84 |
| reviewed_basic_attack_geometry | GK 已审阅事实 | 攻击几何 | 12 |
| reviewed_ranged_area_geometry | GK 已审阅事实 | 攻击几何 | olgoi_upg_alt、medusa ×3 |
| reviewed_attack_dealer_buffs | GK 已审阅事实 | 攻击效果 | 13 |
来源：simulator/src/olden_era_ai/simulator/creature_definitions.py 中的 HARDCODED_TROOP_MECHANICS；设计稿第 4 节。设计时的扫描在 68 个（文件、顶层作用域）组合中发现生物 ID 字面量，未进入上表的都已在守卫测试中分类。
5.5 一致性与行为抽查
| 检查 | 结果 |
|---|---|
| 新建单位与导出基础数值（全部 157 个） | 0 个字段不匹配；唯一差异士气等于“模板士气＋阵营士气修正”后截断，测试按此公式比较 |
| 导出与带哈希规则清单中的技能／被动注册表 | 相等（T5） |
| 技能激活门禁，集能恰好够 | 142 可用、9 被状态禁用（恰为需要先觉醒的 9 个绑定）、5 资源来源不可用（无英雄时的英雄法力类资源） |
| 技能激活门禁，差一次集能 | 141 集能不足、8 被状态禁用、5 资源来源不可用 |
| 受到普通攻击的伤害倍率 | esquire 族 3 个生物远程 0.7、近战 1.0，其余全部 1.0，与导出的被动规则逐一相符 |
| 吸血 | 吸血鬼对农民 1000 伤害：比例 5000 基点、请求回复 500；对骷髅被“目标机制免疫”拒绝；远程攻击不产生回执 |
| 确定性 | 两次导出字节相同；PYTHONHASHSEED 取 0 和 1 的子进程哈希相同；改动天使攻击 +1 后内容哈希改变而目录哈希不变 |
当前两个测试文件共收集 29 个测试函数（主文件 24、守卫 5）。提交说明记录：与公共接口边界测试合跑共 59 项通过，Ruff 无报错。来源：simulator/tests/test_creature_definitions.py、simulator/tests/test_creature_definitions_guards.py、设计稿第 0 节、提交 f6302c4c7。
6. 讨论
结论：已确定的是“导出忠实反映了 Simulator 当前的执行结构”；尚未验证的是“这种结构等于游戏本身”以及“它能帮 AI 学得更好”。
已确定（有测试或记录支撑）
- 导出中的数值、技能、被动、免疫与运行时对象逐项一致，并与带哈希的规则清单一致；技能门禁、受击倍率和吸血三类行为与导出的描述相符。
- 约五分之四的主动技能（62＋20＝82/103）已由类型化程序或单一状态定义执行，剩余 21 个仍是专用代码；这为“哪些生物新增时只需配置”给出了可量化的边界。
- 写死特例是有限且被列出的 18 项，新增未分类的生物 ID 字面量会让测试失败。
- 反伤一次修复覆盖四类入口，说明“修共享处理器而不是逐入口补丁”在该案例中有效。
未验证的解释
- 21 个专用解析技能里，有多少其实可以用现有操作表达，目前只是推测；GPT 也提醒不要为此发明 DSL。
- 用导出生成的生物特征是否改善学习型 AI，尚无正面证据。0069 的动作编码器已用导出中的生物静态特征（每个动作 351 维），但模仿 T 策略的 0229 测试集完整菜单移动 Top-1 只有 0.137，低于冻结门槛 0.25；新特征相对 v1 消融提升 0.112 属探索性结果。GPT r15 之后学习型 AI 已暂停（来源：
simulator/docs/HANDOFF.md）。 - 共享处理器在致死、治疗和清除同时发生时的全部订阅者相对顺序，仍未经原生调用链认证。
共享也有代价：一个共享算子写错，会让多个内容一起出错。因此代码行数减少本身不是正确性证据，机制测试、绑定测试和组合测试缺一不可。
7. 局限与威胁
结论：导出是“对代码的诚实描述”，不是“对游戏的完整描述”。
- 视图而非真值：导出读取的是 Simulator 的实现；若实现与游戏不符，导出会忠实地复制这个错误。逐字段相等只证明两者同步，不证明正确。
- 未导出的内容：英雄与军队上下文（英雄调整后的属性、专长加成、虫巢数量、灵魂同化参数、原生地形加成、阵营士气修正、召唤数量）；战斗中的单位状态；状态定义的具体内容（只导出状态编号）；需要战斗状态才能求出的接收者集合；安装数据里 7 处未执行的受伤修正和 5 个被动注册表之外的光环（计划在 v2 处理）。
- 旧网页来源的 13 个生物：它们被标记出来，但不能当作安装版事实；旧 JSON 中 20 个被忽略的键也未导出。
- 守卫的盲区：字面量扫描只能发现字符串常量形式的生物 ID；按命名后缀（
_upg、_upg_alt）推导的约定被记在“约定”中而不是写死清单里，通过计算拼出的 ID 也不会被扫描到。 - 版本漂移：设计调查时
battle.py正有未提交改动，所以代码位置一律用限定名而非行号；导出在 Core452 下提交，本文计数在 Core453 工作区读取。内容哈希不在测试中固定，因为每次合法的注册表修改都会改变它。 - 软件与实战：所有结果都是 Simulator 内的软件检查，没有对商业游戏做新的对照；反伤案例的 35／75 追加有有界原生证据，其余组合（例如龙的炙焰护体与天堂之刃同时存在）只是标注清楚的合成测试，不代表玩家一定能获得该配装。
8. 结论与后续工作
结论：先把“共享了什么、没共享什么”变成可读、可测的清单，再逐项迁移；不要先造一个包办一切的效果引擎。
后续按 GPT r10 与当前交接的优先级推进：
- 逐项替换写死机制（小范围、每项独立验收）：先迁移能描述为范围模板、朝向和筛选条件的特殊攻击几何（导出中已列出 7 个缺口）；再迁移作用范围、接收对象、触发时机和数值都明确的简单固定光环；再迁移能用现有结构表达的攻击附带效果；死亡转化、召唤、额外行动和多阶段攻击放在最后，因为它们最近仍在暴露正确性问题，重写会带来事件顺序和历史回放兼容风险。
- 导出 v2：读取安装数据中的受伤修正与光环，导出状态定义内容，让“未表示”的列表变短。
- 共享伤害入口继续收敛：2026-10-07 的设计列出攻击波次、周期伤害、地表和处决仍有独立编排，应逐个接入共享结算并保留中间快照和独立账本；本文未重新清点这些入口在 Core453 下的现状。
- 机器学习：若恢复，应同时使用生物机制表示与合法动作表示，而不是单独扩大生物嵌入。
每一步若改变公共语义，规则版本与消费者一起更新；旧版本存档继续由明确的读取器按原语义回放。
相关实验报告
共享机制上的具体修正与复核，多数在 0300–0399 段有单独报告：
- 共享受伤结算与伤害包：0309 受伤结算的共享实现、0322 每个真实受伤包立即增攻、0308 恢复伤害测试执行。
- 同一机制从多个入口进入：0319、0320 皇家九头蛇命中减益的屏障、免疫与混合目标；0315–0317 生齿不息与护盾、反击、驱散。
- 召唤与临时单位：0339 两种英雄召唤的数量修正、0341 召唤法术的咒力组合、0338 召唤与甲壳、驱散、0343 原始残骸复制体、0349 化身召唤的继承系数。
- 状态与持续时间：0342 技能持续时间与重施、0345 七个原生状态的面板属性查询、0346 虫巢“众志”计数。
- 生物定义导出的下游使用：0069 每个合法动作的结构化特征（见 s50）。
前一章 s20 讲一次行动怎样按序结算，下一章 s22 讲怎样测试这些机制的组合；总体地图见 s00。
9. 复现方式
在 olden-era 仓库根目录、使用核心 Python 环境（下面的 python 指它）：
# 导出与守卫测试（数秒级）
python -m pytest -p no:cacheprovider \
simulator/tests/test_creature_definitions.py \
simulator/tests/test_creature_definitions_guards.py
# 查看导出的总数与某个生物（Windows 需设置 UTF-8 输出）
PYTHONIOENCODING=utf-8 python -c "
from olden_era_ai.simulator import export_creature_definitions, creature_definition
from olden_era_ai.simulator.battle_catalog import BattleCatalog
doc = export_creature_definitions()
print(doc['ruleset_version'], doc['counts'], len(doc['hardcoded_mechanics']))
print(creature_definition(BattleCatalog.load(), 'vampire')['hardcoded_mechanics'])
"接口合同与字段来源见 simulator/docs/creature-definitions-design-2026-10-15.md；实现见 simulator/src/olden_era_ai/simulator/creature_definitions.py。共享机制的原始设计见 docs/architecture/SIMULATOR_MECHANISM_REUSE.md 与 docs/architecture/SIMULATOR_EFFECT_PIPELINE_DESIGN.md；反伤案例的测试与输出见 docs/handoff/SIMULATOR_REFLECTION_FOLLOWUPS_2026_10_07.md。
10. 更新记录
2026-10-15（夜）：新增“相关实验报告”与前后章节链接；删去本地路径。
2026-10-15：改写为完整设计报告并结束草稿状态。新增四类注册表、类型化效果程序、状态叠加策略的说明，新增吞噬圣杯同编号状态复制顺序修复的例子，新增 CreatureDefinition 只读导出（157 个生物、技能执行方式 62/20/21、18 项写死机制、确定性字节与内容哈希、守卫测试）及 GPT r10 意见；当前注册表计数按 Core453 工作区读取。原第 5 节“复用边界”与第 6 节“如何继续”并入讨论、局限和后续工作。
2026-10-14（规则、回放与 AI 研究进展）：近期规则修复继续放在共同语义层：最终攻击／防御求值取不低于 0 的结果，同时保存原始减益和来源；回合开始临时部队到期后的胜负，交由 Simulator 现有权威结算处理，AI 和界面不再各自补一条“判胜”公式。共享也必须保留历史语义：Core449 修正生命周期终局边界，显式 Core448 存档仍走受限旧时序入口，事件和终态继续严格比对。这个兼容分支不意味着接受未知版本，也不意味着必须复制整份引擎；复用应同时考虑执行、公开查询和保存读取者。
2026-10-14（交接更新）：七个已观察状态的面板查询获有限修复（见 实验 0345）；伤害倍率、追加攻击与面板攻防不是同一通道，未知状态继续阻断。该轮仅更新本地来源；最近工作总览见从已读属性到有来源的战斗解释，软件回归、曝光训练样例和独立实战验收分别报告。
2026-10-07：初版（R1）记录 Core407 实现：三层职责、绝望的英雄覆盖、伤害包边界、反伤触发天堂之刃的修复。R1 接受外部 GPT 审阅；R1.1 由 Codex 依据反馈澄清职责和证据范围。配套设计以 SIMULATOR_MECHANISM_REUSE.md 和 SIMULATOR_EFFECT_PIPELINE_DESIGN.md 为准。
Comments