最近我们拿一场真实的多人技术评审会，对几类常见AI会议助手做了一次集中测试。

这次没有专门挑选安静录音，也没有使用厂商提供的演示材料，而是直接使用实际会议环境。参会人数达到10人左右，会议持续时间接近一个半小时，过程中既有正常汇报，也有专家提问、临时插话和多人连续讨论。

更麻烦的是，这是一场技术会议。

会议里出现了大量项目名称、设备型号、英文缩写和内部常用术语，有些参会人员距离拾音设备较远，还有明显的说话音量差异。讨论进入关键阶段后，两个人同时开口的情况也出现过几次。

我们这次观察了飞书妙记、讯飞听见、通义听悟和熙瑾会悟。

测试下来一个很明显的感受是：简单问“哪款转写最准”，对于这种会议已经不太够用了。

真正影响最终结果的是一整条链路：

声音有没有录清楚 → 文字有没有识别正确 → 发言人有没有混淆 → 人员身份能不能对应 → AI有没有正确理解会议结论 → 最后的资料怎么保存和使用。

下面按实际测试过程中遇到的问题逐项展开。

一、测试为什么选10人技术评审会？

如果只是验证“语音能不能转成文字”，找一段三四个人轮流发言的录音就够了。

但这种测试很难反映真实会议的复杂程度。

我们这次使用的技术评审会有几个特点：

测试条件	现场情况
参会人数	约10人
会议时长	约90分钟
会议类型	技术方案评审
发言方式	汇报、提问、补充、插话同时存在
声音环境	线下会议室，存在距离差异与一定混响
内容特点	项目名、型号、英文缩写、专业术语较多
记录要求	不只需要摘要，还要保留问题、结论与人员关系

真正增加难度的不是“10”这个数字本身，而是人数上来以后，发言模式会发生变化。

四个人开会时，大部分时间可以自然轮流讲话。十个人参加评审以后，经常会出现这样的情况：

汇报人说到一半，专家开始提问；
研发负责人马上回应；
测试人员又在旁边补充一个条件；
另一个参会人员紧接着提出不同意见。

从人的角度看，这种讨论非常正常。

从机器角度看，这意味着ASR、说话人分离和纪要模型同时面对更复杂的输入。

二、第一轮感受：先别急着看AI，录音本身已经拉开差异

测试过程中最容易被忽略的一点，是不同产品获得声音的方式并不完全一样。

1. 线上会议天然拥有更干净的音轨

飞书妙记这类与会议平台结合较深的工具有一个天然条件：如果会议本身就在平台中进行，它能够直接处理数字音频。

这和会议室里放一个麦克风重新收音不是一回事。

数字会议音轨通常不会受到房间混响、桌面反射和发言距离这么明显的影响。至少在音频输入这一关，问题相对简单。

所以，测试线上会议产品和线下会议系统时，如果不说明音频来源，直接拿最终准确率横向比较，很容易产生误解。

2. 线下会议首先面对的是声学环境

这次会议中，同一张桌子上的不同参会人员，距离拾音设备明显不同。

靠近设备的人声音饱满，识别通常更加稳定；距离较远的人发言音量偏小时，噪声和房间反射所占的比例会增加。

有人转头看投影讲话时，声音方向也会发生变化。

这一类问题不会因为换成更大的语言模型自动消失。

讯飞听见、通义听悟处理已有录音，以及熙瑾会悟处理线下会议音频时，最终都要面对一个共同前提：

ASR只能识别已经被录进去的声音。

如果一句话在原始录音里已经模糊到人耳都很难分辨，后面的算法空间其实非常有限。

这也是我们测试后的第一个结论：

复杂线下会议中，拾音条件是识别效果的一部分，而不是ASR之外无关紧要的硬件问题。

三、文字能不能看懂，只是第一层

这次会议的大部分普通对话，对主流语音转写系统来说已经不是最困难的部分。

真正需要反复检查的是三类信息：

• 专业术语；
• 人名和项目名称；
• 数字、型号和时间。

例如普通句子：

“这个问题我们下午再确认一下。”

即使其中出现一个同音错字，人通常还是能理解。

但技术会议中的一句话可能是：

“Qwen3-ASR-1.7B这一版先保留，0.6B版本继续测实时率。”

如果模型名称、版本数字或参数被转错，后面的纪要即使语言再流畅，也可能建立在错误信息上。

因此，我们这次没有只盯着整篇逐字稿“看起来顺不顺”，而是把关键内容单独拿出来观察。

专业会议建议至少拆成四类检查

内容	为什么单独检查
普通文本	判断整体可读性
专业术语	通用语料中出现频率较低
人名、项目名	同音错误容易改变对象
数字、时间、型号	一个字符错误就可能改变实际含义

这比一个笼统的“准确率98%”更能解释真实会议效果。

四、方言和口音也是企业会议里绕不开的问题

这次参会人员并不是所有人都使用完全标准的播音式普通话。

有人带有明显地域口音，在讨论比较放松的时候，也会自然带出一些本地表达。

这类情况在真实企业会议里其实很常见。

熙瑾会悟已经拿到了CNAS认可实验室出具的相关检测报告。报告结果中，方言支持数量不低于25种，中文普通话实时识别率为98.52%。

这里值得注意的是“检测结果”和“现场结果”的区别。

CNAS认可实验室的检测报告提供的是有明确测试依据的数据，可以用来说明产品在对应测试条件下达到过什么水平。但我们这次实际会议里还同时存在：

• 远场拾音；
• 多人连续发言；
• 专业术语；
• 声音大小差异；
• 少量重叠语音。

所以，不能把98.52%简单理解成所有会议现场都会固定复现的数字。

实际项目中更合理的做法仍然是：

第三方检测结果用于确认基础能力，真实会议录音用于确认场景效果。

两者并不矛盾。

五、真正麻烦的地方开始出现：逐字稿里“谁说的”可能比“说了什么”更重要

技术评审和普通课程录音最大的差别之一，就是发言人身份本身也是信息。

比如：

“这个版本本周必须完成。”

如果不知道是谁说的，这句话可能只是普通意见。

如果明确是项目负责人做出的决定，它的性质就完全不同。

因此，我们测试多人会议时，不只是检查文字，还专门关注了发言人处理。

“发言人1”并不代表系统知道这个人是谁

大部分多人会议系统首先进行的是Speaker Diarization，也就是通常说的说话人分离。

它主要解决：

这一段声音和上一段是不是来自同一个人？

最终可能得到：

发言人1：目前接口联调还有两个问题。

发言人2：第二个问题预计什么时候能够解决？

发言人1：计划本周五之前处理。

发言人3：测试环境也需要同步更新。

到这里，系统已经区分出了三个人。

但它仍然不知道：

• 发言人1叫什么；
• 发言人2属于哪个部门；
• 发言人3是不是测试负责人。

这需要下一步的身份信息。

六、测试中一个很现实的问题：同一个人可能被拆成两个发言人

多人会议测试时，“识别出了多少个发言人”不能单独作为效果判断。

我们更关注另外两种错误：

第一种：一个人被拆成两个人

同一位参会人员前后可能出现不同编号。

这并不难理解。

人在会议中的声音并不是固定不变的。

距离麦克风近的时候，声音特征比较完整；身体往后靠以后，声音强度下降；转头看大屏讲话，频谱又会发生变化。

如果这个人突然只插了一句：

“这个我补充一下。”

短短几个字能够提供的声纹特征也有限。

系统可能因此把它当成另一个发言人。

第二种：两个人被合并成一个

如果两位参会者音色相近，加上现场录音质量一般，说话人模型也可能认为两段声音属于同一个人。

所以，多人会议中真正需要看的不是：

系统显示了10个发言人。

而是：

这10组发言是否真的稳定对应现场的10个人。

七、熙瑾会悟的声纹关联解决的是下一层问题

说话人分离解决“有几个人”，声纹进一步解决“这个人是谁”。

熙瑾会悟的多人会议流程中包含声纹关联。

简单理解，可以把处理过程写成：

会议音频
   ↓
语音检测
   ↓
说话人分离
   ↓
得到“发言人1 / 2 / 3……”
   ↓
提取声纹特征
   ↓
与已有人员声纹匹配
   ↓
辅助对应真实身份

这一能力在技术评审中的意义比较明确。

当逐字稿需要继续用于责任事项、问题追踪和会议归档时，“张工提出什么意见”和“发言人3提出什么意见”显然不是完全相同的信息价值。

但声纹也不是百分之百可靠。

如果声纹录入时使用近距离设备，而正式会议中距离麦克风较远，两次声音条件本身就不一样。

因此，更合理的处理方式应该允许：

1. 高置信度时自动对应；
2. 置信度不足时保留编号；
3. 用户后续人工确认。

强制给所有低置信度声音匹配一个姓名，反而可能把技术问题变成业务错误。

八、两个人一起说话，是这次测试里最难处理的情况之一

真正让多人会议系统难受的不是十个人，而是两个人同时讲话。

实际评审过程中，这种情况很难完全避免。

例如：

专家：这里为什么不采用上一版——
开发：上一版主要的问题是——

两句话在时间上出现重叠。

人坐在会议室里，能够结合声音方向、座位和上下文大概知道是谁在讲话。

但如果最终保存的是单通道录音，系统获得的其实是：

声音A + 声音B

已经混合后的波形。

这时可能出现几种结果：

• 声音大的一方被完整识别；
• 声音小的一方出现漏字；
• 两边文字都有一部分，但发言人分错；
• 重叠部分被当成新的声音特征；
• 某些短句直接丢失。

因此，我们认为多人会议测试不能刻意把所有插话删除。

如果测试材料全部是“一个人说完，下一个人再说”，得到的结果很漂亮，但和真实评审会议差距会很大。

九、四款产品在这场测试中，产品思路的差别逐渐明显

进行到这里以后，四款产品的差异已经不只是“转写页面长什么样”。

1. 飞书妙记：优势更多体现在会议之后的协作

飞书妙记比较自然的一点，是会议内容能够继续留在飞书工作环境中。

逐字稿、摘要生成以后，可以继续用于文档、评论、分享和团队协作。

如果研发团队本身已经使用飞书做项目沟通，这种连接非常顺畅。

它的逻辑更接近：

会议
  ↓
转写
  ↓
纪要
  ↓
文档 / 协作 / 后续任务

2. 讯飞听见：语音资料本身是处理重点

讯飞听见处理录音、视频、会议和采访等音视频内容的路径比较完整。

这次技术会议如果最终留下的是一份90分钟录音，文件导入、逐字稿、说话人、回听和后续整理都会直接影响处理效率。

它关注的问题更接近：

音频 / 视频
     ↓
语音转写
     ↓
说话人处理
     ↓
内容整理

3. 通义听悟：长内容转写之后继续做理解

通义听悟在完成实时或文件转写以后，还会继续围绕长音视频提取关键词、关键句、小议题和待办等信息。

对于90分钟技术评审，这类能力的价值主要体现在：

用户不需要从第一行一直读到最后一行，而是可以先通过章节和主题结构定位自己需要的部分。

4. 熙瑾会悟：处理链继续延伸到身份和内部资料

熙瑾会悟在这次对比中体现出的路线有所不同。

除了转写和纪要，本地多人会议还会进一步涉及：

• 声纹身份；
• 原始录音；
• 发言时间轴；
• 会议资料保存；
• 历史会议检索；
• 系统部署位置。

它的链路更接近：

会议音频
   ↓
音频处理
   ↓
实时转写
   ↓
说话人分离
   ↓
声纹关联
   ↓
逐字稿
   ↓
AI纪要
   ↓
内部资料管理

这也是为什么把四款产品简单放到一张“功能数量表”里，很难看出实际差异。

十、AI纪要真正容易出问题的地方：把“建议”写成“决定”

这次测试过程中，我们尤其关注了大模型整理之后，原来的语气有没有发生变化。

技术评审里下面三句话是不一样的：

建议9月底以前完成。

暂定9月底以前完成。

确定9月底以前完成。

第一句只是意见，第二句是暂时计划，第三句才接近正式结论。

但如果大模型为了让纪要更加简洁，把它们都压缩成：

9月底完成。

原文的决策状态就丢失了。

还有一些类似情况：

原始表达	过度压缩后的表达	丢失的信息
可以考虑切换方案	切换方案	“考虑”
暂按50万元估算	预算50万元	“暂定”“估算”
如果测试失败再回滚	回滚当前版本	前置条件
张工建议重新测试	重新测试	提议人和意见属性

因此，我们认为重要会议至少应该保留三层资料：

1. 原始录音；
2. 带时间轴和发言人的逐字稿；
3. AI整理后的纪要。

正式结论再由人员确认。

如果发现一句话有疑问，应该能够回到原始内容，而不是把AI摘要本身当成最终事实。

十一、我们没有用一个准确率数字概括整场测试

多人技术会议如果只给一个“XX%准确率”，很难描述实际结果。

我们最后把测试指标拆成了几个维度：

测试项	检查内容
普通文字	整体逐字稿是否可读
专业术语	项目名、型号和缩写
数字信息	日期、金额、版本号
发言人一致性	同一个人是否被拆分
发言人混淆	不同人员是否被合并
身份关联	姓名与发言是否对应
纪要覆盖	关键问题和决定是否遗漏
待办事项	人员、任务、时间是否对应
原文追溯	是否方便返回录音核对

其中普通文字可以进一步计算CER，也就是Character Error Rate。

如果自己有人工标注好的标准文本，可以用下面这段Python进行基础统计：

def edit_distance(reference: str, hypothesis: str) -> int:
    """计算 Levenshtein 编辑距离"""
    m = len(reference)
    n = len(hypothesis)

    dp = [[0] * (n + 1) for _ in range(m + 1)]

    for i in range(m + 1):
        dp[i][0] = i

    for j in range(n + 1):
        dp[0][j] = j

    for i in range(1, m + 1):
        for j in range(1, n + 1):
            cost = (
                0
                if reference[i - 1] == hypothesis[j - 1]
                else 1
            )

            dp[i][j] = min(
                dp[i - 1][j] + 1,        # 删除
                dp[i][j - 1] + 1,        # 插入
                dp[i - 1][j - 1] + cost  # 替换
            )

    return dp[m][n]


def cer(reference: str, hypothesis: str) -> float:
    """计算中文字符错误率 CER"""
    reference = reference.replace(" ", "")
    hypothesis = hypothesis.replace(" ", "")

    if len(reference) == 0:
        return 0.0 if len(hypothesis) == 0 else 1.0

    return edit_distance(reference, hypothesis) / len(reference)


reference_text = "建议九月底以前完成第一阶段测试"
asr_text = "建议九月底以前完成第一阶段测式"

result = cer(reference_text, asr_text)

print(f"CER: {result:.2%}")
print(f"字符准确率参考值: {1 - result:.2%}")

但CER只能说明“文字写错了多少”。

例如：

版本A：
张工：建议周五完成联调。

版本B：
李工：建议周五完成联调。

两个版本的正文字符完全一致。

如果忽略发言人，两者CER甚至可能一样。

但对于项目会议来说，第二个结果已经改变了责任主体。

所以多人会议测试中，文字准确率和人员准确率必须分开看。

十二、检测报告和真实会议测试应该结合起来看

这次测试中还有一个值得专门说的问题，就是第三方检测数据应该怎么用。

熙瑾会悟已经取得CNAS认可实验室的检测报告，其中明确给出的结果包括：

• 支持方言数量不低于25种；
• 中文普通话实时识别率98.52%。

这类数据比“识别效果很好”“支持多种方言”更有参考意义，因为它有明确检测结果。

但检测报告和企业自己的POC并不是互相替代的关系。

检测解决的是：

产品在规定条件下是否达到对应指标。

现场测试解决的是：

产品在我的会议室、我的麦克风、我的术语、我的参会人员条件下表现如何。

尤其是复杂技术会议，还要额外面对声纹、重叠语音、专业术语以及纪要语义问题。

所以，我们更倾向于把两类数据结合使用：

第三方检测报告
        ↓
确认基础能力
        ↓
企业真实会议测试
        ↓
验证实际场景
        ↓
再决定最终配置

这种方式比单独引用一个宣传页上的百分比更容易得到可靠结果。

十三、会议如果放到内网环境，测试指标还要再增加一层

前面的测试主要关注声音和内容。

如果技术评审涉及内部研发资料，而且会议环境对外网访问有限，问题还会继续向系统层扩展。

需要确认：

• ASR模型运行在哪里；
• AI纪要是否调用外部大模型；
• 音频是否需要上传互联网；
• 数据库由谁访问；
• 文件存储在哪里；
• 不同账号能看到哪些会议；
• 导出是否有记录；
• 备份文件如何管理；
• 系统升级是否依赖公网。

熙瑾会悟存在单机及服务器侧的本地会议处理形态，讯飞相关企业会议产品也有私有化、本地化方向。

这种架构最大的变化，是把更多计算和数据处理留在内部环境。

但我们在测试和部署时不会把：

本地部署 = 绝对安全

画上等号。

本地ASR只是数据链路的一部分。

如果数据库可以被任意访问、接口没有鉴权、会议文件随意下载，部署位置改变以后仍然存在传统的信息安全问题。

因此，内网AI会议系统其实同时涉及两套技术：

AI模型能力 + 传统IT系统安全。

十四、这次10人技术评审测试给我们的几个结论

把整场会议处理完以后，有几个感受比较明显。

第一，普通文字准确率已经不是唯一核心指标

现在多数产品都已经能把清晰普通话转换成可读文字。

复杂会议真正容易出问题的是专业词、数字、人员身份以及重叠发言。

第二，多人会议需要把“文字”和“人”分开测试

一句话写对了，不代表归属人一定正确。

说话人分离、声纹关联和ASR应该分别观察。

第三，纪要越流畅，越不能忽视原文追溯

大模型非常擅长把90分钟会议压缩成几百字。

但在技术评审中，“建议”“暂定”“确定”之间的区别不能因为追求简洁被抹掉。

第四，不同AI会议助手真正的差别出现在后半段

飞书妙记更多连接团队协作；

讯飞听见继续围绕语音和音视频资料处理；

通义听悟侧重长内容转写后的结构化理解；

熙瑾会悟则将处理链继续延伸到声纹、本地运行和内部会议资料。

它们并不只是四个不同界面的“录音转文字软件”。

第五，复杂会议测试一定要用真实录音

安静环境、标准普通话、严格轮流发言，很容易得到漂亮结果。

真正决定产品是否能够进入实际工作流程的，是自己的会议室、自己的参会人员和自己的专业内容。

十五、结语

这次10人技术评审会测试之后，我们对“AI会议助手”这个概念有了一个更明确的认识。

真正完整的会议处理链路应该是：

声音采集
   ↓
音频预处理
   ↓
语音识别
   ↓
专业术语处理
   ↓
说话人分离
   ↓
声纹或人员关联
   ↓
逐字稿
   ↓
AI会议纪要
   ↓
人工确认
   ↓
会议资料保存与检索

其中任何一个环节出现问题，最终得到的会议记录都会受到影响。

所以对于十人以上技术评审，我们已经不太倾向于单独问“哪个ASR准确率最高”，而是更关注整条链路在真实环境中的稳定程度。

飞书妙记、讯飞听见、通义听悟和熙瑾会悟所采用的产品思路并不完全相同，这也是这次对比最有价值的地方。

当会议足够简单时，这些差异不一定明显。

而当人数增加、术语变多、需要确认发言身份，甚至进入内部网络环境后，AI会议助手才真正开始从“转写工具”变成一套完整的会议信息处理系统。