用 Twilio+Python 把电话自动转文字并入库

客服电话最“浪费”的部分，不是通话本身，而是通话后的手工整理：谁打来的、说了什么、要跟进什么、有没有承诺回拨、有没有投诉点。很多小企业会把这些信息留在员工脑子里、聊天记录里、或者零散的表格里——等到要复盘、交接、追责时，基本就等于没有。

这篇文章把 Deepgram 的电话语音识别 + Twilio 的通话录音串起来，用 Python 搭一个最小可用的“电话自动转写”服务。更关键的是：我们会用“小企业自动化工作流”的角度重写这个教程——不止是把语音转成文字，而是把它变成可搜索、可分配、可追踪的运营数据，为后续的 AI 语音助手、CRM、工单系统、以及 5G/6G 场景下的实时通信智能化打底。

直白点说：把电话从“瞬时沟通”变成“可被自动化处理的结构化事件”。这才是真正能省人力的地方。

把电话转写接进自动化工作流：你要的不是文字，是“事件”

把电话录下来再人工听，是很多团队的常规操作，但效率很低。语音识别的价值在于：它能把音频变成机器可读的信息，让后续自动化成立。

一个更实用的目标是：每通电话结束后，系统自动生成一条“通话事件”，至少包含：

• 来电时间、通话时长、对话双方（或通道）
• 全量转写文本（带标点、分段更好）
• 关键字段（客户姓名/公司/需求/预算/地点/回拨时间）
• 下一步动作（创建任务、发提醒、更新 CRM、生成工单）

这类事件化数据在“人工智能在通信与 5G/6G”系列里非常重要：通信系统越来越数据化、实时化，语音作为非结构化数据，如果不先被转换成结构化事件，就没法进入流量预测、服务质量监控、自动质检、智能运维等更上层的能力。

方案架构（Twilio + Deepgram + Flask）：小而够用

这套方案的核心链路很清晰：

1. Twilio 号码接听/拨号：把来电转接到你指定的电话，同时开启录音（双通道更利于分离双方说话）。
2. Twilio 录音回调 Webhook：通话结束后，Twilio 把录音 URL 发到你的服务端。
3. Deepgram 预录音转写：你的服务端拿到录音 URL，调用 Deepgram Speech-to-Text，把音频转成带标点的文本，并按 utterance（话轮）切分。
4. 落库 + 展示/对接：先用轻量 DB（比如 JSON DB）落地，再逐步对接 CRM/工单/任务系统。

为什么这套组合适合小企业？因为它把复杂问题拆成两件你能控制的事：

• 通话基础设施交给 Twilio（稳定、合规能力强）
• 语音识别交给 Deepgram（有适合电话场景的模型）

你只需要写一个很薄的“粘合层”（Flask 服务），就能把电话接进你的自动化工作流。

你会用到的组件

• Twilio：购买有语音能力的号码、配置 Voice webhook、获取 RecordingUrl
• Deepgram Python SDK：完成 speech-to-text（电话模型、双通道、多说话人片段）
• Flask（含 async 支持）：提供 /inbound、/recordings、/transcribe 等路由
• Ngrok：本地开发时暴露公网 URL，方便 Twilio 回调
• PysonDB（轻量 JSON 数据库）：先把转写结果存起来，验证业务闭环

按步骤搭建：把“能跑起来”作为第一目标

下面的步骤源自原教程，但我会用“生产思维”补上几个更容易踩坑的点。

1）准备密钥与环境变量

你需要：

• Deepgram API Key
• Twilio 账号 + 语音号码
• 一个接听电话的真实号码（比如老板手机或客服手机）

用 .env 管理配置（别把 key 写死在代码里）：

DEEPGRAM_API_KEY=YOUR_API_KEY
RECEIVER_NUMBER=+8613xxxxxxxxx

2）安装依赖并启动 Flask

依赖（按原文示例）包括 Deepgram SDK、Twilio、dotenv、Flask、async、PysonDB：

pip install deepgram-sdk twilio python-dotenv Flask 'flask[async]' pysondb

先用最小 Flask 验证环境没问题：

from flask import Flask

app = Flask(__name__)

@app.get("/")
def hello():
    return "Hello World!"

if __name__ == "__main__":
    app.run()

3）用 Ngrok 暴露回调地址，并配置 Twilio

Twilio 的 webhook 必须是公网可访问 URL。本地开发用 ngrok 最快。

你会得到一个类似 https://xxxx.ngrok.io 的地址，把它配置到 Twilio 的号码上。

原教程把录音回调指向：

• https://<ngrok-domain>/recordings

这个设置很关键：通话结束后触发的不是你主动拉取，而是 Twilio 推给你。

4）实现 /inbound：接通、转接、并录音

核心点：用 TwiML 的 Dial 开启录音，并设置 recording_status_callback。

from flask import Flask
import os
from twilio.twiml.voice_response import Dial, VoiceResponse
from dotenv import load_dotenv

app = Flask(__name__)
load_dotenv()

@app.post("/inbound")
def inbound_call():
    response = VoiceResponse()
    dial = Dial(
        record='record-from-answer-dual',
        recording_status_callback='https://<your-ngrok-domain>/recordings'
    )
    dial.number(os.getenv("RECEIVER_NUMBER"))
    response.append(dial)
    return str(response)

为什么选 record-from-answer-dual？

• from-answer：对方接起才开始录，避免空录音
• dual：双通道更利于把双方声音分开，后续做质检/摘要/争议定位更靠谱

5）实现 /recordings：拿录音 URL 转写并落库

Twilio 会在回调里带上 RecordingUrl。你的服务端拿到它后调用 Deepgram：

import json
import os
from flask import request
from deepgram import Deepgram
from pysondb import db

calls_db = db.getDb('calls')

@app.route("/recordings", methods=['GET', 'POST'])
async def get_recordings():
    deepgram = Deepgram(os.getenv("DEEPGRAM_API_KEY"))

    recording_url = request.form['RecordingUrl']
    source = {'url': recording_url}

    transcript_data = await deepgram.transcription.prerecorded(
        source,
        {
            'punctuate': True,
            'utterances': True,
            'model': 'phonecall',
            'multichannel': True
        }
    )

    if 'results' in transcript_data:
        utterances = [
            {
                'channel': u['channel'],
                'transcript': u['transcript']
            }
            for u in transcript_data['results']['utterances']
        ]

        calls_db.addMany(utterances)
        return json.dumps(utterances, indent=4)

这里有两个非常“落地”的选择：

• model: 'phonecall'：电话场景的声学条件更差（压缩、回声、串音），用电话模型会更稳。
• utterances: True：直接输出“话轮”，后面做摘要、提取待办、判断情绪都会更容易。

6）实现 /transcribe：把结果展示出来（方便验收）

from flask import render_template

@app.route("/transcribe", methods=['GET', 'POST'])
def transcribe_call():
    context = calls_db.getAll()
    return render_template("index.html", context=context)

templates/index.html 最简单版本：

<!DOCTYPE html>
<html lang="en">
  <body>
    {% for c in context %}
      {{ c.transcript }}<br />
    {% endfor %}
  </body>
</html>

到这里你就完成了“打电话 → 自动转写 → 入库 → 可查看”的闭环。

从“能转写”到“能省人”：三种小企业最实用的自动化

转写只是第一步。真正的 ROI 来自把它接进你的日常流程。

1）电话转任务：自动生成待办与回拨提醒

最常见的损失是“答应回拨但忘了”。做法很直接：

• 用 utterances 合成全文
• 让一个 LLM 或规则引擎抽取：客户名、需求、截止时间
• 写入任务系统（哪怕先写到一个 Google Sheet/Notion/企业微信待办）

你不需要一步到位做“全自动”。我更推荐半自动：系统生成草稿，客服点一下确认。这样准确率和可控性都更好。

2）电话质检：把“抽查录音”变成“全量覆盖”

很多小团队不做质检，是因为听录音太费时间。转写后，质检可以先从文本筛查开始：

• 是否出现敏感词/竞品词/违规承诺
• 是否按 SOP 说到了关键步骤（比如身份核验、报价确认、售后条款）
• 是否出现明显负面情绪（可以先用关键词粗筛，再做更精细的情感模型）

在通信与 5G/6G 场景里，这属于“运营侧的智能运维”：用数据驱动服务质量，而不是凭感觉。

3）客户记录自动补全：减少 CRM 手工输入

CRM 最大的问题不是买不起，而是大家懒得写。

电话转写后，你可以把“本次沟通要点”自动写进 CRM 的备注字段，并标记：

• 本次诉求
• 下次跟进时间
• 相关产品/套餐

哪怕你只做到“自动写备注 + 人工校对”，也能把录入成本降到可接受水平。

生产化要注意的 5 个坑（很多人第一周就踩）

1. 录音 URL 权限与有效期：有的录音链接需要鉴权或有过期策略。生产环境建议把录音拉回自有存储或用受控访问。
2. 异步与队列：转写是耗时任务。通话量上来后，建议用队列（如 Celery/RQ）把转写从 webhook 请求里拆出去，避免超时。
3. 数据合规与告知：电话录音与转写涉及隐私与合规要求。务必做来电提示、存储加密、访问控制、保留周期。
4. 通道与说话人区分：双通道不等于“说话人识别”。但对电话场景来说，channel 维度已经能解决 80% 的定位问题。
5. 成本可控：别一上来就“全量、实时、最高精度”。从高价值电话（销售线索/投诉/高客单）先做起，最容易看到回报。

常见问题（People Also Ask）

电话语音识别一定要实时吗？

不一定。小企业更常见的需求是通话后 1-5 分钟内出转写，就足以驱动回拨、工单、CRM 记录。实时识别更复杂，也更贵。

为什么要用 Twilio，而不是手机直接录音？

手机录音难以标准化、难以集中管理，也很难触发自动化。Twilio 的价值是把通话变成可编排的通信流程：录音、回调、转接、路由都能用代码管理。

这套方案和 5G/6G 有什么关系？

5G/6G 让通信更实时、更低时延、更可编排。语音识别把“语音流量”转成“数据流量”，后续才能做自动分发、质量监控、业务分析与智能运维。

下一步：把“转写服务”升级成你的 AI 语音助手底座

如果你已经跑通了 Twilio + Deepgram + Python 的电话转写闭环，下一步建议按这个顺序升级：

1. 加通话元数据：Call SID、来电号码、时长、录音时长、时间戳
2. 加摘要与待办：每通电话自动生成 3 行摘要 + 1-3 个待办（人工确认）
3. 对接一个系统：先选任务系统或 CRM 的其中一个，别同时做
4. 做检索与权限：让管理者能搜“某客户/某关键词/某日期区间”的通话记录

电话自动转文字不是炫技，它是一种很务实的运营升级：把沟通成本转化成可复用的数据资产。当你的电话开始“自动写记录、自动出待办、自动进系统”，你就已经在用 AI 做流程自动化了。

你希望你的电话转写接到哪里：任务管理、CRM，还是售后工单？选一个高频场景先落地，效果会比做一个“大而全的语音助手”快得多。