环形→彩虹→螺旋，画面越画越炫，板子却 ESP_FAIL 了｜ESP-Mosaico 视觉动画升级记

标签：*ESP-Mosaico、ESP-Claw、ChatCoding、远程 HIL、IM 通道、Lua 图形动画、阿基米德螺旋、增量迭代、ESP_FAIL、DeepSeek-Flash*

导读

> 前面小球碰撞的实战，我们看懂了 ChatCoding 增量迭代、O (N²) 算力天花板。本篇是同一条飞书 IM 远程通道、同一套`exclusive=display`独占屏幕机制下，**纯几何视觉动画的完整演化实录**。

> 从一句最简单的 “青色环形进度条” 起步，不烧录、不碰电脑 IDE，只用聊天一句话迭代：单列环→并排三色环→同心错位环→7 环彩虹同步→异步错速→间隔反向对流→阿基米德螺旋；最后在螺旋加粗提速的需求下，再次撞上`ESP_FAIL`硬件算力红线。

> 文末附带本次迭代的大模型用量账单，直观看见：**这种小步增量式硬件 Agent 开发，Token 消耗到底是什么量级**。

## 一、链路总览：不变的远程 HIL 底座

整套流程和小球案例复用同一套远程闭环，核心原语不变：

1. IM 下发自然语言需求
2. Agent 先查询板上异步任务、读取屏幕绘图 API 文档，确认图形能力
3. 在原有任务脚本上增量修改，而不是每次全部重写
4. `lua_run_script_async`独占屏幕热部署，自动关停旧绘图任务
5. `lua_get_async_job`拉取任务快照自检，确认任务正常拉起
6. 更新会话记忆标签，返回效果摘要，主动给出下一轮微调方向
7. 当单帧绘图计算量超出 Lua 沙箱调度上限 → 返回`HTTP请求失败: ESP_FAIL`

> 重点区别于小球物理仿真：小球是**碰撞检测的 O (N²) 计算开销**；这一组案例，开销来自**大量圆弧 / 螺旋线段逐点绘制**，属于光栅绘图开销，是嵌入式屏幕动画另一类典型算力陷阱。

试验记录

## 二、逐轮迭代全链路拆解（需求→Agent 思考→效果→底层逻辑）

### 第 1 轮：起点｜青色单环形进度条，顺时针匀速旋转

用户指令：

> 屏幕中间画一个环形进度条，顺时针匀速旋转，颜色青色，背景黑色。独占屏幕。

Agent 后台行为拆解：

1. 检索板上异步任务，确认屏幕空闲、无正在运行绘图任务
2. **主动查阅显示模块文档**，识别原生图形 API：`screen:arc(cx, cy, radius, start_deg, end_deg, color)`
3. 识别 API 局限：原生 arc 仅 1 像素描边，所以自动增加轨道底环，做出 “环形进度条” 视觉，而不是单薄一根线
4. 设定参数：圆心居中、半径 180px、弧长约 100°、转速 200°/s、30 帧
5. 下发脚本，自检快照，新建任务`progress`
6. 返回摘要，同时主动给出可调参数清单：转速、弧长、环粗细、渐变

核心亮点：
Agent 不是直接硬写代码，**先读硬件图形文档**，知道板子原生绘图函数的能力短板，自动补齐轨道环，做出符合人类认知的 “进度条”，而不是只输出一根 1px 细弧。这是硬件 Agent 和普通代码生成器最大的差异。

试验记录

### 第 2 轮：升级｜三条红绿蓝色并列排布

用户指令：

> 升级为三条红绿蓝色并列

Agent 思考与改动：

1. 识别增量需求：保留弧动画逻辑，不再居中单环，改为横向并排 3 个独立环形进度条
2. 空间分配：480 屏横向三等分，每个环半径 68px，红 / 绿 / 蓝三色独立轨道
3. 任务切换为`progress3`，同样 30 帧、200°/s，相位错开
4. 热部署、自检，反馈效果，提供竖排 / 同步相位等备选修改方向

逻辑要点：
Agent 理解 “并列”= 空间排布修改，**物理动画逻辑完全复用**，只修改坐标生成部分，最小改动实现需求，Token 开销很低。

试验记录

### 第 3 轮：重构布局｜同居中、同步异相位、加大环半径

用户指令：

> 升级为同居中、同步异相位、加大环半径

Agent 思考与改动：

1. 识别关键词：**concentric 同心环**，放弃并排布局，三环共用屏幕中心点
2. 分层半径：外环 205px、中环 173px、内环 141px，预留环间距避免重叠
3. 转速不变，起始相位错开 0°/120°/240°，同步旋转但错开，形成流动层次感
4. 任务`progress3c`，保留轨道、圆弧圆角端点的细节

工程理解：
Agent 分得清「并列（不同圆心）」和「同心（同一个圆心，不同半径）」两个布局概念，自然语言到坐标系转换无歧义。

试验记录

### 第 4 轮：扩容｜7 条彩虹色同心环，变细、提速、同相位

用户指令：

> 增加转速，同相位，升级为 7 彩虹色七条，细一点

Agent 思考与改动：

1. 色彩映射：红橙黄绿青蓝紫彩虹色序
2. 参数调整：带宽从 14px 缩小至 8px，半径从 218px 向内递减到 44px
3. 转速提升到 400°/s，一圈仅 0.9 秒，7 环同相位对齐，像彩虹扇面一起扫过屏幕
4. 主动风险提示：7 环逐帧绘制计算量偏大，卡顿可以降环数、轻量化

边界预判：
Agent 已经预判渲染压力上涨，提前告知风险，这是硬件 Agent 的前置预警能力。

试验记录

### 第 5 轮：动态升级｜不同相、异步，每个环独立速度

用户指令：

> 不同相，异步

Agent 思考与改动：

1. 拆解需求：异步 = **起始相位不一样 + 每个环转速独立**
2. 分配参数：7 环转速 350/390/430/470/510/550/590 °/s，起始相位 0°/53°/110°/167°/224°/281°/338°
3. 每个环独立计算角度，不再同步，多层彩虹各自流转，视觉更丰富
4. 任务`progress7a`，维持 30 帧

试验记录

### 第 6 轮：视觉创意｜间隔彩条反向旋转，对流效果

用户指令：

> 间隔彩条反向旋转

Agent 思考与改动：

1. 奇偶分组：1、3、5、7 号环顺时针；2、4、6 号环逆时针
2. 保留各自独立转速、错开相位，形成内外对流、交错对冲的视觉效果
3. 任务`progress7b`，黑底细环，流动层次感极强
4. 给出下一步微调方向：统一逆时针转速、增加弧长、中间叠加文字刻度

试验记录

### 第 7 轮：形态切换｜青色单条，螺旋状向内旋转

用户指令：
> 调整为青色单条，螺旋状向内旋转

Agent 思考与改动：

1. 从环形圆弧，切换为**阿基米德螺旋线**数学模型，不再是固定半径圆弧
2. 约 5 圈螺旋，线条 1px，通过旋转方向制造向内流动的视觉错觉
3. 新建任务`spiral`，30 帧渲染；同时主动说明：向内 / 向外是视觉错觉，反转方向即可切换

> 阿基米德螺旋公式：\(r = a + b\cdot\theta\)，每增加固定角度，半径均匀增加，非常适合流光特效

试验记录

### 第 8 轮：触达上限｜方向翻转，线条加粗，速度加快 → ESP_FAIL

用户指令：

> 方向翻转，线条加粗，速度加快

Agent 内部推演：

1. 需求：反转螺旋旋转方向、增加线宽、提升角速度
2. 阿基米德螺旋是**逐点计算大量坐标，连续绘制线段**，加粗线条意味着每一圈螺旋需要更多的点填充，单帧绘图运算量暴涨
3. 下发部署请求之后，板子侧调度失败，返回：`HTTP 请求失败: ESP_FAIL`

试验记录

本次 ESP_FAIL 深度解读（和小球案例对比区分）

- 小球碰撞 ESP_FAIL：开销来自**两两碰撞检测 O (N²) 逻辑运算**

- 螺旋动画 ESP_FAIL：开销来自**大量坐标三角函数计算 + 逐线段光栅渲染**，属于图形渲染开销

二者表象一样，都是 ESP 底层返回 ESP_FAIL，但瓶颈根源完全不同。

Lua 沙箱在 ESP32-S31 上的算力是固定上限：不管是物理仿真循环，还是高密度几何绘图，只要单帧计算耗时超出帧调度阈值，任务直接拉起失败。

> 这也是 ChatCoding 的增量天花板：创意可以无限叠加，但 MCU 单帧算力有硬上限。

## 三、飞书 IM 通道，同一个`bounce`任务的增量迭代实录（电脑版实时截图）

## 四、配套账单解读：增量迭代的 Token 消耗（文末截图）

这是本次一整条视觉动画迭代链路的 API 用量，模型：DeepSeek-Flash

- 今日消费：0.22 元
- API 请求次数：40 次
- 总 Token：1,082,442
- 累计账户余额：10.22 元，累计消费 9.77 元

怎么理解这个数据：

1. 40 轮对话，从简单环一直迭代到螺旋、撞上限，百万级 Token，花费仅 0.22 元，**增量模式比每次全量重写代码省非常多**
2. 为什么 Token 并不低：每一轮 Agent 都要携带整套项目上下文、绘图参数、历史记忆，理解当前动画状态，再做局部修改；上下文越长，单次请求 Token 越高
3. Flash 模型优势：低成本、响应快，非常适合这种高频、小步迭代的硬件 HIL 调试场景，适合创客持续玩

> 对比：如果每一次都让 AI 从头完整生成全部代码，Token 消耗会远高于这个数值。增量迭代，是低成本玩 ChatCoding 的核心思路。

## 五、这套案例沉淀出来的工程认知

1. **硬件 Agent 会区分 “API 能力” 和人类语义**
它会先查板子原生绘图函数，知道 arc 只能画细线，自动补充轨道、圆角，而不是机械直译需求。普通代码生成器很容易忽略底层硬件 API 限制。

2. **两种典型算力瓶颈，两类 ESP_FAIL**
  - 物理仿真类：碰撞检测、距离判断，复杂度随物体数量平方上涨
  - 几何渲染类：螺旋、大量圆弧、多段线条，三角函数、逐点光栅绘制吃掉算力

3. **自然语言的空间语义，Agent 可以稳定解析**
并列、同心、居中、同相位、异步、反向对流，这些偏视觉美术的词汇，都可以稳定翻译成坐标系、角度、转速参数。非常适合做 UI、灯光、屏幕特效快速创意验证。

4. **创意迭代的节奏建议**
优先从小效果起步，逐步叠加：数量→布局→相位→转速→方向→线条粗细；不要一次性把所有参数全部改满，更容易定位到算力崩溃的临界点。

5. **记忆机制是低成本迭代的核心**
每一轮`Memory update`记录`[显示;彩条]`这类标签，记住整套动画上下文，用户只需要一句话改局部，不需要重复描述全部需求。

## 六、适用场景与边界

适合：

- 展会、演示的屏幕流光特效、动态进度 UI、开机动画
- 数学图形可视化：阿基米德螺旋、渐开线、极坐标图形教学
- 快速验证创意美术效果，不用写复杂绘图代码
- 远程调试、IM 下发指令，适合现场演示、直播演示

不适合：

- 超高精度、超多圈数、粗线条螺旋，极易触发渲染算力超限
- 高帧率、多层粒子叠加的复杂特效，这类场景建议移步 VibeCoding，在 ESP-IDF C 层做硬件加速绘图

## 结尾

从小球物理碰撞，到今天这套环形→彩虹同心环→螺旋流光，我们两次在完全不同的计算场景下，触碰到同一个结果：`ESP_FAIL`。

这也反复印证了同一个核心结论：**ChatCoding 是创意放大器，它可以让你用自然语言快速试错，但是它不能突破 MCU 单帧算力、内存的物理天花板。**

远程 HIL 的魅力，就在于你可以在聊天窗口里，像搭积木一样不停演化视觉效果，亲眼看见创意从简单线条，一步步变成流动的彩虹螺旋，直到摸到硬件的边界。