有些数据散落在 Telegram 附件里，有些埋在贴吧长帖和楼中楼里，还有一些只在历史评论包、弹幕 CSV 或公开名录里出现。下载下来不难，但想回答“这个关键词在哪里出现过”“几个来源能不能一起查”，就没有那么直接了。
我做了 VTuber Data：把已经取得、核验并处理的内容保存在自己的服务器上，再提供一个公共、只读的查询入口。它不是 AICU 官方站，也不是 B 站全站数据库的镜像。
项目地址：vtuber-data.bismih520.com。无需登录，可以混合检索、浏览数据覆盖与处理状态，并导出小规模查询结果。本文依据 2026 年 10 月 10 日北京时间 11:47:56 的接口快照及当日功能核验撰写；持续采集中的数量会变化。
一、我希望它解决什么问题
这个项目的重点不是“收藏一堆链接”，而是把内容真正变成可检索的档案。
例如，想查看“嘉然”相关的历史讨论，以前可能需要分别打开评论包、动态包、贴吧和公开名录。现在可以先做一次混合查询，再缩小到某个数据集，查看正文、记录时间和能够确认的来源。
它适合几类用途：
- 找回已归档的历史评论、视频弹幕或动态片段。
- 对照不同社区中某个关键词的讨论，取得后续人工分析的样本。
- 浏览 VTuber 公开艺名和官方账号名录。
- 查看数据到底处理到哪里，而不是只看一个下载完成的进度条。
- 导出当前查询的部分结果，交给自己的笔记、脚本或研究流程。
它不负责证明传闻、识别真实身份，也不会因为存了历史数据，就保证能够找回上游已删除或不可见的内容。档案能够支持查证，但不能代替查证。
二、当前已经有多少数据
快照中，接口报告 88,152,595 条已入库记录，注册了 24 个数据集，其中 21 个已有可查询记录。
这几个数字的口径需要先说清楚：
- 一条记录可能是弹幕、评论、帖子正文、公开名录条目，或者一个聚合统计结果；不是一个独立的人。
- 去重范围不能理解成整个网站的全局去重。不同数据集、不同历史快照之间可能重叠，尤其是 V 吧历史库和持续采集库。
- “21 / 24”表示有记录的数据集数量，不表示 21 个来源已经全部采完。
- 总量主要来自历史包，不能把八千多万条说成刚刚实时爬到的新内容。
历史包与公开资料
| 数据集 | 快照入库记录 | 可以怎样查询 |
|---|---|---|
| VTuber 视频弹幕 · 2024 | 46,690,054 | 弹幕正文、AV 数字编号、记录日期 |
| A-SOUL 标签动态 · 2023 | 338,467 | 动态正文、动态数字 ID、记录日期 |
| A-SOUL 官方评论 · 2022 | 11,907,313 | 评论正文、记录日期 |
| A-SOUL 相关评论 · 2023 | 21,274,348 | 评论正文、记录日期 |
| 视频互动 · 匿名聚合统计 | 5,882,634 | AV 数字编号、原始 action 编码 |
| 公开账号资料 · 2024 | 926,259 | 公开昵称关键词 |
| 公开粉丝排行 · 2026 | 1,000,000 | 公开账号编号的文本检索、历史排行 |
| 公会样本统计 · 明细汇总 | 923 | 公会名称或编号、样本规模 |
| 公会规模统计 · 2025 | 923 | 公会名称或编号、历史规模快照 |
| DD Center VDB 公开名录 | 9,580 | 公开艺名、官方 Bilibili 主账号编号 |
表中的年份主要来自原包说明，不能把频道上传日期当成每条内容的发布时间。其中 2022 年评论包还有 4 条格式异常记录未索引，这个缺口保留在状态里，没有藏掉。
“视频互动”也容易误读：后台处理了 91,094,995 条源记录，最后按视频和原始 action 编码汇总成 5,882,634 条查询记录。两者不是同一个计数，不应相加；原始编码的业务语义没有完全确认，不能擅自叫它“点赞数”或“收藏数”。
贴吧：历史恢复与持续采集分开
| 数据集 | 快照入库记录 | 状态与范围 |
|---|---|---|
| V 吧 · 历史归档 | 26,701 | 恢复的本地快照，包含主题、回复和楼中楼 |
| V 吧 · 持续采集 | 20,171 | 公开内容断点续采 |
| 4soul 吧 | 11,895 | 公开内容断点续采 |
| 千袅official 吧 | 12,471 | 公开内容断点续采 |
| eoe 吧 | 8,165 | 公开内容断点续采 |
| 四禧丸子 吧 | 6,946 | 公开内容断点续采 |
| 永雏塔菲 吧 | 8,994 | 公开内容断点续采 |
| 星瞳official 吧 | 10,329 | 公开内容断点续采 |
| asoul 吧 | 12,009 | 公开内容断点续采 |
合计 117,681 条贴吧记录。这个合计包含历史库和持续采集库，可能有跨库重叠；它不是整个 V 吧或这些社区的完整历史。
B 站新增投稿与评论：接通了，但还不完整
持续采集队列围绕 11 个指定官方账号，分成 A-SOUL、EOE、四禧丸子、塔菲、星瞳五组。
| 分组 | 快照入库记录 | 本次核验结论 |
|---|---|---|
| A-SOUL | 1,942 | 已能查询投稿 / 评论队列中实际取得的内容 |
| EOE | 0 | 已注册，尚无入库记录 |
| 四禧丸子 | 0 | 已注册，尚无入库记录 |
| 塔菲 | 0 | 已注册，尚无入库记录 |
| 星瞳 | 2,471 | 已能查询投稿 / 评论队列中实际取得的内容 |
两组共 4,413 条记录，不是 4,413 个视频。快照时五组都显示接口冷却状态；已有记录仍可正常查询。遇到访问限制时，采集器暂停并保留断点，不把空响应算成“采完了”。
截至本文核验，微博、抖音尚未接通；新的直播弹幕监听也没有启用。旧视频弹幕包不等于直播弹幕库。开源项目在研究列表里出现，不代表它已经贡献了本站数据。
三、打开网站，应该先看哪里
页面保留三个主要入口：混合查询、数据覆盖与进度、外部数据站。前两个是本地功能，第三个是参考导航。
这是 2026 年 10 月 10 日的实际界面截图，不是设计稿。截图拍摄晚于上面的接口快照，因此总量略有增长；两处数字都应按各自时间理解。
混合查询
默认可以在所有已入库类型之间查一个关键词，也可以勾选多个数据集。结果卡片标明数据类别、正文、时间和内容编号，提供展开与复制按钮；能确认原始地址的记录才提供原文或公开主页链接。
数据覆盖与进度
这里回答“有哪些数据、支持哪些字段、处理到哪里”。它还展示下载校验、格式异常、任务数量和重试状态。任务完成数不是完整覆盖率，因为采集器只知道已经发现的任务，不知道上游所有历史内容的总量。
外部数据站
AICU、LAPLACE Live、VTBs.moe、Danmakus 等入口用于继续浏览与参考。导航中的站点数据库并没有因此同步到本地，不能计入本站总量。
四、混合查询怎样用，结果怎样读
最简单的用法是输入至少两个字或字符，例如“嘉然”或“直播”，直接查询。关键词留空则浏览所选范围的已归档内容。
可以从这些入口开始：
- 全库混合查“嘉然”：看看评论、动态、弹幕、贴吧与名录怎样一起返回。
- 只在 4soul 与 EOE 吧查“直播”：把范围缩到两个相关社区。
- 在公开名录中查“嘉然”：适合找公开艺名及官方账号。
- 浏览 A-SOUL 新增队列已入库内容：区分持续采集与历史评论包。
- 查看全部数据覆盖与进度：先检查有没有数据，再判断查询结果。
有几个行为不是常规搜索引擎的默认体验，需要特别说明。
第一，混合结果按来源交错展示。 大评论库不会把小名录或小贴吧完全挤下去，但这也意味着它不是全局时间排序，更不是相关度排行榜。单类结果主要按归档记录倒序，不一定是内容发布时间倒序。
第二，前端显示的是“已加载多少条”，不是匹配总数。 每页最多 25 条，通过游标继续加载。系统没有为了给一个漂亮总数，先对几千万条记录做完整计数。
第三，日期和编号要符合数据类型。 没有日期字段的资料快照不能参与日期筛选；不同来源的内容编号也不能在混合查询里当成同一种编号。视频弹幕使用 AV 数字编号，不支持直接输入 BV；2022 / 2023 评论包的原编号语义未完全确认，所以没有开放按视频编号精确反查。
第四，关键词查询不等于严格的全文短语匹配。 中文索引把文本拆成相邻双字词元，查询按词元组合匹配；词元可能分散出现在正文里，长查询也有词元数量上限。要核对具体说法，仍应阅读结果正文，不能仅凭“搜到了”就认为完整短语一致。
混合查询还会报告每个来源的返回情况：有后续页、没有更多匹配、尚未入库，或者超时异常。如果某个来源失败，会明确显示部分结果，而不是把失败伪装成零条。
五、导出与接口：给后续分析留一个出口
网页提供 JSONL 导出，单次最多 1,000 条。每一行是一个 JSON 记录，通常包含数据集编号、类型、正文、内容编号、时间和来源；VDB 名录还会保留署名、许可证与投影说明。
这是小规模结果导出，不是整库下载，也没有提供原始压缩包、SQLite 数据库或作者身份明细。混合查询存在超时来源时，导出会拒绝生成可能遗漏来源的文件，建议缩小范围后再试。
公开接口与页面使用的是同一套只读能力：
| 路径 | 用途 |
|---|---|
/api/stats |
数据集记录数、下载 / 处理状态 |
/api/live |
共享采样快照、观察窗口内的入库增长 |
/api/catalog |
频道可见消息及附件的处理清单 |
/api/search |
单类或混合检索、游标分页 |
/api/export |
最多 1,000 条的 JSONL 结果 |
例如，单次查询公开名录：
curl --get 'https://vtuber-data.bismih520.com/api/search' \
--data-urlencode 'dataset=201' \
--data-urlencode 'q=嘉然'
接口有请求频率和并发限制，批量分析应先导出合适的样本，不要每秒反复搜索，也不要把结果导出接口当作无约束的数据镜像服务。
六、数据从哪里来，为什么不是附件全部直接入库
Telegram 历史附件
历史数据主要来自公开频道 @aicu_cc。本次目录核验覆盖 29 条当前可见消息、21 个附件，不是只读取第一页。
但“核对所有附件”与“把所有附件公开索引”是两回事：
- 内容包经过格式核验后，解析为可检索正文。
- 公开资料只保留本项目允许的字段。
- 视频互动和公会样本转换成聚合统计，避免公开个人关系明细。
- 纯编号清单留在目录里，不冒充正文数据。
- 图片附件按实际状态登记，不把图片文件数量算成可搜索文本。
- 工具脚本不执行、不作为业务数据入库。例如“bilibili直播原画2.1.js”不应出现在数据搜索结果中。
- 联系方式、历史身份关联、个人付费或成员关系等包不进入公开查询索引。
频道的公开状态，也不等于授予其中每个包不受限制的商业再利用权。使用和传播时仍需核对来源、许可和个人信息边界。
下载阶段支持断点恢复，并做文件大小、SHA-256 和 ZIP CRC 校验；解析阶段按文件成员和行位置保存检查点。下载成功、校验通过、解析完成、索引完整，是四个不同的结论。
贴吧持续采集
V、4soul、千袅official、eoe、四禧丸子、永雏塔菲、星瞳official、asoul 八个吧使用轮转队列，逐步推进列表页、主题回复和楼中楼。
失败页不会被标成完成。任务保留页位置，按失败次数退避重试；上游已删除、限制访问或不再返回的内容，不能保证补齐。
Bilibili 新增采集
这里参考了 1dyer/bilibili-comment-crawler 的评论接口与分页方式；它确实能采集评论及二级回复，而不是单纯的评论显示工具。
本站的采集器独立实现动态 WBI 签名、最新评论游标与嵌套回复队列。投稿发现和评论采集分别管理冷却，避免投稿列表受限时，已经发现的视频也完全停止处理。接口实际返回了什么，就只登记什么；不恢复已删除评论，也没有照搬原项目的个人资料采集字段。
DD Center VDB
公开名录来自 DD Center / vdb contributors 的 JSON 数据。本站只投影公开艺名及官方 Bilibili 账号，不建立跨平台私人身份关联；上游暂时不再出现的条目保留为历史记录，不自动断言其仍然活跃。
该数据的 上游许可证包含 CC BY-NC-SA 4.0，即署名、非商业、相同方式共享。查询与导出保留来源和许可信息，不能把这个名录直接包装成不受限制的商业数据商品。
七、更新是怎么运行的
采集在服务器上通过 systemd 任务运行，不依赖我打开 Codex，也不依赖访客打开网页。
| 任务 | 当前调度 / 预算 | 实际意义 |
|---|---|---|
| 贴吧队列 | 距上次任务激活约 10 分钟再次调度；单轮最多 120 次请求，间隔至少 2 秒，约 8 分钟工作预算 | 发现新内容，同时逐页补历史 |
| B 站队列 | 距上次任务激活约 10 分钟再次调度；最多 90 次请求，间隔至少 3 秒，460 秒工作预算 | 发现投稿、续采评论和楼中楼；受限时冷却 |
| VDB 名录 | 每日检查，支持条件请求 | 减少未变化数据的重复传输和重复入库 |
| 频道目录核验 | 每日检查全部当前可见消息 | 发现新附件并登记处理范围 |
| 增长统计 | 共享采样器每 2 秒读取一次计数；每 15 秒保存一次历史样本 | 支撑前端增长数字和趋势图 |
“约 10 分钟”不是承诺每个吧、每个视频都十分钟抓完一次。定时器采用 OnUnitActiveSec，按上次任务激活时间计时，不是结束后再等十分钟；同一服务仍在运行时不会并行重启。实际采集还受轮转、随机延迟与冷却影响；B 站已完成的部分评论任务可在六小时后重新进入刷新队列。相关调度语义见 systemd.timer 官方文档。
历史压缩包导入是可恢复的一次性任务。核验时这个导入服务为 inactive，而查询、隧道、公开入口与增长采样服务均在运行；一次性导入结束后 inactive，不等于查询服务停了。
八、实时增长怎样做到，又不拖累查询
页面上的“数据正在生长”，显示的是实际入库净增长。它包括旧包回填、新发现来源和定时采集的结果，不是平台刚发布的帖子数。
服务器只有一个共享采样器，读取各数据集已有计数，而不是每两秒扫描几千万行。前端读取轻量快照：增长面板约两秒刷新，普通数据集状态约十秒刷新，切换到浏览器后台后暂停轮询；请求失败会退避重连。
因此，多打开一个网页不会多开一套 B 站或贴吧爬虫。查询与采集相互解耦，采集暂时受限时，历史数据仍然可以查。
本次快照里，最近 62 秒新增 345 条，最近 3,614 秒新增 3,207 条；24 小时窗口尚未积累出有效基线，所以显示“积累样本中”。这些是当时的观测值，不应外推成每天固定新增多少条。
趋势样本保留七天，页面主要展示最近约三十分钟的曲线。如果采样中断、快照过旧或窗口不足，页面提示延迟 / 等待基线，不用假零补齐。
九、后端是怎么组织的
这不是把整个数据站压进浏览器，而是一个较轻的归档检索系统：FastAPI / Uvicorn + SQLite WAL / FTS5 + 原生 HTML、CSS、JavaScript + Nginx + Cloudflare Tunnel。
历史附件 ── 下载校验 / 流式解析 ──┐
贴吧页面 ── 断点与重试队列 ─────┤
B站接口 ── 投稿 / 评论独立队列 ─┼─→ 分来源 SQLite + FTS5
公开名录 ── 每日增量核验 ───────┘ │
只读查询 API + 共享统计快照
│
本机 Nginx → Tunnel → 公共网页
历史内容、额外资料、贴吧、名录和 B 站新增分别放在数据库中，避免所有写任务争抢同一个大库。混合查询用受限线程池向多个库查询，再按来源交错合并；分页保存每个来源的游标，而不是使用越翻越重的大 OFFSET。
中文搜索使用双字词元建立 FTS5 索引。数据库有内容编号和记录时间索引；单类 SQL 设置约三秒执行期限，混合查询对单来源采用更短期限，并限制同时进行的混合任务。它不是毫无限制地让访客提交长查询。
这也解释了磁盘占用：原始已选下载包约 3.98 GiB，但解压、解析、正文表与全文索引需要更多空间。当日五个主要 SQLite 文件的 du 占用合计约 33.44 GiB，还不包含原始包、WAL、增长库和备份。压缩包大小不能当成整个项目的磁盘占用。
十、本次实际验了什么
除了读取代码，我还对线上公开接口做了少量只读核验：
| 查询 | HTTP | 本页返回 | 服务端报告耗时 |
|---|---|---|---|
| 全库混合查“嘉然” | 200 | 25 条，来自 14 个数据集 | 31.2 ms |
| 4soul + EOE 吧混合查“直播” | 200 | 25 条 | 15.0 ms |
| VDB 名录查“嘉然” | 200 | 1 条 | 0.8 ms |
| 浏览 A-SOUL 新增队列 | 200 | 25 条 | 1.2 ms |
| 浏览星瞳新增队列 | 200 | 25 条 | 1.2 ms |
两次混合查询都没有报告来源超时；分页入口返回了后续游标。名录查询导出得到一条有效 JSONL 记录，包含来源、许可证和投影说明。桌面与 390 像素手机宽度的页面也检查过，没有页面级横向溢出。
上表是少量功能核验，不是压力测试，也不是普遍延迟承诺。服务端耗时不包含完整的网络往返、浏览器渲染；这次同一环境的 HTTP 请求约 341–429 ms，不代表任意地区的访问速度。稀疏关键词、很宽的日期范围或并发查询仍可能触发超时和限流。
十一、公共查询与隐私边界
当前网站公开读取，不要求 GitHub 登录；HTTPS 仍保留。公开并不意味着服务器里的所有东西都公开。
网页访问经过专门的只读入口，只开放首页、已知静态资源和少量 GET / HEAD 查询路径。查询进程使用独立账号、只读 SQLite 连接，不能读取 Telegram 登录会话和原始附件目录；没有公开写入后台。
入口设置了搜索、统计、导出各自的频率限制和连接上限；导出更严格。它们用于保护资源，不是防止所有分布式抓取的保证。
数据层不提供邮箱、QQ、历史名称关联或普通用户身份反查。正文在入库与输出时对常见联系方式、手机号、证件号模式做掩码；自动处理不能保证识别所有个人信息，发现问题仍需要人工核验与纠正。
前端不加载第三方图片和统计脚本，后端查询服务关闭常规访问日志；明暗主题偏好保存在浏览器本地。网站仍经过 Cloudflare，不能把这些设计描述成“互联网上绝对没有任何请求元数据”。
也请不要把历史粉丝数当成当前人数，把抽样讨论当成整个群体的态度，或把一个昵称当成已经验证的身份。
十二、下一步值得做的，不只是把数字变大
这部分是后续方向，不是已经完成的功能：
- 让 B 站剩余三组取得可验证的数据，改善投稿发现受限和评论刷新覆盖。
- 把“发现的任务”“已经完成的页链”“源站已删除 / 不可达的缺口”分开呈现，避免假完整率。
- 加强跨快照重复识别，保留历史版本和来源，不让相同内容被误解成新增事件。
- 增加更清楚的全文匹配说明、时间线和小样本分析工具，再考虑趋势统计。
- 按明确范围验证直播弹幕、微博、抖音等新来源；代码仓库、可用接口和实际数据分别验收。
- 保持一致性数据库备份与恢复演练。源码能放 GitHub，但源码备份不等于八千多万条记录已经备份；运行中的 SQLite 也不能随便复制一个主文件就当作完整备份。
我希望这个站的价值是：以后再找一段历史内容，不必先翻一堆压缩包；看到一个统计，也能知道它从哪里来、是否完整、能不能复核。
数据多是基础，但能查、能解释、能知道缺口，才是一份有用的档案。
项目入口：VTuber Data · 公开查询；实时数量和覆盖状态以站内 数据覆盖与进度 为准。本文没有转载整库正文、原始包、Cookie 或任何登录凭据。