eighthoursleep Unity 一级模块子模块 / 子系统总索引
目标
承接 unity-project-overview 的输出，对用户指定的一个一级模块（如"业务模块"）进行全面扫描，列出其下所有子模块/子系统，并重点梳理子模块/子系统之间的依赖关系，生成一份结构化的"子模块总索引"文档。
本文档只负责"子模块层"——列出一级模块下的子模块并刻画其依赖；某个子模块内部的核心逻辑由 unity-module-detail 技能深入解析，本文档不重复。
前置依赖
- 用户必须从
项目根目录/AboutMe/Overview.md的"一级模块列表"中选择一个模块名称（例如"业务模块"）。 - 若用户未提供，则读取
项目根目录/AboutMe/Overview.md的"一级模块列表"供选择。
输出文档结构（必须包含以下章节）
1. 文档头部信息
# [一级模块名称] 子模块梳理总索引
> 路径：[对应的物理目录路径]
> 文件总数：[该目录下 .cs/.lua 文件总数]
> 子模块数：[识别出的子模块/子系统总数]
> 上游模块：[依赖它的一级模块]
> 下游模块：[它依赖的一级模块]
2. 梳理方案说明
用 1-2 段话说明：本索引的划分原则（按玩法系统 / 功能边界 / 分层）、识别出多少个子模块、各子模块的定位。
3. 子模块 / 子系统清单（核心章节一）
将一级模块下的所有子模块识别出来，直接列出（如子模块较多可按功能轻量分组，但每个子模块必须有独立条目，不允许遗漏，也不允许有无归属的子模块）。
子模块识别判定规则（内置规范，随本技能分发）——权威母本维护于 ClaudeSkills/_shared/module-division-guide.md，本段为其随包副本；复制到其他环境后母本不可达时，按本段执行即可：
- 按逻辑职责划分，不按文件/类逐个拆。
- 同类前缀归并：类名前缀/命名空间相同的一组类 = 同一模块的不同部分，必须归并、不得拆多。如
BattleCtrl/BattleView/BattleData同属"战斗模块"。 - 判定优先级：逻辑职责 → 类名前缀/命名空间 → 目录结构（目录仅供参考）。
- 模块大类（标注属性，非重划分）：B=底层 / F=框架 / A=应用。
大类标注：每个子模块/子系统也需标注大类（B=底层 / F=框架 / A=应用）。同一业务一级模块内通常以 A 为主，但可能混入 F（如红点、配置）甚至 B（如通用网络）。
| 子模块/子系统 | 大类 | 对应目录路径 | 核心职责（一句话） | 涉及核心类/文件 | 依赖关系 |
|---|---|---|---|---|---|
| 登录模块 | A | Modules/Login/ | 登录鉴权与账号处理 | LoginCtrl.lua, LoginView.lua | 依赖全局数据（读写玩家信息） |
| 背包模块 | A | Modules/Bag/ | 物品存取与管理 | BagCtrl.lua, BagData.lua | 依赖登录（拿玩家 id） |
| 战斗模块 | A | Modules/Battle/ | 战斗表现与结算 | BattleMgr.cs | 依赖背包（读道具）、经事件解耦 |
| ... | ... | ... | ... | ... | ... |
依赖关系列：每条写明方向 + 内容（依赖对方哪些能力）+ 强度（强耦合 / 经事件 / 接口解耦），判定必须基于代码实际引用（require / using / 接口调用 / 事件注册），不得猜测。
4. 子模块间依赖关系
- 用箭头图呈现内部调用链，例如：
登录 → 全局数据 → 背包 → 战斗。 - 重点标注：循环依赖、单例贯穿引用、事件总线解耦等结构性特征。
给下游的一句话：3 中任意一个子模块（如战斗模块）就是 unity-module-detail 技能的输入项——选定后对该子模块的核心逻辑做深度解析。
5. 子模块通用架构模式
总结该一级模块下子模块的共性架构模式（通常 2-4 种），每种说明：模式名称、目录/文件组成、典型生命周期、适用场景。例如：
### 模式 A：完整 MVC（Ctrl + View + Data）
- 目录结构：xxx_ctrl.lua、xxx_view.lua、xxx_data.lua
- 生命周期：Awake → Open → Refresh → 用户操作 → Request → Handle → Refresh → Close
- 适用：大部分有 UI 的业务模块
### 模式 B：轻量页面（View + Data，无 Ctrl）
...
6. 网络同步 / 协议交互模式（如涉及）
描述该一级模块下各子系统的通用网络通信模式（协议收发流程、协议号定义位置、异常处理方式）。若不涉及网络，标注"无网络交互"。
7. 阅读建议
- 优先阅读：建议从哪几个子模块入手
- 核心/高复杂度子模块：哪些最复杂、值得深入
- 依赖关键节点：哪些子模块被大量依赖（改动影响面大），需重点关注
执行步骤
- 定位目标目录：根据用户选择的模块名称，从
项目根目录/AboutMe/Overview.md的一级模块列表中获取对应物理路径并验证。 - 扫描识别子模块：递归遍历目标目录，按逻辑职责 + 类名前缀/命名空间聚合识别出所有子模块/子系统（类名前缀相同的一组类归并为同一子模块，如
Battle*为一组、Login*为一组）。 - 识别子模块间依赖：对每一对子模块，检查代码中的 require/using/接口调用/事件注册，标注方向、内容、强度。
- 归纳架构模式：抽样阅读代表性子模块的代码结构，总结 2-4 种共性架构模式。
- 文档生成：
项目根目录/AboutMe/<一级模块名>.md（如"业务模块.md"）仅生成一个文件，按上述结构输出。
约束
- 本文档边界 = 子模块层：只列出一级模块下的子模块 + 子模块间依赖，不深入到某个子模块内部的核心逻辑（那是 module-detail 的职责）。
- 子模块清单必须完整覆盖，无遗漏、无无归属项。
- 归类与依赖要有据可依（基于实际目录、文件、类名、代码引用）。
- 只允许在
项目根目录/AboutMe/下生成 1 个<一级模块名>.md文件；同名的AboutMe/<一级模块名>/目录是 module-detail 与 core-flow-doc 的产出，不在本 skill 写入范围，不得创建、写入或删除。 - 同名冲突防护：生成前检查
项目根目录/AboutMe/<一级模块名>.md是否已存在。若已存在且非本模块产出，先向用户确认再覆盖，不得静默覆盖他人文件。module-detail 的产出已下沉到AboutMe/<一级模块名>/<子模块名>.md，与本文件不再可能同名。 - 下游依赖：第 3 节子模块清单表的"子模块名"与"对应目录路径"两列，是 module-detail 判定其输出目录
AboutMe/<一级模块名>/<子模块名>.md的依据，须逐行填写完整，不得留空。 - 中文行文约定：禁止长串的句子，或把几个句子连在一行/一段。必须一句话一行；即使描述一件事用了一个长句，也要拆成多行单句。表格单元格、步骤概括、职责边界、清单项的表述均适用。