Wispr Flow 語音輸入 — 用說的寫字,比打字快三倍
Wispr Flow 的實測輸入速度約為每分鐘 220 字（英文），而一般人打字約每分鐘 40-60 字——差距接近四倍，這是它與傳統語音輸入最大的分野。真正的差異不在辨識準確率，而在於它會即時清掉「呃」「那個」這類贅詞、自動補標點、並依照你當下所在的應用程式（Slack、Gmail、VS Code）調整語氣與格式。換
Wispr Flow 的實測輸入速度約為每分鐘 220 字（英文），而一般人打字約每分鐘 40-60 字——差距接近四倍，這是它與傳統語音輸入最大的分野。真正的差異不在辨識準確率，而在於它會即時清掉「呃」「那個」這類贅詞、自動補標點、並依照你當下所在的應用程式（Slack、Gmail、VS Code）調整語氣與格式。換句話說，你講出來的是口語，落到游標上的是可以直接送出的書面文字。 語音輸入為什麼直到 2024 年後才真正可用 語音轉文字的技術門檻在 2022 年 OpenAI 開源 Whisper 後被大幅拉低。Whisper 以 「68 萬小時多語言與多任務監督資料訓練，涵蓋 96 種語言」（來源：OpenAI） 為基礎，讓英文以外的語言辨識錯誤率首次落到實用區間。在此之前，主流聽寫工具在非母語腔調、專有名詞、中英夾雜的情境下錯誤率高到不值得使用。 但單純的「聲音轉文字」不等於「可用的輸入法」。真正的瓶頸是三件事： 贅詞與重述 ：人講話會停頓、會改口、會說「我的意思是」。逐字轉寫出來的文字沒人想讀。 標點與斷句 ：口語沒有逗號句號，需要模型從語意推斷。 情境格式 ：對同事講的話丟進 Slack 是一回事，丟進正式 email 又是另一回事。 Wispr Flow 的產品定位就是處理這三層。它在轉寫之後多加一層 LLM 潤稿，把口語直接整成可送出的文字，而不是留一堆逐字稿讓你手動修。 實際輸入速度：220 wpm 對比 40 wpm 官方公布的輸入速度是每分鐘 220 字，約為平均打字速度的四倍。 「Wispr Flow 使用者平均輸入速度達 220 wpm，較鍵盤輸入快約 4 倍」（來源：Wispr Flow 官方網站） 。這個數字需要放進脈絡理解：220 wpm 指的是「說話速度」，而非「產出定稿速度」。實務上你仍需要 10-20% 的時間校對與微調，所以真實的端到端增益大約落在 2.5-3 倍。 對照組的打字速度有公開研究支撐。 「16.8 萬名受試者的實體鍵盤打字研究顯示，平均速度為每分鐘 52 字」（來源：Aalto University 人機互動研究） 。手機觸控鍵盤更慢，同團隊的另一份研究測得約每分鐘 36 字。也就是說，在手機上使用語音輸入的相對增益比在桌機上更大。 資金面也反映市場對這個方向的認可。 「Wispr 於 2025 年 6 月完成 3,000 萬美元 A 輪募資，累計募得約 5,600 萬美元」（來源：TechCrunch） 。這輪資金主要投向行動端與更多語言支援。 它跟 macOS 內建聽寫、Whisper 有什麼不同 三者處在不同的抽象層級，直接比較會失焦。以下是實務上的分工： macOS / Windows 內建聽寫 內建聽寫做的是逐字轉寫，不做潤稿。你說「呃那個我覺得這個提案應該可以」，它就照樣打出「呃那個我覺得這個提案應該可以」。標點需要你唸出「逗號」「句號」。優點是免費、離線可用、零延遲成本；缺點是產出仍需大量手動修整。適合短句、指令式輸入。 Whisper 及其衍生工具 Whisper 是模型不是產品。你可以用 whisper.cpp 在本機跑，或用 API 呼叫，但需要自己處理錄音觸發、游標插入、應用程式偵測。開源社群有 MacWhisper、Superwhisper 等封裝產品，功能與 Wispr Flow 重疊度高。這條路的優勢是資料留在本機、成本可控；代價是設定門檻與後處理品質需要自己調。 Wispr Flow Wispr Flow 賣的是整條流程：按住快捷鍵、說話、放開、文字直接落在游標處，且已經潤過稿。它會偵測前景應用程式來調整輸出風格，也支援自訂字典（人名、公司名、專案代號、技術術語）。多語言方面官方宣稱支援 100+ 種語言且可自動偵測，中英混講的情境不需要手動切換。 中文使用者的實際體驗與限制 中文語音輸入的準確率明顯低於英文，這是所有工具的共同狀況，不是 Wispr Flow 獨有。主要原因有三：中文同音字多（「以後」「一後」「已候」）、缺乏詞界、專有名詞常是自創組合。Whisper 系列模型在繁體中文上還有一個特定問題：訓練資料中簡體遠多於繁體，容易輸出簡體字或簡繁混雜，需要後處理轉換。 中英夾雜是台灣使用者的高頻情境，也是最能看出工具差異的地方。「這個 API 的 rate limit 要調高」這種句子，內建聽寫常會把英文詞硬轉成中文音譯。Wispr Flow 因為有 LLM 潤稿層，處理這類混語句子的成功率較高，但仍不是 100%。實務建議是把常用的技術詞、產品名、同事姓名全部加進自訂字典，這對準確率的提升比任何其他設定都明顯。 另一個限制是延遲。因為要走雲端 LLM 潤稿，從放開快捷鍵到文字出現通常有 0.5-2 秒的等待，段落越長越久。如果你的工作流是
FAQ
語音輸入為什麼直到 2024 年後才真正可用
語音轉文字的技術門檻在 2022 年 OpenAI 開源 Whisper 後被大幅拉低。Whisper 以 「68 萬小時多語言與多任務監督資料訓練，涵蓋 96 種語言」（來源：OpenAI） 為基礎，讓英文以外的語言辨識錯誤率首次落到實用區間。在此之前，主流聽寫工具在非母語腔調、專有名詞、中英夾雜的情境下錯誤率高到不值得使用。 但單純的「聲音轉文字」不等於「可用的輸入法」。真正的瓶頸是三件事： 贅詞與重述 ：人講話會停頓、會改口、會說「我的意思是」。逐字轉寫出來的文字沒人想讀。 標點與斷句 ：口語沒有逗號句號，需要模型從語意推斷。 情境格式 ：對同事講的話丟進 Slack 是一回事，丟進正式 email 又是另一回事。 Wispr Flow 的產品定位就是處理這三層。它在轉寫之後多加一層 LLM 潤稿，把口語直接整成可送出的文字，而不是留一堆逐字稿讓你手動修。
它跟 macOS 內建聽寫、Whisper 有什麼不同
三者處在不同的抽象層級，直接比較會失焦。以下是實務上的分工： macOS / Windows 內建聽寫 內建聽寫做的是逐字轉寫，不做潤稿。你說「呃那個我覺得這個提案應該可以」，它就照樣打出「呃那個我覺得這個提案應該可以」。標點需要你唸出「逗號」「句號」。優點是免費、離線可用、零延遲成本；缺點是產出仍需大量手動修整。適合短句、指令式輸入。 Whisper 及其衍生工具 Whisper 是模型不是產品。你可以用 whisper.cpp 在本機跑，或用 API 呼叫，但需要自己處理錄音觸發、游標插入、應用程式偵測。開源社群有 MacWhisper、Superwhisper 等封裝產品，功能與 Wispr Flow 重疊度高。這條路的優勢是資料留在本機、成本可控；代價是設定門檻與後處理品質需要自己調。 Wispr Flow Wispr Flow 賣的是整條流程：按住快捷鍵、說話、放開、文字直接落在游標處，且已經潤過稿。它會偵測前景應用程式來調整輸出風格，也支援自訂字典（人名、公司名、專案代號、技術術語）。多語言方面官方宣稱支援 100+ 種語言且可自動偵測，中英混講的情境不需要手動切換。
什麼工作適合用語音輸入，什麼不適合
語音輸入的增益不是均勻分布的，取決於「你腦中的內容有多完整」。適合的情境有共同特徵：內容已經想好，只差把它輸出。 回覆 email 與訊息 ：內容明確、篇幅中等、格式要求低。增益最大。 會議紀錄與想法速記 ：需要快速捕捉，之後才整理。 寫初稿 ：部落格、報告的第一版。講出來再改，比對著空白畫面打字快得多。 給 AI 的 prompt ：prompt 通常長、口語化、不需要精確格式，是語音輸入的理想對象。 不適合的情境同樣有清楚特徵： 寫程式 ：符號密度高、縮排有語意、變數命名需要精確。念 const handleSubmit = async (e) => { 遠比打出來慢。 需要邊想邊寫的內容 ：複雜論證、數學推導。打字的節奏本身就是思考節奏，語音會逼你在想清楚之前先講出來。 開放式辦公空間 ：這是實務上最常見的採用障礙。你不會想在會議室外對著筆電講三分鐘。 大量數字與代號 ：訂單編號、身分證字號、SKU 這類內容的錯誤成本高，逐字檢查的時間會吃掉所有節省。
由 FeiYueh 親自審稿驗證 · 最後更新於 2026-09-23. Independently maintained — not AI-generated boilerplate.
← Back to Blog