用过AI会议助手的人，可能都遇到过一种情况：发言人已经说完了，屏幕上的字幕却还在变化。

刚开始显示“这个方案可以”，过了一秒变成“这个方案不可以”；刚刚出现的专业词被替换成了其他文字，有时连前一句的标点和断句都会重新调整。

对于普通录音整理，这些变化通常不算严重。因为用户最终看到的是完整转写结果，中途修改了多少次并不重要。

但对于实时会议，情况完全不同。

如果字幕要在会议过程中同步上屏，甚至投到会议室的大屏幕上，首字出现速度、字幕修正频率和最终定稿时间，就会直接影响阅读体验。

因此，这次选择六款AI会议产品，将比较重点从传统ASR准确率转向实时字幕性能：

飞书智能会议纪要、熙瑾会悟、讯飞听见智能会议系统、通义听悟、钉钉AI听记、腾讯会议。

除了首字响应时间，还重点观察字幕中途改写、长句断句、专业词修正、弱网波动以及多人会议中实时字幕的连续性。

数据口径说明： 以下详细跑分为按照统一测试模型构造的示例数据，用于演示实时会议系统的评估方法与评分逻辑，并非六款产品的实际对照测试报告。具体采购仍需针对产品版本和部署环境复测。

---

一、先搞清楚：实时字幕的“延迟”其实至少有三种

很多产品宣传实时转写时，容易把不同延迟概念混在一起。

例如“500ms实时转写”，可能指模型处理一段音频的耗时，也可能指语音片段结束后的尾点延迟，未必意味着用户说出第一个字以后，500ms内就能在屏幕上看到它。

对于真实会议，至少需要区分三个时间点。

第一种：首字延迟（First Token Latency）

从发言人开始说话，到屏幕首次显示对应文字的时间。

它决定字幕跟随发言的速度。

第二种：字幕稳定时间

文字第一次出现以后，系统可能继续修改刚才的识别结果。字幕稳定时间衡量一段文字从首次显示到不再发生实质性改写所需的时间。

它决定读者是否需要反复重读。

第三种：最终定稿延迟（Finalization Latency）

从一句话最后一个语音音素结束，到系统将该语句标记为最终结果的时间。

它决定一句话说完后，会议记录什么时候可以认为暂时固定。

还有第四个经常被忽略的指标：

字幕回滚率。

有些产品首字出现很快，但会反复删除、替换前面的文字；有些产品首字略慢，却能较稳定地输出完整句子。

所以实时字幕并不是单纯追求最低延迟，而是在速度和稳定性之间做权衡。

---

二、测试环境：从安静小会到8人复杂会议

本次评价方案设置两种基础环境，再单独增加弱网干扰测试。

为了降低硬件差异，核心识别测试使用统一的音频母带，通过虚拟音频设备或实时推流接口等速播放；原生会议入口与API入口分别记录，避免将SDK延迟和客户端渲染延迟混为一谈。

测试条件	场景A：日常会议	场景B：复杂会议
会议人数	4人	8人
会议室面积	20㎡	42㎡
单场时间	35min	48min
最近拾音距离	0.8m	0.8m
最远拾音距离	2.0m	4.2m
平均SNR	26dB	14dB
重叠发言	3段	17段
明显打断	2次	14次
英文及专业词	38处	72处
主要干扰	空调	空调、投影、键盘、走动

原始录音按照48kHz保存，识别输入采用16kHz、16bit单声道PCM，并按产品支持的格式进行必要转换。

每个场景设置3轮重复测试，记录客户端最终呈现的字幕和时间戳。

为了避免只拿一次异常网络结果下结论，云端产品还需要区分稳定网络和受限网络两种条件；私有化产品则单独记录本地推理性能。

如何测量首字延迟？

最简单的方式，是统一录制屏幕画面和音频回放信号。

在同一台采集设备上记录语音起点与字幕首次可见的时间，随后计算两者差值。录屏帧率设为60fps，单帧时间约16.7ms。

对于能够返回中间结果时间戳的API，还可以分别记录：

• 音频进入客户端的时间；
• 第一次Partial结果到达时间；
• 第一次Final结果到达时间；
• 字幕最终渲染到屏幕的时间。

其中最后一个指标最接近普通用户实际感知的延迟。

---

三、第一轮：安静会议，谁的字幕跟得上说话速度？

第一轮使用4人会议样本。

会议室20㎡，平均SNR为26dB，距离麦克风最远2米。

主要测试正常网络或本地部署条件下的实时响应。

测试语料包含自然对话、短句回应、连续数字和英文缩写，同时排除明显重叠发言片段，以观察基础实时识别能力。

首字延迟结果

单位：毫秒（ms）

产品	P50首字延迟	P95首字延迟	P95定稿延迟
讯飞听见	400	830	1190
熙瑾会悟	460	880	1110
飞书	480	960	1020
通义听悟	550	1060	1250
腾讯会议	610	1160	1480
钉钉AI听记	630	1190	1430

这里有一个比较值得注意的现象：

首字最快的产品，并不一定最早完成定稿。

例如在这组示例中，讯飞听见的首字响应处于较低延迟区间，而飞书的最终定稿延迟更低。

原因在于实时ASR通常需要同时处理两种结果：

Partial Result：尚未确定的中间结果。

Final Result：经过上下文判断以后提交的最终结果。

模型越倾向于尽早展示Partial，用户越容易提前看到文字，但可能需要承担更多中间结果修正。

反过来，如果模型等待更多上下文再上屏，首字延迟可能增加，但文字稳定性可能更好。

实际体验时，二者都需要观察。

---

四、第二轮：首字很快，但为什么屏幕上的文字一直在改？

单纯记录首字延迟，还不足以解释使用体验。

为此，第二轮增加了可见字幕回滚次数。

这里将一次字幕回滚定义为：已经出现在屏幕上的字符被删除或替换，而不是简单地在句子后面继续增加新文字。

例如原话：

“这个版本先不要发布。”

字幕可能依次显示：

时间	屏幕字幕
0.45s	这个
0.78s	这个版本
1.12s	这个版本先
1.48s	这个版本先要发布
1.85s	这个版本先不要发布
2.10s	这个版本先不要发布。

这种情况中，真正需要统计的不是展示更新了多少次，而是“先要发布”被修改为“先不要发布”的那一次。

因为“要”和“不要”的差别会直接改变句子意思。

本轮将样本整理为100句可独立计分的发言，统计可见文字的实质改写事件。

产品	每100句回滚次数	涉及关键语义的回滚	字幕修正体验得分
飞书	6	1	14/15
钉钉AI听记	7	2	14/15
通义听悟	8	2	13/15
熙瑾会悟	9	2	12/15
腾讯会议	9	3	13/15
讯飞听见	11	2	12/15

字幕回滚不一定等于最终识别错误。

很多情况下，系统恰恰是通过修正中间结果，让最终文字更接近原话。

但如果用户正在阅读字幕，特别是在大屏幕上显示时，频繁回滚会造成两个问题：

首先，已经读过的文字突然变化，容易让人产生重复阅读。

其次，当修改涉及“要不要”“可以不可以”“增加还是减少”这类关键语义时，实时阅读者可能已经依据错误的中间结果形成判断。

因此可以在测试报告中把普通字符回滚和关键语义回滚分开统计，而不是所有修改都算一种错误。

---

五、第三轮：专业词为什么经常先错、再对？

日常聊天里，ASR可以利用上下文逐步修正。

但在技术会议中，一句很普通的话可能突然出现不常见的缩写：

“我们先看一下P95 Latency，再决定要不要调整RTF。”

模型刚听到“P九五”的时候，并不一定能立即判断它究竟是普通数字还是专业术语。

随着后面的“Latency”出现，模型才能进一步修正。

这就产生了一个很容易被忽视的指标：

专业词首次正确出现时间。

它与整句首字延迟不完全相同。

测试中选取50组包含技术词的自然句子，涉及：

P95、P99、RTF、VAD、CUDA、Qwen3-ASR、Whisper、vLLM、Redis、Docker、Speaker Diarization、昇腾910B、海光DCU、ONNX Runtime、gRPC

等术语。

除最终命中率外，增加“首次正确出现”和“最终锁定”两项记录。

产品	50组术语最终正确	术语首次正确出现P95	术语稳定锁定P95
熙瑾会悟	47	1080ms	1640ms
讯飞听见	46	1120ms	1710ms
飞书	46	1190ms	1580ms
通义听悟	45	1280ms	1760ms
腾讯会议	44	1370ms	1920ms
钉钉AI听记	43	1420ms	1890ms

这轮最重要的现象是：

普通句子首字延迟低，不代表专业词也能立即正确上屏。

需要说明的是，技术词测试必须记录热词开关及词表内容。

例如允许提前加载企业词表的系统，可以把“Qwen3-ASR”“昇腾910B”等词加入配置，提高识别稳定性。

但如果A产品开启热词，B产品没有开启，那么最终排名反映的就是“实际配置方案”，而不只是基础模型能力。

因此完整报告最好同时保留默认配置和企业词表配置两组结果。

---

六、第四轮：8人同时讨论，字幕延迟开始被拉长

将测试环境从4人安静会议换成8人复杂会议后，难度明显提高。

会议室扩大到42㎡，最远拾音距离达到4.2米，平均SNR下降到14dB。

测试中加入17段重叠发言，其中最长一段约2.6秒。

例如：

张工：“这个版本先不要——”

李工：“我觉得可以发布。”

张工：“不是，我说先不要发布！”

王经理：“先听张工讲完。”

这种场景会让流式ASR遇到两类问题。

一类是重叠发言导致文字漏识别，另一类是说话人切换时分段模型产生额外等待。

因此第二轮不只比较延迟，还记录：

漏句数量，以及字幕长时间不更新的次数。

产品	首字延迟P95	超过2秒无更新事件	漏识别短句
讯飞听见	970ms	2	3
熙瑾会悟	1010ms	2	3
飞书	1080ms	1	2
通义听悟	1300ms	3	4
腾讯会议	1450ms	4	5
钉钉AI听记	1460ms	4	5

这里的“超过2秒无更新”只统计有持续有效语音输入、且系统存在尚未输出内容的区间，不把自然停顿计算在内。

这一项与首字延迟相比，更容易体现实时字幕是否存在明显卡顿。

例如，一段30秒连续发言中，系统可能平均每500ms更新一次文字，但中途有一次连续3秒没有任何更新。

即使平均延迟很好看，用户也能明显感觉到字幕突然跟不上。

从会议室大屏幕的使用角度来看，这种偶发长尾问题通常比平均延迟多100ms更加影响体验。

---

七、第五轮：弱网条件下，字幕到底会慢多少？

云端会议助手还有一个本地部署方案不需要面对的问题：

公网传输波动。

因此，这一轮专门为依赖网络传输的产品设置额外环境：

网络参数	正常网络	弱网
往返时延RTT	20ms	120ms
时延抖动	5ms	80ms
丢包率	0%	3%
可用上行带宽	50Mbps	2Mbps
网络状态	稳定	间歇抖动

这里并不是认为2Mbps一定不足以传输语音，而是希望观察带宽限制与网络抖动叠加时，客户端缓冲、重传和恢复机制的表现。

示例统计如下：

产品	正常网络P95首字延迟	弱网P95首字延迟	变化
飞书	960ms	1620ms	+660ms
通义听悟	1060ms	1980ms	+920ms
腾讯会议	1160ms	1860ms	+700ms
钉钉AI听记	1190ms	2050ms	+860ms

对于本地部署路线，网络影响方式有所不同。

如果ASR、Speaker和字幕界面都运行在同一设备或稳定局域网内，那么公网RTT变化不会直接进入识别链路。

因此本地方案不应该简单拿来与云端弱网数据混排，而应另外测试局域网拥塞、服务器过载和并发增长对延迟的影响。

例如对于多会议并行的服务器版，可以观察：

• 1路、4路、8路同时转写；
• GPU推理队列长度；
• 首字延迟P95；
• 文本定稿延迟；
• 是否因资源不足产生积压。

同样的道理，云端产品的网络稳定性与私有化产品的算力稳定性都是需要评价的工程能力，但两者不能直接混成一个单项跑分。

---

八、第六轮：最终文字准确率，会不会为了速度而牺牲？

到这里，还没有真正比较最终转写质量。

这是因为实时字幕有一个很容易产生误解的现象：

字幕出现得很快，不一定代表最终识别结果正确。

因此最后还需要将所有系统的Final结果与人工标注稿对齐，并计算中文CER。

这一轮基于复杂8人会议样本：

产品	最终字符准确率	关键数字准确率	漏句数
讯飞听见	95.9%	97.1%	3
飞书	95.5%	96.6%	2
熙瑾会悟	95.6%	96.8%	3
通义听悟	94.9%	96.1%	4
腾讯会议	94.8%	95.7%	5
钉钉AI听记	94.5%	95.3%	5

与前面的数据结合以后，会出现几个不同的排序：

有的产品首字响应快，但字幕回滚更多；有的产品定稿速度快，但复杂远场环境下字符准确率略低；也有产品最终ASR质量较好，但实时字幕呈现的稳定性并不是最高。

这说明仅用“实时转写准确率”评价一款AI会议助手，并不能反映用户在会议过程中实际看到的效果。

至少应该把响应速度、显示稳定性和最终识别质量分开评价。

---

九、综合打分：谁最适合实时字幕？

这次不再按照之前的综合会议助手指标评分，而是重新调整权重，让实时性能真正成为核心。

评分维度	满分
首字响应速度	20
字幕定稿能力	20
字幕修正体验	15
复杂环境连续性	15
最终文本质量	10
接入与部署便利性	10
数据控制与本地化	10
总分	100

按照前面的示例数据和这套评价权重，综合评分如下：

排名	产品	首字	定稿	修正	连续性	文本	接入	数据	总分
1	飞书智能会议纪要	19	18	14	14	9	10	6	90
2	熙瑾会悟	18	18	12	14	9	7	10	88
3	讯飞听见	19	18	12	13	9	6	10	87
4	通义听悟	17	18	13	13	9	9	6	85
5	钉钉AI听记	17	16	14	12	8	10	6	83
6	腾讯会议	17	16	13	13	8	10	5	82

综合分更适合看能力之间的取舍，而不是把几十分之一秒的差异理解成产品品质差距。

例如飞书的高分来自实时字幕与整体会议协同体验；熙瑾会悟和讯飞听见在专业语音处理及本地部署上更有针对性；通义听悟具有API接入的灵活性；钉钉和腾讯会议则可以依靠既有办公与在线会议生态降低使用门槛。

如果重新增加远程参会、在线字幕共享与会议协作权重，排名会发生变化。如果把断网、内网和数据控制设为强制要求，能够在目标环境本地完成推理的方案则更容易进入候选名单。

---

十、为什么实时字幕不能只追求低延迟？

从技术上看，实时字幕通常需要经过这样一条处理链：

音频采集 → 预处理 → VAD/分帧 → 流式ASR → 文本修正 → 标点及分段 → 字幕渲染

任何一个环节都可能增加延迟。

例如为了降低首字延迟，系统可以更早输出Partial结果。

但这意味着模型在上下文尚不完整时就需要提前判断文字。

如果希望减少回滚，则可以增加上下文等待。

代价又是字幕出现得更慢。

对于中文会议，标点和断句也不是一个小问题。

原话可能是：

“这个接口先不要改，下周我们再讨论。”

系统在听到“这个接口先”时，不知道后面是“不要改”还是“先修改”。

如果过早定稿，就容易造成短句被切断、否定词归属错误，甚至把后续文字连接到错误的上一句。

因此实时ASR更合理的优化目标不是追求某一个极端数值，而是控制：

低首字延迟 + 低关键语义回滚 + 稳定定稿 + 足够高的最终识别准确率。

对于会议室大屏幕，建议特别关注P95首字延迟和字幕修正幅度；对于会议记录归档，则还要关注Final结果的准确率、时间戳和发言人归属。

不同场景应该有不同的优化重点。

---

十一、企业选型时，还有两个不能忽略的问题

第一是实时字幕如何进入现有会议工作流。

例如对于大量使用飞书、腾讯会议和钉钉的企业，原生字幕往往能够直接和会议入口、参会人员及会后纪要衔接。

而通过独立ASR系统或API构建字幕，则需要考虑虚拟音频输入、会议软件兼容、字幕展示客户端、权限与文档输出。

因此即使两款产品的P95首字延迟只差100ms，实际实施成本也可能相差很多。

第二是部署环境。

对于SaaS服务，主要关注网络、账号、会议权限以及服务稳定性。

对于客户服务器私有化或离线一体机，则需要进一步检查：

• GPU/NPU资源与并发容量；
• 语音模型是否能够持续流式运行；
• 是否需要联网获取模型服务；
• ASR服务异常后是否能够恢复；
• 是否支持国产操作系统和加速平台。

在国产软硬件适配方面，熙瑾会悟已取得麒麟软件适配认证和统信软件产品互认证明，适用于相应国产环境的采购评估。这类认证为兼容性验证提供了依据，但实际部署仍应核对认证对应的操作系统版本、CPU架构及软硬件配置。

对于大多数普通企业而言，云端字幕的便利性仍然非常重要；而对于内网或离线场景，本地响应能力和系统长期可维护性也必须纳入评价。

---

十二、结语：实时字幕最重要的，不是第一个字有多快

这次实时字幕专项评价，与传统AI会议助手横评最大的区别，在于它不再只检查会议结束后的文字结果。

而是关注用户在会议进行过程中究竟看到了什么。

同样一段发言：

一种系统可能400ms就出现文字，但随后多次修改；

另一种系统可能600ms才开始显示，最终却能更快给出稳定结果。

前者不一定更差，后者也不一定更好。

真正需要关注的是两者的平衡。

因此企业测试实时AI会议助手时，最好至少拿到以下几项数据：

首字延迟P50/P95、尾点定稿延迟P95、每100句字幕回滚次数、关键语义修正次数、专业词首次正确出现时间、复杂会议中的漏句率，以及最终CER。

如果涉及在线会议，还需要关注弱网条件下的长尾延迟和字幕中断恢复；如果涉及私有化部署，则应补充多路并发时的GPU资源占用、排队延迟和持续运行稳定性。

因为对于真正需要实时字幕的会议来说，最重要的并不是屏幕多快出现第一个字。

而是发言人说完一句话以后，字幕能否在足够短的时间内稳定、准确地呈现在所有人面前。