用腾讯云语音识别打造会议纪要小帮手：录音转写、说话人分离全攻略

不开会不知道，一开会就发现人的耳朵其实没那么靠谱。连续两小时的远程会议，前半小时还精神，后半小时就开始走神，等反应过来，重点早就过去了。更要命的是，会后整理纪要这件事，谁做谁知道——回放录音、逐句听写、归纳决议，一份两小时的会议录音，整理出三千字纪要，普通人要折腾两三个小时。我就一直在想，能不能让AI帮我干这个活。后来用了腾讯云的AI语音识别做了一套会议小帮手，整场录音丢进去，转文字、分说话人、提取要点，基本都是自动化，我只负责最后校对一遍。这篇文章就把我完整踩过的坑、选型思路和可复现的方案分享出来，适合自己写脚本做自动化、又被会议纪要折磨得不行的开发者，也适合想了解语音识别到底能不能落地的产品经理。

1. 会议记录这个场景，到底需要什么样的AI帮手

1.1 先从最笨的需求聊起

很多人一上来就问我：你是不是要搞实时转写？就是那种会议开着，屏幕上字幕实时蹦出来的？说实话，最开始我也想做实时，后来冷静一想，真正常用的场景其实分两种。

第一种是线上会议。现在腾讯会议、钉钉会议里自带的转写功能已经很好用了，你根本不需要自己再造轮子。第二种是线下会议室。一堆人围着一张桌子，录音笔一放，或者手机往中间一丢，这种时候没有字幕、没有转写，会后只能靠人肉听录音。

我做的这个会议小帮手，核心服务的就是第二种场景：你只需要把录音文件丢给它，它会帮你把整段语音转成文字，并且尽量区分出是谁在说话。输出结果是一份带说话人标签、带时间戳的文本文稿。有了这份文稿，你再去提炼待办事项、会议决议，就轻松太多了。

这个需求听起来简单，但真正拆开了之后，你会发现有几个问题必须解决。

第一个问题：识别率。普通对话识别不难，但是会议里全是专有名词——项目代号、客户名、技术术语，甚至是一些英文缩写，默认模型大概率会认错。第二个问题：谁在说话。只有一段连续的文字，你不知道这句话是A说的还是B说的，那这份纪要的价值就大打折扣。第三个问题：长音频。一场会动辄一个小时以上，音频文件巨大，怎么处理才能不超时、不丢失数据。

这三点，其实就是我选型时最核心的判断标准。

1.2 技术拆解：录下来、转成字、还得认得出人

顺着上一节的问题往下捋，一个完整的会议小帮手，在技术层面无非是下面这四个环节。

采集端：需要一个能录音的设备。手机就行，不用专门的录音笔。转录端：把录音文件变成文字，这一步就是整套系统的核心引擎。分离端：识别出不同说话人的声音特征，把每一句话归到对应的人身上。整理端：输出带有说话人和时间信息的文本，再根据你的需要格式化成纪要模板。

前两个环节没什么好说的，关键在于第三个环节——说话人分离。

你可能觉得，区分两个人说话有什么难的？一个男声一个女声，一听不就分开了？但真实会议上，两三个人都是同性别、音量相近、语速相近，甚至同时抢话的时候，区分度会急剧下降。腾讯云语音识别里有一项功能，专业术语叫说话人分离，也就是声纹级别的区分，它会根据说话人的音色特征把音频切成不同的角色段，然后标上Speaker ID。这项能力对于会议纪要而言，是真正能节省人工的部分。

所以我的结论是：这个项目不需要过度设计，核心就是"一段音频进去，一段分好人的文字出来"。在此基础上再考虑热词、标点、数字格式化这些细节优化，而不是一开始就去搞前端界面、实时流式识别，那样只会让项目的复杂度飙升，实用性却没有明显提升。

2. 腾讯云语音识别到底怎么选，这几个参数别搞错

2.1 三种接口，会议场景先用哪一个

腾讯云语音识别并非只有一个接口。我当初打开文档的时候也愣了一下，接口名字太多了，什么一句话识别、实时语音识别、录音文件识别，看起来都差不多，实际上适配场景完全不同。

一句话识别：适合语音短搜索、语音输入这种极短音频，一段话在60秒以内。实时语音识别：适合直播字幕、实时会议转写这种需要边说边出字的场景，有配套的WebSocket接口和流式音频处理。录音文件识别：适合录音文件转写。音频时长可以到5小时，文件大小上限是500MB，支持录音文件上传后异步识别、回调结果。

会议小帮手用哪个？答案已经写得很清楚了：录音文件识别。

为什么不用实时识别？因为线下会议结束之后才去整理，没有实时出字的必要，实时识别反而要处理音频流的分帧、发送、连接保持，代码复杂很多，还把服务器网络的稳定性也牵扯了进来。用录音文件识别就有个好处：提交任务、等回调、拿结果，整个流程可以做成完全异步的，哪怕音频再长，也不用担心长时间占用连接。

三种接口对比一下，你就能看得更清楚：

我实际用的就是第三类，录音文件识别。它解决了我最核心的痛点：一次性丢进去一个两小时的录音，然后我就可以去干别的，等到它回调通知我结果出来了，再去拿数据。

2.2 真正决定识别效果的几个参数

如果你准备调用接口，会发现创建任务时有几个参数特别容易踩坑，我挨个说。

第一个是引擎模型。腾讯云的录音文件识别有多个引擎模型，常见的有16k_zh_video、16k_zh_asr等。16k表示音频采样率16kHz，zh是中文，video和asr对应不同的优化场景。我实测下来，电话录音用电话模型效果好，普通会议录音用16k_zh_video效果要更好一些，因为视频会议和线下会议的录音经过麦克风采集，声音特性和电话信道完全不同。但这个参数很多人不调，直接用默认，结果识别率不高还找不到原因。

第二个是说话人分离开关。有一个参数叫EnableSpeakerDiarization，默认是不开的。你需要把它打开，同时还要设置一个SpeakerNumber，也就是说话人的预估人数。这里有个经验：宁可把这个数字设大一点，设成4、5，也不要设成2。因为实际会议总有意外——某个人插了一句话、主持人偶尔客串，这些额外的声音如果你预估人数太少，会被强行合并到已有的Speaker里。设大一点，哪怕最后实际的SpeakerID比预估人数少，也不会出大问题，最多就是某些角色是空的。

第三个是热词表。这个我之前完全没想到，后来才发现它才是提升会议识别率的隐藏神器。你可以上传一个热词表，每个热词配一个权重，数值越大，模型就越倾向于识别成这个词。例如你们的项目代号、产品名、用户专有名词，全部塞进去，效果立竿见影。

第四个是音频格式。录音文件识别支持wav、mp3、m4a等主流格式，还支持base64数据提交。但有一点要注意：声道、采样率这些信息如果你不确定，建议把音频先转成wav格式、16k采样率、单声道。为什么是16k？因为中文识别模型大多在16k采样率上做了优化，你用48k的原始音频直接上传，云端会做降采样处理，理论上没问题，但偶尔会引入一些不可控的失真。我自己就遇到过m4a格式传上去一直报错的情况，转成wav之后一次就过了。

2.3 为什么说话人分离是会议纪要的核心

没有说话人分离的文字稿，说到底就是一篇没有标点的大段文字，看完还得猜"这句话是谁说的"。有了说话人分离，出来的结果长这样：

[0] 开发者A 00:01:20 - 00:01:35 这个需求这周必须确认下来，不能再拖了。 [1] 开发者B 00:01:36 - 00:01:58 我这边接口已经准备好了，就差前端联调。

这种格式才能直接落到会议纪要里，不同的发言人在后面讨论的时候才能被区分对待。

但说实话，这个功能并非完美。它本质上是通过声纹聚类实现的，如果会议室里两个人的声音实在太像，或者背景噪音很大，还是会出现错标的情况。不过，至少比完全没有分开要好得多。而且这个特性一旦打开，你不需要做任何额外的模型训练，直接在接口参数里设置两个字段就能启用，这对小成本工具来说就是白嫖福利。

3. 手把手搭一个最小可用的会议小帮手

3.1 整体链路图：从录音文件到会议纪要

我再强调一次，这条链路不需要很复杂。很多教程上来就让你搭前端页面、加数据库、做用户登录，我反而不建议这么做。最小可用版本，就三步。

第一步，录音文件准备好。这一步虽然在系统外，但出问题最多，后面我专门写。第二步，调用录音文件识别接口，提交一个异步任务。第三步，轮询或等待回调，拿到转写结果，清洗成你要的格式。

整个项目从开始写代码到跑通，我用了一个晚上加一个早上。如果你之前写过Python，其实只花一个下午就能搞定。

3.2 用Python快速调用录音文件识别

说下具体的调用方式。我用的Python，因为腾讯云官方有现成的SDK，不用自己去拼请求签名。

先安装SDK：

pip install tencentcloud-sdk-python

然后创建一个客户端。这里要填你的SecretId和SecretKey，直接在控制台的API密钥管理里创建就好。

from tencentcloud.common import credential from tencentcloud.common.profile.client_profile import ClientProfile from tencentcloud.common.profile.http_profile import HttpProfile from tencentcloud.asr.v20190614 import asr_client, models # 密钥建议用环境变量传入，不要硬编码在代码里 SECRET_ID = "你的SecretId" SECRET_KEY = "你的SecretKey" cred = credential.Credential(SECRET_ID, SECRET_KEY) http_profile = HttpProfile() http_profile.endpoint = "asr.tencentcloudapi.com" client_profile = ClientProfile() client_profile.httpProfile = http_profile client = asr_client.AsrClient(cred, "ap-guangzhou", client_profile)

创建任务时，关键参数如下。其中EngineModelType选16k_zh_video，EnableSpeakerDiarization打开，SpeakerNumber设成你预估的人数，ChannelId是声道编号。

req = models.CreateRecTaskRequest() req.EngineModelType = "16k_zh_video" req.ChannelId = 1 req.SourceType = 0 # 0表示URL，1表示Base64 req.Url = "https://你的存储桶/meeting_20250101.wav" req.EnableSpeakerDiarization = True req.SpeakerNumber = 4 req.FilterPunc = False # 保留标点，方便阅读 resp = client.CreateRecTask(req) task_id = resp.Data.TaskId print("TaskId:", task_id)

这里有一个特别要注意的点：SourceType。如果是0，表示你传的是一个可公网访问的URL；如果是1，表示把音频的Base64内容直接放进请求里。Base64方式适合小文件，大会录音动辄几百MB，你把它编码成Base64塞进POST请求，不仅让请求体巨大，还容易超时。我强烈建议：先把音频传到COS或者任意对象存储桶，拿到URL再提交任务。

我一开始用Base64方式传了一个40分钟的录音，结果等了很久都拿不到结果，后来才发现问题就出在请求上。排查了半天，最后改成传URL，几秒钟就提交成功了。

3.3 等待结果，处理转写数据

提交任务之后，有两种方式拿结果。第一种是轮询——每隔几秒去查一次任务状态。第二种是回调——创建任务时填一个回调URL，处理完成之后腾讯云会往这个URL上POST结果。本地开发没有公网回调地址的话，用轮询是最省事的。

查询结果的代码也很简单：

import time req = models.DescribeTaskStatusRequest() req.TaskId = task_id while True: resp = client.DescribeTaskStatus(req) status = resp.Data.Status if status == 0: print("任务正在处理中...") time.sleep(5) elif status == 1: print("任务处理成功") print(resp.Data.Result) break else: print("任务处理失败") print(resp.Data.ErrorMsg) break

这里的状态值要记住：0是排队中或处理中，1是成功，2是失败。成功之后，Resp.Data.Result就是一个JSON字符串，里面包含了完整的转写结果和说话人信息。

我一般会把这个JSON里的数据整理一下，变成更容易阅读的格式。核心的数据结构大概是这样的：Result里有一个Utterances数组，每一个Utterance包含StartTime、EndTime、SpeakerId、Text。你只需要遍历一遍，拼成"说话人ID加文本"的形式就OK。

import json result = json.loads(resp.Data.Result) utterances = result.get("Utterances", []) for u in utterances: speaker = u["SpeakerId"] start = u["StartTime"] text = u["Text"] print(f"[说话人{speaker}] ({start}s) {text}")

就这么简单。把这份文本往纪要模板里一贴，一份初稿就出来了。

4. 实测中的典型坑和排查思路

4.1 识别结果乱码、丢字，先别急着骂模型

我第一次拿到识别结果的时候，发现里面有一句莫名其妙的乱码。后来仔细对比音频，发现是演讲者突然切换成英文单词，模型把它识别成了看似乱码的中文近似音。

这类问题第一排查方向是引擎模型有没有选对，第二是音频本身是否有严重压缩。我有个朋友用微信语音转存下来的录音，格式是sicp的加密格式，转成mp3之后音质很差，识别率直接掉了三成。后来我把语音编码重新转一遍，码率拉到128kbps以上，情况才好转。

这个经验很重要：音频源的质量，决定了识别的上限。你模型参数调得再花哨，源文件一团糊，结果也救不回来。

4.2 说话人分离不准，SpeakerID错乱

出现这种问题，多半是SpeakerNumber设定了不合适的值。例如实际只有两个人开会，你把预估人数设成了8，模型就会把同一个人的不同句强行拆成两个甚至三个角色。

解决办法是通过观察结果动态调整。先设一个相对合理的值跑一遍，数一下最终输出里出现了几个SpeakerID。如果发现同一句话被拆给不同角色，下一次就调大人数阈值；如果发现两个人被合并成一个人，就调小阈值。这个参数没有绝对正确，只能在你的具体场景里试。

这里有个小技巧：提前把每个人的发言片段截出来，单独提交到一句话识别，看能不能稳定识别出同一人声纹，这样可以在正式跑之前做一些检验。

4.3 音频太长、任务失败、回调超时

录音文件识别单任务最大能接受5小时的音频，听起来很长，但真要传一个3小时的会议，还是会遇到文件体积过大的问题。有一个隐藏的限制：URL方式上传的音频文件，大小不能超过500MB。

有一段时间我的录音全是48kHz、双声道、无损格式的wav，两小时的会议跑到800多MB，死活过不去。后来我把音频批量转成16kHz、单声道wav，大小直接缩到原来的五分之一。

还有一个细节：如果你把音频放在自己的服务器上做URL提交，要确保这个URL能被腾讯云的服务器访问到。我自己本地开发时用内网IP生成的URL，控制台一直提示下载音频失败，后来才知道必须用公网可访问的URL。处理办法很简单，把文件丢到COS上，生成一个临时链接填进去。

4.4 标点和数字格式问题

腾讯云识别返回的文字，默认带标点，数字默认转换成阿拉伯数字。但如果你用的是某些特定模型或者关了标点符号选项，结果就会变成一坨连续的文字。这种文本直接拿去排版，根本没法看。

处理方式有两个：一是创建任务时设置FilterPunc为False，让它保留标点；二是用一些文本处理脚本，把常见的中文标点统一格式化。这个不算技术难点，但到了输出环节特别影响观感，需要提前规划好。

另外要注意，会议中出现的专业术语，比如"CQRS""K8s""DevOps"，模型经常把大小写搞错。我最后是写了一个简单的字典替换脚本，把这些词在输出之前强制统一成标准写法。这个属于锦上添花，但确实让结果看起来专业很多。

5. 成本、效果，以及这套小帮手还能怎么扩展

5.1 钱真没花多少，学会按量计费

很多人以为AI语音识别很贵，其实用起来我算过一笔账：录音文件识别是按录音时长计费的，一场一小时的会议，花费在几块钱这个量级，也就是一杯饮料钱还不到。当然，具体价格要按官方定价页为准，不同区域和模型会有一点差异。

而且这个服务是按量付费的，每个月用几次就付几次的钱，不需要预付费，也不用担心闲置成本。我自己是平时不开，月底统一把积累的录音文件跑一遍，一个月的会议纪要成本摊下来非常低。相比的人工整理的时间成本，这个投入很值。

省钱还有个土方法：会议中途如果有明显地长时间没说话的片段，比如中场休息、大家各自看手机，先手动把这段时间剪掉再提交任务。音频短了，钱就省了，识别速度还快。

5.2 提升识别效果的几个土办法

如果你的录音环境比较复杂，有几个偏门技巧值得一试。

第一，给录音做预处理。很多录音有底噪、有轻微的电流声。我在上传之前会先用音频处理工具做一遍降噪，把静音部分压缩掉，识别率会肉眼可见地提升。

第二，准备一份针对项目的高频词表。我之前提到过热词表，这个一定要用起来。会议里老板最喜欢说战略、复盘、OKR，还有项目代号，你把这些都加权，模型就会乖乖听你的。权重不是越高越好，我一般设5到10之间，太高的权重反而会强制匹配，把本该识别成其他词的地方强行替换掉。

第三，长音频可以考虑分段提交。虽然录音文件识别支持长音频，但单次任务识别时间越长，等待时间也越长，出错时排查难度也更大。我遇到过一次整段音频只有一个地方识别有误，但整个任务失败，重新跑一遍要等很久。改成按篇章分段提交之后，哪段有问题就重跑哪段，效率立刻上来。

5.3 后面还能怎么扩展这套系统

当前这套方案只能做到"转出来"，如果你想让会议小帮手更完整，有几个方向可以做。

一是自动生成会议纪要摘要。转写出来的是全文，我们真正需要的是结论。可以接一个大语言模型，把带说话人的转写结果投喂进去，让它自动提炼出参会人、讨论事项、结论、待办事项。这一步我在后续版本里接上了，效果很不错。

二是自动把录音内容归档到知识库。会议转写稿是一种很有价值的资料，可以按日期、项目打好标签，放进企业内部的知识库，以后谁忘了什么事，一搜就能搜到当时谁说的。三是和日历系统打通，会议结束两小时后自动给参会人推送一份纪要邮件。这一步做出来之后，这个工具才真正算得上是一个"帮手"。

但这些都是后话，如果你是从零开始，建议先把最核心的"录音转文字、分说话人"这一步跑通，其他的锦上添花功能，等到实际使用有需求了再慢慢加。

我在实际使用中发现，整个项目最让我意外的并不是识别准确率，而是"异步处理"这个设计给工作流带来的改变。提交完录音之后，我完全可以先去干别的，等结果好了再回来看。这种体验比实时转写更符合会议纪要整理的实际节奏。如果你也被会议纪要折磨过，不妨照着这个方法搭一个试试，几个小时就能搞定，成本也很低。