产品经理 · 端到端独立(硬件 + 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、声纹)都在后端完成。
| 模式 | 行为 |
|---|---|
| 闲聊模式(默认) | 作为 AI 秘书随时语音对话:声纹认人、工具调用(天气 / 新闻);并接入团队与项目的资料,能结合实际项目情况作答,而非泛泛闲聊;长回复屏内可滚动 |
| 会议模式 | 按 BOOT 键开始 → 只做实时转写 + 声纹区分发言人(AI 全程不插话) → 再按 BOOT 结束 → 自动生成纪要(主题 / 关键结论 / 待办) |
已跑通并实测 ✅:瘦客户端固件(会议状态机、纪要页、声纹标签 UI)、会议模式实时转写(逐句字幕带 [时间][说话人])、单人声纹识别、LLM 流式生成结构化纪要、闲聊模式接入团队 / 项目资料(AI 秘书,可结合实际场景作答)、自建后端全链路、唤醒词 + 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)。
四、我的核心技术决策
① 二次开发开源框架,而非从零自研固件(最核心判断) —— 设备端基于成熟开源固件框架二次开发,复用 WiFi、协议、Opus、LVGL、OTA 这些底层轮子,把精力集中在我自己做的差异化上:会议模式状态机、纪要页、声纹标签 UI,以及把默认”闲聊模式”深度改造成接入团队 / 项目资料、能结合实际场景作答的 AI 秘书。代价:要吃透别人的架构;收益:用工程判断力换开发速度,而不是炫技重造轮子。
② “云端托管 → 自建后端”分期切换 —— 先用官方云端跑通全链路验证产品价值,再把各模块逐个切到自建后端控成本、做定制。替换顺序有理由:ASR(对转写质量影响最大,先换)→ LLM(纪要质量)→ 声纹(P1 新能力,直接自建)→ TTS(用得最少,最后)。这是”先验证价值,再控成本”的产品工程节奏。
③ 给”不确定的 AI”套”确定的尺子”(验收标准) —— AI 输出不确定,我用分层方法定义”做对了”:
| 能力 | 验收标准 | 方法 |
|---|---|---|
| 转写(ASR) | 2 人 / 1m / 准确率 >85% | 定量阈值,已达成 |
| 说话人识别 | 4 人 / 准确率 >80% | 定量阈值(目标值) |
| 纪要(LLM) | 覆盖 >90% 关键决议 + 零明显幻觉 | 结构化模板(主题→结论→待办→风险)约束自由生成 + 人工抽检 |
方法论:能量化的用准确率阈值;不能量化的(纪要)用”结构化模板 + 覆盖关键决议 + 零幻觉”,用模板约束降低 LLM 的不确定性。
五、最难的一关:让 AI 在会议里”该闭嘴时闭嘴”
一个反直觉的产品判断:会议场景下,AI 最该做的不是”聪明地回答”,而是”安静地记录”。 这恰恰是最难调的一关。
先是产品决策 —— 原框架不分模式,会议里每个人说一句都会触发 AI 应答 + 语音播报(AI 全程插嘴),根本没法用。我判断会议模式必须让 AI 静默:只下发转写、跳过 LLM/TTS。加上模式判断后,会议全程零误触发。
再是一次跨层 debug —— 闲聊模式下 AI 又频繁”中断”,后端报”阿里云 TTS 会话异常”,第一反应是云服务挂了;但逐条核对日志发现阿里云全程零报错。真因是”实时打断模式”在嘈杂多人环境下产生”打断风暴”(13 分钟 26 次 Abort),AI 每次刚要说话就被环境声打断、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++);后端支持私有化部署。
- 设备端算法:ESP-SR(AEC / VAD / NS / 唤醒词)。
- 开发工具:Claude Code / Codex / Cursor 配合切换着用 —— 开发与排障(后端 bug 定位、固件 UI 改造、配置修复)。
七、成果与数据
- 转写准确率 >85%(2 人 / 1m,MVP 验收已达成)。
- 闲聊端到端延迟 500ms~2s(安静一对一无打断)。
- 声纹识别:已注册并验证可认出指定发言人。
- 完整链路实测通过:BOOT 开始 → 多句发言转写 + 声纹 → BOOT 结束 → 出纪要,零误触发 LLM。
- 样机 BOM 低于 ¥300,量产估 低于 ¥150。
- 已有正式交付物:面向测试工程师的《Demo 交付说明 v2.1.0》。
八、我从这个项目学到的
最大的收获:亲手下场,不是为了”会做嵌入式”,而是为了更快验证想法、更懂开发者。 嵌入式是比软件(平台 / 用户端)门槛更高的领域,连它我都能跑通 —— 这意味着我能用最快的方式把一个需求或想法验证到”真能跑”,而不是停在 PPT;也因为真写过、调过,我更清楚开发会卡在哪、什么需求是合理的,和研发协作更省力。
落到具体能力上:
- 端到端的系统判断力:知道哪些自研、哪些复用、哪些先验证再优化(分期切换)。
- 给 AI 定可检验的标准:把”纪要好不好”这种主观问题,拆成”结构化模板 + 覆盖率 + 零幻觉”的可抽检指标。
- 真能调通系统:从设备固件到后端服务,能独立定位并修复跨层 bug。
我的核心卖点是端到端的产品判断力 + 真能下场把系统调通,而不是底层固件功力 —— 扬长避短。
访问入口
- 演示视频:见本页顶部内嵌播放器(可直接播放)。
- 代码:固件仓库暂为私有,可按需提供 / 面试时演示。