docs: 更新文档内容，简化语言并修正格式

- 简化插件开发指南中的描述，移除冗余内容
- 调整部署文档中的Python版本说明
- 优化最佳实践文档的措辞和格式
- 更新性能优化文档，删除不准确的数据
- 重构核心概念文档，使用更简洁的语言
- 修正README中的项目描述和技术栈说明
- 更新快速上手文档，简化安装步骤
- 调整事件流转文档的描述方式
- 简化架构文档内容
- 更新指令处理文档，添加参数注入示例
- 优化单例管理器文档的表述

docs/core-concepts/performance.md

@@ -1,27 +1,27 @@
 # 性能优化详解
 
-NEO Bot 能跑这么快，不是因为运气好，是因为我们做了大量微小的优化工作。这里详细拆解每一个性能黑科技。
+NEO Bot 实际上是python，有人说用Java可能更好。。。嗯但是镀铬酸钾不会Java，镀铬酸钾只会python，所以只能用python了
 
 ## 1. Playwright 页面池 (Page Pool)
 
 ### 痛点
-传统的 Bot 发图流程：
+之前 Bot 发图流程：
 1.  用户发指令。
-2.  Bot 启动浏览器 (耗时 500ms+)。
-3.  创建新页面 (耗时 100ms+)。
+2.  Bot 启动浏览器。
+3.  创建新页面。。
 4.  渲染，截图。
 5.  关闭浏览器。
 
-这种模式下，发一张图至少要等 1 秒以上，并发高了直接卡死。
+这种模式下，发一张图至少要等 1 秒以上。。。
 
 ### 解决方案
 `BrowserManager` 维护了一个**页面池**。
 *   **启动时**: 自动预热 3 个页面（可配置），挂在后台待命。
-*   **运行时**: 需要截图时，直接从池里 `get_page()`，耗时 **0ms**。
+*   **运行时**: 需要截图时，直接从池里 `get_page()`
 *   **结束后**: 截图完成，页面执行 `about:blank` 洗白，然后 `release_page()` 放回池里。
 
 ### 收益
-图片生成响应时间从 **1.5s** 降低到 **0.2s** (仅渲染耗时)。
+我不知道快了多少，也没人测试，嗯
 
 ## 2. Jinja2 模板缓存
 
@@ -34,7 +34,7 @@ NEO Bot 能跑这么快，不是因为运气好，是因为我们做了大量微
 *   后续请求直接从内存拿对象渲染。
 
 ### 收益
-模板加载时间归零。
+省了硬盘IO
 
 ## 3. 全局 HTTP 连接复用
 
@@ -48,26 +48,26 @@ NEO Bot 能跑这么快，不是因为运气好，是因为我们做了大量微
 *   复用底层的 TCP 连接 (Keep-Alive)。
 
 ### 收益
-API 请求延迟降低 50% 以上，大幅减少服务器 TCP 连接数。
+实际上我也不知道，bot没高并发的实验。。。
 
 ## 4. orjson 极速序列化
 
 ### 痛点
-Python 自带的 `json` 库性能平平，特别是在处理 OneBot 这种大量 JSON 通信的场景下。
+Python 自带的 `json` 库性能好像不太好，特别是在处理 OneBot 这种大量 JSON 通信的场景下。
 
 ### 解决方案
-我们全面替换为 `orjson`。
-*   Rust 编写，速度是标准库的 10 倍以上。
+全面替换为 `orjson`。
+*   Rust 编写
 *   支持直接返回 `bytes`，减少内存复制。
 
 ## 5. Mypyc 编译
 
 ### 痛点
-Python 是解释型语言，执行效率天生低。
+Python太慢了。。。
 
 ### 解决方案
 利用 `setup_mypyc.py` 将核心模块编译为 C 扩展。
 *   `core/ws.py`: WebSocket 消息处理循环。
 *   `core/managers/*.py`: 事件分发逻辑。
 
-这些高频调用的代码变成了机器码，执行效率直逼 C++。
+这些高频调用的代码变成了机器码