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 上这是应用层面的保证，而不是平台层面的。无论哪种情况，你的稿子都不会被收集，也没有账号把这一切和你关联起来。