摘要

2026-09-07，用户要求记录 Simulator（项目对游戏战斗规则的重新实现）当前所有未完成项，并判断近期交付变慢是否需要重构。本记录是一次检查点评估：把欠账整理为 B01–B10 十个工作包，用只读的行数 / 语法树统计找出复杂度集中处，结论是需要重构，但要围绕具体缺陷和职责分批做，不能把拆文件当作修规则。随后执行的第一批重构（专注触发模块提取）通过了新旧行为等价检查，但并未关闭任何已知数值缺陷。

要回答的问题

  1. 还有哪些工作没完成，各自的关闭条件是什么？
  2. 交付变慢是不是代码结构造成的？应该先重构什么？

方法

  • 只使用已有文字、截图、安装资料和已有录像，不操作商业游戏，不重启用户正在使用的本地服务。
  • 每个工作包写明当前依据和关闭条件；工作包之间不能相加成“bug 总数”。
  • 对当前工作树做只读行数与语法树统计。

结果：十个工作包（节选）

编号 内容 状态
B01 兵种固定等级 / 重抽整合 固定种子卡局已消失，原作候选池耗尽时的恢复规则仍未知；仍是发布前首要可玩性缺陷
B02 强力链接四维百分比 已确认数值缺陷，24 个严格预期失败
B03 三位一体与 Jack 组合 私有新版本已接线，公开版本仍有 4 个严格预期失败
B04 完整对局稳定性 自动化门禁当前无红灯，但不等于完整商业保真
B05–B10 复杂规则保真、施法交互、UI 可玩性、日志因果统计、AI 训练准入、完成度追踪 均部分完成，未关闭

复杂度最集中的几处：战斗主文件 26441 行（其中布阵构造函数 3189 行）、状态文件 11390 行（一个初始化函数 1671 行）、对战 AI 的单位能力评分函数 1021 行。更重要的观察是：临时英雄属性的“应用”和“到期”分散在不同路径，原始来源、当前面板和移除增量被分头维护，而这恰好与 B02 / B03 的缺陷边界重合——这比“文件太长”更值得重构。

为什么变慢（未量化）

代码职责集中会扩大一次修改的检查范围；近期很多工作是规则取证而非新增功能；部分测试用完整随机选秀去获得某个法术，规则一改就在无关步骤失败；全量测试本身耗时（例如 App + 集成全量约 317 秒）。没有编辑耗时的历史测量，因此不能说某个因素贡献了多少减速。

建议顺序

  1. 围绕 B02 / B03 统一临时英雄属性的来源与生命周期，复用现有组件，不另造一套属性引擎；修规则单独升版本，纯提取保持行为不变。
  2. 整理测试前置条件：展示类测试用明确合法的场景构造，另保留真实端到端轨迹。
  3. 按职责拆分网页会话的展示与存档。
  4. 逐项减少日志、UI、AI 对规则的重复解释。

首批重构结果

把战斗引擎中的“专注消耗效果”提取为独立模块，调用方只负责提交结果。16 项新测试通过；用 Git 中提取前的旧方法对照 12 局 / 60 次状态转移，菜单、完整事件和状态逐次相同。最终 95 通过 / 28 严格预期失败；Simulator + 集成全量 8853 通过 / 30 失败 / 3 错误 / 2 跳过 / 28 严格预期失败（202.65 秒），33 个失败编号全部在此前出现过。首次对照脚本因缺少常量导入失败，补齐后重新完整通过。

局限与结论

这是检查点，不是发布证书或完成百分比。重构等价性只证明行为没变，不证明符合原游戏；24+4 个已知数值缺陷原样保留。用户随后授权执行覆盖 B01–B10 的整体目标，后续进展在各工作包的生命周期文档中逐项更新。