ylhan
2b6093d392
方案 v2.4 修订：按评审意见修正 8 处
评审指出的问题，逐条修正：
1. AEC 结论过早
原文写"WebRTC 自带 AEC，因此解决 P2"，这是把"框架有实现"当成了
"链路配置正确"。补充了三个前提：麦克风采集与播放参考要正确送入、
XVF3800 自身 AEC 路由需实测（两处 AEC 串联可能互相干扰）、
打断判定依赖 AEC 输出质量。P2 该行改标"待验证"。
2. 音频路径旧描述
第 157 行仍写"N5095 的 TTS"，已改为完整链路：
服务器 Qwen3-TTS → WebRTC → N5095 USB 播放端点 → XVF3800 AUX → 音箱。
并补一条：AEC 所需播放参考必须在 N5095 本地可得，不能依赖服务器回放时钟
（两侧时钟不同步会导致参考信号对不齐）。
3. "N5095 不跑任何推理"不准确
方案自己安排 N5095 跑 VAD、唤醒、人脸检测，这些也是推理。
改为"不运行 STT/TTS/LLM 等重型推理"。
4. 架构变更理由说过重
原文称"N5095 跑不动可用的语音模型"，但 P0 数据证明它能跑
Zipformer STT（RTF 0.22）和 Piper TTS（RTF 0.36）。
改为"N5095 能完成低配本地语音，但达不到当前的目标音质与延迟"——
音质达标的 Qwen3-TTS 在它上面 RTF 1.86，在服务器上 0.09。
5. 客户端/服务器音频边界未定义（新增一节）
传什么（持续音频 vs 带预卷的语音段）、唤醒在哪端、打断谁判定、
断线抖动如何恢复——四个问题列了选项与权衡，给出当前倾向，
并标注必须在做 WebRTC 客户端之前定稿，否则接口要返工。
6. STT 是最大功能风险
在 §5 表格和 §10 各标出：中文真人识别率至今无可信数据，
音频硬件到手后应优先录制本人语音算 CER，并与 SenseVoice /
faster-whisper large-v3 对比。
7. 首音延迟需按真实链路重测
当前 1545ms 是非流式、无 VAD、无传输、无播放缓冲的数据。
补入必须计入分句等待、WebRTC 抖动、播放缓冲，并测 P50/P95。
8. 尾部旧状态与重复段
§10 重写：原文还写"继续确认 Ubuntu 版本""未做实机测试"，
与 v2.4 实际进度冲突。改为已完成/下一步/风险/待办四段。
删除 §5 中完全重复的 P0 测试说明段。
同时采纳评审给出的下一步顺序：先闭环实时语音链路
（WebRTC 客户端 → 真实音频 → AEC/打断/STT 正确率），
再推 ESP32 表情，最后摄像头/多人/电机。
2026-09-15 12:49:42 +08:00
..
2026-09-15 12:49:42 +08:00
2026-09-14 17:02:12 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00
2026-09-15 11:08:56 +08:00