用腾讯云ASR打造会议小帮手：从语音识别到自动纪要

先说我为什么会做这个项目。几个月前我在一个创业团队做技术顾问，每次周会开完，大家最常问的一句话是“刚才那个结论是啥来着”。不是记性差，是会议信息密度实在太高，又要听、又要想、又要记，根本忙不过来。市面上现成的会议纪要工具我大概扫了一圈，要么价格偏贵，要么对中文长语音的识别效果一般，还有些是数据完全封闭的SaaS，不方便直接接入内部工作流。最后我决定自己动手，用腾讯云AI语音识别做了一款会议小帮手，把开会这件事从“事后靠回忆”变成了“全程可检索”。

这篇文章不是官方文档的搬运，更多是我从零把腾讯云AI语音识别落到真实会议场景的记录。内容包括选型时的思考、录音文件识别和实时识别两条接入路径的实际操作、会议室嘈杂环境下怎么调准确率、说话人分离和纪要生成怎么做，以及上线以后最容易踩的几个坑。如果你正准备做会议纪要工具、课堂录音整理、播客转写或者采访速记，这篇应该能帮你少走不少弯路。

1. 先想清楚：这个“会议小帮手”到底要解决什么

1.1 记不住内容才是会议的真正问题

很多人以为会议工具的痛点是把语音转成文字，真用下来会发现，转出流水账只是第一步，真正的痛点是“事后找不到关键信息”。我观察过好几支团队的开会习惯：有人埋头记笔记，结果全程没跟上讨论；有人开着手机录音，但会议结束后音频文件就躺在网盘里再也没人打开；还有人会后凭着记忆补纪要，遗漏和扭曲几乎是必然的。

我做的这个小帮手，核心解决三件事：第一，把会议语音变成可读的逐字稿，带时间戳，方便回看某句话出现在哪一刻；第二，把不同说话人的发言分开，谁说了什么一目了然；第三，基于转写文本自动生成结构化的会议纪要和待办事项。这三件事做完，会议就不再是一个“听的时候很热闹、事后只剩模糊印象”的事件，而是一份可以检索、可以追溯、可以派发任务的资产。

1.2 第一版功能边界：只做三件事

一开始我也想过把功能做全，比如自动关联日历、自动创建任务卡片、跟视频会议系统深度集成。后来还是把范围收住了，第一版只做“转写、分离、纪要”这三件最核心的事。原因很简单：用户最痛的是会开完了不知道结论是什么，而不是缺少一套完整的工作流自动化。

做工具的人容易犯一个毛病，就是第一版想包揽一切。实际上，转写质量如果不可靠，后面接再多自动化都是空中楼阁。所以我建议你也按这个节奏来：先跑通一条30秒的音频，确认文字识别准确率满意了，再做说话人分离，最后加纪要生成。每一步都是一个可以独立交付的里程碑。

2. 为什么我选了云端ASR而不是本地开源模型

2.1 我实测比较过的三种方案

动手之前，我把市面上可用的语音识别方案粗略分成了三类，然后用同一个会议录音样本做了对比测试。

第一类是本地开源模型。准确率其实已经比前几年强很多了，尤其是英文场景，中文的断句和时间戳也做得有模有样。但问题在于硬件成本，跑一个像样的本地模型至少需要一块足够好的显卡，会议室或笔记本上想流畅地实时转写很吃力。第二类是腾讯云这类云厂商的ASR API，开通服务后拿到密钥就能调用，提供了录音文件识别和实时识别两种模式，还内置了热词表、说话人分离这些高级能力。第三类是面向客服电话场景的识别引擎，对室内多人会议的支持比较弱，很快被我排除了。

我把三个方案的对比整理了一张表，当时选择时参考价值很高：

2.2 云端ASR的取舍：准确率、时延、成本三者怎么平衡

选腾讯云ASR，我的判断逻辑其实很简单：在这个项目里，我不想去维护GPU环境，也不想自己折腾声学模型和语言模型的调优。云API最大的价值在于它把“训练和调优”的成本摊在了服务端，我们只需要关心音频质量和业务逻辑。尤其是热词表功能，会议里经常出现产品名、人名、技术术语，这些专名恰恰是通用模型最容易听错的，云API能通过配置词表的方式显著改善，这个能力本地模型做起来麻烦得多。

当然，云端方案也有代价。数据要走公网，敏感会议需要提前评估；接口有并发上限，高峰期要排队；按量计费意味着长期使用会持续产生成本。但对一个小团队内部工具来说，这些代价是完全可以接受的。真正不该省的地方是：不要在选型上拍脑袋。一旦代码写进后处理逻辑，再更换引擎的迁移成本会非常高，所以第一周我花了不少时间只做测试，没有急着写业务代码。

3. 两条核心接入路径：录音文件识别与实时识别

3.1 离线转写：录音文件识别（CreateRecTask + 轮询状态）

腾讯云AI语音识别的录音文件识别接口，适合处理已经存在的音频文件，比如录好的会议音频、课程录音、访谈文件。原理不复杂：你把音频的URL提交给服务端，拿到一个TaskId，然后轮询任务状态，识别完成后把结果拉回来。我在Python里封装了一个简单的提交和轮询函数，核心逻辑如下：

import json import time import os from tencentcloud.common import credential from tencentcloud.asr.v20190614 import asr_client, models SECRET_ID = os.environ.get("TENCENTCLOUD_SECRET_ID") SECRET_KEY = os.environ.get("TENCENTCLOUD_SECRET_KEY") cred = credential.Credential(SECRET_ID, SECRET_KEY) client = asr_client.AsrClient(cred, "ap-guangzhou") def submit_rec_task(audio_url): req = models.CreateRecTaskRequest() req.EngineModelType = "16k_zh_video" # 带说话人分离的极速版模型 req.ChannelNum = 1 # 单声道；双声道要提前混音或分轨 req.ResTextFormat = 3 # 3表示带时间戳且带说话人ID req.SourceType = 0 # 0表示URL方式，1表示本地上传 req.Url = audio_url resp = client.CreateRecTask(req) return resp.Data.TaskId def poll_task(task_id, max_wait=300): req = models.DescribeTaskStatusRequest() req.TaskId = task_id waited = 0 while waited < max_wait: resp = client.DescribeTaskStatus(req) status = resp.Data.Status if status == 2: # 2代表识别成功 return resp.Data.Result elif status == 3: # 3代表任务失败 raise RuntimeError(f"识别失败: {resp.Data.ErrorMsg}") time.sleep(3) waited += 3 raise TimeoutError("识别任务超时")

这里有几个参数值得专门说一下。EngineModelType选的“16k_zh_video”，适合视频或会议录音这类带环境噪音的音频，而且支持返回说话人信息；它要求音频采样率是16kHz。ChannelNum如果设成2，服务端会期望你传双声道音频并做声道分离，但真实会议录音往往是单声道或者两路声音混在一起，我建议在预处理阶段统一成单声道，不要指望接口帮你做什么复杂的音源分离。ResTextFormat设成3，返回结果里才有说话人和时间戳信息，这是后续做纪要的关键。

我建议把轮询结果按业务ID缓存到数据库里，而不是每次都去查询。项目初期我图省事直接查，结果会议一多，任务状态查询的调用量跟着涨，既浪费配额又容易在回调时弄混不同场的音频。

3.2 实时转写：WebSocket 流式识别

如果需要开会现场就出字幕，或者一边说话一边看到转写文本，就要走另一条链路：实时语音识别。它的原理是建立一条WebSocket长连接，客户端持续把麦克风采集到的音频帧推给服务端，服务端边收边识别，实时返回中间结果和句级结果。

实时识别最关键的一点是音频帧的拉取节奏。我用的是系统录音设备回调，每20毫秒取一帧音频，然后通过WebSocket发出去。服务端返回的事件里，需要重点关注三类：语音段开始、中间结果、最终结果。中间结果会跟随说话内容不断刷新，最终结果是在一句话说完后返回的稳定文本。实际做会议字幕时，我通常只展示最终结果，避免屏幕上文字跳来跳去，只有在自己用的调试模式里才会看中间结果。

还有一点要注意，实时识别和录音文件识别是两套独立的接口，计费方式不同，并发限制也不同。千万不要以为实现了一种，另一种就不用看了。我的工具最终两个都做了：现场会议用实时识别出字幕，同时录一份完整音频，会后用录音文件识别再生成高精度的完整逐字稿。两条链路互补，效果比单走一条要好。

3.3 音频格式的硬性要求与转码操作

在接入时踩过的最大的格式坑，是对采样率不敏感。会议系统导出的录音经常是48kHz或者44.1kHz，双声道更是家常便饭，而ASR接口明确要求16kHz、单声道。直接提交会产生两种后果：要么接口直接报错，要么识别率骤降但你根本不知道原因。

我的做法是在提交前先用ffmpeg做一次标准化转码：

ffmpeg -i input.m4a -ar 16000 -ac 1 -acodec pcm_s16le output.wav

这条命令把音频重采样到16kHz，转成单声道，编码格式设为16位PCM。有人会担心48kHz降到16kHz会丢信息，其实对语音转写来说完全不用担心。人声的有效频段集中在300Hz到3400Hz左右，16kHz采样率能覆盖到8kHz的音频带宽，远够用了。反而是一些会议系统录出来的双声道音频，左右声道各收了一半人的声音，如果不混音直接提交，识别结果里会出现串话和混乱。所以统一转成单声道不仅仅是格式规范问题，更是保证识别质量的前提。

4. 会议室真实环境下的识别效果调优

4.1 采集端决定了识别率的上限

我第一次用真实会议室录音做测试，结果惨不忍睹，产品名词全错，人名一个都对不上，有些句子直接变成乱码。后来逐条排查才发现，问题不全在识别引擎，最关键的瓶颈在采集端。那间会议室用的是投影仪自带的麦克风，远场拾音效果本来就一般，加上空调噪声和投影风扇声，喂给引擎的音频就已经脏了。

如果你要做的也是会议场景，我最真诚的建议是：不要在采集环节省钱。一个质量还不错的全向会议麦克风，或者用视频会议终端的录音输出，效果远好于笔记本内置麦克风。混响严重的房间可以在地面铺地毯、挂一些吸音材料，这些物理手段对识别率的提升，比任何参数调整都明显。

4.2 热词表怎么配：专名、人名、产品名一个都不能少

腾讯云ASR提供热词表功能，这个词表是提升会议场景准确率的利器。会议里高频出现的产品名、技术术语、人名、地名，默认模型大概率会听错，原因很简单：通用模型的词表里没有这些专名，或者它们在语料里出现的频率太低。

我的做法是把团队内部常用词整理成一个热词列表，每隔一段时间更新一次。比如“微前端”“低代码平台”“数据中台”，还有几个核心成员的名字，都加进去。实测下来，一个很典型的案例是会议里提到某技术方案缩写，不加词表时被识别成毫不相关的两个汉字，加入热词表后准确率立即恢复正常。需要注意，热词表不是越多越好，词条过多会提高误召回的概率，导致本来正常的句子被强行改写成词表里的内容。我一般控制在几百条以内，并且定期清理不再使用的词汇。

4.3 方言、重口音和中英文混说的处理

很多团队不是全员标准普通话，广普、川普、带口音的英文混着说，这是中文ASR在会议场景最头疼的挑战。我试过的方式是：能提前约束就提前约束，无法约束就在后处理里弥补。所谓提前约束，就是尽量让每位发言者靠近麦克风，发音清楚些，这能直接降低识别错误率。后处理弥补，则是把转写文本扔给大模型做一次纠错和润色，比如依据上下文把不合理的同音字修正回来。

对于中英文混说的场景，腾讯云有专门的英文模型和普通话带英文混说模型。如果你的会议是中英混合比例很高的技术评审，建议单独测试不同的引擎类型，不要默认用纯中文模型。这里有个决策点：会议到底该用“实时识别+后处理纠错”还是“录音识别+后处理纠错”？我个人的结论是，重要会议两者都跑一遍，实时字幕给人看，录音识别结果用于生成归档纪要，准确率优先。

5. 从“转写文本”到“会议小帮手”：后处理才是灵魂

5.1 说话人分离：分清“谁说了什么”而不是“谁是谁”

录音文件识别返回的Result里，如果一开始就指定了带说话人的格式，你会拿到类似“发言人1：关于这个需求，我的想法是……”“发言人2：但排期上我们可能有风险”这样的结构化数据。每个说话人用一个ID表示，同一人的语音会自动归到同一个ID下。这一步做完，原始的连续语音流就变成了一出有角色标识的对话剧本。

需要特别说明的是，说话人分离不等于身份识别。它只是根据音色把不同说话人区分开，并不会告诉你“1号是张三”。如果你想在纪要里显示真实姓名，最简单的方法是会议开始时让每个人自报家门，然后人工把“发言人1”映射成对应的名字。这个映射在我做的第一版里是自动完成的：我根据会议参与人名单和发言片段里的称呼，做一次简单匹配，准确率尚可，但偶尔会出错，所以保留人工修正入口。

5.2 用提示词把流水账变成会议纪要

拿到带说话人和时间戳的逐字稿后，真正的会议小帮手才刚刚开始。我做的事情很简单：把整段转写文本交给大模型，用一段结构化的提示词让它输出会议纪要。提示词模板大致是：

你是一位会议助理。下面是某次会议的完整逐字稿，包含说话人ID和时间戳。 请提取： 1. 会议主题 2. 讨论过程中的关键信息 3. 最终达成的共识 4. 分歧点（如有） 5. 待办事项，每条尽量带上发言人信息和大致时间点 要求：忽略寒暄和与主题无关的闲聊，输出用中文，尽量精简。

最初我是一整段直接扔给大模型的，但会议超过一小时时，转写文本量会超窗口，于是改成先分段摘要再汇总。分段的方法是：按时间窗口切成15分钟左右的片段，每段生成一个小摘要，最后把小摘要合并成最终纪要。这个办法牺牲一点上下文连续性，换取对超长会议的稳定支持，实测效果很好。

还有一个经验：为了让待办事项不漏掉，我不会只依赖大模型从全文里总结，还会先用规则在原文里搜索“要跟进”“负责”“什么时候上线”“回头确认”这类承诺型语句，命中后把这些句子连同上下文标记出来，再喂给大模型。这种做法能明显提升待办识别的召回率，比单纯让模型通读全文更可靠。

5.3 关键词提醒与事后检索

会议小帮手还有两个很有实用价值的附加功能。第一个是关键词提醒：在实时识别过程中，如果出现“风险”“延期”“上线”“故障”这类关键词，系统可以马上弹出提示。实现方式也不复杂，我在识别回调里对每个最终结果跑一遍规则匹配，命中后通过内部机器人推送给相关人。这个功能用来监控项目风险会特别有用，比如会上有人说“这个版本可能要延期”，相关同学能在第一时间收到提醒。

第二个是事后检索。会议开完，逐字稿都在数据库里了，我用一个支持全文检索的本地索引把每场会的内容建好索引。这样以后问“上个月讨论数据迁移的时候结论是什么”，我可以直接在索引里搜“数据迁移”，定位到对应的会议和说话人，几秒钟就能找到原始上下文。这一步让会议资料从“存储”变成了“资产”，是我认为这个工具最值得坚持的部分。

6. 上线后遇到的坑、限额与成本

6.1 四个真实踩过的坑

先把我踩过的坑一个个列出来，如果你也打算接ASR，大概率会碰到相同的问题。

第一个坑是双声道音频没转码就提交。结果识别出来的文本里，两个声音叠在一起，语句前后错乱。后来我在提交前统一加了混音和转码步骤，问题才消失。第二个坑是长音频超时。录音文件识别对单次音频长度有上限，我一开始拿整场两小时的会议直接提交，任务跑到一半就失败了。解决办法是按逻辑节点切分，比如按议程切成20到40分钟的片段，逐个提交，再按时间戳拼接。第三个坑是任务回调顺序不保证。我同时提交多个会议的任务时，完成顺序和提交顺序并不一致，差点把A会议的转写结果写进B会议。现在我在每次提交前都带上业务唯一ID，在拉取结果时校验，绝不依赖回调顺序。第四个坑是热词表更新后不立即生效。调试时我以为词表没配好，反复删加了好几次，最后发现只要等一小段时间重新提交任务就能用上，这个延迟容易被忽略。

6.2 并发、限额与控制台报价

云端ASR接口不是无限调用的，开通后有并发和QPS限制。我的工具一开始是单线程串行提交，后来多个人同时上传录音时出现了排队。解决方案是在代码里加了一个简单的任务队列，限制同时提交的任务数量，超过并发上限的任务先排队，避免接口返回限流错误。实时识别也是一样，我在客户端做了并发控制，同一个时间只保持有限数量的WebSocket连接，宁可排队也不要触发限流。

价格方面，腾讯云ASR按音频时长计费，录音文件识别和实时识别的单价略有不同，具体以控制台当前报价为准。我当时粗略算过，一场一个小时的会议，转写成本在个位数的量级，相比人工整理纪要花掉的时间，这个成本几乎可以忽略。但如果你的工具是面向公众的，每天有几千场录音提交，那就必须在产品里做配额管理，否则费用会非常可观。

6.3 关于敏感会议数据的提醒

最后想说一个容易被忽略但很重要的问题：会议录音往往包含内部信息甚至个人隐私。把音频发送到云端识别之前，团队内部一定要有明确的告知和授权流程，尤其是讨论敏感话题的会议。我当时跟团队确认过，只把脱敏后、不含关键秘密的会议录音接入云端转写，并且让参会人知情。如果你所在的组织对数据安全要求极高，连标准协议都不满足，那可能要考虑本地部署方案，但那又会回到一开始的算力问题。所以上不上云，需要先回答“数据敏感级别有多高”这个问题。

回顾这一整个搭建过程，我最大的体会是：语音识别只是会议小帮手的底座，真正拉开体验差距的，是音频质量、热词配置、说话人分离、摘要生成这一长串后处理环节。如果你也要做类似工具，我建议从一段最熟悉的30秒会议录音开始，把它跑通、调准，再一步步放大场景。先把转写本身做到让人愿意用，再谈纪要和检索，这个节奏是最踏实的。