為什麼語音訊息的逐字稿不等於一則訊息

說話時會冒出贅詞、重新起頭，還有講到一半的更正，寫好的文字大多沒有這些，所以語音訊息的逐字稿，還稱不上是一則訊息。手機會把你說的話打成字，Otter、WhatsApp 的逐字稿功能，以及建立在開放語音模型上的各種 App 也都做得到，但一段講得東拉西扯的語音訊息，轉成逐字稿之後，仍然是一則東拉西扯的訊息。「呃」還在，你講到一半改口的地方還在，你想到什麼就先說什麼的順序也還在。要把語音訊息變成一則清楚的訊息，App 在轉錄之後還得做第二件事：弄清楚你的意思，再把那個意思寫出來。

前半篇談研究。語言學家量過口語和書面語有什麼不同，語音辨識的研究者量過轉錄會在哪裡出錯、對誰特別容易出錯，也有幾項研究問過人們為什麼傳語音訊息，收的人又為什麼想拖著不聽。後半篇談大家手上現成的語音輸入工具做了什麼、多一道改寫能補上什麼，以及 Subtext 怎麼處理語音訊息。接近結尾處有一次實際執行，用的是一則虛構的、姊姊傳來的語音訊息，看 Subtext 從她說的話寫出什麼回覆。她的話是直接以文字送進去的，所以這次執行跳過了轉錄這一步。

我是 Subtext 的共同創辦人。在這款 App 裡，語音是三種輸入方式之一，另外兩種是打字寫的草稿，和對話截圖，所以我對這個問題的答案有利害關係。下面列的每一筆來源，我都實際打開看過。如果我只看得到摘要，我會直接說明，也不引用其中的任何數字。

口語和書面語，產生的方式不同

自發性口語裡，有大量書面語會略去的東西。Elizabeth Shriberg 彙整了幾個美式英語自發性口語語料庫裡的不流暢現象，算出的比率最高可占字詞的 10%，超過三分之一的話語裡也會出現¹。常見的形式有填充停頓（「uh」、「um」）、重複（「I I think」）、修正（句子講到一半把某個字換掉），以及重新起頭（說到一半放棄一個子句，再從頭開始，她把這類歸在「刪除」底下）。她檢視的兩個真人對話語料庫，一個是非正式的電話交談，一個是規劃旅行的電話，以字詞計算，不流暢現象約占 6%¹。這兩份樣本（分別為 40,515 和 12,762 個單字）是她在另一篇談同樣語料庫的 SRI 論文中，以人工標註的²。在另一個語料庫裡，人是按住「按住說話」的按鈕對電腦講話，比率降到不到 1%，她認為這個落差有一部分要歸因於那顆按鈕：說話的人可以先想好要說什麼，再錄下來¹。錄語音訊息時，你點一下就開口，整理思緒是邊說邊做的。

口語的贅詞，以及說話者之間的差異

口語裡的贅詞不是雜訊，這也是它們很難被剔除的原因之一。Herbert Clark 和 Jean Fox Tree 根據幾個大型語料庫主張，「uh」和「um」本身就是詞，跟其他詞一樣是事先計畫、再說出口的，用來告知對方接下來會有短暫或較長的延遲，因為說話的人正在找下一個詞，或正在決定要說什麼³。說話者之間的差異也非常大。London-Lund 語料庫收錄了 1961 年到 1976 年間錄下的 50 段英國人面對面對話，說話的人大多是學者，全部約 170,000 個單字。其中每人說了超過 1,000 個單字的 65 位說話者，每 1,000 個單字裡的贅詞，從 1.2 個到 88.5 個不等，中位數是 17.3 個³。有些逐字稿幾乎乾乾淨淨，有些大約每十二個單字就夾著一個贅詞。

不流暢現象也會集中在最需要思考的地方。Shriberg 引用更早的研究指出，它比較容易出現在一句話的前段¹。放進語音訊息，那就是開場，也就是你還在決定這則訊息要做什麼的時候。用寫的，這段開場可以在別人看到之前刪掉；語音訊息則多半會直接送出去，除非你整則重錄。

語音辨識的錯誤，因說話者而異

轉錄會在你說出口的瑕疵之上，再添上它自己的錯誤。我找到最清楚的量測，是 2020 年發表在《PNAS》的一項研究：研究者用五套商用語音辨識系統（來自 Amazon、Apple、Google、IBM 和 Microsoft），處理 42 位美國白人和 73 位美國黑人說話者共 19.8 小時的訪談錄音⁴。平均字詞錯誤率，白人說話者是 0.19，黑人說話者是 0.35，每一套系統都出現這個落差。表現最好的是 Microsoft，兩組分別是 0.15 和 0.27；最差的是 Apple，分別是 0.23 和 0.45。黑人說話者的錄音片段中，有超過 20% 的轉錄結果至少有一半的詞是錯的，白人說話者的片段則不到 2%⁴。作者把這個落差歸因於聲學模型（也就是把聲音對應到詞的那一部分），並指出訓練資料裡來自黑人說話者的音檔太少。

同一篇論文裡還有第二個模式，跟語音訊息有關：這些系統處理男性說話者時，表現稍差一些，作者把原因歸於男性的說話風格比較隨性，發音更短促、更弱化，不流暢現象也更多⁴，而這正是你傳給朋友的語音訊息常見的說話方式。

口音、第二語言，還有沒人說過的詞

語音辨識遇到有口音的說話者，或是用第二語言說話的人，表現也比較差。2024 年發表在《JASA Express Letters》的一篇論文，測試了 OpenAI 的 Whisper 模型處理各種英語口音的表現，報告指出：以英語為母語的說話者，準確度高於把英語當第二語言的人；美式英語的結果比英式或澳洲英語好；朗讀語音的結果比對話好⁵。我只看得到摘要，所以只引用趨勢方向，不引用數字。Whisper 的訓練資料有 680,000 小時的音檔，作者形容這些模型的「準確度與穩健性」接近人類⁶。它自己的說明文件則補了一句：「表現會因語言而差異很大」⁷。跨說話者的平均值，說明不了你累的時候用第二語言錄的那則語音訊息會是什麼狀況。如果那個語言是英語，一則沒有錯誤的訊息，在母語者讀來仍可能顯得唐突，而逐字稿不會告訴你這件事。

Whisper 還可能補上沒有人說過的詞。2024 年的一項研究，拿 437 位參與者的 13,140 段簡短英語錄音（在美國的機構錄製，參與者有人有失語症，有人沒有），在 2023 年 4 月和 5 月送進 OpenAI 雲端上的 Whisper API。轉錄結果中約有 1%，出現了音檔裡根本沒有的整個片語或整句話；這些憑空多出來的內容裡，有 38% 帶有至少一項明確的傷害性內容，例如暴力，或是謊稱自己具有某種權威。停頓很長的片段風險更高。在 Whisper 編造出文字的 187 段錄音上，Google、Amazon、Microsoft、AssemblyAI 和 RevAI 都沒有產生可比擬的編造內容。這些錄音是訪談，不是語音訊息，而且這項研究測試的是 2023 年時的 API⁸。

人們為什麼傳語音訊息

人們傳語音訊息，是因為對傳的人來說很快。我找到規模最大的研究來自 Ulm University：2020 年的一項調查，透過 Amazon Mechanical Turk 招募了 1,003 人，大多在美國，另外還對六位重度使用者做了為期兩週的實地研究⁹。調查中，83% 的人收過語音訊息，73% 的人傳過。傳送的理由，取自 735 則開放式回答（回答者都錄過語音訊息），歸納成四個主題。各主題的次數加起來比 735 多，因為有些回答同時屬於不只一個主題。「方便」被提到 359 次，理由是在手機上用說的比用打的快。聲音能傳達、文字卻會流失的語氣和情緒，229 次。打字不方便或不安全的情境，例如開車，203 次。最後是收訊息的人，他們要求用語音，或覺得語音比較容易，34 次。

有一項實驗室研究量了速度。48 位大學生（其中 24 位的母語是英語）在 iPhone 上照著抄短句，英語語音輸入是每分鐘 153 個單字，鍵盤是 52 個單字，速度是鍵盤的 2.93 倍；不過語音輸入留在最終文字裡、沒被改掉的錯誤稍多一點，是 0.55% 對 0.35%。這項任務是照抄固定的句子，和自己寫一則訊息是兩回事，所以能說明的不多。這是 2017 年發表的論文，其中兩位作者任職於 Baidu，而論文測試的 Baidu 伺服器端辨識系統 Deep Speech 2，是透過 iPhone 6 Plus 上的 App 執行的¹⁰。

語音訊息把費力的部分，從傳的人轉給收的人

在 Ulm 的實地研究中，兩週內記錄到 438 則語音訊息，長度從 1.5 秒到略多於七分鐘，中位數是 17.5 秒⁹。作者還指出，有一項代價，在任何收訊息的人聽到之前，就已經由傳的人付掉了。聲音稍縱即逝，所以錄音很難回頭檢查、修改，一次口誤，就得整則重錄⁹。他們實地研究中途放棄的十二段錄音裡，有五段就是這樣。

作者寫道，語音訊息會「把溝通所需的力氣轉向收訊息的人」⁹。錄的時候很快，但要把內容取回來，比讀一則內容相同的文字，要花更多時間和力氣；實地研究的參與者，大多在工作時把語音訊息先擱著，因為文字一眼就能掃過，錄音不行。他們在 2020 年提出的解法，是自動產生逐字稿，這樣藏在錄音裡的約會日期和地點，就能靠掃視找出來。

收的人為什麼會拖著不聽

收到語音訊息的人沒辦法像讀文字那樣一眼掃過去，所以只能回頭重聽。同一項實地研究裡，收到的語音訊息平均被播放 1.37 次，有一則被播放了 13 次⁹。讀文字就不需要重播。2019 年一篇納入 190 項研究、共 18,573 位參與者的統合分析，算出默讀英文非小說類文章的平均速度是每分鐘 238 個單字¹¹。在一個大型電話語料庫裡，對話的語速，若把整通電話算進去，約為每分鐘 196 個單字；若只算說話者自己開口的那幾輪，約為 164 個單字¹²。讀的人還能自己控制速度，直接跳到問題那裡；聽的人拿到的字詞，是照說話者的速度、說話者的順序來的。

大家對語音訊息不太熱衷，對收的態度比對傳的稍微好一點。YouGov 有一項民調，訪問了 2,149 位英國成年人，調查時間是 2022 年 5 月 5 日和 6 日，結果在同年 6 月發布。其中的智慧型手機使用者有 1,956 人，民調問了他們對語音訊息的看法。這些人當中，16% 喜歡傳語音訊息，36% 不喜歡。至於收語音訊息，22% 喜歡，25% 不喜歡，29% 說不上喜歡或不喜歡¹³。只有在 18 到 24 歲的人當中，喜歡收的人才比不喜歡的多，是 43% 對 28%；就算在這個年齡層，也有一半的人不喜歡傳，喜歡傳的是 30%。所有智慧型手機使用者裡，63% 從來沒傳過語音訊息。

語音訊息多長算太長？

在 2022 年 5 月 YouGov 對英國智慧型手機使用者所做的民調中，有作答的人裡，65% 認為一分鐘的語音訊息太長；在不喜歡收語音訊息而且有作答的人當中，57% 光是 30 秒就覺得煩躁。所有智慧型手機使用者裡，27% 不知道界線在哪裡。被問到比較想用什麼方式收一則很長的訊息時，78% 選文字，14% 選語音訊息；這記錄的只是他們說出來的偏好¹³。有些傳語音訊息的人，似乎知道錄音是在麻煩對方。2024 年一項分析德國和西班牙 WhatsApp 對話的研究，發現人們會在訊息之前、之中和之後，說明自己為什麼選擇用語音；作者形容這些說明在發揮社交上的作用，包括把語音訊息講成一件值得道歉的事¹⁴。把這幾項來源放在一起看，傳的人省了力氣，收的人付出代價，而有些傳的人還會為此道歉。

Apple 的聽寫怎麼處理語音訊息

語音輸入給你的，就是照你說話順序排好的字詞；以 Apple 的聽寫（Dictation）來說，工作到這裡就結束了。Apple 的 iPhone 使用手冊（iOS 27 版）說明，聽寫在手機上處理，不需要網路連線，支援多種語言，在該語言有支援的情況下，會自動插入逗號、句號和問號¹⁵。在最新的手機上，有一個裝置端模型能改善英文的拼字、標點和大小寫。其他一切都得靠口說指令：說「new line」換行，或說「delete」再接上要刪掉的那句話。「裝置端處理」這個說法是有條件的。Apple 的隱私權頁面說，如果「Keyboard Settings」（鍵盤設定）裡沒有顯示聽寫是在裝置上處理，你口述的內容就會送到 Apple 的伺服器，而且除非你選擇加入「Improve Siri and Dictation」（改善 Siri 與聽寫），否則不會被儲存。頁面也說，Apple 可能保留請求紀錄和逐字稿，最長兩年，這些資料連結的是隨機的裝置識別碼，而不是你的 Apple 帳號¹⁶。說不會被儲存，卻又說可能保留最長兩年，這兩種說法怎麼並存，頁面沒有說明。改寫是 Apple 另外那套書寫工具（Writing Tools）負責的事，而它不會判讀一段文字傳達得好不好。

Google 和 Microsoft 的語音輸入能做什麼

Google 的 Gboard 基本語音輸入，和 Apple 的聽寫一樣，是把你說的話照原樣給你。點一下麥克風，說出你想寫的內容，標點符號也要用說的，不過並不是每種語言都有語音輸入和標點功能¹⁷。它的進階語音輸入，在 Pixel 6 以後的機型上會隨著你說話加上標點；在 Pixel 9（不含 9a）以後的機型上，還能用口說指令，要它校對、換個說法、縮短或加長你剛口述的內容。Google 說這項功能在裝置上執行，支援英文、法文、義大利文、日文和西班牙文，德文即將推出¹⁸。在 Windows 上，Microsoft 的說明頁面寫道，Fluid dictation 是 Copilot+ PC 的功能，會在你說話的同時修正文法、標點和贅詞¹⁹。進階語音輸入只有在你下口說指令時才會改寫。Fluid dictation 不用下指令就會執行，但只限 Copilot+ PC，而且它的說明頁面沒有提到調整訊息的順序。在這裡引用的 Apple、Google 和 Microsoft 說明頁面上，我沒有找到任何一項功能，預設就能把一整段東拉西扯的語音訊息，變成一則可以傳的訊息。

轉錄 App 和通訊軟體怎麼處理

轉錄 App Otter 比手機鍵盤多做了一步。它的語音轉文字頁面描述的成果，是附有說話者標示和時間戳記的逐字稿、自動產生的摘要與重點，以及擷取出來的關鍵要點和待辦事項²⁰。Otter 的說明中心列出的支援語言是英文、西班牙文、法文、德文、日文和簡體中文²¹，比語音轉文字頁面所說的多。它是為開會設計的，所以做的是濃縮說過的內容，而我在這兩個頁面上，沒有找到任何一項功能，能替你擬出你原本想傳的訊息。有些 App 的底層用的是開放的語音模型。Whisper 本身產出的是逐字稿和語言標記⁷，建立在它上面的 App 各有不同。MacWhisper 宣稱，在逐字稿之上還能去除贅詞、做摘要、使用自訂提示詞，這個步驟可以選擇本機模型或雲端模型²²。

通訊軟體已經開始替你收到的語音訊息產生逐字稿。WhatsApp 在 2024 年 11 月加入語音訊息逐字稿功能，逐字稿在裝置上產生，所以 WhatsApp 自己看不到內容；使用者要在「設定」的「聊天」底下開啟，再長按那則訊息來觸發²³。貼文說，一開始只支援少數幾種語言，目前的清單我無法確認。只要那種語言有涵蓋，這就解決了 Ulm 作者指出的掃視問題。你拿到的，是別人邊想邊說的逐字稿。就算人在開會，你也能讀，但回覆還是得你自己寫。

多一道改寫能補上什麼

改寫這一步，是把逐字稿變成你在打字毫不費力時，本來會打出來的那則訊息。它會拿掉 Clark 和 Fox Tree 描述的贅詞，把 Shriberg 分類裡的重複和重新起頭合併掉，並且把你說到一半做的更正，放回它該在的位置，取代被更正的那段話。它也會調整順序。口頭的解釋，往往是照你想到的順序冒出來：先交代背景、最後才提出請求，或是先講請求、理由拖在後面。寫下來的訊息可以直接從重點開頭。

這一步有兩樣東西不能動。第一是意思。把你的語音訊息變成另一種請求的改寫，比逐字稿更糟，因為逐字稿至少說的是你說過的話。第二是語氣。你原本是溫暖、直率或在開玩笑，寫出來的版本也該是同一個人。這裡會出的毛病，就是〈AI 會讓你的訊息聽起來像機器人嗎〉談過的那一種：改寫後的訊息客客氣氣，卻千篇一律。

還有一種判斷，是逐字稿從來不需要做的。你在語音訊息裡說的話，有些是說給自己聽的，不是說給收訊息的人聽的。邊說邊想要不要提某件事，不代表你真的打算提。改寫這一步得判斷，哪些是訊息本身，哪些只是擬稿的過程，而這個判斷兩個方向都可能出錯：可能留下一句你正在說服自己別講的話，也可能刪掉一句你本來就想講的話。我沒有找到任何研究，量過任何工具（包括 Subtext）出現這種情況的頻率。

Subtext 怎麼處理語音訊息

Subtext 會先把你在 App 裡錄的語音轉錄成文字，再根據你想表達的意思寫出訊息，最多回傳三個版本，每個版本都附有一個「可放心傳送」分數，表示這則訊息照你的本意傳達出去的可能性有多高。這些版本的設計，是要保留你的意思和你的個性。第一次分析一份草稿時，其中一個版本貼近你的原話，只把問題修掉；一個是更溫暖的潤飾，或是換個切入方式；還有一個是幅度更大的改寫。如果措辭讀起來比你想要的更冷、更尖銳，App 會點出問題，並標出有問題的字句。它不會替你傳送任何東西。

模型的指示涵蓋了轉錄造成的瑕疵，寫這篇之前，我讀過後端的提示詞。當一則訊息被標記為口述的，模型會被告知要預期聽錯或黏在一起的字詞、怪異的標點和零星的贅詞，要越過這些瑕疵，抓出你原本想用的措辭，並默默修正，而不是把這些標示成你做錯了什麼。提示詞呈現的，是模型被要求怎麼做。針對 Subtext 的語音轉錄或改寫，我沒有找到任何獨立的評估，所以這一切都建立在 App 呈現的內容，以及它的提示詞和隱私權政策所說的話上。Deepgram 是替 Subtext 的音檔做轉錄的語音模型，上面這些研究都沒有測試過它，所以口音、第二語言說話和隨性說話風格的錯誤模式，有多少會套用在它身上，我說不準。因此，傳出去之前，請把訊息再讀一遍。

你錄的語音，在 Subtext 裡會發生什麼事？

Subtext 會把語音錄音傳給 Deepgram 轉錄，所以音檔會離開你的手機。它的隱私權政策（2026 年 10 月 10 日更新）列出了幾家供應商：語音錄音交給 Deepgram，文字、圖片和語音逐字稿交給 Anthropic，帳號和對話交給 Google Firebase，OpenAI 則只有在你開啟朗讀功能時才會用到。政策還提到，開啟網頁搜尋時，從你的請求中擷取的搜尋字詞，會經由 Anthropic 傳給第三方搜尋供應商，你可以在 App 的設定裡關掉網頁搜尋²⁴。政策表示，你提交的任何內容都不會用來訓練 AI 模型，它的 AI 供應商也都不得用這些內容訓練；針對語音，Subtext 還設定了 Deepgram 的模型改善退出選項。政策也表示，Subtext 會在你最後一次使用一則對話的五天後，從伺服器刪除自己那一份副本，如果你把對話釘選起來，則是 90 天。政策說，在設好那個退出選項的情況下，Deepgram 只在轉錄所需的時間內保留音檔；Anthropic 會在 30 天內刪除輸入和輸出內容，被標記的請求最多可能保留兩年，相關的安全分數最多可能保留七年。政策也說，Subtext 與這些供應商之間，沒有任何「零保留」的約定²⁴。其他助理怎麼處理你的文字，在〈哪些 AI 寫作助理會拿你的訊息來訓練〉裡有比較。

Subtext 支援哪些語言？

Subtext 會用你說話的語言寫出訊息，支援 17 種以上的語言，而且在那種語言會區分正式程度的情況下，會維持你用的正式程度。一則德語的語音訊息，回來的就是一則德語訊息。你收到的語音訊息，摘要會用它原本的語言寫成。Google Play 的編輯在一篇名為「Hot Tip」的專題中介紹了這個流程：點麥克風圖示、說話、再點一次，就會拿到一則修飾過的訊息，附有標籤說明原稿給人的觀感，還有一個複製按鈕²⁵。我在 2026 年 10 月 4 日打開頁面時，德國區的商店頁面顯示 4.3 顆星、295 則評論，下載次數超過 50,000 次，這只是 Google Play 的計數；星等會因國家而異。使用 Subtext 要付費，剛開始有幾次分析是免費的。錄下來的語音訊息，會變成一則可以傳出去的訊息。

對方傳來一段很長的語音訊息，該怎麼回？

Subtext 也會處理別人傳給你的語音訊息，這是單純的逐字稿最接近夠用的一面。WhatsApp 在裝置上產生的逐字稿，讓你可以用讀的看完一段兩分鐘的錄音，前提是你的語言有涵蓋²³。它做不到的，是告訴你對方想要什麼。Ulm 研究自己舉的例子，就是藏在音檔裡的一個日期和一個地點⁹。朋友或主管傳來的長語音訊息，也是同樣的結構：問題藏在中間，理由圍在四周。對回訊息容易卡住的人來說，讀訊息這一步，是回覆會卡住的五個地方之一，而 Ulm 實地研究的參與者，大多在工作時把語音訊息先擱著，因為錄音沒辦法一眼掃過⁹。

把對方傳來的語音訊息丟進 Subtext，它會轉錄成文字，用一句話總結對方想要你做什麼，再列出兩到五個待辦重點。接著它可以擬一則接得上對話的回覆，而且不會替對方的語氣貼標籤。後端的提示詞預設你附上的語音檔多半是對方傳給你的；如果模型不確定誰是誰，指示它要先問。摘要的品質，取決於底下的轉錄，而且一句話的摘要離開脈絡就很難讀懂，〈這則訊息是什麼意思〉就說明了這一點。遇到口音很重或雜音很多的錄音，轉錄的錯誤會比錄音室等級的清晰英語錄音多，所以只要事情重要，回覆之前先聽一遍原始錄音。文字和截圖也走同一個摘要步驟，所以你收到的訊息也會得到同樣的一句話摘要。

2026 年 10 月 13 日的一次執行，示範了回覆這一步。輸入的是一則虛構語音訊息的內容，以文字送進去，就像轉錄完成後把內容交給下一步那樣，所以這次執行完全看不出轉錄表現得如何。存下來的重播裡沒有那句摘要，只有回覆，所以摘要這一步，這裡示範不了。語音訊息是一位姊姊錄的，內容是：「欸，是我。那個，我剛跟爸講完電話，然後，說來話長啦，車子還在修車廠。他們現在說禮拜四，可能禮拜五。總之，不是，我不是為了這個打給你。媽生日是 19 號，我在想我們可以在她家吃午餐就好，不要出去吃，因為你知道她去餐廳會怎樣。蛋糕我來弄。禮物可以你來處理嗎？我是想說那條她喜歡的藍色圍巾，就市場買的那條，不過老實說，你覺得怎樣都可以。然後你可以禮拜三之前跟我講你會不會帶 Sam 來嗎？因為我要跟她說我們總共幾個人。好，就這樣。喔對，不要跟她講圍巾的事喔。掰掰。」

語音訊息底下輸入的要求是「跟她說圍巾我來買，還有 Sam 會來」。Subtext 先回了一句「好的，兩件事都有答案了，我幫你回得簡單清楚。」，然後寫了兩個版本，兩個都標為「可放心傳送」，沒有標出任何標籤。第一個版本標著「簡短直接」，感受詞是「輕鬆」，就是下面的重播一打開會看到的那一個，中間那句是「圍巾我來買，就買市場那條藍色的，我不會跟媽說」。第二個版本標著「稍微溫暖」，感受詞是「體貼」，開頭是「收到你的語音了。車子的事希望趕快修好。19 號在媽家吃午餐我覺得很好，也省得她在餐廳不自在。」，接著是「圍巾交給我，我去買那條藍色的，保證不會說溜嘴。Sam 會來，你跟媽說我們兩個。蛋糕就麻煩你囉。」。車子的事占了語音訊息開頭的一大段，第一版一個字都沒提，第二版用一句話帶過。輸入的那句要求沒有提到圍巾要保密，兩個版本卻都把這件事寫了進去，第一版標示背後的說明也寫著，它「也回應了不告訴媽媽的提醒」。Subtext 最後自己說明的是另一處：它把「我們兩個」寫進去，「是因為你說 Sam 會來」，接著問想要更短，還是更口語一點。以上是 App 實際回傳的內容，沒有經過修改。

最接近的實驗，年代久遠，規模也小

我找到最接近改寫或摘要這一步的兩項實驗，分別是 2003 年和 2005 年的，規模都很小。2003 年，一項由 DARPA 出資的實驗，讓 28 位母語為英語的人閱讀 150 到 250 個單字、內容為電話與廣播口語的段落，有原封不動的逐字稿，也有人工整理過的版本。讀者評分認為整理過的文字比較容易理解，但回答相關問題的正確率和速度沒有比較好，作者認為這是因為讀者的得分本來就已接近上限。對不完美的辨識結果做自動整理，評分上傾向於比沒整理的版本更難讀，不過差距很小²⁶。整理的做法是去掉不流暢的部分、修正標點，但沒有把文字改寫成一則訊息。

2005 年的實驗，16 個人根據自動擷取的摘要，回答 15 則語音留言的相關問題。從辨識出來的語音產生的摘要，答對來電者姓名的比例是 57%，從人工逐字稿產生的摘要則是 94%；來電原因則傳達得一樣好，都是 78%。當摘要來自辨識出的語音，人們要求聽原始音檔的次數更多，53% 對 30%²⁷。這些是用 2005 年的語音辨識技術，對語音留言做的擷取式摘要，所以這項研究只能提供一個預期。兩項研究都沒有量測過一則會被人傳出去的訊息。

證據到哪裡為止

證據扎實的部分在兩端。口語帶有書面語沒有的不流暢現象，而且比率量得出來；語音辨識對某些說話者犯的錯，比對其他人多，上面的數字可以佐證。中間的部分比較薄弱。我沒有找到任何研究，量過改寫過的語音訊息，傳達的效果比原始逐字稿好多少，也沒有研究量過改寫在過程中多常改變原意。關於語音訊息的研究只有寥寥幾項，其中規模最大的一項，調查樣本取自美國的群眾外包平台，外加一項只有六位參與者的實地研究。YouGov 的民調只涵蓋一個國家、一個年份。而且這些語音訊息研究，都早於裝置端逐字稿的出現，所以它們描述的那種力氣轉移，現在有一部分已經由通訊軟體自己補平了。

實際上，這取決於你說話的方式。如果你說話本來就是乾淨的完整句子，語音輸入就夠了，你的手機本來就有。如果你說話的方式，和那些語料庫裡的說話者一樣，帶著 Clark 和 Fox Tree 數過的贅詞、Shriberg 歸類過的重新起頭，那麼逐字稿交到對方手上的，就是你擬稿的過程，把它變成一則訊息的，是改寫這一步。Subtext 是做這一步的 App 之一，你錄的語音訊息和你收到的語音訊息都能處理；如果你的問題是一則回覆改個不停，〈為什麼一則簡短的回覆要花一小時〉談的就是那個循環。

資料來源

依首次出現的順序編號。頁面於 2026 年 10 月 4 日和 5 日查閱，Subtext 的隱私權政策則於 2026 年 10 月 10 日再次查閱。

1. Shriberg, E. (2001). To ‘errrr’ is human: ecology and acoustics of speech disfluencies. Journal of the International Phonetic Association, 31(1), 153-169. 美式英語對話的語料庫研究；不流暢現象的比率與類型。
2. Shriberg, E. Disfluencies in Switchboard. SRI International Speech Technology and Research Laboratory. 會議論文；PDF 沒有標示年份，其引用的參考文獻到 1996 年為止。人工標註的語料庫：Switchboard 為 30 位說話者的 40,515 個單字，AMEX（SRI 員工與旅行社人員之間的電話）為 523 位說話者的 12,762 個單字。由 DARPA 和 NSF 出資。2026 年 10 月 5 日查閱。
3. Clark, H. H., and Fox Tree, J. E. (2002). Using uh and um in spontaneous speaking. Cognition, 84(1), 73-111. 取自 London-Lund 語料庫的每位說話者贅詞率。
4. Koenecke, A., Nam, A., Lake, E., Nudell, J., Quartey, M., Mengesha, Z., Toups, C., Rickford, J. R., Jurafsky, D., and Goel, S. (2020). Racial disparities in automated speech recognition. Proceedings of the National Academy of Sciences, 117(14), 7684-7689. 五套商用系統，42 位白人說話者和 73 位黑人說話者，19.8 小時的音檔。
5. Graham, C., and Roll, N. (2024). Evaluating OpenAI’s Whisper ASR: Performance analysis across diverse accents and speaker traits. JASA Express Letters, 4(2), 025206. 僅讀到摘要；查閱時無法取得全文。
6. Radford, A., Kim, J. W., Xu, T., Brockman, G., McLeavey, C., and Sutskever, I. (2022). Robust Speech Recognition via Large-Scale Weak Supervision. arXiv preprint.
7. OpenAI. Whisper README. GitHub. 2026 年 10 月 4 日查閱。
8. Koenecke, A., Choi, A. S. G., Mei, K. X., Schellmann, H., and Sloane, M. (2024). Careless Whisper: Speech-to-Text Hallucination Harms. ACM Conference on Fairness, Accountability, and Transparency (FAccT ’24). 13,140 段音檔，來自 437 位在美國機構錄音的參與者（有失語症與沒有失語症者都有），於 2023 年 4 月和 5 月送進 Whisper API。由 Pulitzer Center 和 Cornell’s Center for Social Sciences 出資。
9. Haas, G., Gugenheimer, J., Rixen, J. O., Schaub, F., and Rukzio, E. (2020). “They Like to Hear My Voice”: Exploring Usage Behavior in Speech-Based Mobile Instant Messaging. MobileHCI 2020. 調查 1,003 人，另有一項為期兩週、6 位使用者的實地研究。
10. Ruan, S., Wobbrock, J. O., Liou, K., Ng, A., and Landay, J. A. (2017). Comparing Speech and Keyboard Text Entry for Short Messages in Two Languages on Touchscreen Phones. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies, 1(4), 159. 2017 年 12 月發表。實驗室研究，48 位大學生，每種語言 24 位，在 iPhone 上照抄短句。兩位作者任職於 Baidu USA，其伺服器端語音系統 Deep Speech 2 執行於 Baidu 的伺服器上，並透過 iPhone 6 Plus 上的 App 測試。
11. Brysbaert, M. (2019). How many words do we read per minute? A review and meta-analysis of reading rate. Journal of Memory and Language, 109, 104047. 190 項研究，18,573 位參與者。
12. Yuan, J., Liberman, M., and Cieri, C. (2006). Towards an integrated understanding of speaking rate in conversation. Interspeech 2006. Switchboard 電話對話。
13. YouGov. How many Britons like voice notes? 2022 年 6 月 14 日。調查 2,149 位英國成年人，訪問時間為 2022 年 5 月 5 日和 6 日，其中 1,956 位是智慧型手機使用者；長度相關的數字，是有作答者所占的比例。2026 年 10 月 4 日和 5 日查閱。百分比依 YouGov 的文章內文；結果表格中「不喜歡」的合計略有不同，原因是四捨五入。結果表格： 文章： https://yougov.com/en-gb/articles/42817-how-many-britons-voice-notes
14. Sampietro, A., and König, K. (2024). The medium is accountable: Metacommunication and media ideologies about voice messages in WhatsApp chats. Discourse & Communication, 18(1), 51-71. 德語和西班牙語的 WhatsApp 對話；摘要是透過出版社的 Crossref 紀錄讀到的，全文需付費。
15. Apple. Dictate text on iPhone. iPhone User Guide, iOS 27. 2026 年 10 月 4 日查閱。
16. Apple. Siri, Dictation & Privacy. Legal 頁面，最後更新於 2026 年 9 月 14 日。2026 年 10 月 5 日查閱。
17. Google. Type with your voice. Gboard Help. 2026 年 10 月 4 日查閱。
18. Google. Use advanced voice typing features. Gboard Help. 2026 年 10 月 5 日查閱。
19. Microsoft. Use voice typing to talk instead of type on your PC. Microsoft Support. 2026 年 10 月 5 日查閱。
20. Otter.ai. Convert Speech to Text. 2026 年 10 月 4 日查閱。
21. Otter.ai. Supported languages. Otter Help Center，文章編輯於 2026 年 5 月 6 日。2026 年 10 月 5 日查閱。
22. MacWhisper. Homepage. 行銷頁面，沒有標示日期，所以呈現的是產品宣傳的內容，不是實際表現。2026 年 10 月 5 日查閱。
23. WhatsApp. Introducing Voice Message Transcripts. 2024 年 11 月 21 日。2026 年 10 月 4 日查閱。
24. Subtext, Terms, privacy and your account. 隱私權政策最後更新於 2026 年 10 月 10 日。2026 年 10 月 10 日查閱。
25. Google Play. Hot Tip: Speak your mind with Subtext. 2026 年 10 月 4 日查閱；我打開的每個地區商店頁面都顯示 295 則評論和 50K+ 次下載，德國區的頁面顯示 4.3 顆星。
26. Jones, D. A. 與另外六位共同作者 (2003). Measuring the Readability of Automatic Speech-to-Text Transcripts. Eurospeech 2003, 1585-1588. 招募了 32 位母語為英語者，分析了 28 位。由 DARPA 贊助，空軍合約編號 F19628-00-C-0002。
27. Koumpis, K., and Renals, S. (2005). Automatic summarization of voicemail messages using lexical and prosodic features. ACM Transactions on Speech and Language Processing, 2(1). 理解測驗，16 位參與者、15 則語音留言；數字取自作者自行託管的 PDF。由 EPSRC ROPA 獎助出資，編號 GR/R23954。