78/xiaozhi-esp32

解决什么问题

在单片机上做语音助手，通常要自己拼：离线唤醒、Opus 音频推流、稳定的传输通道、ASR/LLM/TTS 串联，以及让模型真正能操作硬件。大多数个人项目卡在其中某一环。这个项目提供一套完整的 ESP32 固件，把受支持的板子直接变成语音终端；设备侧 MCP 让模型可以控制扬声器、LED、舵机和 GPIO，云端 MCP 则把能力扩展到智能家居、PC 操作等场景。

有什么不同

自己基于 ESP-SR 加 WebSocket 客户端搭一套，也能跑通，但这里的优势是覆盖面和整合度：138 个板型目录、171 个发布变体，支持 WebSocket 与 MQTT+UDP 两种传输，离线唤醒词可自定义，同时兼容传统 ASR+LLM+TTS 链路和实时端到端语音模型。与芯片厂商的语音套件 SDK 相比，它跨 ESP32/C3/C5/C6/S3/P4，且 MIT 协议允许商用。真正拉开差距的是 MCP 这层抽象：把设备当作 MCP server，而不是为每个外设硬编码指令。

适合谁

适合做 AI 语音硬件原型的爱好者和小团队——桌面陪伴、挂件、机器狗之类——不想从零写音频栈。固件工程师也可以把它当作多板型抽象的参考实现。如果你需要带 SLA 的量产设备云服务，或者主控不是 ESP32，那就别选它：代码与 ESP-IDF 及其组件生态绑定很深。

上手成本

工具链要求不低：最低 ESP-IDF v6.0.1，推荐 release/v6.1，明确不支持 5.x；切换 SDK 后还要做 submodule 更新和 fullclean 重编。实际使用通常意味着注册官方 xiaozhi.me 作为默认后端，或者自己部署社区服务端（Python/Java/Go）。刷预编译固件对新手友好，改固件则不友好。项目已有两年且维护活跃，但板型矩阵持续膨胀，引脚与 IDF 兼容性的边缘问题是不小的维护负担。

点评

这是成熟项目而非短期爆发：约 31.9k star，本月 C++ 月榜第 2、单月 +1,729 star，关注度仍在上升。变动集中在硬件适配上而不是核心设计，对固件基座来说是健康信号。如果你在做 ESP32 语音产品，想直接跳过音频链路，值得采用；但要把它当成需要跟随升级的 SDK，而不是刷完就完的固件。主要风险是绑定厂商工具链节奏，以及默认依赖官方托管后端。