1. 传统会议纪要方案为什么正在被淘汰先说说我自己的真实经历。这几年帮不少团队部署过会议工具从十几个人的创业公司到几百人的中型企业都接触过大家吐槽的核心点极其一致。第一种是纯录音转文字的工具。这类产品能把你说的每句话变成文字但输出出来就是一坨没有结构的草稿稿。你得自己翻上下文自己找重点自己梳理出谁负责做什么整理完发现比开会还累。我见过有团队用了三个月这种工具最后集体放弃回归到手工记录的老路上。第二种是基于关键词规则的工具。它能按照预设的关键词去提取内容比如下一步截止日期负责人这类词然后拼凑成一份看起来像纪要的文本。但它不理解语义经常把开玩笑的话当真把真正重要的决策漏掉。有一次测试有人在会上说了句这个方案要不就算了吧反正也没人反对规则工具把它识别成了方案已通过无异议差点酿成事故。这两种方案的本质问题都在于它们只做了信息记录没有做信息理解。而会议真正的价值恰恰在于理解——谁提出了什么观点为什么这个方案被否决最终达成的共识是什么新冒出来的风险点在哪里。多模态大模型的介入改变了这个局面。它不只看文字转录结果还能处理会议中的语音情绪、PPT 画面、共享的代码片段、白板上的草图。比如你在会上快速画了个架构图传统纪要系统完全无能为力但多模态系统可以把这张草图识别出来结合讨论上下文生成一段描述说明这个架构图的关键节点和团队讨论后的修改意见。这里我要澄清一个误区真正实用的多模态会议纪要不是放几张图片让模型识别一下那么简单。它把整个会议的内容按时间轴对齐起来谁在什么时间点讲了一段话与此同时屏幕上展示的是什么内容这两者之间的语义关系是什么。这是一个跨模态对齐问题也是整套系统里技术含量最高的部分。所以当你看完这篇文章再回头看标题里多模态 大模型 生态这几个关键词就会明白它是在描述一次范式切换会议纪要从记录行为变成了理解行为。2. 系统整体架构四层解耦各管一摊我调研过不少开源会议纪要项目凡是做得好的架构上几乎都是解耦的。所谓解耦就是把完整流程拆成四个独立模块采集层、处理层、推理层、展示层。每一层都有清晰边界可以单独替换、单独升级。这样的设计对团队来说特别友好你可以先用默认实现跑通全流程再逐步替换掉某一层的组件。2.1 采集层多模态数据的源头采集层解决的是数据从哪来的问题。会议纪要系统的输入远不止麦克风音频。一套基本完整的多模态采集包含以下通道音频输入与会者的麦克风流可能是单麦克风也可能是多个分轨音频视频输入摄像头画面或线下会议室里全景摄像头采集的画面屏幕共享演示者共享的幻灯片、代码、文档、网页文档输入会议前上传的议程、相关材料、历史纪要白板内容支持手写笔的会议平板产生的墨迹数据这些数据流异构性很强格式不同、时间轴不同、采样率不同。采集层要做的事就是把它们统一汇聚起来打上全局时间戳转成后续模块能消费的标准化格式。我第一次部署这类系统时最崩溃的就是音频流对接。不同会议软件腾讯会议、Zoom、钉钉输出的音频格式和声道数参差不齐采集层如果不做统一处理后面的模型根本没法稳定工作。我们的做法是统一转成 16kHz 单声道 WAV 格式这是音视频处理里最常见的预处理基准几乎所有开源语音模型都认这个格式。2.2 处理层让数据变成模型能读的语言采集层拿到的原始数据不能直接丢给大模型。大模型吃的是文本、图像 token不是原始 WAV 文件或 MP4 视频流。处理层承担的是数据加工职责。音频这边主要做两件事语音识别和说话人分离。语音识别把发言转成带时间戳的文字说话人分离解决这段话是谁说的问题。这里有个常见坑不要用单一的语音识别服务处理多人会议准确率会掉得厉害。更好的做法是先用说话人分离模型把音频按说话人切段然后每一段独立做语音识别最后再合并。我实测下来这样处理人名归属准确率能提升至少 20 个百分点。画面这边主要做关键帧提取。不是每一帧都要送进大模型那样成本太高。策略是检测画面变化剧烈的帧比如 PPT 翻页、代码窗口切换、白板书写动作把它提取成静态图片再配上对应的音频时间段信息。这个模块的经典实现思路是基于场景切换检测的关键帧抽样具体可以用相邻帧直方图差异阈值来触发。阈值设得太低会抽出一堆重复帧设得太高又会漏掉短暂的切换画面需要在实际数据上调几轮。2.3 推理层大模型真正的用武之地处理层完成数据加工后才轮到推理层上场。这是大模型真正发挥价值的地方。推理层内部按功能拆成三个小模块。第一个是语义结构化模块。它把原始转录文本切分成议题块。一场一小时的会议通常经历好几个完全不同的议题比如先讨论预算然后切到技术选型最后又回到运营计划。语义结构化模块负责识别话题切换把文本按议题重新分组同时把相关画面和文档引用关联进来。第二个是内容摘要模块。它给每个议题生成一段结构化摘要。注意是结构化不是单纯压缩文字。输出要包含该议题涉及的核心问题、参与人的立场、提出的方案、最终结论或未决事项。这要求模型对整段对话有全局理解而不是孤立地看每一句话。第三个是决策和行动项提取模块。这是会议纪要系统区别于普通转写工具的关键能力。它要从文本和画面里提取谁负责什么事情、什么时间之前完成。这个提取结果最好是机器可读的 JSON这样下游可以直接导入项目管理工具省去人工二次转录。2.4 展示层纪要生成之后去哪推理层生成的结构化数据最后要在展示层呈现给用户。一个成熟的会议纪要系统至少有两种展示形态。一种是交互式活文档用户可以看纪要内容然后点击某句话直接跳转到对应的录音和画面位置。这对事后回溯特别有用——大家经常会问这个决策当时是怎么讨论出来的有这条跳转链路就不用整段重听录音。另一种是可导出的标准文档包括 Markdown、PDF、Word 格式方便归档和分发。很多团队有外部对接需求要定期把纪要发给合作方标准格式导出是刚需。展示层还需要处理权限问题。不是所有参会者都有权限看到全部内容比如敏感的商业数据讨论可能只有特定角色能看。这就要求展示层在渲染数据之前做细粒度的权限过滤。这也是很多开源系统容易忽略、但企业用户特别在意的一点。3. 多模态融合与对齐系统中最难啃的骨头这一节展开讲讲多模态融合的具体实现思路。我强调一下这是直接决定你的会议纪要能不能看得懂会议的关键环节。市面上大多数开源项目标榜多模态实际上只是把图像翻译成文本描述和音频转录文本拼接起来然后一次性丢给大模型。这种方式在数据量小的时候勉强能用但一旦会议时间长、画面信息密集效果就非常不稳定。3.1 时间轴对齐一切理解的基础多模态融合的第一步是时间轴对齐。对齐要做两层硬对齐和软对齐。硬对齐是指把音频、视频、屏幕共享按全局时钟标记成同一时间线上的片段这个相对简单采集层统一打时间戳就能实现。软对齐则是让文本段和图像内容建立语义关联这才是真正的难点。举个例子。假设发言人说我们看下这个页面上这个按钮它的点击率一直上不去与此同时屏幕上展示的是一张后台截图。软对齐要判断的是这个按钮对应截图里的哪个 UI 元素点击率上不去这句话和截图里的数据曲线图有什么语义联系。我的实现思路是把屏幕共享的截图和发言人这段语音的转录文本同时送进一个视觉-语言模型做关联打分。打分高的片段对说明图像和文本强关联需要合并处理打分低的说明只是背景画面不必浪费 token。这个匹配打分可以用双塔模型实现一张图片和一句文本分别编码成向量计算余弦相似度超过阈值就判定为有效关联对。这个方法非常朴素但实际运行效果已经足够好。别一上来就上端到端的多模态大模型融合成本高调试也麻烦。3.2 屏幕共享内容识别被忽视的信息金矿屏幕共享是会议中信息密度最高的渠道但传统纪要系统完全忽略了它。想想看你的产品评审会上大家对着 Figma 设计稿讨论交互细节技术方案会上对着架构图争论数据流走向。这些画面里的信息量比人说话的内容还关键。处理屏幕共享内容时我觉得先做一个分类策略比较实用把画面分成三类然后按类采取不同方案。第一类是文本类画面比如代码、文档、PPT。这类画面里的文字本身就有语义直接用 OCR 识别出来把识别出的文本作为上下文交给大模型。注意一个细节OCR 出的文本不要直接拼接进转录文本而是和画面时间段绑定作为图像模态的补充信息而不是独立文本源。第二类是图形类画面比如架构图、流程图、设计稿。单纯 OCR 起不了多大作用因为图里的语义不在文字里而在结构关系里。这类画面建议走视觉语言模型先生成图的自然语言描述再把描述和发言内容融合。比如一张架构图模型可以生成系统分为三层前端应用层、业务逻辑层、数据存储层数据流从上层向下层单向流动这类描述非常有用。第三类是动态操作类画面比如现场演示一个交互操作流程。这类画面需要按操作步骤切段每一段对应一个动作描述然后和发言人的解说对齐。切段的依据可以是鼠标点击、键盘输入、界面跳转这些事件信号。3.3 说话人分离与角色识别做过语音处理的朋友应该都知道说话人分离有多折磨人。开会的时候麦克风收到的往往是一路混合音频多个人说话互相交叠。说话人分离模型要做的事是把每个说话人单独切出来然后再做语音识别转写文字才能带上人名标签。这里有个容易被忽视的难点分离完成之后你还要知道谁是谁。模型只告诉你这是说话人 A这是说话人 B但不会告诉你 A 是张三还是李四。解决这个问题我用过两种方式。第一种是提前注册声纹。让每个参会者提前录一段自己的声音样本系统拿分离出的信号和声纹库做比对。这种方式在企业内部系统里效果最好因为人员相对固定。但痛点在于维护成本高有新员工入职就得提前录入声纹偶尔有人感冒嗓子哑了还会匹配失败。第二种是纯自动聚类。分离模型先把音频切成若干说话人片段然后通过声纹特征聚类自动识别出这段声音和那段声音来自同一个人。至于这个人是谁通过会议日程、座位图、发言顺序做逻辑推断。开源项目大多先做这一步因为开箱即用不需要提前采集声纹。实际部署时我建议两种结合自动聚类作为基础后面再挂一个轻量级的声纹注册模块做校准。这样的话新成员不用强制注册系统也能跑常用成员注册了之后准确率会明显上升。4. 大模型选型与提示词工程决定纪要质量的根本因素会议纪要系统的智能程度模型选型占七成另外三成靠你自己的设计。如果底层模型能力弱再好的提示词都拯救不了反过来模型再强你不会组织输入数据效果也打折扣。这一节分享我的模型选型思路和提示词设计方法。4.1 开源大模型怎么选现在开源可商用的大模型选择很多各有侧重。我选型时基本只关注三个维度上下文长度、推理能力、部署成本。上下文长度是最硬的门槛。它决定了模型能否一次性吃下整场会议的关键内容。一场一小时的会议转录文本大约一万多字如果还要带上屏幕共享画面的描述整体输入可能奔着两万到三万字去了。上下文窗口如果只有 8k那就非常紧张只能把会议切段送进去切段带来的问题是你得手动做跨段融合活很碎效果还不一定能保证。我的经验是优先选支持长上下文的模型至少 32k 以上才比较从容。推理能力决定模型能不能准确执行提取行动项判断决策结果这类复杂任务。说实话如果预算有限我建议把推理能力强的模型用在决策提取这个核心环节其余环节比如标题生成、关键词提取用轻量模型就够了成本能降不少。部署成本不只算 GPU 显存还要算推理速度。会议纪要系统是异步场景不要求实时流式输出所以你有较大容错度。我自己给客户做部署时比较偏爱分层模型策略前端用速度快、性价比高的模型处理简单任务后端用大模型处理复杂任务。4.2 提示词工程让模型输出结构化结果提示词是决定纪要质量的最直接因素。我见过太多人拿一个通用提示词就往里丢会议文本得到的输出就是流水账根本不实用。正确做法是先定义清晰的输入结构再给模型明确的输出诉求。分享一个我常用的精简版提示词实际部署时可以在此基础上扩展你是一名资深的会议纪要整理专家。你将收到一段带说话人标签的会议转录文本以及可能伴随的屏幕画面描述、文档引用。 任务 1. 将内容按逻辑议题切分每个议题输出议题名称、讨论背景、提出方案、达成结论、未决问题。 2. 从全部内容中提取所有行动项格式为 JSON字段owner负责人、action动作描述、due_date截止日期如无明确日期输出 null、related_topic关联议题。 3. 对于包含决策的段落单独输出决策摘要注明决策理由与反对声音。 要求 - 所有输出使用中文。 - 不要凭空补充会议中没有提到的信息。 - 如果消息冲突以较新的发言为准。 - 输出格式严格遵循 JSON。这个提示词里有两个设计细节值得说。一个是任务格式约束行为约束的结构。模型在长文本上容易自由发挥如果不约束输出格式它会把纪要写成一篇散文给它明确的 JSON 输出指令它反而更稳定地执行抽取任务。另一个是冲突处理规则。我加了一条以较新发言为准因为实测发现如果不加这条模型倾向把所有观点平均对待导致最终摘要失去焦点。而会议实际的特点是越靠后的讨论越接近最终结论。4.3 结构化输出的工程化处理提示词虽然要求模型输出 JSON但实际上模型的输出经常是格式正确但字段缺失或者字段值是一大段话而不是期望的短值。针对这种情况推理层要加一个后处理模块。我的后处理模块做三件事字段校验、格式修复、超长截断。字段校验就是检查模型输出是否包含所有必填字段没有就触发一次补抽只给模型发它缺失的字段让它重新生成格式修复处理括号不闭合、引号转义错误这类常见问题超长截断则是对超过预设长度的字段做语义压缩避免后续流程和处理程序出问题。这里分享一个很实用的小技巧在提示词里要求模型输出一个包含完整 JSON 的隐藏标记程序只从隐藏标记之间截取 JSON 部分。实现上可以要求模型在 JSON 前后分别输出一个特定的开始标记和结束标记。这听起来有点取巧但在实际部署中效果非常好能大幅降低解析失败率。我用这套思路把结构化解析成功率从大约 70% 提升到了 95% 以上。5. 落地部署中的实战经验从 Demo 到稳定运行如果你只是想跑个 Demo代码拉下来、装好依赖、录一段会议音频、调一次接口几分钟内看到一份纪要这确实很快。但要把这套系统真正在团队内部稳定运行起来还有不少工作要做。这一节分享几个我在真实部署里反复遇到的痛点。5.1 任务队列与成本控制会议纪要系统是典型的波峰波谷场景。一天内大多数时间没人开会但到了某个固定时段可能同时有几十场会议要处理。这时候如果并发地调用大模型接口不仅账单难看还可能触发接口限流。我的建议是引入一个任务队列把纪要请求全部异步化。每场会结束之后把音频和画面丢进队列然后由一个或多个 worker 按优先级顺序消费。队列的好处是系统在高峰期能平滑排队在低峰期保持合理的资源利用率。技术栈上用 RabbitMQ 或 Redis 队列都行看团队已有基础设施。成本控制还有个隐藏招数做增量处理。某场会如果是每周固定的例会大量内容是重复的你可以把上次的纪要结果缓存起来只对新增的讨论内容做增量摘要最后合并进上次的纪要。这个方案深入跑几周之后API 成本能有明显下降特别是在例会频率高的团队里。5.2 任务顺序与可靠性把任务丢进队列之后有一个很多人容易忽略的问题任务处理是有顺序依赖的。如果你把录音转文字和转文字再送大模型拆成两个独立任务中间隔着队列你就没有可靠保证第二个任务运行时第一个任务已经完成。我处理这个问题的思路是第一版优先把步骤合并成一个大任务worker 内部串行执行完整流程——录音转文字完成后直接在同一 worker 进程内调用大模型接口。这种方式链路清晰排查问题方便适合中小规模部署。等并发量上来了再演进到工作流编排的模型用有向无环图DAG组装依赖关系支持细粒度的重试和调度。一开始就上工作流编排复杂度会高不少对团队资源是种浪费。5.3 隐私与数据合规会议纪要涉及的数据敏感度不用多说语音、屏幕、文档都是团队资产。很多团队看到开源版本就立刻接入公有云大模型这里头的风险值得好好掂量。我强烈建议如果对数据安全要求高优先选择支持私有化部署的模型和系统架构。把整个链路全部放在内网环境包括语音识别、说话人分离、大模型推理全部本地部署。这么做虽然对硬件有一定预算要求但数据流出内网的风险基本可以忽略。如果受限于成本必须调用云端 API那就至少做到数据脱敏。先把文本里的电话号码、邮箱、人名替换成占位符再送去云上推理推理结束后再映射回来。这个策略我在实践中验证过安全性和语义完整性都能兼顾实现成本也不高。5.4 中文会议的特殊挑战专业术语与口音开源项目大多以英语场景为主搬到中文会议场景时会出现不少额外问题。第一个痛点是中文专业术语和英文缩写混用。比如K8sBFFSDK语音识别模型如果覆盖不到会把这些词错误转写成莫名其妙的汉字。我的处理办法是准备一份自定义词汇表放进语音识别服务的热词功能里效果立竿见影。每家公司都该维护这么一份词表随着会议积累不断补充。第二个痛点是方言口音。国内会议语音里多多少少带着川普、广普、东北腔的痕迹。纯靠通用模型效果很不稳。可以尝试用本地微调过的语音识别模型对团队常用的口音做特定优化。训练样本不好收集但只要你能集到一两个小时的常规会议录音微调的收益就很明显。6. 开源生态与二次开发方向不只是部署更要参与这篇文章的核心关键词之一是生态。一个开源项目如果只有一个孤零零的主程序没有周边生态生命力会很有限。一套成熟的会议纪要系统通常有插件机制、开放 API、和社区驱动的模型迭代路径。理解这三块你就知道怎么把开源项目变成符合自己团队需求的东西。6.1 插件机制让 AI 能力可以按需插拔插件是生态的灵魂。我调研过的优质开源项目都提供了一个插件注册机制允许开发者写一个自定义处理器挂接在某个流程节点上。比如你可以写一个插件纪要从 JSON 格式的行动项中自动扫描然后创建一个日历邀请或在项目管理平台里建任务。这些扩展完全不用改动主程序插件注册进去就能生效。插件机制的实现核心就是定义好接口约定。每个插件通常要实现两个钩子函数一个在文本转写完成后触发接收原始转写结果另一个在结构化纪要生成后触发接收最终结构化数据。开发者只需要关心自己的业务逻辑不用碰主程序。6.2 开放 API 设计怎么跟企业 IM 集成企业不想要一个孤立的工具而是要把纪要系统嵌进工作流里。比如会议一结束纪要自动推送到团队群聊或者在日历应用里点进一场会议直接看到历史关联纪要。这套集成通常依赖三个核心接口创建任务接口提交音频或视频资源创建一次纪要处理任务返回任务 ID查询结果接口给定任务 ID查询结构化纪要结果回调通知接口任务完成时主动推送结果到指定 webhook这种异步 API 设计在企业集成中很常见。集成方只需要提前配置一个回调地址主系统就能主动把结果推过来集成方不用轮询等待效率高不少。6.3 模型微调与持续进化会议纪要系统上线后效果不会一劳永逸因为团队的业务用语、术语、讨论风格一直在变。固定基座模型的效果用久了会渐渐跟不上需求。社区驱动的迭代模式在这方面很有优势。你可以把团队的脱敏会议语料整理成一套微调数据集定期在基座模型上做低成本微调。这个过程不一定需要很重的训练资源用 LoRA 微调方案就能做。做好的模型版本可以通过插件机制在系统里做在线热切换不用重启主服务。这里我给一个中肯建议从系统上线第一天就想办法建立语料积累机制。每场会议结束后把录音、转录文本、人工修订后的纪要都存进统一的数据集合里。等积累到一定量级你就能有非常扎实的数据基础来实现微调。这是很多团队开始容易忽视、但长期回报最高的投入之一。7. 实测复盘一场产品评审会的 AI 纪要表现光讲原理和架构有点纸上谈兵。我把最近一次用这套系统做真实测试的案例复盘一下看看在一个典型场景里系统的实际表现到底怎么样。7.1 会议基本情况我挑了一场线上产品评审会时长 47 分钟参会 6 人讨论主题是新版本支付流程的交互改版。会议过程中演示者共享了 3 张设计稿中途打开了一个数据后台讨论了一组转化率数据。音频是会议软件录制的单轨混合音频画质一般屏幕共享流有一些压缩痕迹场景算是比较典型的日常会议。7.2 系统输出效果会议结束后系统大约用了 6 分钟完成全部处理流程包括语音识别、说话人分离、关键帧提取、大模型摘要生成。我逐段检视了生成的纪要整体表现超出我预期。它成功识别出了三个主要议题和我自己人工记录的议题划分完全一致支付流程现状问题、两个备选设计方案的优劣比较、最终决策投票。四个行动项的提取比较准负责人也对得上号包括张伟负责周三前更新支付失败页细节李婷负责整理下单转化率漏斗数据这类细排待办。最让我惊喜的是它捕捉到了一个非常重要的隐性信息。在讨论过程中有位工程师提出一个技术风险改版可能动到底层支付状态机的状态流转逻辑。这个发言并没有明确结论但系统在结构化纪要里把这个信息单独标记为待评估风险而不是简单写进讨论内容。这说明模型不是在做机械关键词提取而是真的理解了这段发言暗示了一个潜在技术隐患。7.3 已知问题与改进方向这次测试也不是没有瑕疵。有两点值得单独记录。第一屏幕共享关键帧提取的时候图里字体真有点小OCR 识别出的中文字符误差比较大。后来我把关键帧处理链路改了一下先做超分辨率预处理再做 OCR错误率明显下降。第二说话人分离的效果比较一般。六个人里有两个人的声音相似度非常高聚类结果发生了串扰。最后纪要里有两段话的说话人标签搞错了对象。这种问题在纯自动聚类方案里确实难以完全避免需要配合声纹注册来做精调才能变好。8. 从零接入这套系统的实操步骤最后给一份可以直接上手的操作清单适合有一点技术基础、想快速评估这套系统是否适合自己的朋友。8.1 环境准备建议操作系统用 Ubuntu 20.04 或 22.04 或者 macOS需要有 NVIDIA GPU 或云端 GPU 实例。显存建议不低于 24GB如果只跑轻量模型16GB 也能凑合。通用依赖包括 Python 3.10 及以上版本、FFmpeg以及语音相关处理库。装这些底层依赖的时候建议用 conda 管理 Python 环境能避开不少兼容性麻烦。8.2 部署实施步骤第一步克隆代码仓库进入项目目录用 conda 创建一个新的环境并激活它。第二步安装项目依赖包括 Python 包和系统级依赖。系统级依赖这块我第一次装就因为漏了某个编译工具导致后续编译失败多花了大半天排查。第三步配置模型路径。把基座大模型权重下载到本地在配置文件里指定路径同时配置语音识别模型和说话人分离模型的权重路径。路径一定要写对很多模型加载失败的问题其实就是路径少了斜杠。第四步准备测试音频。找一段至少十分钟的会议录音格式建议 WAV 或 MP3。手头没有真实会议音频的话可以先拉一个公开的会议数据集做测试。第五步修改核心配置文件。把仓库路径、模型路径、输出路径全部改成你本机的对应值。第六步启动一个测试任务用 API 接口提交音频文件观察系统是否正常开始处理。第七步盯日志输出。任务执行过程中每一步都会打日志确认流程走到哪一步卡住就根据当时的报错信息去排查。8.3 常见问题排查清单我把自己踩过的坑整理成一份清单你接入时可以直接对照着排查语音识别结果为空检查音频采样率是否为 16kHz。如果采样率不对重新转码再试说话人数量异常检查录音里是否混入了环境噪音或者聚类参数需要调整模型显存溢出减少并发任务数或者改用量化版本的模型加载方式输出 JSON 解析失败参考上文提到的隐藏标记方案或更新后处理模块的重试机制中文术语乱码检查自定义词汇表是否已正确加载这个最容易被忽略把这份清单提前背熟接入时会顺畅很多。我每次给企业内部部署都是先把这份清单丢给对接的人对接出问题的概率立刻降了不少。最后再分享一个小经验这套系统的价值要通过长期使用来体现而不是只看一次 Demo 的输出。建议在你团队里选一个例会先跑起来坚持用几周让系统积累语料同时人工修订纪要里的错误。这些修订数据本身就是后面做模型微调最重要的资产。等数据积累到一定程度你会发现系统的纪要质量会经历一次质变那时候你就明白为什么说生态和多模态不是营销话术而是实实在在的生产力。