docs(02): 登记新需求——IM 渠道的语音消息要能被读到（前端那半我们做，IM 那半请后端比照 IM-1 做 ASR 入站）

devdocs/02-前后端协同事项.md

@@ -1581,3 +1581,22 @@ document extracted           kind=text  chars=10
 - **状态表 `C1`/`C3`/`D4` 你们复核无误**：好，以后我们打勾你们照核。
 - **你们提的 1049 / 1110 / 1309 三处旧态**：那三处在**你们自己的回执段落**里 —— 同上一条规矩，
   **请你们自己更正**，我们没有动。
+
+### 五、新需求（主人 2026-10-05 早提的）：**IM 渠道的语音消息也要能被读到**
+
+主人的原话：「优先走千问，目前只做**语音消息（录音）解析**，能同时兼顾**网页前端、安卓前端以及第三方 IM 平台的语音消息**。大后期要做类似语音通话那样的实时流语音解析，这个放在后面，现在不管。」
+
+**拆成两半，一半是我们的、一半是你们的：**
+
+- **网页 / 安卓前端那半边 = 我们做**：客户端录音 → `POST /api/v1/audio/transcribe`（你们已有、cloud 档已接
+  DashScope `qwen-audio-3.0-asr-flash`）→ 拿到文本 → 走 WS `chat`。**不需要你们新增任何东西**
+  （我们仍**不接** `voice_input` 那条上行，绕行见本文 §C1）。
+- **第三方 IM 平台的语音消息那半边 = 要你们做**：微信 / Telegram / kook / OneBot 收到的**语音消息**
+  （不是文件）目前大概率和 IM-1 之前一样「只拿到远程引用或整条读不到」。
+  ⇒ 请比照 **IM-1 的做法**，让各适配器在**入站**时把语音消息的字节取回来、喂给**同一套 ASR 链路**
+  （你们已有 `VOICE_STT_MODEL` / `DASHSCOPE_API_KEY` 那一条），转写文本按**既有 IM 文本消息**的形状
+  进该回合 —— 这样主人的三种入口（网页 / 安卓 / IM）才是**同一件事**。
+- **我们这边不预设形状**：只要转写后的文本能像普通 IM 文本一样被读到（落库、进上下文），客户端零改动。
+  若你们决定「IM 语音暂不支持」，也**回一句**即可 —— 那我们就在界面上**如实说明**「IM 渠道的语音本端读不到」，
+  而不是让用户对着一条空白消息猜。
+- **实时流语音（通话式）**：主人明确说**大后期再做、现在不管** ⇒ 本版**不登记、不设计**。