前言¶

自己盯着 B 站账号看每周投了哪些视频，要么翻创作中心后台，要么翻历史记录，每周一次挺烦。更麻烦的是自动化脚本跑完了，报告躺在磁盘上，你不会每次都去打开它。

这个 Skill 解决的就是后半段：跑完每周播报脚本 → 读报告文件 → 整理成一段文字 → 同时推到微信和邮箱。前半段脚本本身它不负责。

这是什么¶

SkillHub 上的社区 Skill，坐标 @user_96ce8353/bilibili-video-monitoring，当前版本 1.1.1，分类 ai-agent，来源 community，发布者 user_96ce8353。

它的定位不是「帮你写 B 站文案」，也不是「全功能 B 站 API 封装」，而是一条固定的流水线：运行每周播报脚本、读取生成的报告文件、把内容整理成文字、通过双通道推送给用户。

触发场景写得很明确：用户请求“查看B站播报”“运行播报脚本”“生成本周投稿报告”，或类似表达。也适用于自动化定时任务执行完毕后，读取报告内容并推送。

标签里有一项 requires_api_key=true，说明依赖的凭据需要你自己准备。

核心功能¶

按官方简介，能力分四步，每一步都有明确的文件或接口边界：

1. 运行 B 站每周播报脚本，产出本周投稿报告。
2. 读取生成的报告文件，把内容整理成一段文字。
3. 推送通道一：调用 @skill://微信 PC 端自动控制，把整理好的内容发送到配置的微信联系人。
4. 推送通道二：调用 @skill://agently-mail（Agent Mail），把报告发送到配置的邮箱地址，采用两阶段确认：发信前先展示摘要，用户确认后再发出。

两个推送通道是互补的，不是二选一。微信通道面向日常即时查看，邮箱通道带确认环节，适合作为存档型备份。

脚本、报告、Cookie 三个路径，官方简介给出的是相对路径：

脚本路径    bibili_weekly.js
报告文件    ./bilibili_report.txt
Cookie 文件 ./bilibili_cookie.txt

作者在自己的机器上部署时用的是 Windows 绝对路径，如果你要改成自己的部署，照这个结构对应替换：

C:\Users\X270\.workbuddy\skills\bibili-video-monitoring\bibili_weekly.js
C:\Users\X270\WorkBuddy\Claw\.workbuddy\bibili_report.txt
C:\Users\X270\.workbuddy\skills\bibili-video-monitoring\bilibili_cookie.txt

注意官方原文里脚本目录名拼作 bibili-video-monitoring、脚本名 bibili_weekly.js，两个都是单 b，和 Skill 名里的 bilibili 不一致。照抄路径时别顺手改成双 b，否则找不到文件。

作者自用配置里，微信联系人是“微光浮影”（UID 3493115144964536），邮箱是 laohuoji5903@agent.qq.com。这两处是作者自己的部署值，不是你的配置，需要在脚本里改。

安装与启用¶

已抓取资料里没有给出命令行安装指令，也没有 Cursor / Codex CLI / Claude Code 的分端差异说明，这部分不猜。官方页面给出的是技能坐标和触发表达，启用路径就是通过 SkillHub 页面对应坐标使用该技能。

上手前要自己准备的东西，按官方说明和路径推断：

1. B 站 Cookie。官方简介明确写了“需自行创建，切勿提交真实 Cookie”。Cookie 文件路径见上，文件不存在脚本就取不到登录态，播报脚本大概率跑不动。
2. 两个下游 Skill。微信通道依赖 @skill://微信 PC 端自动控制，邮箱通道依赖 @skill://agently-mail。任一缺失，对应通道不可用，但不影响另一条通道。
3. 可写的报告目录。报告落在 bilibili_report.txt 所在目录，脚本要能读、Skill 要能读。
4. 脚本内的接收方配置。微信联系人和邮箱地址都写在脚本里，官方简介也写了“默认 UID 请在脚本中配置”。

安装数值方面，SkillHub 页面显示评分 100000、下载 742、安装 0。安装数为 0 意味着目前还没有人通过页面统计口径安装过，实际使用者数量未知，不要当成成熟度信号。

典型用法¶

不需要写调用参数，用自然语言触发即可。按官方给出的触发场景，直接说下面任意一句：

查看B站播报
运行播报脚本
生成本周投稿报告

具体行为按官方描述走完整链路：脚本跑完 → 读取报告 → 整理文字 → 微信联系人收到内容 → 邮箱侧先弹出摘要，你确认后才真正发出。

定时任务场景下，触发时机由你的自动化任务决定，Skill 侧只负责在执行完毕后读取报告并推送。也就是说它适合挂在 cron / 定时任务的尾部，而不是自己起一个调度。

适用场景与注意¶

适合这几类人：已经写了（或准备写）B 站每周播报脚本，想把报告自动递送出去；需要在多个端同时看到每周投稿结果；愿意自己处理 Cookie 和依赖 Skill。

几个坑按官方资料可以直接判定：

• Cookie 是自己创建并维护的，官方明确要求不要把真实 Cookie 提交进仓库。要做就放本地路径或忽略列表里。
• 路径是 Windows 风格，用 C:\Users\... 形式。在 Linux / macOS 上部署需要自行改成对应路径，别照抄。
• 目录名和脚本名的单 b 拼写是原文如此，替换路径时保留。
• 推送通道二有两阶段确认，所以不是无人值守的静默发送。如果放在无人值守的定时任务里，确认环节需要有人在场，否则邮件发不出去，这一点要提前想清楚。
• 官方简介里的联系人和邮箱是作者配置，直接用会推到别人手上，动手前先改。
• 下游依赖 Skill 的可用性决定了通道可用性，缺一个就只剩单通道，降级行为官方资料里没写。

结尾¶

它的价值不在功能多，而在把「脚本跑完 → 报告归档 → 人收到消息」这条链路变成一句话触发，省掉每周手动开文件的步骤。双通道的意义是即时查看和留档备份各占一条，邮件那侧的人工确认也避免了误发。

官方地址：https://api.skillhub.cn/user_96ce8353/bilibili-video-monitoring
SkillHub 页面：https://www.skillhub.cn/skills/user_96ce8353/bilibili-video-monitoring