探索与队伍回合战斗系统需求 v1

状态：draft_for_review

日期：2026-07-29

本轮范围：需求收敛，不授权实现

首个落地场景：闯荡 - 关中官道 后续消费者：比武、剧情战、护送战等

1. 一句话目标

把比武玩法中已经成立的“2D 戏台表现、按回合推进、关键时刻做选择”抽成共享战斗能力，先用于客栈员工组队探索，让员工养成、装备、羁绊与客栈经营形成可持续的玩法闭环。

这套玩法不是独立于经营系统的新游戏。玩家调谁离店、带什么装备、走多远、何时撤退，最终都要回到客栈的人手、收益、健康和长期成长上。

2. 第一性原则

2.1 玩家为什么要玩

玩家需要获得三种体验：

1. 看见员工真实出手，而不只是比较一个“队伍总战力”数字。
2. 用少量但有意义的决策改变战局，而不是每名角色每回合重复点技能。
3. 为探索付出真实的经营机会成本，并把战利品带回客栈继续养成。

2.2 设计约束

• 客栈经营仍是主循环，单场战斗不能过长或要求持续高频操作。
• 回合结果必须可读：敌人准备做什么、员工为什么先手、伤害和状态从何而来，玩家应能看懂。
• 自动模式应处理日常战斗，但关键风险必须交还玩家决定。
• 失败产生代价，但不永久死亡、不锁死主线、不让一次失误破坏存档。
• 首版复用现有闯荡的地图、难度、补给、掉落与结算；现有固定两人编队需要迁移为可变人数编队。

3. 非目标

首版不做以下内容：

• 卡牌构筑、抽牌与牌库循环。
• 战棋格子、站位移动、地形寻路。
• SLG 兵种生产、领地占领与大规模军团。
• 传统 JRPG 式每名角色逐个点选普通攻击和多个技能。
• PVP、实时联机战斗或排行榜数值对抗。
• 元素克制、复杂技能树、召唤物、永久死亡。
• 离线逐回合模拟。
• 额外招募雇佣兵、召唤物或临时单位扩充队伍。
• 首次迭代内一次性替换全部闯荡地图和全部比武逻辑。

因此，产品形态确定为：可变人数员工队伍、人数难度缩放、队伍指令制、半自动回合战斗。

4. 当前系统真值

截至本文编写时，现有闯荡已经具备：

• 5 张地图与 8 类探索节点。
• 固定 2 人编队。
• 三档难度、镖资、补给、羁绊、遗物与掉落。
• 路线偏好、半自动推进、暂停与撤退规则。
• 白天出发门禁、统一入场/结算和 runId 防重复。
• 员工等级、武学、智识与装备参与队伍战力计算。

现有战斗的本质仍是：

1. 计算队伍总战力。
2. 与敌方战力比较，并叠加概率判定。
3. 一次性返回胜负和文本结果。

它目前没有单位生命、行动顺序、技能冷却或气力、敌方意图、逐回合状态，也没有真正的战斗运行态。

4.1 复用与替换边界

| 现有能力 | 首版处理 | | --- | --- | | 地图与节点图 | 保留 | | 固定 2 人编队 | 改为可变人数，难度由人数缩放表控制 | | 出发门禁、难度与入场成本 | 保留 | | 行军精力、补给、遗物 | 保留并接入战斗 | | 普通战/Boss 一次性胜负判定 | 由回合战斗替换 | | 非战斗文本事件 | 保留 | | 自动路线与暂停 | 扩展为同时理解战斗状态 | | 统一结算与 runId | 保留，增加战斗结果输入 | | 比武状态机 | 暂不迁移，只作为表现与交互参考 |

5. 全局战斗框架

5.1 定位

建立一个与具体玩法无关的“战斗会话”。探索、比武和剧情只负责提供参战者、敌人、场景、特殊规则和结算去向；共享战斗层负责回合、行动顺序、伤害、状态、胜负与战斗 UI。

探索 / 比武 / 剧情事件
        |
        v
  创建战斗会话
        |
        v
意图 -> 指令 -> 行动 -> 回合结算
        |
        v
胜利 / 失败 / 撤退结果
        |
        v
返回各玩法自己的外层状态机

5.2 消费者边界

• 探索：首个正式消费者，使用队伍战、连续节点生命和撤退代价。
• 比武：后续消费者，可使用单挑、固定回合、剧情裁定等专属规则。
• 剧情战：后续可锁定角色、台词和胜负分支。
• 护送/守店：后续可追加保护目标或回合上限。

共享层不能直接依赖探索或比武的数据。各玩法通过适配层创建战斗，并在收到唯一一次结束事件后自行结算。

6. 探索核心循环

客栈整备
  -> 选择地图、难度、若干名员工、装备与补给
  -> 员工离店，探索开始
  -> 推进路线节点
  -> 遭遇战斗或文本事件
  -> 获得战利品、承受伤势、决定继续或撤退
  -> Boss / 主动撤退 / 全队倒地
  -> 回店结算
  -> 恢复员工、调整经营岗位、继续养成

核心张力来自“继续深入还是带着已有收益回店”，而不只来自单场胜负。

7. 出征编队与经营占用

7.1 编队规则

• 队伍人数不写死为 2 人，也不在共享战斗层设置固定人数上限。
• 当期可选上限由当前已解锁、可出征的员工数量自然决定；现有员工全部可加入时即允许多人队伍。
• 队伍至少需要 1 名员工。每名入队员工都必须已解锁、未重伤、未被其他互斥玩法占用。
• 编队数据、战斗状态和结算必须使用员工数组处理，禁止使用 memberA/memberB 或固定双槽字段。
• 装备、员工等级、武学、智识、健康、体力、羁绊和探索遗物共同形成战斗初始状态。
• 首个内部纵切片至少支持 1、2、3 人三种编队规模；对玩家开放前，所有可选员工都必须至少具备基础行动、1 个主动技能和 1 个被动特性。

7.2 人数难度缩放

人数增加带来的额外行动次数和技能组合，不通过硬性人数上限限制，而通过可配置数值表提高遭遇难度。

每个遭遇先读取基础敌人数值，再按实际出征人数应用 partySizeScale[partySize]：

最终敌方生命 = 基础生命 x hpScale[队伍人数]
最终敌方伤害 = 基础伤害 x damageScale[队伍人数]
最终控制抗性 = 基础控制抗性 x controlResistScale[队伍人数]
最终奖励 = 基础奖励 x rewardScale[队伍人数]

数值规则：

• hpScale、damageScale 和 controlResistScale 必须随队伍人数单调递增。
• 首版只调整数值，不因人数变化偷偷替换敌人、增加敌人波次或新增特殊机制。
• rewardScale 独立配置，可以随人数小幅增长，但增速必须低于总体难度增速。
• 更多员工还会带来更多离店岗位和装备占用，形成额外经营成本。
• 出发页必须显示“队伍规模修正”和修正后的危险等级，不能隐藏人数造成的难度变化。
• 具体倍率由数值模拟校准后写入数据层；逻辑层只读取配置并计算，不散落硬编码人数判断。
• 数值表结构必须允许未来新增员工后继续扩展，不能只写到当前人数后静默回退。

人数缩放的目标是控制额外行动经济，而不是保证“多一人必定更难通关”。阵容搭配和装备仍可产生优势，但相同遭遇的敌方数值难度必须随人数提高。

7.3 离店规则

• 从确认出发到回店结算，出征员工标记为“离店”。
• 离店员工不能同时上岗、参加其他出征或被派往互斥玩法。
• 出发确认页必须展示离店对当前经营的影响，例如岗位空缺和预估收益变化。
• 若经营系统暂不支持自动补位，必须明确提示，不静默换人。

这条规则是探索与客栈主循环发生关系的关键，不能退化为“角色分身外出”。

8. 战斗规则

8.1 单场流程

每回合固定经过以下阶段：

1. 回合开始：结算持续状态，生成敌方意图。
2. 意图展示：显示每名敌人本回合将要采取的行为及目标范围。
3. 玩家指令：选择 1 个队伍指令；气力满足时可额外指定 1 个角色主动技能。
4. 行动队列：根据速度和状态生成本回合行动顺序。
5. 逐个行动：角色执行基础行动、主动技能、受控或防御行为。
6. 回合结算：处理持续伤害、护盾、气力和倒地状态。
7. 结束判断：敌方全倒为胜利，我方全倒为失败；玩家也可在允许时撤退。

只有上一阶段完成后才能进入下一阶段。表现动画可以加速，但不能改变逻辑顺序。

8.2 队伍指令

首版固定三项，玩家每回合只选一项：

| 指令 | 玩家理解 | 机制方向 | | --- | --- | --- | | 猛攻 | 抢伤害、尽快结束 | 提高攻击倾向与破防能力，承担更高受伤风险 | | 稳守 | 扛住重击、保护队友 | 提高减伤、格挡或护援，降低输出效率 | | 应变 | 针对意图、争取先手 | 提高速度、闪避或打断机会，收益依赖敌方行动 |

具体倍率在数值设计阶段确定，需求层只锁定三者必须形成可理解的风险差异，不能变成同一按钮的轻微数值变化。

8.3 角色行动

每名员工首版拥有：

• 1 个基础行动：由角色定位与队伍指令共同决定。
• 1 个主动技能：消耗气力，由玩家点名触发或由自动策略触发。
• 1 个被动特性：持续体现角色性格或职业价值。
• 1 个倒地状态：生命归零后跳过行动，可被特定效果救起；首版不提供常规复活技能。

角色不需要玩家逐个点普通攻击。玩家做的是团队层决策，只在关键时刻使用角色技能。

8.4 行动顺序与可读性

• 行动顺序主要由速度决定，装备词条和状态可以修正。
• UI 在确认指令前展示本回合预计行动顺序。
• 同速时采用确定性规则，不能依赖玩家不可见的随机排序。
• 暴击、闪避、打断等随机结果必须在战报或飘字中标出来源。
• 随机种子属于战斗会话，读取存档不能通过反复重载无限改写同一回合结果。

8.5 战斗时长

| 遭遇类型 | 目标回合数 | 硬上限建议 | | --- | ---: | ---: | | 普通战 | 2-3 | 5 | | 精英战 | 3-5 | 7 | | Boss 战 | 5-7 | 10 |

达到硬上限仍未分胜负时进入“僵持结算”：根据剩余生命、任务目标和特殊规则裁定，不允许无限拖延。

9. 三类资源必须分开

| 资源 | 归属 | 用途 | 持续范围 | | --- | --- | --- | --- | | 行军精力 | 整支探索队 | 推进节点、触发现有补给/暂停规则 | 整次探索 | | 战斗生命 | 每名员工 | 承受伤害、决定倒地 | 同次探索跨战斗保留 | | 战斗气力 | 每名员工 | 释放主动技能 | 单场保留，战后部分恢复 |

规则要求：

• 战斗生命在同次探索的多个节点之间保留，休息和补给节点可恢复。
• 进入战斗时不能用“行军精力”直接替代生命。
• 战斗结束后，伤势会影响玩家是否继续深入。
• 回店结算时，剩余战斗生命和倒地次数折算为有上限的健康、体力或疲劳变化。
• 折算不得让角色因一次探索永久不可用。

10. 敌人与关卡

10.1 敌方最小数据

每名敌人至少包含：

• 身份、视觉资源与体型槽位。
• 生命、攻击、防御、速度。
• 基础行动与意图库。
• 目标选择规则。
• 掉落标签与遭遇等级。

10.2 敌方意图

首版支持五类可读意图：

• 普通攻击：显示目标或目标规则。
• 重击：高伤害，给玩家稳守或打断的理由。
• 防御：获得护盾、格挡或减伤。
• 控制：降低速度、封锁技能或施加负面状态。
• 支援：治疗、增益或召唤仅在后续需要时启用。

敌方意图不是装饰。玩家选择正确指令后，应能显著降低风险或提高收益。

10.3 难度

现有三档难度继续决定敌人强度、精英规则、奖励倍率和撤退代价。首版不再增加新难度维度。

难度不能只提高生命和攻击；中高难至少应改变一项行为，例如意图组合、技能频率或 Boss 阶段。

11. 胜利、失败与撤退

11.1 胜利

• 敌方全部倒地后，本场战斗立即停止接受操作。
• 结算战斗生命、气力、消耗品、掉落和节点进度。
• 普通战胜利返回路线；Boss 胜利进入地图结算。

11.2 失败

全队倒地时：

• 强制结束探索并回店。
• 保留部分已获得基础奖励，损失部分未保护战利品。
• 出征员工获得有上限的伤势或疲劳。
• 消耗已发生的时间、补给与经营机会成本。
• 不永久死亡、不删除装备、不阻断主线。

11.3 主动撤退

• 玩家可在回合指令阶段选择撤退。
• 撤退可以有被追击风险，但结果必须在确认前说明。
• 撤退成功保留的战利品高于战败，低于正常完成地图。
• Boss 特殊阶段可临时禁止撤退，但必须提前明确提示。

12. 自动战斗与暂停规则

12.1 模式

• 手动：每回合等待玩家选择队伍指令。
• 半自动：按预设策略选择常规指令，触发关键情况时暂停。
• 自动：用于已稳定通过的低风险内容；仍受强制暂停规则约束。

支持 1 倍和 2 倍速度。倍速只压缩表现时间，不跳过战斗事件或结算。

12.2 强制暂停

以下情况必须暂停并要求玩家确认：

• 首次遭遇新敌人或新 Boss 阶段。
• 任一队员进入濒危阈值。
• 任一队员倒地。
• 敌方出现重击、处决或不可逆特殊意图。
• 获得传奇级战利品后的路线选择。
• 路线岔路、补给耗尽、现有行军精力低于撤退阈值。
• Boss 战开始与战斗结束。

玩家可在设置中放宽部分普通暂停项，但“全队倒地、Boss 结束、路线岔路”不可关闭。

13. 外层探索与战斗的状态顺序

这是首版的硬性正确性要求。

exploration_node_entered
  -> combat_session_created
  -> combat_active
  -> combat_resolving
  -> combat_completed（仅一次）
  -> node_reward_applied（仅一次）
  -> route_choice_available 或 exploration_settlement

必须满足以下不变量：

• combat_active 或 combat_resolving 时，路线选项不可见、不可点击。
• 外层探索不能在战斗动画结束前仅凭计时器推进。
• 战斗只通过明确的 combat_completed 结果事件解锁后续节点。
• 同一战斗不能重复发放奖励、重复扣除资源或重复触发结算。
• 组件卸载、切换页签、倍速、暂停和恢复不能改变事件顺序。
• 存档恢复后只能回到一个明确阶段，不能同时显示战斗与战后选项。
• 战败或撤退后不能继续触发原节点的胜利选项。

14. 2D 戏台式战斗呈现

14.1 舞台布局

• 左侧：按实际人数自适应排列我方员工，使用前后错位的舞台站位但不形成战棋格。
• 右侧：1-3 名敌人或 1 名 Boss。
• 顶部：回合数、双方生命、气力、状态和敌方意图。
• 中部：角色关键姿势、位移、受击、格挡、倒地与技能特效。
• 底部：三项队伍指令、可用角色技能、自动、倍速和撤退。

14.2 资产策略

沿用比武验证过的“关键姿势切换 + 短位移 + 特效层”，不要求逐帧骨骼动画。

每名首版角色的最小姿势集：

• 待机。
• 普通出招。
• 主动技能。
• 受击。
• 防御/闪避。
• 倒地。

每类首版敌人至少具备待机、攻击、受击、倒地四态。素材保留角色原图，并从原图派生透明运行时切图；身份、服装和体型必须跨姿势一致。

14.3 反馈要求

• 伤害、治疗、闪避、暴击、格挡、状态获得使用不同但克制的视觉反馈。
• 当前行动者与目标必须始终可辨认。
• 动画尚未播放完时可以预计算结果，但不能提前展示外层选项。
• prefers-reduced-motion 下缩短位移和震动，不影响信息完整性。

15. 员工差异化方向

首版角色身份应来自现有性格和岗位，而不是只换数值：

| 员工 | 战斗方向 | 设计重点 | | --- | --- | --- | | 郭芙蓉 | 正面输出 / 破防 | 猛攻收益高，招式直接，风险也高 | | 白展堂 | 先手 / 控制 / 闪避 | 利用速度、点穴或打断处理危险意图 | | 吕秀才 | 应变 / 弱化 / 辅助 | 通过智识识破敌方、降低威胁 | | 李大嘴 | 承伤 / 补给 | 提供护援、恢复或探索续航 | | 佟湘玉 | 团队增益 / 稳定 | 调度队伍、降低失败与撤退损失 |

表中是能力方向，不是本轮锁定的最终技能名称和倍率。

16. 奖励与成长

16.1 奖励来源

• 普通战：基础银两、材料、低阶装备机会。
• 精英战：更高品质装备、遗物或路线资源。
• Boss 战：地图首通、稀有装备、声望与剧情信号。
• 无伤、低回合或特殊解法：用于评分和附加奖励，不作为主线硬门槛。

16.2 与现有系统联动

• atk / def / eff 参与战斗派生属性。
• critRate / critDmg / dodgeRate / speed 在回合层产生可见效果。
• 武学、智识和员工等级决定基础能力或技能效果。
• 羁绊可提供组合被动，但首版不新增复杂合击动画。
• 首版优先投放现有装备和材料，不新增独立“战斗币”。

16.3 防止纯战力碾压

队伍战力继续用于出发建议和遭遇预估，但不能直接决定胜负。合理应对意图、角色搭配、装备词条和撤退判断都应改变结果。

17. UI 信息架构

17.1 出发前

• 地图、难度与预估危险。
• 可增减的员工队列、当前人数和角色定位。
• 队伍规模造成的敌方数值修正与危险等级变化。
• 装备、补给与羁绊摘要。
• 员工离店造成的经营影响。
• 推荐战力只作风险提示，不显示虚假的精确胜率。

17.2 战斗中

• 第一优先级：敌方意图、我方生命、可用指令。
• 第二优先级：行动顺序、气力、状态。
• 第三优先级：战报与来源明细，可折叠查看。
• 移动端必须在首屏同时看到舞台、当前意图和三项队伍指令。

17.3 战斗后

• 本场胜负、回合数、伤势变化和消耗。
• 新获得战利品。
• “继续深入 / 使用补给 / 撤退回店”等外层决策。
• 战斗尚未完成时，这一层绝不能出现。

18. 概念数据模型

以下仅用于锁定职责，不等于最终 TypeScript 字段：

type CombatPhase =
  | 'intro'
  | 'intent'
  | 'command'
  | 'acting'
  | 'round_settlement'
  | 'completed'

interface CombatSession {
  id: string
  source: 'adventure' | 'tournament' | 'story'
  phase: CombatPhase
  round: number
  seed: string
  allies: CombatUnitState[]
  enemies: CombatUnitState[]
  intents: EnemyIntentState[]
  command?: TeamCommand
  actionQueue: CombatAction[]
  result?: CombatResult
}

interface PartySizeScale {
  partySize: number
  hpScale: number
  damageScale: number
  controlResistScale: number
  rewardScale: number
}

架构必须遵守项目三层约定：

| 层 | 建议目录 | 职责 | | --- | --- | --- | | 数据层 | src/data/combat/ | 类型、角色/敌人/技能/状态常量配置，不放函数 | | 逻辑层 | src/utils/combat/ | 回合状态机、派生属性、行动队列、伤害与结果计算 | | UI 层 | src/components/combat/ | 舞台、HUD、指令栏、战报与表现 | | 探索适配 | src/utils/adventure/ | 将探索队伍和节点转换为战斗输入，消费战斗结果 |

依赖方向为：玩法 UI -> 玩法逻辑/共享战斗逻辑 -> 静态数据。共享战斗层不能导入探索或比武 UI。

19. 首个实现切片

首个纵向切片只验证完整闭环，不代表正式内容量：

• 地图：关中官道。
• 队伍：可选择 1-3 人，内部验收使用郭芙蓉、白展堂和李大嘴。
• 员工能力：每人 1 个基础行动、1 个主动技能、1 个被动特性。
• 人数缩放：同一遭遇必须分别验证 1、2、3 人配置，敌方数值随人数单调提高。
• 指令：猛攻、稳守、应变。
• 遭遇：1 个普通战、1 个 Boss 战。
• 敌方意图：普通攻击、重击、防御三类。
• 状态：生命、气力、速度、暴击、闪避、格挡、倒地。
• 流程：出发、战斗、战利品、继续/撤退、失败、回店结算全部可走通。
• 自动化：半自动策略、2 倍速、关键节点暂停。
• 素材：三名员工完整最小姿势集；普通敌人与 Boss 各一套最小姿势集。

纵切片通过后，再补全 5 名员工和关中官道的正式遭遇池；未补齐前不替换现有玩家可见的全部闯荡战斗。

20. 分期路线

Phase A：共享战斗纵切片

• 建立数据、逻辑、UI 三层骨架。
• 完成确定性回合状态机与外层阻塞契约。
• 接入关中官道 1 个普通战和 1 个 Boss。
• 验证郭芙蓉、白展堂、李大嘴三名角色以及 1-3 人动态编队。

Phase B：探索正式化

• 补全 5 名员工的基础战斗身份。
• 补全关中官道遭遇池与难度差异。
• 接通跨节点生命、补给、伤势、掉落和经营占用。
• 经过玩家体验验收后替换该地图的旧胜负判定。

Phase C：内容扩展

• 按地图逐张迁移普通战、精英战与 Boss。
• 增加状态、敌方行为和遗物联动。
• 建立战斗数值模拟与掉落监控。

Phase D：其他消费者

• 在共享战斗层稳定后，再评估迁移比武。
• 比武保留剧情轮次、擂台热度、观众反馈和特殊结局等玩法专属状态。
• 后续接入剧情战、护送战或守店战时，不修改共享核心去迎合单一场景。

21. 验收标准

21.1 玩法闭环

• 玩家能选择不同数量的员工，看到人数难度修正和离店影响并确认出发。
• 同一遭遇使用 1、2、3 人队伍时，读取对应人数配置，敌方生命、伤害和控制抗性单调提高。
• 编队、行动队列、舞台布局和结算均不存在固定两人假设。
• 普通战和 Boss 都至少需要 2 个有意义的回合决策。
• 三项队伍指令在相同战局下产生可观察的不同结果。
• 装备速度、暴击、闪避等词条在战斗中真实生效且可追溯。
• 胜利、失败和撤退都能完成一次且仅一次的回店结算。

21.2 状态正确性

• 战斗未结束前，后续路线选项不会出现或被触发。
• 快速连点、2 倍速、切换页签、暂停恢复不会重复行动或重复结算。
• 存档恢复后只处于一个明确的战斗阶段。
• 同一 combatSessionId 只产生一个最终结果。
• 失败和撤退不会继续执行胜利节点。

21.3 节奏与易读性

• 普通战中位体验目标不超过约 45 秒，Boss 不超过约 120 秒。
• 玩家在下指令前能读懂敌方主要意图和预计行动顺序。
• 自动模式不会跨过强制暂停点。
• 桌面端与移动端均不遮挡角色、意图和指令。

21.4 经营联动

• 出征员工在探索期间不能同时上岗。
• 回店后伤势、疲劳、奖励和时间成本都有明确反馈。
• 失败有代价但不会造成不可恢复的存档破坏。

22. 风险与控制

| 风险 | 控制方式 | | --- | --- | | 战斗抢走经营主循环 | 限制回合数、默认半自动、保留离店成本与回店结算 | | 状态机与探索自动推进互相抢跑 | 战斗作为阻塞子状态，只接受唯一完成事件 | | 可变人数扩大首版内容量 | 纵切片只开放 1-3 人，但数据结构不写死上限 | | 人数越多导致行动经济失控 | 使用独立人数缩放表，并通过 1/2/3 人同场模拟校准 | | 角色姿势素材成本失控 | 使用关键姿势切换，不做逐帧全动画 | | 数值变成战力碾压 | 敌方意图、队伍指令和跨节点伤势共同决定结果 | | 旧存档不兼容 | 战斗会话使用可选运行态；非战斗旧存档按安全节点恢复 | | 比武逻辑被无限扩张 | 新建共享 combat 领域，比武后续通过适配器接入 |

23. 已拍板项与待拍板默认值

| 决策 | 当前定义 | 状态 | | --- | --- | --- | | 队伍人数 | 不固定为 2 人，由当前可出征员工数量决定 | 已拍板 | | 人数难度 | 人数越多，敌方难度数值越高，由数据表统一控制 | 已拍板 | | 操作粒度 | 每回合 1 个队伍指令，可追加 1 个角色技能 | 推荐默认值 | | 战斗生命是否跨节点 | 保留至回店，休息节点可恢复 | 推荐默认值 | | 出征是否占用客栈岗位 | 占用 | 推荐默认值 | | 离线战斗 | 首版不做 | 推荐默认值 | | 比武是否立即迁移 | 不立即迁移 | 推荐默认值 | | 首个纵切片角色 | 郭芙蓉 + 白展堂 + 李大嘴 | 推荐默认值 |

文档评审通过后，下一步应先输出“Phase A 实施切片 + 状态机测试矩阵”，再开始代码施工。

24. 关联现有文件

• docs/design/active/gameplay/战斗模式投放与界面设计-v1.md：战斗情节、收益、解锁和 UI 投放细化。
• src/components/AdventureTab.tsx：当前闯荡编队、推进和一次性战斗判定。
• src/data/adventure/：地图、节点、遗物、补给等静态数据。
• src/utils/adventure/partyPower.ts：现有队伍战力派生。
• src/utils/adventure/autoAdvanceLogic.ts：现有自动推进与暂停规则。
• src/utils/adventure/settlementLogic.ts：统一结算与重复保护。
• src/components/tournament/：比武的 2D 戏台 UI 参考。
• src/data/tournament/、src/utils/tournament/：比武专属数据和状态逻辑，不作为共享战斗核心继续扩张。
• docs/design/active/闯荡玩法未完成功能清单-v1.md：现有闯荡缺口。
• docs/design/active/产品需求总览-v1.md：全局产品边界。