AI语音转文字+自动邮件：语音留言变工单

很多小企业的“信息堵点”不在客户不联系你，而在客户联系你时你没看到：电话没接到、语音留言懒得听、转给同事又丢上下文。把语音留言变成可检索、可转派、可追踪的文本，其实比招一个“24小时前台”更实在。

我更愿意把这类方案叫作“最小可行的AI语音助手”：它不需要能闲聊，也不需要复杂意图识别，只要把电话内容可靠地转成文字，并且自动送到你最常用的渠道（邮箱、工单系统、企业微信等）。这类自动化工作流在智慧城市建设里也很常见：城市服务热线、社区物业报修、停车场求助电话、园区安保值守……核心诉求都一样：用语音入口承接需求，用自动化把信息推到该处理的人手里。

下面用一个非常落地的组合来实现：Twilio Studio（接电话+录音）+ Deepgram（语音识别/转录）+ Pipedream（自动化编排+发邮件）。它既适合小企业快速上线，也能作为智慧城市项目里“市民语音入口”的原型。

为什么“转录并邮件通知”比“听语音”更靠谱

直接给结论：文本比语音更适合进入业务流程。语音适合输入，不适合分发、检索和审计。

把留言自动转为文本并发送到邮箱（或工单系统）后，你能立刻获得这些管理上的好处：

• 响应速度更快：邮件/工单能触发提醒与值班轮转；语音留言通常只躺在某个号码的收件箱里。
• 可搜索、可复制、可转发：客户电话里提到的订单号、地址、设备编号能被搜索到。
• 更容易结构化：在Pipedream里可以把文本再提取成字段（姓名、电话、地点、问题类型），自动打标签或分派。
• 合规与审计更清晰：文本记录更易留存（当然也要注意隐私与授权，后面会讲）。

对“人工智能在智慧城市建设”的语境来说，这一步尤其关键：城市治理的难点不是收不到诉求，而是诉求分流与闭环。语音转录+自动分发，就是把“热线”从单一通道升级成可运营的数据流。

整体架构：三块积木拼出一个AI语音助手工作流

先把系统讲清楚，你后面搭建会少走弯路。

工作流链路（Answer-first版）：

1. Twilio Studio Flow：来电进入后播放提示语，并录制留言。
2. Twilio Add-on + Deepgram：录音完成后触发转录（使用 Deepgram 增强转录），并把转录任务信息以 webhook 形式回调。
3. Pipedream Workflow：接 webhook → 解析负载 → 向 Twilio API 拉取转录结果 → 格式化 → 发邮件。

一句话概括：Twilio负责“电话”，Deepgram负责“听懂”，Pipedream负责“送达与自动化”。

你需要准备什么（小企业友好清单）

• Twilio 账号与一个可接听的语音号码
• Pipedream 账号（用来接 webhook、写一点点 Node 代码、发邮件）
• Twilio 控制台里启用 Deepgram 转录 Add-on（Enhanced 版本）

如果你在国内做智慧园区/物业项目，也可以把这套思路映射到本地通信平台与ASR服务上；关键是**“录音 → ASR → webhook → 自动化分发”**这个模式。

搭建步骤（按最少踩坑的顺序）

下面的步骤基于原教程，但我会补上“为什么要这么做”以及一些更贴近业务的改造点。

1) 用 Twilio Studio 接电话并录音

直接做法：在 Twilio Studio 新建一个 Flow（比如叫 Transcribe Voicemail），并串起两个关键组件：

• Say/Play：播放提示语，例如：Hello. Leave a message please.
• Record Voicemail：录制留言，建议配置：
  • Trim silence: Trim silence（去掉前后静音）
  • Play beep: True（提示用户开始说）

然后把你的 Twilio 号码的 A Call Comes In 绑定到这个 Studio Flow。

业务建议（我强烈建议你加上）：

• 提示语里加一句隐私与录音告知，例如“为提升服务质量，本次通话将被录音并转为文字记录”。在很多城市服务场景里这是必须的。
• 设置最大留言时长（比如60-120秒）。越长越容易出现噪声、跑题与成本上升。

2) 先建 Pipedream Webhook，再回 Twilio 配 Deepgram Add-on

顺序原因：Twilio Add-on 需要一个可用的 Callback URL。

在 Pipedream 创建新 Workflow，触发器选：

• HTTP / Webhook
• HTTP Requests with a Body

保存后复制 webhook URL。

接着在 Twilio 控制台启用 Deepgram Enhanced Transcription Add-on，并在 Configure 里：

• Unique Name 设为：deepgram_enhanced_transcription
• Use In 全勾选（按教程做）
• Callback URL 粘贴 Pipedream 的 webhook
• Method 选 POST

先打一通电话做“样本数据”

这一步很关键：Pipedream 需要看到一次真实事件，后面你才知道字段路径。

打电话到 Twilio 号码留一段语音，回到 Pipedream 的 trigger 结果里查看 payload。

3) 在 Pipedream 解析 AddOns 字段（它是 JSON 字符串）

Twilio webhook 的 AddOns 通常是一个 JSON 字符串。先用 Node 步骤解析：

export default defineComponent({
  async run({ steps, $ }) {
    const addOnData = JSON.parse(steps.trigger.event.AddOns);
    return addOnData;
  },
})

解析后你会拿到 Deepgram add-on 的结果元数据，其中包含一个 url——这不是最终转录文本，而是拉取转录结果的地址。

4) 用 HTTP 请求从 Twilio 拉取转录结果

新增一步 Send any HTTP Request（GET 请求），URL 使用上一步返回值：

• URL：{{steps.node.$return_value.results.deepgram_enhanced_transcription.payload[0].url}}

认证方式：Basic Auth

• Username：Twilio Account SID
• Password：Twilio Auth Token

测试后，结果里应该能看到 Deepgram 的转录结构化输出（通常包含 channels[0].alternatives[0].transcript）。

5) 把转录文本邮件发给自己（或发给值班组）

新增一步 Send Email：

• Subject 示例：Call Transcript - {{steps.trigger.context.ts}}
• Body 示例：
  • {{steps.custom_request.$return_value.results.channels[0].alternatives[0].transcript}}

到这里，“语音留言 → 自动转录 → 邮件通知”就跑通了。

让它更像“AI语音助手”：三种实用增强

把工作流跑通只是第一步。真正省时间的，是把“邮件提醒”变成“可执行任务”。

1) 邮件内容要能直接行动（推荐模板）

把邮件正文从“只有一段转录”升级成信息卡片：

• 来电号码（Caller）
• 通话时间
• 转录文本
• 置信度/是否可能有误（如果结果里有评分字段）
• 下一步建议（例如“回复客户”“创建工单”“回拨电话”）

即使你暂时不接入工单系统，这种格式也会让团队更愿意看。

2) 自动打标签与分派（小企业也用得上）

Pipedream 里可以加一步简单的规则引擎：

• 包含“发票/开票” → 财务邮箱
• 包含“报修/漏水/停电” → 运维值班邮箱
• 包含“投诉/噪音” → 客服主管

在智慧城市场景，这相当于热线的“初筛分流”，能显著降低人工分拣压力。

3) 成本与质量的平衡：别一上来就追求“全量录音全转录”

我的建议是：

• 先只转录“未接来电+语音留言”，这是性价比最高的部分。
• 控制单次录音时长与并发，避免账单不可控。
• 对高价值线路（例如市政应急、园区安防）再考虑更高质量模型与冗余。

安全与合规：这不是“可选项”

把语音转成文本后，信息可用性变强了，风险也变大了。建议至少做到：

• 录音与转录告知：提示语明确告知用途与留存。
• 最小化留存：只保留必要字段，设定自动清理周期（比如30/90天）。
• 访问控制：邮箱转发范围要可控；更理想是进入权限明确的工单系统。
• 敏感信息处理：如果留言里常出现身份证号、地址等，可以在 Pipedream 增加脱敏步骤（正则替换）。

在智慧城市建设里，公共服务数据往往涉及个人信息与事件信息，合规设计要前置，而不是上线后补救。

常见问题（你大概率会遇到）

Q1：为什么 webhook 里没有直接带转录文本？

因为回调通常只携带任务元数据与查询地址。这样做能避免回调体过大，也更适合异步转录。

Q2：转录质量不稳定怎么办？

先排查两件事：

1. 录音质量：背景噪声、话筒距离、线路质量会显著影响 ASR。
2. 提示语：引导用户“说慢一点、报设备号/地址时重复一次”，质量会立刻提升。

Q3：能不能不发邮件，直接进工单/IM？

可以，而且更推荐。邮件是最容易起步的通知方式；稳定后可把最后一步换成：

• 创建工单（Jira/ServiceNow/自建系统）
• 推送企业微信/钉钉
• 写入数据库形成“城市治理事件流”

把这个案例放进智慧城市的叙事里

智慧城市的“入口”很多：App、二维码、热线电话、社区终端。但最普适的入口依然是电话——不需要下载、不挑机型、老人也会用。

这套“AI语音识别 + 自动化工作流”其实是在做一件很朴素的事：把电话这种非结构化入口，变成可治理的结构化事件。小企业用它提升客服与运营效率；城市治理用它缩短诉求闭环时间、减少漏单、提升服务一致性。

如果你准备从零搭一个语音留言自动化，我建议你先把目标定得简单点：

1. 先实现“留言转录 + 自动通知”跑通闭环
2. 再做“标签分流 + 自动建单”让团队真的省时间
3. 最后再做“数据看板 + SLA”让运营可量化

下一步你想把它接到哪个渠道：工单系统、企业微信，还是直接进入城市事件中台？