如何用 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 语音识别工作流适合的场景很具体场景痛点工作流做法客服录音质检录音量大人工回听成本高定时批量转写结果入数据库会议纪要会后整理耗时长录音转文字后交给 LLM 总结播客/课程内容需要字幕或文稿转写后写入文件或推送语音留言/工单内容无法被检索转写后做关键词提取不适合的场景也要说清楚实时通话中的逐字转写不适合这条路线它需要流式 API 和 WebSocket超出了普通 HTTP 节点的舒适区本文解决的是文件已存在批量转写的问题。三个节点怎么串起来整个 n8n Whisper 集成工作流的核心就是把三个节点按顺序连起来Read Binary File → HTTP Request → Set (读音频) (调识别API) (取文本)第一步Read Binary File 读取音频这个节点负责从磁盘把音频文件读进来挂在 item 的 binary 字段上。两个参数File Path音频文件路径如/data/audio/recording.wavProperty Name二进制数据的属性名默认data建议改成audioData避免和别的节点冲突它的源码在packages/nodes-base/nodes/ReadBinaryFile/ReadBinaryFile.node.ts实现上用的是 read stream读取流所以大文件也不会把内存撑爆。第二步HTTP Request 调用识别引擎以 OpenAI Whisper API 为例关键配置Method:POSTURL:https://api.openai.com/v1/audio/transcriptionsBody Type:Form Data-multipart表单字段model→whisper-1file→ 选 Binary Property指向audioDatalanguage→ 可选如en用 n8n 凭证存 API Key而不是硬编码在请求头里这样密钥不会出现在工作流 JSON 中导出、分享都安全。第三步Set 节点提取文本Whisper 返回的 JSON 里text字段就是转写结果。在 Set 节点里加一个字段Name:transcriptionValue:{{ $json.text }}后面所有节点写文件、发邮件、入库都消费这个字段链路就干净了。语音引擎怎么选n8n 本身不带识别能力引擎靠外部 API 提供。主流三条路维度OpenAI Whisper APIGoogle Cloud Speech-to-Text自托管开源Vosk 等端点POST /v1/audio/transcriptionsPOST https://speech.googleapis.com/v1/speech:recognize自建服务如http://localhost:2700音频传法multipart 表单上传JSON base64 内嵌取决于实现多语言强自动检测强弱按模型语言成本按时长计费按时长计费一次性服务器成本隐私数据出境数据出境完全本地选型建议默认选 Whisper多语言、长音频、准确率综合最好接入最简单。已在 Google 生态且需要流式/批量 API选 Google STT。注意它的音频要走 base64请求体长这样{ config: { encoding: LINEAR16, sampleRateHertz: 16000, languageCode: en-US }, audio: { content: …base64… } }base64 会让请求体膨胀约 33%超长音频建议先分段。录音含敏感数据、不能出内网自部署 Voskn8n 侧还是同一个 HTTP Request 节点只换 URL。手把手跑通一遍完整配置假设服务器上有/data/conference_call.wav目标是把转写文本存成文件。节点 1 — Read Binary FileFile Path:/data/conference_call.wavProperty Name:audioData节点 2 — HTTP RequestPOST →https://api.openai.com/v1/audio/transcriptionsAuthorization: 选预置的 OpenAI 凭证Body:Form Data-multipart字段modelwhisper-1、languageen、file指向二进制audioData节点 3 — Settranscription{{ $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_TIMEOUT600如果要在 Code 节点里 import 第三方库记得配NODE_FUNCTION_ALLOW_EXTERNAL。凭证一律走 n8n 凭证管理器不落配置文件。踩坑排查清单现象大概率原因处理API 返回 401凭证没选对 / Key 失效确认 HTTP Request 的 Authorization 引用了凭证返回 400提示 file 相关body 类型选错必须选Form Data-multipart不能选 JSON 传文件输出里有乱码或截断音频编码 API 不支持先转码为 WAV/MP3/M4A 再进工作流长时间音频直接超时超时没调HTTP Request 节点超时调到 600s或先分段Google 接口 4xxbase64 没做 / 采样率写错检查encoding和sampleRateHertz与实际文件一致Set 节点拿不到 textresponse_format 是 verbose_json字段在{{ $json.text }}没问题检查响应里是否多包了一层收尾回看这条链路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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何用 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 语音识别工作流适合的场景很具体场景痛点工作流做法客服录音质检录音量大人工回听成本高定时批量转写结果入数据库会议纪要会后整理耗时长录音转文字后交给 LLM 总结播客/课程内容需要字幕或文稿转写后写入文件或推送语音留言/工单内容无法被检索转写后做关键词提取不适合的场景也要说清楚实时通话中的逐字转写不适合这条路线它需要流式 API 和 WebSocket超出了普通 HTTP 节点的舒适区本文解决的是文件已存在批量转写的问题。三个节点怎么串起来整个 n8n Whisper 集成工作流的核心就是把三个节点按顺序连起来Read Binary File → HTTP Request → Set (读音频) (调识别API) (取文本)第一步Read Binary File 读取音频这个节点负责从磁盘把音频文件读进来挂在 item 的 binary 字段上。两个参数File Path音频文件路径如/data/audio/recording.wavProperty Name二进制数据的属性名默认data建议改成audioData避免和别的节点冲突它的源码在packages/nodes-base/nodes/ReadBinaryFile/ReadBinaryFile.node.ts实现上用的是 read stream读取流所以大文件也不会把内存撑爆。第二步HTTP Request 调用识别引擎以 OpenAI Whisper API 为例关键配置Method:POSTURL:https://api.openai.com/v1/audio/transcriptionsBody Type:Form Data-multipart表单字段model→whisper-1file→ 选 Binary Property指向audioDatalanguage→ 可选如en用 n8n 凭证存 API Key而不是硬编码在请求头里这样密钥不会出现在工作流 JSON 中导出、分享都安全。第三步Set 节点提取文本Whisper 返回的 JSON 里text字段就是转写结果。在 Set 节点里加一个字段Name:transcriptionValue:{{ $json.text }}后面所有节点写文件、发邮件、入库都消费这个字段链路就干净了。语音引擎怎么选n8n 本身不带识别能力引擎靠外部 API 提供。主流三条路维度OpenAI Whisper APIGoogle Cloud Speech-to-Text自托管开源Vosk 等端点POST /v1/audio/transcriptionsPOST https://speech.googleapis.com/v1/speech:recognize自建服务如http://localhost:2700音频传法multipart 表单上传JSON base64 内嵌取决于实现多语言强自动检测强弱按模型语言成本按时长计费按时长计费一次性服务器成本隐私数据出境数据出境完全本地选型建议默认选 Whisper多语言、长音频、准确率综合最好接入最简单。已在 Google 生态且需要流式/批量 API选 Google STT。注意它的音频要走 base64请求体长这样{ config: { encoding: LINEAR16, sampleRateHertz: 16000, languageCode: en-US }, audio: { content: …base64… } }base64 会让请求体膨胀约 33%超长音频建议先分段。录音含敏感数据、不能出内网自部署 Voskn8n 侧还是同一个 HTTP Request 节点只换 URL。手把手跑通一遍完整配置假设服务器上有/data/conference_call.wav目标是把转写文本存成文件。节点 1 — Read Binary FileFile Path:/data/conference_call.wavProperty Name:audioData节点 2 — HTTP RequestPOST →https://api.openai.com/v1/audio/transcriptionsAuthorization: 选预置的 OpenAI 凭证Body:Form Data-multipart字段modelwhisper-1、languageen、file指向二进制audioData节点 3 — Settranscription{{ $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_TIMEOUT600如果要在 Code 节点里 import 第三方库记得配NODE_FUNCTION_ALLOW_EXTERNAL。凭证一律走 n8n 凭证管理器不落配置文件。踩坑排查清单现象大概率原因处理API 返回 401凭证没选对 / Key 失效确认 HTTP Request 的 Authorization 引用了凭证返回 400提示 file 相关body 类型选错必须选Form Data-multipart不能选 JSON 传文件输出里有乱码或截断音频编码 API 不支持先转码为 WAV/MP3/M4A 再进工作流长时间音频直接超时超时没调HTTP Request 节点超时调到 600s或先分段Google 接口 4xxbase64 没做 / 采样率写错检查encoding和sampleRateHertz与实际文件一致Set 节点拿不到 textresponse_format 是 verbose_json字段在{{ $json.text }}没问题检查响应里是否多包了一层收尾回看这条链路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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
