企业官网建设流程全解析

这个糖球系列做到第三期，正好可以聊聊一个很多人容易误解的点：为什么这代圆屏方案我没让ESP端去跑模型，而是老老实实当后台的语音客户端。说实话，刚立项那会儿我也天真过，想着ESP32-S3毕竟带向量加速指令，多少能塞个轻量模型进去，结果一跑就发现根本不是那么回事。你真把模型塞进去之后，唤醒、识别、对话刷新、屏幕渲染这堆活儿全挤在同一个MCU上，体验基本是灾难级的。所以这一篇我就把整个设计逻辑和落地过程完整拆一遍，尤其是“不跑模型”这个取舍背后的原因，以及ESP端到底该负责些什么活才最合理。

先说说这套东西的整体定位。糖球是一个圆形屏幕的桌面语音交互设备，核心交互方式是语音对话加屏幕反馈，背后的大语言模型能力全部由后台提供。ESP32-S3在整套系统里承担的职责是：收音、播放、显示、按键与状态管理，另外负责和后台的语音识别、大模型和语音合成服务通信。说得直白点，它就是一个带屏幕的语音终端，模型推理放在后台PC服务器上，ESP端只做客户端的活。正因为把模型推理从端侧拿走了，整个系统的开发效率和升级灵活性才有了质的提升，而圆屏上的交互效果也能做到足够流畅。

1. 整体架构：为什么让ESP圆屏当“语音客户端”，而不是“模型终端”

1.1 端侧算力与需求之间的真实差距

先算一笔账。ESP32-S3主频最高240MHz，带向量指令，内存最大的模组也就8MB左右的外部PSRAM可用，Flash一般是8MB或16MB。看起来好像能跑点东西，但常识判断一下：一个参数规模在1B左右的量化对话模型，光权重就至少占500MB以上存储空间，运行时还要加载进内存，MCU上根本没地方放。即便是小得多的语音识别模型或者唤醒词模型，用ESP-SR这类专门优化过的方案跑起来，也需要占用大量CPU周期和内存带宽，尤其是进入连续监听状态时，系统几乎干不了别的活。

我做第一版原型的时候，试着在上面同时跑唤醒词模型和一个轻量的命令词分类模型，结果屏幕刷新掉帧、音频采样出现断流、网络请求超时。最直观的现象是，你说一句话，屏幕要卡半天才反应。这就是典型的任务挤占效应：MCU的算力是固定的，模型推理一旦开始，就会周期性地抢占CPU时间片，音频DMA传输、LVGL渲染、WIFI协议栈这些实时性要求高的活会全部受影响。

所以后来我想明白一个道理：不是所有设备都非得跑模型才是智能硬件。模型在端侧的价值是离线可用、低延迟、隐私更好，但代价是算力、内存、功耗、flash空间的极大消耗。对于桌面型语音设备来说，后台有PC或局域网服务器的情况下，让ESP只做采集和渲染，既能把硬件成本压下来，又不会因为模型能力有限导致对话效果拉胯。

1.2 前后端分离：从“单机逻辑”到“端云一体”的思路转变

这套系统的核心思路可以概括成一句话：端侧管输入输出，后台管理解与生成。ESP32-S3端只做四件事，音频采集、音频播放、屏幕渲染、用户交互事件采集。后台统一处理语音识别、语义理解、对话生成、语音合成。这种架构本质上和Web前后端分离是同一个套路。

这种分离带来的第一个好处是升级方便。模型迭代这种事放在后台做就够了，服务器上换个模型文件，重启一下服务，所有设备自动就具备新能力。不需要OTA刷固件，不需要担心Flash写坏，不需要挨个设备升级。我做第一版的时候后台接的开源本地模型，后来觉得效果不理想，换了好几个模型，每次都是后台几分钟搞定，ESP端一行代码没改，这种爽感只有经历过“端侧模型升级地狱”的人才懂。

第二个好处是并行开发。做硬件和做算法的人可以互不干扰。后端同学专心在服务端处理音频流、接大模型API、调TTS音色；嵌入式这边的活就是音频格式、网络协议、屏幕UI、交互状态机。两边只要定好通信协议，各自调试各自的，联调的时候很少出大问题。

1.3 这个方案的天花板在哪里

但“端侧不跑模型”不代表没有短板。最明显的是断网不能用，网络一断，糖球就直接变成摆设了。第二个问题是延迟，音频要上传、处理、再下传，和端侧本地推理相比，网络传输加后台推理的时间开销不小。实测下来，在局域网环境下，从用户说完话到屏幕出现反馈文字，一般需要500毫秒到1秒左右，如果走公网API，延迟更高。所以做体验优化的时候，必须在交互流程上加“已听到”之类的即时反馈，否则用户会觉得设备没反应。

还有一个点是隐私。所有语音内容都会经过后台，如果是局域网部署的本地模型，隐私风险还可控；如果用的是云服务API，那就要考虑数据安全策略。好在现在很多本地模型服务框架已经很成熟，可以完全离线跑在PC或者开发板上，隐私问题就有了更多选择空间。

2. 核心细节：圆屏显示、语音采集与客户端协议设计

2.1 圆屏驱动和UI设计上的几个关键选择

糖球用的是GC9A01这颗圆形LCD驱动芯片，分辨率240x240，接口是SPI。这颗屏在市面上很常见，驱动代码也相对成熟，但真正把它用好的前提是别忽略刷新方式。SPI刷一帧全屏RGB565数据大概需要115200字节，如果按30fps算，每秒要传3.4MB以上数据，普通SPI不加DMA根本扛不住。我实测用SPI 40MHz加DMA双缓冲，LVGL刷新能稳定在25到30fps左右，基本够用。

圆屏UI设计和方屏区别很大。四个角的信息没法放，布局天然就是中心聚焦式。菜品、时钟、对话气泡这类内容居中最合适，边缘区域适合放状态图标和滚动文字。LVGL本身提供了圆形的样式裁剪能力，但要注意在样式中设置圆角半径足够大，否则控件边缘会露出方形的底。色深方面，这块屏是RGB565，显示渐变和阴影效果时会有明显色阶断层，所以UI审美要走扁平风，减少大面积渐变。

还有一个特别容易踩的坑是屏幕初始化序列。市面上GC9A01模组来自不同厂家，初始化命令可能略有差别，有些屏幕上电后颜色偏紫，大概率是初始化序列里的Gamma设置不对或者RGB/BGR顺序设反了。我用的初始化序列是厂家提供的版本，跑起来颜色正常，但如果你买的屏幕有偏色问题，优先检查SPI模式（Mode 0还是Mode 3）和RGB字节序，这两个是最常见的偏色来源。

2.2 语音采集：I2S麦克风与音频前处理

音频采集用的是一款I2S接口的模拟麦克风加外部ADC，还是数字PDM麦克风，取决于硬件选型。第一版我用的PDM麦克风，接线简单，但PDM对时钟抖动和电源噪声比较敏感，布线不好容易有沙沙声。后来改成I2S数字麦克风之后，噪声问题好了很多，代码上也更可控。

采样率方面，后台语音识别一般用16kHz或更高，我统一用的16kHz、16bit、单声道，既能保证识别准确率，又不会让上传数据量过大。按这个参数，每秒音频数据是32KB，一段10秒的语音也就320KB，在局域网环境完全能接受。

采集流程上，ESP端要做的第一件事是检测用户开始说话。最简单的方案是按键触发，按住说话、松开发送，这种模式最可靠，不会出现误触发。进阶方案是用ESP-SR的唤醒词做免提唤醒，识别到“你好糖球”之类的关键词后开始录音。再进一步是做VAD（语音活动检测），自动检测到人声结束后停止录音并上传。我实际产品里做的是：唤醒词触发开始，VAD检测结束。三件事分层处理，每一层都不会占用过多CPU。

值得注意的坑是，I2S采集的DMA缓冲区大小设置要匹配网络发送的节奏。如果缓冲区太小，中断太频繁，CPU占用高；太大则录音延迟高，导致一句话说完后要等很久才开始上传。我调试下来，DMA缓冲区设置为480样本（约30ms）比较合适，配合FreeRTOS的流缓冲，把音频数据按100ms一个包推送出去，整体体验最顺。另一个血泪教训：麦克风的参考电压和供电纹波直接影响底噪。模拟麦克风必须用低纹波的LDO单独供电，千万别和屏幕背光共用电源，否则屏幕上亮度变化时，扩音器里全是滋滋的电流声。

2.3 网络选型：WiFi连接与通信协议

通信方式上，ESP32-S3通过WiFi连接局域网，后台服务跑在同一局域网内的PC或服务器上。采用HTTP还是WebSocket，主要看对实时性的要求。如果只是“录完音上传，拿结果返回”，HTTP短连接就够了。但做对话型语音助手时，用户说完话后希望尽快看到反馈，最好是“边说边传”的流式模式，这时候WebSocket就合适得多。

我最终用的是WebSocket做双向通信通道，JSON封装消息。从ESP到后台发音频数据时，用WebSocket是二进制帧，后台按流式处理；后台返回结果时，按文本帧推送，包含状态码、文字内容、播放指令、表情动画指令等。如果后台配置了流式输出（就是大模型一边生成一边吐字），还可以做成“打字机效果”，屏幕上文字逐个出现，体验比等全部生成完再一次性显示强太多了。

网络上额外要考虑的是断线重连和心跳机制。WebSocket连接如果长时间没有数据传输，可能会被路由器或系统断开，所以客户端需要定期发ping，服务器回pong。另外，ESP端的WiFi省电模式默认会影响延迟，我直接关掉了WiFi Modem Sleep，功耗大了点，但延迟从几秒降到几百毫秒，代价完全值得。

2.4 与后台模型对接：从语音到文字再到语音的完整链路

后台框架我用的Python实现。WebSocket服务接收音频帧，先做语音识别（ASR），把音频转成文本；文本交给大语言模型服务（比如本地模型框架）生成回复；回复文本再交给语音合成（TTS）生成音频，最后把音频和文本一起推回ESP端。这整条链路里最值得注意的点是，ASR、LLM、TTS都是独立服务，不要把它们写死在同一个进程里，要让它们可以独立重启。

我给这三个环节分别设计了端口和接口，ASR用WebSocket接收音频、返回文本，LLM用HTTP或SDK方式调用，TTS用HTTP上传文本、返回音频二进制。这样哪个环节挂了、哪个模型效果不好，都可以单独替换和调试。像TTS这块，我试过好几套方案，有的音色自然但延迟高，有的速度快但机械感强，最后还是选了可以在本地运行、延迟相对可控的方案，具体到项目上可以根据自己的硬件和网络条件权衡。

协议设计上，我定义了一条比较简单的消息规范。后台返回给ESP的每条消息都包含一个type字段，用来区分是纯文本显示、是音频播放、还是UI动画指令。有的消息带文本字段，有的带音频数据字段，有的两者都有。比如用户问完天气后，后台返回文本“今天晴，25度”加一段TTS音频，ESP先把音频解码播放，同时屏幕上把文本显示出来，再根据type字段触发一个天气动画。这样协议保持简单，端侧的解析逻辑也清晰。

3. 实操过程：从环境搭建到端侧代码落地

3.1 ESP-IDF开发环境搭建与编译问题排查

开发框架我用的乐鑫官方ESP-IDF，版本是v5.x。Windows下安装的时候，IDE自带的安装工具会自动把工具链、Ninja、CMake这些装好，听起来省心，但实际坑不少。最常见的就是安装路径问题，如果路径有中文或者空格，Ninja在编译的时候会报各种莫名其妙的错误，比如找不到头文件或者无法生成构建文件。

我自己遇到过的典型问题，是这个报错：

终端进程“c:\app\esp\espressif\tools\ninja\1.12.1\ninja.exe”已终止，退出代码 1

这种问题我会按四个方向排查。一是检查项目路径和ESP-IDF路径有没有中文、空格，有就改成纯英文路径；二是看内存是不是不够，Windows下同时开着IDE、浏览器、微信再加上编译，内存很容易吃紧，Ninja分配不到内存就直接挂；三是删除build目录重新编译，排除CMake缓存损坏的干扰；四是暂时关闭杀毒软件，有些杀毒软件会对ninja生成的可执行文件做实时扫描，导致进程被误杀。

编译配置也需要注意。第一次编译时，我直接用默认的sdkconfig，结果WiFi吞吐率特别低，后来才发现是默认开启了省电模式，导致WiFi模块频繁休眠。正确的做法是，在menuconfig里把WiFi省电关掉，同时把TCP/IP的收发缓冲区调大一点，这样音频数据传输才稳定。

3.2 ESP端代码结构：音频采集、屏幕刷新与状态机

端侧代码我按模块划分，main目录下放了几个核心文件。音频采集模块负责初始化I2S接口，把麦克风数据读取到环形缓冲区；网络模块管理WiFi连接和WebSocket的建立、重连；UI模块用LVGL实现屏幕上的所有界面；状态机模块是整个设备的主干，负责协调音频、网络和UI之间的切换。

状态机的设计非常关键。糖球的典型状态包括“待机”“唤醒中”“录音中”“等待后台回复”“语音播报中”“网络异常”等。每一种状态下，用户交互和屏幕显示内容都不一样。比如待机状态屏幕显示表盘或者待机动画，听到唤醒词后进入唤醒中状态，屏幕显示聆听动画，同时开始录音。录音结束后自动切换到等待回复状态，屏幕上显示正在打字的效果。收到后台回复后，切换成语音播报状态，屏幕同步显示文字。

状态管理最怕的是状态错乱，比如用户还在说话，后台结果就返回了；或者网络断开后，录音还停在录音状态。所以我的状态机只在主循环和事件回调中切换，加了一个专门的锁机制保护共享数据，同时给网络断线设置了超时检测，超过三秒没有心跳响应就强制回退到网络异常状态，提示用户检查网络。

代码结构大致是这样：

// 状态机核心数据结构 typedef enum { STATE_IDLE, STATE_WAKEUP, STATE_LISTENING, STATE_WAITING_REPLY, STATE_SPEAKING, STATE_NETWORK_ERROR } sys_state_t; // 主循环中持续运行状态机 void app_main(void) { // 初始化各模块 audio_init(); wifi_init(); ws_client_init(); ui_init(); // 状态机主循环 while (1) { state_machine_tick(); vTaskDelay(pdMS_TO_TICKS(10)); } }

3.3 后台语音客户端：VAD、ASR、LLM、TTS的串联

后台部分，我写了一个Python脚本直接串起整条链路。这个脚本监听来自多个ESP客户端的连接，每收到一段音频帧，先缓存到临时缓冲区；当检测到语音停止（通过VAD判断）或者客户端主动发送结束标志时，调用ASR接口识别文字；将识别结果送入大语言模型服务生成回答；回答文本再送入TTS服务生成语音；最后把文本和语音一起推回给ESP端。

VAD我用的WebRTC VAD库，它专门检测人声和非人声，对于静音、噪音的容忍度还可以。这里有个经验：单纯的VAD容易把气流声、键盘声误判为人声，所以实际处理时要结合能量阈值和时间长度做双重判断，只有持续超过一定时间且能量超过阈值才认为是有效语音。

后台代码的一个核心片段：

# 收到完整音频后，串联ASR/LLM/TTS def handle_full_audio(audio_bytes): # 1. 语音识别 text = asr_engine.recognize(audio_bytes) if not text: send_to_esp({"type": "hint", "text": "没有听清，请再说一遍"}) return # 2. 交给大模型获取回复 reply = llm_client.chat(text) # 3. 文本转语音 tts_audio = tts_engine.synthesize(reply) # 4. 推给ESP显示和播放 send_to_esp({"type": "reply", "text": reply, "audio": tts_audio})

链路里最影响体验的是TTS延迟，所以我把TTS做了缓存，常用回复短句提前生成好音频，命中缓存就直接播放，能省几百毫秒。

3.4 屏幕反馈优化：让用户始终知道设备在“听”和“想”

屏幕反馈是整个交互体验的灵魂。圆屏虽然小，但反馈及时性直接决定用户觉得这个设备“灵不灵”。我做了几层优化，第一是录音时屏幕有个动态的音量波动动画，用LVGL画一圈圆弧，根据音频RMS值实时调整圆弧长度，让用户一眼就知道设备正在收音。

第二是等待后台回复期间，屏幕中央显示一个呼吸灯效果的小圆点，同时旁边显示“思考中...”之类的文字。这个动画虽然简单，但能显著降低用户因等待产生的焦虑感。实测下来，加了这层反馈后，用户普遍觉得设备“反应变快了”，其实后台速度没变，只是用户在等待期有事可看，感知延迟降低了。

第三是文字显示采用逐字弹入效果，模拟打字机。收到后台完整文本后，不一次性刷出来，而是按每帧显示一部分的方式逐步出现。配合LVGL的textarea控件，用定时器每50ms追加几个字符，实现类似ChatGPT打字流的效果。一点小技巧：追加字符时如果遇到标点符号，可以多停顿一两帧，读起来更像真人说话节奏。

3.5 语音播报与文字显示同步

后台返回的TTS音频格式，我用的MP3还是WAV，需要根据ESP端的解码能力决定。ESP32-S3要解码MP3，一般需要软件解码，比较吃CPU；WAV的话直接I2S就能播放，几乎不占额外资源。为了控制延迟和降低CPU占用，我在TTS服务端直接把合成结果转成16kHz单声道WAV，ESP端拿到WAV数据直接进DMA播放，一路畅通。

音频播放和文字显示同步这一步，要做到“说了哪段字，就高亮显示到哪段”。最简单的实现方式是后台TTS返回时同时返回每个句子的时间戳，ESP播放音频时根据时间戳动态更新文字高亮位置。但做完整对齐工作量不小，我在第一版里偷了个懒，采取了一个近似方案：先等TTS音频全部播完，然后在播完的同时把全文一次性显示出来。实际体验还行，但缺少逐句对应感。后来优化成把文本按中文标点切分为短句，每播放一句话前先显示该句话的文字，看起来也接近逐句高亮的效果，代码却简单得多。

4. 常见问题与排查技巧实录

4.1 ESP-IDF编译环境反复出问题

这一节先说编译。很多初学者卡在环境上，最典型的几个表现：Ninja进程崩溃、找不到工具链、编译到一半报内存不足。我总结了一套固定排查流程，遇到就按顺序检查，基本都能解决。

第一步，确认路径。项目目录、ESP-IDF目录、用户文件夹这三个路径都要是纯英文，不能有空格。Windows用户名如果是中文，也会引发很多奇怪问题，最简单的办法是换个英文路径重新clone项目。第二步，确认内存。编译ESP-IDF工程，尤其是首次全量编译时，建议保证系统有至少8GB可用内存，IDE加其他应用一起跑很容易不够。第三步，删掉build目录和sdkconfig重新配置，有些时候是配置缓存和当前环境不匹配。第四步，关杀毒软件，这一步听着玄幻，但真的有效。

另外还要注意，ESP-IDF自带的espressif.exe installer一键安装工具，在Windows下有时会用到旧版本工具链，导致编译错误。如果遇到新版本组件编译失败，建议去乐鑫官网下载最新版的ESP-IDF Tools Installer，完全重装一遍，不要用老版本升级上来。我自己重装后，很多诡异问题就消失了。

4.2 收音和识别效果不佳的调优方向

如果你做好之后发现后台识别准确率低，先说结论：问题八成出在音频采集端，而不是模型不够好。常见的原因有麦克风采样率设置错误、数据溢出导致削波、背景噪声太大等。

采样率必须和后台ASR要求的输入一致，我用的16kHz，后台ASR也要求16kHz，如果两端不一致，识别效果会断崖式下降。麦克风增益也一样，太大会导致削波，声音破音；太小则信噪比不足，安静环境下都识别不好。我调试的时候，先通过串口把采集到的原始音频导出到PC，用Audacity打开，看波形和频谱，就能直观发现问题。

特别是模拟麦克风的电路设计，电源一定要干净。我之前用ESP32-S3开发板的3.3V给模拟麦克风供电，屏幕一亮，音频底噪立刻明显增加。后来换成一棵独立的低噪声LDO给麦克风供电，电源纹波从几十毫伏降到几毫伏，底噪问题明显改善。另有几个方向可以尝试，拾音孔开孔位置如果太靠内，人声反射会造成梳状滤波效应，声音发闷；麦克风尽量靠近设备正面开孔，周围不要有遮挡。

4.3 后台服务状态异常或者连接不稳定

设备偶尔连不上后台服务，网络上用的名词叫做“后台有进程但面板不显示”，其实也是后台服务没有正常监听端口。我排查这个问题的思路是，先看后台进程是否真的启动成功，然后在同一局域网内用手机或电脑的浏览器访问后台HTTP端口，能不能通；再查看防火墙有没有拦截端口。Windows防火墙经常默认拦截Python进程监听外部端口，需要在入站规则里放行对应端口。

另外，如果后台服务是多进程模式，比如线程池开了多个工作进程，要注意每个进程是否正确绑定了端口。用netstat -ano | findstr 端口号可以快速确认端口监听状态。如果是WebSocket服务，还可以用在线的WebSocket测试工具做连接测试，确认不是客户端代码的问题。

设备端问题多见于WiFi信号强度弱、路由器开启了客户端隔离功能，导致设备无法访问局域网内其他设备。遇到连不上后台时，首选排查方法是：在ESP端串口日志里看WebSocket连接错误码，是DNS解析失败、TCP连接失败还是服务端主动断开，然后对照排查。还有一个坑是无线路由器开启了AP隔离或访客网络模式，导致同一WiFi下的设备之间不能互通，这种情况下无论如何调代码都白搭，优先换网络环境验证。

4.4 圆屏显示卡顿、刷新率低

圆屏卡顿的原因，排在第一位的永远是SPI刷新方式不对。如果不用DMA，CPU光刷屏就占用大量时间，音频和WiFi全都要受影响。所以第一步是确认SPI是否启用了DMA传输，LVGL的刷新回调里是否直接用了spi_device_polling_transmit这种阻塞式接口，如果用了，改成spi_device_queue_trans异步发送。

第二是LVGL的缓冲区大小。LVGL实际使用时会从内部buffer读取像素绘制。Buffer太小会导致频繁刷屏和撕裂，太大则内存紧张。我这边开了双缓冲，每个buffer分配了屏幕总像素的1/10，大概240x240x2除以10等于11520字节，两个缓冲区总共23KB左右，在ESP32-S3的PSRAM加持下完全不是问题。开启PSRAM后，可以把LVGL的buffer放在PSRAM里，不占用内部SRAM，进一步降低内存压力。

第三是屏幕SPI时钟频率。GC9A01这个屏理论上可以跑到80MHz，但实测超过40MHz后，部分模组会出现花屏和颜色错位，特别是杜邦线连接的时候，信号完整性差，更容易出问题。所以我最终锁定了40MHz，稳定性和速度兼顾。如果用了PCB软排线连接，可以尝试60MHz到80MHz，但需要做长时间稳定性测试。

第四是渲染耗时，LVGL画圆弧、画图片、文字抗锯齿都是CPU密集操作。如果渲染函数占用太长时间，会阻塞主循环，导致音频、网络处理不及时。针对这个，我做了两个优化，一是把常用背景图和图标做成C数组，避免从Flash读取时因为SD卡或文件系统IO慢而拖慢渲染；二是尽量少用透明度混合效果，圆屏小，纯色和简单边框就足够美观。

4.5 后台模型返回内容过长导致截断

这个问题很常见，大模型默认输出长度可能超过实际需要，后台和客户端又没有做处理，于是屏幕上显示到一半就截断了，或者TTS播报时只说了一部分。之前热搜里有人提到“达到输出token上限回答被截断”，本质就是这个问题。

我的处理方式是，对话提示词里直接限定回复长度，要求模型用两到三句话、不超过50个字回答，适合口语播放；后台侧再设置一个最大token数，从默认的2048收紧到256，这样即使模型“话痨”也不会返回一大段长文；TTS合成前还要做一次文本长度检查，超过设定长度就截断到最近的标点符号，避免播放时话说到一半突然中断。另外，客户端收到超长文本时，可以设计一个分页或滚动显示机制，但语音播报一定要截断，否则用户体验极差。

4.6 关于“后台有进程但面板不显示”的补充

这一类问题在Windows上格外常见。我调试后台服务时也遇到过几次，进程列表里明明有python.exe在跑，但控制台窗口或者自带Web面板打不开。排查的顺序，我建议是先确认端口是否真的在监听。

netstat -ano | findstr 8000

如果没有任何输出，说明服务根本没绑定端口，进程可能在启动初始化阶段卡死了，此时去看日志文件最直接。如果端口有监听，但浏览器访问不通，那大概率是防火墙拦截，或者服务绑定的是127.0.0.1，而不是0.0.0.0。绑定地址是127开头时只有本机能访问，局域网内其他设备肯定连不上。解决办法是把服务启动的主机地址改成0.0.0.0，也就是监听所有网卡地址，这样局域网内的ESP设备就能正常访问了。这个问题我在不看文档的时候踩过好几次，查出来之后感觉特别基础，但就是容易忽略。

5. 一些体会和小技巧

这套“ESP圆屏做后台语音客户端”的方案，做下来最大的心得是，先想清楚“端侧到底应该做什么”再动手。很多人一听说语音助手，直觉就是设备端要跑模型，但实际上对桌面设备来说，后台有算力、有成熟模型生态，端侧把采集、显示、交互做好，系统的上限会高很多。

还有两个细节想特别强调。一个是音频数据格式统一，从麦克风采集到ASR识别再到TTS播放，整条链路里的采样率、位深、声道数必须完全统一，我统一成16kHz/16bit/单声道后，出问题的概率大幅下降。另一个是日志系统一定要从一开始就建好，端侧用串口日志，后台用文件日志，每次出问题先看日志再猜原因，排查效率天差地别。

最后再分享一个实际优化技巧：为了让语音对话的“回合感”更自然，我在ESP端加了一个“播放结束”的回调事件，TTS音频播放完成之后，设备会主动进入待机状态，并且屏幕回到待机界面。这个细节看似不起眼，但实际体验中非常关键，不然设备会一直停留在“播报完”的状态，用户再说话时，状态机可能还卡在语音播报里，导致下一轮对话无法触发。加上这个回落后，整套交互的连贯性算是基本到位了，糖球这个项目到这里也就算是不跑模型但足够好用的一个完整语音客户端了。