ylhan
2b6093d392
评审指出的问题，逐条修正： 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 表情，最后摄像头/多人/电机。