【踩坑实录】DeepSeek接入ESP-Mosaico：从太阳到7帧月相看懂ChatCoding边界

标签：*ESP-Mosaico  ChatCoding  DeepSeek V4.1-Flash  Vibe Mode Lua  硬件在环  AI 硬件开发*

## 导读

很多小伙伴拿到 ESP-Mosaico 之后，第一件事就是替换默认大模型，想用 DeepSeek 更强的推理能力跑 ChatCoding。但这里藏着一个非常容易踩的陷阱：**产品宣传名，不等于 API 接口可识别的模型 ID**。

本次实战，我从模型配置报错开始，跑通太阳月亮交替动画，再挑战 7 帧月相连续动画，直观摸到 ChatCoding 板端会话、单次生成代码量的天花板，看懂什么时候适合 ChatCoding，什么时候必须换 VibeCoding。

## 一、开篇：一个 90% 的人都会踩的参数坑

拿到 DeepSeek V4.1-Flash，第一反应就是在 ESP-Mosaico 的 LLM 配置面板直接填入 `deepseek-v4.1`，保存后进入 AI CREATE，下发指令：画一张太阳和一张月亮的图片，间隔 1 秒交替显示。

板子直接返回经典 400 报错：

HTTP 400: The supported API model names are deepseek-flash, deepseek-v4-pro, but you passed deepseek-v4.1

### 核心区分（重点）

- 市场 / 文档宣传名称：DeepSeek V4.1-Flash
- API 接口后端**真实识别的 model 参数**：`deepseek-flash`
- 同平台另一个可用模型：`deepseek-v4-pro`

很多人在这里卡很久：API 密钥正确、BaseURL `https://api.deepseek.com` 正常、网络连通、工具调用开关已经打开，就是调用失败。本质不是鉴权、网络问题，只是**模型名字符串对不上**。

修复操作：
进入 LLM 设置页面，模型一栏修改为 `deepseek-v4-pro`，确认【LLM 模型支持工具调用】打开，超时我设置 120000ms（120s），保存页面，重启 Mosaico-Claw 会话。

> 划重点：工具调用开关是 ChatCoding 的生命线，关闭之后，大模型只能聊天，无法生成可在板端沙箱运行的 Lua 脚本。

## 二、实战第一阶段：2 帧太阳月亮动画，链路跑通

修正模型标识之后，重新下发相同指令：

> 画一张太阳和一张月亮的图片，间隔 1 秒交替显示

这一次链路闭环成功。

板子返回提示：脚本已经生成，路径 `/nand/sun_moon.lua`，后台任务 `sun_moon` 独占显示屏循环运行。

动画逻辑：
- 太阳画面：蓝天背景 + 黄色圆形太阳 + 16 条光芒
- 月亮画面：夜空背景 + 星星 + 月牙
- 每 1 秒自动切换，无限循环

同时保留交互能力：随时语音发送 “停止动画”，Agent 可以直接终止这个后台 Lua 任务。

这就是 ChatCoding 最舒服的使用场景：**简单、少量画面、短代码、单次生成逻辑简单**。

自然语言描述需求 → DeepSeek 推理生成 Lua 绘图脚本 → Vibe Mode 热部署，直接在真机运行，**不需要电脑编译、下载固件**，硬件在环轻量闭环一次性完成。

到这里，外接 DeepSeek 的整套链路已经验证成功，看起来一切都很完美。

试验记录

## 三、实战第二阶段：挑战复杂度上限，7 帧月相动画触发会话超时

同一个会话里，我继续提升难度，下发指令：

> 生成月相圆缺变化连续 7 张图片，间隔 1 秒执行切换

板子直接返回报错：

AI Create request timed out. Please retry.

这里是本篇最关键的知识点：**两个完全独立的超时机制，千万不要混为一谈**

1. LLM 面板设置的 120s 超时：是发给 DeepSeek 服务商的 HTTP 接口超时，控制大模型接口的返回时间；

2. `AI Create request timed out`：是**ESP-Mosaico 板端 Claw（AI CREATE）会话层超时**，属于 Vibe Mode 固件内部限制，不受 LLM 面板超时参数控制。

### 为什么 2 帧太阳月亮能跑，7 帧月相直接超时？

1. **代码体量差距巨大**
太阳月亮只需要 2 套绘图逻辑；7 组月相，每一组都要单独绘制圆弧、阴影遮罩、背景，几何计算复杂，一次性生成的 Lua 代码量成倍上涨，大模型推理耗时大幅增加。

2. **历史上下文持续累积**
我们没有新开对话，沿用了刚才太阳月亮动画的会话，之前的对话记录、完整 Lua 脚本全部留在上下文，Token 越来越多，进一步拉长推理时间。

3. **ChatCoding 本身存在增量天花板**
ChatCoding 定位是**轻量快速原型验证**，它的设计目标不是一次性生成超长篇、多场景复杂脚本。一次性塞入大量绘图逻辑，很容易突破板端会话等待上限。

## 四、两种解决方案，对应两条开发路线

### 方案 A：继续使用 ChatCoding（推荐创客演示、快速试想法）

遵循**增量迭代思路**，不要一次性要求全部 7 帧。

1. 新开 Claw 会话，清空历史上下文；

2. 指令拆分：先画新月，运行成功；再追加指令增加上弦月，以此类推，一次只新增 1 个画面；

3. 简化图形逻辑，先不用精细渐变遮罩，用基础色块、圆弧模拟月相，降低代码复杂度。

优点：全程在板子上语音交互，门槛最低；
局限：复杂动画、大量画面迭代时，依然会受会话时长、单次代码上限约束。

### 方案 B：切换 VibeCoding（适合复杂图形、机器人、多帧动画正式项目）

把 7 帧月相动画这类复杂绘图工程交给电脑端 Agent（Cursor / Claude Code），电脑端不受板端会话超时限制，写完完整工程后，再下发到 ESP-Mosaico 真机调试。

优点：没有单次代码长度限制，适合长期迭代、复杂视觉项目；
局限：需要电脑，不再是纯板端语音对话的极简体验。

## 五、总结与边界思考

1. 对接第三方大模型，**不要把宣传名称直接当成 API 模型 ID**，一定要核对服务商文档里的标准 model 字段，这是接入的第一道门槛；
2. ChatCoding 非常适合少量画面、简单交互、快速验证创意，像太阳月亮这种 2 帧动画，是它的舒适区；
3. 当需求变成多帧、大量几何绘图、复杂逻辑，就会触碰到 ChatCoding 的增量天花板，表现形式就是板端 AI Create 会话超时；
4. 两条路线没有优劣，是互补关系：
  - 想随手玩、快速验证脑洞 → ChatCoding；
  - 复杂视觉、机器人、长逻辑工程 → VibeCoding。

AI Agent 可以帮我们写硬件代码，但它不能突破平台本身的运行约束。看懂这个边界，才不会误以为换一个更强的大模型，就能解决所有硬件开发问题。

### 拓展阅读（同系列博客）

1. ChatCoding 增量天花板实战：ESP-Mosaico 十款轮播表盘完整踩坑实录
2. 告别 ROS 与 Arduino 的 “静态牢笼”：具身智能与动态机器人的下一代开发范式
3. VibeCoding—— 电脑上的 Agent 直接操控真机：ESP-Mosaico 的另一条开发路线

附录
本次试验调用 API 请求次数 18，消耗 Tokens 306,803，试验费用 1.33元