伟大航路仍未闭合的规则表 ¶

文档目的 ¶

本表用于收口当前反推工作中“已经知道大方向，但还没有足够证据锁死细节”的部分。

和 reverse-engineering-gaps.md 的区别是：

• reverse-engineering-gaps.md 更偏缺口分类。
• 本文更偏实现决策，明确哪些可以直接做，哪些必须参数化，哪些属于高风险待确认。

分类说明 ¶

• 可直接实现
  • 客户端和配置证据已经足够，可以直接落服务端规则。
• 需要参数化
  • 能做，但不宜写死，应作为配置或策略函数。
• 高风险待确认
  • 当前证据不足，贸然写死容易与真实口径偏差较大。

一、可直接实现 ¶

1. 五岛阶段骨架 ¶

可直接实现内容：

• S7 起切换伟大航路
• 岛屿顺序：
  • 灰盐岛
  • 青铜岛
  • 秘蓝岛
  • 紫青月宫
  • 黄金天宫

依据：

• 客户端规则文案
• SecondSeasonStart = 7
• 客户端阶段枚举

2. 前四岛周赛到月赛的周级门槛 ¶

可直接实现内容：

• 灰盐岛：
  • 首战场前 8 / 4 / 4 升进阶赛
  • 进阶赛第 4 周后前 15 进月赛
  • 月赛总积分前 960 升青铜岛
• 青铜岛：
  • 第 4 周后前 16 进月赛
• 秘蓝岛：
  • 第 4 周后前 16 进月赛
  • 月赛前 10 升月宫
• 月宫：
  • 第 4 周后前 16 进月赛
  • 月赛前 10 升黄金天宫

依据：

• 客户端规则图文
• 语言表 TopTips
• config1.json 中 legionWarThird* 常量

3. 黄金双败主线 ¶

可直接实现内容：

• 黄金总量 80
• 胜者线 4 -> 2 -> 1
• 败者线 2 -> 2 -> 1
• 总决赛 1
• 失败两场淘汰至秘蓝岛

依据：

• 黄金阶段页面结构
• 黄金提示文案
• 黄金专项接口字段

4. 基础战场字段集 ¶

可直接实现内容：

• phase
• type
• legionWarType
• subType
• legionWarMapType
• battlefieldId
• battlefieldNumber
• signupStartTime
• signupEndTime
• readyTime
• startTime
• endTime
• sid
• domainName
• canEnterWar

依据：

• 客户端 GDBattlefieldInfo

5. 基础资格约束 ¶

可直接实现内容：

• 报名时锁成员
• 锁成员不可代表其他俱乐部参赛
• 月赛成员资格至少要求：
  • 前置比赛参与
  • 个人积分大于 0
  • 指定时间点仍在俱乐部内
• 黄金阶段存在“登岛成员”资格限制

依据：

• 客户端规则文案
• 黄金页面锁成员提示

二、需要参数化 ¶

这些内容已经能做，但不建议直接写死逻辑。

1. 青铜岛升秘蓝岛动态名额 ¶

当前可知：

• 名额是 500 / 380 / 300
• 与 blueRiseRound / blueRiseCount 相关

建议：

• 做成配置驱动
• 不要在业务代码里写死 if-else 常量链

2. 岛屿总池规模 ¶

当前可知：

• 秘蓝岛 500
• 月宫 200
• 黄金 80

建议：

• 做成赛季配置
• 因为未来可能调规模或分赛段

3. 分组数量与并组阈值 ¶

当前可知：

• 黄金的组数较明确
• 前四岛总体量能推测，但未完全锁死

建议：

• 抽成“分组策略”
• 输入：
  • 岛屿
  • 阶段
  • 当前可参赛俱乐部数
• 输出：
  • 组数
  • 每组人数
  • 并组策略

4. 晋级/淘汰阈值 ¶

例如：

• 周赛前 16
• 月赛前 10
• 青铜动态总榜前 500/380/300

建议：

• 统一走配置
• 服务端逻辑只消费阈值，不嵌名额常量

5. 阶段时间窗 ¶

当前客户端保留旧周赛模板：

• 18:00 报名截止
• 20:00 开战
• 提前 5 分钟进场

建议：

• 先用统一模板实现
• 但时间窗本身做成配置
• 避免后续黄金阶段或高级阶段变更时重写逻辑

6. 回流来源集合 ¶

例如：

• 青铜岛接灰盐岛升入和秘蓝岛淘汰
• 秘蓝岛接青铜晋升、月宫淘汰、天宫归来

建议：

• 抽成每岛来源集合配置
• 服务端只按“阶段结束结果 -> 目标池”分发

三、高风险待确认 ¶

这些内容目前最容易与真实规则不一致，后续实现时必须留出修正空间。

1. 前四岛的精确分组算法 ¶

当前不清楚：

• 每岛每月到底分多少组
• 组大小是否恒定
• 不足一组时怎么并组
• 候选排名如何和回流来源共同排序

风险：

• 这会直接影响谁能进月赛、谁会掉级

2. 岛屿积分表 ¶

当前不清楚：

• 第 1~20 名分别加多少岛屿积分
• 周赛和月赛积分表是否相同
• 黄金阶段的积分和普通岛屿积分是否共口径

风险：

• 若积分表错，周赛后到月赛的资格线都会偏掉

3. 同分裁定规则 ¶

当前不清楚：

• 小组同分按什么排
• 总榜同分按什么排
• 是否使用：
  • 占城积分
  • 历史最高排名
  • 总战力
  • 报名顺序

风险：

• 排行和晋级线都会产生争议

4. 月赛资格成员的继承链 ¶

当前不清楚：

• 灰岛进阶赛成员资格是否沿用周赛名单
• 青铜/秘蓝/月宫月赛是否沿用第4周周赛名单
• 天宫归来后是否重新锁成员

风险：

• 资格越权或误拒绝

5. 黄金淘汰后的名次分配 ¶

当前只知道：

• 败者赛淘汰俱乐部先获排名
• 总决赛决出剩余排名

但不清楚：

• 第2周败者淘汰对应哪些名次段
• 第3周败者淘汰对应哪些名次段
• 第4周败者淘汰对应哪些名次段

风险：

• 奖励和荣誉发放会错

6. 奖励发放口径 ¶

当前不清楚：

• 岛屿积分奖励
• 俱乐部排行奖励
• 个人排行奖励
• 晋级通知
• 淘汰通知
• 首占奖励

在五岛体系下的完整发放矩阵

风险：

• 发奖重复、漏发、错发

7. 异常分支处理 ¶

当前不清楚：

• 人数不足时是不开赛、并组还是降级
• 创建战场失败后如何回滚
• 已报名俱乐部解散如何处理
• 赛季切换时未结束战场如何收口

风险：

• 线上一致性问题

四、实现建议 ¶

第一层：先按确定信息做骨架 ¶

优先实现：

• 五岛阶段切换
• warType/mapType 动态调度
• 战场查询字段完整化
• 黄金双败主线
• 基础报名与资格锁定

第二层：把不确定部分做成参数 ¶

必须参数化：

• 分组数
• 每组晋级线
• 总榜晋级线
• 回流来源集合
• 时间窗
• 动态名额切换

第三层：把高风险部分显式标记 ¶

实现时建议单独留：

• TODO(confirmed-rule)
• TODO(reward-matrix)
• TODO(tie-breaker)
• TODO(bracket-ranking)

避免后续误以为已经完全复刻。

五、当前最值得继续补的证据 ¶

如果还要继续反推，最优先的是：

1. 岛屿积分配置或奖励配置
2. 分组算法配置
3. 黄金淘汰名次段配置
4. 月赛资格成员锁定规则

六、结论 ¶

现在已经足够支撑“一版结构正确、可配置、可落地”的服务端设计。

真正还不能写死的，不是大方向，而是：

• 分组
• 积分
• 同分
• 奖励
• 异常处理

这些必须保留参数化和修正规则的空间。