企业官网建设流程全解析

1. 项目概述：一块开发板如何长出“AI灵魂”

你手边那块不到百元的 ESP32-S3 开发板，它真就只是个带 Wi-Fi 和 USB 的微控制器吗？我去年在调试一个智能盆栽监测项目时，随手给它接上 OV2640 摄像头模组、插上麦克风和扬声器，再烧录一段轻量语音唤醒代码——结果那天晚上，它第一次用合成语音对我说：“土壤湿度偏低，需要浇水。”那一刻我意识到：ESP32-S3 不是终点，而是端侧 AI 的起点。它不是要替代大模型，而是成为大模型在物理世界里的“手”和“眼”。我们做的这件事，就是把一块裸板，变成能听、能看、能思考、能反馈的 AI 陪伴设备；而支撑它的，不是单点功能堆砌，而是一套可生长、可回滚、可监控、可替换模块的端云架构。关键词里反复出现的ESP32-S3、AI、端云架构，不是并列关系，而是层级依赖：ESP32-S3 是硬件锚点，AI 是能力内核，端云架构是演进骨架。它不追求“无禁词”“无审核”这类虚浮标签，而是直面真实场景中的约束——功耗要压到 80mA 持续运行，响应延迟不能超过 1.2 秒，离线时基础对话必须可用，云端升级失败后能自动回退到上一稳定版本。这套架构已在我家老人陪护设备中稳定运行 117 天，期间完成 3 次模型热更新、2 次协议升级、1 次硬件传感器替换，全程无需拆机或重刷固件。如果你正卡在“AI 小项目总做不长”“一加功能就崩”“改个提示词就要重烧整个固件”的阶段，这篇就是为你写的实操笔记。

2. 整体设计思路：为什么必须是“端云协同”，而不是“端侧全包”或“纯云端”

2.1 三个现实铁律，决定了架构必须分层

很多开发者一上来就想让 ESP32-S3 跑 Llama-3-8B 或 Qwen2-VL，我试过，也劝退过至少 7 位朋友。不是技术不行，而是被三道物理铁律死死卡住：

第一道是内存墙。ESP32-S3 最大 PSRAM 是 8MB（常见板载仅 2MB），而哪怕量化到 INT4 的 Phi-3-mini（3.8B 参数），推理所需显存也超 1.8GB。这不是“优化一下就能跑”，是数量级断层。你拿 8MB 去塞 1800MB 的东西，就像往保温杯里倒一整桶水——漏得比装得快。

第二道是功耗墙。ESP32-S3 在 240MHz 主频 + Wi-Fi 连续传输下，峰值电流达 180mA。若强行加载模型推理，散热片都来不及导热，芯片温度 3 分钟飙到 85℃，触发 thermal shutdown。而真实陪伴设备要求 7×24 小时待机，平均功耗必须控制在 25mA 以内（靠深度睡眠+事件唤醒）。模型推理这种“重活”，必须交给能散热、有电源、可扩容的云端。

第三道是演进墙。AI 能力不是写死的。上周你用的天气问答 prompt，下周可能要接入医院挂号 API；这个月识别的是老人跌倒动作，下个月要加宠物异常行为检测。如果所有逻辑都固化在端侧，每次变更都要用户手动下载 bin 文件、按住 BOOT 键、打开串口工具——这根本不是产品，是电子积木说明书。

所以我们的架构选择不是“技术炫技”，而是对这三道墙的务实回应：端侧只做确定性高、实时性强、资源消耗低的事；云端承担不确定性高、计算密集、需持续迭代的事；两者之间用极简协议桥接，确保任何一方故障，另一方仍能降级运行。

2.2 端云职责切分：一张表说清谁该干什么

我们把所有功能按“确定性”“实时性”“资源消耗”三个维度打分（1~5 分），最终划出清晰边界。这张表是我和团队在 3 轮硬件压力测试、11 次用户场景模拟后定稿的，不是理论推演：

这个切分不是静态的。比如当 ESP32-S3 升级到 S3-WROOM-2（带 8MB PSRAM），我们已在测试将 YOLOv5n 量化版部署到端侧，用于跌倒检测的初筛——但最终判定仍交云端复核。架构的“可持续演进”，就体现在这种能力边界的动态迁移上。

2.3 架构图不是画出来的，是焊出来的：核心组件选型逻辑

网上很多“端云架构图”画得天花乱坠，MQTT、Kafka、Redis 全堆上去。但我们实际焊板子、写代码、测功耗时，砍掉了所有非必要组件。最终落地的架构只有 4 个核心角色，每个都经过实测验证：

• 端侧通信代理（ESP32-S3 内置）：不接 MQTT 客户端库（太重！），而是用轻量 HTTP Client + 自定义二进制协议。协议头仅 8 字节：[magic:2][ver:1][cmd:1][len:2][crc:2]，命令类型cmd定义为0x01=心跳、0x02=事件上报、0x03=指令下发。实测比标准 MQTT PUB 消息小 62%，解析耗时从 8.3ms 降到 1.7ms。

• 边缘网关（树莓派 4B）：不是必须，但强烈推荐。它作为端云之间的“缓冲带”，解决两个致命问题：一是 ESP32-S3 的 Wi-Fi 在弱信号下频繁断连，网关用有线连接云端，保证消息不丢；二是网关可运行轻量 Python 服务，做协议转换（HTTP→MQTT）、数据脱敏（抹掉 MAC 地址）、本地缓存（断网时存 72 小时数据）。我们用 Flask + SQLite 实现，内存占用恒定 28MB。

• 云端核心服务（Nginx + FastAPI + PostgreSQL）：拒绝微服务陷阱。所有业务逻辑写在一个 FastAPI 服务里，用async处理 HTTP 请求，用threadpool调用模型推理。PostgreSQL 不仅存用户数据，还存设备影子（device shadow）——每个设备在 DB 里有一行 JSONB 字段，记录当前状态（如"light": "on", "volume": 70），APP 和设备都读写这一行，天然解决状态同步。

• AI 模型服务（Ollama + 自研 Adapter）：没上 Kubernetes，就用 Ollama 的原生 API。关键创新是Adapter 层：它接收设备上报的结构化事件（如{"event":"fall_detected","confidence":0.92,"timestamp":1715234567}），动态拼装 prompt，注入用户偏好（如老人语速慢，加请用短句，每句不超过 8 个字），再调用ollama run phi3。Adapter 本身是 200 行 Python，却让同一个模型能适配 17 种不同设备事件。

这个架构没有“高大上”的名词，但每一环都经受过凌晨三点的崩溃日志考验。它不承诺“无限能力”，但保证“每次升级都比上次更稳”。

3. 核心细节解析：ESP32-S3 端侧实现的 5 个生死细节

3.1 电源管理：如何让设备真正“7×24 小时在线”

很多人忽略一点：ESP32-S3 的“低功耗”宣传，是建立在“什么都不干”的理想状态下的。一旦接摄像头、开 Wi-Fi、跑语音，功耗立刻翻倍。我们实测了 4 种供电方案，最终锁定USB PD 诱骗芯片 + 降压模块组合：

• 方案 A：直接插电脑 USB（5V/0.5A）→ 待机电流 42mA，Wi-Fi 连接后 110mA，摄像头工作时 185mA →淘汰（发热严重，PC 端口易过载）
• 方案 B：3.7V 锂电池 + TP4056 充电板 → 待机 38mA，但锂电池电压从 4.2V 降到 3.3V 时，ESP32-S3 的 ADC 读数漂移 12%，温湿度数据失真 →淘汰
• 方案 C：USB PD 诱骗芯片（CH224K）强制协商 9V/2A，再经 MP2315 降压到 3.3V → 待机 22mA，Wi-Fi+摄像头持续工作 78mA，温升仅 12℃ →采用
• 方案 D：PoE 供电（IEEE 802.3af）→ 成本高，需额外 PoE 模块，家庭场景不实用 →放弃

关键细节在于MP2315 的电感选型。原厂推荐 2.2μH，但我们换成 4.7μH 后，纹波从 85mVpp 降到 22mVpp，Wi-Fi 丢包率从 3.7% 降至 0.2%。这是因为 ESP32-S3 的 RF 模块对电源噪声极其敏感，纹波大会直接干扰 2.4G 射频。

提示：不要迷信“低功耗模式”代码。真正的低功耗，始于电源设计。我们把 CH224K 的 PD 协商引脚接到 ESP32-S3 的 GPIO，开机时由 MCU 主动触发协商 9V，避免默认 5V 导致降压模块效率低下。

3.2 摄像头驱动：OV2640 的“隐藏开关”与 JPEG 压缩实战

ESP32-S3 的 USB 摄像头功能（USB Device CDC ACM）常被误认为“即插即用”，其实藏着一个关键开关：必须在 camera_config_t 结构体中显式启用fb_count = 2。否则默认单缓冲，遇到 USB 传输卡顿，图像就会撕裂。我们踩过的坑是：初期用fb_count=1，设备连续运行 4 小时后，USB 描述符错乱，必须拔插才能恢复。

JPEG 压缩不是调个参数就行。OV2640 的 JPEG 压缩质量（JPG_QUALITY）设为 10（最高）时，单帧 640×480 图像约 120KB；设为 30（肉眼难辨差异）时，压缩到 45KB，但 ESP32-S3 的 PSRAM 会因 JPEG 解码临时分配失败而重启。最终方案是双轨压缩：

• 事件触发压缩：运动检测或人脸出现时，用JPG_QUALITY=25，输出 55KB 图像，满足云端识别需求；
• 预览流压缩：APP 端请求实时画面时，用JPG_QUALITY=45，输出 30KB 图像，保证流畅性；

代码层面，我们修改了 esp-idf 的camera.c，在esp_camera_fb_get()后插入自定义压缩函数，绕过 SDK 默认的阻塞式 JPEG 编码，改用 DMA 异步编码，CPU 占用率从 92% 降到 35%。

3.3 语音唤醒：Porcupine 的“静音窗”设置与误唤醒防控

Picovoice Porcupine 是目前端侧唤醒最稳的方案，但它有个致命坑：默认的“静音窗”（silence window）是 1.5 秒。这意味着，只要 1.5 秒没声音，它就自动重置状态机。老人说话常有停顿，一句“小智，今天……（停顿 2 秒）……帮我看看药盒”，就会被切成两段，唤醒失败。

解决方案是重编译 Porcupine 的 C 库。我们找到pv_porcupine.h中的PV_PORCUPINE_SILENCE_WINDOW_MS宏，从 1500 改为 3000，并重新生成libporcupine.a。同时，在唤醒回调中加入双阈值确认：首次检测到唤醒词，不立即响应，而是启动 300ms 计时器，期间持续监听；若 300ms 内再次检测到同一唤醒词（置信度 >0.7），才触发 ASR。这招把误唤醒率从 12.3 次/天降到 0.8 次/天。

注意：Porcupine 的唤醒词模型必须用官方训练工具生成，自己用音频剪辑拼凑的 WAV 文件，即使格式正确，也会因采样率抖动导致识别率暴跌。我们实测，同一段录音，用 Audacity 导出和用 SoX 导出，识别率相差 37%。

3.4 安全启动与 OTA：差分升级的“原子性”保障

ESP32-S3 的 OTA 机制（app_update）默认不校验签名，极易被中间人劫持。我们采用双保险机制：

1. 端侧校验：下载差分包后，先用内置 RSA-2048 公钥验证签名，再计算 SHA256 与云端下发的 hash 对比；
2. 云端控制：差分包生成时，Ollama 服务调用bsdiff生成 patch，同时用私钥签名，签名随 patch 一起下发；

最关键的细节是分区擦除的原子性。ESP32-S3 的 OTA 分区（0x10000）大小固定，但差分包可能大于分区。我们强制规定：差分包体积不得超过 OTA 分区的 85%。升级时，先擦除整个 OTA 分区，再写入 patch，最后跳转。如果写入中途断电，bootloader 会检测到 OTA 分区无效，自动回退到 factory 分区（0x1000）的旧固件。这个“擦除-写入-跳转”三步，必须用esp_ota_begin()/esp_ota_write()/esp_ota_end()严格封装，不能用裸 flash API。

3.5 端云协议：为什么不用 MQTT，而用自定义二进制 HTTP

MQTT 看似标准，但在 ESP32-S3 上有三大硬伤：

• 内存占用高：Paho MQTT 客户端库编译后占 Flash 120KB，PSRAM 45KB，挤占本就不宽裕的资源；
• 连接脆弱：MQTT 的 keepalive 机制在 Wi-Fi 信号波动时，常出现“连接假死”——设备以为在线，云端以为离线；
• 调试困难：MQTT 报文是二进制，抓包后需用 Wireshark 解析，无法直接用 curl 测试。

我们回归本质：设备只需“上报事件”和“接收指令”。于是设计了极简 HTTP 协议：

• 上报事件：POST /v1/event HTTP/1.1，Body 是紧凑 JSON：{"d":"esp32s3-abc123","t":1715234567,"e":"motion","p":{"x":320,"y":240}}
• 接收指令：GET /v1/cmd?d=esp32s3-abc123 HTTP/1.1，返回{"c":"led_on","p":{"pin":2,"dur":5000}}

所有字段名用单字母缩写（d=device_id,t=timestamp,e=event,p=payload），JSON 无空格，Body 平均大小 68 字节。实测在 20dBm 信号下，单次 POST 耗时 112ms（含 DNS 查询），比 MQTT PUB 快 40%。调试时，直接curl -X POST http://your-api.com/v1/event -d '{"d":"test","e":"test"}'，秒级验证。

4. 实操过程：从零搭建端云架构的 7 个关键步骤

4.1 步骤 1：硬件准备与底层固件烧录（30 分钟）

这不是“插上线就完事”，而是决定后续所有环节稳定性的地基。我们用的是ESP32-S3-DevKitC-1（带 8MB PSRAM），搭配以下外设：

• 摄像头：OV2640 模组（注意选带 FIFO 的版本，否则无法 USB 摄像头模式）
• 麦克风：SPH0641LU4H（I2S 接口，信噪比 65dB，远超普通 MEMS 麦克风）
• 扬声器：PAM8403 放大器 + 2W 3Ω 喇叭（直接接 ESP32-S3 的 I2S DAC）
• 电源：USB PD 诱骗模块（CH224K）+ MP2315 降压（3.3V/3A）

烧录固件前，必须执行3 项底层配置：

1. Flash 模式设置：用 esptool.py 烧录前，执行esptool.py --chip esp32s3 --port /dev/ttyUSB0 set_flash_mode dio。ESP32-S3 默认 QIO 模式，但某些 OV2640 模组只兼容 DIO，不设会黑屏；
2. PSRAM 初始化：在sdkconfig中开启CONFIG_ESP32S3_SPIRAM_SUPPORT=y和CONFIG_SPIRAM_SPEED_80M=y，否则 8MB PSRAM 无法被识别；
3. USB Device 配置：在menuconfig中进入Component config → USB OTG → USB Device Support，勾选CDC ACM和Mass Storage，并设置Vendor ID=0x1234,Product ID=0x5678（避免与 Windows 驱动冲突）。

实操心得：第一次烧录务必用esptool.py --chip esp32s3 --port /dev/ttyUSB0 --baud 921600 write_flash -z 0x0 build/bootloader/bootloader.bin 0x8000 build/partition_table/partition-table.bin 0x10000 build/ai_companion.bin全量烧录。跳过 bootloader 或 partition-table，后续 OTA 会失败。

4.2 步骤 2：端侧代码框架搭建（2 小时）

我们不从零写，而是基于ESP-IDF v5.1.2 + PlatformIO构建。关键目录结构如下：

ai_companion/ ├── main/ │ ├── app_main.c // 主循环：初始化硬件、启动任务 │ ├── camera_task.c // 摄像头采集与 JPEG 压缩 │ ├── audio_task.c // 麦克风采集、Porcupine 唤醒、Vosk-Lite ASR │ ├── network_task.c // HTTP Client、心跳、事件上报 │ └── ota_task.c // 差分包下载、校验、写入 ├── components/ │ ├── porcupine/ // Picovoice Porcupine SDK（已重编译，静音窗 3s） │ └── vosk_lite/ // Vosk-Lite 模型（200 词库，<1MB） └── model/ // 本地 TTS 缓存（MP3 文件，预生成常用回复）

核心是network_task.c中的 HTTP 客户端。我们没用 esp_http_client，而是用lwip raw API自写，原因：esp_http_client 会自动重连、重试，但在弱网下反而加剧功耗。我们实现的是“一次发送，超时即弃”：

// 精简版伪代码 err_t http_post_event(const char* json) { struct netconn *conn = netconn_new(NETCONN_TCP); netconn_connect(conn, &server_ip, 80); netconn_write(conn, "POST /v1/event HTTP/1.1\r\n", ...); netconn_write(conn, "Content-Length: ", strlen(json)); netconn_write(conn, json, strlen(json)); // 设置超时：5 秒内无响应，关闭连接 netconn_set_recvtimeout(conn, 5000); netconn_delete(conn); return ERR_OK; }

这样，一次 POST 内存占用仅 1.2KB，比 esp_http_client 的 8.7KB 少得多。

4.3 步骤 3：云端服务部署（1 小时，Ubuntu 22.04）

我们用最简栈：Nginx（反向代理）+ FastAPI（Python 3.10）+ PostgreSQL 14。不装 Docker，直接系统安装，避免容器层额外开销。

• PostgreSQL 初始化：

  CREATE DATABASE ai_companion; \c ai_companion CREATE TABLE devices ( id SERIAL PRIMARY KEY, device_id VARCHAR(32) UNIQUE NOT NULL, shadow JSONB DEFAULT '{}'::jsonb, last_seen TIMESTAMP WITH TIME ZONE DEFAULT NOW() );

• FastAPI 核心路由（main.py）：

  from fastapi import FastAPI, HTTPException from sqlalchemy import create_engine import json app = FastAPI() engine = create_engine("postgresql://user:pass@localhost/ai_companion") @app.post("/v1/event") async def handle_event(event: dict): # 1. 校验 device_id # 2. 更新 devices 表的 shadow 字段（用 JSONB 的 || 操作符合并） # 3. 若 event.e == "fall_detected"，触发异步 AI 分析任务 return {"status": "ok"} @app.get("/v1/cmd") async def get_cmd(device_id: str): # 从 devices 表读取 shadow，提取 pending_cmd 字段 return {"c": "led_on", "p": {"pin": 2}}

• Nginx 配置（/etc/nginx/sites-available/ai-companion）：

  server { listen 80; server_name api.yourdomain.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

注意：PostgreSQL 的shadow字段用 JSONB，不是 TEXT。这样才能用UPDATE devices SET shadow = shadow || '{"light":"on"}' WHERE device_id='abc123'原子更新，避免并发写覆盖。

4.4 步骤 4：AI 模型服务对接（1.5 小时）

Ollama 安装后，拉取phi3:3.8b模型：

ollama pull phi3:3.8b

但直接调用ollama run phi3无法满足设备事件驱动。我们写了一个Adapter 服务（Python + Flask），它监听/v1/ai/invoke：

@app.route("/v1/ai/invoke", methods=["POST"]) def invoke_ai(): data = request.json # data = {"device_id": "abc123", "event": "fall_detected", "payload": {...}} # 1. 从 PostgreSQL 读取用户偏好（如语速、方言） user_pref = get_user_pref(data["device_id"]) # 2. 动态拼装 prompt prompt = f"""你是一个居家陪伴助手，用户是{user_pref['age']}岁老人。 当前事件：{data['event']}，置信度{data['payload'].get('confidence', 0.9)}。 请用不超过 10 个字的短句回复，语速放慢。 回复：""" # 3. 调用 Ollama API response = requests.post( "http://localhost:11434/api/generate", json={"model": "phi3:3.8b", "prompt": prompt, "stream": False} ) return {"reply": response.json()["response"]}

这个 Adapter 是 AI 能力的“翻译官”，把设备的冰冷事件，翻译成有温度的回复。

4.5 步骤 5：端云联调与压力测试（3 小时）

联调不是“能通就行”，而是模拟真实地狱场景。我们用3 台设备 + 1 台树莓派网关 + 1 台 PC 压测机进行：

• 场景 1：弱网模拟
  用tc命令在树莓派上限制带宽：tc qdisc add dev eth0 root netem loss 5% delay 200ms。观察设备是否在丢包下仍能维持心跳，事件是否堆积后批量上报。

• 场景 2：高并发指令
  PC 上用ab -n 1000 -c 50 http://api.yourdomain.com/v1/cmd?d=esp32s3-abc123发起 50 并发请求。检查 PostgreSQL 的shadow字段是否被正确更新，无丢失。

• 场景 3：OTA 断电测试
  在设备下载差分包到 73% 时，直接拔掉 USB 电源。重新上电后，用esptool.py --port /dev/ttyUSB0 chip_id查看当前运行分区，确认回退到 factory 分区。

实测结果：在 5% 丢包、200ms 延迟下，设备 24 小时内事件上报成功率 99.2%；50 并发指令下，shadow 更新无丢失；OTA 断电后 100% 回退成功。

4.6 步骤 6：用户界面（APP）开发（2 天）

APP 不是重点，但必须轻量。我们用Flutter + Riverpod，核心只做 3 件事：

• 设备列表页：从/v1/devices获取在线设备，显示shadow.light状态；
• 实时画面页：用http://your-api.com/v1/stream?d=abc123接收 MJPEG 流（服务端用StreamingResponse实现）；
• 语音对话页：点击麦克风，APP 录音后 POST 到/v1/audio，云端 ASR + AI 后返回文字，TTS 播放。

关键优化：APP 不存设备密钥，所有请求都经 Nginx 的 JWT 验证。用户登录后，Nginx 生成短期 Token（2 小时），APP 每次请求带Authorization: Bearer xxx，Nginx 解析后透传X-Device-ID到后端。

4.7 步骤 7：灰度发布与监控体系（持续进行）

上线不是终点，而是演进起点。我们建立了三层监控：

• 端侧日志：ESP32-S3 的ESP_LOGI输出通过 UART 重定向到syslog-ng，存入 ELK；
• 云端指标：Prometheus 抓取 FastAPI 的/metrics（QPS、延迟、错误率），Grafana 看板实时展示；
• AI 效果追踪：每次 AI 回复后，APP 弹出“是否帮到您？”按钮，点击后上报{"device_id":"abc123","feedback":"yes/no","reply":"..."}

灰度发布流程：新固件先推送给 5 台内部测试设备 → 监控 24 小时错误率 <0.1% → 推送至 5% 公测用户 → 无异常后全量。

5. 常见问题与排查技巧实录：那些没写在文档里的坑

5.1 问题 1：摄像头图像“绿屏”或“花屏”，但日志显示无错误

现象：OV2640 采集的 JPEG 图像，在 PC 端用浏览器打开是绿色噪点，或完全花屏，而ESP_LOGI显示JPEG encoded, size=45232。

排查路径：

1. 首先确认FIFO 模式：OV2640 有两种工作模式——直接 JPEG 输出（需 FIFO 缓冲）和 RGB565 输出（无需 FIFO）。ESP32-S3 的 USB 摄像头模式强制要求 FIFO，如果模组没焊 FIFO 芯片，必花屏；
2. 检查时钟频率：在camera_config_t中，xclk_freq_hz必须设为20000000（20MHz）。设为 10MHz 或 40MHz，都会导致图像错位；
3. 最隐蔽的坑：USB 数据线质量。我们曾用一根 3 米长的廉价 USB 线，图像稳定；换一根 1 米的“高速线”，反而花屏。原因是高速线屏蔽更好，但阻抗不匹配，导致 USB 信号反射。最终解决方案是：在 ESP32-S3 的 USB D+/D- 线上，各并联一个 1.5kΩ 电阻到 GND，消除反射。

实操心得：花屏问题 80% 出在硬件链路。不要急着改代码，先换根线、换个模组、测测时钟。

5.2 问题 2：Porcupine 唤醒率低，尤其在空调噪音下

现象：安静环境下唤醒率 95%，但空调开启后骤降到 30%，日志显示pv_porcupine_process返回PICOVOICE_STATUS_INVALID_ARGUMENT。

根本原因：Porcupine 的音频输入缓冲区（frame_length）与麦克风采样率不匹配。我们用 SPH0641LU4H，采样率 16kHz，但 Porcupine 默认frame_length=512，对应 32ms 帧长。空调噪音是宽频，32ms 帧太短，无法有效滤波。

解决方案：

• 修改porcupine.h，将PV_PORCUPINE_FRAME_LENGTH从 512 改为 1024；
• 重编译 SDK；
• 在audio_task.c中，麦克风采集时，每 1024 个样本才喂给 Porcupine 一次；

效果：空调噪音下唤醒率回升至 88%。额外收获：1024 样本帧让 CPU 负载更均衡，避免突发高负载。

5.3 问题 3：OTA 升级后设备“变砖”，串口无任何输出

现象：烧录新固件后，设备 LED 不亮，串口 `AT+R