消息：
Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。


https://www.xyfan.com/data/attac ... 6ab6f3d8f7b289.jpeg

文章代表作者个人观点，少数派仅对标题和排版略作修改。


https://www.xyfan.com/data/attac ... 86dc55dd8bfbbe1.png

本文记录的固件代码由 Anthropic 的 Claude Code（Claude 模型）编写，作者负责提出需求、在开发板上安装验证和做决定。文章初稿由 Claude 根据开发过程中的会话记录和交接文档整理成文，作者逐段改写并核对了其中的事实、数据和引用来源；文中「顺手想到」和「放大看」两类段落的观点为作者本人所写。示意图由 Claude 按作者要求绘制，实拍照片和截图为作者本人拍摄、截取。作者已对全文做了核查和修改，文责自负。


https://www.xyfan.com/data/attac ... 7543f234028d67a.png

如果有人问我，我花时间，花 Token 来做这么一个没有用的东西有价值吗？我的回答是肯定的，最大的意义其实就在于，证明 Vibe Coding 在硬件领域正在快速成长，为什么呢？因为数字世界已经到了一定的瓶颈了，是需要物理世界来反哺数字世界。如果没有 AI Agent 发展到今天这个程度，我是完全不敢想象自己要能做这件事要花多少时间去学习硬件、嵌入式、软件、通信等知识，要去查多少资料，这都需要时间的积累，但这些积累在数字世界基本都有了，硬件的东西像乐鑫这样子专业的公司做了就行了。


https://www.xyfan.com/data/attac ... 09982ae5bd41152.png

整个过程是我和 Claude Code 一起做的，前后开了四个会话，其中两个在同一块板子上并行干活。这篇按发生的顺序写，分五段，每段后面放一点做的时候顺手想到的，最后放大看。代码在这两个仓库：


https://www.xyfan.com/data/attac ... ef9c19b7f560789.png

那句提示词丢进去之后，AI 先花了一个晚上搭环境，坑都在环境这一层，不在游戏：


https://www.xyfan.com/data/attac ... f74637ce2eec45e.png

模拟器里顺手抓到一个模板的 bug：空白游戏模板只听触摸点 0，浏览器把鼠标报成点 1，所以点击没反应。改成跟着先按下的那根手指或鼠标走。


https://www.xyfan.com/data/attac ... fd0df15a5afcdc6.png

贪吃蛇做完，环境也就踩通了。接下来的 Muse 全部建立在这上面。


https://www.xyfan.com/data/attac ... 0b60a883a179a89.png

初次使用，我发现 Muse 比 GrokBot 反应是要快很多的，应该是意图识别做的更好，GrokBot 说什么都要比较长的反应时间，GrokBot 本身没有做任何设备交互的工作，界面显示的内容和设备播报的内容不会完全一致，Muse 就好很多。


https://www.xyfan.com/data/attac ... 4849ecbe4acb179.png

把 Muse 的固件直接编译给这块板，有三件事过不去：


https://www.xyfan.com/data/attac ... 14613012f71faeb.png

如果是我本人没有 Claude 的情况下，我都看不出来这三个问题，现在有了，不妨碍我继续玩下去。我的决定是：Vibe Mode 不动，把 Muse 做成一个标准的 ESP-Mosaico 应用，用 Vibe Mode 装机。后面的 Flash 的分法是 Claude 做的，变成下面这样。


https://www.xyfan.com/data/attac ... 271b1b9f98a295c.png

Muse 的配对信息、Wi-Fi 密码、设备凭证都在那块 64 KB 的 nvs 里，换固件不会清，所以后面十几次装机都没有重新配过对。这个点太重要了，如果不是做这个项目，我完全不知道还可以这样子操作。


https://www.xyfan.com/data/attac ... c421c45e8741f1e.png

路由器是普通家用的，改不了网关。最后的做法是把 Mac Studio 当旁路由，只让板子这一台走它，家里别的设备不动。


https://www.xyfan.com/data/attac ... 0f60139b3ccd934.png

配对本身很顺：App 里选设备，日志提示确认时短按 AI 键，填 Wi-Fi 密码，板子重启后连上 Muse。


https://www.xyfan.com/data/attac ... 71742903724362b.png

带屏幕的 Muse 界面是 LVGL 画的，上游用的板子是圆屏。移植有两个选择：照着 Muse 已支持的 Waveshare 板写一套驱动，或者用 ESP-Mosaico 官方的 BSP。选了 BSP：它认识这块板的两个硬件版本（引脚从 eFuse 读），管着屏幕依赖的电源，还会接住 Vibe Mode 的开机画面，让屏幕一直显示到 Muse 画出第一帧。代价是关掉 BSP 自带的 LVGL 层，图形库只留 Muse 那一份，免得两份打架。


https://www.xyfan.com/data/attac ... 00f7ef44fcade81.png

Muse 自带一个桌面模拟器，给它加了一档 480 方屏的配置。待机、聆听、思考、配网、出错五个状态先在模拟器里看过，没有越界，再上板。


https://www.xyfan.com/data/attac ... 49b3626e3b1c4aa.png

配对成功后第一次用中文提问，屏幕上一片空白。Muse 的字幕字体是 unscii，只有 ASCII。固件会把弯引号、破折号这些转成英文符号，汉字直接没了。


https://www.xyfan.com/data/attac ... 85678c69cfb3995.png

Muse 这边加了一个「宽字体回退」：主字体没有的字去宽字体里找。两个细节要处理：


https://www.xyfan.com/data/attac ... 0a07b6739fe2674.png

还顺手抓到一个老 bug：字幕缓冲 400 字节，一个汉字占 3 字节，一页中文只能放半页，后半页被跳过。改成 800 字节，补了一条测试，旧代码跑这条会挂。后来又把 Markdown 从字幕里去掉了：行首的井号、列表号、引用号，行内的加粗、代码、删除线，链接只留文字。Muse 写回复很爱用这些符号，在 16 px 的字幕里只会碍事。


https://www.xyfan.com/data/attac ... 05e514e56cd5493.png

板子这边，摄像头子板插左槽。第一版按 BSP 文档里的 OV3640 写，让传感器直接出 JPEG。装上去一试，Muse 说拍了两次都失败：


https://www.xyfan.com/data/attac ... afdfe9c63a5aae7.png

esp-sr 只认汉字、数字和中文标点，Muse 的回复里有 Markdown、表情、链接和零星英文，念之前要先清理一遍：


https://www.xyfan.com/data/attac ... 3c9c014f351db36.png

喇叭开着时，字幕跟着语音走；喇叭关着时按阅读节奏翻页，和上游一样。


https://www.xyfan.com/data/attac ... 33c24a7b3bea33b.jpg

这条路第一版就把板子搞崩了。服务端按合成速度往板子灌 PCM，板子只开了 1 秒的下载缓冲，读不完的语音堆在网络协议栈里，占住 Wi-Fi 的接收缓冲，片内 DMA 内存被吃到 1 KB 以下。改成两头都收着：服务端先发 1 秒，之后不超过实时的 1.5 倍；板子把整条语音先存进 PSRAM 再播。试过把 Wi-Fi 的缓冲挪去 PSRAM，这颗芯片上进不去，反而多出一批常驻的发送缓冲，撤回了。


https://www.xyfan.com/data/attac ... a2acddec64829d7.jpg

接着是一个更难的：对话中随机崩，空闲时也崩过一次。板上留下的 5 份 core dump 全是读内存出错，地址都是合法的 PSRAM 数据，而且全部落在 PSRAM 里只读区和可读写区的分界线之后 46 KB 以内。读了两个核的内存保护寄存器，都是对的。能稳定复现：同时跑一个内存锤子测试和边下载边播放，4 分钟左右崩一次。


https://www.xyfan.com/data/attac ... e2e4a339d6b304b.png

这是另一个会话做的。右槽插 ESP-Mosaico 的交互模块，上面有一个 PIR 人体感应和 6 颗 WS2812 灯。想要的效果是我走到桌前，它亮灯、亮屏、打个招呼。

PIR 感应的是动作，不是存在。坐着一分钟不动再动一下，会被当成新来人，灯再亮 6 秒。

ESP32-S31 的片内 RAM 是紧的，Wi-Fi 和 TLS 都要从里面拿 DMA 内存。加上字体、语音、问候之后，Muse 就绪时的空闲片内内存从 74.7 KB 掉到 49.0 KB，DMA 内存最低到过 12 KB。两个会话各自把能挪的挪到 PSRAM：语音的文本缓冲和字幕页、问候任务的 4 KB 栈和状态。前提是查过它们的调用链不碰 flash。

剩下的大头在 BSP 里：模块管理器以前拍照时才启动，现在开机就起，带两个各 4 KB 的片内栈，大小写死在子模块里。

语音转文字的信息现在是最容易被从真实世界收集上来的。

做到这里，板子是在「被动服务」：Muse 要看就拍，回复来了就念。我问 Muse「你能用 gadget 说话吗」，它答「没有扬声器播放的指令」。这句话点明了 Muse 和板子之间的关系：不是 MCP，是 Meta 自己的 Home Link 协议。板子连上时报一份命令清单，每条带描述和参数，Muse 看着清单决定什么时候调。上游的清单里只有五条：健康、发现、画一张网址图、放动画、拍照。

我们在研究 Home Agent 这条赛道的时候，团队其实最大的争议就是“主机太贵了，谁会买呀”，确实会买的人很少，便宜的能力又不够，而我这样想站在最前沿尝试的人会买。手里有一点算力，有 Token 真的感觉很爽，难以想象那些富豪有多爽，现在勉强可以想象了，在探索 AI 这条路上目前还没遇到大的阻碍，再大一点的模型我暂时也还玩不动，我主要是探索应用领域。

这个周末开了四个 Claude Code 会话，之后两天又开了几个。

有意思的是最后一天下午，两个会话在同一块板子、同一个 build 目录上并行：一个做字幕、拍照、语音，一个做来人问候。它们之间互发消息排队：谁要编译先打招呼，装机前确认对方没在测，装完报一下 Boot ID 和内存数字。语音那边的崩溃修复和问候那边的灭灯修复，最后是合在一个固件里由一个会话装上去的。

回到机器人本身。相信业内早已达成共识就是，双足人形机器人技术是最厉害的，但不是最实用的，后面在各个细分领域都有专属具身智能机器人在执行任务。扫地还是扫地机器人、割草还是割草机，以此类推。过去多少年来，我们已经发明太多非人形态的设备来提升效率了，未来我们这是要把这些设备都和 AI 结合起来，这也是为什么早就有人说“所有硬件都会被 AI 重做一遍”，这个重做一遍现在看来硬件层面的有，软件层面的也有。

人为什么要制造机器，是为了提升效率。其实同样一个任务交给人去做可能需要一个小时，但如果是交给 AI 做，10 分钟没做好就觉得这个 AI 不行，实时语音交互的 AI 设备和场景就会遇到这样子的问题。如何在 AI 硬件场景下解决普通用户对 AI 过高的期待，既需要工程化手段，也需要 AI 进一步普及，让普通用户也能理解 AI 的能力边界。

未来很长一段时间的 AI 产品，一定是软件硬件结合的，赋予用户自由创造的自由，硬件的能力一定会有冗余的，如果还在追求极致的成本管控，那根本不可能做的好 AI 硬件。只有冗余的硬件设计才能填补硬件开发物理周期和 AI 软件发展的时间差，同样一款硬件至少要覆盖半年以上的 AI 软件发展。今后不会再有公司做出来一款极致成本的 AI 硬件来解决用户的场景问题，一定是一些极客用户在某个场景下开发出了应用，帮助更多的人解决同样的问题，这个需求会被更细分，垂直的市场会更多，但他们用的可能都是同一款硬件。只有在量级超过一定数量之后才会去做 Cost Down 的操作，或者说 AI 能力发展要求硬件的能力更低之后成本会更低。

现在我就正在做一款集合超过 10 种感知能力于一体的设备，我把在家里能想到的感知能力都放进来了，还做了一个配套的 Agent，打算全开源出来给大家玩。希望能帮助你用 Claude/Codex 或者其他工具就能去实现你的想法，你完全可以不用操心硬件的事情。现在产品在收敛的状态，写这篇文章是希望如果你有类似的想法可以联系我，我们交流一下，一起共创，看看你还想加什么样的感知能力。

点击下方按钮可复制链接
（转载少数派）