2023 年 7 月初，我在我个人的推特上公开了一系列创业脑洞，在众多推友的参与和反馈之后，我选定了做 AI 儿童陪伴玩具的想法。借助「改造火火兔」大概一个月左右我们验证通所有的产品化技术难点，网友们都在安静等待着产品发布，我自己反而觉得越来越着急，这是一个月遇到技术问题的汇总，希望也能给其他做 IoT 硬件产品的朋友以启发。

我们没有选用树莓派之类的可以运行完整 Linux 的方案，而是采用了 ESP32 嵌入式方案，我们希望模块可以做得非常小，功耗低，成本也低，这样我们就需要自己搞定硬件的设计和固件的开发，也就遇到了后续的这些问题。

开始的选择了 ESP32S3 模块，搭配数字麦克风，第一版硬件做出来以后，发现数字麦克风在 USB 充电时总是会受到干扰，导致录音噪声太多以致不能识别语音，经过多次尝试，始终无法解决问题，我认为这种缺陷无法接受，需要调整。在测试玩具自带的模拟麦克风时，发现效果非常好，于是尝试使用自带麦克风。

起初想法是用户在拿到板子后，不需要自己运行服务程序，只需在固件中配置好 OpenAI 和 Azure 的 APIKey 就可以使用，在做了一些测试之后，发现芯片计算能力有限，从录音到播放生成的回复语音这段过程耗时太长，这样的体验让人难以接受，而把语音处理的过程放到服务器来实现后，回复较短的情况下，整体的响应的速度提高到 3-5s。

ChatGPT 玩具在对话时需要一直在线，是需要联网的 IoT 设备，除了要支持上下行控制指令和配置参数的下发上传，还需要上传下载语音。实现上，在线控制我们使用了 MQTT， 实时发送语音使用单独了 UDP 通道，设备再通过 HTTPS 下载服务器生成好的语音回复文件来播放，数据传输的方案也是遇到一些问题后才确定的。

一开始，我们认为玩具的交互过程非常简单，直接使用 UDP 就可以了，但在实现的过程中发现，服务器在向 ESP32 板子发送 UDP 的语音数据时，会发生非常明显的丢包，从而造成扬声器播放有断断续续的现象，而且不同的电脑运行服务器程序现象还不尽相同，我的 MacBook 体验就很好，而换成 ThinkPad 就丢包严重。

从 UDP 上解决这个问题我感觉难度较大，可能要我们自己做缓存适配硬件解码速度的来播放语音。于是我们从服务器推语音文件转向由板子自己拉(下载)语音文件的方式，流程：板子通过 UDP 上传语音，服务器接收语音后通过 MQTT 下发语音文件 URL，在服务器完成所有的接口调用和语音处理之后，通知板子下载语音。

到此，技术上主要的问题都已经解决，此外我们还做好了通过 Web 更新固件，配网，定义好了灯的状态，而且芯片换为资源更多的 ESP32，从而有足够的 Flash 用于存储出厂固件等。

然后就有了接下来的故事。