通话摘要是怎么生成的？实时转写加总结

AI 手机的宣传里，通话摘要常被排在第一位：挂掉电话，要点和待办已经躺在备忘录里。这个功能听起来像一步完成的魔法，实际是两个环节的接力——先把通话实时转成文字，再让模型从文字里归纳出要点和待办。两个环节各有各的脾气，衔接处还藏着误差。

第一步：边说边转成文字

通话摘要从转写开始。手机把通话音频流式送进语音识别模型，边听边出字，挂断时文字稿已经基本成型。这一步与录音转写同源，模型听的是音节和语流，输出是逐字文本。区别在于通话场景更难：电话音质被压缩过，方言、口音、专有名词都可能出错，而这些错误会被原样带进下一步。识别环节的输出质量，直接决定了摘要的天花板。此外，系统还要处理说话人混叠的问题：你一句我一句的对话要拼回通顺的文本稿，抢话、停顿、重复都得在文本层面抹平，这些细节处理得好不好，翻一遍转写稿就能看出来。

第二步：从全文里归纳要点

转写稿交给模型做归纳：把几十分钟的对话压成几条要点，顺手把「明天下午三点对一下方案」这类句子识别成待办。归纳模型读的是文字而非声音，它不负责纠正转写错误，只负责在现有文本里挑重点。云端助手类产品也提供类似能力——把长录音丢给豆包、Kimi 这类工具，同样能拿到要点列表，只是通话摘要把转写和归纳两步打包成了自动化流程，省去了手动搬运的环节。

实时与准确的取舍

摘要什么时候生成，决定了它的完整度。实时摘要在通话进行中就出结果，好处是挂断即得，代价是模型没看到全文，结尾出现的待办可能漏掉；通话结束后再生成，模型能通读整份转写稿，归纳更完整，但要等几十秒。厂商取向不同，有的给出「实时草稿＋结束后定稿」两档，用户能感知的差别主要在时效与完整度的平衡上。挑哪种更合适，看通话性质：安排事务的电话优先时效，涉及方案讨论的长通话等定稿更稳妥。

误差会顺着流程传下去

转写错一个数字，摘要里就会错一个数字——归纳模型不回听音频，它只信转写稿。所以关键信息要回查：金额、时间、电话号码这类内容，看摘要不如看转写原文，必要时听录音核对。对模型给出的要点保持一般性的怀疑是有益的，思路与不确定性声明一致：工具知道哪些环节不可靠，使用者也应该知道。

通话摘要流程对照

• 输入：通话音频（电话或网络通话）
• 环节一：流式语音识别，输出逐字文本稿
• 环节二：模型读文本稿，归纳要点与待办
• 主要误差源：电话音质、口音方言、专有名词
• 稳妥用法：关键数字与承诺回查转写原文

顺带一提，通话摘要只是 AI 手机功能版图的一角，修图、消除、智能助手共同构成这套体系，具体见AI 手机的 AI 用在哪。而转写和归纳这两步究竟跑在手机本地还是云端，两种安排的体验差异在本地模型和云端模型体验差在哪里有展开。

再多说几句通话摘要

• 摘要会漏掉重要内容吗？：会。模型按自己的「重要」标准筛选，未必与你的关注点一致，重要通话建议通读转写稿。
• 通话录音和摘要在哪存着？：本地功能多存于手机，走云端的服务会留存在服务器，涉及隐私的场景先看厂商的数据说明。
• 方言通话能摘要吗？：常见方言的识别能力在持续改进，重口音与语速过快的场景错误率明显更高，用前可先试一次短通话。