如果你正在筹备一个需要长期沉淀团队知识的组织或者刚开完一个两小时的线上评审会、却只剩下七零八落的笔记那么“AI 会议记录器”这个词你大概率已经听过不止一次。市面上确实有大量会议纪要工具但它们的共同问题是音频基本都要上传到云端由外部模型转写和总结。对一些公司来说会议内容就是核心资产和技术机密把内部讨论发送给第三方服务本身就是一件需要反复评估风险的事情。这就引出了今天文章的主题Local、开源的 AI 会议记录器——一个“看得见、听得见一切”的本地会议记录方案。所谓“听”是把语音变成文字所谓“看”是进一步理解屏幕共享、PPT、白板或者视频画面里的内容。这类项目在 GitHub 上并不是某一个独苗而是一整类开源方案的总称。它们把语音识别、大模型摘要、多模态理解放在本地运行数据不出机器同时又能让开发者完全掌控每一环的细节。这篇文章我不想只给你复述“什么是会议记录器”而是想和你一起拆解它的技术架构然后从零搭一个最小可用的本地版本。读完你至少能回答三个问题这类工具到底解决什么痛点一个“听看”的本地会议管线由哪些组件构成以及换到真实业务环境里有哪些地方特别容易踩坑。1. 为什么本地开源会议记录器值得关注先看传统方案的痛点。日常开会经常使用的在线会议软件大多内置了字幕和纪要能力体验确实不错。问题在于会议的原始音频、转写文本、结构化摘要通常都保存在服务商的服务器上。对于内部战略会、客户方案评审、薪酬讨论这类敏感场景这是很多团队无法接受的。其次在线工具的功能边界是厂商定义的。厂商给了“自动摘要”你就只能用“自动摘要”如果想要一个“按项目维度拆解风险清单”的纪要或者要把纪要和内部 Wiki/看板打通厂商往往不支持。开源方案的优势就在这里你拿到的是一套可以改的数据管线而不是一个封装好的黑盒。更关键的是本地运行的成本结构已经变得可行。早期语音识别需要专门的 GPU 集群普通开发者想跑起来并不容易。但近两年Whisper 系列模型、各种量化推理框架、本地大模型运行时例如 Ollama已经可以在个人电脑上完成质量不错的转写和总结。换句话说过去做不到本地是因为硬件和模型不允许现在做不到本地更多是因为你没有把管线搭起来。从材料提供的标题来看“sees and hears everything”是一个很准确的能力画像hears是语音采集与转写sees是屏幕内容、视频画面和文档图像的理解。一个成熟的本地会议记录器通常会把这两条感知路径合并到同一个工作流里。1.1 这类工具真正降低的开发成本如果你只是偶尔需要一份会议纪要手动整理也许更高效。但如果你是以下人群这类工具的价值会非常明显技术团队负责人每周有大量评审会、站会和规划会需要结构化纪要留档。产品/研发个人想把会议里的行动项自动收集到待办列表而不是会后翻聊天记录。开源社区维护者想基于一套可修改的代码接入自己的提示词、模型和知识库。它降低的不是“按一下按钮”的操作成本而是从语音到结构化知识之间的整条链路的开发成本。传统做法是你需要分别集成语音转写服务、调 LLM 接口、处理文件存储、设计摘要模板然后还要面对数据隐私评估。而一个本地开源项目通常已经把前几步封装成模块你只需替换模型、调整提示词、接上自己的输出端。1.2 现实边界它不是录音笔也不该是录音笔这里要泼一盆冷水。如果你只是想“把会议录下来事后能搜到”那么只用录音笔加转写就够了根本不需要大模型。会议记录器的进阶价值在于它需要理解讨论结构、识别决策、提取行动项、甚至回答“上次评审会关于数据库选型到底定了什么”这类问题。所以判断一个本地会议记录器好不好用不能只看转写准确率还要看摘要质量、行动项提取能力、多模态理解能力以及整个流程是否稳定可复用。这也是为什么我会把文章的重心放在架构和管线而不是某一个模型效果上。2. 核心概念从一段音频到一份行动清单在开始写代码之前有必要把这条管线里的每个术语讲清楚。下面这些概念会贯穿全文。2.1 ASR自动语音识别ASR 负责把音频波形转成文字。当前开源社区最常用的基础模型之一是 OpenAI 开源的 Whisper 系列它支持多语言识别、时间戳输出并且在中文场景也有不错的表现。社区也发展出多种高速推理实现例如faster-whisper它使用 CTranslate2 做推理加速在 CPU 上也能跑出可用的速度。2.2 VAD语音活动检测VAD 用来判断一段音频里哪些部分有人说话、哪些是静音或噪声。在转写之前先做 VAD可以避免把漫长的沉默送进模型大幅减少计算量。很多转写库已经内置了 VAD 能力例如faster-whisper的vad_filterTrue参数。2.3 说话人分离主持人、产品经理、研发各自说了什么这是会议纪要非常重要的维度。说话人分离Speaker Diarization会为每一句话标注讲话人。开源实现有pyannote.audio等但它通常需要额外下载模型并在某些情况下需要经过授权流程。是否引入取决于你是否需要区分发言人。2.4 多模态模型标题里“sees and hears everything”的“sees”在这里主要靠多模态大模型实现。多模态模型可以同时接收文本和图像输入比如局部截图、PPT 页面、白板照片。当前社区里常见的本地可运行多模态模型包括 Qwen2-VL、Gemma 3、LLaVA 等系列。它们可以分析“屏幕上出现了一张架构图图中标注了三个微服务”从而让纪要不只包含“说话内容”还包含“讨论对象”。2.5 LLM 摘要与结构化输出最后一步是把转写文本以及多模态模型抽取的视觉信息喂给一个大语言模型让它生成结构化 Markdown 纪要。这一步是“质量感”的关键来源同样是转写文本好的摘要能提炼决策、行动项、风险差的摘要则只是把讨论流水账复述一遍。下面用一张表对比三类方案对比维度传统录音笔云端 AI 会议助手本地开源方案数据存储位置本地设备服务商云端本地硬盘转写能力无或少强中到强取决于模型多模态理解无部分支持可定制接入视觉模型行动项提取无有有提示词可调可定制程度低低高部署门槛低低中合规风险低高取决于本地配置从表里能看出本地开源方案最大的优势是“可定制”和“数据可控”代价是部署和维护成本更高。这也是这篇文章要重点帮你解决的部分。3. 典型架构一条会议数据的流水线一个“看和听”的本地会议记录器内部本质是一条流水线。下面先给出整体流程再讲每一环的设计选择。音频采集从麦克风或系统声卡录制会议音频也可以直接接收会议软件的录音文件。预处理采样率转换、静音检测、音量归一化。ASR 转写将音频转为带时间戳的文本片段。视觉采样按一定间隔抓取屏幕或视频帧必要时做 OCR。多模态理解把关键帧交给视觉模型提取图表、文字、界面信息。LLM 结构化把转写文本和视觉信息一起交给大模型生成会议纪要、行动项、决策清单。输出与存储保存 Markdown 文档写入本地知识库或向量数据库方便后续检索。可选自动化将行动项同步到待办系统、日历、IM 群机器人。从模块划分上看1-3是“听”的基础设施4-5是“看”的基础设施6-7是理解与沉淀层8是工程化接入层。在实际项目中很多开源项目并不强制要求同时跑通所有模块。你可以先实现“录音 转写 摘要”也就是一个最小可用版本之后再逐步加入视觉采样、说话人分离、知识库检索。本文接下来就按这条路线展开。如果你只想跑一个快速原型我建议把每条链路的产物都单独保存下来音频文件、JSON 转写结果、视觉提取结果、最终 Markdown 纪要。这样即使某一步失败也不需要重新录制会议方便排错和重跑。4. 环境准备与前置条件搭建这套环境并不需要超大算力但你需要准备一台能长时间运行的电脑并且有足够的磁盘空间存放模型和音频。下面列出本文示例使用的软件环境版本请以实际安装为准我重点演示通用思路。操作系统建议 Linux 或 macOSWindows 也可以但 ffmpeg 设备选择和麦克风权限配置会稍有不同。Python建议 3.10 或更高版本。音频处理FFmpeg。语音转写faster-whisper。本地大模型运行时Ollama。可选视觉模型Ollama 中可拉取的 Qwen2-VL、Gemma 3 等多模态模型。在硬件方面CPU 可以完成整个流程只是速度偏慢。如果机器有 NVIDIA GPU建议安装 CUDA 版本的 PyTorch并把转写模型和设备参数调整为 GPU推理速度会有明显提升。不是必要但推荐。需要特别说明的是通过 Ollama 安装本地大模型是目前比较省事的方案它会自动处理模型下载和运行时启动。如果你想更轻量也可以直接用 HuggingFace 的 Transformers 库加载 4-bit 量化模型但代码量会多不少。为了突出重点本文示范使用 Ollama 作为 LLM 后端。4.1 重要提醒合规与授权在继续之前有一个前提必须强调。会议记录涉及参与者隐私无论技术方案多么本地化都应该在录制前告知参会人员并取得同意。这是法律和伦理底线与使用哪种开源工具无关。相关授权文件、录音留存规则建议由所在公司或团队的法律与安全部门确认后再执行。5. 完整示例搭建一个最小可用会议记录器下面我们开始搭建。为了让流程简单我会把项目拆成几个脚本安装依赖、录音转写、摘要生成、一键运行。5.1 安装依赖先创建 Python 虚拟环境并安装转写与音频处理相关依赖。# 创建并激活虚拟环境 python -m venv .venv source .venv/bin/activate # Windows 下使用.venv\Scripts\activate # 安装依赖 pip install faster-whisper sounddevice numpy # 安装 FFmpeg如果系统还没安装 # macOS: brew install ffmpeg # Ubuntu: sudo apt install ffmpeg # Windows: 下载 FFmpeg 并加入 PATH # 安装并启动 Ollama本地大模型运行时 # 请从 Ollama 官网下载对应系统的安装包安装完成后在终端执行 ollama pull qwen2.5:7b ollama pull gemma3:4b这个步骤里有两个容易出问题的点。第一ffmpeg必须能被命令行直接调用否则录音脚本会失败第二ollama pull需要联网下载模型之后的推导过程则完全在本地执行。模型文件较大建议预留足够磁盘空间。5.2 录音与转写脚本先写一个转写脚本transcribe.py它的作用是把音频文件转成带时间戳的文本片段并输出到 JSON 文件。# 文件路径transcribe.py import json import sys from faster_whisper import WhisperModel def transcribe(audio_path: str, model_size: str small) - list[dict]: # device 可切换为 cudacompute_type 可切换为 float16 model WhisperModel(model_size, devicecpu, compute_typeint8) segments, info model.transcribe( audio_path, languageNone, # None 表示自动检测语言 vad_filterTrue, # 过滤静音段节省计算 word_timestampsFalse, ) print(f[info] detected language: {info.language}, prob: {info.language_probability:.2f}) result [] for seg in segments: item { start: round(seg.start, 2), end: round(seg.end, 2), text: seg.text.strip(), } result.append(item) print(f[{seg.start:7.2f} - {seg.end:7.2f}] {seg.text.strip()}) return result if __name__ __main__: if len(sys.argv) 2: print(Usage: python transcribe.py audio.wav [model_size]) sys.exit(1) audio sys.argv[1] model_size sys.argv[2] if len(sys.argv) 2 else small segments transcribe(audio, model_size) output_json audio.rsplit(., 1)[0] .json with open(output_json, w, encodingutf-8) as f: json.dump(segments, f, ensure_asciiFalse, indent2) print(f[done] transcription saved to {output_json})这段代码的关键逻辑有两个。第一vad_filterTrue会跳过静音片段对长会议尤其重要第二languageNone让模型自动识别语言。如果会议同时有中文和英文自动检测通常比固定语言更稳。小模型速度快但中文识别精度一般追求质量可以换成large-v3不过速度会慢很多。5.3 用本地大模型生成会议纪要转写只是第一步真正让记录变成“纪要”的是大模型摘要。下面编写summarize.py它读取转录 JSON调用 Ollama 的本地模型生成结构化 Markdown。# 文件路径summarize.py import json import sys import urllib.request def load_transcript(json_path: str) - str: with open(json_path, r, encodingutf-8) as f: segments json.load(f) lines [] for seg in segments: lines.append(f[{seg[start]:.2f} - {seg[end]:.2f}] {seg[text]}) return \n.join(lines) def build_prompt(transcript_text: str) - str: return f你是一个专业的会议记录助手。请根据下面的会议转写文本生成一份结构化会议纪要。 要求 1. 按主题归纳讨论内容 2. 列出明确的行动项Action Items注明负责人和截止时间如果原文提到 3. 标出关键决策 4. 输出 Markdown 格式 会议转写文本 {transcript_text[:12000]} def call_ollama(prompt: str, model: str qwen2.5:7b) - str: payload { model: model, messages: [ {role: system, content: 你是一个专业会议记录助手。}, {role: user, content: prompt}, ], stream: False, } req urllib.request.Request( http://localhost:11434/api/chat, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json}, methodPOST, ) with urllib.request.urlopen(req, timeout300) as resp: data json.loads(resp.read().decode(utf-8)) return data[message][content] if __name__ __main__: if len(sys.argv) 3: print(Usage: python summarize.py transcript.json output.md [model]) sys.exit(1) json_path sys.argv[1] output_path sys.argv[2] model sys.argv[3] if len(sys.argv) 3 else qwen2.5:7b transcript_text load_transcript(json_path) prompt build_prompt(transcript_text) summary call_ollama(prompt, model) with open(output_path, w, encodingutf-8) as f: f.write(summary) print(f[done] summary saved to {output_path})这一步是整个系统里最影响体验的地方。摘要质量主要由三件事决定模型能力、提示词质量、输入文本的完整度。transcript_text[:12000]是保护性的长度限制避免超出上下文窗口。如果会议很长你应该先做分段摘要再合并而不是直接把几万字塞给模型。为什么这里使用 Ollama 的 HTTP 接口而不是 Python SDK因为这样脚本不依赖额外 SDK方便在任何语言里复用同一套流程。你只需要保证ollama serve在运行默认监听localhost:11434。5.4 录音与一键运行脚本现在需要一个真正录制会议音频的入口。最简单可靠的方法是使用 FFmpeg。下面给出 macOS 和 Linux 的用法Windows 用户可以先用系统录音工具生成 wav 文件再运行后面的脚本。#!/usr/bin/env bash set -euo pipefail # 防止时间冲突 TS$(date %Y%m%d_%H%M%S) RECORD_FILEmeeting_${TS}.wav JSON_FILEmeeting_${TS}.json SUMMARY_FILEsummary_${TS}.md echo 1. 开始录音按 CtrlC 结束... # macOS 使用 avfoundation 输入设备 :0 # Linux 可改用: ffmpeg -f pulse -i default -ac 1 -ar 16000 $RECORD_FILE # Windows 可改用: ffmpeg -f dshow -i audioMicrophone -ac 1 -ar 16000 $RECORD_FILE ffmpeg -y -f avfoundation -i :0 -ac 1 -ar 16000 $RECORD_FILE echo 2. 转写... python transcribe.py $RECORD_FILE small echo 3. 生成纪要... python summarize.py $JSON_FILE $SUMMARY_FILE qwen2.5:7b echo 完成 echo 音频$RECORD_FILE echo 转写$JSON_FILE echo 纪要$SUMMARY_FILE这个脚本体现了整个流程的顺序依赖先录音再转写最后摘要。set -euo pipefail的作用是任何一步失败时立即退出避免你拿着半成品文档继续操作。录制采样率固定为 16000 Hz 单声道这是语音识别最常用的配置既能保证质量也能控制文件体积。如果你在真实会议中使用我更建议直接读取会议软件的录音文件而不是现场用麦克风外录。系统声卡录制能避免环境噪声也更容易做说话人分离。外录适合线下小会议室但要注意参会者彼此声音重叠时的识别率下降。6. 运行结果与效果验证运行一键脚本后你会在当前目录看到三个文件音频、JSON 转写、Markdown 纪要。下面是一个名为meeting_20250510_153000.wav的示例输出形态。JSON 转写文件大致如下[ { start: 0.12, end: 4.38, text: 大家好今天我们主要讨论数据库选型的问题。 }, { start: 4.52, end: 9.70, text: 我建议先比较 PostgreSQL 和 MySQL 在读写性能上的差异。 } ]最终的 Markdown 纪要应该包含主题归纳、关键决策、行动项列表。你可以通过三个标准判断系统是否成功转录文本是否基本准确时间戳是否递增且对齐。纪要是否覆盖了会议的主要讨论主题而不是复述流水账。行动项是否能从原文中找到依据而不是模型编造。如果转录结果不理想先别急着调整大模型。语音识别是上游上游错误会传导到摘要环节。先检查录音质量采样率是否为 16000、是否有爆音、是否有多人同时说话。如果摘要环节失败优先检查 Ollama。在终端执行curl http://localhost:11434/api/tags如果返回模型列表则服务正常如果连接失败说明ollama serve没有启动或端口被占用。7. 常见问题与排查思路本地搭建过程中最常见的坑集中在环境依赖和模型性能上。下面把高频问题整理成表。问题现象可能原因排查方式解决方案转写中文准确率低Whisper 小模型中文能力有限用一段已知文本测试换medium或large-v3模型CPU 转写太慢无法实时计算量太大未做加速查看 CPU 占用和模型大小开启 VAD 过滤、用 int8、换更小模型转写过程中内存占用过高长音频一次性加载查看内存监控对音频分段转写或换量化版本模型说话内容有重复/幻觉模型生成阶段不稳定检查原始转录和提示词在提示词中要求“只依据原文不要编造”Ollama API 连接失败服务未启动或端口占用执行curl localhost:11434/api/tags启动ollama serve检查端口录音无声音或声音小输入设备选择错误执行ffmpeg -devices查看设备选择正确的设备编号和声道会议太长超出模型上下文上下文窗口不足查看摘要脚本的截断逻辑先分段摘要再合并或使用更长上下文的模型无法区分发言人未做说话人分离查看转录 JSON 是否带说话人字段集成 pyannote.audio 或改用支持 diarization 的后端这里我想单独强调一下“分段摘要再合并”的策略。一次 90 分钟的会议转写文本可能超过 2 万字。即便模型支持 128K 上下文直接全部塞入也会让推理变慢并且模型容易忽略中间细节。比较稳妥的做法是把转写按时间窗口切分成 5-10 分钟一段每段先生成局部摘要和临时行动项最后再让模型把局部结果合并成最终纪要。另一个常被忽略的问题是格式检查。Markdown 输出里可能出现模型把它认为的“负责人”写成一个不存在的名字或者把讨论时的假设当成既定决策。因此在正式发布纪要前人工快速过一遍仍然是必要的。开源工具能提高效率但不能完全替代人工校对。8. 最佳实践与工程建议当你完成了最小原型下一步就是把它往工程化方向演进。基于社区项目的常见做法我给出下面几条建议。8.1 数据与隐私设计本地部署不等于自动安全。即使录音不出机器也应该设置合理的文件访问权限并使用加密磁盘保护敏感会议录音。建议定期清理超过保留期的音频文件只保留转写文本和纪要作为长期资产。对涉及个人信息的转写内容应根据所在地区法规进行匿名化或脱敏处理。8.2 中间产物缓存会议录制的成本很高尤其是线下会议无法重新录。因此管线设计时应把每一步结果都落盘缓存。比如audio.wav、transcript.json、summary.md分别对应三个独立阶段。如果某次摘要模型升级了你不需要重新转写整场会议只需要拿旧的transcript.json重新生成摘要。这在模型迭代时能节省大量时间。8.3 提示词工程摘要质量很大程度取决于提示词。推荐在系统提示词中固定角色和输出格式在用户提示词中强调“只依据转写内容不补充原文没有的信息”。如果你们团队有固定的会议纪要模板可以把模板直接放进提示词让模型按填空方式输出。这样生成的纪要格式稳定也方便后续程序解析。8.4 多模态扩展让记录器真正“看见”如果只做语音转写和摘要那“sees”还没有落地。多模态扩展的典型做法是在会议进行时按固定间隔截取屏幕帧或者把会议录屏按关键帧切出来然后用 Ollama 的多模态模型例如 Qwen2-VL、Gemma 3对图像做描述把描述文本也加入摘要提示词。这样讨论架构图、PPT 数据甚至白板内容时纪要不只是“某人在说某个图”而是能包含图中内容的信息。这个过程需要注意两个问题。第一截帧频率不要太高推荐 5 到 10 秒一次否则会产生大量重复图片浪费算力。第二要先去重连续画面包含的信息量很低只保留画面变化超过一定阈值的帧才有价值。8.5 对接知识库与检索会议纪要完成后如果只是散落在本地文件夹价值仍然有限。更好的做法是把 Markdown 文档按会议主题、日期、参与人建立索引再接入向量数据库。这样你可以在后续提问“我们三月那次评审会关于缓存方案的结论是什么”通过 RAG 检索快速定位到对应纪要和关键段落。这是从“工具”走向“团队知识库”的关键一步。8.6 权限与最小化原则在团队部署时不是所有成员都应该看到全部会议记录。建议在文件系统或知识库层面设置访问控制只向参与者、记录归档人员和有明确需求的人开放。涉及技术评审的会议可以在纪要中隐藏薪酬、人事等敏感讨论而不是把原始录音完全开放。最小权限原则同样适用于本地服务Ollama 的 API 不要监听在局域网可访问的地址只保留本机访问即可。9. 总结与后续学习方向这篇文章从一个现实痛点出发在线会议工具有很多但把会议内容留在本地的开源方案才是可控的选择。我们拆解了“听”和“看”两条感知路径从音频采集、ASR 转写、多模态视觉理解到大模型摘要与输出存储完整搭建了一个最小可用的本地会议记录器。整个示例只有三个脚本和一条命令行链路但它已经具备了一个完整流水线的骨架。下一步你可以按这个顺序继续深入先跑通本文的“录音 转写 摘要”最小流程然后用你自己的会议录音测试效果接着引入说话人分离让纪要从“每个人说的话”升级为“谁说了什么”再之后加入屏幕截图与多模态模型让记录器开始“看见”内容最后把纪要接入向量知识库实现全文检索和问答。真正需要提醒你的仍然是那句技术越强大使用边界越要谨慎。会议是团队协作的重要场景也是隐私敏感度极高的场景。本地化、开源化能帮你在技术上守住数据边界但“是否记录、谁可访问、保留多久”这些规则必须由人和制度来定。建议把这套流程先在内部小范围试点确认合规与效果之后再逐步推广。希望这篇内容对你有帮助也欢迎在实际搭建中多试不同模型和提示词组合找到最适合你团队的那一套方案。
如果你正在筹备一个需要长期沉淀团队知识的组织或者刚开完一个两小时的线上评审会、却只剩下七零八落的笔记那么“AI 会议记录器”这个词你大概率已经听过不止一次。市面上确实有大量会议纪要工具但它们的共同问题是音频基本都要上传到云端由外部模型转写和总结。对一些公司来说会议内容就是核心资产和技术机密把内部讨论发送给第三方服务本身就是一件需要反复评估风险的事情。这就引出了今天文章的主题Local、开源的 AI 会议记录器——一个“看得见、听得见一切”的本地会议记录方案。所谓“听”是把语音变成文字所谓“看”是进一步理解屏幕共享、PPT、白板或者视频画面里的内容。这类项目在 GitHub 上并不是某一个独苗而是一整类开源方案的总称。它们把语音识别、大模型摘要、多模态理解放在本地运行数据不出机器同时又能让开发者完全掌控每一环的细节。这篇文章我不想只给你复述“什么是会议记录器”而是想和你一起拆解它的技术架构然后从零搭一个最小可用的本地版本。读完你至少能回答三个问题这类工具到底解决什么痛点一个“听看”的本地会议管线由哪些组件构成以及换到真实业务环境里有哪些地方特别容易踩坑。1. 为什么本地开源会议记录器值得关注先看传统方案的痛点。日常开会经常使用的在线会议软件大多内置了字幕和纪要能力体验确实不错。问题在于会议的原始音频、转写文本、结构化摘要通常都保存在服务商的服务器上。对于内部战略会、客户方案评审、薪酬讨论这类敏感场景这是很多团队无法接受的。其次在线工具的功能边界是厂商定义的。厂商给了“自动摘要”你就只能用“自动摘要”如果想要一个“按项目维度拆解风险清单”的纪要或者要把纪要和内部 Wiki/看板打通厂商往往不支持。开源方案的优势就在这里你拿到的是一套可以改的数据管线而不是一个封装好的黑盒。更关键的是本地运行的成本结构已经变得可行。早期语音识别需要专门的 GPU 集群普通开发者想跑起来并不容易。但近两年Whisper 系列模型、各种量化推理框架、本地大模型运行时例如 Ollama已经可以在个人电脑上完成质量不错的转写和总结。换句话说过去做不到本地是因为硬件和模型不允许现在做不到本地更多是因为你没有把管线搭起来。从材料提供的标题来看“sees and hears everything”是一个很准确的能力画像hears是语音采集与转写sees是屏幕内容、视频画面和文档图像的理解。一个成熟的本地会议记录器通常会把这两条感知路径合并到同一个工作流里。1.1 这类工具真正降低的开发成本如果你只是偶尔需要一份会议纪要手动整理也许更高效。但如果你是以下人群这类工具的价值会非常明显技术团队负责人每周有大量评审会、站会和规划会需要结构化纪要留档。产品/研发个人想把会议里的行动项自动收集到待办列表而不是会后翻聊天记录。开源社区维护者想基于一套可修改的代码接入自己的提示词、模型和知识库。它降低的不是“按一下按钮”的操作成本而是从语音到结构化知识之间的整条链路的开发成本。传统做法是你需要分别集成语音转写服务、调 LLM 接口、处理文件存储、设计摘要模板然后还要面对数据隐私评估。而一个本地开源项目通常已经把前几步封装成模块你只需替换模型、调整提示词、接上自己的输出端。1.2 现实边界它不是录音笔也不该是录音笔这里要泼一盆冷水。如果你只是想“把会议录下来事后能搜到”那么只用录音笔加转写就够了根本不需要大模型。会议记录器的进阶价值在于它需要理解讨论结构、识别决策、提取行动项、甚至回答“上次评审会关于数据库选型到底定了什么”这类问题。所以判断一个本地会议记录器好不好用不能只看转写准确率还要看摘要质量、行动项提取能力、多模态理解能力以及整个流程是否稳定可复用。这也是为什么我会把文章的重心放在架构和管线而不是某一个模型效果上。2. 核心概念从一段音频到一份行动清单在开始写代码之前有必要把这条管线里的每个术语讲清楚。下面这些概念会贯穿全文。2.1 ASR自动语音识别ASR 负责把音频波形转成文字。当前开源社区最常用的基础模型之一是 OpenAI 开源的 Whisper 系列它支持多语言识别、时间戳输出并且在中文场景也有不错的表现。社区也发展出多种高速推理实现例如faster-whisper它使用 CTranslate2 做推理加速在 CPU 上也能跑出可用的速度。2.2 VAD语音活动检测VAD 用来判断一段音频里哪些部分有人说话、哪些是静音或噪声。在转写之前先做 VAD可以避免把漫长的沉默送进模型大幅减少计算量。很多转写库已经内置了 VAD 能力例如faster-whisper的vad_filterTrue参数。2.3 说话人分离主持人、产品经理、研发各自说了什么这是会议纪要非常重要的维度。说话人分离Speaker Diarization会为每一句话标注讲话人。开源实现有pyannote.audio等但它通常需要额外下载模型并在某些情况下需要经过授权流程。是否引入取决于你是否需要区分发言人。2.4 多模态模型标题里“sees and hears everything”的“sees”在这里主要靠多模态大模型实现。多模态模型可以同时接收文本和图像输入比如局部截图、PPT 页面、白板照片。当前社区里常见的本地可运行多模态模型包括 Qwen2-VL、Gemma 3、LLaVA 等系列。它们可以分析“屏幕上出现了一张架构图图中标注了三个微服务”从而让纪要不只包含“说话内容”还包含“讨论对象”。2.5 LLM 摘要与结构化输出最后一步是把转写文本以及多模态模型抽取的视觉信息喂给一个大语言模型让它生成结构化 Markdown 纪要。这一步是“质量感”的关键来源同样是转写文本好的摘要能提炼决策、行动项、风险差的摘要则只是把讨论流水账复述一遍。下面用一张表对比三类方案对比维度传统录音笔云端 AI 会议助手本地开源方案数据存储位置本地设备服务商云端本地硬盘转写能力无或少强中到强取决于模型多模态理解无部分支持可定制接入视觉模型行动项提取无有有提示词可调可定制程度低低高部署门槛低低中合规风险低高取决于本地配置从表里能看出本地开源方案最大的优势是“可定制”和“数据可控”代价是部署和维护成本更高。这也是这篇文章要重点帮你解决的部分。3. 典型架构一条会议数据的流水线一个“看和听”的本地会议记录器内部本质是一条流水线。下面先给出整体流程再讲每一环的设计选择。音频采集从麦克风或系统声卡录制会议音频也可以直接接收会议软件的录音文件。预处理采样率转换、静音检测、音量归一化。ASR 转写将音频转为带时间戳的文本片段。视觉采样按一定间隔抓取屏幕或视频帧必要时做 OCR。多模态理解把关键帧交给视觉模型提取图表、文字、界面信息。LLM 结构化把转写文本和视觉信息一起交给大模型生成会议纪要、行动项、决策清单。输出与存储保存 Markdown 文档写入本地知识库或向量数据库方便后续检索。可选自动化将行动项同步到待办系统、日历、IM 群机器人。从模块划分上看1-3是“听”的基础设施4-5是“看”的基础设施6-7是理解与沉淀层8是工程化接入层。在实际项目中很多开源项目并不强制要求同时跑通所有模块。你可以先实现“录音 转写 摘要”也就是一个最小可用版本之后再逐步加入视觉采样、说话人分离、知识库检索。本文接下来就按这条路线展开。如果你只想跑一个快速原型我建议把每条链路的产物都单独保存下来音频文件、JSON 转写结果、视觉提取结果、最终 Markdown 纪要。这样即使某一步失败也不需要重新录制会议方便排错和重跑。4. 环境准备与前置条件搭建这套环境并不需要超大算力但你需要准备一台能长时间运行的电脑并且有足够的磁盘空间存放模型和音频。下面列出本文示例使用的软件环境版本请以实际安装为准我重点演示通用思路。操作系统建议 Linux 或 macOSWindows 也可以但 ffmpeg 设备选择和麦克风权限配置会稍有不同。Python建议 3.10 或更高版本。音频处理FFmpeg。语音转写faster-whisper。本地大模型运行时Ollama。可选视觉模型Ollama 中可拉取的 Qwen2-VL、Gemma 3 等多模态模型。在硬件方面CPU 可以完成整个流程只是速度偏慢。如果机器有 NVIDIA GPU建议安装 CUDA 版本的 PyTorch并把转写模型和设备参数调整为 GPU推理速度会有明显提升。不是必要但推荐。需要特别说明的是通过 Ollama 安装本地大模型是目前比较省事的方案它会自动处理模型下载和运行时启动。如果你想更轻量也可以直接用 HuggingFace 的 Transformers 库加载 4-bit 量化模型但代码量会多不少。为了突出重点本文示范使用 Ollama 作为 LLM 后端。4.1 重要提醒合规与授权在继续之前有一个前提必须强调。会议记录涉及参与者隐私无论技术方案多么本地化都应该在录制前告知参会人员并取得同意。这是法律和伦理底线与使用哪种开源工具无关。相关授权文件、录音留存规则建议由所在公司或团队的法律与安全部门确认后再执行。5. 完整示例搭建一个最小可用会议记录器下面我们开始搭建。为了让流程简单我会把项目拆成几个脚本安装依赖、录音转写、摘要生成、一键运行。5.1 安装依赖先创建 Python 虚拟环境并安装转写与音频处理相关依赖。# 创建并激活虚拟环境 python -m venv .venv source .venv/bin/activate # Windows 下使用.venv\Scripts\activate # 安装依赖 pip install faster-whisper sounddevice numpy # 安装 FFmpeg如果系统还没安装 # macOS: brew install ffmpeg # Ubuntu: sudo apt install ffmpeg # Windows: 下载 FFmpeg 并加入 PATH # 安装并启动 Ollama本地大模型运行时 # 请从 Ollama 官网下载对应系统的安装包安装完成后在终端执行 ollama pull qwen2.5:7b ollama pull gemma3:4b这个步骤里有两个容易出问题的点。第一ffmpeg必须能被命令行直接调用否则录音脚本会失败第二ollama pull需要联网下载模型之后的推导过程则完全在本地执行。模型文件较大建议预留足够磁盘空间。5.2 录音与转写脚本先写一个转写脚本transcribe.py它的作用是把音频文件转成带时间戳的文本片段并输出到 JSON 文件。# 文件路径transcribe.py import json import sys from faster_whisper import WhisperModel def transcribe(audio_path: str, model_size: str small) - list[dict]: # device 可切换为 cudacompute_type 可切换为 float16 model WhisperModel(model_size, devicecpu, compute_typeint8) segments, info model.transcribe( audio_path, languageNone, # None 表示自动检测语言 vad_filterTrue, # 过滤静音段节省计算 word_timestampsFalse, ) print(f[info] detected language: {info.language}, prob: {info.language_probability:.2f}) result [] for seg in segments: item { start: round(seg.start, 2), end: round(seg.end, 2), text: seg.text.strip(), } result.append(item) print(f[{seg.start:7.2f} - {seg.end:7.2f}] {seg.text.strip()}) return result if __name__ __main__: if len(sys.argv) 2: print(Usage: python transcribe.py audio.wav [model_size]) sys.exit(1) audio sys.argv[1] model_size sys.argv[2] if len(sys.argv) 2 else small segments transcribe(audio, model_size) output_json audio.rsplit(., 1)[0] .json with open(output_json, w, encodingutf-8) as f: json.dump(segments, f, ensure_asciiFalse, indent2) print(f[done] transcription saved to {output_json})这段代码的关键逻辑有两个。第一vad_filterTrue会跳过静音片段对长会议尤其重要第二languageNone让模型自动识别语言。如果会议同时有中文和英文自动检测通常比固定语言更稳。小模型速度快但中文识别精度一般追求质量可以换成large-v3不过速度会慢很多。5.3 用本地大模型生成会议纪要转写只是第一步真正让记录变成“纪要”的是大模型摘要。下面编写summarize.py它读取转录 JSON调用 Ollama 的本地模型生成结构化 Markdown。# 文件路径summarize.py import json import sys import urllib.request def load_transcript(json_path: str) - str: with open(json_path, r, encodingutf-8) as f: segments json.load(f) lines [] for seg in segments: lines.append(f[{seg[start]:.2f} - {seg[end]:.2f}] {seg[text]}) return \n.join(lines) def build_prompt(transcript_text: str) - str: return f你是一个专业的会议记录助手。请根据下面的会议转写文本生成一份结构化会议纪要。 要求 1. 按主题归纳讨论内容 2. 列出明确的行动项Action Items注明负责人和截止时间如果原文提到 3. 标出关键决策 4. 输出 Markdown 格式 会议转写文本 {transcript_text[:12000]} def call_ollama(prompt: str, model: str qwen2.5:7b) - str: payload { model: model, messages: [ {role: system, content: 你是一个专业会议记录助手。}, {role: user, content: prompt}, ], stream: False, } req urllib.request.Request( http://localhost:11434/api/chat, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json}, methodPOST, ) with urllib.request.urlopen(req, timeout300) as resp: data json.loads(resp.read().decode(utf-8)) return data[message][content] if __name__ __main__: if len(sys.argv) 3: print(Usage: python summarize.py transcript.json output.md [model]) sys.exit(1) json_path sys.argv[1] output_path sys.argv[2] model sys.argv[3] if len(sys.argv) 3 else qwen2.5:7b transcript_text load_transcript(json_path) prompt build_prompt(transcript_text) summary call_ollama(prompt, model) with open(output_path, w, encodingutf-8) as f: f.write(summary) print(f[done] summary saved to {output_path})这一步是整个系统里最影响体验的地方。摘要质量主要由三件事决定模型能力、提示词质量、输入文本的完整度。transcript_text[:12000]是保护性的长度限制避免超出上下文窗口。如果会议很长你应该先做分段摘要再合并而不是直接把几万字塞给模型。为什么这里使用 Ollama 的 HTTP 接口而不是 Python SDK因为这样脚本不依赖额外 SDK方便在任何语言里复用同一套流程。你只需要保证ollama serve在运行默认监听localhost:11434。5.4 录音与一键运行脚本现在需要一个真正录制会议音频的入口。最简单可靠的方法是使用 FFmpeg。下面给出 macOS 和 Linux 的用法Windows 用户可以先用系统录音工具生成 wav 文件再运行后面的脚本。#!/usr/bin/env bash set -euo pipefail # 防止时间冲突 TS$(date %Y%m%d_%H%M%S) RECORD_FILEmeeting_${TS}.wav JSON_FILEmeeting_${TS}.json SUMMARY_FILEsummary_${TS}.md echo 1. 开始录音按 CtrlC 结束... # macOS 使用 avfoundation 输入设备 :0 # Linux 可改用: ffmpeg -f pulse -i default -ac 1 -ar 16000 $RECORD_FILE # Windows 可改用: ffmpeg -f dshow -i audioMicrophone -ac 1 -ar 16000 $RECORD_FILE ffmpeg -y -f avfoundation -i :0 -ac 1 -ar 16000 $RECORD_FILE echo 2. 转写... python transcribe.py $RECORD_FILE small echo 3. 生成纪要... python summarize.py $JSON_FILE $SUMMARY_FILE qwen2.5:7b echo 完成 echo 音频$RECORD_FILE echo 转写$JSON_FILE echo 纪要$SUMMARY_FILE这个脚本体现了整个流程的顺序依赖先录音再转写最后摘要。set -euo pipefail的作用是任何一步失败时立即退出避免你拿着半成品文档继续操作。录制采样率固定为 16000 Hz 单声道这是语音识别最常用的配置既能保证质量也能控制文件体积。如果你在真实会议中使用我更建议直接读取会议软件的录音文件而不是现场用麦克风外录。系统声卡录制能避免环境噪声也更容易做说话人分离。外录适合线下小会议室但要注意参会者彼此声音重叠时的识别率下降。6. 运行结果与效果验证运行一键脚本后你会在当前目录看到三个文件音频、JSON 转写、Markdown 纪要。下面是一个名为meeting_20250510_153000.wav的示例输出形态。JSON 转写文件大致如下[ { start: 0.12, end: 4.38, text: 大家好今天我们主要讨论数据库选型的问题。 }, { start: 4.52, end: 9.70, text: 我建议先比较 PostgreSQL 和 MySQL 在读写性能上的差异。 } ]最终的 Markdown 纪要应该包含主题归纳、关键决策、行动项列表。你可以通过三个标准判断系统是否成功转录文本是否基本准确时间戳是否递增且对齐。纪要是否覆盖了会议的主要讨论主题而不是复述流水账。行动项是否能从原文中找到依据而不是模型编造。如果转录结果不理想先别急着调整大模型。语音识别是上游上游错误会传导到摘要环节。先检查录音质量采样率是否为 16000、是否有爆音、是否有多人同时说话。如果摘要环节失败优先检查 Ollama。在终端执行curl http://localhost:11434/api/tags如果返回模型列表则服务正常如果连接失败说明ollama serve没有启动或端口被占用。7. 常见问题与排查思路本地搭建过程中最常见的坑集中在环境依赖和模型性能上。下面把高频问题整理成表。问题现象可能原因排查方式解决方案转写中文准确率低Whisper 小模型中文能力有限用一段已知文本测试换medium或large-v3模型CPU 转写太慢无法实时计算量太大未做加速查看 CPU 占用和模型大小开启 VAD 过滤、用 int8、换更小模型转写过程中内存占用过高长音频一次性加载查看内存监控对音频分段转写或换量化版本模型说话内容有重复/幻觉模型生成阶段不稳定检查原始转录和提示词在提示词中要求“只依据原文不要编造”Ollama API 连接失败服务未启动或端口占用执行curl localhost:11434/api/tags启动ollama serve检查端口录音无声音或声音小输入设备选择错误执行ffmpeg -devices查看设备选择正确的设备编号和声道会议太长超出模型上下文上下文窗口不足查看摘要脚本的截断逻辑先分段摘要再合并或使用更长上下文的模型无法区分发言人未做说话人分离查看转录 JSON 是否带说话人字段集成 pyannote.audio 或改用支持 diarization 的后端这里我想单独强调一下“分段摘要再合并”的策略。一次 90 分钟的会议转写文本可能超过 2 万字。即便模型支持 128K 上下文直接全部塞入也会让推理变慢并且模型容易忽略中间细节。比较稳妥的做法是把转写按时间窗口切分成 5-10 分钟一段每段先生成局部摘要和临时行动项最后再让模型把局部结果合并成最终纪要。另一个常被忽略的问题是格式检查。Markdown 输出里可能出现模型把它认为的“负责人”写成一个不存在的名字或者把讨论时的假设当成既定决策。因此在正式发布纪要前人工快速过一遍仍然是必要的。开源工具能提高效率但不能完全替代人工校对。8. 最佳实践与工程建议当你完成了最小原型下一步就是把它往工程化方向演进。基于社区项目的常见做法我给出下面几条建议。8.1 数据与隐私设计本地部署不等于自动安全。即使录音不出机器也应该设置合理的文件访问权限并使用加密磁盘保护敏感会议录音。建议定期清理超过保留期的音频文件只保留转写文本和纪要作为长期资产。对涉及个人信息的转写内容应根据所在地区法规进行匿名化或脱敏处理。8.2 中间产物缓存会议录制的成本很高尤其是线下会议无法重新录。因此管线设计时应把每一步结果都落盘缓存。比如audio.wav、transcript.json、summary.md分别对应三个独立阶段。如果某次摘要模型升级了你不需要重新转写整场会议只需要拿旧的transcript.json重新生成摘要。这在模型迭代时能节省大量时间。8.3 提示词工程摘要质量很大程度取决于提示词。推荐在系统提示词中固定角色和输出格式在用户提示词中强调“只依据转写内容不补充原文没有的信息”。如果你们团队有固定的会议纪要模板可以把模板直接放进提示词让模型按填空方式输出。这样生成的纪要格式稳定也方便后续程序解析。8.4 多模态扩展让记录器真正“看见”如果只做语音转写和摘要那“sees”还没有落地。多模态扩展的典型做法是在会议进行时按固定间隔截取屏幕帧或者把会议录屏按关键帧切出来然后用 Ollama 的多模态模型例如 Qwen2-VL、Gemma 3对图像做描述把描述文本也加入摘要提示词。这样讨论架构图、PPT 数据甚至白板内容时纪要不只是“某人在说某个图”而是能包含图中内容的信息。这个过程需要注意两个问题。第一截帧频率不要太高推荐 5 到 10 秒一次否则会产生大量重复图片浪费算力。第二要先去重连续画面包含的信息量很低只保留画面变化超过一定阈值的帧才有价值。8.5 对接知识库与检索会议纪要完成后如果只是散落在本地文件夹价值仍然有限。更好的做法是把 Markdown 文档按会议主题、日期、参与人建立索引再接入向量数据库。这样你可以在后续提问“我们三月那次评审会关于缓存方案的结论是什么”通过 RAG 检索快速定位到对应纪要和关键段落。这是从“工具”走向“团队知识库”的关键一步。8.6 权限与最小化原则在团队部署时不是所有成员都应该看到全部会议记录。建议在文件系统或知识库层面设置访问控制只向参与者、记录归档人员和有明确需求的人开放。涉及技术评审的会议可以在纪要中隐藏薪酬、人事等敏感讨论而不是把原始录音完全开放。最小权限原则同样适用于本地服务Ollama 的 API 不要监听在局域网可访问的地址只保留本机访问即可。9. 总结与后续学习方向这篇文章从一个现实痛点出发在线会议工具有很多但把会议内容留在本地的开源方案才是可控的选择。我们拆解了“听”和“看”两条感知路径从音频采集、ASR 转写、多模态视觉理解到大模型摘要与输出存储完整搭建了一个最小可用的本地会议记录器。整个示例只有三个脚本和一条命令行链路但它已经具备了一个完整流水线的骨架。下一步你可以按这个顺序继续深入先跑通本文的“录音 转写 摘要”最小流程然后用你自己的会议录音测试效果接着引入说话人分离让纪要从“每个人说的话”升级为“谁说了什么”再之后加入屏幕截图与多模态模型让记录器开始“看见”内容最后把纪要接入向量知识库实现全文检索和问答。真正需要提醒你的仍然是那句技术越强大使用边界越要谨慎。会议是团队协作的重要场景也是隐私敏感度极高的场景。本地化、开源化能帮你在技术上守住数据边界但“是否记录、谁可访问、保留多久”这些规则必须由人和制度来定。建议把这套流程先在内部小范围试点确认合规与效果之后再逐步推广。希望这篇内容对你有帮助也欢迎在实际搭建中多试不同模型和提示词组合找到最适合你团队的那一套方案。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
