聲聲慢 SpeakSlow：中文本地語音輸入的隱私邊界與 AI 對話工作流
Voice Input / Privacy / Local AI Tool
聲聲慢 SpeakSlow：中文本地語音輸入的價值，不只是「更快打字」
這則 Threads 把兩件事放在一起看：一是對 Typeless 的資安疑慮，二是轉向開源、本地、中文優化的聲聲慢 SpeakSlow。可核對的官方資訊顯示，SpeakSlow 是 Windows 工具，使用 sherpa-onnx 本地語音辨識，主打 100% local、不上雲、按右 Alt / 右 Ctrl 錄音後直接貼到游標處，特別適合用語音和 AI 對話。
保守解讀：Threads 對 Typeless 的逆向工程指控應視為社群風險訊號，除非另有原始技術報告，不宜直接當成已定案事實；但它提醒了一個更穩的選型原則：語音輸入工具會接觸麥克風、鍵盤、剪貼簿、瀏覽器文字與歷史資料，隱私邊界必須先審，再談效率。
原貼文的核心訊號
作者提到 Typeless 被日本工程師逆向後揭露可能把語音送 AWS、蒐集網址與螢幕文字、本機明文保存紀錄，甚至具備鍵盤側錄能力；因此改用「聲聲慢 SpeakSlow」。
官方可驗證的 SpeakSlow 特性
GitHub README 標示：免費開源、Windows、Apache 2.0、本地 sherpa-onnx Paraformer、100% local、聲音不上傳伺服器，支援自動標點、去口吃贅字、熱詞/自訂字典、歷史與錄音保存。
真正適合的使用場景
不是單純取代輸入法，而是把「口述 → 文字 → 貼到 AI 對話框」變成快速工作流。對長提示、需求描述、會議後整理、和 AI pair working 都有價值。
| 評估面向 | Typeless 風險訊號 | SpeakSlow 對應特性 | 採用前檢查 |
|---|---|---|---|
| 語音資料 | 貼文稱語音 100% 送 AWS。 | 官方主張語音辨識完全在本機運行，聲音不上傳伺服器。 | 確認是否真的離線可用、網路斷線時能否辨識。 |
| 螢幕/網址資料 | 貼文稱會蒐集瀏覽網址與螢幕文字。 | SpeakSlow 主軸是全域熱鍵錄音並貼到游標處，不以讀取瀏覽內容為核心賣點。 | 檢查權限、原始碼、執行程序、網路連線行為。 |
| 本機紀錄 | 貼文稱本機明文保存所有紀錄。 | SpeakSlow 官方也有歷史、錄音保存、重新辨識功能。 | 本地保存不是問題本身，重點是是否可關閉、加密、清除與匯出。 |
| 鍵盤/剪貼簿 | 貼文稱技術上有鍵盤側錄能力。 | SpeakSlow 使用全域熱鍵與貼到游標處，並稱貼上後會還原原剪貼簿。 | 任何全域熱鍵工具都要評估最小權限與開源可信度。 |
產品細節：SpeakSlow 最新 v1.0.9 加入麥克風選擇與 AGC 開關，解決「收錯麥克風 → 噪音被增益 → 辨識亂跳/幻聽」這類實務問題；也修正切換 AI 供應商時 API key 留存造成的設定混亂。
對 AI 工作者的價值
輸入瓶頸從鍵盤變成口述，長 prompt、情境補充、需求規格、debug 描述都能更快丟給 AI。這比一般語音輸入更貼近「和 AI 對話」的工作型態。
對中文使用者的價值
官方特別標示中文/台灣優化：繁體標準字、中英混用保留英文、自動標點、規則式列點、停頓斷行，這些都是中文語音輸入的痛點。
仍要注意的界線
SpeakSlow 的本地歷史與錄音保存對重辨識有幫助，但若處理客戶資料、公司機密或醫療/財務內容，仍應先確認儲存位置、清除機制與備份範圍。
採用語音輸入工具前的 6 個檢查
- 是否能在斷網狀態下完成語音辨識？
- 是否會把音訊、螢幕文字、網址、剪貼簿內容送到第三方？
- 本機歷史與錄音存在哪裡？是否能刪除或關閉？
- 全域熱鍵、鍵盤監聽、剪貼簿存取是否符合最小權限？
- 是否開源？最近 release 是否活躍？
- 若接 AI 潤飾，API key、供應商與本地 LLM 選項是否清楚隔離？