腾讯云AI语音识别实战：搭建会议纪要自动生成工具

1. 会议记录这件事，到底难在哪

开会这件事，估计每个职场人都有一肚子话想说。尤其是会后整理纪要，那真是谁做谁知道。我待过的几个团队，几乎每次周会、评审会、复盘会，都有人负责记录。记录的人往往全程埋头敲键盘，根本没精力参与讨论，结果就是会议开完了，纪要还得花一两个小时整理，遇到多人抢话、语速快、专业术语多的场景，整理出来的东西经常缺胳膊少腿。

后来我开始琢磨，能不能让机器来干这个活。市面上语音转文字的工具不少，但真正能扛住真实会议场景的，其实没几个。原因很简单，会议室里的音频环境太复杂了：有人离麦克风远，有人说话带口音，有人喜欢插话，还有空调声、键盘声、翻页声这些背景噪音。通用语音识别模型直接怼上去，出来的结果往往惨不忍睹。

我试过好几套方案，最后稳定下来的组合是腾讯云 AI 语音识别加上一层自己的后处理逻辑。这套东西我把它叫做“会议小帮手”，核心目标就三个：把会上的话准确转成文字、把不同说话人区分开、把转出来的文字整理成能直接用的纪要。听起来简单，但每个环节都有坑，下面我把整套思路和实操细节完整拆一遍。

这篇文章适合谁看？如果你是需要频繁组织会议的项目负责人、需要整理访谈记录的运营同学、或者想给自己团队搭一套内部会议记录工具的技术同学，那接下来的内容应该能帮你省下不少试错时间。我不讲虚的，直接上我踩过的坑和验证过的参数。

2. 整体方案设计与选型思路

2.1 为什么选云端语音识别而不是本地部署

一开始我也考虑过本地部署开源模型，比如 Whisper 这类。本地跑的好处是数据不出内网，隐私性强，但问题也很明显：第一，想要高准确率就得用大模型，大模型对显卡要求高，一台普通办公电脑根本跑不动；第二，会议场景需要实时性，本地推理延迟经常飙到十几秒，体验很差；第三，多人说话人分离（也就是常说的“说话人日志”）在开源方案里实现起来相当折腾，效果也不稳定。

腾讯云 AI 语音识别的优势在于，它把录音文件识别和实时语音识别两条链路都做得很成熟，而且内置了说话人分离能力。对于会议场景，我主要用的是录音文件识别这条线，因为会议通常允许会后处理，对实时性要求没那么苛刻，但准确率要求高。如果你们有实时字幕的需求，实时语音识别那条线也能接，只是参数调优逻辑不太一样。

提示：选云端服务之前，先确认你们公司对数据外发的合规要求。如果会议内容涉及敏感信息，建议先走内部审批流程，或者只把非敏感的会议交给云端处理。

2.2 会议小帮手的三个核心模块

整套方案我拆成了三个模块，每个模块各司其职：

• 音频预处理模块：负责把会议录音转成符合识别要求的格式，做降噪和声道处理。这一步很多人会忽略，但它直接决定了后面识别的上限。
• 语音识别模块：调用腾讯云 AI 语音识别接口，拿到带时间戳和说话人标签的原始转写结果。
• 纪要后处理模块：对原始转写做清洗、分段、关键词提取，最终生成结构化的会议纪要。

这三个模块里，第一个和第三个是我自己写的，第二个直接调云服务。下面逐个展开。

2.3 方案选型背后的几个关键取舍

在动手之前，有几个决策点值得说清楚，因为它们直接影响后面的实现方式。

第一个取舍：用录音文件识别还是实时流式识别。我选的是录音文件识别，原因是会议场景下，录音文件识别支持更大的音频时长（单文件可以到数小时），而且说话人分离效果更好。实时流式识别虽然能出字幕，但说话人分离能力弱一些，适合做辅助字幕而不是正式纪要。

第二个取舍：说话人分离用云端能力还是自己聚类。腾讯云的录音文件识别自带说话人分离参数，我实测下来，在 4 人以内的会议里，分离准确率能到八成以上。自己用声纹聚类去做，调参成本高，效果还不一定更好。所以除非有特殊需求，直接用云端能力就行。

第三个取舍：后处理用规则还是用大模型。我一开始纯用规则做清洗，后来发现规则只能处理格式问题，没法做语义层面的摘要和要点提取。所以最终方案是规则加轻量级大模型结合：规则负责去重、去语气词、按说话人分段，大模型负责提炼议题和待办事项。

3. 音频预处理：识别效果的地基

3.1 会议录音的常见格式问题

真实会议录音的来源五花八门：有的是会议室设备录的，有的是手机录的，还有的是线上会议软件导出的。格式上可能是 mp3、m4a、wav、aac，采样率从 8kHz 到 48kHz 都有。腾讯云 AI 语音识别对输入格式有要求，我一般会统一转成16kHz 采样率、16bit 位深、单声道 wav。这个格式是语音识别的“黄金标准”，既能保证识别准确率，又能控制文件体积。

转换工具我用的是 ffmpeg，命令行操作，稳定可靠。下面这条命令是我常用的：

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

参数解释一下：-ar 16000指定采样率 16kHz，-ac 1指定单声道，-acodec pcm_s16le指定 16bit 小端 PCM 编码。这三项配好，基本就不会因为格式问题导致识别失败了。

3.2 降噪和音量归一化怎么做

会议室录音最大的敌人是背景噪音和音量不均。有人说话声音小，有人声音大，直接扔给识别引擎，小声的部分容易丢字。我的做法是先用 ffmpeg 做一次音量归一化，把整体响度拉到统一水平：

ffmpeg -i output.wav -af "loudnorm=I=-16:TP=-1.5:LRA=11" normalized.wav

loudnorm是 ffmpeg 内置的响度归一化滤镜，I=-16表示目标响度 -16 LUFS，这是语音内容的常用值。归一化之后，小声的发言也能被清晰识别。

至于降噪，我试过几种方案。ffmpeg 自带的afftdn滤镜能去掉一部分稳态噪音，比如空调声，但对突发噪音效果一般。如果会议录音质量实在太差，可以考虑用专门的降噪工具先处理一遍，但要注意别降过头，把语音本身也削掉了。我的经验是，轻度降噪即可，过度降噪反而会损失语音细节，导致识别率下降。

3.3 长音频切分的策略

腾讯云录音文件识别对单文件时长有上限，虽然支持长音频，但为了容错和并行处理，我习惯把超过 30 分钟的录音切成 10 分钟左右的片段。切分的时候有个关键点：不要按固定时间硬切，要在静音处切，否则会把一个词切成两半，影响识别。

用 ffmpeg 的静音检测可以做到这一点：

ffmpeg -i normalized.wav -af silencedetect=noise=-30dB:d=1 -f null -

这条命令会输出所有静音段的起止时间，我根据这些时间点来决定切分位置。noise=-30dB表示低于 -30dB 算静音，d=1表示持续 1 秒以上才算。切分点选在静音段中间，这样不会切断语音。

注意：切分后的片段要保留原始时间戳偏移量，否则后面合并转写结果时，时间信息就乱了。我的做法是给每个片段记录一个offset值，合并时把片段内的时间戳加上这个偏移。

4. 调用语音识别接口的核心细节

4.1 录音文件识别的参数配置

腾讯云录音文件识别的调用方式，我走的是异步任务模式：先提交任务，拿到 TaskId，然后轮询查询结果。核心参数有这么几个：

这里重点说两个参数。SpeakerNumber如果你们会议固定是几个人，建议直接指定人数，比如 4 人会议就填 4，这样分离准确率会比自动判断高。FilterModal我建议开启，因为会议里“嗯”“那个”“就是说”这类语气词特别多，过滤掉之后转写结果干净很多，后处理也省事。

4.2 说话人分离的实际效果与调优

说话人分离是会议场景的核心能力。我实测下来，影响分离效果的因素主要有三个：

第一是音频质量。如果两个人同时说话，分离就会出错。所以开会时尽量提醒大家不要抢话，这个虽然听起来像废话，但确实是最有效的优化手段。

第二是说话人数量。人数越多，分离难度越大。4 人以内效果最好，超过 6 人就开始明显下降。如果会议人数多，可以考虑按议题分段处理，每段只涉及少数几个人。

第三是说话时长。如果某个人全程只说了一两句话，分离模型可能识别不出来，把他归到别人身上。这种情况在后处理阶段需要人工校正。

实操心得：我一般会在提交识别任务前，先听一遍录音，确认有几个主要发言人，然后在参数里指定人数。这一步花两分钟，能省下后面半小时的校正时间。

4.3 识别结果的原始结构解析

识别完成后，返回的结果是一个 JSON 结构，核心字段是Result，里面包含SentenceList。每个句子对象长这样：

{ "Sentence": "这个方案我觉得可行", "StartTime": 12500, "EndTime": 15800, "SpeakerId": 2, "Words": [...] }

StartTime和EndTime是毫秒级时间戳，SpeakerId是说话人编号。这个结构已经相当规整了，但直接拿来当纪要还不行，因为它是按句子切的，不是按议题切的，而且说话人编号是数字，需要映射成真实姓名。

5. 后处理：从转写文本到可用纪要

5.1 说话人编号映射与分段

原始结果里的SpeakerId是 0、1、2 这样的数字，得映射成真实姓名。我的做法是：先统计每个 SpeakerId 的发言总时长，时长最长的通常是会议主持人，然后根据发言内容里的称呼线索来推断身份。比如某段话里出现“张工你觉得呢”，那下一段发言大概率就是张工。

这个映射过程我做了半自动化：脚本先给出候选映射，人工确认一遍。确认之后，把所有句子按说话人重新分段，同一说话人连续发言的句子合并成一段。

5.2 语气词清洗和重复内容去重

虽然识别接口已经过滤了一部分语气词，但转写结果里还是会有残留，比如“那个”“然后”“就是”。我用正则做了一轮清洗：

import re def clean_text(text): # 去掉常见语气词 fillers = ['嗯', '啊', '那个', '然后就是', '就是说'] for f in fillers: text = text.replace(f, '') # 去掉连续重复的标点 text = re.sub(r'([，。！？])\1+', r'\1', text) # 去掉多余空格 text = re.sub(r'\s+', ' ', text).strip() return text

重复内容去重也很重要。会议里经常有人重复别人的话，或者自己说了一遍又补充一遍。我用的是基于文本相似度的去重：如果相邻两段话的相似度超过 0.85，就保留信息量更大的那段。

5.3 议题提取和待办事项识别

这一步我用轻量级大模型来做。把清洗后的转写文本按段落喂给模型，让它输出两部分内容：议题摘要和待办事项。提示词我打磨了好几版，最终稳定下来的是这个结构：

你是一个会议纪要助手。请阅读以下会议转写内容，完成两件事： 1. 用一句话概括这段讨论的核心议题。 2. 提取其中明确的待办事项，格式为“负责人：事项内容：截止时间”。 如果某项信息缺失，标注为“待确认”。

实测下来，议题提取的准确率不错，待办事项识别也能抓住大部分明确的任务分配。但要注意，模型有时候会把讨论过程中的假设当成待办，所以最终纪要还是需要人工过一遍。

6. 常见问题与排查技巧实录

6.1 识别准确率低的几种原因

热词表这个功能值得单独说。腾讯云支持上传自定义热词表，把你们团队常用的专业术语、产品名、人名加进去，识别准确率会有明显提升。我一般会在项目启动前，先整理一份 50 到 100 个词的热词表，效果立竿见影。

6.2 长会议处理的超时与容错

长会议处理最容易遇到两个问题：一是任务超时，二是部分片段识别失败。我的应对策略是：

• 分片处理：前面说的 10 分钟切分，不仅是为了容错，也是为了避免单任务超时。
• 失败重试：每个片段识别失败后自动重试两次，两次都失败就标记出来，人工处理。
• 断点续传：把每个片段的识别状态记录到本地文件，程序中断后可以从上次的位置继续，不用全部重来。

踩过的坑：有一次处理一个两小时的会议录音，没做分片，结果任务跑到一半超时了，前面识别好的结果也没保存，全部白干。从那以后我养成了分片加状态记录的习惯。

6.3 成本控制的几个实用技巧

云端语音识别是按量计费的，会议多的话成本不小。我总结了几个省钱的办法：

第一，音频压缩。16kHz 单声道 wav 已经比原始录音小很多了，如果还想再压，可以转成 16kHz 单声道 mp3，体积能再小一半，识别效果几乎没差别。

第二，按需识别。不是所有会议都需要转写。我一般只对正式评审会、需求讨论会做转写，日常站会这种信息密度低的就不做了。

第三，复用结果。识别结果存到本地数据库，后续做搜索、做知识库都从本地读，不用重复调用接口。

7. 这套方案的实际效果与扩展方向

7.1 实测数据与效果评估

我在团队内部跑了大概三个月，处理了四十多场会议。平均下来，一场一小时的会议，从录音到生成初版纪要，耗时大约 8 到 12 分钟，其中识别占大头。转写准确率方面，在音频质量正常、发言人不超过 4 人的情况下，字准确率能到 92% 以上，说话人分离准确率大约 85%。经过后处理清洗后，纪要的可读性已经能满足内部传阅要求，人工只需要花 10 分钟左右做最终校对。

对比之前纯人工记录的方式，整理时间从平均 90 分钟压缩到了 15 分钟以内，而且记录人终于可以全程参与讨论了。这个收益对我们团队来说非常实在。

7.2 可以继续叠加的能力

这套基础方案跑通之后，我还尝试了几个扩展方向。一个是会议知识库：把历史纪要存进向量数据库，新会议开始前可以检索相关历史讨论，避免重复扯皮。另一个是待办追踪：把识别出的待办事项同步到任务管理工具，自动创建任务并分配负责人。还有一个是多语言会议支持：腾讯云支持多种语言识别，跨国团队开会时可以直接转写英文内容。

这些扩展我还在逐步完善，但核心链路已经稳定了。如果你也想搭一套类似的会议小帮手，建议先从音频预处理和基础识别跑通，再逐步叠加后处理和扩展能力，不要一上来就追求大而全。

最后分享一个我踩过的小坑：别在会议进行中实时调用识别接口做字幕，除非你们网络特别稳定。我有一次在客户面前演示实时字幕，结果网络抖动，字幕卡住不动，场面一度非常尴尬。后来我改成会后处理，稳定多了。实时字幕可以作为锦上添花的功能，但别把它当成核心依赖。