腾讯云AI语音识别：自动生成会议纪要的实践与调优

我们每次开会一小时，纪要却要整理半小时，这句话我从不止一个团队嘴里听到过。会议内容总要有人记，记完还要提炼待办、确认负责人，稍微复杂一点的讨论，光靠人工回忆很容易漏掉关键信息。所以这两年我一直建议有条件的团队试试用腾讯云 AI 语音识别给会议加一个“自动记录助手”：会议开始录音，结束之后由程序把语音转成文字，再自动整理成会议纪要、待办事项和责任人清单。这篇文章就把我从需求拆解、方案选型到接口接入、调优避坑的整个实践过程梳理一遍，给想搭类似系统的同学一份能直接上手的参考。

1. 会议小帮手到底解决什么问题

1.1 开会半小时，整理三小时——痛点在哪

我见过很多团队的会议流程是：开会时一个人兼职记录，会后凭记忆和零散笔记补一份纪要，再发到群里让大家确认。这套流程听起来简单，实际执行起来问题非常多。

首先是记录不完整。讨论到后半程，记录员自己也在参与讨论，手一停，关键结论就漏了。经常出现两种结果：要么纪要写得太粗，只有结论没有依据，过两周再看不知道当时为什么这么决定；要么纪要写得太细，把口语化的重复表述也原样搬进去，读起来像一盘散沙。

其次是待办跟踪困难。会议强调要推进的事情往往有好几件，散落在不同段落里，人工提炼全靠眼力和记忆力。漏掉一条待办，可能就是某个环节多拖延一周。更麻烦的是，很多人开完会之后不会主动回看纪要，等下一次开会才发现上次的结论和这次对不上。

还有就是追溯成本高。项目做到一半起了争议，想翻出三个月前某次会议的原话，翻聊天记录和文档根本找不到，因为没人把当时完整的发言记下来。录音倒是可能有，但整段音频没有索引，想定位一句话得从头听，非常浪费时间。

所以会议小帮手要解决的其实不是“记不记”的问题，而是“记得全、找得到、能跟踪”的问题。用 AI 语音识别把整场会议的语音变成带时间轴的文字底稿，再在这个底稿上做待办抽取和关键词检索，一套流程下来，会议记录就从负担变成了资产。

1.2 腾讯云 AI 语音识别能做什么

腾讯云 AI 语音识别（ASR）起的作用是把音频转成文字。官方把它分成两大类：实时语音识别和录音文件识别。实时版本适合边说话边出字，可以接麦克风或网页端做字幕；录音文件识别适合上传一整段会议录音，异步返回结果，对时延要求不高。

对我做会议助手来说，核心能力有这几块。

一是长音频支持。单次录音文件识别的时长上限足够覆盖绝大多数会议场景，不需要把整场会议切成十几段手动处理，接口内部会自行处理长音频的分片和拼接。

二是说话人分离。多个人轮流发言时，可以在转写结果里标注这句是哪个人说的。它并不是靠人脸或声纹识别身份，而是把音频里不同声音特征区分开，返回 SpeakerId，同一个说话人在同一段音频里会被尽量归到同一个编号下。

三是带时间戳的词级别结果。不仅返回整句话，还能返回每个词或每个字对应的开始时间、结束时间，这个特性对后续做关键词定位、视频字幕对齐非常有用。

四是自定义热词。业务里常出现的公司名、产品名、专业缩写，可以在热词表里提前配置，识别时会优先往这些词上面靠，准确率提升比较明显。

另外，腾讯云 ASR 还支持字幕文件生成、词级置信度返回、语种识别等能力，虽然会议场景里不一定要全部用上，但按需打开也不费事。

1.3 从标题到落地：目标功能清单

做项目最忌讳一上来就铺开一堆功能。我先给自己圈了一个最小可用版本，一共四件事。

第一，录音文件转写。开会时用录音笔或手机录一段音频，会后上传，系统自动转成带说话人和时间戳的文字。

第二，说话人分区。把不同发言人的话分开，至少能在纪要里标出“A 说了什么、B 回应了什么”，这样讨论脉络一目了然。

第三，关键词提醒。配置一批需要重点关注的词，比如“上线时间”“预算”“风险”，转写完成后扫描全文，把这些关键词所在的句子拎出来单独汇总。

第四，待办抽取。基于转写文本，把“需要做、我来负责、月底前完成”这类表述对应的句子筛出来，形成一份初步的待办草稿，人工再确认一遍即可。

我当时把前三项放在第一周做，待办抽取放在第二周做。原因很简单：前三项依赖的是 ASR 本身的能力，接入成本低；待办抽取需要写规则或接文本处理模型，复杂度更高，放前面反而影响节奏。这个顺序后来被证明是对的。

2. 整体方案设计：为什么选腾讯云 ASR，而不是自己训练模型

2.1 三条技术路线对比

在决定调用腾讯云语音识别之前，我认真比过三条路：自己训练语音识别模型、部署开源模型、用云厂商现成的识别 API。

自己训练模型这条路线，对绝大多数团队来说可以直接排除。语音识别不是单纯跑通一个模型就结束，还要准备上万小时带标注的音频数据、GPU 训练环境、持续调优迭代的工程团队。哪怕只做一个限定领域的模型，成本也远超预期。会议场景本身又特别开放，不同人口音、语速、说话习惯差异巨大，自己训练的效果很难追上通用大模型。

部署开源模型是很多人会心动的一条路。开源社区确实有不少可用的语音识别模型，中文识别效果这几年进步很快。但真正落地时有两个问题：一是部分模型的部署依赖较强，要求较新的显卡和较大的显存，会议室配一台机器专门跑推理，电费和硬件成本得算清楚；二是中文会议场景下的标点预测、数字转换、口语流畅度处理，开源模型通常不如商业云服务打磨得细。

对比之下，用腾讯云 ASR 的优势就出来了。首先是准确率，特别是中文通用场景，云厂商在大量业务数据上持续迭代，长音频、多人对话、口音覆盖都比中小团队自己搞要稳。其次是工程成本，上传音频拿结果，网络请求的事，不需要自己维护推理服务和高可用。再就是附加能力，说话人分离、热词、词级时间戳、数字归一化这些开箱即用，省去大量开发时间。

当然云 API 不是没有代价，成本会随调用量上涨，音频数据也要经过服务端处理。如果团队对数据隐私特别敏感，需要完全私有化部署，那云 API 不适合你；但对绝大多数做内部效率工具的团队来说，这是性价比最高的路线。我自己的结论是：先把业务跑起来，等用户量和预算增长到需要精细化控制时，再考虑迁移或混合部署。

2.2 核心链路：先想清楚实时还是离线

会议助手有两种典型工作方式。一种是实时模式，开会时麦克风采集音频，边说话边生成字幕，会议结束文字稿已经完整生成；另一种是离线模式，先把整场会议录音下来，会后把文件传给识别服务，等几秒或几十秒再拿结果。

我建议第一版做离线模式。原因很直接：实时语音识别对网络稳定性、音频采集质量、前端降噪都有更高要求，一旦现场网络抖动，字幕就断断续续，反而影响体验。离线模式简单可靠，录音文件完整上传，识别服务有充足时间处理，结果更稳定，还支持随时重跑。

离线链路设计大概是这样的：录音设备生成音频文件 -> 上传到对象存储 -> 调用录音文件识别接口 -> 轮询任务状态 -> 拿到转写结果 -> 写入数据库 -> 下游做关键词扫描和待办抽取。

这里有个容易被忽略的点：会议录音文件可能很大，不能直接塞进 API 请求体里传。腾讯云的录音文件识别一般要求音频放在公网可访问的 URL 上，所以我习惯先把录音传到对象存储，再把 URL 传给识别接口。对象存储本身也解决了录音文件长期保存的问题，一举两得。

2.3 成本估算与用量控制

云服务按量计费，成本心里要有个谱。以我接入时的经验，语音识别按调用时长计费，实时和录音文件识别的单价略有差异，另外还有免费额度覆盖前期的测试调用。具体价格官网每个季度都可能有调整，我不在这里写死数字，但可以分享一个估算方法。

假设一个团队每月开 40 场会，每场会议录音 1 小时，那么每月累计识别时长是 40 小时。按常见单价粗算，一个月的费用是几十元到一百多元的级别，不会比团队喝几杯咖啡贵。如果开会频率更高或者每场会议超过两小时，费用再往上翻，但仍然属于可以接受的范围。

控制成本的几个技巧我也说一下。第一，能走录音文件识别就走录音文件识别，通常比实时识别更划算；第二，测试阶段用短视频和短录音验证流程，不要每次测试都传一整场会议；第三，把识别任务放在非紧急时段批量跑，有些服务对异步任务有更优惠的计费方式。这些细节都能把月度账单压下来不少。

3. 核心实践：接入腾讯云 AI 语音识别的完整过程

3.1 前置准备：账号、密钥与 SDK

在写第一行代码之前，需要先在腾讯云控制台完成三件事：开通语音识别服务、创建 API 密钥、确认 SDK 环境。

开通服务没什么好说的，在控制台找到语音识别对应的产品页，按引导开通即可，新用户一般有免费额度。创建密钥需要在访问管理里新建一组 SecretId 和 SecretKey，这组密钥相当于账号的通行证，只放在服务端环境变量里，绝对不能写进前端代码或提交到代码仓库。我在实际项目里见过有人把密钥写在配置文件的公共分支里，结果几分钟后就被巡检工具告警，这是个很低级但很常见的错误。

开发语言我用的是 Python，安装官方 SDK 很方便。如果团队用 Java、Go 或 Node.js，腾讯云也都提供了对应 SDK，接口结构大同小异。安装好之后，初始化客户端的代码像下面这样：

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 cred = credential.Credential("你的SecretId", "你的SecretKey") http_profile = HttpProfile() http_profile.endpoint = "asr.tencentcloudapi.com" client_profile = ClientProfile() client_profile.signMethod = "TC3-HMAC-SHA256" client_profile.httpProfile = http_profile client = asr_client.AsrClient(cred, "ap-guangzhou", client_profile)

这段代码里 region 我填了 ap-guangzhou，实际以你控制台选择的地域为准。密钥建议放到环境变量里读取，而不是硬编码在源码中。

3.2 方案 A：录音文件转文字

录音文件识别走的是异步任务模式：先提交一个识别任务，拿到 TaskId，再用 TaskId 去查询识别结果。这是因为长音频处理需要时间，接口不会立刻返回完整文本。

把音频传到对象存储并拿到访问 URL 之后，提交任务的代码大致如下：

from tencentcloud.asr.v20190614 import models req = models.CreateRecTaskRequest() params = { "EngineModelType": "16k_zh", "ChannelNum": 1, "ResTextFormat": 2, "SourceType": 0, "Url": "https://your-bucket.example.com/meeting/20250101.mp3", "EnableSpeakerDiarization": 1, "SpeakerNumber": 4, } req.from_json_string(json.dumps(params)) resp = client.CreateRecTask(req) task_id = resp.Data.TaskId

这里几个参数值得解释一下。EngineModelType 表示使用的引擎模型，16k_zh 是中文通用模型，要求音频采样率是 16k 或更高；ChannelNum 是音轨数，普通会议录音用单声道填 1，如果录的是立体声且不同发言人在不同声道，可以填 2，识别时会按声道区分；ResTextFormat 填 2 表示返回带词级时间戳的详细结果；SourceType 填 0 代表传入的是 URL 而不是本地文件。

EnableSpeakerDiarization 和 SpeakerNumber 是说话人分离的参数。打开后，返回结果里会多出每个句子的 SpeakerId 字段。SpeakerNumber 需要填一个预估的说话人数，我就遇到过填少了导致说话人合并的情况，实际人数最好比估计值多一两个，宁可多分出几个编号，也不要让两个人被合到一起。

提交完任务，需要轮询查询结果。查询逻辑一般放在一个定时任务里，每隔几秒查一次，直到返回状态为成功或失败。查询代码：

def wait_for_result(task_id, max_wait=300): req = models.DescribeTaskStatusRequest() req.TaskId = task_id for _ in range(max_wait): resp = client.DescribeTaskStatus(req) status = resp.Data.StatusStr if status == "success": return resp.Data.Result elif status == "failed": raise Exception(f"recognize failed: {resp.Data.ErrorMsg}") time.sleep(3) raise TimeoutError("recognition timeout")

StatusStr 在不同阶段会返回 arrived、doing、success、failed 等状态。轮询间隔我建议 3 到 5 秒一次，太频繁没有意义，反而可能触发接口限流。

3.3 方案 B：实时语音转写（流式接入）

如果你还是要做实时字幕，腾讯云也提供流式语音识别接口。它基于 WebSocket 协议，客户端边录音边把音频二进制流推给服务端，服务端持续返回实时识别文本。

实时接入的复杂度比离线高不少。首先要选好 WebSocket SDK，官方提供了 JavaScript 和 Android、iOS 等多端 SDK，服务端也有 Python 和 Java 版本。我调研时发现，这类接口通常先发起握手请求，带上引擎模型和签名信息，然后建立长连接，再持续发送音频帧。

流式接口请求头需要一个签名，签名用 SecretId 和 SecretKey 计算，同时要带上请求参数和当前时间戳。不同 SDK 对这部分封装程度不一样，我用的 SDK 已经封装好了握手逻辑，只需要填参数。

这里我多说一句：实时识别的体验非常依赖音频采集。本地麦克风采集到的声音要先做回声消除、降噪、人声增强，否则会议室里空调声、键盘声、远处的说话声都会被识别进去。很多团队第一版实时识别效果差，问题不在腾讯云 ASR，而在前端采集链路。所以如果只是做会议纪要，不要一上来就挑战实时模式，离线模式已经把 80% 的价值拿出来了。

3.4 把转写结果拼成会议纪要

录音文件识别的结果是一长串 JSON，里面包含句子列表、每个句子的说话人编号、起止时间、句子文本和词级信息。如果直接把这个 JSON 丢给业务方，没人看得下去。所以需要一个整理步骤，把它变成接近人工纪要的格式。

我在项目里写了这么一层处理：遍历句子列表，按 SpeakerId 分组，同一个说话人的连续句子先合并成一段话；再把每段话按时间顺序排列，生成类似下面这样的中间结果：

[00:01:23 - 00:03:45] 说话人 1：这个版本的上线时间我们先定下来，下周五之前要完成联调。 [00:04:02 - 00:05:30] 说话人 2：联调环境我来负责，但是测试数据需要产品同学提前准备。

生成这种底稿之后，再叠加关键词逻辑。我会维护一个关键词表，例如“上线时间”“环境”“测试数据”，扫描每一句话，命中关键词的句子单独标出来，放在纪要给“待关注”区。

至于自动生成议程摘要和待办事项，我是在文本底稿上接了一个文本分析模块，用规则先粗筛，再用大模型精炼。规则部分非常朴素：句子中包含“我需要”“我来负责”“我们决定”“下周”这类表达，就优先提取。大模型部分把这几个候选句子丢进去，让它输出结构化的待办清单。

这一步的价值在于，语音识别给出的文字是流水账，需要二次加工才能变成可执行的信息。加工层不复杂，但非常影响最终体验，属于“看不见但用了就离不开”的部分。

4. 从能跑到好用：准确率、多说话人与长音频调优

4.1 录音环节决定一半效果

做了一轮调优之后，我最深的体会是：识别准确率的上限在录音阶段就决定了，后处理能补的非常有限。

有次测试用的是手机放在会议桌角落录音，离发言人最远有四米，中间还有茶杯和笔记本遮挡。结果整段录音识别出来大量错别字，把“迭代”听成“替代”、“排期”听成“拍齐”，准确率惨不忍睹。后来换了独立麦克风，放在会议桌中央，同样内容的录音，准确率立刻提升了一大截。

会议场景建议优先使用全向麦克风或带麦克风的会议终端，摆放位置尽量靠近参会人中心，让每个人的语音距离相对均衡。如果条件不允许，至少把录音设备放在桌面而不是随手扔在桌边，避免被遮挡。

另外，录音格式也值得检查。我遇到过同事用低码率的录音笔录出来的音频，采样率只有 8k，喂给 16k 模型之后识别质量很差。后面我统一在录音设备里把采样率设成 16k 或 44.1k，保存成 WAV 或高质量 MP3 格式，问题就解决了。

4.2 说话人分离的正确用法

说话人分离是我在会议场景里最看重的功能，但它不是万能的，用不好反而会让结果变乱。

腾讯云的说话人分离返回的是一个数字编号，比如 SpeakerId 为 0、1、2，它不代表具体是哪个人，只代表声音特征不同的几个人。如果会议期间有人中途换了座位、换了麦克风方向，或者因为感冒声音变化，同一个真人可能被识别成两个不同编号。反过来，如果两个人音色特别接近，也可能被合并成一个编号。

所以我不会把说话人分离的输出当作最终身份信息，只把它当作“分区”线索。后续如果要做精确到人的纪要，可以在转写完成后人工映射一遍：让系统把每个编号对应的声音片段抽出来，听几秒就知道是哪个人说的，然后维护一张编号到人名的映射表，第二次开会就能复用。

还有一点，开启说话人分离之前，要确保会议是轮流发言为主。如果整场会议频繁抢话、重叠发言，分离效果会大打折扣，这是所有语音识别系统共同面临的难题，不是换一家云服务就能解决的。

4.3 长音频分段与任务幂等

虽然录音文件识别接口支持长音频，但我在工程上依然做了分段和重试机制。原因有两个：一是单次任务处理时间过长时，客户端连接容易中断；二是任务失败后重试整场会议录音，成本太高，不如按小段重试。

我的做法是：先用 FFmpeg 把整场录音按 15 分钟一段切分，每段独立提交识别任务，识别完成后再按时间顺序拼接。分段可以在对象存储层面做，也可以在服务器端做，关键是切分点要选在静音区域，避免把一句话从中间切断。

为了应付网络超时和任务失败，每个分段任务还需要记录状态。我建了一张 task 表，字段包括音频文件名、分片序号、TaskId、识别状态、结果文本、重试次数。任务失败时先查状态，如果确实失败，重推这一分片，不影响其他分片的结果。做好这一层之后，整体成功率从 90% 出头提升到了接近 100%，稳定性非常重要。

4.4 专业术语和口音怎么补救

会议内容里经常有业务黑话：项目代号、产品功能名、英文缩写，这些东西通用模型一开始很难听对。解决办法是自定义热词，把高频术语提前配置成热词表，识别时会优先朝这些词上靠。

热词不是配得越多越好。我配了一百多个词进去之后，发现有些无关词也开始频繁出现在结果里。后来我把热词表精简到 20 个以内，只保留真正影响业务理解的核心词，比如产品名、项目代号，效果明显变好。我的理解是，热词相当于给模型一个偏置，重点词汇给太多，模型注意力会被带偏。

口音问题相对难办。普通话不标准不是热词能解决的，这是模型训练数据的覆盖问题。我的建议是，在不影响业务理解的前提下接受部分口音误差，把精力放到后续加工的容错上：关键词规则不要太严格，文本匹配时做同义词和近音词的扩展，待办抽取允许人工微调。

5. 实测对比与踩坑记录

5.1 我的一套测试方法

调优不能靠感觉，我搭了一套非常简单的测试基线。先把测试音频分成几个固定场景：双人安静对话、三人会议室发言、带背景噪声的多人讨论、含大量专业术语的评审会。每个场景准备三段长度约三分钟的音频，这些音频固定不变，每次调整参数后重新识别，对比结果。

评估指标我主要看两个：字错率高低和关键信息是否完整。字错率是一个模糊感受，我不会逐字去对标准文本，太费时间；我更关心的是会议里那些关键数字、人名、时间点是否被识别正确，因为会议纪要最怕的是把责任人或者时间搞错，这种错误比普通别字严重得多。

测试时注意统一参数，尤其是引擎模型和热词表。我踩过一次坑，前后两次对比用了不同的热词表，结果准确率波动很大，以为是模型不稳定，查了半天发现是热词表不一致。测试基线必须锁死，变量一次只动一个。

5.2 不同场景下的识别效果

把观感数据整理成一张表，大概长这样：

这三个数据说明几个问题。第一，会议场景只要录音质量基础达标，腾讯云 ASR 的文字结果可用度是很高的，人类整理纪要时不需要从零开始，改错和归纳的成本大大降低。第二，背景噪声和多人抢话是准确率最大的敌人，录音设备和会议规则对最终效果的影响甚至超过模型参数。第三，热词配置在专业领域场景中的提升是肉眼可见的，值得多花时间维护。

5.3 三个让我印象深刻的坑

第一个坑是静音段导致识别结果出现大段空白或重复。有一场会议中途有人离开了十来分钟，整段音频长时间没有语音，识别结果里出现了十几秒的空行。后面我做了预处理：转写前先用静音检测把前后导语和长时间静音段剔除，或者切分音频时把长静音区域作为天然分界点。

第二个坑是数字格式。会议里“报价大概三百万”被识别成“报价大概3百万”，后面待办抽取时我按“三百万”去匹配，匹配不上。解决办法是让识别接口做数字归一化，开启相关参数，让“三百万”统一转成“300万”或保留中文数字，同时在规则层做成兼容匹配。

第三个坑是回调地址。录音文件识别支持回调方式通知任务完成，我一开始设置了回调地址，但测试时本地环境根本收不到外网请求，任务一直卡在静默状态。后来我改成轮询方式，开发期就顺畅多了。回调适合有稳定公网服务的生产环境，本地测试务必用轮询。

6. 常见问题排查与效率提升技巧

6.1 常见问题速查表

把我在接入和实际使用中遇到的问题整理成速查表，碰到类似问题可以直接对号入座：

排查这些问题的总原则是“从前到后分层看”：先看音频能不能正常下载，再看参数有没有传对，再看任务状态是否推进，最后才怀疑模型能力。大多数问题都出在前三层。

6.2 接入后的几个加分项

识别转写本身跑通之后，会议小帮手还可以在几个方向上继续加分，成本不高但体验提升明显。

第一个加分项是把会议纪要自动通知到团队群。转写和整理完成后，通过 Webhook 把纪要摘要推送到工作群，大家不用主动刷新就能看到结果。推送内容只放摘要和待办，完整底稿放在文档链接里，避免刷屏。

第二个加分项是给转写结果打标签和归档。每次会议按照日期、项目名、参会人标签归档，以后想找某次讨论的原话，直接按标签搜，比翻聊天记录高效得多。时间一长，这就是团队的决策知识库。

第三个加分项是把文字底稿和原录音绑在一起。遇到文字识别模糊的地方，点击句子能跳转到对应时间点的音频片段。我实现的时候是把句子时间戳和音频资源 URL 存在一起，前端播放器直接跳转，说起来简单，做出来非常实用。

6.3 接入后的长期维护建议

系统上线后不是一劳永逸的，会议小帮手最需要长期维护的是热词表和规则库。每个新项目都会有新的缩写、新的产品名，我每周会固定抽几个会议的转写结果看一遍，把高频错词补充进热词表，把误判的关键词规则改掉，这个维护动作每次不到半小时，但能让识别效果越来越好。

还要提醒一点，音频和转写文本里常常含有参会人的个人信息、商业决策信息，在设计和部署时要做好访问控制，不能谁都能翻历史会议记录。至少要做到按团队隔离、按角色授权，转写文本尽量不要明文存到不可控的第三方工具里。效率工具做出来是方便大家的，但因为权限问题出事故就得不偿失了。

几次踩坑之后，我的体会是，会议助手这类工具真正的难点不在 AI 识别那一环，而在录音质量、结果加工和后续追溯这些看起来不起眼的工程细节。腾讯云 AI 语音识别把最难的语音理解部分包掉了，我们要做的就是把周边流程打磨顺，让一场会议开完，纪要自动出现在对的人面前。按这个思路，哪怕第一版只做到录音转写和关键词扫描，对团队的开会效率也是一次明显的升级。