为什么做Timao

抖音直播的痛点很明确：主播在直播过程中需要同时关注弹幕、话术、节奏，但人脑很难同时处理这么多信息。市面上的直播助手大多是简单的弹幕展示工具，缺少智能化的能力。

Timao 的目标是：让AI实时辅助直播决策。

技术架构

整体采用前后端分离 + 本地桌面的方案：

┌─────────────────────────────┐
│       Electron 38 Shell      │
│  ┌───────────┐ ┌──────────┐ │
│  │  React 18 │ │ FastAPI  │ │
│  │  Renderer │ │ Backend  │ │
│  └─────┬─────┘ └────┬─────┘ │
│        │             │       │
│        └──────┬──────┘       │
│         WebSocket IPC        │
└─────────────────────────────┘
              │
    ┌─────────┼─────────┐
    │         │         │
┌───▼──┐ ┌───▼──┐ ┌───▼──┐
│弹幕   │ │语音   │ │AI    │
│抓取   │ │识别   │ │分析  │
└──────┘ └──────┘ └──────┘

1. 弹幕抓取

通过 WebSocket 直接对接抖音直播间弹幕流，毫秒级响应。不是传统的HTTP轮询方案，而是建立持久连接，弹幕来了就处理。

关键技术点：

  • 抖音直播WebSocket协议逆向
  • 心跳保活与断线重连
  • 弹幕数据结构化解析（礼物、评论、点赞分别处理）

2. 语音转写 — SenseVoice

为什么选 SenseVoice 而不是 Whisper？

  • 实时性：SenseVoice 的流式识别延迟更低，适合直播场景
  • 中文优化：针对中文直播话术的识别准确率明显更高
  • 资源占用：本地运行对CPU/GPU要求更友好

实现方式：

音频流 → VAD端点检测 → SenseVoice流式识别 → 文本输出 → AI分析

3. AI实时分析 — LangChain + Qwen

这是核心。用 LangChain 编排分析链路：

# 简化的分析链路
chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt
    | qwen_model
    | output_parser
)

AI做的三件事：

  1. 话术建议：分析当前弹幕趋势，推荐主播该说什么
  2. 节奏把控：识别直播冷场/高潮，给出节奏建议
  3. 实时互动：自动回复常见弹幕问题

4. 直播复盘

直播结束后自动生成复盘报告：

  • 话术时间线（什么时候说了什么）
  • 弹幕高峰时段分析
  • 观众互动热度图
  • 优化建议

为什么选 Electron + FastAPI

方案优势劣势
纯Web部署简单无法调用本地模型
纯PythonAI生态好GUI体验差
Electron + FastAPIAI+GUI都强打包体积大

选择 Electron + FastAPI 的原因：

  • React 18 做直播仪表盘，实时数据展示体验好
  • FastAPI 做后端，Python AI生态无缝接入
  • 两者通过本地 HTTP/WebSocket 通信，各司其职

隐私设计

所有数据本地处理，不上传任何云端。这是和SaaS直播工具的核心区别：

  • 语音识别：本地 SenseVoice
  • AI分析：本地 Qwen 模型
  • 弹幕数据：本地存储

MCN机构和主播不用担心直播数据泄露。

性能优化经验

  1. 弹幕去重：直播高峰期每秒几十条弹幕，需要智能去重避免重复处理
  2. 音频缓冲区：VAD检测的缓冲区大小直接影响识别延迟和准确率的平衡
  3. AI推理节流：不是每条弹幕都触发AI分析，用滑动窗口+关键词触发

技术栈总结

前端：Electron 38 + React 18 + TypeScript
后端：Python 3.13 + FastAPI
AI：  LangChain + Qwen + SenseVoice
通信：WebSocket（弹幕）+ HTTP（IPC）

开源

项目开源在 GitHub：timao-douyin-live-manager

欢迎交流直播系统开发的经验和问题。