
文章写作工具
语音备忘的转写文本,为什么还不是一条消息
单纯的语音转文字能把语音备忘变成文字,但往往会把口头填充词、重新起头的半句话,以及你想到哪说到哪的顺序一并留下。下面先看研究怎么说,再看改写这一步能补上什么。
作者 Samet Durgun · Subtext 联合创始人 · 阅读约需20分钟
· 更新于2026年10月31日
口语里会有“嗯”“呃”这类填充词,有起了头又放弃的半句话,也有说到一半的改口,而写好的文字大多没有这些。所以一段语音备忘的转写文本,还算不上一条消息。手机能把你说的话打成字,Otter、WhatsApp 的转写文本和基于开源语音模型做出来的各种应用也能,但一段东拉西扯的语音备忘,转出来仍是一条东拉西扯的消息。那声“呃”、说到一半的更正、你碰巧想到事情的先后顺序,它都原样保留。想把一段语音备忘变成一条清楚的文字消息,应用在转写之后还得做第二件事:弄明白你想说什么,再把它写出来。
前半部分讲研究。语言学家测量过口语和书面语有什么不同,语音识别研究者测量过转写在哪里出错、对谁出错,还有几项研究问过人们:为什么发语音消息,收的人又为什么拖着不听。后半部分讲大家手机里本来就有的语音转文字工具能做什么,改写这一步又多做了什么,以及 Subtext 怎么处理一段语音备忘。文章靠后有一次真实运行,用的是一段编出来的、姐姐发来的语音备忘,看的是 Subtext 根据它写出的回复。她的话是直接以文字输入的,所以这次运行跳过了转写这一步。
我是 Subtext 的联合创始人。在这款应用里,语音是三种输入方式之一,另外两种是打字写的草稿和对话截图,所以在这个问题上,我的立场并不中立。下面的每一条来源,我都亲自打开读过。只读到摘要的,我会写明,也不引用其中的任何数字。
口语和写作的产生方式不同
自发的口语里,有大量写作会省掉的东西。Elizabeth Shriberg 综述了几个美国英语自发口语语料库里的不流畅现象,给出的比率,按词数算最高可达10%,按话语算则超过三分之一1。具体形式有:填充停顿(“uh”、“um”)、重复(“I I think”)、修正(说到一半把某个词换掉),还有重新起头,她把它归在“删除”一类,指一个分句被放弃,然后重新开始。她考察了两个真人对话的语料库,一个是非正式的电话交谈,一个是旅行规划电话,按词数算,比率约为6%1。这个比率所依据的样本,是她在 SRI 另一篇论文中对同样的语料库做过人工标注的部分,分别有40,515个词和12,762个词2。在另一个语料库里,人们是按住“按键说话”按钮对着电脑说话,比率降到了1%以下,她认为下降有一部分要归因于那个按钮:说话的人可以先把话想好,再录下来1。录语音备忘时,你点一下就开口,边说边想,全都出了声。
口头填充词,以及说话人之间的巨大差异
口头填充词并不是噪音,这也是它们不好去掉的原因之一。Herbert Clark 和 Jean Fox Tree 根据几个大型语料库提出,“uh”和“um”本身就是词,和别的词一样,是有计划地说出来的。它们用来告诉听的人:接下来会停一小会儿,或者停一大会儿,因为说话的人正在找下一个词,或者正在决定说什么3。不同的人用起来也相差极大。London-Lund 语料库收录了1961年到1976年间录下的50段英国人面对面交谈,大多发生在学者之间,共约17万个词。在说出1,000个词以上的65位说话人中,每1,000个词里的填充词数量最少1.2个,最多88.5个,中位数是17.3个3。有的转写文本几乎干干净净,有的每隔十来个词就有一个填充词。
不流畅现象还会扎堆出现在最费心组织语言的地方。Shriberg 引用此前的研究指出,它更容易出现在一个短语的开头1。放到语音备忘里,这个位置就是开场白,你还在决定这条消息到底是为了什么。写字的时候,你可以在别人看到之前把这段开头删掉。语音备忘则不行,除非把整条消息重录一遍,否则它通常会原样发出去。
语音识别的错误,因说话人而异
转写还会在你自己说出口的那些失误之上,再添上它自己的错误。我找到的最清晰的测量,来自2020年发表在 PNAS 上的一项研究:研究者用 Amazon、Apple、Google、IBM 和 Microsoft 的五套商用语音识别系统,转写了19.8小时的访谈录音,说话人是42位白人和73位黑人美国人4。平均词错误率,白人说话人是0.19,黑人说话人是0.35,每一套系统都出现了这个差距。表现最好的 Microsoft,两组分别是0.15和0.27;表现最差的 Apple,是0.23和0.45。黑人说话人的音频片段里,超过20%的转写结果至少有一半的词是错的,白人说话人的片段里这一比例不到2%4。作者把这个差距追溯到声学模型,也就是把声音对应到词的那一部分,并指出训练数据里黑人说话人的音频太少。
同一篇论文里的另一个规律,对语音备忘也有意义。这些系统对男性说话人的表现略差一些,作者把原因归结为男性的说话风格更随意,发音更短、更弱化,不流畅现象也更多4。发给朋友的语音消息,用的正是这种说话方式。
口音、第二语言,以及没人说过的词
语音识别在口音和第二语言的语音上,表现也更差。2024年发表在 JASA Express Letters 上的一篇论文,测试了 OpenAI 的 Whisper 模型在各种英语口音上的表现,报告说:对母语者的准确率高于对以英语为第二语言的说话人,对美式英语的结果好于英式和澳大利亚英语,对朗读语音的结果好于对话5。我只读到了摘要,所以这里只引用结论的方向,不引用数字。Whisper 用68万小时的音频训练而成,它的作者称,这些模型的“准确度和稳健性”接近人类水平6。它自己的文档又补充说,“表现因语言而差别很大”7。对所有说话人取平均值,说明不了多少你那条用第二语言、带着倦意录下的语音会出什么状况。如果那门语言是英语,一条没有错误的消息,在母语读者看来仍可能显得突兀,而转写文本不会告诉你这一点。
Whisper 还可能凭空添上没人说过的词。2024年的一项研究,把13,140段简短的英语音频,在2023年4月和5月送进了 OpenAI 托管的 Whisper API。这些音频来自437名参与者,在美国的机构录制,参与者中有失语症患者,也有没有失语症的人。约1%的转写结果里,出现了音频中根本没有的整个短语或整句话,其中38%至少带有一种明确的危害,比如暴力内容,或者冒用权威名义的虚假说法。含有长时间停顿的片段风险更高。在 Whisper 编造出文字的187段音频中,Google、Amazon、Microsoft、AssemblyAI 和 RevAI 都没有产生类似的编造内容。这些音频是访谈,不是语音消息,而且这项研究测试的是2023年时的 API8。
人们为什么发语音消息
人们发语音消息,是因为对发的人来说快。我找到的规模最大的研究来自乌尔姆大学(Ulm University):2020年的一项调查,在 Amazon Mechanical Turk 上招募了1,003人,大多在美国;另有一项为期两周的实地研究,对象是六位重度用户9。调查中,83%的人收到过语音消息,73%的人发过。发语音的原因取自735条开放式回答,答题的都是录过语音消息的人,这些原因归为四个主题。各主题的次数加起来超过735,因为有些回答同时归入了不止一个主题。方便,也就是在手机上说话比打字快,被提到359次;声音能传达、文字却会丢掉的语气和情绪,229次;打字不方便或不安全的场合,比如开车,203次;还有接收方,也就是对方要求用语音,或者觉得语音更容易,34次。
速度方面,有一项实验室研究做过测量。共有48名大学生参加,其中24人是英语母语者。参与者都在 iPhone 上抄录简短的短语。英语语音输入的速度是每分钟153个词,键盘输入是52个词,语音是键盘的2.93倍,不过语音输入留在最终文本里、没有改正的错误略多一些,是0.55%,键盘是0.35%。任务是抄录给定的短语,这对写一条消息说明不了多少。论文发表于2017年,两位作者在百度工作,百度的服务器端识别系统 Deep Speech 2,是用一个 iPhone 6 Plus 上的应用测试的10。
语音消息让发的人省力,收的人费力
在乌尔姆的实地研究中,两周里记录下438条语音消息,最短1.5秒,最长刚过七分钟,中位数是17.5秒9。作者还指出,在任何收件人听到之前,就已经有一笔成本付出了。声音转瞬即逝,所以录好的语音很难回看、很难修改,一旦口误,就得把整条消息重录9。在他们的实地研究里,十二次中途放弃的录音中,有五次正是这个原因。
作者写道,语音消息“把沟通所需的精力转移到了接收方身上”9。录起来快,但从录音里把内容取出来,比读一条内容相同的文字消息更费时间、更费力;他们实地研究的参与者里,大多数人在工作时会把语音消息先放一放,因为文字一眼就能看完,录音不行。他们在2020年提出的补救办法,是自动生成转写文本,这样埋在录音里的约见日期和地点,扫一眼就能找到。
收到的人为什么拖着不听
收的人没法扫读,所以要回头再听一遍。还是那项实地研究,人们对收到的一条语音消息平均播放1.37次,有一条被播放了13次9。读文字不需要重放。2019年一项元分析汇总了190项研究、18,573名参与者,得出默读英语非虚构类文本的平均速度是每分钟238个词11。在一个大型电话语料库里,对话的语速按整通电话算,约为每分钟196个词;只算说话人自己发言的那几段,约为每分钟164个词12。读的人还能自己掌握节奏,直接跳到问题那里。听的人拿到这些词,速度由说话人定,顺序也由说话人定。
人们对语音消息不太热衷,对收比对发略微热衷一点。YouGov 对2,149名英国成年人做了一项民调,调查在2022年5月5日和6日进行,同年6月发布;其中使用智能手机的1,956人,被问到了语音消息。这些人里,16%喜欢发语音,36%不喜欢发。至于收语音,22%喜欢,25%不喜欢,29%持中立态度13。只有18到24岁的人里,喜欢收语音的多于不喜欢的,是43%对28%;即便在这个年龄段,不喜欢发的也占一半,喜欢发的占30%。在全部智能手机用户中,63%从没发过语音。
一条语音消息多长算太长?
在2022年5月 YouGov 对英国智能手机用户的那项民调中,给出了答案的人里,65%认为一分钟的语音消息太长;在不喜欢收语音、并且给出了答案的人里,57%对30秒的语音就已经感到挫败。在全体智能手机用户中,27%说不准界限在哪里。问到更希望怎样收到一条很长的消息时,78%选文字,14%选语音,不过这只反映人们嘴上说的偏好13。有些发语音的人似乎也知道,这段录音是在给对方添麻烦。2024年一项对德国和西班牙 WhatsApp 聊天记录的分析发现,人们会在语音之前、之中和之后,为自己选择语音作出说明;作者认为这些说明起着社交上的作用,包括把发语音说成一件值得道歉的事14。综合这三项来源,发的人省了力,付出代价的是收的人,而有些发的人会为此道歉。
Apple 的听写会怎么处理一段语音备忘
语音转文字给你的,是你说过的词,顺序也是你说的顺序;对 Apple 的听写(Dictation)来说,这就是它的全部工作。Apple 为 iOS 27 写的 iPhone 使用指南介绍说,听写在手机上处理,不需要联网,支持多种语言,在语言受支持的情况下会自动插入逗号、句号和问号15。在最新的手机上,一个在设备上运行的模型会改进英语的拼写、标点和大小写。除此之外,一切都靠口头命令:说“new line”(换行),或者说“delete”(删除)再跟上要删的那句话。“在设备上处理”这个说法有一个条件。Apple 的隐私页面写道,如果“Keyboard Settings”(键盘设置)里没有显示听写是在设备上处理的,你口述的内容会发送到 Apple 的服务器,但不会被存储,除非你选择开启“Improve Siri and Dictation”(改进 Siri 与听写)。页面还写道,Apple 可能保留请求历史和转写文本,最长两年,它们关联的是一个随机的设备标识符,而不是你的 Apple Account16。页面没有说明这两种说法怎么衔接。改写是 Apple 另一套工具 Writing Tools 的工作,但它不会告诉你一段文字对方读到后的效果。
Google 和 Microsoft 的语音输入做了什么
Google 的 Gboard 基础语音输入和 Apple 的听写一样,把你说的词原样交给你。点一下麦克风,说出想写的内容,标点也要说出来,不过语音输入和标点功能并非每种语言都有17。它的高级语音输入,在 Pixel 6 及之后的机型上会边说边加标点;在 Pixel 9(不含 9a)及之后的机型上,还可以用一句口头命令,对你口述的内容做校对、换种说法、缩短或加长。Google 称这些功能在设备上运行,支持英语、法语、意大利语、日语和西班牙语,德语即将支持18。在 Windows 上,Microsoft 的帮助页面称,Copilot+ PC 上的 Fluid dictation 功能会在你说话时修正语法、标点和口头填充词19。高级语音输入只有在你下口头命令时才会改写。Fluid dictation 不用下命令就会运行,但只限 Copilot+ PC,而且它的帮助页面没有提到调整消息的顺序。在这里引用的 Apple、Google 和 Microsoft 帮助页面中,我没有找到哪个功能,默认就能把一整段东拉西扯的语音备忘变成一条可以发送的消息。
转写应用和聊天应用做了什么
转写应用 Otter 比手机键盘多走了一步。它的语音转文字页面介绍说,转写文本带说话人标签和时间戳,有自动生成的摘要和重点,还会提取要点和待办事项20。Otter 的帮助中心列出的支持语言有英语、西班牙语、法语、德语、日语和中文(简体)21,比语音转文字页面上写的要多。它是为会议设计的,所以做的是把说过的话压缩,而在这两个页面上,我没有找到哪个功能能起草你本来想发出去的那条消息。有些应用的底层是开源语音模型。Whisper 本身产出的是转写文本和一个语言标签7。基于它做出来的应用各不相同。MacWhisper 宣称,在转写文本之上,提供去除口头填充词、摘要和自定义提示词的功能,这一步可以选用本地模型或云端模型22。
聊天应用已经开始为你收到的语音消息转写文字。WhatsApp 在2024年11月上线了语音消息转写,转写在设备上完成,所以 WhatsApp 自己也读不到;在“设置”里的“聊天”下开启,长按那条消息就会触发23。那篇公告说,转写最初只支持少数几种语言,现在支持哪些,我没能确认。在语言受支持的情况下,这就解决了乌尔姆的作者指出的扫读问题。你拿到的,是别人出声思考的转写文本。哪怕正在开会,你也能读一读,但回复还得你自己写。
改写这一步多做了什么
改写这一步,会把转写文本变成一条消息:如果打字不费力,你本来就会这样打出来。它去掉 Clark 和 Fox Tree 描述的那些填充词,合并 Shriberg 分类里的重复和重新起头,把你说到一半做的更正放回它该在的位置,替换掉被更正的那个说法。它还会调整顺序。口头的解释往往想到什么说什么:先讲背景,最后才提请求,或者先提请求,理由跟在后面。写下来的消息可以开门见山。
有两样东西,这一步必须原封不动。第一是意思。如果改写把你的语音备忘抹平成了另一个请求,那还不如转写文本,因为转写文本至少说的是你说过的话。第二是语气。无论你当时是温暖、直白,还是在开玩笑,写出来的版本都应该还是同一个人。这里常见的失败,在AI 会不会让你的消息听起来像机器人写的里讲过:改写出来的东西客气而笼统。
还有一种判断,是转写文本从来不用做的。你在语音备忘里说的话,有一部分是说给你自己听的,不是说给收件人的。出声地琢磨要不要提某件事,不等于你打算提。改写这一步得判断,哪些是消息,哪些是打草稿,而这个判断两个方向都可能出错:要么留下了一句你正劝自己别说的话,要么删掉了一句你本来想说的。我没有找到任何研究,测量过任何工具(包括 Subtext)出这种错的频率。
Subtext 怎么处理一段语音备忘
Subtext 会先转写你在应用里录的语音备忘,再根据你想表达的意思写出消息,最多给出三个版本,每个版本都带一个“可放心发送”评分,说明对方读到后,效果和你的本意一致的可能性有多大。这些版本的目标是保住你的意思和你的个性。针对初稿,一个版本紧贴你的原话,只把问题改掉;一个是更温暖的润色,或者换一种思路;还有一个是更彻底的改写。如果措辞读起来比你的本意更冷、更尖锐,应用会点出问题,并标出有问题的词。它不会替你发送任何东西。
写这篇文章之前,我读过后端的提示词。模型的指令里专门考虑到了转写造成的瑕疵。当一条消息被标记为口述时,模型被告知要预料到听错或连在一起的词、古怪的标点和零星的填充词,要越过这些瑕疵读出你想要的措辞,并且悄悄改正,不要把它们当作你的错误标出来。提示词只能说明模型被要求怎么做。我没有找到对 Subtext 的语音转写或改写所做的独立评估,所以这一切,依据的只是应用展示出来的东西,以及它的提示词和隐私政策里写的内容。上面那些研究都没有测试过 Deepgram,也就是给 Subtext 的音频做转写的语音模型。口音、第二语言语音和随意说话风格带来的错误模式,有多少会延续到它身上,我没法说。所以发出去之前,先把这条消息自己读一遍。
在 Subtext 里,语音录音会怎么处理?
Subtext 会把语音录音发给 Deepgram 转写,所以音频是会离开手机的。它的隐私政策(2026年10月10日更新)列出了几家服务商:语音录音交给 Deepgram,文字、图片和语音转写文本交给 Anthropic,账号和对话用 Google Firebase,只有在你打开“朗读”时才会用到 OpenAI。政策还补充说,开启联网搜索后,根据你的请求提取的搜索词会经由 Anthropic 发送给第三方搜索服务商,你可以在应用的设置里关闭联网搜索24。政策称,你提交的任何内容都不会用来训练 AI 模型,它的 AI 服务商也都不得用这些内容训练,Subtext 还为语音设置了 Deepgram 的模型改进退出选项。政策称,Subtext 会在你最后一次使用某段对话的五天后,从自己的服务器上删除这段对话的副本;如果你把它置顶,则是90天后。政策称,在设置了那个退出选项的情况下,Deepgram 只在转写所需的时间内保留音频;Anthropic 会在30天内删除输入和输出,被标记的请求最长可能保留两年,相关的安全评分最长可能保留七年。政策还称,Subtext 与它们中的任何一家都没有零留存的约定24。其他助手怎么处理你的文字,可以看哪些 AI 写作助手会用你的消息来训练模型,那篇文章做了比较。
Subtext 支持哪些语言?
Subtext 会用你说话时用的语言来写这条消息,支持17种以上语言,在语言区分正式程度的地方,还会保持你原来用的正式程度。用德语录的语音备忘,回来的是一条德语消息。你收到的语音消息,摘要也是用语音本来的语言写的。Google Play 的编辑把这套流程放进了一篇“Hot Tip”专题里,文中描述的步骤是:点按麦克风图标,说话,再点按一次,得到一条润色过的消息,附有说明原稿读起来是什么印象的标签,还有一个复制按钮25。我在2026年10月4日打开这个页面时,德国区的页面显示4.3星、295条评价,下载量超过5万次,这只是 Google Play 上的数字;星级各国不同。Subtext 是收费的,开头有几次免费分析。录好的语音备忘,Subtext 会给你一条可以发出去的消息。
别人发来一条很长的语音消息,怎么回复?
Subtext 也能读别人发给你的语音消息,而在这一侧,单纯的转写文本最接近够用。在你的语言受支持的情况下,WhatsApp 在设备上生成的转写文本,能让你把一段两分钟的录音读下来23。它做不到的,是告诉你对方到底要什么。乌尔姆那项研究自己举的例子,就是埋在音频里的一个日期和一个地点9。朋友或上级发来的一条很长的语音,也是同样的结构:问题在中间的某个位置,理由围在四周。对回复总是卡住的人来说,阅读这一步,是回复容易卡住的五个环节之一,而乌尔姆实地研究的大多数参与者在工作时会推迟处理语音消息,因为录音没法一眼看完9。
把收到的一条语音消息放进 Subtext,它会先转写,再用一句话概括对方想要你做什么,并列出两到五条行动要点。接着它可以起草一条接上话头的回复,而且不会给发送者的语气贴标签。后端提示词把你附上的语音文件,当作最可能是对方发给你的;如果模型拿不准谁是谁,指令要求它去问。摘要的质量,取决于底下的转写;而一句话脱离了上下文很难读懂,这条消息是什么意思一文就说明了这一点。口音重或者录音嘈杂时,转写的错误会比录音棚里的英语多,所以遇到要紧的事,回复之前先把原始录音听一遍。文字和截图走的是同一个摘要步骤,所以你收到的消息也会得到同样的一句话摘要。
下面用一次运行看回复这一步。我编了一段语音备忘,以文字形式输入,就像转写这一步把内容交给后面的环节那样,所以这次运行并不能说明转写本身的任何情况;回放里也没有出现上面说的那种一句话摘要,摘要写得怎么样,这次运行同样说明不了。这段语音是姐姐发来的,内容如下:“喂,是我。那个,我刚跟爸打完电话,说来话长,反正车还在修理厂。他们现在说周四,也可能周五。哎,算了,我打电话不是为这个。就是,咱妈生日是19号,我想着要不我们去她那儿吃午饭吧,就别出去吃了,你知道她在餐厅会什么样。蛋糕我来弄。礼物你能负责一下吗?我想的是她喜欢的那条蓝围巾,就集市上那条,不过说实话,你觉得怎么样都行。然后,你周三之前跟我说一下带不带Sam来?因为我得告诉她我们一共几个人。嗯,就这些。哦对了,围巾的事别跟她说。拜拜。”
语音下面输入的指示是“跟她说围巾我来买,还有,Sam会来”。Subtext 没有给任何标签,先回了一句“好的,信息都很明确,我帮你写好回复了。”,接着写出两个版本,都标为“可放心发送”,没有一个标成“需要留意”。第一个版本叫“简短直接”,情绪词是“平和”,内容是“嗨,收到你的留言了。围巾我来买,Sam也会来,你可以跟妈说我们一共几个人了。”,说明里写它“直接回答了礼物和Sam两件事”。第二个版本叫“更暖一点”,情绪词是“体贴”,开头是“听到你的留言啦。在妈家吃午饭挺好的,她也自在些。”,后面是“围巾我来买,放心,不会跟她说。”和“Sam会来,你就按我们一共几个人跟她讲吧。”
“不会跟她说”这半句,输入的那句指示里没有,它来自语音最后的“围巾的事别跟她说”;应用没有另外交代为什么加上它,只在这个版本的说明里写到“也保证了围巾保密”。只有第二个版本接住了保密这件事。语音一开头讲的那辆车,两个版本都没有提。最后它问:“要不要再短一点,或者更随意、更暖一些?”,下面是“更简短”“更温暖”“更随意”三个可点选项,这次运行到这里为止。以上是应用的真实输出,没有改动。
跟她说围巾我来买,还有,Sam会来
好的,信息都很明确,我帮你写好回复了。
- 简短直接 (平和, 可放心发送): 嗨,收到你的留言了。围巾我来买,Sam也会来,你可以跟妈说我们一共几个人了。 直接回答了礼物和Sam两件事,简短清楚,对方很容易看懂。
- 更暖一点 (体贴, 可放心发送): 听到你的留言啦。在妈家吃午饭挺好的,她也自在些。围巾我来买,放心,不会跟她说。Sam会来,你就按我们一共几个人跟她讲吧。 回应了午饭安排,也保证了围巾保密,同时答复了礼物和Sam,显得贴心又清楚。
要不要再短一点,或者更随意、更暖一些?
最接近的实验,年头久,规模小
就改写步骤或摘要来说,我找到的两项最接近的实验,分别来自2003年和2005年,规模都很小。2003年,一项由 DARPA 资助的实验,让28名英语母语者阅读150到250个词的电话和广播语音的文字稿,有逐字转写的,也有经人工清理过的。读者认为清理过的文字更容易理解,但回答相关问题时,并没有更准确,也没有更快;作者把这归因于读者的得分本来就已接近上限。对有瑕疵的识别结果做自动清理,得到的文字往往被评为比没清理过的更难读,不过差距很小26。这里的清理,去掉了不流畅现象,修正了标点,但没有把文字改写成一条消息。
2005年,16个人根据自动抽取的摘要,回答了关于15条语音留言的问题。看由识别出的语音生成的摘要,人们答对来电者姓名的比例是57%,看由人工转写文本生成的摘要则是94%;来电原因两种摘要传达得一样好,都是78%。当摘要来自识别出的语音时,人们更常要求听原始音频,是53%对30%27。这些是用2005年的语音识别技术,对语音留言做的抽取式摘要,所以这项研究只能让我们有个大致预期。两项研究都没有测量过一条会被人发出去的消息。
证据到哪里为止
证据比较扎实的,是两头。口语里的不流畅现象有实测得出的比率,写作里没有这种现象;语音识别对一些说话人出的错比对另一些人多,上面的数字显示了这一点。中间的部分薄弱一些。我没有找到任何研究,测量过一段改写过的语音备忘,效果比原始的转写文本好多少;也没有找到研究,测量过改写时有多常改变了原意。关于语音消息的研究只有寥寥几项,其中规模最大的一项,调查样本来自美国的一个众包平台,实地研究则只有六个人。YouGov 的民调只来自一个国家、一个年份。而且这些语音消息研究都早于在设备上生成的转写文本,它们描述的那种负担转移,现在已经被聊天应用自己弥补了一部分。
落到实际使用上,关键看你怎么说话。如果你说话本来就是干净利落的整句,语音转文字就够了,你的手机里已经有了。如果你说话像那些语料库里的说话人,带着 Clark 和 Fox Tree 数过的填充词,带着 Shriberg 分门别类整理过的重新起头,转写文本交到收件人手里的,就是你起草的过程,要把它变成一条消息,靠的是改写这一步。Subtext 就是做这一步的应用之一,处理你录的语音备忘,也处理你收到的那一条;如果你的难处是一条回复改来改去,为什么一条简短的回复要花一个小时讲的就是这个循环。
参考来源
按首次出现的顺序编号。页面核查于2026年10月4日和5日,Subtext 隐私政策又于2026年10月10日重新打开查阅过。
- Shriberg, E. (2001). To ‘errrr’ is human: ecology and acoustics of speech disfluencies. Journal of the International Phonetic Association, 31(1), 153-169. 美国英语对话的语料库研究;不流畅现象的发生率和类型。
- Shriberg, E. Disfluencies in Switchboard. SRI International Speech Technology and Research Laboratory. 会议论文;PDF 上没有标注年份,所引参考文献截至1996年。人工标注的语料库:30位说话人的40,515个词(Switchboard),以及523位说话人的12,762个词(AMEX,SRI 员工与旅行社代理人之间的电话)。由 DARPA 和 NSF 资助。. 核查日期:2026年10月5日。
- Clark, H. H., and Fox Tree, J. E. (2002). Using uh and um in spontaneous speaking. Cognition, 84(1), 73-111. London-Lund 语料库中每位说话人的填充词比率。
- 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小时音频。
- 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. 仅读到摘要;核查时无法获取全文。
- 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.
- OpenAI. Whisper README. GitHub. . 核查日期:2026年10月4日。
- 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 的 Center for Social Sciences 资助。
- 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人的实地研究。
- 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 运行在百度的服务器上,用一个 iPhone 6 Plus 上的应用测试。
- 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名参与者。
- Yuan, J., Liberman, M., and Cieri, C. (2006). Towards an integrated understanding of speaking rate in conversation. Interspeech 2006. Switchboard 电话对话。
- YouGov. How many Britons like voice notes? 发布于2022年6月14日。对2,149名英国成年人的民调,调查于2022年5月5日和6日进行,其中1,956人使用智能手机;时长方面的数字,是给出了答案的受访者所占的比例。结果表见 . https://yougov.com/en-gb/articles/42817-how-many-britons-voice-notes. 核查日期:2026年10月4日和5日。百分比依据 YouGov 文章正文;结果表里“不喜欢”一项的合计数略有不同,系四舍五入所致。
- 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 记录里读到的,全文需付费。
- Apple. Dictate text on iPhone. iPhone User Guide, iOS 27. . 核查日期:2026年10月4日。
- Apple. Siri, Dictation & Privacy. Legal,最后更新于2026年9月14日。. 核查日期:2026年10月5日。
- Google. Type with your voice. Gboard Help. . 核查日期:2026年10月4日。
- Google. Use advanced voice typing features. Gboard Help. . 核查日期:2026年10月5日。
- Microsoft. Use voice typing to talk instead of type on your PC. Microsoft Support. . 核查日期:2026年10月5日。
- Otter.ai. Convert Speech to Text. . 核查日期:2026年10月4日。
- Otter.ai. Supported languages. Otter Help Center,文章编辑于2026年5月6日。. 核查日期:2026年10月5日。
- MacWhisper. Homepage. 营销页面,未标注日期,所以它显示的是产品的宣传内容,而不是实际表现。. 核查日期:2026年10月5日。
- WhatsApp. Introducing Voice Message Transcripts. 2024年11月21日。. 核查日期:2026年10月4日。
- Subtext, Terms, privacy and your account. 隐私政策最后更新于2026年10月10日。核查日期:2026年10月10日。
- Google Play. Hot Tip: Speak your mind with Subtext. . 核查日期:2026年10月4日;在我打开的每个地区的商店页面上,页面都显示295条评价和5万以上下载量,德国区页面显示4.3星。
- Jones, D. A. 和另外六位合著者 (2003). Measuring the Readability of Automatic Speech-to-Text Transcripts. Eurospeech 2003, 1585-1588. 招募了32名英语母语者,分析了其中28名。由 DARPA 赞助,空军合同号 F19628-00-C-0002。
- 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 资助。