eighthoursleep Unity 客户端项目架构总览（通用）
对任意一个 Unity 游戏客户端仓库，产出一份精简、可扫读的架构总览文档。目标是"一页看懂这个项目"：不追细节，只交代骨架，让新同事几分钟建立整体认知。
触发与目标
用户想要的是项目级骨架认知，不是某个模块或引擎功能的深挖。你的产出应回答四件事：
- 这是什么项目（引擎/平台/类型/核心目标）
- 代码怎么分层、目录放哪层、各自职责
- 程序启动后发生了什么（启动链路）
- 有哪些必须知道的约定与风险
第一步：快速侦察（不要逐文件读）
用轻量手段建立全局认知，先看骨架再看关键点。探查顺序（命中即明确，未命中就跳过）：
- 入口：全局搜启动相关脚本（
GameApp、App、Main、Bootstrap、Entry、场景内第一个MonoBehaviour）。确认 bootstrap 从哪里创建插件/模块系统。 - 架构模式：看业务脚本命名/目录是否出现
Proxy/Mediator/Controller/Command（PureMVC 或类 MVC）、System/Component（ECS）、Module/Plugin（自研模块系统）。据此判断组织方式。 - 热更新：搜
ILRuntime、IFix、HybridCLR、xLua、puerts、Reflection/Assembly.Load。区分"热更层"与"原生层"的代码分界。 - 资源管理：看是否有
Addressables/AddressableAssetSettings、AssetBundle、XAsset、ScriptableObject $(Resources)等。判断主方案与兜底。 - 配置/数据：看是否有
Excel/Json/ScriptableObject/Binary/SQLite的读取服务。判断配置读取方式。 - 网络协议：搜序列化库（
protobuf/proto/sproto/MessagePack/JsonUtility）与传输（Tcp/Udp/WebSocket/HTTP）。 - 目录结构：
Assets一层子目录名 + 每个目录顶层内容，据此判定分层。 - 分层依据：看
.asmdef（程序集引用关系），据此判断依赖方向是否单向、有没有明确的层边界。
优先使用项目配置的知识图谱/索引工具（若有）做搜索，减少逐文件扫描。整个侦察阶段控制在合理步数内，够用就停。
第二步：按以下模板产出（中文）
引擎: Unity <版本>（<渲染管线>） 项目类型: <平台/类型> 框架: <架构/框架一句话，如 PureMVC + 自研插件框架> 热更新: <热更方案；无则写"无"或"纯原生">> 资源: <资源管理主方案（+ 兜底）> 配置/协议: <配置读取方式；协议序列化方式>
1. 项目概述
两三句话：这是什么游戏、核心目标、为什么这么设计（如"通过热更实现在线更新""框架与业务分离"）。玩法类型一句话点到即可，不要展开成玩法清单。
2. 架构分层与目录速查
一张表，列：层级 | 目录 | 职责。 按"从入口到底层"或"从业务到框架"的依赖方向排列；每层给一行负责说明。层数通常 3–5 层： 入口/应用层 → 业务层 → 客户端组件/框架层 → 底层（第三方库/原生插件）→ 资源/配置目录（StreamingAssets/Config 等）。
3. 启动流程
一个代码块内画启动链路，用缩进箭头表达调用顺序，例如：
入口 → 创建插件/模块系统 → 注册各层插件
└─ 初始化核心服务
└─ 加载热更代码 → 业务入口 → 启动业务层
只画骨架，不写细节。列到业务层真正开始跑为止。
4. 开发约定与注意事项
- 3–6 条"必须知道的约定/红线"（短句，如"代理层禁止调用 UI/Unity API""框架层改动谨慎"）
已知风险
- 2–4 条已知风险/注意事项（短句）。
篇幅控制（硬性）
- 目标行数 60–110 行，最多不超过 120 行。
- 用表格和紧凑列表，不用整段长文；每格/每点尽量一行。
- 不逐模块展开、不列 API 清单、不复制代码、不写各目录下的每个文件。
- 写完后自查行数；过长就压缩表格和要点。
第三步：输出文件
把结果写入文件：
- 默认写
Overview.md（仓库根目录）；若仓库已有同名文件，写<项目名>-Overview.md避免覆盖。 - 文件顶部标题为通用 H1：
# 代码架构总览（不要带具体项目名，例如不要写成# IG-Client — …；项目名放进引言元信息块里体现）。 - 写完后在对话里打印一段简短摘要（2–4 行：项目一句话 + 架构 + 几个关键点），不要把整篇文档再贴一遍。
关于"核心服务"节
传统 Overview 里的"框架核心服务"表往往针对特定自研框架，通用 skill 不保留专列的核心服务小节（各项目框架各异，名称不通用，且会稀释精简度）。有价值的核心服务信息改在"架构分层表"或"路径/命名速查"里顺带体现即可。