夜雨聆风学习资料网

ARTICLE · 1053975

全平台私信自动回复,源码拆开只有三层东西

全平台私信自动回复,源码拆开只有三层东西
TUTORIAL · 源码拆解2026.09

回私信得来回切五个 App

六个平台的消息

收进一个后台

规则 + AI 双层回复 · 开源 Flask 项目

bbbb.bid · 开源源码拆解

六平台聚合开源项目

📦 5 个核心看点

👉 滑动

看点 01

先问来路

从哪个仓库来

看点 02

为什么叫神器

包装与流传

看点 03

真正解决什么

收件箱合一

看点 04

值得抄什么

四个工程习惯

看点 05

边界与红线

谁适合用

一句话说破这套系统的本质

所谓私信神器,是把六个收件箱合并成一个

技术不算新,麻烦的是六个平台各有各的脾气

做多平台运营的人大概都经历过同一个循环:B 站有人问接不接商务,抖音有人问教程在哪买,小红书有人求资料链接,微博有人问什么时候更新,闲鱼有人问还在不在。

五个 App、五套通知、五种界面,你要做的事其实只有一件——把一句差不多的话,复制五遍

这类需求存在快十年了,方案也换过好几代:从一个人一个平台各写一份脚本,到打着「自动化」旗号、最后把人往付费群里导的机器人,再到今天这种做法——把多个平台的收件箱,收进同一套系统

今天拆的这套,就是被不少下载站冠名「全平台私信神器」的 BiliGo V3 Ultra。但它配不配这两个字,得把源码摊开才能说清。先看它从哪来。

01

PART

它从哪来:一个朴素的 Flask 项目

ORIGIN · GITHUB

把「神器」这层包装撕掉,底下是个挺老实的开源项目。

它在 GitHub 上的名字叫 BiliGo,仓库描述写得很克制:an automated reply system for Bilibili private messages——一开始只做 B 站私信一件事。

后来才慢慢扩到今天这六类消息入口:

B 站

私信 + 评论区两块,其中私信支持图片回复

抖音

私信消息

小红书

私信消息

微博

私信消息

闲鱼

买卖家消息

技术栈朴素到有点意外:主程序是单个 Flask 应用,依赖清单里只明确声明了 Flask 和 requests;真正干重活的是浏览器自动化,靠的是 playwright,而且被写成延迟导入的可选依赖——不装它,Web 界面照样能起,只是浏览器相关的几个平台用不了。

目录结构一眼能看出分层:平台模块通过 register_*_routes(app) 挂载到主应用,浏览器自动化收在 *_playwright.py,AI 相关逻辑在 ai_*.py

数据层也简单,三个 SQLite 库各管一摊:会话数据、人工待回队列、仪表盘指标

所以第一个结论很明确:这不是黑盒。它是个能被读完、能被自己改的小项目——这一点很重要,因为「能不能读完」,决定了你能不能判断它安不安全。

十个页面挂在同一个端口上:B 站私信、B 站评论、抖音、小红书、微博、闲鱼,再加 AI 回复设置、数据仪表盘、系统日志和使用文档。

02

PART

为什么会被叫「神器」

SPREAD · PACKAGING

一个 GitHub 上的开源项目,怎么就变成「神器」了?这段流传路径比功能本身更说明问题:同一段介绍文案在各资源站重复出现,措辞几乎一字不差,末尾都配着网盘链接;标题统一加「V3 Ultra」后缀、统一缀上「神器」两个字;完整链条是开源仓库 → 搬运站改标题加网盘 → 采集站再收录一遍,本站也是这条链上的一环。

这么一倒手,代价是什么?版本、更新记录、依赖说明全断了。你拿到的是一个某个时间点打包的压缩包,加一段复制来的文案。作者后面修了什么都跟你无关,因为没有任何东西告诉你「有新版」。

还有个更隐蔽的坑:分发包里有没有凭据。真实项目里永远不该出现 Cookie 和登录态。如果你下载到的压缩包里带着配置文件、浏览器用户目录或者数据库文件——那不叫「开箱即用」,那叫别人用过的登录身份。

这一点上,这个项目本身做得挺正:默认配置不含任何凭据,容器首次启动时从无凭据模板复制一份进数据卷,仓库里明确忽略配置文件、浏览器资料目录、数据库和日志。判断一个源码包干不干净,先看它有没有把不该进仓库的东西塞进仓库——这条比任何功能清单都有用。

03

PART

剥开营销,它真正解决的是什么

VALUE · REAL PROBLEM

功能列表越长,越容易看漏真正的设计。这套系统里最值钱的一处,恰恰不在功能列表上。

先看两套回复模式,每个平台可以独立选

关键词规则模式

默认回复 + 关键词触发两层,可区分已关注和未关注用户,限制单用户回复次数、自定义发送间隔来降低风控概率,B 站私信支持图片回复。

AI 客服模式

兼容 OpenAI、Anthropic 及自定义兼容接口,知识库按平台分配,会话上下文自动压缩,内置违禁词拦截;AI 处理不了的会话转人工待回复队列,而不是硬答。

然后是这个设计:它只处理程序启动之后收到的新消息,不会批量回历史会话

这一句话看着不起眼,其实同时解决了两件事。一是隐私——不去翻别人过去说过什么;二是风控——少一层「翻旧账」的自动化,就少一次被判定为滥发的机会。做自动化的人容易沉迷于「能做的事越多越好」,而这个项目主动给自己划了边界。

隔离做得也干净:各平台配置、登录状态、统计数据、日志互相独立,某个平台掉线或者被限流,不会把其他平台一起拖下水。运维层面也没糊弄——仪表盘看全平台回复量和成功率,登录失效与程序异常走邮件告警,规则可以跨平台导入导出。

04

PART

四个值得直接抄走的工程习惯

ENGINEERING · REUSABLE

如果只把这篇当功能介绍看,那真是白拆了。它有几个工程做法,跟业务无关,换个项目照样能用。

① 路径解析三态

数据目录的查找顺序是:先看环境变量指定的目录,再看打包后冻结目录,最后落到源码根目录。同一份代码,源码直接跑、打成单文件 EXE 跑、丢进容器跑,都能正确找到自己的数据在哪里。想同时支持这三种分发方式,这是代价最小的做法。

② 凭据零入库

模板进仓库、凭据进数据卷。忽略清单里点名列出配置文件、登录态文件、浏览器资料目录、数据库和日志,规则导出文件里不带 Cookie。一句话概括:配置可以分享,登录态不能。

③ 把冒烟测试当护栏

四个测试脚本分别覆盖回归、平台登录守卫、闲鱼模块、评论界面,各自拉起临时实例、用随机端口和临时数据目录,不污染本地数据。浏览器自动化最怕页面改版让选择器失效——有这层护栏,坏了能第一时间知道坏在哪一块。

④ 把踩过的坑写进提交规范

文档里明确写着:改 B 站相关代码时,要保留某类 HTTP 状态码的区分逻辑和账号隔离字段,因为这是历史风控事故的修复成果。这一行注释,防止后来者把血泪教训改回去。

这四条有个共同点:它们都不是功能,而是防止项目自己烂掉的习惯。判断一份源码值不值得读,看功能清单没用,看这些地方。

05

PART

三种部署形态与几条不能碰的线

DEPLOY · BOUNDARY

部署方式是三选一,按场景挑:

源码运行

推荐 Python 3.11,本机装好 Chrome 或 Playwright 的 Chromium,直接启动即可

Docker

两个镜像按需选:基础镜像只有 B 站接口模式和 Web 界面,体积小;完整镜像内置 Chromium,五个浏览器平台全功能。数据卷持久化,编排文件已就绪

Windows EXE

PyInstaller 打包成单文件,页面资源全部内嵌;但 EXE 不带浏览器内核,仍依赖系统 Chrome 或 Playwright Chromium

上手时容易卡住的三个点,也一并记下:

1

playwright 是可选依赖,不装也能启动,但浏览器相关的平台功能不可用——别以为是配置写错了。

2

国内装包和下载浏览器内核都很慢,走镜像源会快很多;用基础镜像跑浏览器平台一定起不来,那是镜像里没有内核,不是程序问题。

3

数据目录解析到只读位置时,需要显式指定数据目录环境变量。

项目给出的适用人群是三类:自媒体运营者、店铺客服、需要管多个账号的人。翻译一下就是:消息量大、重复度高、又必须及时回 的场景。

⚠️ 第一,平台规则永远排在功能前面。各平台对自动化私信都有或明或暗的限制,发送频率、内容重复度、互动模式都会进风控模型——频率控制和间隔设置这些开关不是装饰,是该调的。

⚠️ 第二,几条明确的红线。不群发骚扰、不刷量刷评、不绕人机验证、不冒充他人身份。工具是中性的,用它做什么决定了性质;多账号运营要符合平台账号规则与实名要求,企业场景先拿到正式授权。

⚠️ 第三,这类项目要重点看凭据放在哪。自动化工具手里握着你的登录态和对外请求权限,审计重点很清晰——登录态存在哪、有没有加密、请求都发往哪些地址、有没有未告知的数据上报。本文只做源码层面的设计拆解,不提供任何规避平台规则的方法。

老规矩:拿到任何源码,第一件事是审后门。这种既要登录你的账号、又要对外发请求的系统,先跑一遍网络请求清单再挂真实账号,比什么功能测试都重要。

///

LAST

写在最后

CONCLUSION · THOUGHTS

神器两个字,替它省掉了所有解释成本

把 BiliGo 拆完,最直观的感受是:它没有一样技术是新的。Flask、浏览器自动化、SQLite,都是老面孔。可这堆老东西凑起来,居然真解决了一个很多人每天都要面对的问题。

这也是「神器」这个词最值得警惕的地方——它把一堆琐碎流程的工程化包装成了某种不可思议的东西。等你真去看源码:六个平台适配器、一套规则匹配、一个 AI 兜底队列、三个 SQLite 库,再加四条防自己烂掉的工程习惯。没有魔法。

所以这篇拆解真正想留下的,不是「有这么个工具可以省事」,而是那几个可以搬走的做法:数据目录三态解析、凭据零入库、冒烟测试当护栏、把事故写进规范。功能会过时,平台会改版,这四个习惯不会。

资源来源:源码库 bbbb.bid本文仅为源码层面的技术拆解与合规提醒,不含任何资源获取方式。关注星标公众号,不定期分享源码干货与安全审计笔记。

既然看到这里了,如果觉得有用,随手点个赞、在看、转发三连吧。

点赞
在看
转发

THANKS FOR READING

相关学习资料