ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

属于 vibe coding 时代的宠物来啦:Vibe Pet 配 TaoToken 的 config.toml 骨架与 BLE 联调

属于 vibe coding 时代的宠物来啦:Vibe Pet 配 TaoToken 的 config.toml 骨架与 BLE 联调 1. 当桌宠开始读你的 AI 编程状态Vibe Pet 是一个给 AI 编程助手准备的桌宠项目它能读取 Codex、Cursor、Windsurf 以及其他 CLI / IDE 里 AI 编程助手的实时状态把「正在思考」「正在写代码」「报错了」这些状态变成桌面上的小宠物动画再通过 BLE 同步到 Wio Terminal 或 ESP32-S3 这类嵌入式设备上。适合谁适合同时开着一堆编辑器、想让 AI 助手状态一眼可见的开发者也适合手里正好有一块 ESP32-S3 TFT 屏、想低成本30 元左右跑通一个 AI 宠物交互原型的嵌入式玩家。它解决的核心痛点很具体当你一堆编辑器同时打开让 AI 写代码时很难一眼看到某个编辑器的状态。桌宠把抽象状态变成可视动画硬件端再把这种可视性延伸到桌面之外。桌面端和嵌入式端都支持意味着你可以先在电脑上跑通效果再决定要不要接硬件。这篇要做的不是泛泛介绍而是把双端联调一次跑通给出 TaoToken 统一 Key / API 通道的config.toml可复制骨架演示桌面端与 ESP32-S3 的 BLE 配对、消息收发以及报错排查的验证动作。TaoToken 在这里的角色是统一模型接入通道让 Vibe Pet 背后调用的模型请求走同一套 Key 和 API 地址省去多平台配置的麻烦。2. TaoToken 前置统一 Key 与 API 通道Vibe Pet 本身是桌宠与状态同步层但它背后的 AI 编程助手需要模型能力。如果你同时用多个助手、多个模型Key 管理会变得很碎。TaoToken 提供统一 Key / API 通道把模型调用收敛到一套配置里config.toml就是承载这套配置的骨架文件。先明确几个地址后面配置里会用到官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基地址https://taotoken.net/api模型对话页https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewriteCoding Plan 页https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteClaudeCodeAnthropic 接入https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite注意API 基地址不带 UTM 参数直接写https://taotoken.net/api即可避免某些客户端把查询串拼进请求路径导致 404。拿到 Key 的路径是进 API Keys 管理页创建 Key复制后只存在本地配置文件或环境变量里不要提交到 Git。Vibe Pet 的config.toml里我们用一个[taotoken]段落承载它桌面端和嵌入式端共用同一份 Key 语义但嵌入式端不直接持有 Key——Key 留在桌面端嵌入式端只通过 BLE 收状态这样更安全。3. 可复制配置config.toml 骨架下面这份config.toml骨架可以直接复制放在 Vibe Pet 的配置目录下桌面端一般是用户配置目录具体路径看 Releases 安装包的说明。它分成三段TaoToken 通道、桌宠行为、BLE 硬件。# Vibe Pet config.toml 骨架 # 桌面端与嵌入式端联调配置 [taotoken] # 统一 API 通道注意不要带查询参数 base_url https://taotoken.net/api # 从 API Keys 管理页创建后填入建议用环境变量覆盖 api_key sk-替换成你自己的Key # 默认模型按需替换 model claude-sonnet # 请求超时秒 timeout 60 [pet] # 桌宠显示模式desktop / hardware / both mode both # 状态刷新间隔毫秒 refresh_ms 800 # 是否把每个助手的宠物卡片分开显示 per_assistant_card true [ble] # 设备名关键字用于扫描过滤 device_name_prefix VibePet # 服务 UUID桌面端与固件需一致 service_uuid 0000ffe0-0000-1000-8000-00805f9b34fb # 状态特征 UUID桌面端写入、设备端读取 state_char_uuid 0000ffe1-0000-1000-8000-00805f9b34fb # 扫描超时秒 scan_timeout 10 # 断线自动重连 auto_reconnect true几个关键点解释一下。base_url用https://taotoken.net/api不要在后面加斜杠或查询串。api_key建议用环境变量覆盖比如在启动脚本里export TAOTOKEN_API_KEYsk-xxx然后配置里写api_key ${TAOTOKEN_API_KEY}这样配置文件可以安全地放进版本库。service_uuid和state_char_uuid必须和 ESP32-S3 固件里定义的一致否则 BLE 能连上但收不到状态。嵌入式端不需要这份完整配置它只需要 BLE 部分。ESP32-S3 固件里对应的宏定义大致如下// ESP32-S3 固件侧 BLE 定义与 config.toml 对齐 #define DEVICE_NAME VibePet-S3 #define SERVICE_UUID 0000ffe0-0000-1000-8000-00805f9b34fb #define STATE_CHAR_UUID 0000ffe1-0000-1000-8000-00805f9b34fb设备名以VibePet开头桌面端扫描时用device_name_prefix过滤避免扫到一堆无关蓝牙设备。4. 双端 BLE 联调与验证请求配置写好后联调顺序建议是先桌面端单独跑通再接硬件。桌面端启动 Vibe Pet确认桌宠动画能随 AI 助手状态变化然后给 ESP32-S3 上电屏幕亮起进入 BLE 广播最后在桌面端触发扫描和连接。桌面端连接设备后会向state_char_uuid写入状态数据。状态数据用一个简单的 JSON 字符串方便调试{assistant:cursor,state:thinking,pet:cat,ts:1730000000}嵌入式端收到后解析state字段切换 LVGL 角色动画。验证请求是否成功可以分两步看。第一步桌面端日志确认写入。Vibe Pet 一般会在日志里打印 BLE 写入结果看到类似BLE write ok, len64就说明桌面端到设备端的链路通了。第二步设备端串口确认接收。ESP32-S3 用串口监视器115200 波特率能看到回调打印// 设备端接收回调示例 static void on_state_write(BLECharacteristic *c) { std::string v c-getValue(); Serial.printf(recv state: %s\n, v.c_str()); }如果串口打印出recv state: {assistant:cursor,...}说明双端联调成功。此时你在 Cursor 里让 AI 写一段代码桌面桌宠进入「思考」动画ESP32-S3 屏幕上的宠物也应同步切换。想单独验证 TaoToken 通道是否通可以用一条 curl 请求打模型对话接口curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:claude-sonnet,messages:[{role:user,content:ping}]}返回里有choices字段就说明 Key 和通道都正常。这一步和 BLE 无关但能帮你把「模型通道」和「硬件链路」两个问题域分开排障时不会互相干扰。5. 本篇常见错排查联调时最容易卡在几个固定位置按下面顺序排查效率最高。BLE 扫不到设备。先确认 ESP32-S3 固件确实在广播串口能看到BLE advertising started。再确认device_name_prefix和固件里的DEVICE_NAME前缀一致。如果设备名是VibePet-S3前缀写VibePet能匹配写VibePet-S3也能匹配但写vibepet大小写不一致就扫不到。能连上但收不到状态。九成是 UUID 不匹配。桌面端state_char_uuid和固件STATE_CHAR_UUID必须逐字符一致包括中间的-。另外确认桌面端写入的是 state 特征不是 service 特征。写入报错GATT_WRITE_NOT_PERMITTED。固件里 state 特征的属性要包含WRITE或WRITE_NR。如果只声明了READ桌面端写入会被拒。检查固件里BLECharacteristic创建时的属性位。TaoToken 请求 401。Key 没填对或者环境变量没生效。先在终端echo $TAOTOKEN_API_KEY确认有值再确认config.toml里没有把 Key 写死成占位符。如果用的是${TAOTOKEN_API_KEY}语法确认 Vibe Pet 启动时能读到该环境变量。请求 404。大概率是base_url拼错了。正确值是https://taotoken.net/api不要写成https://taotoken.net/api/或带查询串。某些 HTTP 客户端会把 base_url 和路径直接拼接多一个斜杠就变成//v1/chat/completions。断线后不重连。确认auto_reconnect true同时检查设备端是否在断开后重新开始广播。有些固件断开后不重启广播桌面端自然扫不到。提示排障时把桌面端日志和设备端串口并排看时间戳对齐能快速定位是「桌面端没发」还是「设备端没收到」。6. 继续接入与下一步双端跑通后下一步通常是两件事把模型通道换成更稳定的长期方案以及把 BLE 状态协议扩展成双向。模型通道方面如果你要长期跑编码类助手可以看 Coding Plan 页https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它更适合持续性的编码场景。如果只是验证模型返回模型对话页更直接https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。接入细节和参数说明都在接入文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。Key 的创建和管理在 API Keys 页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。如果你用 ClaudeCodeAnthropic 那套工具链对应接入页是https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。BLE 协议扩展的方向我自己的做法是给 state 特征加一个 notify 属性设备端也能主动上报按键或触摸事件桌面端订阅后就能做双向交互。这样 Vibe Pet 就不只是「显示状态」而是能反过来影响 AI 助手的行为。先把单向跑稳再动双向排障成本会低很多。
返回列表