用 Django 做实时语音转文字：小企业工作流实战

2024 年起，远程协作和多渠道客服把“说过的话”变成了高价值数据：会议结论、客户意向、工单细节、投诉证据、巡检记录……问题在于，大多数团队仍在用手工记要点或事后听录音补记录。结果就是：遗漏、延迟、争议、以及最贵的成本——重复沟通。

我更愿意把“实时语音转文字（Live Transcription）”看成一种基础设施，而不是一个炫技功能。它能把语音直接变成可检索、可路由、可自动化处理的数据流，进而接入你的AI 语音助手与自动化工作流。对小企业来说，这类能力不一定要上复杂的大平台：用 Python + Django，配合 WebSocket，把浏览器麦克风音频实时发到语音识别服务，再把文本推回页面，你就能搭起一个能跑起来的最小系统。

本文以 Django、Django Channels 和 Deepgram 的实时识别为主线，讲清楚：怎么做、怎么把它变成工作流、以及在“人工智能在智慧城市建设”的语境下，它如何落到真实场景（城市客服、社区治理、巡检记录、公共安全联动）。

实时语音转文字真正解决的是什么问题？

实时转写的核心价值只有一句话：把口头信息变成机器可执行的事件流。

传统录音+事后转写是“文件”，更像存档；实时转写是“流”，更像消息队列。这个差异决定了它能否进入自动化链路。

对小企业最直接的三类收益：

1. 客服与销售更快闭环：客户一边讲需求，系统一边生成要点、标签、以及工单字段（产品型号、地址、预算、紧急程度）。
2. 会议纪要不再靠一个人扛：实时识别把讨论内容变成文本，后续再做摘要、行动项提取、责任人分配。
3. 一线执行更少回填：仓库、门店、物业、巡检人员用手机说一句“2 号电梯异响，已报修”，系统立刻入库并通知相关人。

放到智慧城市建设的更大图景里，语音转文字常常是“城市数据采集”的入口：社区网格员、12345 热线、交警指令、应急调度口令，都需要低摩擦地进入系统。

系统架构：浏览器麦克风 → Django → 语音识别 → 实时回传

最稳妥的实现方式，是用两段 WebSocket 串起来：

• WebSocket A（浏览器 ↔ Django）：浏览器把麦克风音频切片发送到你的 Django 服务。
• WebSocket B（Django ↔ 识别服务）：Django 把音频转发给识别服务，收到转写结果后再推回浏览器。

这种“中间层”设计很关键，因为你可以在 Django 这一层做三件事：

• 鉴权与限流：谁能用、每分钟多少时长、是否要记账。
• 数据治理：脱敏、落库、审计、合规策略。
• 工作流编排：把文本变成任务、工单、CRM 记录、告警事件。

一句话概括：浏览器负责采集音频，识别服务负责 ASR（Automatic Speech Recognition），Django 负责业务。

为什么用 Django Channels？

Django 默认更擅长“请求-响应”的 HTTP 模式，但实时音频是持续流式数据。Django Channels 提供 ASGI + WebSocket 支持，能让你保持连接、持续接收音频并推送转写。

如果你要做的是语音助手或实时客服辅助，WebSocket 是绕不开的。

关键实现步骤（用最小成本跑通）

下面这套路径的重点不是“代码抄一遍”，而是理解每一步在系统里扮演的角色。你可以把它当成你公司语音能力的第一块积木。

1）准备依赖与环境变量

用虚拟环境隔离依赖，并把 API Key 放进 .env：

• Django（Web 框架）
• channels（WebSocket 支持）
• python-dotenv（加载环境变量）
• deepgram-sdk（语音识别 SDK）

把密钥写进 .env，并加入 .gitignore。这不是洁癖，这是生存策略。

2）一个最简单的页面：显示连接状态和转写文本

页面只需要两个区域：

• #status：WebSocket 是否连上
• #transcript：不断追加识别结果

前端不必先做复杂 UI。先跑通数据链路，再谈产品体验。

3）浏览器采集麦克风音频：MediaRecorder

浏览器端用 navigator.mediaDevices.getUserMedia({ audio: true }) 获取音频流，再用 MediaRecorder 切片。

实践建议：

• 切片间隔 250ms 是常见折中：延迟不高、服务器压力可控。
• 真要做客服辅助（需要更低延迟），可以尝试更小切片，但要更关注带宽与并发。

4）Django 端 WebSocket Consumer：转发音频、回传文本

Consumer 的职责很纯粹：

• connect()：建立与识别服务的连接，然后接受浏览器连接
• receive(bytes_data)：收到音频就转发给识别服务
• get_transcript(data)：收到转写事件就 send() 给浏览器

这里有一个很实用的产品选择：

• interim_results=False：只要最终结果，页面更干净，适合先做 MVP。
• 你做“实时提示词/坐席辅助”时可以打开 interim（中间结果），体验更“跟嘴”。

5）把转写从“显示”升级为“工作流事件”

多数团队做到“页面显示文字”就停了，但这只完成了 30%。真正值钱的是后面 70%：把转写接到自动化工作流。

你可以在 Django 的 get_transcript() 里增加一个极简的事件处理器：

• 写入数据库：会话 ID、时间戳、说话人、文本
• 同步到工单：命中关键词（退款、投诉、发票）就创建工单
• 触发通知：出现“电梯困人/燃气泄漏/打架”之类的高危词，推送企业微信/短信

一个可落地的字段建议（适合小企业，也适合智慧城市基层系统）：

• session_id（一次会话）
• source（客服/会议/巡检）
• text（原文）
• intent（意图标签：咨询/投诉/报修）
• entities（结构化实体：地址、设备编号、时间）
• priority（紧急程度）

这些字段一旦形成，你就能开始做统计与治理：热点问题、平均处理时长、重复投诉、区域分布等。

把它用在小企业：三个“立刻能用”的场景

实时语音转文字并不只属于大厂坐席。小团队更需要它，因为你们没有多余人力来“搬运信息”。

场景 1：客服实时辅助（缩短工单创建时间）

做法：客服通话同时开一个转写页面（或嵌入坐席系统），系统自动补全工单字段。

我见过不少团队的现状是：一通电话 6 分钟，录入工单再花 3 分钟。实时转写后，录入时间可以接近 0，把精力留给解决问题。

进一步：对常见问题自动弹出 SOP（退换货政策、安装指引、话术），让新客服也能稳住体验。

场景 2：会议纪要 + 行动项（减少“会后失忆”）

做法：每次线上会议开转写；会后用规则或大模型把文本转成：

• 决策（Decision）
• 行动项（Action Items）
• 风险（Risks）

你不一定要马上上复杂的 LLM 方案。先用关键词规则提取“我来”“截止”“需要”“负责”等短语，就能把行动项抓个七八成。

场景 3：巡检与现场记录（适配智慧城市基层治理）

在智慧城市建设里，基层一线最常见的瓶颈是：信息采集慢、回填成本高、格式不统一。

让巡检人员对着手机说：

• “XX 路口摄像头离线，编号 A-103，已重启无效”
• “小区 3 号楼消防通道被占用，已通知物业”

系统实时转写并结构化入库，就能让城市治理从“人找事”变成“事找人”。

工程与合规：别等上线后才补课

做实时语音系统，工程细节决定你能不能稳定跑半年。

延迟与成本怎么控？

• 音频切片间隔：250ms 通常够用；更小会更实时，但服务器与带宽压力会明显上升。
• 并发连接数：WebSocket 是长连接，记得做连接上限与心跳。
• 存储策略：很多场景只需要存文本，不必存音频；要存音频也要设置保留周期。

隐私与数据安全怎么做？

如果涉及客户通话、投诉、地址等信息，建议至少做到：

• 最小化采集：只收业务需要的字段
• 脱敏：手机号、身份证、门牌号按规则遮盖
• 权限与审计：谁看过、谁导出过，都要可追溯
• 明确告知：客服场景提示“通话可能被记录用于服务改进”

在智慧城市语境下，公共服务数据更敏感，合规不是附加题，是必答题。

常见问题（你大概率也会踩）

Q1：为什么我收到了音频，但没有转写？

最常见原因有三个：

• 浏览器麦克风权限没给
• WebSocket 地址/路由不对（如 /listen 未匹配）
• 音频格式与服务端期望不一致（不同浏览器输出容器可能不同）

建议做法：把“连接状态、发送帧大小、服务端异常”都打日志。实时系统不怕问题多，怕的是你看不到问题。

Q2：要不要做“说话人分离（diarization）”？

客服场景、多人会议场景很需要。MVP 阶段可以先不做，先把“可用的文本流”跑通。等要做质检、归因、责任划分时，再引入说话人分离。

Q3：能不能直接把转写推给大模型做总结？

能，但我建议顺序是：先落库、再异步处理。

原因很现实：大模型调用有成本也有延迟，你不想让 WebSocket 处理链路被阻塞。用队列（如 Celery/RQ）异步做摘要、意图识别、实体抽取，会更稳。

下一步：把实时转写变成“语音助手入口”

实时语音转文字搭好之后，你已经拥有了语音助手最关键的输入层。接下来真正值得做的是：把文本变成动作。

如果你要我给一个优先级，我会这样排：

1. 结构化：从纯文本到字段（意图、实体、优先级）
2. 自动分发：根据字段路由到负责人/部门
3. 闭环反馈：处理结果回写到会话，形成可追踪链路

智慧城市建设讲“数据贯通、协同治理”，小企业讲“少人也要跑得快”。两者在这件事上其实是同一条路：把一线语音变成可执行的数字流程。

你现在的团队，最想先从哪个语音场景开始：客服、会议，还是巡检？