py-xiaozhi 實測：免硬體跑小智 AI 語音助理，啟動先綁帳號

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

想在電腦上體驗小智 AI 語音助理，過去要先買一塊 ESP32 開發板、燒錄韌體；py-xiaozhi 把這道門拆掉了，Windows、macOS、Linux 都能跑，有麥克風就能對話。我在 macOS 上實際裝了一次、啟動了一次，結論先講：免硬體這件事是真的，安裝也順利，但第一次啟動的第一個畫面不是對話框，是一組六位數驗證碼，要你先去 xiaozhi.me 註冊帳號、把這台電腦綁定成一台「設備」，綁完才能開口說話。而在你綁定之前，這台電腦的網路卡 MAC 位址、一組設備序號，還有你連線的對外 IP，都已經先送出去了。

我從原始碼層把啟動流程讀完：它向哪個伺服器報到、帶了哪些識別碼、語音流量走哪條線、雲端模型反過來能操作你電腦的哪些東西。對話品質、喚醒詞靈敏度我沒有測（綁定需要帳號，我停在這一步），所以這篇談的是啟動之前你就該知道的邊界，不是使用心得。

裝完啟動，先撞上 xiaozhi.me 的綁定閘門

安裝有兩條路。想直接用的人，GitHub Releases 提供安裝包：macOS 的 dmg 約 314MB（Intel Mac 版約 366MB）、Windows 的 exe 約 295MB、Linux 有 x86 與 ARM 兩種 deb。體積會這麼大，是打包流程把可攜的 FFmpeg 等依賴整包塞了進去，從原始碼的打包腳本與提交紀錄可以直接對上；好處是裝完即用，不必先架 Python 環境。想跑原始碼的人，clone 下來一行 uv sync 就把依賴裝完，我實測的這條路一次成功，接著 python main.py 啟動圖形介面，加 –mode cli 可以只跑命令列。專案指定 Python 3.10 到 3.12，圖形介面要多裝一組 GUI 套件，命令列模式的依賴乾淨得多，這對樹莓派之類記憶體有限的板子有實際差別。

真正的第一道門在啟動之後。程式第一次跑起來會先產生一份「設備指紋」：一組序號、一把 HMAC 金鑰、以及這台電腦真實的 MAC 位址，存在本機設定檔裡；接著它向小智官方的 OTA 端點報到，伺服器回覆「這台設備還沒綁定」，命令列畫面於是印出六位數驗證碼，指示你打開 xiaozhi.me、登入帳號、新增設備、輸入那組數字。整個流程與 ESP32 硬體版完全同一套，官方把它設計成設備制，你的電腦在系統裡就是一台小智設備。原始碼裡有一個 –skip-activation 旗標可以跳過這一步，但註解寫明是除錯模式，跳過之後伺服器端會不會放行，文件沒有保證，我沒有繼續往下測。

xiaozhi.me 是小智生態的官方控制台，頁尾的聯絡信箱掛在 tenclass.com 網域，與語音後端 api.tenclass.net 同一家。也就是說，綁定帳號、設備管理、語音服務，都收斂在同一個營運主體手上。

Pin

還沒開口說話，三樣識別碼已經出門

把啟動流程的程式碼攤開看，綁定之前客戶端已經先做了一輪事。OTA 請求的標頭帶著 Device-Id，值就是網路卡 MAC 位址；另一個 Client-Id 是自動生成的 UUID；請求內容除了軟體版本，還包含板型名稱與這台電腦的區網 IP。對一個還沒綁定、還沒對話的客戶端來說，這份名單不算短。

更值得記下的是伺服器發回來的東西。OTA 回應會把後續連線設定直接寫進本機設定檔，我實測那次拿到的內容包括：語音通道的 WebSocket 位址 wss://api.tenclass.net/xiaozhi/v1/、一組 MQTT 連線憑證，以及一個存取權杖，未綁定設備拿到的權杖字面值就是 test-token。其中 MQTT 憑證的使用者名稱是一串 base64，解開後是這個格式：{“ip”:”你的對外 IP”,”c”:0}。伺服器在你報到的當下，就把你連線用的公共 IP 編進了它發給你的憑證裡。

這些不是偷跑，是這套設備協議的設計：伺服器要靠 MAC 位址認設備、靠 IP 做連線管理，客戶端對伺服器的身分則靠一把存在本機的 HMAC 金鑰簽名，屬於設備對伺服器的單向驗證。但對使用者來說，意思很具體，你只是想跟 AI 聊天，這台電腦的硬體識別碼與網路位置已經在對方系統裡掛了號。隨後的每次對話，麥克風收到的音訊都會送往上面那個 WebSocket 位址，也就是蝦哥官方的伺服器；程式也支援把通道換成 MQTT 協定，位址同樣由 OTA 下發，兩種協定背後是同一個端點。

兩條通道都有加密，但都關掉了身分驗證

語音走 wss，也就是加密的 WebSocket，OTA 請求走 HTTPS，聽起來安全。但程式碼裡有兩個細節值得停下來看。第一，OTA 請求雖然是 HTTPS，程式卻主動關閉了憑證驗證：check_hostname 設為 False、憑證模式設為 CERT_NONE，等於只要求「有加密」，不檢查「對方是不是真的是那台伺服器」。第二，2026 年 9 月 11 日發布的 v2.1.2 把 MQTT 連線也改成同一套做法，TLS 從需要憑證改成不驗證，還呼叫了 tls_insecure_set，提交訊息直接寫著跳過憑證驗證。

為什麼要這樣改？合理的推測是為了自架服務端的用戶：自己架的伺服器常用自簽憑證，嚴格驗證會連不上，放寬是最省事的解法。但代價由所有人一起承擔，在可被劫持的網路環境裡，關閉驗證的加密通道抵擋不了中間人冒充伺服器。這不是理論潔癖：一個會接收你全部語音、又能反向操作你電腦的通道，身分驗證與加密同樣重要。家用網路上風險低，公共 Wi-Fi 上就是另一回事了。

雲端模型拿到的權限：截圖、拍照、開關程式

py-xiaozhi 內建一組 MCP 工具，這是它最需要想清楚再開的功能。工具清單包括：桌面截圖、攝影機拍照、應用程式管理（掃描、啟動、強制關閉）、音樂播放、音量調整、天氣查詢，協議是 JSON-RPC 2.0，決定何時呼叫哪個工具的是服務端的 LLM，不是你本機。換句話說，你對它說「幫我看看螢幕上是什麼」，是雲端的模型決定按下截圖工具，畫面內容隨指令回傳。這條控制線的方向值得記住：權限在你這邊執行，決策在對方那邊發生。

攝影機的影像理解是另一段獨立的資料流向。設定檔裡的預設推理端點是智譜開放平台的 open.bigmodel.cn、預設模型 glm-4v-plus，API 金鑰欄位預設空著，要自己申請自己填。拍照功能等於把影像送到你填入的那家服務商，預設值指向中國的雲端服務，這一點使用前先知道。

好消息是這份工具清單可以裁剪。設定頁的 MCP 工具區按功能分組，每個工具都能單獨關閉；關掉之後不只是介面上看不到，客戶端回報給伺服器的工具清單裡也不會出現，服務端真的發起呼叫時會被客戶端拒絕。只想要語音對話、不需要桌面操作的人，把截圖、應用程式、攝影機三組關掉，暴露面就收窄到純語音，這是我會建議所有非開發者使用者的起手設定。

把這幾段接起來看，這套工具的信任邊界很清楚：喚醒與音訊採集在本機，但對話、工具調度、影像理解全在雲端，而雲端那側除了你的語音，還握著一批能碰你桌面的工具。把它當語音助理的玩具，這個交換或許值得；桌面上有工作機密的人，要先想過這條線。

留在你電腦上的部分，比想像的多

講了這麼多邊界，回頭說它做得實在的地方。喚醒詞「你好小智」的辨識用 sherpa-onnx 在本機跑，模型檔直接附在專案裡，不必另外下載，也就是說「有沒有被喚醒」這個判斷不出你的電腦，常駐收音的啟停判定在本地完成；不想用語音喚醒的人，設定檔裡另有五組快捷鍵，預設 Ctrl 加 J 是按住才送音（按鍵放開就停，等於手動閘門）、Ctrl 加 K 切自動對話、Ctrl 加 Q 中斷當前回覆，這套組合讓「只在我想講話時才收音」變成可行的工作方式。不想等喚醒詞辨識模型載入的人也可以直接把喚醒功能關掉，全部改走快捷鍵。授權是標準 MIT，LICENSE 檔在 repo 裡，商用修改都沒問題。專案活躍度夠：3,468 個 star、731 次 fork，v2.1.2 在我查詢的前三天（2026 年 9 月 11 日）才發布，當天上午維護者還連著提交了 MQTT 連線修復與版本封裝。它從蝦哥的 xiaozhi-esp32（29,878 個 star）衍生而來，README 另稱被 D-Robotics 的邊緣運算專案收為上游依賴，這一點屬於作者自己的宣稱，我沒有向對方查證。

Pin

還有一個少見的細節：repo 根目錄放了兩份開發者自己的可靠性審計報告，攤開列出修復前的問題清單，例如全案 275 處 except Exception，其中約 182 處捕獲例外卻沒有記錄堆疊，報告也附了修復後的對照。自己的問題自己攤開，這在開源專案裡不是常態，對想拿它當底座二次開發的人是正面訊號。介面也有三種姿態：桌面 GUI、純命令列，以及給樹莓派等硬體用的 GPIO 模式，ARM 板子都在支援清單裡，這也是它與一般「電腦版語音助理」定位最不一樣的地方，它同時把自己當成機器人與物聯網設備的軟體底座。

Pin

不想綁官方帳號，還有兩條路

如果不想把語音與設備識別交給官方後端，官方文件明言可以換掉兩個端點：把 OTA 位址改成自架伺服器、把授權頁改成自己的後台，系統之後就從你的伺服器拿連線資訊。生態系裡有現成的後端專案 xiaozhi-esp32-server（Python 版，附管理介面）與 Java 版，模型接哪家、對話邏輯怎麼寫都由自己決定，搭配 new-api 這類 API 閘道可以管理多個模型金鑰。這條路把信任邊界整個收回自己機房，代價是後端的安裝維運全自己來，適合有伺服器經驗的人。

另一條路是換硬體思路。手邊已經有小米音箱的人，open-xiaoai-speaker-mod 那篇談過的改造路線是把既有音箱接上自架後端，xiaomusic-xiaoai-speaker 則讓小愛音箱變身音樂播放器；真想體驗完整的小智硬體生態，ESP32 開發板加上原廠韌體是最正統的路，py-xiaozhi 的作者另外還有一個 Electron 桌面版。這幾條路我這次都沒有實測，列在這裡是把它們當選項，不是排名。

當玩具、當底座，或先不要：三種人的判斷

把它當「免費體驗小智」的玩具，付出一個 xiaozhi.me 帳號與一段雲端語音，換到跨平台、可自訂喚醒詞的語音助理，這個交換我認為值得，前提是你在它面前說的話本來就不機密。想拿它做語音應用原型或接機器人專案的人更該用：MIT 授權、三種介面模式、MCP 工具體系、自帶審計報告，底座該有的都有，自架後端一接就是一條完整生產線。

至於想把公司電腦或工作機裝上它的人，建議先停一下：截圖與應用程式工具掛在雲端模型底下、兩條通道關閉憑證驗證、後端服務本身沒有公開的隱私條款可查（repo 與文件裡都找不到對應段落，這是實際翻過的結論）。要用的話，挑一台乾淨的機器、在可信的網路環境跑，或者花一個下午把 xiaozhi-esp32-server 架起來，把每一句語音的落點收回自己手裡。語音隱私的底線原則很簡單，跟挑語音轉文字工具一樣，先問「音訊去了哪」再問「效果好不好」，本地處理的路線可以參考 parakeet-tdt-speech-to-text 那篇的評估方式。