从录音到结构化纪要：本地AI会议记录链路搭建与调优

会议结束的那一刻，真正的活儿才刚开始。录音文件躺在那里两个多小时，你要一边拖动进度条一边把"谁承诺了什么、哪个问题被搁置了、下周谁交什么东西"从三千句闲聊里捞出来，这种经历但凡经历过几次，就会开始琢磨有没有更省事的路子。我后来把整条链路搬到了本地，用的就是Meetily这套思路的本地 AI 助手：音频不出机器，转写、分轨、摘要全部在本机跑完，散会十分钟内拿到一份带说话人标签、带行动项的结构化纪要。这篇东西讲的就是它背后那条流水线怎么搭、参数怎么定、坑在哪。适合三类人看：远程会议多到麻木的、讨论内容不适合往外传的、手里有一台还算能打的机器并且愿意花一个下午折腾一次的。如果你只想开箱即用、一点配置都不想碰，那这篇大概率会让你觉得麻烦，可以先跳过。

1. 我为什么把会议记录整条链路搬到本地

1.1 会议记录真正的难点从来不是"把话变成字"

很多人对会议记录工具的第一反应是"转写准不准"，但实际用过半年以上就会发现，字面准确率只是及格线。一份能用的纪要，起码要满足三个条件：每句话知道是谁说的、散落的讨论能收敛出结论、承诺的事情变成可追踪的行动项。这三个条件里，第一个靠声学，后两个靠语义整理，而绝大多数通用工具只做了第一层，把一段音频变成一大坨没有归属的文本，剩下的全靠人再读一遍。我统计过自己的实际耗时分布：两小时的会议，纯转写如果自动完成，人工校对大概 15 分钟；但把这一坨文本整理成别人愿意看的东西，往往还要 40 分钟以上。真正吃掉时间的不是听不清，而是"读不懂结构"。

所以一个真正解决问题的方案，核心不在识别引擎多强，而在于它有没有把"原始语音"到"结构化结论"这段路走完整。这也是我愿意花时间研究 Meetily 这类本地助手的原因：它把分段、识别、说话人归属、文本顺滑、摘要、行动项抽取串成了一条默认就跑通的链路，而不是丢给你一个转写结果让你自己想办法。

1.2 本地跑这件事，省的不只是钱

把整条链路放在本机，最直接的理由是内容不出机器。内部的方案评审、客户沟通、人事相关的讨论，这些东西上传到任何外部服务，哪怕对方承诺不保留，心里那道坎也过不去。第二个理由是可控：模型版本、提示词、输出格式、保留多久，全在你自己手里，想加一个"自动把行动项同步进待办清单"的钩子，改三行脚本就行。第三个理由才是成本——按次计费的服务用久了，一次两小时的会议折算下来并不便宜，而本地跑除了电费和机器折旧，边际成本几乎为零。

代价当然也有。你要自己管模型文件、自己配音频路由、自己在显存不够的时候降级。这些东西第一次配起来大概要一个下午，之后就基本是"开机就跑"的状态。我的判断标准很简单：如果你每周有三次以上、每次超过 40 分钟的会议需要留档，那这一个下午的投入两三个月就回本了。

1.3 什么样的场景适合，什么样的场景别硬上

先说适合的：跨地域远程会议为主的团队、需要长期保留讨论过程做回溯的项目、内容敏感度较高不方便外传的场合、以及手上有独立显卡或者统一内存容量较大的机器（16GB 内存起步，能到 32GB 会舒服很多）。这套链路在纯 CPU 上也能跑，只是速度会退到接近 1:1 甚至更慢，长会议体验会明显打折。

再说别硬上的：如果你的会议几乎全是线下多人围着一台设备说话，没有独立的音频输入通道，说话人分离会变得非常吃力；如果你需要多人实时协同编辑同一份纪要，本地单机方案天生不擅长，得额外接一个自建的同步服务；如果你的机器是几年前的轻薄本、内存只有 8GB，那跑起来的体验会让你怀疑这套方案的价值。工具选型最怕的就是"看到别人说好用就上"，先看自己的场景和硬件，再决定要不要投入。

2. 整条流水线的架构拆解

2.1 从一段音频到一份纪要，中间有六个环节

我把 Meetily 的处理流程拆成六个环节，每个环节职责边界清晰，出问题时也容易定位到具体哪一步。下面这张表是我自己整理的心智模型，建议先记住它，后面所有参数讨论都围绕这张表展开。

这张表里最容易被低估的是"顺滑"和"摘要"之间的衔接。很多人以为转写出来就能直接喂给模型总结，实际上没有标点、没有分段、满是"那个""就是说"的原始文本，会让摘要模型的表现明显下降——它要花大量注意力在"这句话到底在哪断句"上，留给"这句话是什么意思"的注意力就少了。所以顺滑这一步不能省。

2.2 为什么我坚持双路采集，而不是事后盲分离

这是整个方案里我认为最关键的一个设计决策。开会的时候，声音其实来自两个不同的地方：远端参会者的声音是从系统播放出来的，本地参会者的声音是从麦克风进来的。如果用虚拟回环设备把系统播放单独录一路、麦克风单独录一路，那你天然就拿到了两条已经分好说话人的音轨——远端所有人合并在 A 轨，本地所有人合并在 B 轨。

这听起来很粗糙，但它解决了一个大麻烦。纯软件的说话人分离（也就是大家常说的"声纹聚类"）在真实会议里的准确率远没有 demo 里那么好看：抢话、短应答（"对""嗯""好"）、音色相近的人、以及一句话说到一半换人，这几种情况几乎必错。而双路采集在物理层面就规避了绝大多数跨端混淆，剩下的只需要在每一路内部再做细分。我在几个不同规模的会议上对比过两种做法，双路采集的标签准确率体感上明显更高，而且稳定——不会出现同一场会里标签莫名其妙互换的情况。

代价是配置麻烦。你需要装一个虚拟音频设备，把系统输出同时路由到扬声器和这个虚拟设备，然后在录音程序里指定两个输入源。Windows、macOS、Linux 各有各的做法，这块后面第 4 章会具体讲。我的经验是：这一步值得花时间，因为它决定了后面所有环节的天花板。

2.3 三种运行模式的取舍：实时、准实时、离线

Meetily 这类工具通常支持三种处理节奏，选哪种直接决定了资源占用和体感。

实时流式：音频一边进来一边出字，延迟 1 到 3 秒。适合需要边开会边看转写的场景，比如听力不太好的时候做辅助。缺点是识别模型只能用小的，精度打折扣，而且对机器是持续压力。

准实时分块：每 20 到 30 秒切一块送进识别，延迟半分钟到一分钟。这是我日常用的模式，精度和延迟平衡得最好，而且因为每次处理的是完整的一句话或一小段，识别模型有足够上下文，准确率比逐帧流式高不少。

离线批处理：会议结束之后一次性跑完整段音频。精度最高，因为可以用大模型、可以双向上下文、可以做全局的说话人聚类。缺点是拿不到即时反馈。

我的建议是准实时 + 会后重跑：开会时用准实时模式保证不会漏、能大致看到内容；散会之后如果这份纪要很重要，用离线模式再跑一遍替换掉，成本也就是多等十几分钟。这两个模式共用同一套模型和提示词配置，切换成本几乎为零。

3. 核心细节：从声波到可读文本的关键处理

3.1 采样率定在 16kHz，是一笔算得很清楚的账

采集环节第一个要定的参数就是采样率。我的结论很明确：16kHz、16bit、单声道，够用且省。理由分两层。

第一层是物理层面。人的语音能量主要集中在 80Hz 到 8kHz 之间，更高频的成分对"听清说的是什么"贡献极小。根据采样定理，要无失真地还原 8kHz 以内的信号，采样率至少要到 16kHz，所以 16kHz 正好卡在这个临界点上。再往上采样，多出来的部分基本是气声和齿音的细节，对识别准确率的提升微乎其微，但数据量是线性增长的。

第二层是工程层面，算一下就知道差多少。16kHz × 16bit × 单声道 = 每秒 32KB，也就是每分钟约 1.92MB，一小时会议约 115MB。同样一段内容，如果按 48kHz、24bit、立体声存，是每秒 288KB，每分钟 17.3MB，一小时超过 1GB。差了将近十倍。这两个数字直接决定了你的磁盘规划、内存缓冲大小、以及预处理要花多久。

提示：如果你的采集设备只支持 48kHz，不要让它直接输出 48kHz 给后续环节，用重采样先降到 16kHz 再做 VAD 和识别。重采样本身很便宜，但让后续每一步都处理三倍数据，累积起来就是明显的浪费。

3.2 VAD 切分：参数背后的三个矛盾

VAD（语音活动检测）负责把连续音频切成一段一段。这一步看似简单，实际是整个链路里最需要调参的地方，因为它要同时满足三个互相矛盾的目标：不能吃字、不能切太碎、不能一段太长。

吃字通常发生在语音开头。人说话的第一个音节往往是轻声或者爆破音，能量很低，如果 VAD 的起判阈值设得太高，开头半个字就被切掉了。我的做法是在检测到语音起点后向前回退 200 到 300 毫秒，宁可多带一点静音，也不能丢字。同理，尾部的收尾音（比如"了""的"这种轻声）也容易被误判为静音，所以从检测到静音到真正切断，要留300 到 500 毫秒的缓冲。

切太碎的问题在于，识别模型需要上下文。一句 8 个字的话如果被切成三段，每段都缺少前后文，识别准确率会明显下降，而且时间戳会变得零碎。所以我会设一个最短片段长度 250 毫秒，短于这个的碎片直接并入前一段。

一段太长的问题在识别模型的输入上限。大部分模型单次能吃的音频在 30 秒左右，超过之后要么报错要么内部截断，后者更危险，因为你不容易发现。所以要设一个强制切分上限 30 秒，到点就切，哪怕还在一句话中间。切的时候相邻两段留 200 毫秒重叠，这样即使切点落在字中间，两边都能各自识别出完整的字，后续去重时按时间戳合并即可。

3.3 识别之后的"顺滑"，比想象中重要

原始转写结果大概是这个画风："那个我们这个方案的话就是说可能还需要再评估一下对对对然后下周三之前能不能给个结论"。这句话人类读起来勉强能懂，但直接丢给摘要模型，它会浪费大量算力在解析这些冗余词上，甚至把"对对对"理解成某种肯定结论。

顺滑处理我一般做四件事。加标点：用一个小型的标点恢复模型，或者干脆让本地总结模型在总结阶段顺带做（但这样会污染摘要的注意力，我更倾向独立做）。数字与专名规范化：把"二零二五"统一成"2025"，把团队内部常用的项目代号、人名、产品名放进热词表做强制纠正，这一步对纪要的可读性提升非常直接——一份到处是错别字的纪要，读的人第一反应就是不信任。去重：重叠切分会导致切点附近的词重复出现，按时间戳做一次合并去重。口头语处理：这块要克制，我一般只删掉纯粹的填充词（嗯、啊、那个），"就是说""其实"这类带有语气信息的词保留，因为它们有时能反映出说话人的犹豫态度，对理解讨论进程有帮助。

注意：不要用大模型对转写文本做"润色重写"。看起来很美，但它会悄无声息地改掉原话的意思，而纪要这种东西一旦有一句话不是原意，整份的可信度就崩了。润色只做标点和格式，内容层保持原样。

3.4 说话人标签怎么落到每一行

前面说了双路采集解决了跨端的问题，但同一路内部还要细分。比如远端有五个人在开会，A 轨里混着五个人的声音，你还是需要知道哪句话是产品说的、哪句话是技术说的。

这里用的是声纹嵌入加聚类。流程是这样的：对每个语音片段提取一个固定维度的声纹向量，然后把一场会议里所有片段向量做聚类，簇的数量通过轮廓系数或者简单的距离阈值来自动确定。这里有个非常实用的技巧：开头 30 秒做一次声纹注册。会议刚开始时让每个人说一句话，或者干脆手动给前几句话打上标签，后面所有片段跟这几个注册样本做相似度匹配，比完全盲聚类稳定得多。因为盲聚类的簇数估计经常出错，五个人被聚成三个或者七个的情况我都遇到过。

还有一个现实约束：不要追求完美。真实会议里"对""嗯""好"这种一两个字的应答，声纹信息太少，聚类几乎必错。我的处理策略是给这类超短片段单独打一个"未标注"标签，或者在双路模式下直接继承当前时间窗内主导说话人的标签。接受 90% 的准确率，比花三倍力气追求 98% 要划算得多。

4. 实操：一个下午搭起一条能跑的流水线

4.1 环境准备：先把目录和磁盘算清楚

我习惯先把目录结构定死，后面所有脚本都往这个结构里放，换机器的时候直接整体拷走。

meetily-local/ ├── models/ # 语音识别 + 总结模型权重 ├── audio/raw/ # 原始双路音频（临时） ├── audio/normalized/ # 16k 单声道规范化后音频 ├── out/transcript/ # 分段转写 JSON ├── out/notes/ # 最终纪要 Markdown ├── config/ # 热词表、提示词模板、参数 └── logs/

磁盘估算按前面算的数字来：一小时会议规范化后约 115MB，两路就是 230MB；转写 JSON 大概每小时的文本折算下来 300 到 500KB；纪要 Markdown 几十 KB。所以一场两小时的会议，全链路临时占用不到 1GB。模型权重才是大头，语音识别模型从几百 MB 到 1.5GB 不等，总结模型视量化等级从 2GB 到 15GB 不等。我的建议是至少留 30GB 空闲，把不同量化等级的模型都放一份，方便按场景切换。

Python 环境我建议独立建一个虚拟环境，依赖其实不多：音频处理、数值计算、一个本地推理运行时、再加一个 HTTP 客户端。装完大概两三分钟。

4.2 音频路由：整个配置里最容易卡住的一步

这一步是新手上手最大的门槛。目标是让系统在播放声音的同时，把播放的内容"复制"一份到一个虚拟录音设备上，这样录音程序就能同时拿到"系统播放"和"麦克风"两路。

以常见桌面系统为例，思路都是装一个虚拟音频设备（回环设备），然后在系统的声音设置里启用"监听"或者"环回"功能，把主输出同时送到这个虚拟设备。接着在录音程序里指定两个输入源：一个是虚拟设备（对应远端声音），一个是物理麦克风（对应本地声音）。

几个必须注意的点：统一采样率。虚拟设备、麦克风、录音程序三者的采样率要一致，否则系统会在中间做一次质量未知的重采样，严重的会导致声音变调或者出现周期性咔哒声。关掉回声消除。很多系统默认开着回声消除，它会对麦克风输入做处理，但对虚拟设备那一路做处理就会破坏原始信号，甚至引入延迟导致两路对不齐。麦克风增益不要拉满。增益过高导致的削波失真，对识别的伤害比音量偏小大得多，宁可小一点后面做归一化。

配好之后一定要做一次十分钟的试录，然后分别播放两路，确认 A 轨只有远端声音、B 轨只有本地声音、两路时间轴对齐。这一步不验证，后面所有分析都是在错误数据上做的。

4.3 转写服务的启动与关键参数

转写服务我一般起成本地 HTTP 服务，这样采集端和识别端解耦，可以单独重启某一边，也方便后面接入别的输入源。

# 示意：启动本地识别服务 asr-server \ --model ./models/asr-zh-small \ --device auto \ --port 8421 \ --max-segment-sec 30 \ --overlap-ms 200 \ --hotwords ./config/hotwords.txt \ --timestamps true

几个参数值得解释。--device auto让它优先用加速设备，没有就退到 CPU，这个在换机器的时候很省事。--hotwords是热词表，一行一个词，团队内部的代号、人名、产品名、专业术语都往里塞，实测对专有名词的纠错效果非常明显，比事后用规则替换靠谱得多，因为识别阶段就纠正了，不会污染后面的上下文。--timestamps true必须开，没有时间戳你就没法做说话人归属、没法在纪要里回链到原始音频、没法做重叠去重。

批量处理的时候，batch_size是个需要调的参数。太小则吞吐上不去，太大则显存会炸。我的经验值是先用 1 跑通，然后逐步翻倍，直到显存占用超过 80% 再退回来一档。

4.4 摘要环节：提示词和结构化输出是重点

摘要这一步决定纪要能不能用。我的做法是强制模型输出 JSON，而不是自由文本。自由文本看起来漂亮，但你没法做后续处理——行动项没法自动进待办，决议没法自动索引。

{ "title": "会议主题", "duration_min": 0, "attendees": ["说话人1", "说话人2"], "decisions": [ {"content": "决议内容", "support": "支持该决议的原话要点"} ], "action_items": [ {"task": "具体动作", "owner": "责任人", "due": "截止时间或未指定", "context": "背景一句话"} ], "open_questions": ["未解决、需要下次继续讨论的问题"], "topic_timeline": [ {"start": "00:12:30", "topic": "讨论主题"} ] }

这里有几个防幻觉的设计，是我踩坑之后加上的。责任人字段允许填"未指定"。如果不允许，模型会硬编一个名字出来，而且编得特别自信。每个决议要求给出支持它的原话要点。这一条让模型必须回到原文找依据，凭空生成决议的概率大幅下降，而且人工复核时可以直接对照。明确告诉模型"没有就留空数组"。空数组比编造内容有价值得多。时间戳必须来自原文，不允许模型自己推算，防止出现"下周三"被算成一个具体日期但算错的情况。

4.5 长会议的分块摘要策略

两小时的会议，转写文本大概三万字左右，折算成 token 数量在两万到两万五之间，超过了很多本地小模型的有效上下文窗口。硬塞进去的结果是模型开始"忘记"开头的内容。

我用的是两层 map-reduce。第一层按话题切块，每块控制在 3000 到 4000 字（大约一次 10 到 15 分钟的讨论），每块单独生成一份局部摘要，包含该块的讨论要点、临时决议、行动项。第二层把所有局部摘要再合成一份全局纪要。第一层的块切分不按固定字数，而是优先在话题切换处切——识别文本里出现明显的转折（"好，下一个议题""这个问题先放一放"）就在那里断开。这样每块内部语义连贯，摘要质量明显更好。

第二层合并的时候要注意去重和冲突处理。同一件事可能在不同块里被讨论两次，第一次说"暂定方案 A"，第二次说"改用方案 B"。我让合并步骤显式处理这个情况：如果同一主题出现多次，以最后一次为准，并在纪要里标注"该议题经历了方案调整"。

5. 性能实测与调优：不同硬件怎么跑得动

5.1 三档配置的实测体感

下面的数据是我在自己和同事的几台机器上跑出来的体感区间，不是精确 benchmark，但用来判断"我这台机器行不行"够用了。测试样本是一段 60 分钟的中文会议录音，双路，准实时模式。

"总倍速"指的是处理耗时除以音频时长。1.2x 意味着处理比实时还慢，只能会后批处理；0.2x 意味着 60 分钟的会议 12 分钟出结果，可以边开会边看；0.08x 基本就是实时可用，甚至可以开着实时模式开会。

值得注意的是，入门档的瓶颈几乎全在识别环节，摘要环节反而没有想象中慢——因为摘要处理的是文本，token 数量相比音频样本数少得多。所以如果你只有 CPU，优先考虑换一个更小的识别模型，而不是去优化摘要。

5.2 量化等级怎么选，别迷信最低比特

本地总结模型基本都要做量化才能塞进消费级显存。量化本质上是用精度换空间：把权重从 16 位浮点压到 8 位、4 位甚至更低。粗算一下，一个 70 亿参数的模型，16 位精度下光权重就要 14GB，加上推理时的中间缓存，8GB 显存的卡根本放不下；压到 4 位大概 4 到 5GB，就能舒服跑起来了。

但量化不是越低越好。我实测下来，4 位量化是性价比的拐点：再用更激进的方案，模型在"严格遵守输出格式"这件事上会开始掉链子——JSON 少个括号、字段名拼错、该留空的数组硬编内容，这些在纪要场景里是致命的。而 8 位相比 4 位，质量提升有限，显存却翻倍。所以我一般固定用 4 位，只有在显存实在紧张的时候才降级，降级之后必须重新验证一遍输出格式的稳定性。

提示：切换量化等级之后，别只看"能不能跑通"，一定要拿同一段真实会议录音跑一遍，对比两次输出的行动项数量和质量。格式崩坏往往不是每次都发生，而是十次里错三次，非常隐蔽。

5.3 长会议的内存管理

两小时以上的会议，除了上下文问题，还有一个容易忽略的点：中间结果的累积。分段转写的 JSON、声纹向量、局部摘要，这些东西如果全放在内存里不释放，到了后半程会看到内存占用一路往上爬。

我的做法是每处理完一个分块就把结果落盘，只在内存里保留一个索引。这样即使中途崩了，重启之后能从断点继续，不用从头再来——这个特性在我第一次跑一场三小时会议、到 80% 的时候显存溢出崩溃之后，被我加进了必备清单。

另外，声纹聚类的计算建议延迟到最后统一做，而不是边流式边聚。边流式聚类的问题是早期的簇中心不稳定，后面每来一个新片段都可能引发重新分配，计算量累积起来很可观，而且标签会来回跳。统一做的话，一次性对所有向量做聚类，既快又稳定。

6. 常见问题排查实录

6.1 转写层问题速查表

这张表里我遇到最多的是"大段缺失"。第一次碰到的时候以为模型崩了，折腾半天才发现是 VAD 把两个人的快速对话识别成了背景噪声，因为当时会议室空调声很大，能量阈值被背景噪声顶得很高。后来我加了一个自适应的噪声底估计——开头几秒先静默采一段，把这段的平均能量作为基线，动态调整阈值。这个改动之后，同类问题基本没再出现过。

6.2 摘要层的幻觉，和怎么把它关进笼子

摘要环节的幻觉比识别错误更危险，因为识别错了你一眼能看出来（"这句话根本不通"），而幻觉生成的内容读起来非常顺，不核对原文根本发现不了。我遇到过的典型形态有三种。

第一种是凭空生成行动项。讨论里只是提了一句"这个可能需要找人看看"，模型把它变成"由某某负责在下周五前完成评估"。这种最坑，因为它看起来合理，进了待办清单之后没人认领，最后变成一个悬空任务。对策是要求每条行动项必须附带原文出处片段，人工复核时对照一眼就能筛掉。

第二种是把讨论中的假设当成结论。讨论里说"如果走方案 A，那可能要延期两周"，模型总结成"项目将延期两周"。对策是在提示词里明确区分"已确认的决议"和"讨论中的假设"，要求后者只能进 open_questions 字段。

第三种是把否定说成肯定。这个是最隐蔽的，"这个方案我觉得不太行"被总结成"方案获得认可"。对策是要求所有决议必须由至少两处语义一致的表述支撑，单句不生成决议。这个规则会漏掉一些真实决议，但漏掉比编造好。

6.3 环境和资源类问题的排查顺序

机器跑不动的时候，别急着换硬件，按这个顺序排查通常能解决大半。

先看是不是两路都在跑识别。双路采集意味着两份音频都要转写，如果其实只有一路有内容（比如全程你在说话，远端没人开麦），那另一路纯属浪费。我加了一个能量检测，某一路整场平均能量低于阈值就直接跳过。

再看模型是不是选大了。很多人一上来就用最大的模型，其实对会议这种场景，中等规模的模型配合热词表，效果已经很够用，速度能快两三倍。我的建议是先用小模型跑通全流程，再逐步升级，每次升级都用同一段录音对比，看提升是否值得那个时间成本。

然后看是不是被热降频了。笔记本长时间跑推理，散热跟不上之后性能会掉得很厉害，两小时的会议跑到后半程明显变慢。这种情况下限制一下并发、给机器垫高散热，比换模型更有效。

最后才是考虑换硬件。而且优先加内存而不是换显卡——内存不够导致的交换，对整体速度的打击往往比显卡慢一点更严重。

7. 一些用久了才明白的事

关于录音这件事，有个习惯我建议所有人都养成：会议开始时明确告知在记录。不是为了别的，就是让参与的人知道自己在被记录，说话的分寸会不一样，讨论质量反而更高。这个动作花五秒钟，但能避免后面很多不必要的尴尬。

本地存储也不是一劳永逸。我给自己定的规则是原始音频保留 7 天，转写文本保留 90 天，纪要长期保留。原始音频占空间最大、敏感度最高，但真正需要回溯的机会其实很少；转写文本偶尔要查证；纪要才是长期价值所在。这个规则用一个定时清理脚本就能实现，跑起来之后完全不用管。

最后一个我觉得最有价值的改动：给纪要加一条回链。每条结论后面带上"00:42:15"这样的时间戳，点一下就能跳到原始音频的对应位置。这个功能技术上很简单，但用起来体验完全不同——别人对某条结论有疑问的时候，你不用重新听一遍两小时的录音，直接跳过去 30 秒就能确认。我自己用下来，这一条比任何摘要质量的提升都更让人愿意长期用下去。