两条开发主线讲透：ChatCoding 与 VibeCoding，从“一句话点亮”到“真机工程闭环”

标签：ESP-Mosaico  ESP32-S31  Vibe Mode  Mosaico-Claw  ChatCoding  VibeCoding  ESP-IDF  AI硬件开发

## 前言：两条路，一个底座

前面几篇陆续聊了 ESP-Mosaico 的名字由来、Vibe Mode 的架构、以及 Mosaico-Claw 这个 ChatCoding 入口。到这里，很多读者会冒出一个问题：

既然板子上已经能对话写代码了，为什么还要在电脑上再搞一套 Agent？

这个问题问到了点子上。ChatCoding 和 VibeCoding 不是“新旧两代”，而是同一个底座上的两条并行路线，面向完全不同的阶段和目标。

一句话先划清界限：

ChatCoding = AI 在板子上，面向快速创意原型；VibeCoding = AI Agent 在电脑端，直接打通完整工程链——读写、编译、烧录、抓日志、调试真机，面向正式嵌入式项目。

这里会把两条路线合并讲讲：它们各自是什么、怎么协作、Vibe Mode 在中间扮演什么角色、以及你该在什么阶段用哪条。

## 一、先看清底座：Vibe Mode 是两条路的共同根基

不管走哪条路线，板子开机第一眼看到的都是 Vibe Mode。它不是普通的启动界面，而是固化在独立 Flash 分区里的底层引导管理固件，独立于用户业务 App 运行。

Vibe Mode 负责的事情很具体：

统一管理 USB、Wi-Fi 两条调试链路

统一上报磁吸扩展模块的热插拔信息，让上层实时感知硬件变化

提供安全隔离：前 2 MB Flash 固定为 Vibe Mode，用户应用写坏也不会变砖

统一日志、画面、外设状态的上报接口，上层不用自己对接五花八门的底层串口协议

它的口号是 make ideas run——让创意跑起来。Idea 就是运行在 Vibe Mode 上的独立应用包，Mosaico-Claw、积木编程、相册都是 Idea。

关键点在于：哪怕是原生 ESP-IDF 固件，也可以作为一个 Idea，由 Vibe Mode 加载、管理、启停。 这意味着 VibeCoding 烧录的固件并不是“绕过系统”，而是仍然在 Vibe Mode 的调度框架内运行。调试通道、安全隔离、模块热插拔感知，这些能力在两条路线上是共享的。

## 二、ChatCoding：AI 在板子上，把创意先跑起来

2.1 它是什么
ChatCoding 的载体是出厂预装的 Mosaico-Claw（基于 ESP-Claw 框架）。你打开它，用触屏打字或者直接说话描述需求，Agent 识别当前插了哪些模块，生成适配硬件的 Lua 脚本，交给 Vibe Mode 热部署运行。

官方文档列出的 Claw 内置技能包括：快速提问、AI Create（创建 Lua 自动化）、安装技能（Skills Lab 搜索）、记忆、规划、计划任务。

几个典型需求示例：

“读取摇杆的方向，控制屏幕上小球移动”

“摄像头识别人脸，检测到人脸就亮起 RGB 灯，并且播放提示音”

“读取六轴 IMU 姿态，屏幕实时显示倾斜角度”

2.2 它真正的价值
不是“AI 帮你写代码”，而是把从想法到可运行原型的时间压缩到分钟级。

而且有一个容易被忽略的细节：部署完成之后，项目是本地独立运行的，断网之后依然可以正常工作。 代码生成、大模型理解需求这一环节依赖网络；但传感器读取、外设控制完全在本地执行。你做出来的不是“云端的玩具”，而是真正能离线跑在板子上的东西。

再往上一层，是 Skills Lab 技能生态。做好的项目可以打包成可复用 Skill，也可以一键安装别人分享的技能。对教学来说这一点尤其有价值：老师把课堂案例打包分发，学生一键加载复现，不用把时间耗在环境配置上。

2.3 它的边界
必须说清楚：ChatCoding 生成的是 Lua 脚本，运行在解释器之上，适合逻辑控制、传感器读取、UI 交互，不适合 FOC 电机控制、SLAM、高速图像算法这类硬实时场景。沙箱有性能上限，这是架构决定的，不是调参能解决的。

## 三、VibeCoding：AI 在电脑上，把原型做成工程

3.1 它是什么
VibeCoding 是 ESP-Mosaico 配套的深度开发工作流。你用 USB-C 把板子连到电脑，打开 Cursor、Claude Code 等支持 MCP 的 Agent 工具，让 Agent 直接操作 ESP-IDF 项目。

官方支持的 AI 编码工具包括 Codex、Claude Code、OpenCode、Trae，以及 Cursor 等兼容 MCP 协议的客户端。

它的核心不是“生成代码文本”，而是直接操控物理真机，形成闭环：

写代码 → 构建 → 烧录 → 真机运行 → 读取反馈 → 自动改代码

3.2 完整闭环流程
第一步：连接建立。 板子开机进入 Vibe Mode，USB 连电脑。Agent 通过 MCP 服务连接设备，自动读取当前硬件清单：主板版本、挂了哪些磁吸扩展模块、硬件资源信息。Agent 知道现在是什么硬件，才不会写出脱离硬件的“纸上代码”。

第二步：需求描述与代码生成。 你给 Agent 提需求，比如“基于 ESP-IDF，读取摄像头画面做简单人脸检测，检测到人脸后驱动 RGB 灯矩阵变色”。Agent 读取 BSP、原理图、驱动文档，生成完整 ESP-IDF 工程代码、CMake 配置、UI 资源。

第三步：仿真预检（可选）。 Agent 优先在电脑模拟器里跑一遍，提前排查语法、资源、UI 布局错误，减少反复烧录的时间成本。

第四步：自动构建、烧录。 Agent 调用本地 ESP-IDF 工具链，编译 esp32s31 目标固件；编译成功后自动通过通道烧录进真机。全程不需要你手动点烧录、选串口、敲命令。

第五步：真机运行 + 采集反馈。 固件启动，Vibe Mode 把运行日志、报错信息、传感器数据、屏幕画面、触摸事件回传给电脑 Agent。Agent 能看见：程序有没有跑起来、摄像头有没有出图、IMU 数据是否正常、哪里崩溃了。

第六步：自动迭代修复。 效果不对、程序报错，Agent 拿到真机反馈，定位问题、改代码、重新编译、再次烧录，循环迭代。

3.3 乐鑫为 VibeCoding 铺的五层路
VibeCoding 不是“把 Cursor 打开就完事”。乐鑫做了几层针对性设计：

① 规范驱动的 UI 开发。 给 Agent 明确的设计规则、组件库、资源和约束。UI 不是“随意发挥”，而是在预定义规范内组合，至少保证结构合法。

② ESP-GSP：面向 AI 的 UI 框架。 这是闭环里最具体的一块技术支撑。开发者（或 Agent）用 JSON 描述界面结构和资源，构建工具在编译阶段完成校验、资源优化，生成类型化 C API，设备端只调用 API 更新状态。官方文档明确写了：可结合场景规范和控件文档，由 AI 辅助生成或修改 JSON 界面，并通过编译检查和主机模拟器验证布局与交互。试错成本从“烧录一次等几十秒”降到“改一行 JSON 跑一次模拟”。

③ 闭环设备调试。 乐鑫把烧录、设备控制、输入注入、UI 状态读取、性能数据、故障信息统一暴露为接口，让 Agent 直接调用。开发者的角色变成定义目标、约束和验收标准。

④ Agent-ready 开发资源。 BSP、SDK、原理图、参考工程、文档都整理成 Agent 可读的形式。这一点在实测中效果很明显：有开发者记录，用 ChatCoding 折腾光敏传感器约 2 小时没跑通，因为 Agent 只能靠运行时探测；换用 VibeCoding（Claude Code + BSP 源码），7 分钟一次跑通，因为 Agent 可以直接读驱动代码、读模块 EEPROM 的识别信息。

⑤ ESP-IDF Tools MCP Server。 ESP-IDF v6.0 引入 Tools 本地 MCP Server，让 Cursor、Claude Code 等客户端直接调用 idf.py 的能力：设置目标芯片、编译、烧录、查询项目状态、列出串口设备。以 Cursor 为例，在 .cursor/mcp.json 里注册 eim run idf.py mcp-server，Agent 就能在对话里执行“set target to esp32s31 and build”并拿到真实构建结果和错误信息。

## 四、两条路线清晰对比

二者不是替代关系，是串联的开发流水线。

## 五、它解决了 AI 时代硬件开发的什么痛点

传统嵌入式开发，人是“中间人”：写代码 → 手动编译 → 手动选串口烧录 → 自己看串口日志找 bug → 手动改代码，循环往复。AI 生成代码之后，依然要人工做这一整套体力活。

现在 AI 写代码已经很成熟，但有一个很难绕过去的鸿沟：AI 在电脑里写出来的代码，大多是“纸上代码”。放到真实硬件上，会遇到接线错误、引脚冲突、驱动缺失、总线争抢、传感器噪声一堆现实问题。软件可以秒级迭代，硬件调试周期很长。

乐鑫在发布 ESP-Mosaico 时把这个痛点说得很清楚：“软件现在可以借助 AI 快速生成和修改，但硬件仍然受限于固定的板子、接口和产品形态。”

两条路线从不同层面填这条鸿沟：

ChatCoding 层面：硬件模块化磁吸免接线，Vibe Mode 自动识别模块，Claw 感知当前硬件组合生成适配代码，运行后读反馈迭代。

VibeCoding 层面：Agent 自动识别真实硬件配置，避免写出脱离板子的无效代码；自动编译、自动烧录，解放重复命令行操作；自动采集真机运行反馈，基于真实报错修复；支持先仿真后真机，降低调试翻车成本；模块化硬件变更后，Agent 自动感知模块增减并适配驱动。

这也是乐鑫对 Vibe Coding 的理解：Vibe 不是随便写代码，是在真实物理硬件上持续迭代、生长项目。

## 六、你该在哪个阶段用哪条？

我的建议很简单：看你在哪个阶段。

想法验证阶段 → ChatCoding。 你有一个模糊的创意，想知道“这玩意儿能不能跑起来”。打开板子，说几句话，几分钟看到效果。不对就继续聊。这个阶段的成本是“试错的时间”，ChatCoding 把它压到了最低。

原型打磨阶段 → VibeCoding。 ChatCoding 跑通了，你知道这个方向可行，现在要把它做稳、做完整。换到电脑上，让 Agent 读驱动、写工程代码、编译烧录、闭环调试。这个阶段的成本是“调试的深度”，VibeCoding 给了 Agent 足够的信息去深入。

正式项目 → 原生开发 + Agent 辅助。 VibeCoding 的 Agent 可以帮你写业务逻辑、调 UI、排查编译错误，但架构设计、性能优化、安全边界，这些需要人的判断。

乐鑫自己在发布时也说了：两种方式“既可以独立使用，也可以根据开发阶段灵活选择”。

## 七、上手前置条件与客观边界

VibeCoding 前置条件
ESP-Mosaico 主板（优先 V1.2，双独立 I2C，多模块更稳）

一根支持高速数据传输的 USB-C 线

电脑端：ESP-IDF 开发环境、MCP 服务（对接 Agent 和设备）

支持 MCP 的 AI 编码工具：Cursor、Claude Code 等

板子正常进入 Vibe Mode，电脑与设备通信正常

提示：这套链路目前仍在持续迭代，属于进阶路线，不建议零基础新手直接上手。先吃透 ChatCoding，理解整套生态之后再来体验 VibeCoding。

客观边界
它不是“AI 一键做出完美产品”。Agent 依然会写错底层逻辑，只是把编译、烧录、抓日志这些机械工作自动化；复杂算法思路依然需要开发者把控。

硬实时控制仍要走原生开发。FOC 电机控制、高速闭环、SLAM，VibeCoding 可以帮你写代码、调参数，但性能验证和时序保证仍需人工介入。

ESP-GSP 的 JSON UI 范式有适用范围。适合“界面结构构建期确定、运行时更新数据”的产品；高度动态布局或复杂自定义绘制不一定是最优解。

两套方案各有取舍，不是 VibeCoding 就一定更好。简单交互项目，ChatCoding 效率高得多。

生态还在持续完善，模块、技能库还在不断新增，社区资源相比 Arduino、Mind+ 生态还比较新。

## 结语：一个底座，两条主线

到这里，ESP-Mosaico 的开发主线可以收束成一张图：

磁吸扩展模块（马赛克碎片）
       ↓
ESP-Mosaico 主板（基座）
       ↓
Vibe Mode（系统底座、资源管理器、安全隔离）
       ↓
Idea 应用
  ├── Mosaico-Claw / ChatCoding（轻量原型，一句话点亮）
  └── VibeCoding 固件（电脑 Agent 闭环，工程化打磨）

ChatCoding 让普通人“一句话点亮硬件创意”；VibeCoding 打通了从创意到正式硬件产品的最后一环

当电脑里的 AI 可以直接和你的 ESP-Mosaico 真机对话、读写、烧录、调试，嵌入式开发的范式就变了：不再是人去适配硬件、适配工具链；而是 AI Agent 作为助手，直接接管硬件工程全链路，你只需要专注想法本身。

ChatCoding 是“让创意先跑起来”，VibeCoding 是“让跑起来的东西站得住”。