会议纪要自动化：语音识别与说话人分离的工程实践

上周三下午的产品对齐会，我又一次体会到“开完了等于没开”的痛苦：会上关于上线时间的讨论来回拉扯了十分钟，我低头记了两笔，再抬头的时候，大家已经默认达成了新结论。第二天对需求才发现，三个人记得的版本都不一样。这种场面我遇到太多次了，所以干脆给自己做了个“会议小帮手”：把会议录音交出去，用腾讯云AI语音识别转成文字，再按说话人拆开、清洗、整理成带结论和待办的纪要。整个过程由几个脚本自动跑完，现在每周能省下我两三个小时的整理时间。

这篇文章就聊聊我完整跑通这个项目的思路，包括选型、配置、接入和踩坑。如果你也经常开会、需要快速产出会议纪要，或者单纯想把语音识别能力接进自己的工具链，可以照着这条路径重新走一遍。我不打算把文档复述一遍，只讲实际操作中真正影响结果的部分，以及那些文档里不会写清楚的事。

1. 先搞清楚会议音频为什么这么难识别

1.1 手机输入法的听写，为什么一到会议室就失灵

很多人第一反应是：语音转写不是手机输入法就有吗？拿这个录会议不就行了。我试过，效果很一般。原因是输入法的听写是为“单人近讲”设计的：麦克风离嘴近、背景干净、没有第二个人同时说话。会议室完全相反——人坐在桌子对面，声音经过房间反射才到麦克风；空调、键盘、翻页声全是噪声；你说话的同时，隔壁同事可能也在发表意见。三种情况叠加，听写出来的文字经常缺胳膊少腿。

更麻烦的是中文同音词特别多。“灰度发布”和“回读发布”在语音上几乎一模一样，模型没有上下文提示时很容易选错。加上各种服务代号、客户名、项目代号，这些词压根不在常规词表里，识别出来基本是错别字大集合。第一次拿原始转写结果去对会议录音，我差点以为自己开了一场外星人会议。

1.2 会议音频真正的难点：多人、口音、口语填充

后来我把需求重新定义了一下：会议小帮手不是要“把声音变成字”，而是要“把一场多人讨论变成一段可阅读、可执行的结构化文本”。这决定了技术方案的选择，也决定了后面所有处理逻辑的方向。

瓶颈主要在三方面。第一是多人说话，至少得知道哪句话是谁说的，纪要才有意义；第二是口音和语速，不同人发音习惯差很多，同一个词在不同人嘴里听感完全不同；第三是口语填充词，“嗯”“那个”“就是说”“对吧”，这些东西在转写结果里全都会留下来，直接交出去没人愿意看第二眼。

所以，不能拿一个单纯的语音识别接口就完事。音频前处理、说话人分离、文本后清洗，缺一环都撑不起“小帮手”这三个字。先把问题拆到这一层，后面的技术选型才不容易跑偏。

2. 两条技术路线：实时流式还是录音文件识别

2.1 实时流式识别：适合字幕场景，但不适合第一版

如果需求是“会议大屏上实时出字幕”，那必须走实时语音识别：音频数据一边采一边往服务端推，识别结果以短句为单位回来。这个方案体验最好，但工程量也最大。要维护一个长连接，处理断线重连、音频分片、说话停顿检测、消息粘包，一堆事。我第一版试过一阵子，发现项目还没跑完，光调连接稳定性就花了大半时间。

不是说它不好，而是它解决的问题和“会议纪要”不一定匹配。实时字幕很酷，但开会时没人一直盯着屏幕看，会后大家要的是整理好的结论。第一版把工程重心放在实时链路上，性价比不高。

2.2 录音文件识别：把整段音频一次性交出去

后来改成录音文件识别的思路：等会开完，把完整录音或录音文件链接一次性提交到服务端，服务端异步处理，我隔几秒查一次状态，处理完把整段文字连同说话人信息、时间戳一起拿回来。

这个方案实现简单很多，不需要保持长连接，也不用考虑断线。我甚至可以直接拿手机录音，或者把视频会议的录制文件导出来丢进去，跑完再统一处理。对于“会后出纪要”这个场景，这套路完全够用。

2.3 选型判断：先解决有没有，再解决实时

我的判断标准只有一条：会议纪要需要多快产出？从实际体验讲，会议结束十分钟内能看到整理好的纪要，已经完全能接受。现在大家用文档协作，也没谁要求刚闭会就出逐字稿。真有大屏实时字幕的需求，那再考虑实时流式，两个路线的定位本来就不同。

两种方案差在哪，我整理了一个直观对比：

我选后者不是因为它高级，是因为它能让我在一个周末内把项目跑通。先解决有没有，再追求好不好。

3. 决定识别精度的五个配置项，全都在服务端调

很多人以为语音识别的精度是“模型说了算”，自己只需要把音频丢上去就行。实际用下来，影响准确率的变量特别多，而且大部分是配置层面的，调对了事半功倍。

3.1 音频采样率和格式：原料不对，后处理白费

开会用的手机录音可能是48kHz的立体声，但语音识别服务通常按8kHz或16kHz处理。这里有个声学常识：人的语音主要能量集中在300Hz到3400Hz，16kHz采样已经有很大余量，不需要把48kHz的原始文件原封不动传上去。

最佳做法是提交前统一转码成16kHz、单声道、wav或pcm格式。mp3也行，但压缩格式在不同码率下表现不稳定，我是先把视频会议导出的m4a用转码工具压成16k wav再提交。这一步做不好，后面所有配置都白搭，因为模型拿到的“原料”就是残缺的。

3.2 引擎模型选择：普通话、中英混说、电话线路不是同一个引擎

语音识别服务一般按场景区分引擎模型，电话8k、通用16k、英文、中英混说这些各有对应。会议场景用通用普通话16k基本够。但如果团队会议里密集出现英文产品名，比如“API网关”“KPI对齐”“SLA”，那建议确认一下引擎对中英混说的支持情况。

模型选错不会报错，只是准确率默默变差，这个最隐蔽。我一开始觉得“普通话识别都一样”，结果发现英文缩写识别得一塌糊涂。回头查了文档才意识到，不同引擎的词汇覆盖差异比想象中大。

3.3 说话人分离：不开这个，纪要和转写文本没区别

如果不开说话人分离，你会拿到一整段糊在一起的大文本，根本还原不了谁说了什么。开启之后，结果里每个句子会带上说话人编号。这个功能在多个人离麦克风距离差不多的小会议室里效果比较好；但如果有人离麦特别近、有人特别远，分离效果会打折扣。

有些人可能觉得“我只要全文关键词，不需要分人”。真做出来就会发现，没有说话人信息的纪要价值直接腰斩。谁承诺了什么事、谁提出反对意见、谁负责跟进，全凭人肉去猜，那不如不自动化。

3.4 智能标点和数字转换：让机器学会断句

语音识别默认丢出来的是一串不带标点的字符流。“我们讨论一下这个需求然后下午发布”这种文本，手机上看都费劲。开启智能标点之后，模型会根据语义给句子断句，这是给后处理铺路的基本操作。

数字转换也建议一起开。会议里“三百二十五”“两点四十五”这类表达很常见，转成“325”“2:45”之后，写待办、填排期都方便。别看这些都是小功能，它们决定了转写出来的东西是“给人看的”还是“给机器看的”。

3.5 热词表：专有名词识别差的最后防线

最影响会议纪要质量的是姓名、项目名、客户名这些专有名词。通用模型不认识“妙音脑图”这种内部项目代号，也不认识“灰度发布集群”这种组合词。解决靠词表（热词）：把这些词汇整理成列表上传，识别时会优先匹配。

我第一次跑没有词表，人名识别正确率大概六成，加词表之后能到接近九成。但注意，词表不是越长越好。权重给太高，模型会把正常语句往词表上硬拽，产生错误匹配。我的实践做法是：先跑一版不带词表的结果，把高频错误词收集起来，再开第二版。同一份录音跑两遍，第一遍当“探路”，第二遍才出正式结果。

4. 走通录音文件识别的完整链路：鉴权、提交、轮询、解析

接口文档看着不复杂，真接起来每个环节都有隐藏细节。

4.1 密钥和鉴权：最容易栽跟头的环节

使用服务前需要准备API密钥。签名算法看着繁琐，本质就是按规则拼字符串再计算消息认证码。我最开始图省事直接用官方SDK，把密钥配置放在服务端环境变量里，少踩了很多手动拼签名的坑。

强烈建议密钥只放在服务端，不要写进客户端脚本，权限范围能缩就缩。我之前见过有人把密钥写死在手机App里，结果反编译直接被扒出来，流量被别人刷走，账单看得人心疼。这个跟技术能力无关，纯粹是安全意识。

4.2 提交音频：URL方式比本地数据方式更好排查

录音文件识别支持直接传文件内容，也可以先放到对象存储拿临时URL，再让识别服务去拉。我用的是URL方式：录音先传到对象存储，生成几个小时有效的链接，提交后服务端自己拉取。

好处很明显：提交接口瞬间返回，而且万一识别失败，可以确认不是上传数据的问题，直接去查音频文件本身。传本地数据的方案在音频一大就很容易超时，排查链路还多一环。项目第一版求稳，能把问题拆开就别揉在一起。

4.3 结果轮询：频率、超时和状态判断

提交成功后会拿到一个任务ID，之后就是轮询。查询接口根据状态判断结果是否就绪。这里有两个容易踩的坑。一是轮询间隔别太短，一开始1秒，失败或未完成就翻倍退避，最多10秒一次；二是要区分“还在处理”和“彻底失败”，失败了一般会带错误码和描述，该放弃就放弃，别傻等。

我当时写轮询逻辑的时候加了一个超时上限，比如音频时长的三倍，超过就告警。这样即使服务端卡住，我这边也不会无限挂下去。这种防御性习惯，做工具类项目尤其重要。

4.4 解析返回：说话人、时间轴、文本对齐

返回结果里，全文文本是一份，还有个更细粒度的结果：每个句子带说话人编号、起止时间、词级时间信息。简化结构大概是这样的：

{ "TaskId": "example-task-id", "Status": 2, "Result": "整段会议全文文本...", "ResultDetail": [ { "SpeakerId": 1, "StartTime": 3000, "EndTime": 8200, "Text": "咱们把灰度发布推到周四", "WordInfo": [] } ] }

解析逻辑很直接：按说话人编号把句子分组，按时间排序，重组出“谁在什么时间说了什么”。到这一步，我手里已经有了一份带角色和时间轴的逐字稿，下一步才能做清洗和纪要生成。如果拿不到这一步的细粒度数据，后面很多处理都无从下手。

5. 四十分钟会议实测：处理时长、准确率提升，以及我踩过的五个坑

理论讲再多，不如跑一次真实会议。我拿一场四十分钟的四人需求会做了测试：手机录音转16k wav，提交后大概三到四分钟拿到完整结果，速度完全可接受。准确率不好给一个绝对数字，因为不同会议差异太大；但就这一场而言，加入热词后的人名和项目名识别率提升非常明显，正文语义基本可用。

过程里我记下了五个实打实的坑，每一个都花了不少时间排查。

5.1 坑一：签名时间戳对不上

第一次调用，签名用的时间戳和请求时间对不上，服务端返回鉴权失败。这类问题常见于服务器本地时间不准，或者代码里取了缓存的时间戳。方案是让服务器定期做时间同步，签名时重新生成时间，不要复用上一次的值。

5.2 坑二：音频格式声明与真实数据不符

转码之后忘了改参数，实际文件是44.1kHz立体声，提交参数里却写了16k单声道，结果识别出来一段乱码。这个坑特别低级，但特别容易犯。解决方案就一条：提交前自己把要传的音频真实信息打印出来核对一遍，别相信记忆。

5.3 坑三：轮询太频繁触发限流

一开始我图快，写了个死循环每秒查一次，结果没查几次就开始报错。后来改成指数退避：1秒、2秒、4秒、8秒，封顶10秒。实测下来，完成时间几乎没有变化，但接口稳定多了。做集成的时候，对别人服务的压力要有点同理心，公共接口不是给你一个人刷的。

5.4 坑四：说话人分离把人“拆”成了两个

有段讨论是两个人同时开口，结果其中一个人的声音被分给了两个说话人编号，变成了“两个人”在对话。这不是功能故障，是声学特征混淆：当两个声音在频谱上重叠太多，分离模型确实分不清。

应对策略是降低预期：开启分离，但不把它当精准答案。特别是多人抢话的激烈讨论段，后面人工扫一眼基本能还原。想完全自动正确，现阶段不现实。

5.5 坑五：标点导致句子语义错位

自由讨论阶段，说话人逻辑跳跃，标点模型把陈述句插成了疑问句，导致后处理抽取“待办”时漏了一半。这个问题的根子在于标点本身就是模型推测的，不能当真实语义边界来用。我后来在后处理里明确：标点只用来断行，不参与语义判断，真正抽待办靠关键词线索。

6. 转写文本不等于会议纪要：后处理才是让小帮手真正实用的部分

哪怕识别再准，原始转写文本直接发给同事，大概率会收到一句“这是啥”。转写只是第一步，后面的清洗和结构化才是“小帮手”这个名字的由来。

6.1 口语清洗：把“那个”“就是说”清掉

原始转写里有大量填充词和重复：“就是说”“嗯”“那个”“对吧”“我再补充一下”。这些词不删，文档篇幅至少膨胀三分之一。我用一个简单的清洗脚本处理：定义口语停用词表，按句清洗，保留主谓宾结构。

同音字错别字也要处理，比如把“回读”改成“灰度”，“妙音”改成“妙音脑图”。这个环节依赖词表，和前面的热词是同一个词表，识别和后处理共用一套词汇维护体系，省了很多事。

6.2 说话人映射：Speaker 0 到底是谁

说话人分离只输出编号，不告诉你编号对应谁。做法是我在会议开始环节加了一个固定流程：让每个人依次念一句“我是某某”。脚本检测头部音频的说话人编号，自动建立编号到真实姓名的映射。如果会议录音没有这个开头，就只能在纪要里用“发言人A”“发言人B”代替，可读性差很多。

6.3 纪要结构化：结论、待办、负责人、时限

清洗完文本，我用规则引擎抽结构。规则很简单：包含“推进”“需要”“记得”“跟一下”“周五前”“下周二”这类线索的句子，提取出来作为待办；包含“定了”“确认”“结论是”“同意”的句子，提取出来作为结论。

输出成一个简化的Markdown纪要：

# 需求会对齐纪要（某月某日） ## 议题与结论 - 灰度发布日期：推到周四 - 客户端发版策略：跟灰度走 ## 待办 - A负责灰度配置，周四上午前完成 - B整理变更清单，周三下班前同步 - C确认回滚预案，周四发布前评审

先做到这个程度，已经能覆盖大部分团队的日常需求。之后如果要更智能的摘要，可以再接大模型做长文本压缩，但第一版先把规则做扎实，成本和可控性都可接受。

6.4 一轮完整的输出体验

现在我的流程是：会议结束后把录音丢进脚本，几分钟后拿到一份带议题、结论、待办的Markdown文档，直接贴到团队文档里。从前整理一次纪要要半小时起步，现在基本零成本。

写到这里，我想到第一次用这个小帮手跑完整流程的时候：会议结束后去倒了杯水，回来就看到文档里已经躺着一份像模像样的纪要。那一刻确实有点成就感。如果你也想做一个类似的工具，我的建议很直接：先走录音文件识别，把整个链路跑通，再考虑实时字幕。识别不是旅程的终点，把文本变成别人愿意读的纪要才是。后面我打算把历史会议的纪要攒起来，做一个简单的检索入口。这个小东西，现在已经成了我每周离不开的伙伴。