docs: 更新文档内容并优化语言风格

重构所有文档内容，使用更简洁直接的语言风格
更新架构、插件开发、部署等核心文档
优化代码示例和图表说明
统一术语和格式规范

docs/core-concepts/singleton-managers.md

@@ -1,92 +1,80 @@
 # 核心概念：单例管理器
 
-在 `core/managers/` 目录下，存放着一系列全局唯一的**管理器（Managers）**。它们是 NEO Bot Framework 功能的核心实现，负责处理事件、管理权限、加载插件等关键任务。
+`core/managers/` 这地方，放的都是些**管事的（Managers）**。它们是 NEO Bot 的权力核心。
 
-理解这些管理器的职责，有助于您更好地利用框架提供的能力，并进行更高级的开发。
+## 为啥非得是单例 (Singleton)？
 
-## 设计模式：单例 (Singleton)
+说白了，就是**全局独一份，省事**。
 
-框架中所有的管理器都采用了**单例设计模式**。这意味着在整个应用程序的生命周期中，每个管理器类只会存在一个实例。
+*   **到处都能用**: 在插件里 `import` 就行，不用传来传去。
+*   **数据不打架**: 权限、命令这些东西，全局就一份，改了都认。
+*   **省资源**: Redis 连接池、浏览器这种东西，开一个就够了，多了浪费。
 
-**为什么使用单例？**
+我们专门在 `core/utils/singleton.py` 搞了个基类，继承一下就行。
 
-*   **全局访问点**: 任何模块（尤其是插件）都可以方便地导入并使用同一个管理器实例，无需手动传递。
-*   **状态共享**: 管理器内部维护的状态（如已注册的命令、用户权限列表）是全局共享和一致的。
-*   **资源统一管理**: 对于像 Redis 连接这样的资源，单例模式确保了全局只有一个连接池，避免了资源的浪费和冲突。
+## 认识一下这帮“官”
 
-框架在 `core/utils/singleton.py` 中提供了一个 `Singleton` 基类，所有管理器都继承自它，以轻松实现单例模式。
+### 1. `CommandManager` (外号 `matcher`)
 
-## 核心管理器介绍
+*   **怎么找**: `from core.managers.command_manager import matcher`
+*   **管啥**:
+    *   **总调度**: 所有消息都得从它这过一遍，它说了算分给谁。
+    *   **发牌的**: 你用的 `@matcher.command()` 这种装饰器，就是它发的。
+    *   **对号入座**: 消息来了，它负责对一下，看是哪个插件的活儿。
 
-### 1. `CommandManager` (全局实例: `matcher`)
+写插件天天都得跟它打交道。
 
-*   **文件**: `core/managers/command_manager.py`
-*   **全局实例**: `from core.managers.command_manager import matcher`
-*   **核心职责**:
-    *   **事件处理中枢**: 它是事件流转的核心，负责接收所有类型的事件，并将其分发给相应的底层处理器。
-    *   **装饰器提供者**: 为插件提供了 `@matcher.command()`, `@matcher.on_notice()` 等一系列装饰器，用于注册事件处理器。
-    *   **指令匹配**: 内部维护了一个指令注册表，能够根据消息内容匹配到对应的处理函数。
+### 2. `PermissionManager` (外号 `permission_manager`)
 
-`matcher` 是插件开发者最常打交道的管理器。
+*   **怎么找**: `from core.managers.permission_manager import permission_manager`
+*   **管啥**:
+    *   **划分三六九等**: `ADMIN`, `OP`, `USER` 这些等级都是它定的。
+    *   **记小本本**: 谁有啥权限，都记在 `core/data/permissions.json` 里。
+    *   **会自动变通**: 查权限的时候，它会把 `AdminManager` 里的超管也当成 `ADMIN`。
 
-### 2. `PermissionManager` (全局实例: `permission_manager`)
+### 3. `AdminManager` (外号 `admin_manager`)
 
-*   **文件**: `core/managers/permission_manager.py`
-*   **全局实例**: `from core.managers.permission_manager import permission_manager`
-*   **核心职责**:
-    *   **权限定义与检查**: 定义了 `ADMIN`, `OP`, `USER` 等权限等级，并提供了 `check_permission` 方法来验证用户权限。
-    *   **数据持久化**: 负责从 `core/data/permissions.json` 文件中加载和保存用户权限设置。
-    *   **与 `AdminManager` 联动**: 在检查权限和获取所有用户权限时，会自动合并机器人管理员（来自 `AdminManager`）的数据，将其识别为最高权限 `ADMIN`。
-
-### 3. `AdminManager` (全局实例: `admin_manager`)
-
-*   **文件**: `core/managers/admin_manager.py`
-*   **全局实例**: `from core.managers.admin_manager import admin_manager`
-*   **核心职责**:
-    *   **管理员管理**: 提供 `add_admin`, `remove_admin`, `is_admin` 等接口，用于管理机器人的超级管理员列表。
-    *   **数据同步**: 实现了内存、`core/data/admin.json` 文件以及 Redis 缓存之间的数据同步，确保管理员列表的一致性和高效查询。
+*   **怎么找**: `from core.managers.admin_manager import admin_manager`
+*   **管啥**:
+    *   **钦差大臣**: 专门管机器人的超级管理员，增删改查都在这。
+    *   **三级缓存**: 内存 -> Redis -> 文件，又快又稳。
 
 ### 4. `PluginManager`
 
-*   **文件**: `core/managers/plugin_manager.py`
-*   **核心职责**:
-    *   **插件加载**: 负责扫描 `plugins/` 目录，导入所有合法的插件模块。
-    *   **元数据提取**: 读取插件文件中定义的 `__plugin_meta__` 字典，用于 `/help` 指令等功能。
-    *   **热重载支持**: `load_all_plugins` 函数被 `main.py` 中的文件监控服务调用，以实现插件的热重载。
+*   **管啥**:
+    *   **拉人头**: 启动时把 `plugins/` 目录下的插件都拉进来。
+    *   **热更新**: 你改了插件代码，它负责重载，不用重启机器人。
 
-此管理器通常在后台工作，开发者较少直接与其交互。
+这家伙一般在幕后，你基本不用找它。
 
-### 5. `RedisManager` (全局实例: `redis_manager`)
+### 5. `RedisManager` (外号 `redis_manager`)
 
-*   **文件**: `core/managers/redis_manager.py`
-*   **全局实例**: `from core.managers.redis_manager import redis_manager`
-*   **核心职责**:
-    *   **连接管理**: 负责初始化和管理与 Redis 服务器的异步连接。
-    *   **提供实例**: 通过 `redis_manager.redis` 属性，为其他模块提供一个可用的 `redis` 客户端实例。
+*   **怎么找**: `from core.managers.redis_manager import redis_manager`
+*   **管啥**:
+    *   **接线员**: 管着和 Redis 的连接。
+    *   **提供工具**: 你要用 Redis，就找它要 `redis_manager.redis`。
 
-### 6. `BrowserManager` (全局实例: `browser_manager`)
+### 6. `BrowserManager` (外号 `browser_manager`)
 
-*   **文件**: `core/managers/browser_manager.py`
-*   **全局实例**: `from core.managers.browser_manager import browser_manager`
-*   **核心职责**:
-    *   **浏览器生命周期管理**: 负责 Playwright 浏览器的启动和关闭。
-    *   **页面池 (Page Pool)**: 维护一个预热的浏览器页面池（默认 3 个）。
-    *   **资源复用**: 提供 `get_page()` 和 `release_page()` 接口，让渲染任务直接复用现有页面，避免了每次创建新页面的巨大开销。
+*   **怎么找**: `from core.managers.browser_manager import browser_manager`
+*   **管啥**:
+    *   **浏览器司机**: 负责启动和关闭 Playwright。
+    *   **开个页面池**: 提前准备好几个空白页面（默认3个），你要用直接拿，省下几百毫秒的启动时间。
+    *   **循环利用**: 用完记得还回来 (`release_page`)，建设节约型社会。
 
-### 7. `ImageManager` (全局实例: `image_manager`)
+### 7. `ImageManager` (外号 `image_manager`)
 
-*   **文件**: `core/managers/image_manager.py`
-*   **全局实例**: `from core.managers.image_manager import image_manager`
-*   **核心职责**:
-    *   **图片渲染**: 基于 Jinja2 模板和 Playwright 浏览器生成图片。
-    *   **模板缓存**: 自动缓存编译后的 Jinja2 模板，避免重复 IO 和解析。
-    *   **资源调度**: 自动从 `BrowserManager` 借用和归还页面，开发者无需关心底层浏览器操作。
+*   **怎么找**: `from core.managers.image_manager import image_manager`
+*   **管啥**:
+    *   **美工**: 把数据塞进网页模板，然后用浏览器咔嚓一下截图。
+    *   **记性好**: 模板用一次就记住，下次直接用缓存。
+    *   **自动借还**: 它会自动找 `BrowserManager` 借页面，你只管喊一声 `render_template` 就行。
 
-## 如何在插件中使用管理器
+## 咋用？
 
-在您的插件中，只需通过 `import` 语句导入相应管理器的全局实例即可使用。
+简单粗暴：`import` 就完事了。
 
-**示例**: 在插件中检查用户是否为管理员。
+**举个栗子**: 查查这人是不是管理员。
 
 ```python
 # plugins/my_plugin.py
@@ -97,11 +85,10 @@ from models.events.message import MessageEvent
 
 @matcher.command("secret")
 async def secret_command(event: MessageEvent):
-    # 使用 permission_manager 检查用户权限
+    # 只有管理员能看
     is_admin = await permission_manager.check_permission(event.user_id, ADMIN)
-    
     if is_admin:
-        await event.reply("这是一个只有管理员能看到的秘密。")
+        await event.reply("这是秘密！")
     else:
-        await event.reply("抱歉，您没有权限执行此命令。")
+        await event.reply("你没权限看这个。")
 ```