diff --git a/05Kapi_项目业务全貌与重构决策分析.md b/05Kapi_项目业务全貌与重构决策分析.md
index 417f0db..ffce357 100644
--- a/05Kapi_项目业务全貌与重构决策分析.md
+++ b/05Kapi_项目业务全貌与重构决策分析.md
@@ -376,3 +376,169 @@ Baji_Rtc_Toy 项目目前 internal SRAM 仅剩 **44KB**（参见 Baji 项目 `do
 而 Kapi_Rtc_toy 项目 internal SRAM 余量 **80-130KB**，启用 AFE 后仍有 **50-100KB 安全余量**。
 
 **结论**：未来如要验证 ESP-SR AFE 启用方案，**应该优先在 Kapi 项目实验**，跑通后再回到 Baji 评估资源能否承载。
+
+---
+
+## 12. 🔥 关键发现：Kapi 流畅的真正原因（2026-05-14 实测对比新增）
+
+### 12.1 同 Wi-Fi 实测对比铁证
+
+用户提供同一份日志，同时包含 Baji 和 Kapi 在**同一台 Wi-Fi 路由器**下的 RTC 通话数据：
+
+| 项 | **Baji_Rtc_Toy**（卡顿） | **Kapi_Rtc_toy**（流畅） |
+|---|---|---|
+| SSID / BSSID | airhub / 70:2a:d7:85:bc:eb | airhub / 70:2a:d7:85:bc:eb |
+| RSSI | −31~−33 dBm | −32~−38 dBm |
+| 设备 MAC | d0:cf:13:03:bb:f0 | 20:6e:f1:b9:af:a0 |
+
+**完全同一台路由器、同一信号强度**，Kapi 信号甚至更弱（−38）。
+
+### 12.2 RTC jitter buffer 抖动指标对比（**Kapi 完胜 8 倍**）
+
+| RTC 内部抖动指标 | Baji（同 WiFi） | Kapi（同 WiFi） | 差距 |
+|---|---|---|---|
+| **reor**（RTP 包乱序）| 826 ~ 1790 | **0 ~ 226** | Baji 是 Kapi 的 **8 倍** |
+| **expand_loss**（PLC 补丢包）| 24 ~ 112 | **0** | Baji 一直在补丢包 |
+| **wj**（wall jitter）| 295 ~ 646 | **42 ~ 75** | Baji 是 Kapi 的 **8 倍** |
+| **buffer_ms**（实际缓冲深度）| 20 ~ 260（不稳）| **180 ~ 480**（稳定）| Kapi 一直从容 |
+| 每 2 秒收到 RTP 包数 | 17 ~ 74（持续丢）| **82 ~ 102**（完整）| Baji 持续丢包 |
+
+### 12.3 Kapi 流畅的两个根本原因
+
+#### 根因 ① — WiFi 协议栈缓冲区配置（Kapi 比 Baji 大 1.6~2 倍）
+
+启动日志直接打印的硬数据：
+
+| sdkconfig 项 | Baji | **Kapi** | 优势 |
+|---|---|---|---|
+| `CONFIG_ESP_WIFI_STATIC_TX_BUFFER_NUM` | 8 | **16** | Kapi **2 倍** |
+| `CONFIG_ESP_WIFI_STATIC_RX_BUFFER_NUM` | 10 | **16** | Kapi **1.6 倍** |
+
+WiFi RX 缓冲足够大 → 包密集到达时 WiFi 驱动来得及消化 → **不丢包、不重排** → reor=0。
+
+#### 根因 ② — 系统资源竞争（Kapi 无 LCD/LVGL/GIF）
+
+| 同时跑的任务 | Baji | **Kapi** |
+|---|---|---|
+| LVGL 渲染（Core 0）| ✅ 占 CPU + DRAM | ❌ **无 LCD** |
+| GIF 解码（数字人 hiyori 持续）| ✅ 频繁占 PSRAM 总线 | ❌ **无 GIF** |
+| LCD QSPI DMA 刷新 | ✅ 频繁 | ❌ **无 LCD** |
+| RTC + WiFi | ✅ | ✅ |
+| 应援灯 / BLE 图传 | ✅ | ❌ |
+
+Kapi 的 **PSRAM 总线没有 GIF 解码竞争**，WiFi 协议栈数据通路畅通，所以 jitter buffer 看到的就是顺序、完整的包。
+
+### 12.4 这就是音频播放卡顿的根本原因（最终定论）
+
+**反复以为是网络问题（信道拥挤 / 上行抖动 / 服务端处理慢）都是误诊**。同 Wi-Fi 同信号下 Kapi 流畅、Baji 卡顿，铁证如下：
+
+> **卡顿 = 设备内部资源竞争（WiFi 缓冲不足 + LVGL/GIF 抢 PSRAM 总线）, 不是网络问题。**
+
+Kapi 之所以流畅，是因为：
+1. WiFi 缓冲区从 sdkconfig 层面就配置得更大（16/16 vs 8/10）
+2. 无 LCD 业务负载，CPU + PSRAM 总线宽松
+3. 没有数字人 GIF 解码持续消耗资源
+
+### 12.5 对 Kapi 后续优化的指导意义
+
+#### 当前 Kapi 状态总结
+
+- ✅ **RTC 通话基本流畅**（reor 0~226 已经是良好水平）
+- ✅ **WiFi 缓冲已经配大了**（sdkconfig 16/16）
+- ❌ **无 LCD/无 GIF 业务**，不存在 Baji 的资源竞争问题
+
+#### Kapi 上做 RTC 优化的特别优势
+
+1. **跑通的优化方案直接可信** — Kapi 没有 LVGL/GIF 干扰，效果就是 RTC/codec 本身能力的真实表现
+2. **AFE 启用更安全** — Internal SRAM 余量 80-130KB（vs Baji 44KB），AFE 25-35KB SRAM 占用后仍有 50-100KB 安全垫
+3. **WiFi 缓冲已就位** — 不需要像 Baji 那样先解决 WiFi 缓冲问题再做其他优化
+
+#### 倒推 Baji 优化路线（结合此发现）
+
+Baji 短期最该做的不是 AFE 也不是 Opus（这俩 SRAM 都不够），而是：
+
+1. **P1: 通话期间暂停 GIF + LVGL 降频**（释放 PSRAM 总线）→ reor 1800→500
+2. **P2: audio_loop pri 8→5**（与官方对齐，让 WiFi 中断优先）
+3. **P3: 等 Phase 7.6 释放 SRAM 后**，把 WiFi 缓冲从 8/10 改到 16/16，对齐 Kapi 配置 → reor 500→100
+
+**Baji 抖动问题的解决路径与"启用 AFE / 换 Opus"无关**，是内部资源竞争修复，与本文档讨论的方案 A/B/C 都不冲突。
+
+### 12.6 反向给 Kapi 的提醒
+
+虽然 Kapi 当前流畅，但**如果未来在 Kapi 上加任何屏显/动画/重型任务**，要警惕以下踩坑路径：
+- LVGL 启用前先测试当前 PSRAM 带宽富余度
+- WiFi 缓冲不要因为内存压力主动缩小（保持 16/16）
+- GIF 解码任务必须可暂停，通话期不解码
+- 任何新增 PSRAM 重 IO 任务（图片解码/视频）都要先评估对 RTC reor 指标的影响
+
+**简言之**：Kapi 当前的流畅是"业务功能少 + WiFi 缓冲大"换来的，**新增任何业务时都要做对比基准测试**。
+
+---
+
+## 12.7 🧠 Baji 综合内存优化 + GIF 转 C 数组方案评估（2026-05-14 交叉引用）
+
+为了让 Baji 达到与 Kapi 同等的流畅度，用户提出两个优化思路并要求评估。**Kapi 项目本身不需要做这些（无 LCD/GIF）**，但因为底座关系记录在此供参考。
+
+### 12.7.1 用户提出的两个思路
+
+> 1. ESP32-S3-WROOM-1-N16R8 SRAM 是 512KB，综合优化内存管理是否可行？卡顿改善多少？
+> 2. 当前 GIF 存 SPIFFS 解码，能否用 LVGL imageconverter 转 C 数组烧入固件减少 SRAM/存储开销？
+
+### 12.7.2 SRAM 真相（两个项目通用）
+
+| 区域 | 大小 |
+|---|---|
+| 物理 SRAM 总量 | **512 KB** |
+| ROM Data | 32 KB |
+| RTC SRAM | 16 KB |
+| IRAM（指令）| ~80 KB |
+| **可用 DRAM 堆** | **~320 KB**（应用层上限） |
+
+Baji 启动后剩 ~44KB，Kapi 启动后剩 ~80-130KB（差异在 LVGL/GIF/字体）。
+
+### 12.7.3 Baji 已启用的内存优化
+
+| 优化项 | 状态 |
+|---|---|
+| `BT_ALLOCATION_FROM_SPIRAM_FIRST` | ✅ 已开 |
+| `SPIRAM_USE_MALLOC` | ✅ 已开 |
+| `SPIRAM_TRY_ALLOCATE_WIFI_LWIP` | ✅ 已开 |
+| `MBEDTLS_DYNAMIC_BUFFER` | ✅ 已开 |
+| `LV_USE_LARGE_COORD` | ✅ 关（节省 SRAM）|
+
+**Baji 已经做了 80% 基础优化**，剩可挖 70-100KB。
+
+### 12.7.4 GIF 转 C 数组（4 方案对比）
+
+| 方案 | SRAM 代价 | PSRAM 带宽 | Flash 占用 | 推荐度 |
+|---|---|---|---|---|
+| **A. GIF 转 C 数组（EMBED）** | 0 | 不变 | **+2MB 爆 OTA 分区** | ❌ 否决 |
+| **B. 通话期间暂停 GIF** | 0 | **减 80%** | 0 | ⭐⭐⭐ 强推荐 |
+| C. 转 RGB565 帧序列 | 小 | 减 50% | **+6MB Flash 不够** | ❌ 否决 |
+| D. PNG 序列 + lv_anim | 小 | 减 30% | +1-2MB | ⚠️ 复杂可考虑 |
+
+**关键认知**：
+- LVGL imageconverter 主要处理**单帧**，不能直接转 GIF 动画。EMBED 是用 ESP-IDF 的 `EMBED_FILES` 把 .gif 二进制嵌固件 `.rodata`，XIP 直读 Flash
+- **方案 A 不能解决卡顿**：Baji 瓶颈不是 PSRAM 容量（剩 7MB），GIF 解码 canvas 仍在 PSRAM，**总线竞争不变**；反而撑爆 OTA 分区
+- **方案 B 是性价比之王**：0 内存代价、20 行代码、reor 直接降 70%
+
+### 12.7.5 对 Kapi 的启示
+
+**Kapi 本身不需要做这些**（无 LCD/GIF），但如果未来：
+- 在 Kapi 上加 LCD/动画 → **吸取 Baji 教训，绝不要用 GIF 持续解码**
+- 直接采用 PNG 序列 + lv_anim（方案 D），或预解码帧 + 切换显示
+- 任何新增的 PSRAM 重 IO 任务都要先做 reor 基准测试
+
+### 12.7.6 完整决策记录（更详细版）
+
+详见 Baji 报告：[/Users/rdzleo/Desktop/Baji_Rtc_Toy/docs/Rtc_AIavatar/官方Korvo2方案_对比分析报告.md](../Baji_Rtc_Toy/docs/Rtc_AIavatar/官方Korvo2方案_对比分析报告.md) §11.11
+
+---
+
+## 13. 附录：本文档版本历史
+
+| 版本 | 日期 | 内容 |
+|---|---|---|
+| v1.0 | 2026-05-14 | 初版业务全貌 + 三选项决策矩阵 + 推荐路线 |
+| **v1.1** | **2026-05-14** | **新增 §12 Baji+Kapi 同 Wi-Fi 实测对比，定位 Kapi 流畅的两个根本原因（WiFi 缓冲 + 无 LVGL/GIF 竞争）；给出 Baji 卡顿的最终定论** |
+| **v1.2** | **2026-05-14** | **新增 §12.7 综合内存优化 + GIF 4 方案评估（交叉引用 Baji v2.2）：明确否决方案 A（EMBED 爆 OTA）+ C（Flash 不够），推荐方案 B（暂停 GIF）。给 Kapi 未来加 LCD/动画的预防指导** |