【花雕动手做】ChatCoding 真机闭环演示｜ESP-Mosaico 福州天气时钟完整交互实录

> 标签：*ESP-Mosaico、ChatCoding、ESP-Claw、Vibe Mode、Lua 脚本、硬件在环、IM Channels*

> 导读：

很多人只听说 ChatCoding 能一句话生成硬件脚本，但看不到完整的 Agent 执行链路，更不知道它支持跨 IM 远程调试。本文用「福州天气时钟」轻量化 Demo，完整展示：IM 通道下发指令 → Agent 规划 → 异步调度脚本 → 屏幕独占渲染 → 轮询校验日志 → 持续迭代的闭环，看懂 ChatCoding 不是简单 “生成代码”，而是一套带远程通信、运行监控的硬件自主调试系统。

## 前言

先解释截图里一个很关键的能力：

> 这两张图是 ESP-Mosaico / ESP-Claw 的 **IM Channels（即时通讯通道）** 配对界面，也就是前面微信调试日志的源头：用微信 / QQ / 飞书 / Telegram 远程和板子上的 Claw 对话、下发 ChatCoding 指令。

不用把板子连在电脑串口、不用接入网页控制台，你在微信发一句话，远端 Mosaico 板子上的 Claw 就能接收、生成 Lua 脚本、直接在硬件上跑起来，并且把运行日志、执行结果原路回传到聊天窗口。

之前我们聊过 ChatCoding 的增量天花板、轮播表盘踩坑实录，很多读者会疑惑：

> 一句话发给 Claw 之后，板子内部到底发生了什么？

> Agent 只是吐出 Lua 脚本就完事了吗？

答案是否定的。

ChatCoding 的核心魅力，在于**Agent 会持续接管任务生命周期**：接收来自 IM 通道的指令、生成脚本、调度运行、抢占屏幕资源、定时拉取天气、循环读取运行日志、自动判断是否正常工作，并且开放修改入口。

下面这个天气时钟 Demo，就是非常适合现场演示、给创客理解「远程硬件 Agent 闭环」的标杆案例。

## 案例需求一句话（微信 IM 通道下发）

> 在 ESP-Mosaico 480×480 屏幕上，做一个同屏时钟 + 天气面板，城市锁定福州，全部中文渲染；时钟每秒刷新，天气每 10 分钟拉取一次。

### 最终成品效果（迭代记录）
 

屏幕带圆角边框，分区布局

- 顶部：福州 + 日期、星期
- 中间：大号时分秒，带文字阴影，每秒刷新
- 天气区：实时温度、天气现象、湿度、风速、降雨概率、高低温
- 底部：秒进度条，跟着秒数走动
字体：调用板内自带 Noto Sans SC 中文字体，保证中文不乱码
调度规则：时钟 1s 刷新，天气 10min 网络拉取；任务独占屏幕，避免和其他画面冲突
控制接口：随时修改刷新率、配色、布局；发送`停止`即可终止任务
通信链路：指令从微信 IM 通道下发，运行日志、结果回传聊天窗口

## 完整 Agent 交互链路拆解（对应截图）

说明：*第一次尝试，分别使用了微信、飞书和控制台在线聊天三种IM 通道下发指令，目前偏向于在线聊天，效果好些。*

这就是 ChatCoding 和普通 AI 写代码最大的区别：**多轮自主巡检，不是一次性输出**，整套交互都跑在 IM 消息通道上

1. **Round1：意图解析（IM 收到消息）**
用户在微信发送需求，Claw 通过 IM 通道接收消息，识别目标：创建时钟天气脚本，并且约定全部使用中文反馈。

2. **Round2：调度启动**
Agent 生成 Lua 脚本，调用 Vibe Mode 系统接口，使用 `exclusive="display"` 声明独占屏幕资源，任务命名 `beautiful_clock`，异步启动脚本，并且自动开启日志监听。

> `exclusive="display"` 是 Vibe Mode 的关键机制：防止多个任务同时抢占屏幕，出现画面撕裂、图层冲突。

3. **Round3：延时等待 + 日志校验**
Agent 不会立刻回复完成，主动等待一段时间，读取设备本地运行日志，确认两件事：脚本正常加载、无启动报错。

4. **Round4：日志判读**
日志为空？这里 Agent 有自己的判断逻辑：这个脚本**只有报错时才打印日志**，无日志 = 没有异常，不等于没有运行。
Agent 继续校验：画面是否正常绘制、网络天气请求是否发起。

5. **Round5：长时间运行状态确认**
等待 9 秒后再次巡检：任务还在运行，没有崩溃；首次天气网络请求（2~5s 阻塞）已经跑完，进入主循环。

6. **最终反馈回传 IM**
确认稳定运行后，Agent 把成品说明推送回微信聊天窗口，同时主动告诉用户：支持二次修改、随时关停。

> 对比：普通 AI 代码工具，给到你代码就结束；ChatCoding 的 Agent，是代码交付之后，持续做硬件在环 HIL 监控，并且依托 IM 通道做到**远程双向交互**。

## 【进阶实战：真实网络故障，Agent 自主排错全链路】

上面是网络通畅、接口可达的理想演示。而下面这一组 IM 对话日志，是更贴近创客真实环境的完整记录：同样一句需求，但是外网天气接口被阻断，Agent 独立走完需求解析、硬件探测、真机报错捕获、故障定位、接口降级重试，最终交付可用方案。

> 一句话总览：用户只发送一句「制作显示年月日时分秒和天气的动态数字时钟」，Agent 自主完成 14 轮思考与真机调试，中途遇到 Open-Meteo 接口连接失败，自动切换备用天气源，最终时钟正常运行。

逐轮拆解这条思考链路：

1. **第 1～4 轮：需求解析、硬件识别、方案选型**
Agent 收到 IM 消息里的自然语言需求，拆解两大功能：实时时钟 + 天气 UI。
自动识别硬件载体为 ESP-Mosaico，检索平台可用 Lua 模块：`lvgl`、底层`display`库，评估 UI 方案，梳理整体实现思路。
 关键点：**它先感知当前硬件环境，而不是直接写死一套通用代码**，这和直接输出通用代码的大模型有本质区别。

2. **第 5～9 轮：天气接口真机测试、网络故障自主排查（核心看点）**
Agent 优先选用平台默认 Open-Meteo 天气接口，下发测试代码，直接拿到硬件返回底层错误码 `ESP_ERR_HTTP_CONNECT`。
然后一步步做隔离排查：

- 确认 WiFi 已连接、正常获取 IP，排除未联网；
- 测试`ip-api.com`可以正常请求，证明板子外网通路没问题；
- 校验系统时间正常，排除 TLS 证书时间校验失败；
- 同时测试 HTTP、HTTPS 两种协议访问 Open-Meteo，全部超时失败；

Agent 得出结论：**当前网络环境下 Open-Meteo 域名访问被阻断**。

> 普通 AI：直接写死 Open-Meteo 接口代码，丢给用户，报错由用户自行解决；
> ChatCoding Agent：读取硬件原生错误码，推理根因，主动准备备选数据源。

3. **第 10～12 轮：屏幕硬件自探测**
绘图前必须确认屏幕参数。Agent 自动生成探测脚本读取屏幕信息：识别屏幕型号 CO5300、分辨率 480×480、QSPI 接口 RGB565，拿到准确尺寸之后，再针对性设计 UI 布局。
这就是硬件自发现能力：更换不同规格屏幕，不需要人工修改坐标参数。

4. **第 13～14 轮：异步任务调度、冲突检测、运行校验**
调用 `lua_run_script_async` 异步启动时钟脚本，命名任务`clock`，启动前检测同名任务，避免冲突；启动后不立刻回复，持续巡检日志，排查 “显示已打开” 这类资源冲突错误。

5. **最终交付：自动降级方案**
Agent 自动切换 `wttr.in` 作为备用天气接口，时钟成功运行，并且主动告知全部变更信息：

- 原 Open-Meteo 在当前网络不可连通，已自动替换为 wttr.in；
- 位置由 IP 自动定位到上海；
- 任务后台常驻，不会阻塞 IM 对话；
- 开放迭代入口：更换城市、切换 12 小时制、修改配色、增加农历、设置开机自启都可以继续发指令。

### 本案例提炼 3 个核心观点

1. **ChatCoding = 带硬件反馈闭环的 Agent，不是单纯代码生成器**
它的思考链是：下发测试代码 → 读取硬件底层错误码 → 推理故障根因 → 更换方案重试，是完整的硬件调试闭环，而不是单次代码输出。

2. **具备自主降级容错能力**
外网 API 类项目极易受网络环境限制，Agent 可以根据真机返回结果自动切换备选服务，这是传统嵌入式开发很难低成本实现的轻量化容错。

3. **IM 通道在这里的价值：透明化远程调试**
整条调试链路全部在微信 IM 通道可视化，我们可以看到 Agent 每一步思考、每一次报错、每一轮重试，相当于远程围观 AI 给嵌入式板子排错。

> 两个案例对照：
> 理想版本：一次跑通，用来做成果展示；
> 故障排错版本：还原创客现场，用来理解这套开发范式真正的内核价值。

## 两种任务版本说明

- 版本 1：`beautiful_clock`：通用版，先实现时钟 + 天气同屏

- 版本 2：`clock_cn_fuzhou`：锁定福州、全中文优化版，专门适配本地天气，提前确认所有汉字（福州、湿度、降雨概率等）在 Noto Sans SC 里面都有字形，不会出现方框乱码。

## 这个 Demo 适合用来理解的 4 个核心概念

### 1. IM Channels 即时通讯通道（远程调试底座）

ESP-Claw 内置 IM 通道对接能力，把硬件变成一个可以在聊天软件里对话的终端。

你不在板子旁边，手机微信发指令，远端硬件执行，日志实时回传，这是传统 Arduino、ESP-IDF 开发很难做到的轻量化远程交互。

### 2. 硬件资源声明（exclusive 独占）

Mosaico 有很多共享外设：屏幕、喇叭、IMU。

如果两个脚本同时写屏幕，画面会乱掉。ChatCoding 的 Agent 会自动加上独占标记，这是 Agent 面向硬件的 “资源编排能力”，纯文本代码生成做不到。

### 3. 异步任务 + 日志闭环 = 轻量 HIL

Agent 把脚本丢给板子之后，**没有断开链路**，持续读取设备日志，根据真机反馈修正判断。

这就是我们前面说的硬件在环的轻量形态：真机反馈回传给 Agent，形成闭环。

### 4. 可增量迭代

任务跑起来之后，不需要重新写全套代码。
你随时在微信发指令：

- “天气改成 5 分钟刷新一次”
- “去掉底部进度条”
- “改成黑底白字”

Agent 会在原有任务基础上增量修改，而不是推倒重来，这就是 ChatCoding 的增量开发范式。

## 边界与思考（承接之前的天花板话题）

这个 Demo 属于**轻量型任务**，非常适合 ChatCoding 发挥优势：

逻辑简单、循环周期稳定、外设少、单屏幕输出。

但如果我们继续叠加复杂度：比如同时增加摄像头识别、舵机联动、多传感器并发，就会慢慢触碰到 ChatCoding 的增量上限，这时就需要切换

到 VibeCoding（电脑端 Agent 操作 ESP-IDF 工程）。

这个分界点，也正是我们之前踩坑 10 款轮播表盘时体会到的边界。

## 上手复刻提示词（直接在微信 IM 通道发给 Claw）

在ESP-Mosaico 480×480屏幕制作时钟天气面板，城市福州，全部中文。
布局：顶部城市+日期星期，中间大号时分秒每秒刷新，天气面板展示温度、天气现象、湿度、风速、降雨概率、高低温，底部秒进度条。
字体使用板载Noto Sans SC，天气每10分钟刷新一次，任务独占屏幕。
完成后持续运行，支持后续调整刷新率、配色，回复停止即可关闭。

## 小结

天气时钟看着简单，但是它把整套能力完整跑通了：
IM 通道接收远程指令 → 自然语言意图解析 → 生成 Lua 脚本 → 硬件资源独占调度 → 真机日志巡检 → 稳定运行确认 → 结果回传 IM、持续接受增量修改。

它不是一个 “代码生成玩具”，而是一套跑在 Vibe Mode 之上、依托 IM 即时通讯通道、面向创客硬件的轻量远程 Agent 调试闭环。看懂这个链路，你就分清了：普通 AI 写代码，和 ESP-Mosaico ChatCoding 硬件原生 Agent 开发，到底差在哪。

附录1：飞书上的对话截图

附录2：DeepSeek 今天试验使用量