VoiceScroll 會把我的聲音傳到伺服器嗎？實際情況是這樣

任何一款在你說話時持續監聽的應用程式，都值得問一個問題：那段音訊到底去了哪裡？提詞器和短暫的語音指令不一樣，麥克風在整個錄製過程中都是開著的，所以這個答案更重要。

簡短的答案

在 iPhone 和 iPad 上，VoiceScroll 的語音辨識從不離開你的裝置，不是偶爾離開，也不是作為備援離開：應用程式強制要求裝置端處理，程式碼裡根本沒有把音訊送到伺服器的路徑。在 Android 上，VoiceScroll 同樣不會選擇伺服器端的辨識引擎。如果你的裝置只能靠把音訊送出去才能辨識所選語言，應用程式會告訴你這台裝置無法使用該語言，而不是悄悄那樣做。

「裝置端」到底是什麼意思

語音辨識可以用兩種方式運作。雲端辨識把你的音訊串流傳輸到伺服器，由伺服器完成轉錄再把文字傳回來。裝置端辨識把模型直接跑在本機，你的聲音不需要離開手機就能被理解。代價通常是準確度和語言涵蓋範圍，雲端模型往往更大，但對於本來就在讀你自己寫的稿子的提詞器來說，裝置端辨識的準確度通常已經夠用，而且不依賴拍攝現場的網路狀況。

iPhone、iPad:只用裝置端，沒有例外

在 iOS 上，VoiceScroll 的語音辨識請求被設定為必須使用裝置端處理。這不是一個「偏好設定」，不會因為網路恰好可用就被應用程式悄悄繞過，而是寫死在請求本身裡的硬性要求。如果某種語言在你的裝置上沒有對應的裝置端模型，應用程式會提示你需要下載，而不是悄悄切換到伺服器。這一點在 VoiceScroll 的兩套辨識引擎上都成立:經典引擎，以及 iOS 26 引入的新引擎。

Android:只用裝置端，以及一個需要說明的限度

Android 的語音 API 和 iOS 的運作方式不同。Android 確實有一個嚴格只在裝置端執行的辨識 API，但把 VoiceScroll 收窄到只用它，就會失去某些裝置上實際能辨識的離線路徑。所以應用程式保留更寬的辨識服務集合，同時拒絕一切不是離線的東西。只能連網運作的提供方會被完全排除在候選清單之外，首次選擇和工作階段中途的容錯鏈上都一樣，而且每一次請求都被釘死為優先離線。如果某個語言在你的手機上只能遠端提供，應用程式會攔下開始，並開啟說明原因的語音設定面板，而不是切到伺服器讓它跑起來。

過去的版本在這裡確實有一個值得坦白說明的漏洞。當時的應用程式只是優先裝置端，並沒有拒絕遠端路徑:當排在最前面的離線辨識引擎在工作階段中途掛掉時，可能是啟動逾時、無轉寫的監看程式，或者不支援該語言的錯誤，容錯鏈有可能落到連網的提供方上，把請求以關閉離線旗標的方式重建，然後在螢幕上不作任何提示的情況下，把這一段的剩餘部分交給 Google 的語音服務。這個問題已在 1.10.1 版本中修復。現在應用程式挑選辨識引擎的每一處都會排除連網的提供方，容錯鏈已經無處可落。

還有一個需要挑明的限度:因為 VoiceScroll 用的是那個更寬的集合，而不是只用嚴格的那一個 API，所以它釘在每次請求上的離線優先，只是那些辨識服務可以忽略的提示，而不是平台層面的保證。排除連網提供方並釘死這個旗標，是應用程式在 Android 上能握住的最強槓桿。這是應用程式層面的保證，而不是 iOS 那種可以下斷言的承諾。

稿子本身呢

除了音訊之外，你的稿子文字同樣不會被收集或上傳。稿子保存在裝置本機，VoiceScroll 使用時也不需要帳號，所以根本不存在一個能把你的稿子關聯起來的伺服器端帳戶。如果你錄製影片，情況也一樣:影片和音訊只會寫入裝置上的檔案，不會被傳輸到任何地方。

不只是 VoiceScroll，任何應用程式你都可以這樣檢查

這不是提詞器專屬的問題，對任何經常監聽你的應用程式，都值得檢查一下:

• 在隱私權政策或應用程式介紹裡找「裝置端」這類具體表述。只說「我們非常重視你的隱私」而沒有任何技術性說明，通常沒有實際意義。
• 試試斷網後應用程式還能不能用。如果能，這就是辨識確實在本機進行的一個有力訊號。
• 看應用程式在無法本機辨識時做什麼。拒絕該語言並說明，或者在備援時告知你，這兩種都站得住腳。不告訴你就切到伺服器，才是不行的。

結論

在 iPhone 和 iPad 上，你的聲音不會離開裝置，沒有例外。在 Android 上，VoiceScroll 同樣不會選擇伺服器端的辨識引擎，並且會拒絕你的裝置只能遠端處理的語言，不過在 Android 上這是應用程式層面的保證，而不是平台層面的。無論哪種情況，你的稿子都不會被收集，也沒有帳號把這一切和你關聯起來。