diff --git a/工程调试指南.md b/工程调试指南.md
index a4c9c51..5812fe6 100644
--- a/工程调试指南.md
+++ b/工程调试指南.md
@@ -225,11 +225,21 @@
 5. `AT+MUX?`
 6. `AT+NET=...`
 7. `AT+NET?`
-8. `AT+LINK=...`
-9. `AT+LINK?`
-10. `AT+SAVE`
-11. `AT+RESET`
-12. `AT+DEFAULT`
+8. `AT+BAUD=...`
+9. `AT+BAUD?`
+10. `AT+LINK=...`
+11. `AT+LINK?`
+12. `AT+SAVE`
+13. `AT+RESET`
+14. `AT+DEFAULT`
+
+其中与数据串口相关的固定映射为：
+
+1. `U0 = USART2`
+2. `U1 = USART3`
+3. `AT+BAUD=U0,<baud>` / `AT+BAUD=U1,<baud>` 只更新当前运行配置记录
+4. 新波特率不会立即重初始化 `USART2/USART3`，必须执行 `AT+SAVE` + `AT+RESET` 后按保存值生效
+5. 当前代码接受的波特率范围为 `1200 ~ 921600`
 
 ### 6.2 现场关键规则
 
@@ -238,6 +248,7 @@
 1. 当前现场验证时，配置命令必须保证以换行完成帧。
 2. 若主机侧发送方式不对，现象会很像“配置口完全无响应”。
 3. 因此，配置口不响应时，第一优先级不是改 parser，而是先验证主机端发送格式与接线。
+4. `BAUD` 类命令若查询值已变化，但 `USART2/USART3` 现场波特率尚未变化，不应立即归因为命令无效，应先确认是否已经执行 `AT+SAVE` 与 `AT+RESET`。
 
 ### 6.3 最小验证步骤
 
@@ -247,13 +258,16 @@
 2. 先发 `AT`
 3. 再发 `AT+QUERY`
 4. 再发 `AT+NET?`
-5. 再发 `AT+LINK?`
-6. 修改一个最小参数，例如：
-   - `AT+MUX=1`
-7. 执行：
-   - `AT+SAVE`
-   - `AT+RESET`
-8. 复位后再次查询，确认配置是否保留
+5. 再发 `AT+BAUD?`
+6. 再发 `AT+LINK?`
+7. 修改一个最小参数，例如：
+    - `AT+MUX=1`
+    - 或 `AT+BAUD=U1,38400`
+8. 执行：
+    - `AT+SAVE`
+    - `AT+RESET`
+9. 复位后再次查询，确认配置是否保留
+10. 若本轮验证的是 `AT+BAUD`，还应同步用上位机重新按新波特率连接 `USART2/USART3`，确认数据口实际生效
 
 ### 6.4 持久化失败时怎么查
 
@@ -488,12 +502,15 @@ Keil MDK-ARM 构建 0 Error(s), 0 Warning(s)。Flash 52.7 KB / 64.0 KB (82.5%)
 
 在 CH390 发生 TX timeout 并触发 `ch390_runtime_emergency_reset()` 后，芯片寄存器访问恢复正常，`VID` 可读、PHY 链路也可能保持 `up`，但 TCP 业务流量仍可能长时间不恢复，表现为“芯片还活着，但网络像失联一样，通常只能重启恢复”。
 
+在后续实现收敛中，又确认仅依赖单次 VID 异常或单次 TX busy 即立刻 reset 过于激进，容易把瞬时抖动误判为芯片失活，因此当前代码已经演化为“带阈值的恢复策略”。
+
 #### 根因
 
 `ch390_runtime_emergency_reset()` 旧实现仅执行 `ch390_software_reset()`、`ch390_default_config()` 与 `diag` 刷新，缺少 cold init 里已有的两层恢复语义：
 
 1. **MAC 对齐未恢复**：旧代码没有重新写回 CH390 `PAR`，也没有把硬件 MAC 重新同步到 `netif->hwaddr`。若软件复位后 CH390 的 MAC 过滤状态与 lwIP 侧缓存身份不一致，现象会表现为寄存器可访问、链路仍在，但单播业务流量不通。
 2. **上层链路回收未触发**：TX-timeout 路径直接调用 `ch390_runtime_emergency_reset()`，没有保证 `App_StopLinksIfNeeded()` / `App_StartLinksIfNeeded()` 观察到一次有效的 link-down 周期，导致旧 TCP client/server 状态可能跨芯片复位残留，业务层没有完成重建。
+3. **恢复策略缺少抖动抑制**：若仅凭单次 TX busy 或单次 VID 异常立即 reset，容易在瞬时总线/链路抖动下过度恢复，放大业务扰动，因此当前实现增加了连续失败阈值和失败计数清零逻辑。
 
 #### 修复内容
 
@@ -505,12 +522,40 @@ Keil MDK-ARM 构建 0 Error(s), 0 Warning(s)。Flash 52.7 KB / 64.0 KB (82.5%)
 | `Drivers/CH390/ch390_runtime.c` | emergency reset 成功后清 `g_ch390_irq_pending` 并置位 `g_link_restart_pending` | 避免复位前遗留中断状态影响恢复 |
 | `Drivers/CH390/ch390_runtime.c` | `ch390_runtime_check_link()` 增加一次性 hold-down 逻辑 | 保证主循环至少看到一次 link-down，从而触发 app 层 stop/start 回收重建 |
 | `Drivers/CH390/ch390_runtime.c` | TX-timeout 与 health-check 两条 reset 路径统一传入 `netif` | 让两类恢复路径都走同一套 MAC 重同步与链路重建语义 |
+| `Drivers/CH390/ch390_runtime.c` | 为 TX timeout 与 health-check 增加连续失败阈值 | 降低瞬时抖动导致的过度 reset 风险 |
+
+#### 当前实现语义（以源码为准）
+
+1. **TX timeout 阈值**
+   - 单次判定条件：`CH390_TCR.TXREQ` busy-wait 持续超过 `10 ms`
+   - 连续阈值：累计 `6` 次后才触发 `ch390_runtime_emergency_reset()`
+   - 只要有一次成功发送，`g_tx_consecutive_timeout` 立即清零，因此该阈值针对的是**连续失败**，不是累计历史失败次数。
+
+2. **health-check 阈值**
+   - `VID` 单次读到 `0x0000` / `0xFFFF` 并不会立即 reset。
+   - 只有连续 `3` 次异常 VID 才触发 emergency reset。
+   - 若 `g_ch390_ready == 0`，则 health-check 会直接尝试 reset，不再等待 VID 连续计数。
+
+3. **restart-pending 的单次语义**
+   - emergency reset 成功后会置位 restart-pending。
+   - 下一次 `ch390_runtime_check_link()` 先强制执行一次 `netif_set_link_down()`，随后立即清除此标志并提前返回。
+   - 该设计用于保证主循环至少看到一次有效的 logical link-down，从而沿用现有 `App_StopLinksIfNeeded()` / `App_StartLinksIfNeeded()` 路径回收并重建 TCP links。
+
+4. **内部计数与状态**
+   - `g_chip_reset_count`：记录 emergency reset 尝试次数，饱和递增到 `0xFF`。
+   - `g_tx_consecutive_timeout`：记录连续 TX busy 超时次数；成功发送或进入 reset 路径后清零。
+   - health-check 连续失败计数当前与 `g_link_restart_pending` 共用一个状态字节的高位 nibble 存储；当 VID 恢复正常、达到 reset 阈值或 emergency reset 成功时会清零。
+
+5. **失败路径差异**
+   - 只有当 emergency reset 完成后 `g_diag.id_valid` 仍然有效，才会置位 restart-pending 并进入后续 app recycle 语义。
+   - 若 reset 后芯片仍不响应，则仅记录失败并返回，不会伪装成可恢复状态。
 
 #### 预期结果
 
 1. CH390 发生 emergency reset 后，硬件 MAC、`netif->hwaddr` 与当前业务身份重新对齐。
 2. 即使物理网线始终保持连接，主循环仍会在后续 poll 中观察到一次有效 link-down，并按既有 `App_StopLinksIfNeeded()` / `App_StartLinksIfNeeded()` 路径回收并重建 TCP links。
-3. 复位后的恢复语义与 cold init 更接近，不再停留在“芯片寄存器恢复正常，但业务流量仍死掉”的半恢复状态。
+3. 恢复策略对瞬时异常更保守：只有连续超时或连续 VID 异常达到阈值才会触发 reset，降低误触发恢复的概率。
+4. 复位后的恢复语义与 cold init 更接近，不再停留在“芯片寄存器恢复正常，但业务流量仍死掉”的半恢复状态。
 
 #### 构建验证