故障排查
排查常见问题
排查录音、权限、转写质量、API 和素材采集问题。
- 适合用户
- 工作流被卡住、需要一步步恢复的用户。
- 预计时间
- 16 分钟
- 难度
- 所有用户
使用场景
先确认这篇教程适合什么工作流，再进入操作步骤。
作为准备真实工作流的用户，我想有一份常见失败检查表，这样能修复问题，又不丢录音、不暴露隐私。
你可以判断问题大概发生在哪一层，并收集安全的支持信息。
完整步骤
1
先分类故障
先判断问题属于捕捉、上传、转写、模板输出、API 认证，还是复盘。
你能说出第一个失败步骤。
没有随机修改无关设置。
2
收集安全支持信息
截取能说明错误的截图或日志，但遮挡密钥、私人姓名和敏感原文。
支持信息里没有凭据。
时间和失败动作可见。
3
重试最小安全步骤
用小样本录音或占位 API 请求重试，不要重复整个高风险流程。
重试足够小，可以重复。
结果能说明故障是否还在同一层。
补充说明
故障层级图
大多数问题只要先分清失败层级，就会容易很多。
- 捕捉：麦克风、权限、文件格式。
- 处理：上传、转写、长音频行为。
- 输出：模板质量、词典术语、复盘状态。
- 自动化：认证 Header、接口、密钥处理。
恢复已停止的桌面录音
桌面端录音停止时，只要存在实际音频，就会先保留到本地 Records，再执行后续处理。如果语音检测、网络、转写或 AI 处理失败，请先检查 Records，不要立即重新录音。
- 打开 Records，找到停止录音时创建的条目。
- 重试转写前，先播放或检查保留的音频。
- 如果本地没有条目，记录发生时间和捕捉状态，并在不暴露私人音频的前提下联系支持。
确认 AI 优化是否真的运行
桌面端可以在最后语音稳定时只启动一次 AI 优化，并在录音结束时复用这份预取结果。因此，finalize 很快返回不代表跳过了 AI，也不应该再触发第二次工作流。
- 先检查保存结果标记为已优化、原文降级、处理中还是失败；这些状态不能混为一谈。
- Records 重试成功后，桌面端诊断信息应保留服务端返回的实际 n8n 工作流名称、工作流 ID 和调用 ID。
- 联系支持时，提供时间和诊断日志中已脱敏的 workflow/call 标识；不要提供转写原文、API key 或 webhook URL。
- 预取缓存命中应复用第一次工作流调用，并跳过重复派发。
关联功能路径
这篇教程完成后，不应该停在这里。下面是它自然连接到的功能和下一步。