Bilibili Favorites Executor 开源：把收藏夹迁移做成可审计、可暂停、可恢复的本地执行器
我把 Bilibili Favorites Executor 开源了。
这是一个运行在 Bilibili 收藏夹页面里的 Tampermonkey 执行器。它不接管你的账号，不上传 Cookie，不把收藏夹数据传到第三方服务器；它只做一件事：导入已经审核过的任务包，然后用保守节奏执行收藏夹迁移、复制、目标夹创建、暂停恢复、备份和报告导出。
项目地址：github.com/nj-zhangrui-arvin/bilibili-favorites-executor
为什么做它
Bilibili 收藏夹用久了以后，很容易变成一个数字仓库：视频越来越多，分类越来越旧，想整理却不敢动。
真正困难的地方不只是“怎么分类”，而是分类之后怎么可靠地执行：
- 批量迁移不能一口气猛跑，否则容易触发风控。
- 网络中断、页面刷新、接口返回异常时，不能把状态搞乱。
- 迁移前后需要可追踪，最好能导出备份和执行报告。
- 删除、清理这类危险动作必须和分类迁移隔离。
所以我把系统拆成了清晰的三层：任务生成、页面执行、知识采集。这个仓库只实现中间的 Executor，把最容易出事故的写操作执行层单独做稳。
它解决什么
本地执行
脚本只在浏览器和 Bilibili 页面上下文里运行，复用当前登录态，不上传账号凭证和任务包。
保守迁移
move 采用“先加入目标夹，再移出来源夹”的两步策略，并在写操作之间加入随机间隔。
可恢复
执行状态保存在本地，可暂停、可备份、可继续，异常时优先挂起而不是继续冒进。
可审计
任务包先由人审核，执行后可导出报告，把改了什么、哪里失败了留成证据。
边界很重要
这个项目不做 AI 分类，也不采集视频内容到知识库。
它接收的是已经审核过的任务包。任务包可以来自规则脚本、AI 分类器，或者手工整理；Executor 不关心上游怎么生成，只负责按契约保守执行。
这种边界让项目更容易审查，也更适合作为开源工具长期维护：分类策略可以迭代，知识库可以独立演进，但写操作执行层必须稳定、透明、可控。
安全模型
Executor 的默认策略是宁可慢一点，也不要把账号状态推到不可控的位置。
- 遇到
403、412、登录失效、csrf 缺失、写接口非成功码，会立即挂起。 - 写操作之间有随机间隔，批次之间有休息。
- 迁移状态写入
localStorage，可导出 JSON 备份。 - 清理失效视频、删除收藏夹是独立维护工具，不读取任务包，也不参与迁移流程。
它不是全自动乱改收藏夹的脚本，而是一个带刹车、带记录、带恢复点的执行台。
适合谁
如果你有大量 Bilibili 收藏夹，想把旧分类迁移成新的知识结构，又不想把账号凭证交给第三方服务，这个工具会比较适合。
如果你正在做个人知识库、AI 视频摘要、收藏夹自动整理，也可以把它作为最后一步执行器：上游负责生成计划，人负责审核，Executor 负责落地。
下一步
我会继续把它和自己的收藏夹整理流程接起来：前面用脚本和 AI 生成候选任务包，中间人工审核，最后由 Executor 在页面里稳定执行。
后续可能补的方向：
- 更完整的任务包校验和错误提示。
- 更细的执行报告。
- 与 Obsidian/本地知识库的整理流程衔接。
- 英文文档和更多示例任务包。
项目已经 MIT 开源，欢迎查看源码、提 issue，或者直接 fork 成你自己的收藏夹执行台。