企业官网建设流程全解析

如何用 n8n 搭一条语音转文本工作流：从会议录音到可读文本，一次跑通

【免费下载链接】n8nFair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations.项目地址: https://gitcode.com/GitHub_Trending/n8/n8n

周五下午，你面前堆着 20 段客户电话录音和 3 小时的项目复盘会议录音。手工听、手工记、手工整理，光听就要一天。如果在 n8n 里搭一条语音转文本工作流，这些音频文件可以在几小时内自动变成结构化文本——这就是本文要带你完成的事：用 n8n 的语音识别工作流，把"录音进、文字出"变成一条可复用的流水线。

整条链路只依赖三类节点：Read Binary File（读音频）、HTTP Request（调识别 API）、Set（提取文本）。不写一行代码也能跑，会写表达式则能玩出更多花样。

这套方案能解决什么问题

n8n 语音识别工作流适合的场景很具体：

不适合的场景也要说清楚：实时通话中的逐字转写不适合这条路线，它需要流式 API 和 WebSocket，超出了普通 HTTP 节点的舒适区；本文解决的是"文件已存在，批量转写"的问题。

三个节点怎么串起来

整个 n8n Whisper 集成工作流的核心，就是把三个节点按顺序连起来：

Read Binary File → HTTP Request → Set (读音频) (调识别API) (取文本)

第一步：Read Binary File 读取音频

这个节点负责从磁盘把音频文件读进来，挂在 item 的 binary 字段上。两个参数：

• File Path：音频文件路径，如/data/audio/recording.wav
• Property Name：二进制数据的属性名，默认data，建议改成audioData避免和别的节点冲突

它的源码在packages/nodes-base/nodes/ReadBinaryFile/ReadBinaryFile.node.ts，实现上用的是 read stream（读取流），所以大文件也不会把内存撑爆。

第二步：HTTP Request 调用识别引擎

以 OpenAI Whisper API 为例，关键配置：

• Method:POST
• URL:https://api.openai.com/v1/audio/transcriptions
• Body Type:Form Data-multipart
• 表单字段：
  • model→whisper-1
  • file→ 选 Binary Property，指向audioData
  • language→ 可选，如en

用 n8n 凭证存 API Key（而不是硬编码在请求头里），这样密钥不会出现在工作流 JSON 中，导出、分享都安全。

第三步：Set 节点提取文本

Whisper 返回的 JSON 里text字段就是转写结果。在 Set 节点里加一个字段：

• Name:transcription
• Value:{{ $json.text }}

后面所有节点（写文件、发邮件、入库）都消费这个字段，链路就干净了。

语音引擎怎么选

n8n 本身不带识别能力，引擎靠外部 API 提供。主流三条路：

选型建议：

• 默认选 Whisper：多语言、长音频、准确率综合最好，接入最简单。
• 已在 Google 生态且需要流式/批量 API：选 Google STT。注意它的音频要走 base64，请求体长这样：

{ "config": { "encoding": "LINEAR16", "sampleRateHertz": 16000, "languageCode": "en-US" }, "audio": { "content": "…base64…" } }

base64 会让请求体膨胀约 33%，超长音频建议先分段。

• 录音含敏感数据、不能出内网：自部署 Vosk，n8n 侧还是同一个 HTTP Request 节点，只换 URL。

手把手跑通一遍：完整配置

假设服务器上有/data/conference_call.wav，目标是把转写文本存成文件。

节点 1 — Read Binary File

• File Path:/data/conference_call.wav
• Property Name:audioData

节点 2 — HTTP Request

• POST →https://api.openai.com/v1/audio/transcriptions
• Authorization: 选预置的 OpenAI 凭证
• Body:Form Data-multipart，字段model=whisper-1、language=en、file指向二进制audioData

节点 3 — Set

• transcription={{ $json.text }}

节点 4 — 写文件

用文件写入节点（Read/Write Files from Disk）把{{ $json.transcription }}写到/data/transcripts/conference_notes.txt。

跑一次，看每个节点的 output 面板确认数据流：binary 有没有挂上、API 返回的text对不对、Set 之后字段名对不对。三处都对了，这条 n8n 语音转文本工作流就算通了。

让它稳定跑在生产上

跑通只是开始，批量和定时才是价值所在。

1. 用 Cron + 目录扫描做批量

Cron 节点定时触发 → 文件列表节点扫描新音频 →Split In Batches把文件切成小批次（比如每批 5 个），逐个走上面的转写链路，最后汇总。批次大小按 API 限流和音频时长调。

2. 给 HTTP Request 加超时

长音频转写可能几分钟。把该节点超时调大到 600 秒，别让默认值先杀掉请求。

3. 错误隔离

对 HTTP Request 开启Continue On Fail，单个文件转写失败不会打断整批，失败的 item 走一条错误分支（比如发邮件告警）。

4. 容器化部署要点

Docker Compose 里把音频目录和转写目录挂成 volume，环境变量加N8N_TIMEOUT=600；如果要在 Code 节点里 import 第三方库，记得配NODE_FUNCTION_ALLOW_EXTERNAL。凭证一律走 n8n 凭证管理器，不落配置文件。

踩坑排查清单

收尾

回看这条链路：Read Binary File 负责"取"，HTTP Request 负责"算"，Set 负责"理"。节点少，但每一环都可以替换——换引擎、加情感分析（把transcription喂给 LLM 节点）、结果入库、推送到飞书/邮件，都是往这条主干上挂分支。

n8n 语音识别工作流的真正价值不在于转写本身，而在于它把"音频 → 文本 → 后续自动化"接成了一条不需要人盯的流水线。先把单文件跑通，再上批量和定时，你会发现自己处理录音的方式再也回不去了。

【免费下载链接】n8nFair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations.项目地址: https://gitcode.com/GitHub_Trending/n8/n8n