项目开发重点和难点分析
1. 核心重点
1.1 实时语音流处理
重点:
- WebSocket双向实时通信
- 音频流分片传输(建议3200字节/帧)
- 前后端协议设计(音频数据 + 控制消息)
关键技术:
- 浏览器MediaRecorder API/AudioWorklet
- WSS长连接管理
- 音频Buffer管理
1.2 低延迟架构
重点:
- 0.3秒内完成STT→LLM→TTS全链路
- 流式处理(边收边转边播)
- 音频流式返回(不等待完整音频)
优化策略:
- STT实时识别(不等整句)
- LLM流式输出
- TTS流式合成
- 前端音频流式播放
1.3 三模型协同调用
重点:
- STT、LLM、TTS串行调用
- 中间状态管理
- 错误处理和重试机制
流程设计:
音频流 → STT(实时) → 文本Buffer → LLM(流式) → TTS(流式) → 音频流
2. 技术难点
2.1 极致低延迟优化 ⭐⭐⭐⭐⭐
难点:
解决方案:
- 流式处理: 不等待完整结果,边处理边返回
- 预测性响应:
- STT识别到句子暂停即触发LLM
- LLM生成前N个token即触发TTS
- TTS合成首个音频片段即返回
- 连接复用:
- 本地缓存:
2.2 浏览器音频采集兼容性 ⭐⭐⭐⭐
难点:
- 不同浏览器API支持差异
- 移动端权限管理复杂
- iOS Safari限制多
解决方案:
- API选择:
- 优先使用AudioWorklet(Chrome/Edge)
- 降级到ScriptProcessorNode(Safari)
- 封装统一接口
- 格式转换:
- 浏览器原始格式(通常Float32)→ PCM Int16
- 重采样到16kHz
- 权限处理:
2.3 情感识别与合成 ⭐⭐⭐⭐
难点:
- LLM需输出情感标签
- TTS需支持情感参数
- 情感分类准确性
解决方案:
Prompt设计:
系统Prompt要求LLM输出:
{
"text": "回复内容",
"emotion": "happy/sad/neutral/excited/..."
}
TTS情感映射:
- 将LLM情感标签映射到TTS voice参数
- 预定义情感-音色对应表
动画同步:
2.4 实时音频播放 ⭐⭐⭐
难点:
- 音频流式接收和播放
- 避免卡顿和爆音
- 多段音频无缝衔接
解决方案:
- Web Audio API:
- 使用AudioContext
- AudioBufferSourceNode队列
- 缓冲策略:
- 队列管理:
2.5 WSS连接稳定性 ⭐⭐⭐
难点:
解决方案:
- 心跳机制:
- 断线重连:
- 状态同步:
2.6 录音控制逻辑 ⭐⭐⭐
难点:
解决方案:
- 请求标识:
- 每次录音生成唯一requestId
- 音频帧携带requestId
- 取消机制:
- 点击取消发送cancel消息
- 后端标记该requestId为废弃
- 后端停止处理并丢弃结果
- 前端状态:
- 录音中:实时传输
- 发送:等待响应
- 取消:丢弃响应(即使收到)
3. 技术选型建议
3.1 前端
- 框架: React/Vue + TypeScript
- 音频: Web Audio API + AudioWorklet
- 通信: WebSocket API
- 动画: Lottie/Spine(动画IP)
- 状态管理: Zustand/Pinia
3.2 后端
- 语言: Python 3.9+
- 框架: FastAPI + WebSocket
- 异步: asyncio + aiohttp
- 音频处理: DashScope SDK
- 部署:
- 开发: Uvicorn
- 生产: Uvicorn + Nginx(WSS代理)
3.3 开发优先级
- P0: WSS通信 + STT实时识别
- P0: LLM对话 + TTS合成
- P0: 音频播放 + 基础UI
- P1: 低延迟优化(流式处理)
- P1: 动画IP状态切换
- P2: 情感表达
- P2: 移动端适配
4. 风险点
4.1 技术风险
- 0.3秒延迟: 可能无法达到,需与用户确认容忍度(建议1秒内)
- 模型限流: Qwen API可能有QPS限制
- 浏览器兼容: iOS Safari WebSocket可能有坑
4.2 成本风险
- API调用费用(按调用次数计费)
- 需要监控和优化使用量
4.3 缓解措施
- 早期原型验证延迟指标
- 申请API配额
- 多浏览器测试矩阵