实时字幕直播：用 Amazon IVS + Deepgram 搭建

人工智能在媒体与内容产业••By 3L3C

把直播做成可自动化的语音数据入口：用 Amazon IVS 播放直播，用 Deepgram 实时转写字幕，并接入纪要、质检与知识库流程。

Amazon IVSDeepgram实时字幕语音转写自动化工作流媒体内容技术
Share:

Featured image for 实时字幕直播：用 Amazon IVS + Deepgram 搭建

实时字幕直播：用 Amazon IVS + Deepgram 搭建

直播加字幕这件事，很多团队以为是“锦上添花”。我不这么看：实时字幕本质上是把声音变成结构化数据的入口。一旦语音能被稳定地转成文字，你就不只是“做了无障碍”，而是打开了自动化工作流：会议纪要自动生成、客户咨询自动分流、培训内容自动归档检索——这些都能从同一个能力长出来。

这篇文章放在「人工智能在媒体与内容产业」系列里看，意义更明确：媒体与内容团队每天在生产、剪辑、审核、分发上消耗大量时间，而实时语音转写让内容天然具备“可搜索、可理解、可再利用”的属性。你不一定要做下一个 Twitch，但你很可能需要一个“内部版直播 + 自动转写”的工具来支撑销售培训、门店巡检、客服质检、产品发布会等场景。

下面我会用一个务实的方式，把 RSS 教程里的技术路线（OBS + Amazon IVS + Deepgram）重写成更贴近小团队落地的方案：你能搭一个可运行的字幕直播页面，并且知道下一步怎么把它接到自动化流程里。

为什么小团队更该做“实时字幕 + 自动化”

答案先说：实时字幕不是为了“看起来专业”，而是为了“让语音变成可执行的数据”。

对小企业来说，语音最常见、也最浪费的三个场景是：

  1. 内部会议：说了 60 分钟，真正有价值的决定只有 5 条；会后没人整理，等于没开。
  2. 客户沟通：电话/视频里提到的需求、异议、报价信息，靠销售手记，丢失率很高。
  3. 培训与内容复用：一次培训直播，后续新员工想找“某个功能怎么用”，只能拖进度条。

把语音实时转成文字后，你能立刻做三类自动化：

  • 自动纪要：从实时转写中提取 Action Items、负责人、截止时间
  • 内容资产化：直播结束自动生成可检索的知识库条目（FAQ、SOP、话术）
  • 合规与质检：关键词命中（价格承诺、敏感词、竞品）自动提醒

这就是为什么本篇会强调：直播只是载体，字幕/转写才是业务的核心资产。

整体架构：三块拼起来就能跑

答案先说：用 OBS 负责“采集与推流”，Amazon IVS 负责“低延迟播放与分发”，Deepgram 负责“实时语音识别”。

最小可行架构如下：

  • 视频链路（直播）
    • 摄像头/屏幕 → OBS → Amazon IVS（接入/转码/分发）→ Web 端播放器
  • 音频链路（字幕）
    • 浏览器麦克风（或系统音频）→ WebSocket → Deepgram → JSON 转写结果 → 页面字幕

这个“模块化拼装”的好处很适合做自动化工作流：

  • IVS 负责稳定播放，你不用自己折腾 HLS/DASH 的细节
  • Deepgram 只管转写，你可以把文本送去任何下游：摘要、知识库、工单系统
  • 两条链路相互独立：视频出问题不影响转写调试，反之亦然

可复用的一句话：直播把信息传播出去，转写把信息沉淀下来。

第一步：用 Amazon IVS 把直播“送进浏览器”

答案先说：在 AWS 上创建 IVS Channel，把 Ingest Server 和 Stream Key 填进 OBS，再用 Playback URL 加载到网页播放器。

你需要准备什么

  • OBS（Open Broadcaster Software）：采集摄像头/屏幕并推流
  • AWS 账号与 Amazon IVS：创建直播 Channel

IVS 的关键是三个信息：

  • Ingest server：OBS 推流服务器地址
  • Stream key：OBS 推流密钥
  • Playback URL：网页播放器加载直播的地址

前端播放器的最简代码

在 HTML 里引入 IVS Player SDK，然后让它接管 <video>。

<head>
  <meta charset="UTF-8" />
  <title>Live Stream + Captions</title>
  <script src="https://player.live-video.net/1.6.1/amazon-ivs-player.min.js"></script>
</head>
<body>
  <video id="video-player" width="720" height="405" controls playsinline></video>

  <script>
    if (IVSPlayer.isPlayerSupported) {
      const player = IVSPlayer.create();
      player.attachHTMLVideoElement(document.getElementById('video-player'));
      player.load('PLAYBACK_URL');
      player.play();
    }
  </script>
</body>

这一步完成后，你就已经有了一个“像样的直播页面”。但对于业务自动化来说，真正值钱的是下一步：实时字幕。

成本提醒（别踩坑）

AWS IVS 有 Free Tier，但最常见的坑是：OBS 忘了关推流，后台继续计费。团队里最好设一个“直播结束检查清单”，或者做个自动化：当页面无人观看/超时就提醒主播关闭推流。

第二步：用 Deepgram 做实时字幕（把语音变文本）

答案先说：浏览器用 Media Streams API 采集麦克风音频，再用 WebSocket 把音频流发给 Deepgram，收到转写 JSON 后更新字幕区。

采集音频：getUserMedia + MediaRecorder

navigator.mediaDevices.getUserMedia({ audio: true }).then((stream) => {
  const mediaRecorder = new MediaRecorder(stream);
  // 后面会把 mediaRecorder 的数据发送到 Deepgram
});

这会触发浏览器权限弹窗。对内部系统来说，我建议你在 UI 上明确告知用途：用于字幕/纪要，避免“偷录音”的观感风险。

连接 Deepgram：WebSocket 实时转写

const socket = new WebSocket('wss://api.deepgram.com/v1/listen', ['token', 'YOUR_KEY_HERE']);

socket.onopen = () => {
  mediaRecorder.addEventListener('dataavailable', (event) => {
    if (event.data.size > 0 && socket.readyState === 1) {
      socket.send(event.data);
    }
  });
  mediaRecorder.start(1000); // 每 1 秒推一次音频片段
};

socket.onmessage = (message) => {
  const received = JSON.parse(message.data);
  const transcript = received.channel?.alternatives?.[0]?.transcript;

  if (transcript && received.is_final) {
    document.querySelector('#captions').textContent += transcript + ' ';
  }
};

配合一个简单的字幕容器：

<p id="captions"></p>

到这里，你已经实现了“直播 + 实时字幕”。接下来最关键的问题来了：怎么把它变成自动化工作流，而不是停留在页面效果？

从字幕到自动化工作流：3 个小企业最实用的落地方式

答案先说：把实时转写当作事件流（event stream），每条“final transcript”都是可以触发后续动作的输入。

下面是我见过最容易产生 ROI 的三条路径。

1) 自动会议纪要：字幕流 → 结构化要点

做法很直接：

  • 前端拿到 is_final 的文本片段
  • 发送到你的后端（而不是只显示在页面）
  • 后端按会议 ID 做聚合
  • 会议结束触发：生成纪要（决定/待办/风险）并发到群或邮件

你会立刻得到两个好处：

  • 可追溯：每条决策都有原文依据
  • 可检索：新同事不用再问“上次怎么定的”

在「人工智能在媒体与内容产业」的语境里，这一步相当于把“音视频内容”变成“可索引文本内容”，是内容资产化的起点。

2) 客服/销售辅助：关键词触发 SOP

实时转写特别适合做“轻量实时提醒”，比如：

  • 客户说到“太贵了”→ 弹出价格异议话术
  • 客户提到“合同/发票/交期”→ 自动标记为高意向线索
  • 命中敏感承诺词 → 提醒合规风险

实现上不复杂：在后端做一个关键词/正则匹配器，或者用更强一点的文本分类模型。关键是把文本片段带上时间戳，后续质检回放也能直接定位。

3) 培训内容复用：字幕 → 章节 → 知识库

直播培训常见痛点是“内容存在，但找不到”。有了转写，你可以：

  • 按主题自动分段（例如每 3-5 分钟聚类一次）
  • 生成章节标题（“如何处理退款”“如何设置权限”）
  • 写入知识库并支持全文搜索

这就是内容产业里最典型的链路：生产 → 结构化 → 分发/推荐。实时转写让这条链路自动化程度大幅提高。

真实项目别把 API Key 放前端：安全与架构建议

答案先说：Deepgram API Key 不要写在浏览器里；用后端签发临时凭证或做转写中转服务。

RSS 原教程为了演示简单，直接在前端 WebSocket 里放 Key。做内部工具也不推荐这么干，因为：

  • Key 泄露后别人能消耗你的额度
  • 你无法对不同用户做权限与审计

更稳妥的做法（按成熟度从低到高）：

  1. 后端代理 WebSocket：浏览器连你的服务器，你的服务器再连 Deepgram
  2. 短期 Token：后端签发短有效期凭证（具体取决于服务端能力）
  3. 按用户/房间隔离：每场直播一个会话 ID，严格记录谁在转写、转写内容写到哪

另外，别忽略合规：如果是客户通话或含个人信息的会议，必须在 UI 与制度层面明确告知、保存周期、访问权限。

你可以从“字幕直播 Demo”走到哪里

答案先说：当你把实时字幕接入自动化工作流，它就变成了内容中台的入口——语音助手、推荐、审核都能基于这份文本资产。

如果你打算继续迭代，我建议按这个顺序走：

  1. 先跑通：直播 + 字幕 + 存储（把 final transcript 存到后端）
  2. 再自动化：纪要/工单/知识库同步（把文本变成业务动作）
  3. 最后智能化：摘要、标签、用户画像、内容推荐（把内容分发做起来）

这也正好契合「人工智能在媒体与内容产业」系列的主线：AI 不只是生成内容，更重要的是让内容可理解、可管理、可分发。

如果你正在评估如何把 AI 语音助手接到现有系统里（会议、客服、培训、内容运营），不妨先从这个最小架构开始：IVS 让直播稳定，Deepgram 让语音变数据，剩下的就是你最熟悉的自动化工作流设计。

你下一步更想优先解决哪一个：会议纪要、客服质检，还是培训知识库？