[The Verge 編輯 Sean Hollister 試用 Muse Charm 概念裝置時，遇到回答顯示不便、按住說話鍵稍快放開就送出近乎空白音訊的問題。他用 Claude Code（Anthropic 的 AI 程式編輯工具）改寫 Waveshare ESP32-S3 1.75C 觸控開發板韌體，加入可滑動的對話紀錄、調整語音送出條件並接入播報。後續原型還接上手機相機預覽與虛擬寵物遊戲。這些調整解決的是操作流程中的具體卡點，成品仍是開發板原型，不能當成 Meta 正式版 Muse Charm。
這個案例帶出一個實際問題：畫面、語音、相機和遊戲都出現在同一個小裝置上，是否代表 AI 模型獨自完成了所有工作？拆開來看，模型、韌體、開發板、手機和雲端服務各自承擔不同環節；只看展示畫面，很難判斷功能依賴哪些配件、網路和帳號條件。
ESP32 開發板如何變成 Muse 電子寵物原型？
原型使用 Waveshare ESP32-S3 1.75C 觸控開發板（搭載 ESP32-S3 微控制器）和 Muse Gadgets SDK（軟體開發套件）韌體，再由 Claude Code 協助改寫。它不能視為 Meta 正式版 Muse Charm。
The Verge 編輯改造了哪一塊板子
Hollister 以 Claude Code 改寫程式。ESP32-S3 執行韌體並處理輸入輸出，螢幕、麥克風和喇叭負責顯示與語音互動。
Vibe coding（以自然語言描述需求、由 AI 協助編寫程式）之後，仍須由人建置和測試。報導未展示程式碼品質或安全測試結果。
另有兩個可供比較的 ESP32 圓屏整合專案，並非 Muse 原型的一部分。GitHub 帳號 vthinkxie 的 Claude Desktop Buddy 移植專案將 Claude 桌面程式的近期訊息與權限提示送到 ESP32 AMOLED 螢幕，讓使用者在裝置上核准或拒絕操作。作者在 README 列出四款已支援的 Waveshare AMOLED 板，並說明共用同一套主要介面、各板接線與驅動分開處理；這項成果顯示功能移植涵蓋四種板型，也具體呈現硬體差異仍須逐板設定。
Maler X 的 MOTO GPS 專案則把 iPhone 導航與 Waveshare ESP32-S3 圓屏組成機車導航原型：手機處理定位、搜尋和路線計算，圓屏透過藍牙顯示導航、速度與相對航向，也能控制 Apple Music。作者公開了圓屏韌體、iOS App、路線閘道和網頁除錯工具，並在 README 記錄 2026 年 9 月 16 日通過 9 組 C++、60 項後端、12 項 Swift 核心及 13 項 BLE 策略測試。
這些是作者公布的程式與資料路徑測試結果，不代表獨立驗證或道路測試。README 仍將專案標示為實驗性樣機，真機配對與騎乘也在驗證中，因此不能據此判定長時間使用已完成。
Meta 開放的 Muse Gadgets 硬體 SDK 試作方式也說明韌體、配對和帳號權杖如何影響裝置連線。
原型與 Muse Charm 正式產品要分開看
Muse Charm 是 Meta 的裝置概念，Muse Gadgets 是連接相容硬體與 Muse 服務的 SDK 和韌體；Waveshare 則是 Hollister 的個人原型，不能代表正式規格。
對話、語音與螢幕功能分別由誰負責？
模型產生文字，外部語音服務轉成聲音；韌體負責顯示和音訊，整合仰賴網路、授權與周邊驅動。
模型回覆、雲端連線與語音服務
Hollister 用 Muse 服務處理對話，另接 ElevenLabs 將文字轉成播報語音。這條流程至少經過收音、網路傳送、服務回覆和喇叭播放；任一環節延遲或失敗，使用者看到的都是「裝置沒即時回應」，但故障位置可能完全不同。測試時可分別記錄音訊送出、文字回覆抵達及播音開始的時間，避免只用整體體感猜測瓶頸。
Hollister 將部分延遲歸因於 Meta 伺服器，這是單次使用觀察，無法區分網路品質、服務端處理或音訊播放各自占用的時間。分段時間若顯示文字回覆尚未抵達前等待較久，可優先檢查連線與服務端；若文字已到、播音才延後，則應檢查語音服務和播放緩衝。這些線索只能協助縮小排查範圍，仍須在相同網路與設定下多次重測，才能比較結果是否穩定。
使用前可先查各服務的資料政策與使用條款，確認語音會送往哪些服務、帳號權杖如何撤銷，以及其中一項服務停用後裝置還能做什麼。The Verge 報導沒有交代資料保存細節，因此不能從功能展示推測音訊或對話紀錄保存多久；選擇試作方案時，應以服務文件和帳號設定頁能確認的內容為準。
韌體如何處理對話紀錄和畫面
韌體處理回覆分頁、觸控和畫面狀態。Hollister 發現原本畫面不便閱讀較長回答，於是請 Claude Code 加入可滑動的對話紀錄頁。這項韌體調整改善文字到達裝置後的呈現方式，處理範圍在介面呈現與操作流程。檢查類似功能時，可用長短不同的回答測試換頁、滑動與新回覆插入時的顯示順序，也要確認小螢幕上的文字是否被裁切。
Hollister 發現太快放開按住說話鍵會送出近乎空白的音訊，於是把傳送條件改為只送出超過一秒的音訊。
Meta Muse Gadget SDK 的 ESP32 README「Boards」表列出各板卡支援的介面與功能；標示 UI 的板卡支援螢幕介面，音訊與影像能力則依板卡而異。這份相容性表顯示，即使晶片系列相同，螢幕控制器、觸控元件、接腳配置和記憶體也可能不同。選板時應逐項比對 SDK 支援表與板卡文件；表格未列出的周邊應標為待驗證項目，確認前不要假設韌體支援。
遠端相機與虛擬寵物怎麼整合進同一裝置？
相機預覽依賴手機相機程式、裝置連線與控制介面；寵物遊戲則由程式保存狀態並執行互動規則。
手機相機預覽需要哪些連線與程式
Hollister 的遠端取景器以 Waveshare 按鍵控制手機相機、回傳預覽；低畫質藍牙模式可脫離家中 Wi-Fi 取景。
評估相機權限、藍牙畫質、斷線提示和照片傳輸路徑時，可以先用手機螢幕確認取景，再比較圓屏預覽是否有明顯延遲或更新中斷，最後測試離開應用程式或關閉藍牙時裝置如何提示。若只有預覽畫面而沒有照片回傳，不應把它描述成遠端拍照已完成；預覽、快門控制和影像儲存是不同的功能環節。
若低畫質藍牙模式停格、而 Wi-Fi 模式正常，可優先檢查藍牙傳輸距離與連線穩定度；若兩種模式都停格，再查手機應用程式是否仍在前景執行，以及圓屏端是否持續更新畫面。這些測試結果有助於定位傳輸或顯示環節，不能只憑圓屏無反應就歸因於 AI 模型。
寵物遊戲的狀態和互動規則不是模型本身
報導中的虛擬寵物可進食、玩耍、睡覺和洗澡；Hollister再加入飢餓、無聊、髒污狀態。裝置程式保存狀態、套用規則並播放動畫。
寵物狀態由程式保存、規則判斷和動畫呈現。檢查時可讓裝置重開機，確認飢餓或清潔狀態是否依設計保留；再比較快速連點與正常操作，看看狀態變化是否重複觸發。若狀態只存在記憶體，斷電後歸零可能是設計結果，也可能是未完成的保存功能，需先釐清需求再判定。
Vibe coding 加快原型後，哪些問題仍要人工確認？
要確認板卡相容、韌體可建置、憑證安全、斷線處理和程式品質。單次展示不能代替這些驗證。
板卡相容、韌體測試與程式品質
ESP32 板卡的螢幕、觸控、音訊、記憶體與接腳可能不同。SDK 和原理圖可協助核對型號，不能保證修改後都能運作。尤其外觀相似的圓形螢幕，仍可能採用不同顯示或觸控驅動；更換板卡後，先確認韌體選用正確的硬體設定，再逐一測試螢幕初始化、觸控座標、麥克風輸入與喇叭輸出。若只驗證開機畫面，無法代表語音和互動流程也正常。
測試開機、Wi-Fi、配對、畫面、觸控、收音、播音與手機連線，並記錄板卡型號、韌體版本、SDK 版本、設定變更和錯誤訊息。每次只改一項設定，才能知道是哪個修改造成結果不同。對 vibe coding 產生的程式，也應保留可檢視的原始碼與建置紀錄，逐段確認權限判斷、網路請求和資料寫入位置；能成功編譯只表示程式通過建置，不代表它符合預期或已處理所有錯誤狀況。
Meta Muse Gadget SDK 的 ESP32 README 在開頭的安全提示中寫道：「Flashing custom firmware can brick boards and void warranties. Proceed at your own risk!」（燒錄自訂韌體可能使開發板無法啟動，也可能影響保固，請自行承擔風險。）這是 SDK 文件對燒錄行為的警示；個別板卡的實際後果仍依硬體與保固條款而定。
雲端延遲、帳號權限與網路隔離
SDK 要求每個裝置使用 token，並透過 Muse App 配對；文件也提醒，社群裝置未經製造商驗證，配對無法防止中間人攻擊。Hollister 使用訪客 Wi-Fi，這是他的個人做法，不能單獨證明裝置或網路安全。評估隔離效果時，應查看路由器是否真的阻止訪客裝置連入家中其他設備，並確認測試帳號能否撤銷、韌體是否只從可信來源取得。
還要確認手機相機與麥克風權限是否只在需要時開啟，測試用 token 是否避免寫進公開程式庫。這些設定需要從路由器、手機和 SDK 帳號各自檢查，單一頁面的「已連線」狀態不會告訴你其他服務是否仍持有存取權。
可安排一次實際斷網測試，分別操作本地遊戲、Muse 對話和外部語音，記下哪些功能仍可用、哪些會顯示錯誤。這能把「裝置有沒有離線能力」拆成可觀察的功能清單，也方便判斷網路恢復後是否需要重新配對或登入。帳號撤銷則應另做一次演練，確認停用 token 後裝置確實無法再呼叫服務。
評估 AI 硬體原型時可以檢查哪些條件？
把功能拆成硬體、韌體、手機、雲端和帳號權限，再核對相容性、故障處理與停用方式。
對其他 vibe coding 硬體專案，建議照以下順序盤點：
- 核對板卡：檢查周邊、電源和 SDK 支援。
- 畫出依賴：標出模型、語音、手機和網路，區分本地與雲端處理。
- 檢查權限：核對相機、麥克風、帳號及 token 撤銷方式。
- 測試故障：測斷網、逾時、按鍵過快、重啟和配對。
- 準備復原：記下韌體建置方式，備妥原廠韌體並於更新後重測。
多服務整合須確認資料流與中斷備援；可參考 vibe coding 部署時的雲端平台選擇。
- 展示成功不等於品質、安全或相容性已獲驗證。
常見問題
Q1：ESP32 本身可以執行大型 AI 模型嗎？
此原型的對話依賴 Muse 雲端，ESP32-S3 負責韌體和周邊；其他專案須按模型與記憶體確認。
Q2：Claude Code 寫出的韌體可以直接用在所有 ESP32 開發板嗎？
不行。板卡周邊和 SDK 需求不同，須查支援清單並實測。
Q3：把裝置連到訪客 Wi-Fi 就安全了嗎？
不一定，還要檢查網路隔離、token、服務和手機權限。
Q4：這個原型能代表 Meta Muse Charm 的正式功能嗎？
不能，這是個人原型，正式功能以 Meta 規格為準。
