让硬件会说话：ESP32 调用大模型 API

传统硬件是"按死逻辑反应"：按钮按下，灯亮。你给它的每一种反应，都是你提前写死的。AI 时代多了一种可能——硬件能听懂一句你从没预设过的人话，并给出回应。

想象一个场景：你对着桌上一颗巴掌大的板子说"今天会下雨吗"，它停顿一秒，然后用语音答你"杭州今天多云转阴，傍晚有小雨，记得带伞"。这句话不在你的代码里，是大模型现场生成的。这件事的门槛，比你想的低得多：本质上就是 ESP32 把文字发给一个大模型 API，再把回复拿回来——一次你写过无数遍的网络请求，只不过这回发起请求的是一块单片机。

这一节我们把这条链路拆透：每一步在干嘛、难在哪、延迟从哪来、钱怎么算。读完你不一定能立刻跑通一个语音助手，但你会真的理解"AI 硬件"内核是什么，而不是停在"很神奇"的感觉里。

读这篇前，你的板子得能联网——还没搞定的，先看连上 Wi-Fi。这是后面一切的地基：没有网络，板子就够不着云端的大脑。

---

一次对话，发生了什么：四步链路拆解

把你说一句话、板子答一句话这整个过程拆开，其实只有四步。每一步都是一个独立的技术环节，各有各的难点。

第一步：唤醒（板子怎么知道你在跟它说话）

板子不可能一直把你说的每句话都上传云端——那既费流量又不隐私。所以它需要一个本地常驻的"唤醒词检测"：耳朵一直开着，但只在听到"小智你好"这类特定词时才真正醒来、开始录音。

• 在干嘛：本地跑一个极轻量的关键词识别模型，持续听麦克风。
• 难在哪：要省电、要在 ESP32 这种小芯片上实时跑、还得抗噪声不误触发。这一步通常用专门的唤醒词引擎做，不是你随手写几行能搞定的。

第二步：ASR（把你的声音转成文字）

醒来之后，板子开始录你这句话，并把语音转成文字。这一步叫语音识别（ASR，Automatic Speech Recognition）。

• 在干嘛：录音 → 把音频数据传给一个 ASR 服务 → 拿回一串文字。
• 难在哪：ESP32 内存小，存不下整段高采样音频，所以正经做法是流式上传——边录边传边识别，而不是录完再发。流式协议、音频编码、网络抖动处理，都在这一步。

第三步：LLM（把文字发给大模型，拿回答案）

这是最核心、也对你最熟悉的一步：拿到文字后，ESP32 发一个 HTTPS 请求给大模型接口，带上你的问题，等它返回一段回复文字。

• 在干嘛：一次再普通不过的 API 调用——POST 一段 JSON 上去，解析返回的 JSON 拿到回复。
• 难在哪：难点不在"调用"本身，而在 ESP32 上做 HTTPS——要带证书校验、要管鉴权 Key、要解析嵌套 JSON，还得扛住几 KB 的返回体不爆内存。

对会写代码的你来说，这一步的逻辑是最亲切的。先看一个最小示意：

// 伪代码示意：联网后向大模型发一句话（真实实现要带 HTTPS 与鉴权）
String ask(String prompt) {
  HTTPClient http;
  http.begin("https://你的模型服务/chat");   // 大模型接口
  http.addHeader("Content-Type", "application/json");
  int code = http.POST("{\"message\":\"" + prompt + "\"}");
  String reply = http.getString();           // 拿回模型的回复
  http.end();
  return reply;
}

第四步：TTS（把回复文字念出来）

大模型返回的是文字，但你想听到的是声音。所以最后一步把文字转成语音（TTS，Text-To-Speech），从喇叭播出来。

• 在干嘛：把回复文字发给 TTS 服务 → 拿回音频流 → 板子驱动喇叭播放。
• 难在哪：同样是流式问题——理想情况是模型一边吐字、TTS 一边合成、喇叭一边播，这样你感觉不到长时间卡顿。要做到这点，整条链路得是流水线而非"一段段等"。

四步连起来：唤醒 → ASR → LLM → TTS。其中第三步是 AI 硬件的灵魂，前后三步都是为了把"人的声音"和"模型的文字"接通。理解了这四步的分工，你就理解了一大半"AI 硬件"。

---

一段更实在的 HTTPS 调用示例

上面那段伪代码省掉了真实世界里最磨人的部分。这里给一段更贴近能用的示意——注意，它仍然是示意，注释里标了哪些地方要你自己替换或补全，不是复制粘贴就能跑的成品。

#include <WiFiClientSecure.h>
#include <HTTPClient.h>
#include <ArduinoJson.h>   // 解析 JSON 用，需在库管理器里装

// === 下面这些都要换成你自己的 ===
const char* API_HOST = "https://你的模型服务/v1/chat";  // 替换成真实接口
const char* API_KEY  = "你的鉴权Key";                    // 别硬编码进仓库！见下方提醒

String ask(const String& prompt) {
  WiFiClientSecure client;

  // 关键一步：HTTPS 要校验服务器证书。
  // 正经做法是 client.setCACert(rootCA)，把目标服务的根证书贴进来。
  // 下面这行 setInsecure() 是"跳过校验"，仅供你本地调试，千万别用在正式设备上。
  client.setInsecure();   // TODO: 换成 setCACert(...) 并填入真实根证书

  HTTPClient http;
  http.begin(client, API_HOST);
  http.addHeader("Content-Type", "application/json");
  http.addHeader("Authorization", String("Bearer ") + API_KEY);  // 鉴权头

  // 拼请求体。这里的字段名（message）要对齐你的接口文档，不同服务不一样
  String body = "{\"message\":\"" + prompt + "\"}";

  int code = http.POST(body);
  String reply = "";

  if (code == 200) {
    String raw = http.getString();        // 拿到整段 JSON 回复
    // 解析 JSON，从里面取出真正的回复文字。
    // 这里的取值路径（["reply"]）要对齐你的接口实际返回结构
    StaticJsonDocument<2048> doc;          // 2048 字节缓冲，回复长就要调大
    if (deserializeJson(doc, raw) == DeserializationError::Ok) {
      reply = doc["reply"].as<String>();   // TODO: 改成你接口真实的字段路径
    }
  } else {
    reply = "请求失败，HTTP 状态码：" + String(code);  // 方便你排查
  }

  http.end();
  return reply;
}

几个必须你自己补的点，按重要性排：

• 证书：示例里 setInsecure() 跳过了 HTTPS 校验，只能本地调试用。上设备前换成 setCACert() 填真实根证书，否则等于裸奔。
• 鉴权 Key 别硬编码：写死在代码里、再 push 到 Git，Key 就泄露了。正经做法是放进单独的配置、或运行时从安全存储读。
• JSON 字段对齐：请求体的 message、返回里的 reply，全是占位——以你的接口文档为准，不同模型服务的字段名完全不同。
• 缓冲大小：StaticJsonDocument<2048> 是按短回复估的，回复一长就装不下，得调大或改用流式解析。

---

为什么：延迟从哪来、云端还是边缘、钱怎么算

会调用只是表面。真正决定一个 AI 硬件好不好用的，是下面这几笔账。

延迟从哪来

一次"录音 → 上传 → 模型思考 → 下发 → 播放"，端到端常见在 1~3 秒。这个时间花在哪，拆开看就清楚了：

• 网络往返：板子到云、云到板子，来回两趟。Wi-Fi 信号差、跨地域，这部分就涨。
• 模型推理：大模型"思考"本身要时间，问题越复杂、回复越长，越慢。
• ASR/TTS 转换：语音转文字、文字转语音，各自也要时间。

做对话，1~3 秒能接受——人和人聊天也有停顿。但要做实时控制（比如喊一声立刻关灯），这个延迟就嫌长了，得考虑把判断逻辑往边缘挪。

云端 vs 边缘：大脑放哪

把"大脑"放云端最省事——板子只管收发，重活全甩给服务器。但代价是上面说的延迟、以及联网依赖（断网就成砖）和隐私（语音上了云）。

另一条路是边缘/离线 AI：把一个小模型塞进板子本地跑。好处是快、不依赖网、数据不出门；代价是 ESP32 算力和内存有限，只能跑很轻量的模型，能力远不如云端大模型。

现实里常是两者配合：唤醒词、简单指令在本地秒级响应，复杂对话才上云。这一节先把云端这条主路走通，离线那条路属于后面更深的话题。

成本怎么算

云端大模型基本都是按量付费，通常按 token（可粗略理解为字数）计费，输入和输出分别算。一次对话的成本，取决于：

• 你问得多长 + 它答得多长：token 越多越贵。
• 调用频率：一个被频繁唤醒的设备，账单是累加的。
• 用哪档模型：能力越强的模型单价越高。

对一个个人项目，偶尔聊几句几乎不花钱；但要量产成千上万台一直在线的设备，这笔账就得认真算了。省钱的方向：能本地处理的别上云、控制回复长度、给免费/低价模型分流简单问题。

---

故障排查：对不上话，按这个查

第一次让板子调大模型，卡住是常态。照这张表，从最外层往里查：

现象	最可能的原因	怎么办
连不上接口 / connection refused	Wi-Fi 没连上，或接口地址写错	先确认联网正常；核对 API_HOST 拼写和端口
HTTPS 握手失败 / -1	证书没配，或时间不对	调试期可先 setInsecure() 验证逻辑；正式用 setCACert()；ESP32 时间没校准也会握手失败
返回 401 / 403	鉴权 Key 错了或没带	检查 Authorization 头格式、Key 是否过期、有没有写错
请求超时	网络慢，或没设够超时时间	调大 http.setTimeout()；换更稳的网络再试
板子发请求后莫名重启	内存被大回复挤爆	见上方 pitfall：调大 JSON 缓冲或改流式，别 getString() 全读
回复是乱码 / 中文变问号	编码问题	确认接口返回 UTF-8；串口监视器波特率/编码设对
通了但回复内容是错误信息	接口字段对不上	把原始 JSON 打印出来，核对你取的字段路径和实际结构是否一致

排查的总原则：从外往里、一次只动一个变量。先确认网通，再确认能握手，再确认鉴权过，最后才看内容对不对。

---

延伸：两条往下走的路

理解了链路，你会想知道"接下来呢"。两条方向：

• 自己搭个后端中转：与其让板子直连模型服务（Key 暴露在设备上、字段也难改），不如自己起一个小后端——板子只跟你的后端说话，鉴权、拼 prompt、换模型全在服务端做。这是更工程化、也更安全的做法，往 L4 这一级 深入会讲到。
• 去看小智旗舰怎么做完整工程：本节讲的四步链路，实战项目 里的小智旗舰把每一环都落地了——唤醒、流式 ASR/TTS、HTTPS、内存管理。想看"工业级"的样子，去那里逐行拆它。

---

动手挑战

别只看，动手把链路最核心的一环跑通：

1. 先不碰语音：找一个简单的文本 HTTP 接口（哪怕是一个返回天气、或返回一句固定话的接口），让 ESP32 发请求、拿回结果、用串口打印出来。把"板子能从云端拿回一段文字"这件事亲手跑通。
2. 再换成大模型接口：把上面那段示例改成调你的大模型接口，问它一个问题，看串口里能不能打印出它的回答。先让对话"在串口里发生"，语音是后面的事。

卡住了？把你的代码、串口里的报错、还有接口文档一起发给 AI，让它帮你对字段、排错。

---

小结 · 你现在掌握了什么

• 你能说清"硬件接大模型"接的到底是什么：一次 ESP32 发起的 HTTPS API 调用。
• 你看懂了一次对话的四步链路——唤醒 → ASR → LLM → TTS——以及每一步在干嘛、难在哪。
• 你知道了在 ESP32 上做 HTTPS 调用真正要补的是证书、鉴权、JSON 解析和内存这几件事。
• 你能算清云端 AI 的两笔账：延迟从哪来、钱按什么收，以及什么时候该把活儿挪到边缘。

这条链路是所有"会说话的硬件"的共同骨架。把它刻进脑子，再去看任何 AI 硬件项目，你都能一眼看出它在第几步、用了什么方案。

下一步：让大模型不只是"会聊天"——通过 Function Calling / MCP，让它能真的去控制你的硬件，再配合 MQTT 消息总线 把多个设备串起来。从"能对话"到"能动手"，才是 AI 硬件真正的分水岭。