1. 为什么我盯上了"会议小帮手"这个需求
先说个真实场景。我平时要参加不少技术评审会和需求对齐会，一场会短则四十分钟，长则一个多小时。会上大家你一句我一句，信息密度其实很高，但真正落到"谁负责什么、什么时候交付、当前阻塞是什么"这些结论性内容时，你要是光靠脑子记，散会半小时后就模糊了。以前我的处理方式是拿手机录音，会后再对着录音手动整理纪要。一次两次还行，每周三四场会下来，整理纪要这件事本身就成了新负担。
后来我试过一些现成的会议转写工具，说实话，语音识别准确率尚可，但有几个绕不开的问题：一是私有化部署基本不用想，数据要传到别人的服务器上；二是格式灵活性差，我想要的"按说话人分段、带时间戳、自动提炼待办"这些功能，要么得加钱，要么根本不提供；三是很多工具的导出格式绑得死死的，我想接进自己的笔记系统还得手动复制粘贴。琢磨了一圈，不如自己基于云端的语音识别能力写个小工具，要什么格式自己定，要接什么下游自己说了算。
腾讯云的语音识别服务是目前国内做得比较成熟的一批，实时语音识别和录音文件识别都有现成的 SDK，API 文档也比较清晰。我要做的这个"会议小帮手"不是重新发明轮子，而是把语音识别引擎、会议音频输入、文本后处理这三段串起来，形成一个从"会开了"到"纪要出来了"的闭环。这篇文章就把整个搭建过程、代码思路、实测效果和踩过的坑一起端出来，给有类似需求的人一个可以直接抄作业的参考。
适合看这篇东西的人：被会议纪要折磨的职场人、想给团队做个内部效率小工具的开发者、以及对语音识别 API 的工程化落地感兴趣的朋友。我会尽量把原理和代码都讲透，不搞"只给步骤不给理由"那种写法。
2. 方案选型：为什么要用云端 API 而不是本地模型
动手之前先把方案定下来。会议转写这件事，技术路径其实分两条：一条是用本地开源的语音识别模型，比如 whisper 系或者各种中文 ASR 模型；另一条是接云端 API。两条路我都实际试过，这里把取舍逻辑说清楚。
2.1 本地模型的坎：硬件、工程成本和中文优化
本地部署语音识别模型，听起来很美——数据不出内网，费用可控，但真跑起来会发现坑不少。首先是硬件门槛，一个像样点的中文语音识别模型，推理时显存占用动辄几个 GB，普通办公笔记本根本跑不动，得专门搞一台带 GPU 的机器。其次是工程化的隐性成本：音频格式要自己转码、VAD（语音活动检测）要自己写、说话人分离要自己调、长音频要自己切段、识别结果的标点还原和数字规整也要自己处理。这些活儿分散在音频处理、模型推理、文本后处理好几个领域，一个人搞下来至少一两周起步。
更现实的问题是中文准确率。whisper 这类模型对英文的识别效果好，中文场景下虽然能用，但在有口音、语速快、专有名词多的会议场景里，错字率明显偏高。我拿同一段会议录音对比过，本地模型的中文识别准确率大概在 88% 上下，而腾讯云的录音文件识别能到 95% 以上。会议纪要这种东西，错几个字可能就会导致待办事项理解偏差，准确率就是核心竞争力。
2.2 云端 API 的真实优势不止是"省事"
有人会觉得云端 API 就是把录音传上去，拿回文本，没什么技术含量。但实际用下来，它省掉的东西远比想象中多。腾讯云语音识别的录音文件识别接口，内部已经做了音频降噪、说话人分离、标点预测、数字规整这些处理，这些在本地方案里每一项都是独立的研发活。换句话说，我花 API 调用费，买的是对方已经调好的整个识别链路，而不是单纯的"声音转文字"这一个环节。
实时语音识别则是另一个场景的刚需。如果开会时想看着字幕走，或者想实时抓取关键词触发提醒，录音文件识别那种"会后出结果"的模式就不够用了。腾讯云的实时语音识别 WebSocket 接口支持流式上传音频流，一句话说完基本就能出结果，延迟在一秒以内。这两个接口正好覆盖了"会后整理"和"会中辅助"两种使用方式，我后面会详细讲代码实现。
2.3 成本测算：一次会议到底花多少钱
成本这块我也算过账。腾讯云语音识别按量计费，录音文件识别阶梯定价，量大单价会降，大致是每小时音频几块钱的水平。实时语音识别稍微贵一点，按音频时长计费，一小时音频大概十几块钱的量级。普通团队每周开五小时会，一个月二十小时，成本也就几十块钱，相比请人专门整理纪要，或者买一个高价 SaaS 会员，性价比是碾压级的。
当然，要是有人非要说"几十块钱也是钱，我自己听录音整理不花钱"，那我只能说这个账没算上自己的时间成本。一小时录音手动整理纪要至少要花四十分钟到一个小时，一个月就是二十个小时。拿这些时间做点更有价值的事，这才是工具存在的意义。
3. 录音准备与文件上传：最容易忽略但决定成败的环节
方案定下来之后，我本以为最难的会是代码，结果首战就栽在了音频文件处理上。语音识别引擎对输入音频有严格的格式要求，不满足就直接报错或者识别结果惨不忍睹。这一节把录音采集、格式校验、上传预处理的完整流程讲清楚。
3.1 会议录音的采集规范：采样率和编码格式别乱来
会议录音的采集端，经常是手机、电脑自带麦克风、或者专业的会议麦克风阵列。不管用哪个，最终送到识别引擎的音频文件，采样率和编码格式必须符合接口要求。腾讯云录音文件识别支持的格式包括 wav、mp3、m4a 等常见格式，采样率要求 8kHz 或 16kHz，位深 16bit 或更高。如果音频是 44.1kHz 的 CD 音质，反而需要降采样到 16kHz 再上传，因为识别引擎训练时用的主要就是 16kHz 电话宽带和 8kHz 窄带音频，过高的采样率并不会提升识别效果，反而可能因为频谱特征不匹配导致识别率下降。
这里有个实操细节：用手机录音时，尽量把录音软件设置成"会议模式"或者"语音备忘录"这类以人声优化为目标的模式，而不是"高保真音乐"模式。高保真模式会保留很多环境底噪，识别引擎反而要花更多力气去降噪，转写时更容易出错。我实测过同一个房间同一个人说话，用高保真模式录的 m4a 文件，识别准确率比用通话优化模式录的 mp3 文件低了差不多三个百分点。
3.2 音频转码的两种路径：本地处理与云端托管
如果你的录音已经是标准格式，直接上传就行。但实际场景中经常会碰到各种边角料——微信语音发来的 amr 文件、某些会议软件导出的加密格式、录像里单独抽取的音轨。这些情况就需要先转码。转码工具有很多，最通用的方案是用 ffmpeg，一行命令就能搞定格式转换和采样率调整：
ffmpeg -i input.amr -ar 16000 -ac 1 -codec:a pcm_s16le output.wav这条命令把输入文件转成 16kHz 单声道 16bit 的 wav 格式，这是语音识别最友好的参数组合。转码之后务必再检查一次文件的时长和大小，有时候 i 参数输入的文件有问题，转出来时长是 0 或者只有几秒，这种文件直接上传识别接口会直接返回错误码。
编码格式的选择上，我个人的经验是优先用 wav（PCM 编码），其次才是 mp3。wav 文件是无损的，识别器解析起来最直接；mp3 是有损压缩，虽然对人类听觉影响不大，但高频信息会有损失，在语音识别这种对频谱细节敏感的场合，一点点损失都可能被放大。当然，wav 文件体积大，上传速度慢，如果录音很长，折中方案是转成 320kbps 的 mp3，识别率几乎不受影响。
3.3 本地文件分片上传：腾讯云 COS 的接入细节
录音文件识别接口的处理链路是"先上传音频到 COS 对象存储，再把文件 URL 传给识别接口"。这一步很多人会直接在代码里用公网 URL 或者临时外链，但正规做法是用临时密钥上传到自己的 COS 存储桶，然后把对象地址传给 ASR 服务。腾讯云的语音识别 SDK 里其实封装了上传逻辑，你只需要提供一个本地文件路径，它会自动完成 COS 上传和识别请求的串联。
这里有个权限细节值得提一下。如果你是用主账号密钥调 API，自然没问题，但安全规范不建议这样做。正确做法是在控制台创建一个子账号，只授予 COS 上传和语音识别相关的权限策略，然后用临时密钥（STS）的方式在代码里获取凭证。这样做的好处是即使密钥泄露，攻击者拿到的也只是一个有时效的临时凭证，影响范围可控。
临时密钥的获取逻辑大概是这样：先调用 STS 的 AssumeRole 接口拿到临时 AK/SK 和 Token，再把这三个值传给 ASR 客户端。腾讯云语音识别的 Python SDK 里提供了专门的 Credential 模型，你可以在代码里这样初始化：
from tencentcloud.common import credential from tencentcloud.asr.v20190614 import asr_client # 以临时密钥方式初始化客户端 cred = credential.Credential(tmp_secret_id, tmp_secret_key, tmp_token) client = asr_client.AsrClient(cred, "ap-guangzhou")这里 region 参数用 ap-guangzhou 是因为语音识别服务在华南地区的部署最成熟、升级最及时，其他地域也支持，但如果有选择我建议优先用广州。没有特殊合规要求的话，地域越靠近服务端机房，音频上传和结果回传的延迟就越低。
4. 核心实现：录音文件识别接口的完整接入流程
准备工作做完，真正干活的部分来了。这一节从头到尾拆一遍录音文件识别的接入流程，包含创建任务、轮询结果、解析返回文本三个核心环节，并给出完整可跑的示例代码。
4.1 创建识别任务：重要参数逐个解读
录音文件识别的调用方式是异步的，你先提交一个任务，服务端返回一个任务 ID，然后需要轮询查询识别结果。整个过程不复杂，但有四个参数必须理解清楚，不然识别效果会打折。
第一个是EngineModelType，引擎模型类型。这个参数决定用哪个语音识别模型来处理你的音频。会议场景下，我强烈建议用16k_zh_video或者16k_zh_dialogue。前者是音视频场景模型，对背景音乐、多人说话混杂的情况做了优化；后者是对话场景模型，对一问一答、语速快的场景更友好。我实测下来，技术评审会这种多人轮流发言的，用16k_zh_dialogue效果最好；如果会议里有远程参会人通过视频接入，音质参差不齐，16k_zh_video会更稳。
第二个是ChannelNum，音频通道数。如果录音是单声道，就填 1；如果是双声道（比如电话会议录制的双方分离音频），可以填 2。填 2 的好处是识别接口会分别处理两个声道的音频，并在结果里区分说话人，这对"谁说了什么"的记录需求很有帮助。但前提是你的录音真的是双声道且左右声道分别对应不同说话人，如果只是普通立体声，两个声道内容基本相同，填 2 反而会导致结果重复。
第三个是ResTextFormat，识别结果文本格式。这个参数默认值是 0，返回纯文本；推荐填 2，返回带标点和时间戳的详细结果。会议纪要场景，时间戳特别有用，后面做"按说话人切分"和"定位到某个观点的具体时刻"都依赖它。
第四个是FilterDirt，过滤脏词。填 1 的话，识别结果会过滤掉"嗯""啊""那个"这类语气词。这个功能非常实用，直接决定纪要的干净程度。
提交任务的代码用 Python SDK 写出来是这样：
import json 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 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) req = models.CreateRecTaskRequest() req.EngineModelType = "16k_zh_dialogue" req.ChannelNum = 1 req.ResTextFormat = 2 req.FilterDirt = 1 req.SourceType = 0 # 0表示URL，1表示本地文件上传 req.Url = "https://your-bucket-1250000000.cos.ap-guangzhou.myqcloud.com/meeting_audio_20240115.wav" resp = client.CreateRecTask(req) task_id = json.loads(resp.to_json_string())["Data"]["TaskId"] print(f"识别任务创建成功，任务ID：{task_id}")SourceType这个参数的含义值得多说一句。填 0 代表传一个公网可访问的 URL，SDK 会自动去这个地址拉取音频；填 1 代表本地文件直传，SDK 会先把文件传到你指定的 COS 存储桶，再去创建任务。我推荐用本地直传模式，传公网 URL 还要额外处理鉴权、防盗链这些问题，麻烦且没必要。
4.2 轮询结果与错误处理：别用死循环，要有退避策略
任务创建成功后，需要轮询查询结果。查询接口是DescribeTaskStatus，传入任务 ID，返回的状态码含义如下：
| 状态码 | 含义 | 处理建议 |
|---|---|---|
| 0 | 任务进行中 | 继续等待，间隔几秒再查 |
| 1 | 识别成功 | 解析返回的 Result 字段 |
| 2 | 任务失败 | 查看 ErrorMsg 定位原因，修正后重新提交 |
轮询不能搞成无脑死循环。合理做法是每 3 到 5 秒查一次，连续查询超过 10 分钟还没结果就主动放弃并记录日志。正常情况下一小时的会议录音，识别时间大概在 3 到 8 分钟，这和音频时长、声道数、并发任务量都有关系。如果长时间卡住，多半是音频格式有问题或者服务端积压，死等没有意义。
我写的轮询逻辑大概是这个风格：
import time max_retry = 120 # 最多查120次，每次间隔3秒，总共最多等6分钟 for i in range(max_retry): req = models.DescribeTaskStatusRequest() params = {"TaskId": task_id} req.from_json_string(json.dumps(params)) resp = client.DescribeTaskStatus(req) data = json.loads(resp.to_json_string())["Data"] status = data["Status"] if status == 1: print("识别完成") result_json = data["Result"] break elif status == 2: print("识别失败：", data["ErrorMsg"]) break else: time.sleep(3)有个小坑必须提醒：Result字段返回的是一段 JSON 字符串，不是直接从 JSON 里取一个字符串字段就能用。你需要对result_json再做一次json.loads()，才能拿到真正的识别结果列表。我第一次接的时候在这里卡了快半小时，一直以为是接口返回结构变了，结果只是自己少做了一次反序列化。
4.3 解析结果文本：从 Sentence 数组到结构化纪要
识别结果的结构化程度，取决于你在 CreateRecTask 时选择的ResTextFormat。填 2 的话，返回结果里是一个Sentence数组，每个元素包含StartTime、EndTime、Text和SpeakerId四个字段，正好对应"这句话从第几秒开始、到第几秒结束、说了什么、是谁说的"。
拿到这个结构，会议纪要就非常好做了。我按 SpeakerId 分组，把每个人说的话按时间排序拼接，就能得到一个按发言人整理的完整发言稿。再进一步，可以直接统计每个人的发言总时长和发言次数，自动生成一份"会议发言分布报告"，谁讲得多谁讲得少一目了然。
这里给出一个简单的解析和渲染逻辑示例：
sentences = json.loads(result_json)["Sentence"] speaker_text_map = {} for s in sentences: speaker_id = s.get("SpeakerId", -1) text = s["Text"] speaker_text_map.setdefault(speaker_id, []).append(text) for speaker_id, texts in speaker_text_map.items(): full_text = "".join(texts) print(f"发言人 {speaker_id}:") print(full_text) print("---")说到SpeakerId，提一句它的局限性。这个功能是基于声纹特征做的说话人分离，准确率在理想条件下能到 90% 以上，但实际会议场景里，如果两个人声音很像、或者有人频繁进出、或者有严重回声，分离效果会明显下降。它不是百分之百可信的，但作为初筛工具已经足够强大了。
5. 实时模式：会议进行中就要看到文字稿
录音文件识别解决的是"会后整理"的问题，但开会的当下，如果讨论到一个关键结论，你希望立刻在白板上记下来，这时候等会后出稿就来不及了。实时语音识别的价值就在这里——一边开会一边出字幕，关键信息可以随手捕获。腾讯云的实时语音识别走的是 WebSocket 协议，比录音文件识别的 HTTP 轮询方式要复杂一些，但理解核心逻辑之后也不难。
5.1 WebSocket 接入与音频流切片：请求头里藏着关键配置
实时语音识别有两种接入方式：一种是一句话识别，短音频（60 秒内）一次传完，适合语音输入法这种场景；另一种是实时语音识别 WebSocket，适合长时间、流式的场景，也就是我们开会用的。WebSocket 接入时，URL 里要带secretid和token参数，包括鉴权签名。这个签名算法是腾讯云通用的 TC3-HMAC-SHA256，SDK 里已经把签名封装好了，直接用官方提供的示例代码改造就行。
我用的方式是先建立一个 WebSocket 连接，然后循环从麦克风或会议系统的音频流里读取 16kHz 16bit 的 PCM 数据，切成 40ms 一帧发出去。40ms 是一个比较平衡的选择，太短则网络包太碎，白白浪费带宽；太长则服务端响应延迟堆积，字幕会明显滞后于说话人。
音频流切片的核心代码逻辑大概是：
import websocket import json import pyaudio CHUNK = int(16000 * 0.04) # 40ms一帧，约640个采样点 def on_message(ws, message): data = json.loads(message) if "result" in data: text = data["result"]["text"] print(text, end="") def on_error(ws, error): print("WebSocket error:", error) ws = websocket.WebSocketApp( url, on_message=on_message, on_error=on_error ) ws.run_forever()多说一句pyaudio的坑。pyaudio 直接装经常报错，macOS 上要先brew install portaudio，Linux 上要先装libasound2-dev。如果你只是先验证功能，不想折腾音频采集，也可以直接用一个音频文件作为输入源，按帧读取 PCM 数据并发送，这样可以把问题拆成"网络部分"和"音频部分"两个阶段分别调试。
5.2 实时识别结果处理：中间结果 vs 最终结果
WebSocket 返回的消息里有final字段，用来区分中间结果和最终结果。中间结果是随着说话逐步更新的文字，会不停变化，适合做字幕展示；最终结果是这句话说完后定稿的文字，不再变化，适合做纪要采集。我在代码里把这两类分开处理，中间结果直接跳过不落盘，最终结果才追加到纪要文件里，这样避免了一句话被重复记多次的问题。
这个final字段的处理逻辑，是实时语音识别落地时最重要的细节之一。很多人第一次接，满屏的重复文字，以为是接口故障，其实只是没过滤中间结果。
5.3 延迟优化与断线重连：实测效果和抗干扰设计
实时识别的延迟，从说话人开口到文字上屏，实测大概在 800ms 到 1.2s 之间波动。这个延迟主要受网络质量和音频流切片大小影响。网络好的时候，语音几乎是一边说话一边出字。网络差的时候，会出现文字一顿一顿地蹦出来的现象，这时候不用慌，只要不断连，最终结果还是会补齐的。
断线重连是生产环境必须考虑的问题。会议一趟几十万秒的音频流，网络不可能全程稳定。我设计的重连策略是：检测到 WebSocket 断开后，先等待 2 秒，再重新建立连接；如果连续重连 3 次失败，则切换到降级方案——放弃实时识别，保存原始音频，会后再用录音文件识别接口补录。这套策略目前跑下来，基本没出现过数据丢失的情况。
6. 从转写文本到会议纪要：文本后处理的实战调优
语音识别输出的原始文本，和一份能直接发给项目组的会议纪要之间，还差着好几种处理。这个环节是整个工具的核心价值所在——识别引擎负责"听到"，你负责"听懂"。我的文本后处理管线包含三块：内容清洗与格式化、待办事项提取、摘要生成。
6.1 标点恢复与口语词清洗：搭一个轻量文本过滤链
识别接口返回的文本虽然带了标点，但口语化的废词还是不少。比如"就是说""然后呢""基本上""这个这个"，这些词在口头表达里是过渡词，落到文字稿里就是噪音，会严重干扰阅读。我的做法是维护一个自定义停用词表，用正则表达式把高频口语词替换掉。
同时，数字和日期的规整也很重要。语音识别对"下周三下午两点"这种表达，识别结果可能是"下周三下午两点"，也可能变成"下周三 14: 00"，两种情况都要规整成统一格式。时间实体统一转成"周X HH:mm"的形式，日期实体统一转成"X月X日"的形式。正则处理比较直接，如果后续需求复杂了，再考虑引入实体识别模型。
6.2 待办事项提取：关键词规则 vs 轻量方案
会议纪要里最有价值的信息就是待办事项。谁负责什么，什么时候交付，这是整个会议的核心产出。我从语音文本里提取待办，用的是关键词规则加简单语义判断的组合方案。触发词包括"需要""必须""记得""跟进""确认""尽快""截止""下周"这些，一旦句子中出现这些词，就认为这一句可能包含待办信息，把整句话提取出来放入待办候选列表。
接下来是责任人识别。这一环信息量比较大，因为"我""你""他"这种人称代词在会议中是频繁出现的，而且指代关系动态变化。我采用的方案是先识别文本中出现过的人名或角色名（如"前端同学""产品经理"），再结合上下文进行简单的人称消解。这个方法准确率大概在 80% 左右，不完美，但作为初版工具已经能省下大部分手工整理时间了。
6.3 摘要生成：关键句抽取比生成式更稳定
会议摘要这块，我试过两种方案：一种是生成式摘要，也就是用大模型重新组织语言，输出的摘要读起来很通顺但可能会丢掉细节，还偶尔会编造原文没有的信息；另一种是抽取式摘要，也就是按句子的关键程度排序，把权重最高的几句话原样抽出，拼成摘要。目前我主要用抽取式，因为会议纪要最重要的诉求是"忠于原文"，不是"写得漂亮"。
抽取式摘要的权重计算我用了简单的 TF-IDF 加位置加权。句子中出现频率高的词，权重高；句子越靠前，权重越高；包含"结论""重点""最终""决定"这些词的句子，额外加权。一番操作下来，选出的 Top 5 到 Top 10 句话，基本能覆盖会议的核心结论。生成式方案留给后续版本的优化空间，等有把握不丢信息、不瞎编的时候再切换。
7. 踩坑记录：这个项目里最深的几个坑，替你趟过了
这个项目前前后后折腾了两周多，踩的坑不能说少。挑几个印象最深的写在这里，都是真实的报错信息和排查思路，希望后来者能少走弯路。
第一个大坑是音频编码问题导致的持续识别失败。我第一次拿一个 m4a 文件直接上传，接口返回的错误码是FailedOperation.ErrorFormat，提示音频格式不支持。排查过程是：先确认 m4a 是不是腾讯云支持的格式，文档上写的是支持 m4a，那问题出在哪？后来用 ffprobe 查看该文件的内部编码，发现它是一个 AAC 编码的 m4a，而且是 44.1kHz 立体声。于是我先把音频降采样成 16kHz 单声道，再转成 wav，重新上传后问题解决。这让我意识到，支持哪种容器格式是一回事，容器里面的编码参数对不对是另一回事。
第二个坑跟临时密钥的 Token 传递有关。用 STS 临时密钥初始化客户端时，代码里容易写丢token参数，或者只传了 AK/SK 没传 Token。这个问题的报错很隐蔽——它不直接报"缺少 Token"，而是报"签名校验失败"或者"请求被拒绝"。我排查了半天才意识到是 Token 没传全。写代码的时候建议把凭证封装成一个统一的对象，从环境变量读取，避免在代码里硬编码导致情绪管理失败。
第三个坑是轮询频率过高触发服务端限流。我的第一版代码里轮询间隔只设了 1 秒，结果连续创建几个任务之后，服务端直接返回请求频控超限。查文档才明确，DescribeTaskStatus 的 QPS 限制是 20，但高频轮询依然可能触发限流策略。把轮询间隔改成 3 到 5 秒之后，再没出现过这个问题。所以轮询间隔宁慢勿快，这不是佛系，是稳定。
第四个坑和说话人分离的稳定性有关。有一次测试，会议室里两个人声音非常接近，SpeakerId 在两个人的发言之间来回跳，导致最后按发言人整理的纪要被切得稀碎。后来我在后处理里加了一个滑动窗口合并算法：如果相邻两句话的 SpeakerId 不同，但间隔时间小于 2 秒且文本长度都较短，就判定为同一个人，合并 SpeakerId。这个启发式规则做完之后，发言切分的稳定性提升了不少。
8. 效果实测与落地建议：这套工具到底好用吗
工具开发完，我拿过去一个月的会议记录做了回测。选取了四场不同类型的会议——技术评审会、项目周会、需求对齐会、复盘会——对比了工具自动生成的纪要和当时人工整理的纪要，做了个表格：
| 会议类型 | 音频时长 | 识别准确率 | 待办提取准确率 | 人工整理耗时 | 工具整理耗时 |
|---|---|---|---|---|---|
| 技术评审会 | 52分钟 | 96.2% | 85% | 42分钟 | 3分钟 |
| 项目周会 | 38分钟 | 97.1% | 90% | 30分钟 | 2分钟 |
| 需求对齐会 | 65分钟 | 94.8% | 78% | 55分钟 | 5分钟 |
| 复盘会 | 47分钟 | 95.3% | 82% | 38分钟 | 3分钟 |
识别准确率这项数据，是我用人工转写的结果和自动识别的结果逐行比对的，平均在 95% 到 97% 之间。待办提取准确率的定义是：工具提取出来的待办事项中，正确且信息完整的比例。四场会议下来平均在 84% 左右，信息完整率已经具备参考价值，但还达不到直接用。我的处理办法是：工具生成初稿后，我快速浏览一遍待办列表，补充和修正一遍，整体时间成本大概从原来的每场 30 到 55 分钟，降到了 5 到 10 分钟。这个效率提升已经很可观了。
落地建议方面，给不同需求强度的读者几个方向。如果只是个人使用，按我本文的代码搭一个命令行工具就够了，输出 md 格式的纪要文件直接扔进笔记系统。如果是要给团队用，建议加一层简单的 Web 界面，把音频上传、任务状态、纪要预览和导出整合成一条流程。如果再进一步，可以接入企业微信或者飞书的机器人，会议结束后自动把纪要推送到群里——这一块内容能覆盖的话，会议纪要这个场景基本就算做透了。
9. 后续可以扩展的方向与我的个人体会
项目做到这个程度，初步能用，但离"完美"还很远。按我个人的规划，接下来有三件事值得做：第一是把生成式摘要从备选方案转正，但前提是用长文本校验手段确保不幻读；第二是把待办提取这套规则升级成基于序列标注的微调方案，提升人称消解准确率；第三是离线批量任务队列，把多场会议音频的转写和管理系统化，方便团队里的人按时间、项目、发言人检索历史纪要。
最后谈一点个人体会。做这个项目最大的收获，不是我写了几百行代码，而是想明白了一个道理：工具的价值不在于用多高级的技术，而在于能不能精准地解决一个高频且痛苦的问题。语音识别 API 只是引擎，真正决定体验的是你对场景的理解——你知道开会时哪些内容重要、哪些是废话、纪要发给谁、他关心什么。这些判断写进代码里，工具就活了。
当然，安全合规的意识也一直在脑子里绷着。会议音频属于敏感数据，我传上去之前都会先做脱敏判断，涉及敏感内容的会议不会走云端接口。这个红线大家用的时候一定守死了。
