ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

我们把团队半年的会议录屏全丢给 AI 做了个检索库,今天开源了

2026/8/9 23:58:41 拓冰建站 浏览量
我们把团队半年的会议录屏全丢给 AI 做了个检索库,今天开源了

我们把团队半年的会议录屏全丢给 AI 做了个检索库,今天开源了

6 个月,340 个会议录屏,总计 412 小时。当我们试图找出半年前那个“数据库连接池方案”到底是谁说的、在哪次会议上说的——发现这件事比重新开一次会还难。于是我们写了一个开源工具,今天 v0.1.0 MVP 正式提交开源:DiTingAI/ditingyun

一、问题:90% 的企业知识,沉睡在录屏黑洞里

如果你在一家成长型团队,大概率是这样的:

  • 每周高管复盘会、架构评审、客户访谈、新人培训,录屏堆在飞书 / Zoom / 腾讯会议里
  • 会后助理整理一份纪要,关键细节依然遗漏
  • 三个月后想找一个技术决策的原始上下文,翻遍聊天记录找不到
  • 新人入职面对几十小时的技术分享录屏,无从下手
  • 离职员工带走了他脑子里的“会议记忆”

我们自己的团队就是这样的。当 CTO 问“半年前我们为什么选了 Redis 而不是 Memcached”的时候,五个人花了整整一个下午翻录屏,最后还是靠一个老员工的记忆拼出来的。

那一刻我们意识到:录屏不是资产,能被检索的录屏才是资产。


二、市面上的方案,为什么都不对

我们调研了一圈,发现现有方案都有各自的问题:

  • 飞书 / 钉钉的会议纪要:只能处理自家平台的会议,且纪要是 AI 自动总结的,丢失原话和时间戳
  • Otter.ai / 通用转写工具:单次转写,没有团队知识库概念,不能跨视频检索
  • Notion / 语雀:得人手动整理,整理的成本比开会还高
  • 企业级知识库(Glean / Fireflies):贵,且数据要上传到他们的云上,国内合规过不去

我们需要的是:

  1. 能上传任何来源的音视频(Zoom、腾讯会议、本地录屏都行)
  2. AI 自动转写 + 清洗,不需要人干预
  3. 能跨视频语义检索,输入问题直接定位到原话
  4. 数据完全在自己手里,代码可审计
  5. 5 分钟能部署起来,不是又一个需要运维团队的基础设施

找不到,就自己写一个。


三、架构:一个 Go 二进制,跑完整条管线

技术选型的三个坚持

1. 单二进制交付,零外部依赖
我们没有用 MySQL + Redis + Milvus + 消息队列这套“标准 SaaS 架构”。原因是:开源项目最大的门槛是部署门槛。如果用户要装 4 个服务才能跑起来,90% 的人在第一步就放弃了。
所以我们选了:

  • SQLite(纯 Go 的 modernc.org/sqlite,不需要 CGO)存储元数据和向量
  • Go 单二进制,编译出来直接跑
  • Docker Compose 单服务,一条命令起整个系统

2. AI 服务彻底解耦,三路独立

  • Chat 模型用商业 API
  • 语音转写用 Whisper(支持自建 whisper.cpp 服务)
  • 向量化用 bge-m3

我们在客户端设计了三路独立的 OpenAI 兼容端点配置,开源用户可以完全根据需求选择“全部走官方 API”、“全部本地离线”或“混搭”。

3. 向量化函数抽象,屏蔽协议差异
定义了统一的 EmbedFunc 函数签名,切换 embedding 后端只需改配置,不动业务代码。

数据流

上传音视频│▼
ffmpeg 抽 16kHz mono WAV│▼
Whisper 转写 → 原始文本│▼
LLM 清洗(去语气词 + 修正术语,如 Kubernetes、RAG 等)│▼
滑动窗口切片 + bge-m3 向量化 → SQLite 落库│▼
语义检索 / RAG 问答(答案自带时间戳出处)

四、踩过的坑:真诚分享

开源不是只展示光鲜的一面,我们也把踩过的坑写出来:

  • 坑 1:Whisper 冷启动超时。自建 whisper.cpp 第一次请求加载模型耗时较长,导致 Go 客户端等待。解决:增加了分步日志与预热。
  • 坑 2:HTTP keep-alive 导致的 EOF。自建 embed 服务空闲关连接后复用死连接报错。解决:http.Transport 设置 DisableKeepAlives: true
  • 坑 3:ffmpeg 原地覆盖文件报错。输入输出同路径直接拒绝。解决:检测扩展名,WAV 直传跳过转码。
  • 坑 4:同名文件触发 UNIQUE 约束。文件名生成的 task_id 冲突。解决:task_id 追加 Unix 时间戳。

五、为什么开源,为什么选择 AGPL-3.0

做企业知识库,最大的障碍不是技术,是信任。闭源产品再怎么写承诺,也是黑盒。开源是降维打击——代码就在 GitHub 上,你自己审,自己编译,自己部署

我们为核心代码选择了 AGPL-3.0 协议:

  • 完全自由的内部自建:你可以把代码拉到自己公司的私有服务器上,内部使用不受任何限制。
  • ⚠️ 防白嫖的商业保护:如果有人基于修改版通过网络对外提供 SaaS 服务,必须开源其完整修改。
  • 💼 对于需要闭源二次开发或专属托管的企业客户,我们也同步提供了谛听云官网的商业云托管与授权。

六、5 分钟部署,真的

git clone https://github.com/DiTingAI/ditingyun.git
cd ditingyun
cp .env.example .env   # 填入你的 API Key
docker compose up -d

打开 http://localhost:8080,上传第一段视频,开始构建你的知识库。


七、最后

项目刚刚发布 v0.1.0 MVP,如果你也受够了“会议录屏黑洞”,欢迎来 GitHub 看看:

👉 DiTingAI/ditingyun

  • 觉得有用,给个 ⭐ Star,这是开源作者最大的动力
  • 有想法,开个 Issue,我们都会认真看