桌上这块开发板，成本不到 50 块。
它现在能听懂人说话，也能开口回话。灯还亮着，像个有了脾气的小东西。
半年前刚拿到它的时候，我以为自己做的是个小玩具。做完才发现，玩具背后全是坑。
我把这 5 个坑原样写下来，做硬件 AI 的朋友可以对着排一遍。
01 以为 ESP32 跑不动 AI，方向一开始就错了
立项第一周，我卡在一个问题上：ESP32-S3 那点算力，跑得动语音识别吗？
翻了一堆资料，越翻越焦虑。有人用它跑过量化后的关键词检测模型，效果很勉强。
后来才想明白，这个问题本身就问错了。
ESP32 的定位应该是耳朵和嘴。听和说，它来干。想和算，交给云端。
服务端跑识别和生成，端侧只负责采集音频、播放回话、处理触控。职责一切开，算力焦虑直接消失。
一块 50 块的板子，接上了大模型的大脑。
架构想通的当晚很开心。第二天，新的坑就来了。
02 语音链路的延迟，差点让项目死掉
联调第一天，我说了句"打开客厅的灯"。
3 秒后它才回答。就这 3 秒，体验瞬间廉价，像在对着一个反应迟钝的客服。
拆开整条链路看：录音上传 1 秒，云端识别 1 秒，生成回复 1 秒，下载合成音频再播放 1 秒。每段都在排队。
问题出在串行。所有环节首尾相接，用户对着空气干等。
解法是把"等"拆碎。音频边录边传，识别出了中间结果就先回传，回复文本流式生成，合成一段播一段。
改造后，说完话 800 毫秒内能听到第一个字。800 毫秒是体验的分水岭，踩在线上，产品才算活过来。
03 触控和语音打架，双模交互没人管秩序
这版机器有屏幕，也支持语音。用户一边点屏幕一边说话。
然后状态机崩了。触控指令执行到一半，语音指令进来，两边同时改同一个状态，界面直接抽风。
说到底是缺一个仲裁层。两个输入通道各干各的，没人排队。
我加了一个很简单的优先级状态机。同一时间只允许一个交互通道持有控制权，后来的请求进队列，当前交互结束后再处理。
粗暴，但有效。从此再没出现两边打架的情况。
做双模交互的教训就一条：先定规矩，再写功能。
04 Windows 开发环境的坑，比硬件还多
这块最没技术含量，也最消耗人。
编译环境三天两头出问题。路径里有中文就报错，驱动装错版本烧录失败，某个工具的沙盒权限挡住串口访问，一排查就是一晚上。
最坑的一次，构建脚本在沙盒里跑不了，报错信息还看不出原因。折腾到凌晨才发现，关掉沙盒限制就正常了。
后来我做了两件事，环境从此稳定。
第一，所有项目固定放在同一个纯英文路径下，目录结构写进文档，永不破例。
第二，环境依赖列成清单，从驱动版本到编译器版本，每次换机器照单重装。
土办法，省下来的都是命。
05 技术全通了，最难的是"该说什么"
四个坑填完，整条链路终于顺了。语音秒回，触控灵敏，识别准确。
然后我把机器给家人试用。
我妈玩了 5 分钟，问了天气，设了个闹钟，就放下了。之后再没碰过。
那一刻我明白过来，前面所有的技术问题都有解，唯独"用户为什么要用它"没有现成答案。
后来砍掉了所有炫技功能，只留 3 个高频场景做深。每个场景的对话都逐句打磨，让它在该说话的时候说话，不该说话的时候闭嘴。
硬件的难点在硬件之外，这话我现在逢人就讲。
写在最后
回头看这 5 个坑，有个共同点。
算力焦虑，是架构定位问题。延迟问题，是链路设计问题。双模冲突，是交互秩序问题。环境折腾，是工程习惯问题。用户流失，是产品判断问题。
没有一个坑出在电路和芯片上。
下一阶段我打算给它加上本地唤醒和多设备联动，坑肯定还有，到时候继续写。
你希望 AI 终端帮你做什么？评论区聊聊，说不定就成了下一个功能。