用 n8n 搭会议录音转纪要工作流：转写+抽 action item+分发 实战 SOP

开会录音现在不难，难的是录完之后。一场一小时的会，转写要听三遍，纪要靠一个人手敲，action item 散在聊天记录里没人认领，下周开会问"上次那个事推进了吗"，全场沉默。录音文件躺在硬盘里，和没有录音没区别。

问题不在"有没有录"，在"录完之后没有人把声音变成可执行的任务"。这篇 SOP 用 n8n 搭一条「录音上传 → Whisper 转写 → LLM 生成纪要并抽取 action item（含负责人、截止日期）→ 分发飞书/邮件/Notion」的工作流，把从录音到可跟进任务这条链路自动化。节点名和接口参数以官方文档为准，不编造。

一句话定位：这套工作流解决的不是"转写"（Whisper 已经够好），而是转写之后的"结构化"——把一坨文本变成有摘要、有决策、有负责人、有截止日期的可执行纪要，并自动推到该推的地方。

一、场景与痛点

团队开会的典型链路：录音 → 某个人负责整理纪要 → 发群里 → 大家看一眼 → action item 无人跟进 → 下周开会重复讨论同一件事。痛点集中在四个点：

核心矛盾：录音 ≠ 纪要，纪要 ≠ 可执行任务。中间缺两步——把声音变成文字，再把文字变成有负责人和截止日期的结构化任务。n8n + Whisper + LLM 就是补这两步。

二、工具选型：n8n 编排 + Whisper 转写 + LLM 抽取

整条链路三个核心组件，各管一段：

为什么不用现成会议机器人（Otter、Fireflies、飞书妙记）？

不是它们不好，是三个场景下自建更合适：

1. 可控性：现成工具的纪要格式固定，你要改成"action item 必须带负责人+截止日期+@飞书"它做不到。自建 prompt 完全自定义输出格式。
2. 成本：Otter 商业版 $20/月/人，团队 10 人就是 $200/月。Whisper 按分钟计费，一小时会议 $0.36，一个月 50 小时会议约 $18，差一个数量级。
3. 数据隐私：自托管 n8n + 自选 LLM，录音文件不需要传到第三方 SaaS。对内网会议、涉敏内容这是硬需求。

现成工具适合"个人用、不涉密、格式不挑"的场景。团队要定制化输出和私有部署，自建工作流更值。

三、分步搭建

四个步骤，每步给节点配置要点和关键参数。以下以自托管 n8n 为例，云端版操作一致。

步骤 1：录音上传触发（Webhook 节点）

拖一个 Webhook 节点作为工作流入口。录音文件通过 HTTP POST 上传到这个 webhook。

节点配置要点：

Webhook 节点收到文件后，n8n 将文件二进制数据存储在 binary 属性中（默认属性名取决于上传字段名，通常是 data）。后续节点通过这个属性名引用音频文件。

# 上传录音触发 webhook（curl 测试）
curl -X POST https://你的n8n域名/webhook/meeting-upload \
  -F "file=@meeting_20260806.mp3"

如果 n8n 部署在内网，Webhook 需要公网可达。用 ngrok 隧道或反向代理暴露；生产环境务必加 HTTPS 和访问控制。

替代方案：Local File Trigger 节点。 如果录音文件是定期丢进某个文件夹的（比如 Zoom 自动录制后存到共享目录），用 Local File Trigger 节点替代 Webhook，配置监听路径和触发事件（文件新增），省去手动上传。仅自托管可用。

步骤 2：HTTP Request 调 Whisper 转写

拖一个 HTTP Request 节点，连接 Webhook 输出。调用 OpenAI Whisper API 把音频转成文字。

Whisper API 规格（以官方文档为准）：

• 端点：POST https://api.openai.com/v1/audio/transcriptions
• 认证：Authorization: Bearer sk-xxx（用 n8n Credentials 存，不硬编码）
• 必填参数：file（音频文件）、model（whisper-1）
• 可选参数：language（ISO-639-1，如 zh、en）、response_format（json/text/srt/verbose_json/vtt）、prompt（提供上下文/专有名词）、temperature（0-1）
• 文件大小限制：25 MB
• 支持格式：mp3、mp4、mpeg、mpga、m4a、wav、webm

HTTP Request 节点配置：

// verbose_json 响应示例（含时间戳分段，便于后续发言人区分）
{
  "task": "transcribe",
  "language": "chinese",
  "duration": 3600.12,
  "text": "今天的会议主要讨论了Q3的产品路线图...",
  "segments": [
    { "id": 0, "start": 0.0, "end": 5.32, "text": "今天的会议主要讨论了..." },
    { "id": 1, "start": 5.32, "end": 12.10, "text": "..." }
  ]
}

选 verbose_json 而非默认 json 的原因：它返回 text（全文）和 segments（带时间戳的分段），后续如果要做发言人区分或时间戳标注，segments 是基础。

费用参考：Whisper 按 $0.006/分钟计费。一小时会议约 $0.36。具体以 OpenAI 定价页为准。

步骤 3：LLM 节点生成纪要 + 抽 action items

转写拿到全文后，用 n8n 的 Basic LLM Chain 节点（Advanced AI 节点族）生成结构化纪要。这个节点接收一段 prompt，返回 LLM 输出，不需要 Memory 和 Tools——比 AI Agent 节点轻量，适合"输入文本 → 输出结构化结果"的单次任务。

节点配置：

1. 拖入 Basic LLM Chain 节点，连接 HTTP Request（Whisper）的输出。
2. 挂一个 OpenAI Chat Model 子节点作为 Language Model：模型选 gpt-4o（或 DeepSeek 等兼容模型），API Key 用凭证引用。
3. 在 Basic LLM Chain 的 Prompt 里引用转写文本：{{ $json.text }}（Whisper verbose_json 返回的全文）。

System Prompt（关键）：

你是一个会议纪要助手。收到会议转写文本后，按以下结构输出 Markdown：

## 会议纪要

### 摘要
（3-5 句概括会议核心内容）

### 关键决策
1. （每条一个决策点）

### Action Items
| 任务 | 负责人 | 截止日期 |
|---|---|---|
| （具体可执行的任务） | （人名，没明确则标"待确认"） | （日期，没明确则标"待确认"） |

### 未决议题
- （讨论了但没结论的议题）

规则：
- 摘要不超过 5 句，只写结论
- Action item 必须是具体动作，不能是"推进某某"这种模糊表述
- 负责人和截止日期从文本中提取，没明确说就标"待确认"，不要编造
- 不编造文本中没有的信息

进阶：用 Code 节点拆分 action items。 如果要把每个 action item 单独推送到飞书（@负责人），在 LLM 之后加一个 Code 节点，让 LLM 输出 JSON 而非 Markdown，然后解析成数组：

// Code 节点：解析 LLM 的 JSON 输出，拆成多个 item
const raw = $input.first().json.text; // LLM 输出
const parsed = JSON.parse(raw);
const actionItems = parsed.action_items || [];

// 每条 action item 输出为一个独立 item，供下游逐条分发
return actionItems.map(item => ({
  json: {
    task: item.task,
    owner: item.owner,
    deadline: item.deadline,
    full_minutes: parsed.summary // 完整纪要附带
  }
}));

配合 Split Out 节点也可以实现同样效果，Code 节点更灵活。

步骤 4：分发到飞书 / 邮件 / Notion

纪要和 action items 生成后，按团队习惯分发。三种常见通道：

① 飞书（HTTP Request 调飞书自定义机器人 webhook）

n8n 没有原生飞书节点，用 HTTP Request 调飞书自定义机器人的 Incoming Webhook。先在飞书群添加自定义机器人，拿到 webhook URL。

// HTTP Request 节点 → 飞书 webhook
// Method: POST
// URL: https://open.feishu.cn/open-apis/bot/v2/hook/xxx
// Headers: Content-Type: application/json
// Body (JSON):
{
  "msg_type": "interactive",
  "card": {
    "header": {
      "title": { "tag": "plain_text", "content": "会议纪要 - {{ $json.date }}" }
    },
    "elements": [
      {
        "tag": "markdown",
        "content": "{{ $json.minutes }}"
      }
    ]
  }
}

② 邮件（Email Send 节点）

n8n 内置 Email Send 节点，通过 SMTP 发送。配好 SMTP 凭证（Gmail、企业邮箱等），收件人、主题、正文用表达式引用 LLM 输出。

③ Notion（Notion 节点归档）

n8n 内置 Notion 节点，可以把纪要写入 Notion 数据库，便于后续检索和跟踪。配置 Notion 凭证（OAuth 或 Internal Integration Token），操作选 Create Database Page，指定 Database ID，把摘要、action items 填入对应属性。

分发建议：飞书推 action item（@负责人即时触达）+ Notion 归档完整纪要（可检索可追溯）+ 邮件发摘要（兜底）。三通道覆盖"即时提醒 + 长期归档 + 被动通知"。

四、踩坑速查

坑一：录音质量差，转写一堆错。 Whisper 对清晰人声准确率很高，但背景噪音、远场麦克风、多人同时说话会导致大量错字。解法：录音用近场麦克风或会议系统直录（不外放收音）；上传前用 ffmpeg 降噪：

# ffmpeg 降噪处理（自托管 n8n 可用 Execute Command 节点跑）
ffmpeg -i input.mp3 -af "afftdn=nr=10" output.mp3

坑二：长音频超 Whisper 25 MB 限制。 一小时 mp3 约 15-30 MB，wav 更大，很容易超。解法：上传前用 ffmpeg 按时长分段（每段 20 分钟），分多次调 Whisper，最后拼接文本：

# 按时长切割音频（每段 1200 秒 = 20 分钟）
ffmpeg -i long_meeting.mp3 -f segment -segment_time 1200 -c copy chunk_%03d.mp3

自托管 n8n 用 Execute Command 节点跑 ffmpeg（以官方文档为准，云端版不支持此节点）；或在上传端预处理。

坑三：转写文本超 LLM token 上限。 一小时会议转写约 8000-15000 字（中文），GPT-4o 的上下文够用，但更长会议或便宜模型可能超限。解法：按 Whisper segments 分段送 LLM，每段生成摘要，再用一轮 LLM 汇总；或直接用长上下文模型（GPT-4o 128K、DeepSeek 64K）。

坑四：action item 抽不准——负责人张冠李戴或漏抽。 LLM 从口语转写中抽 action item 的难点：口语里"那个谁跟进一下"没指名。解法：① prompt 里要求"无法确定负责人时标'待确认'，禁止猜测"；② 让 LLM 输出 JSON 而非自由文本，结构化约束更紧；③ 会上养成"明确说'张三，周五前完成 XX'"的习惯，源头解决。

坑五：中文专有名词、人名、术语转写错。 Whisper 对常见中文词准确，但公司内部人名、产品代号、行业术语经常错。解法：用 Whisper 的 prompt 参数提供上下文词汇——prompt 里放一段包含专有名词的参考文本，Whisper 会据此调整识别：

// Whisper prompt 参数示例（提供专有名词上下文）
"prompt": "以下是会议中可能提到的人名和术语：张伟、李娜、Project Alpha、Q3 OKR、飞书多维表格。"

坑六：发言人区分（diarization）。 Whisper API 本身不支持发言人区分——转写结果是一段连续文本，不标注"说话人 A / 说话人 B"。解法：① 用 verbose_json 获取 segments 时间戳，配合静音段粗分；② 接第三方 diarization 服务（如 pyannote.audio）做后处理；③ 如果只需要纪要不需要逐字记录，让 LLM 在生成纪要时根据上下文推断发言人（效果有限，适合发言清晰的会议）。

FAQ

Q1：不用 OpenAI Whisper，能换别的转写服务吗？ A：能。把步骤 2 的 HTTP Request 换成别的转写 API 即可——阿里云语音识别、腾讯云 ASR、Azure Speech to Text 都有 REST API，n8n 用 HTTP Request 调，参数结构类似。中文场景国产 ASR 在方言和专有名词上可能更准。端点和参数以各服务商文档为准。

Q2：没有自托管 n8n，用云端版能跑吗？ A：能。n8n 云端版支持所有核心节点，但 Local File Trigger 和 Execute Command 节点不可用（安全限制）。改用 Webhook 触发 + 上传端预处理音频即可。云端版 webhook 直接公网可达，不用配 ngrok。

Q3：飞书机器人 webhook 怎么配？ A：飞书群 → 设置 → 群机器人 → 添加机器人 → 选"自定义机器人"，复制 webhook URL（格式 https://open.feishu.cn/open-apis/bot/v2/hook/xxx），填到 n8n 的 HTTP Request 节点 URL 里。如果开了签名校验，需要在请求体里加 timestamp 和 sign 字段，签名算法见飞书开放平台文档。

Q4：一小时以上的长会议怎么处理？ A：两步拆解——先按时间分段切割音频（坑二），分批调 Whisper 转写，拼接全文；再按段落送 LLM 生成摘要，最后汇总。如果用 GPT-4o 等长上下文模型，一小时会议的转写文本（约 1-2 万字）通常在上下文窗口内，可直接整段送入，不需要分段。

Q5：action item 能自动创建到 Jira/飞书任务吗？ A：能。步骤 3 的 Code 节点把 action items 拆成独立 item 后，接 n8n 的 Jira 节点或飞书任务 API（HTTP Request），每条 item 创建一个任务。需要配置对应凭证和项目 ID。具体节点参数以 n8n 文档为准。

看法

这套工作流的本质不是"用 AI 替人记会议纪要"，而是把"录音 → 可执行任务"这条本该自动化的链路补上。Whisper 解决了"听写"问题，LLM 解决了"结构化"问题，n8n 解决了"串起来自动跑"的问题。三者的成本都很低——一小时会议 $0.36 转写费 + 一次 LLM 调用，比让人花两小时整理纪要便宜太多。

真正的难点不在搭工作流（n8n 画布拖四个节点的事），在两处：一是录音质量，垃圾进垃圾出，再好的 ASR 也救不了远场噪音录音；二是 prompt 设计，action item 抽得准不准全靠 prompt 约束。把这两头抓好，工作流就能稳定产出比人工整理更一致、更不漏的纪要。

参考来源

• n8n 官方文档：https://docs.n8n.io
• n8n Webhook 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/
• n8n HTTP Request 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/
• n8n Basic LLM Chain 节点文档：https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.chainllm/
• n8n GitHub（n8n-io/n8n）：https://github.com/n8n-io/n8n
• OpenAI Whisper API 参考：https://platform.openai.com/docs/api-reference/audio/createTranscription
• OpenAI 语音转文字指南：https://platform.openai.com/docs/guides/speech-to-text
• OpenAI 定价：https://openai.com/pricing
• 飞书自定义机器人：https://open.feishu.cn/document/client-docs/bot-v3/add-custom-bot
• 本文 n8n 节点名与 Whisper 接口参数以官方文档为准，经核实后定稿