Jarvis：先在 NUC 把語音變成文字，再交給模型思考

起點：想法已經有了，手還在打字

使用 AI 時，我常常已經知道想問什麼，卻還得停下來，把腦中的想法打成一段指令。Jarvis 從這個小小的阻力開始：如果可以直接說話，讓桌上的 NUC 先把中文轉成文字，再交給模型處理，工作會不會更順？

我想做的是一個平常真的願意叫出來用的語音入口。先把話聽清楚，再把文字交給合適的模型，最後把結果帶回桌面。語音是否比打字省時，還要把辨識錯誤、修改與等待一起算進去。

決策：把「聽懂」和「思考」分開安排

我的出發點是讓語音轉文字在地端硬體執行。後面的思考則保留選擇：能在本機完成的任務交給 Ollama，需要雲端能力時再使用 Claude。我想測的是這樣的分工能不能融入日常工作，而不是先假設所有工作都要搬到同一種模型。

地端辨識也不等於整段對話都留在本機。選擇雲端模型時，轉出的文字與需要的上下文會送往雲端；目前的 edge-tts 語音回覆也需要網路。哪些內容送去哪裡，應該是使用者看得懂、能選擇的設定。

實作：一段話，走過三個步驟

目前的 Python／Electron 原型已接起語音辨識、模型回覆與桌面介面。第一步，以 Breeze／faster-whisper 在地端把語音轉成文字；第二步，將文字交給所選的 Ollama 地端模型或 Claude；第三步，在 HUD 顯示處理狀態與回覆，並串接語音輸出。模型切換已有實作，自動判斷哪個模型最適合任務則仍是後續研究。

我負責使用情境、功能優先序與驗收方向，和 AI 開發工具一起完成原型，再依實際使用調整。介面回饋很重要：我需要知道它正在聽、正在想，還是需要我介入，而不是說完一句話後只能等待。

接下來：量出從開口到可用指令的差別

這個專案目前是私人原型，還沒有公開操作示範。程式已具備地端語音轉文字與地端／雲端模型接續的流程；端到端穩定度、延遲，以及是否真的比打字省時，仍需要同一套條件下的實機比較。封面是使用情境示意，不是運作畫面。

下一輪我想用同一批中文任務，比較打字與語音兩種輸入：從開始輸入到得到可用指令花多久、需要改幾次、模型多久回應。記錄 NUC 配置、模型版本與收音條件，才能說清楚這個語音入口適合什麼工作，又在哪些情況下還不夠好。