中/EN
实战 SOP
实战 SOP

会议纪要自动化工作流

这套 n8n 工作流把会议纪要端到端自动化：录音上传后调 Whisper 转写，大模型抽取议题/决议/待办，再分发飞书群、邮件和 Notion。区别于「会议纪要 Prompt 包」只处理文本到纪要，本篇是无人值守流水线，30 分钟会议从上传到纪要进群可压到 3 分钟。

发布于 2026年7月31日5 分钟阅读
<!-- workflow-meeting-notes-automation | resource | 会议纪要自动化工作流 -->

开会两小时，整理纪要又是两小时--录音丢在群里没人听，专人听写耗时费力，还常常漏掉关键决议和待办。更普遍的情况是：会议结束时说“录音稍后发群里大家自己看”，然后就没了下文。这套 n8n 工作流把端到端流程串起来：录音上传后自动调 Whisper 转写文本，再用大模型抽取结构化纪要（议题 / 决议 / 待办），最后分发到飞书群、邮件和 Notion，会议一结束纪要就自动到同事手上。

如果你用过「会议纪要 Prompt 包」手动把转写文本喂给 AI，本篇是把它升级成无人值守的流水线--Prompt 包只解决“文本到纪要”这一段，而工作流把录音获取、转录、结构化、分发全部自动串起来，无需人值守。它最适合周会、项目复盘、跨部门协作会这类“有决议、有待办、但没人爱写纪要”的会议；客户访谈、销售对接也很合适，能把口头承诺的事项自动落成可追踪的任务。导入模板、改改 API key 就能跑，一段 30 分钟的会议从上传录音到纪要进群，可压到 3 分钟内。

一、工作流链路

录音上传（Webhook 接收音频 URL + 会议标题）-> 下载音频文件（HTTP Request）-> Whisper 转录（HTTP Request 调 OpenAI 语音转写 API）-> LLM 结构化（HTTP Request 调大模型，输出议题 / 决议 / 待办 JSON）-> Code 节点解析并拼接消息 -> 分发三路：飞书群推摘要 + 邮件发全文 + Notion 入库归档。整条链路串起来后，会议组织者唯一要做的，是把录音文件传给 Webhook。其中转录和结构化是核心两跳--转录决定文本准不准，结构化决定纪要好不好用，其余节点都是搬运和分发。整条链路跑下来，单场会议的 API 成本主要是 Whisper 转录（按音频时长计费）加一次 LLM 调用，30 分钟会议通常在几分钱量级，远低于人工听写的时间成本。

二、下载模板

会议纪要自动化工作流n8n JSON

三、使用步骤

  1. 导入模板：n8n -> Workflows -> Import from File，选 workflow-meeting-notes-automation.json，导入后可见 8 个节点
  2. 录音上传触发节点：复制 Webhook 的 Production URL，接到录音完成后的回调--会议软件录制结束、飞书妙记导出、OBS 上传后端都可以；请求体传 audio_url（录音文件可下载直链）和 meeting_title
  3. 下载录音节点：HTTP Request GET 拉取音频文件，建议用对象存储预签名直链（阿里云 OSS / 腾讯云 COS / AWS S3），避免大文件传输超时
  4. Whisper 转录节点：填 OpenAI API key，POST 到 https://api.openai.com/v1/audio/transcriptions，model 设 whisper-1，response_format 设 json；中文会议带 language: zh 参数能明显提升识别准确率。注意该节点要配置成 multipart/form-data 上传，把上一步下载的音频二进制作为 file 字段提交，Content-Type 不要手填（n8n 会自动带 boundary）
  5. LLM 结构化节点：填 Kimi / DeepSeek API key，8k 上下文模型够用，Prompt 见下；务必要求模型只输出 JSON，方便下游解析。会议超过 1 小时时换 32k 上下文模型，避免转写文本被截断丢决议
  6. Code 解析节点：用正则 /\{[\s\S]*\}/ 提取 LLM 输出里的 JSON（兼容模型偶尔包裹 markdown 代码块的情况），解析出议题 / 决议 / 待办，并拼接成飞书消息文本；解析失败走兜底分支，把原始文本原样发出，避免整条链路中断
  7. 飞书推送节点：填自定义机器人 webhook，POST {"msg_type":"text","content":{"text":"..."}}，消息带会议标题 + 待办清单
  8. 邮件发送节点：用 SMTP 把全文纪要发给参会人，邮件主题带会议标题，正文附议题 / 决议 / 待办
  9. Notion 入库节点：调 Notion API 在“会议纪要”数据库新建页面，把结构化字段写入对应 property，方便日后检索；先在数据库页面把该 integration 共享授权，否则 API 会报 404
  10. 试运行：上传一段 5 分钟测试录音，依次检查转录文本是否正确、LLM 是否输出合法 JSON、飞书群是否收到摘要、Notion 是否建页

四、配套 Prompt（LLM 结构化）

Prompt
你是会议纪要助手。基于以下录音转写文本，输出结构化纪要（仅 JSON，不要多余文字和代码块）：
{
  "topic": "会议主题（一句话）",
  "issues": ["讨论的议题，3-5条，每条一句话"],
  "decisions": ["明确达成的决议"],
  "action_items": [
    {"task": "可执行的具体任务", "owner": "负责人，未明确标待分配", "due": "截止日期，未明确标待定"}
  ]
}
规则：
1. 过滤寒暄、重复、跑题内容，只保留有信息量的部分
2. 行动项必须可执行（“优化产品”不行，“周三前出登录页 v2 设计稿”行）
3. 没明确负责人的标「待分配」，没明确日期的标「待定」
4. 忠于原文，不编造未提及的内容
转写文本：{{transcript}}
合规提示：会议内容可能含商业敏感信息，仅用于生成纪要，不得用于模型训练或外发第三方。

五、踩坑

  • 音频超 25MB 被拒：OpenAI Whisper 单文件上限 25MB，约对应 30 分钟以上会议。超长会议需先用 ffmpeg 按静音切段，分批转录后再拼接文本；也可在下载节点后加一个“切段”子流程，用 -segment 参数自动切分
  • 中文专有名词识别错：Whisper 对人名、术语、产品名常出错。利用 Whisper 的 prompt 参数喂一段“词汇表”（参会人姓名、产品名、项目代号），能显著降低误识；注意这个 prompt 是给 Whisper 的声学提示，不是 LLM 的 prompt
  • 录音质量差拖垮识别率：远程会议常出现回声、串音、背景噪音，直接喂给 Whisper 错字率飙升。建议录会议时各端单独录制再合流，或在下载节点后加 ffmpeg 降噪归一化（afftdn + loudnorm 滤镜），预处理后准确率能提一截
  • LLM 不按 JSON 输出：模型偶尔带 markdown 代码块或解释语，导致 Code 节点解析失败。务必在 Prompt 里强约束“仅输出 JSON”，Code 节点加正则兜底（提取第一个 { 到最后一个 } 之间的内容），必要时把 temperature 设为 0
  • 长会议超 token：1 小时会议转写约 1.5 万字，逼近 8k 模型上下文上限。长会议换 32k 或 200k 长上下文模型，或先分段摘要再合并，避免截断丢失决议
  • 飞书机器人收不到消息：飞书自定义机器人若在安全设置里开了“关键词过滤”，消息内容必须包含该关键词才会被接收；若开了“签名校验”，则需在请求里带上 timestamp 和 sign，建议在 Code 节点用 HmacSHA256 算好 sign 再发，否则消息会被静默丢弃
  • 飞书消息超长被截断：飞书单条文本消息有长度限制，待办多时分两条发（摘要一条 + 完整待办清单一条），或改用富文本 post 类型排版更清晰
  • Notion 报 404 或无权限：新建的 Notion integration 默认看不到任何页面，必须在目标数据库右上角 Share -> 添加该 integration 共享授权，否则 API 返回 404；数据库的 property 名称要和模板里的字段名对齐
  • 会议录音合规：录音需提前告知参会人（会议软件提示或会前通知）。含客户信息、薪资、合同条款等敏感议题的会议，转录文本不要发往第三方 LLM，改用本地部署模型处理；纪要入库前脱敏

跑通后建议加两个增强：一是会前从 Notion 拉出上次待办清单，随 Prompt 一起喂给 LLM，让它顺带核对完成情况并标红逾期项；二是会后把每个待办自动创建为飞书任务并 @ 负责人，把“纪要”变成“可追踪的执行链”。落地节奏上，建议先在低频的周会或双周会上试跑，确认转录和结构化稳定后再接入每日站会；高频会议对准确率和成本更敏感，贸然全量接入容易翻车。转录和结构化的准确率每月抽几场会议人工复查一次，把识别差的术语补进 Whisper 词汇表，让流水线越跑越准。

参考来源

本文由 AI 辅助生成，经人工审核编辑。最后更新：2026-07-31

相关文章