【花雕动手做】了解板端AI：ESP-Mosaico 十款轮播表盘 ChatCoding 连环踩坑实录

原文标题：《【花雕动手做】摸清板端 AI 的底牌！ESP-Mosaico 十款轮播表盘 ChatCoding 连环踩坑实录》

原文链接：

博客标签：*ESP-Mosaico  ChatCoding  Vibe Coding  AI 硬件编程  Lua 沙箱  创客实战*

## 导读：ChatCoding 真的是“许愿机”吗？

许多刚接触 ESP-Mosaico 硬件的创客，都会被 ChatCoding 的丝滑体验惊艳：不用装编译器、不用配环境，对着板子一句话，大模型自动生成 Lua 脚本，秒级热部署直接跑。这很容易让人产生一种错觉——只要会拆解需求，不管多复杂的项目，都能靠对话搞定。

本次尝试，我原来打算做一个极具观赏性的压轴 Demo：10 款风格完全不同的动态表盘，每秒自动轮播切换。

就在这个重度绘图项目的调试过程中，我的小试验，经历了一连串的报错连环暴击，最终结果是彻底摸清了板端 AI Create 接口的“增量天花板”。

如果你正准备用 ChatCoding 写复杂业务，这篇基于真实试错的复盘，建议先收藏再看。

🔄 ChatCoding 标准闭环链路

注：*生成阶段依赖云端算力；部署到板端 Lua 沙箱后，断网也能本地独立运行。*

## 一、热身：轻量级案例打通链路

在挑战高难度绘图前，先跑几个轻量级案例验证硬件、网络和模型调用的连通性：

屏幕文字：蓝色背景显示“你好，Mosaico”。（验证基础 UI 渲染）

IMU 姿态：实时显示板子倾斜角度。（验证传感器读取与刷新）

震动/RGB：定时循环震动、红绿蓝渐变切换。（验证时序逻辑与外设驱动）

摄像头预览：调用磁吸摄像头子板，实时显示画面。（验证图像链路）

以上小步快跑全部丝滑通过，这给了我继续做系列尝试极大的信心。然而，真正的毒打才刚刚开始。

## 二、连环翻车实录：四轮交锋，看懂 ChatCoding 天花板

我带着很大的期待，提交了压轴需求。这四轮真实的试错链路，彻底打破了“只要拆分就一定能成功”的幻想。

第一轮：大而全的野心 —— 惨遭空响应
我的自然语音指令是：“设计 10 种完全不一样风格的手表表盘图案，每秒自动切换一款，循环轮播，每款表盘布局、刻度、配色、指针样式都不一样，请执行。”
现象：界面直接报错 LLM returned empty text response。
原因拆解：10 套表盘包含大量独立绘图逻辑、三角函数计算、配色方案。整体输出 Token 量巨大，直接触发了模型侧的输出长度限制或风控机制，大模型直接“罢工”，返回空数据包。

第二轮：分步拆解骨架 —— 触发超时
指令 1：“先写一款基础表盘，再切换框架。”
结果：成功。深蓝科技风基础时钟完美渲染，指针平滑走动，这证明硬件和链路毫无问题。
指令 2：“在这个框架里继续增加剩下 9 种不同表盘式样。”
现象：界面报错 AI Create request timed out. Please retry.
原因拆解：大模型已经开始处理代码，但生成耗时超过了 AI Create 服务预设的等待时限（超时红线）。一次性追加 9 套独立绘图函数，压力依旧爆炸。

第三轮：缩小增量粒度 —— 依然超时
指令：“增加第 2、3 款表盘测试切换执行。”
现象：依旧 AI Create request timed out. Please retry.
原因拆解：这是很多人容易踩的坑。表盘属于“高单重绘图任务”。它不像“加个灯光闪烁”那样只需改几行参数。每一套新表盘，都需要从头写一套独立的 Canvas 绘制逻辑。哪怕只新增 2 款，生成开销依然极高。

第四轮：压到理论极值 —— 彻底撞墙
指令：“再增加一款表盘，然后循环显示执行。”
现象：仍是 AI Create request timed out. Please retry.
结论：到此，瓶颈彻底清晰。对于这类重度依赖几何绘图、多独立渲染分支的任务，单一套表盘的代码量，其生成耗时就已经逼近了板端 AI Create 的时间上限。

避坑指南：两种高频报错的本质区别
报错信息    根本原因    偏向类型    解决思路
LLM returned empty text response    任务体量过大，超出单次输出 Token 上限或触发风控拦截    长度限制    大幅减少单次生成的需求量
AI Create request timed out    模型正常生成代码，但生成耗时太久，超过了服务端的等待极限    耗时限制    降低生成复杂度，或换工具链

## 三、工程破局：不撞南墙，两条路线登顶

面对板端 ChatCoding 的硬性物理边界，这里并非无计可施。改用适配的工程思路，问题迎刃而解。

方案 A：参数化驱动（坚守 ChatCoding 生态）
核心思想：放弃让 AI 每次都写一套全新的 draw() 函数，改用“一套通用绘制引擎 + 配置参数”的模式。
优化提示词：

“复用现有的 draw_dial 绘制函数，新增一组样式配置参数（如刻度类型、背景色、指针长度），实现一款新表盘，绝对不要新增独立的绘图函数。”

优势：新增表盘只需增加几行配置表，Token 消耗极低，完美避开超时和空响应。

代价：所有表盘的底层渲染结构一致，只能改外观参数，无法实现结构上的截然不同。

方案 B：降维打击（切换 VibeCoding 电脑端开发）
如果你非要 10 套结构完全独立、自由度极高、绚丽复杂的表盘，请果断切换 ESP-Mosaico 的第二条开发路线：VibeCoding。
在电脑端用 Cursor / Claude Code，AI 不受板端短超时限制，一口气写完所有复杂的 Lua 逻辑。代码在电脑上调试定稿后，再一键下发到板子运行。这才是重型项目该走的通道。

## 四、范式思考：重新理解 ChatCoding 的定位

这四次翻车，让我对 AI 硬件开发有了更敬畏的认知。

ChatCoding 的伟大之处，在于零底层门槛、秒级热部署、真机即时反馈，它是创意验证和课堂演示的神兵利器。

但这里必须清醒：ChatCoding 不是万能的一键生成器。

它的增量迭代存在两座大山：输出 Token 上限与接口等待时长上限。

轻逻辑（传感器、开关、单屏文本）：小步迭代如丝般顺滑，尽情发挥创意。

重逻辑（海量绘图、高频三角函数、复杂状态机）：瓶颈会迅速显现，此时切勿死磕。

简单来说：ChatCoding 用来验证想法，VibeCoding 用来落地工程。

ESP-Mosaico 提供两条路线的初衷，正是让我们在“极速原型”与“复杂开发”之间，找到最适合当下的那把武器。

## 附录

跟踪系列小实验过程，抓拍到几个半成品的画面，也算多重踩坑后的小收获，意外之喜了。