开源哔哩哔哩日常任务：在浏览器里装好的自托管小助手

小新平时追番、刷动态，也免不了惦记那些「每天点一下」的琐碎事：签到、领经验、偶尔还要看看定时任务有没有跑完。纯手点既费神又容易忘，把脚本散在好几台机器上更不好维护。他更希望有一间「看得见、管得着」的控制台，打开网页就能登录、改配置、看日志，而不是对着一堆配置文件猜来猜去。

这套面向哔哩哔哩日常任务的开源方案，正是把自动化收拢进 Web 管理界面：用容器部署后，在本地或家里 NAS 上起一个服务，用浏览器完成账号维护、任务开关和调度。产品说明里反复强调仅供学习交流、不要滥用，也不要把账号信息提交到公开仓库——小新觉得，这类边界写清楚，反而让人安心下手试。

核心功能

小新最在意的是「我打开页面能干什么」。这里把日常任务相关的操作都收进 UI：首页可以查看和触发定时任务，并浏览运行日志，出了问题不用翻远程终端。配置管理里能开关具体任务、调整 Cron、投币与推送等参数，把「什么时候跑、跑什么」说清楚。账号管理则用于添加或维护站点账号信息，例如 Cookie 等凭据，避免每次改参数都要 SSH 进机器。

默认管理员账号与密码在安装文档的 Docker 说明里单独列出，并提醒首次登录后在管理入口修改密码。对小新来说，这意味着他可以先把服务跑起来验证流程，再立刻收紧访问，而不是带着默认口令长期暴露在内网端口上。

系统技术栈

工程以 C# 为主，规模上可见大量源码文件与 Razor 视图，整体是典型的 ASP.NET 系 Web 应用形态。容器构建基于微软提供的 .NET 8 运行时与 SDK 镜像，发布入口为 Web 项目的已编译程序集，对外暴露 8080 端口，便于与 Compose 或反向代理对接。

仓库内可见与 Quartz 相关的作业与核心库命名，说明定时调度并非简单 sleep 循环，而是依托成熟的调度组件来管理触发器与任务历史。数据侧在 Compose 说明中指向 SQLite 嵌入式方案，默认 compose 仅服务本体、无需额外数据库容器，降低了单机与家庭环境的部署成本。接口调试目录中存在面向哔哩哔哩各子域的 API 集合，反映出与官方接口交互面较广，适合在可控环境下做联调与学习。

特色主要在哪里？

小新对比过「纯命令行定时脚本」和「带后台的成套工具」：前者轻，但每次改参数都像在黑暗中摸开关；后者重一点，却把登录、调度、日志串成一条故事线。这里的特色在于交付形态——Docker 一键构建与启动、浏览器里完成运营侧操作——而不是让用户自己拼 systemd、cron 与日志轮转。

安装文档同时给出从源码全量构建的 Compose 模板与仅引用现成镜像的模板，方便「愿意编译最新提交」和「只想稳定跑 release」两类人各取所需。环境变量、卷挂载以及日志和配置目录在完整 Compose 文件中有注释说明，对要把数据目录挂到宿主机持久化的人来说，这比散落在论坛帖子里靠谱得多。

对我们的生活/工作有什么帮助？

对习惯把账号挂在固定设备上的观众，把服务部署在家里的软路由或 NAS 上，可以减少在办公电脑存 Cookie 的心理负担，调度与日志也集中在一处。对偶尔做活动任务、会员任务的用户，图形界面里开关任务、调整 Cron，比改 YAML 更直观，适合非专职运维的爱好者。

对实施与学习场景，小新认为它适合作为「接口调用 + 定时作业 + 管理后台」的完整样本：既能观察 Web 层如何组织配置与账号，也能对照接口集合理解业务域划分。前提是遵守平台规则与产品说明中的合规要求，把自动化限制在个人学习与授权范围内，而不是试探风控边界。

普通人如何实现盈利？

若具备部署与排障能力，可以为有刚需但不愿自己折腾的朋友提供合规的私有化部署与代维服务，按年或按次约定服务范围与责任边界。若熟悉二次开发，可在尊重 GPLv3 许可证的前提下承接定制，例如对接企业内通知渠道或与企业身份体系集成，以开发合同计费。

也可以把「从拉镜像到首登改密」写成可复用的文档与短视频教程，通过知识付费或打赏获得回报，但需如实说明风险与限制，不承诺违反平台条款的用途。任何路径都应以合法合规为前提，避免代挂、批量养号等灰色需求。

总结

开源哔哩哔哩日常任务方案把「定时做事」和「看得见的管理台」绑在一起，Docker 交付降低了环境差异带来的摩擦，SQLite 默认方案又减轻了配套中间件负担。小新如果正想找一套可自托管、可对照源码学习的 B 站自动化样本，不妨从完整 Compose 构建起步，改好密码再慢慢打开任务开关。你会优先把这类服务跑在家里，还是放在云主机上？

图片

购买后查看资源链接：