产品经理 · 端到端独立(硬件 + AI 全链路) · 已完成 · 固件 v2.1.0
AI 会议秘书
带屏智能会议终端 + 可私有化部署的后端 —— 我作为产品经理下场打通「硬件 + AI 全链路」:按键即实时转写、按声纹区分发言人、结束自动出结构化纪要。
核心:作为产品经理,我下场把「硬件 + AI 全链路」端到端做通了。 一块带屏 ESP32-P4 终端做瘦客户端,配一套可私有化部署的后端 —— 按一下键就实时转写、按声纹区分发言人、结束自动出结构化纪要。2 人 1m 转写准确率 >85%,样机 BOM 低于 ¥300。
一、背景与动机
我是产品经理,做这个项目的真实起点,是想验证自己能不能真正下场做”嵌入式 + AI”的端到端系统,而不只是写需求文档。
之所以选「会议秘书」当载体,是因为它一个项目就把整条链路串了起来:ESP32-P4 硬件 → 音频采集 → ASR 转写 → LLM 纪要 → 声纹识别 → 结构化输出;而且它天然带”团队协作”场景,我能在真实开会里测它好不好用。
- 目标用户:4–8 人的中小团队 / 创业公司日常会议。
- 痛点:小型会议没人愿意记纪要,记了也漏关键决议。
- 长期方向:沿”项目管理 + Agent”深挖,把它从”会议记录工具”做成服务 To B 团队的会议智能体。
二、产品形态与核心能力
这不是一个单机录音盒子,而是「瘦客户端 + 后端系统」:设备端只负责录音 / 播放 / 显示,所有 AI 能力(ASR、LLM、TTS、声纹)都在后端完成。
| 模式 | 行为 |
|---|---|
| 闲聊模式(默认) | 语音对话、声纹认人、工具调用(天气 / 新闻),长回复屏内可滚动 |
| 会议模式 | 按 BOOT 键开始 → 只做实时转写 + 声纹区分发言人(AI 全程不插话) → 再按 BOOT 结束 → 自动生成纪要(主题 / 关键结论 / 待办) |
已跑通并实测 ✅:瘦客户端固件(会议状态机、纪要页、声纹标签 UI)、会议模式实时转写(逐句字幕带 [时间][说话人])、单人声纹识别、LLM 流式生成结构化纪要、自建后端全链路、唤醒词 + VAD + AEC 回声消除。
已设计、下一步路线图 🚧:多人说话人分离(声纹 + DOA 融合)、DOA 声源定位 + LED 灯环指向、配套小程序(声纹自助注册 / 纪要历史)、纪要落库持久化。
我刻意把”做到的”和”设计中的”分清楚 —— 能讲清边界,本身就是产品判断力的体现。
三、系统架构
核心原则:设备端零模型推理,所有 AI 推理在云端 / 私有服务器完成。 ESP32-P4 这类资源受限设备扛不起 ASR/LLM;把推理放后端,还能做到”后端换模型,客户端代码不动”。
- 设备端(ESP32-P4):MEMS 麦 → ES7210 四通道 ADC → ESP-SR(AEC / VAD / 唤醒)→ Opus 编码 → WebSocket/MQTT;LVGL UI 负责实时字幕、说话人标签、纪要页。
- 后端服务器:WebSocket 网关(Python)调度 → 阿里云流式 ASR + 声纹微服务(3D-Speaker CAM++)+ DeepSeek 纪要 + EdgeTTS;MySQL / Redis + 管理后台(Java + Vue)。
四、我的核心技术决策
① 二次开发开源框架,而非从零自研固件(最核心判断) —— 设备端基于开源 xiaozhi-esp32 二次开发,复用 WiFi、协议、Opus、LVGL、OTA 这些底层轮子,把精力集中在差异化的”会议模式状态机、纪要页、声纹标签 UI”上。代价:要吃透别人的架构;收益:用工程判断力换开发速度,而不是炫技重造轮子。
② “云端托管 → 自建后端”分期切换 —— 先用官方云端跑通全链路验证产品价值,再把各模块逐个切到自建后端控成本、做定制。替换顺序有理由:ASR(对转写质量影响最大,先换)→ LLM(纪要质量)→ 声纹(P1 新能力,直接自建)→ TTS(用得最少,最后)。这是”先验证价值,再控成本”的产品工程节奏。
③ 给”不确定的 AI”套”确定的尺子”(验收标准) —— AI 输出不确定,我用分层方法定义”做对了”:
| 能力 | 验收标准 | 方法 |
|---|---|---|
| 转写(ASR) | 2 人 / 1m / 准确率 >85% | 定量阈值,已达成 |
| 说话人识别 | 4 人 / 准确率 >80% | 定量阈值(目标值) |
| 纪要(LLM) | 覆盖 >90% 关键决议 + 零明显幻觉 | 结构化模板(主题→结论→待办→风险)约束自由生成 + 人工抽检 |
方法论:能量化的用准确率阈值;不能量化的(纪要)用”结构化模板 + 覆盖关键决议 + 零幻觉”,用模板约束降低 LLM 的不确定性。
五、最难的一关:「阿里云断了」的误判排查
现象:会议中 AI 频繁”中断”,后端报 阿里云TTS会话在启动完成前退出,第一反应是阿里云服务挂了。
排查:逐条核对日志,发现阿里云全程零报错 —— 没有 TaskFailed、没有连接关闭、没有 token 错误,说明 ASR/TTS 本身健康。
真因:设备处于实时打断模式,在多人 / 嘈杂环境下产生”打断风暴”——13 分钟触发 26 次 Abort。AI 每次刚要说话就被环境声打断,TTS 握手没完成就被掐断,才报出那条误导性日志。安静一对一环境完全不复现。
附带修的 bug:原框架不分模式,会议里每说一句都会触发 LLM 应答 + TTS(AI 一直插嘴)。定位到入口函数后加模式判断:会议模式只下发转写、跳过 LLM/TTS,实测全程零误触发。
收获:故障未必在它报错的那一层。 完整的”现象 → 假设 → 用日志证伪 → 定位真因”比盲目重启服务有效得多。
六、技术栈
- 硬件:ESP32-P4(双核 RISC-V 400MHz)+ 32MB PSRAM;微雪 4.3″ 触摸屏开发板;ES7210 四通道麦 ADC + 板载 MEMS 麦 + ES8311 功放;WiFi 6(经 ESP32-C6);ESP-IDF 5.4。
- 后端 / 算法:阿里云流式 ASR · DeepSeek(纪要 + 对话)· EdgeTTS · 声纹微服务(3D-Speaker CAM++ + FastAPI)· 主后端
xiaozhi-esp32-server(Python + Java + Vue + MySQL + Redis)。 - 设备端算法:ESP-SR(AEC / VAD / NS / 唤醒词)。
- 开发工具:主要用 Claude Code 做开发与排障(后端 bug 定位、固件 UI 改造、配置修复)。
七、成果与数据
- 转写准确率 >85%(2 人 / 1m,MVP 验收已达成)。
- 闲聊端到端延迟 1~5s(安静一对一无打断)。
- 声纹识别:已注册并验证可认出指定发言人。
- 完整链路实测通过:BOOT 开始 → 多句发言转写 + 声纹 → BOOT 结束 → 出纪要,零误触发 LLM。
- 样机 BOM 低于 ¥300,量产估 低于 ¥150。
- 已有正式交付物:面向测试工程师的《Demo 交付说明 v2.1.0》。
八、我从这个项目学到的
- 端到端的系统判断力:知道哪些自研、哪些复用、哪些先验证再优化(分期切换)。
- 给 AI 定可检验的标准:把”纪要好不好”这种主观问题,拆成”结构化模板 + 覆盖率 + 零幻觉”的可抽检指标。
- 真能调通系统:从设备固件到后端服务,能独立定位并修复跨层 bug。
我的核心卖点是端到端的产品判断力 + 真能下场把系统调通,而不是底层固件功力 —— 扬长避短。
访问入口
- 演示视频:见本页顶部内嵌播放器(可直接播放)。
- GitHub(固件部分):github.com/Olaf-biu/AI-meeting-firmware