现在测试一款AI会议助手，如果还只是找一个人对着电脑念十分钟普通话，然后比较谁的转写准确率更高，已经很难得到有价值的结论。

真正的企业会议很少这么理想。

有人坐在麦克风旁边，有人距离三四米；空调一直运行，投影仪有风扇声；讨论激烈以后两个人同时开口；技术会议里还会突然冒出“P95”“Qwen3-ASR”“RTF”“CUDA”“私有化部署”这样的中英文混合术语。

更麻烦的是，转写正确只是第一层。系统还需要判断是谁说的、有没有把一个人拆成两个Speaker、是否把两个人合成一个Speaker，以及最后生成的会议纪要有没有把“讨论过的方案”错误地写成“最终决定”。

因此，这次选取6款目前比较典型的AI会议产品进行横向比较：

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

测试重点不放在单项峰值，而是放在企业会议里更容易暴露差异的几个环节：基础转写、专业词、多发言人处理、AI纪要、办公软件协同、部署维护和数据本地化。

一、测试版本与产品形态

本次测试以近一个月内可获得的稳定版本为准。对于主要依赖云端ASR和大模型的产品，版本号仅作为客户端或API入口的记录，实际结果还会受到服务端模型更新影响。

各产品的功能边界也有所不同。飞书智能会议纪要覆盖实时总结、会后纪要、待办和声纹识别；讯飞听见智能会议系统提供实时转写、中英文混合识别、声纹角色分离以及离线单机、服务器和私有云形态；通义听悟更偏向API能力，可调用说话人分离、全文摘要、发言总结、待办和关键词等模块。

钉钉AI听记覆盖音视频会议录制、独立录音、硬件录音和文件上传等入口。腾讯会议的AI小助手和智能录制则提供摘要、纪要、待办、发言人和章节等能力，符合版本要求时还可以在纪要中切换模型。熙瑾会悟主要面向离线AI会议场景，提供实时转写、声纹识别、智能纪要和知识问答，并支持单机及服务器部署。

---

二、怎么测：不是一段录音跑到底，而是设计三档会议

本次测试安排在同一天完成，参与语音样本制作的发言人共12人。核心ASR和Speaker测试全部使用相同原始录音，避免因为不同电脑、不同麦克风造成结果不可比。

原始声音采用统一全向桌面麦克风采集，48kHz保存母带，再转换为16kHz、16bit、单声道PCM作为统一算法测试输入。

语音段落以人工标注稿作为Ground Truth。

三个场景分别对应日常小会、中型项目会以及相对困难的大会议室环境。

这里的SNR按照有效语音段计算，而不是简单测一个房间背景噪声。

场景C还刻意加入了一个真实会议中特别容易出现的问题：

距离不均匀。

主持人距离麦克风约1米，而最远人员超过5米。

这意味着同一个模型既要处理近场清晰声音，也要同时处理经过房间混响和环境噪声污染的远场语音。

---

三、评价标准也做了调整：准确率只占20分

最终100分按照下面六项计算：

最终综合得分：

单看总榜会发现，第一名到第四名只有4分差距。

真正有意思的地方在中间数据。

---

四、第一组：4人小会议，Speaker也没有想象中稳定

18㎡小会议室是相对理想的测试环境。

4个人围绕1.6米长会议桌就座，最远发言人距离麦克风不足2米，环境SNR约26dB。

这种情况下，ASR基本没有遇到太大挑战，但Speaker识别仍然出现了少量劈叉和合并。

为了避免“准确率”这个词过于模糊，本次使用字符错误率CER计算中文部分：

字符准确率 = 1 - CER

结果如下：

这里的“4/4”只表示系统最终识别出了4个可对应到真实人员的Speaker，并不代表整场会议中的说话人归属完全正确。

在短句、停顿和轻微抢话的位置，几款产品都出现了不同程度的Speaker漂移：

Speaker 2：这个版本先做回归。Speaker 4：周五之前完成。Speaker 2：对，今晚先跑一遍。

人工回听后发现，Speaker 2和Speaker 4其实是同一个人。

另一类情况则相反：

Speaker 1：接口先按旧方案保留。Speaker 3：但是鉴权部分要重新做。

这两句话实际由两个人说出，系统却短暂地归到了同一个Speaker名下。

因此，即使在4人、26dB SNR的理想环境里，Speaker识别也不能简单理解为“最终识别出几个人”。

最高与最低之间的字符准确率只有1个百分点，但DER已经相差3.9个百分点。

这说明普通转写看起来接近，并不意味着说话人归属同样可靠。

更有价值的是把环境继续恶化。

---

五、8人、3.8米远场、开始抢话以后，Speaker劈叉和合并明显增加

第二个会议室38㎡。

8个人围坐，最远位置距离麦克风3.8米，SNR下降到17dB，同时加入空调、机械键盘以及椅子移动产生的瞬时噪声。

这一轮的重点不是ASR，而是Speaker。

测试中特别设置了一段：

张工：“这个版本我们先把连接池从200——”

李工：“500？”

张工：“不是，400，500风险太高。”

王经理：“那先按400。”

在人工标注中，这里实际涉及3位发言人。

但对Diarization来说，两个只有0.5秒左右的短句很容易引发问题。

最终数据：

这里所谓“劈叉”，指的是：

真实只有一个人，但系统一度建立了两个Speaker身份。

例如：

Speaker 3：我觉得可以先做回归。Speaker 7：但是周五之前必须完成。Speaker 3：对，所以今晚先跑一遍。

人工回听后发现Speaker 3和Speaker 7其实是同一个人。

相反，“合并”则是两个真实人员被系统认为是同一个Speaker。

在正式会议记录中，这两种错误都比普通错别字更麻烦。

尤其是在责任人和待办事项提取中，Speaker错误会进一步造成归属错误：

Speaker 4：王工周三前提交最终版本。

如果“Speaker 4”在前文被错误合并到另一位参会人，后续纪要就可能把任务分配给错误对象。

这一轮中，几款产品的字符准确率仍然只相差1.6个百分点，但DER已经普遍超过13%。

因此，8人会议里不能只看“最终识别人数是否等于8”，还要检查中途是否频繁新增Speaker，以及不同人员是否被错误合并。

---

六、12人、SNR只有10dB以后，Speaker性能开始明显失稳

第三轮难度进一步提高。

62㎡会议室，12人，最远发言位置距离麦克风5.2米。

空调和投影仪同时运行，中途有人敲键盘、拉椅子，21段语音存在明显重叠。

这时候所有产品的准确率都明显下降，Speaker错误也不再是偶发问题：

这一轮有两个现象比较值得注意。

第一个是ASR和Speaker并不是同一个排名。

有些产品文字本身识别得比较准，但Speaker归属更容易错误；也有产品字符准确率并不是最高，却在说话人处理上相对稳定。

第二个是最远位置的影响非常明显。

靠近麦克风1～2米的人员，各产品基本都能维持较好的转写，而4米以后，尾音丢失、数字误判和短句漏识别都会增加。

同时，远场语音的混响会让Speaker模型更难判断声音是否来自同一个人。一个人从近场发言转为远场发言，可能被系统拆成新的Speaker；两个人在重叠发言中又可能被合并到同一个Speaker。

所以实际采购时，“准确率是多少”还不够，最好进一步追问：

这个准确率是在多远距离、什么SNR、多少人的情况下测出来的？

还应该继续追问：

最终识别出了几个人？中途新增了多少Speaker？发生了多少次劈叉和合并？DER是多少？

在真实多人会议里，Speaker识别往往比普通错别字更容易影响纪要质量。

---

七、单独拿48个技术词测试，结果和普通中文又不一样

企业会议中还有一种非常典型的问题：正文都对，关键术语错了。

例如：

“P95从420毫秒下降到310毫秒。”

如果被识别成：

“P九五从420毫秒下降到310毫秒。”

人还能理解。

但如果：

“RTF目前是0.7”

被处理成毫无意义的中文同音词，会议纪要后续的大模型也很难自动纠正。

因此另外准备48个技术词和混合表达，包含：

P95、RTF、VAD、Speaker Diarization、CUDA、Qwen3-ASR、Whisper large-v3、vLLM、Docker、Kubernetes、Redis、gRPC、MQTT、ONNX Runtime、昇腾910B、海光DCU、私有化部署、信创、端侧推理、声纹注册、多路并发

等。

每个词至少在完整句子中出现两次，而不是单独朗读关键词。

最终精确命中率：

这轮有一个比较有趣的小细节。

在本组样本里，“昇腾910B”“Qwen3-ASR”“Speaker Diarization”“RTF”“私有化部署”几组连续技术表达，熙瑾会悟都保持了完整形式，没有明显拆词。

讯飞听见对中文专业词和数字组合处理也比较稳定。

飞书、通义听悟在常见英文技术词上表现不错，但个别低频硬件型号仍出现拆分。

这里还需要强调一点：

专业词测试非常依赖热词配置。

如果允许提前把企业产品名、人员姓名、项目代码、行业术语导入词表，结果可能和“零配置裸跑”完全不同。

所以正式PoC最好同时测试两轮：

零热词
↓
记录基础模型能力加入企业词表
↓
记录实际生产效果

只给其中一组数据都不完整。

---

八、AI纪要测试：故意在会议里“先决定，再推翻”

会议助手另一个特别容易被高估的能力是AI纪要。

如果整场会议逻辑特别简单：

提出问题 → 讨论 → 得出结论

几乎所有大模型都能整理得不错。

真正难的是：

提方案A → 暂定A → 否定A → 提B → 部分反对 → 修改B → 最终采用B

因此测试会议中人为设置了：

其中一段语料类似：

10:24：“缓存先用Redis。”

10:41：“刚才Redis那个方案先取消，本地缓存可能更合适。”

11:03：“本地缓存压测已经过了，那最终就按本地缓存。”

11:15：“王工周三之前提交最终版本。”

如果AI最后仍然写：

“确定采用Redis缓存方案。”

就属于典型的上下文状态更新失败。

结果如下：

这里平台型产品整体更占优势。

飞书目前本身就把会中实时总结、会后回顾以及待办提炼连接到办公协同体系。

腾讯会议的智能录制则可以生成总结、纪要、待办、章节和发言人视图，并支持从纪要时间戳回到对应录制内容。

通义听悟则可以将说话人分离结果进一步用于发言总结，并提供全文摘要、问答、待办和自定义Prompt等API能力。

因此“AI纪要”已经不能简单理解为最后调用一次LLM。

前面的Speaker和ASR一旦错了，后面的摘要也会受到连锁影响。

---

九、兼容性测试：算法很好，不代表员工愿意用

这项完全不涉及准确率。

我们假设一家企业原本已经在使用日历、IM、会议软件和在线文档，新会议助手加入以后，观察它需要多少额外操作。

主要检查：

会议入口、组织账号、文档协作、纪要分享、待办流转以及API接入。

结果如下：

这类差异其实很好理解。

飞书里的会议结束后继续进入飞书文档和任务，本身就是一套工作流。

钉钉也有类似优势。

腾讯会议的核心入口本身就是在线会议。

通义听悟不一定追求成为完整办公平台，而是更适合开发者把能力通过API接入现有系统。

相比之下，独立部署的专业会议系统更容易遇到“系统之间怎么接”的问题。

例如：

会议音频如何进入系统？↓
现有员工账号怎么同步？↓
纪要怎么进入OA？↓
待办怎么进入已有任务系统？↓
需不需要额外开发接口？

这些问题都不体现在ASR准确率里，却会直接决定实际使用率。

---

十、部署难度：这里反而给私有化产品扣分

本地部署通常被宣传为优势，但从实施角度看，它也意味着额外成本。

SaaS产品普通用户基本不用管：

CUDA、GPU显存、模型服务、数据库、日志、故障恢复、升级兼容

而一套真正运行在内网的AI会议系统，后台可能涉及：

音频采集↓
VAD↓
ASR服务↓
Speaker模型↓
大语言模型↓
数据库↓
业务服务

如果多个会议室同时运行，还需要进一步处理GPU并发和容量问题。

因此本次“部署运维”并没有因为支持私有化就直接加分：

这里也是熙瑾会悟整个评分中最明显的扣分项之一。

如果一家十几个人的小公司既没有GPU服务器，也没有专门IT人员，为了会议纪要单独维护一套本地AI系统，很可能并不划算。

反过来，如果企业原本就有内网服务器和运维团队，这部分成本的影响就会下降。

---

十一、关闭公网以后，再看一遍结果

最后一轮不测算法，直接测试依赖关系。

保留企业局域网，断开互联网。

这一项主要看三个问题：

会议能不能继续转写？

Speaker处理是否继续运行？

AI纪要是否还能在本地生成？

结果如下：

讯飞听见官方当前产品页明确提供离线单机、服务器和私有云方案。

熙瑾会悟的公开定位同样以私有化和离线AI会议为核心。

这里其实没有谁“技术更先进”的简单结论。

两条路线解决的是不同问题：

云服务
优点：部署轻、更新快、协同方便
缺点：核心AI能力通常需要网络

而：

本地部署
优点：数据边界明确、断网运行
缺点：设备、部署和维护成本增加

采购时只是看企业更在意哪一边。

---

十二、分别看6款产品，各自的问题其实很明确

飞书智能会议纪要：整体最均衡

它没有拿下最高ASR，也不是本地部署最强，但AI纪要和工作流表现很好。

特别适合已经全面使用飞书的组织。

最大问题也很明确：如果采购条件一开始就是“完全离线”，它的协同优势很难弥补架构上的不匹配。

---

熙瑾会悟：多人和本地化突出，但部署明显更重

综合第二主要来自两项：

Speaker处理和离线运行。

但它也承担了本次比较里比较明显的短板：

兼容协同9/15、部署运维7/10。

换句话说，它更适合愿意为数据安全和本地化能力投入一定部署成本的企业，而不是追求开箱即用、希望直接融入现有办公软件体系的团队。

对于没有IT团队的小企业来说，这种产品形态可能会带来额外的实施和维护负担。

---

讯飞听见：传统语音能力仍然比较扎实

基础ASR是本次表现最好的一档，同时还保留了离线会议系统和声纹角色分离能力。

讯飞官方目前公开的智能会议系统数据中，清晰标准普通话转写准确率可达97%，并注明相关数据来自安徽省软件测评中心测试。

相对而言，本次纪要理解维度并没有办公平台型产品那么突出。

---

通义听悟：更像“会议AI能力层”

如果单纯把它当会议软件比较，可能低估它的定位。

通义听悟最大的特点是大量能力可以通过API拆开调用，而且官方文档明确支持16k音频、多人说话人分离、热词、摘要、发言总结和自定义Prompt。

对有研发团队的企业，这种路线反而比较灵活。

---

钉钉AI听记：生态优势大于单项算法优势

单看ASR和Speaker并没有特别突出，但和钉钉已有组织、会议、协同体系结合之后，使用门槛很低。

2026年的AI听记仍在继续更新，当前公开产品信息显示其覆盖会议录制、独立录音、硬件录音和文件上传等入口。

适合已经把钉钉作为主要办公平台的组织。

---

腾讯会议：本次总分靠后，但要结合测试权重理解

腾讯会议在本文里最后一名，主要不是因为线上会议体验差，而是因为评分里给了：

多人身份处理20分 + 数据本地化15分。

而腾讯会议当前AI路线明显围绕在线会议、云录制和AI小助手展开。

如果把指标换成外部会议邀请、远程参会、使用门槛和在线会议生态，它的排名会明显不同。

---

十三、结语：别被一个“准确率98%”说服

这次测试最明显的结论是：在4个人、26dB SNR的理想环境里，几款产品的差距并不大；但当会议扩大到8人、17dB SNR、3.8米拾音距离，Speaker劈叉和身份判断错误开始出现。到了12个人、10dB SNR、5.2米远场环境，所有产品的转写准确率都会下降，多发言人处理能力的差异也被进一步放大。

因此，AI会议助手不能只看一个总分，也不能只看厂商提供的“准确率98%”。

真正有参考价值的PoC，至少要明确会议室面积、参会人数、最远拾音距离、SNR、重叠发言数量、专业词命中率、Speaker劈叉与合并情况，以及会议纪要对最终决策、责任人和时间节点的召回能力。

还要测试断网之后系统还能保留哪些能力。

因为真正决定产品能不能进入生产环境的，往往不是理想条件下能做到多高，而是会议变吵、人变多、距离变远、网络消失以后，它还能剩下多少能力。