摘要
承接实验 0338 与 0340 发现的召唤数量差异，本批在 Simulator（本项目的战斗规则引擎）中新增规则版本 Core385：星之子和原始残骸共用一个有版本的数量解析。原始残骸的系数由历史上的 2/2/2/4 修正为 1/1/1/2；百分比加成（例如 Legion 的 +30%）先在 32 位浮点（binary32）中运算，再舍入到最近整数、恰好一半时取偶数。例如有效咒力 4、熟练度 1、有 Legion 时，星之子由 15 变 16，原始残骸由 26 变 21。默认规则仍为 Core380，旧版本保留原含义。
要回答的问题
在当前安装版本的配置与原生算术证据下，两种英雄召唤的出生数量应该是多少？修正后会不会破坏甲壳、稳定、驱散等组合，或影响旧存档？
来源
0.81.04 / Steam 25672315 的完整配置、30 段数量算术、8 段百分比与舍入辅助函数、2 段咒力读取切片。本批重新读取本地安装并验证身份，没有改版本号绕过门禁。这是配置事实加有界原生推断；没有运行商业客户端，也不认证所有咒力写入、出生回调或其他召唤类型（Avatar、复制、暗影军队、召唤仪式、兵种召唤不变）。
方法
- 新增
resolve_summon_quantity，返回基础数量、最终数量和取整说明；执行和预览共用，底层复用已有 binary32 百分比算术。 - Game AI 的咒力估值和选秀属性投影传入所选目录，启用时策略 ID 追加标识，没有调整搜索或效用；公开战斗规则查询对无法确认的召唤估值仍标为部分已知，不偷读隐藏状态。
- 新启动的 Web 服务使用 385，恢复 380–385 存档时先选择原规则。
结果
人工复核的代表数字（均有 Legion，每次法力 300→280）：
| 场景 | 基础数量 | 最终数量 | 最终总生命 |
|---|---|---|---|
| 星之子 M1/SP1 | 9 | 12 | 420 |
| 星之子 M1/SP7 | 15 | 20 | 700 |
| 星之子 M1/SP17 | 25 | 32 | 1120 |
| 原始残骸 M1/SP4 | 16 | 21 | 1050 |
| 原始残骸 M4/SP4 | 20 | 26 | 1300 |
| 原始残骸 M1/原 SP11、敌方 −10%、学派 +6 | 28 | 36 | 1800 |
最后一行先把主属性 11×0.9 舍入为 10，再加学派 6 得有效咒力 16；出生后不重复套用减益或学派加成。
- 80 个数量边界、48 个学派/主属性组合，以及重复施法、半整数上下舍入、非法数值、版本互拒等检查；修正后数量还与两层甲壳、稳定、反魔法和紫龙两种移除能力组合验证。
- 导出 128 条受控历史、2944 次操作，其中 24 条有逐行动完整快照；自然 AI 对战 0 局。
- 五模块全量（1004.93 秒）：31569 通过、96 失败、7 准备错误、22 跳过、152 严格预期失败；与上一批逐节点比较，新增坏节点 0、结果变化 0。87 份 380–384 归档录像按原引擎重放，哈希完全相同。
失败与负结果
初次测试夹具错误保留：四级直接牌实际没有正概率，改用一级；当前存活数应读 count 而非死亡后仍保留的 quantity。没有放宽规则门禁。
局限
关闭的只是两种英雄召唤的数量偏差；九头蛇、增攻时序、复制体生命周期等仍在，Simulator 整体正确性未得到证明。
结论与下一步
数量修正已作为 Core385 上线并兼容旧存档；后续增攻时序见实验 0322。
Comments