公开测试开始：豆备 0.0.1

这个项目的第一行代码是 2020 年 5 月写的。那时候它是个 Go 命令行工具 （its-my-data/doubak）， 断断续续跑了几年，也真的抓下了一份 782 MB 的档案——本项目后来几乎所有的设计判断， 都是拿那批数据验证的。那个仓库上周归档了。

现在这一版是重写：从命令行搬进浏览器扩展，7 月 28 日第一次提交，到今天五天。 抓取已经对着真实豆瓣跑通了：广播、五类标记列表、作品详情页和封面图， 增量抓取，导出与回读校验。112 次提交里 48 个是 fix:， 18 个是 feat:——修的比做的多两倍半。这个比例挺说明问题： 绝大多数坑不是设计阶段能想出来的，得让它对着真实的豆瓣跑一遍才会露头。

为什么现在就开放

因为广播等不起。

广播的正文发出去之后不能编辑——这一点在真实账号上确认过。 这让每一条广播都成了「某句短评在那个时刻长什么样」的带日期快照， 是唯一能回溯检测编辑的来源。同时它可以被静默删除：删掉之后， 没有任何东西能证明它曾经存在过。抓过就是抓过了，没抓就是永远没有了。

对比之下，作品详情页什么时候抓都一样——豆瓣的条目库不会因为你晚一个月就消失。 所以优先级是按不可替代程度排的：广播 → 自己写的长文 → 自己上传的图片 → 标记列表 → 作品详情页。既然最不可替代的那一段已经能跑了，压着不放没有道理。

能跑的

• 广播、五类标记列表（书／影视／音乐／游戏／舞台剧）、作品详情页与封面图
• 增量抓取：沿着上一份档案的下界回溯，只抓新增的，并标出改动过的和已经失效的条目
• 连续性证明：每条路线从哪里回溯到哪里、中间有没有缺口，都写进档案
• 崩溃恢复：service worker 被杀掉是常态，恢复之后能接着跑，也不会伪造出一次「跑完了」
• 导出整条链，导出后回读校验一遍

不能跑的

• 用户上传的图片（相册、日记里的插图）还没抓。 目前只有作品封面。这正是「备份必须联网才能看」的病根，是接下来最优先的一块。
• 日记 / 影评 / 相册这条路线还没接上，需要走豆瓣另一套接口。
• 导出中断要从头来，没有续导。
• 还没跑过一次几小时量级的完整全量。 只做过小范围试跑。段轮转、跨越多次 worker 被杀死这些事，在真实规模上还没有实测数据。

顺便说清楚：这一版是 vibe coding 写的

前一版是古法编程，Go 代码一行一行手敲出来的，写了几年。 这一版基本是 vibe coding：五天，112 次提交。这件事该说在明处， 因为你正要把不可再抓的数据交给它。

模型写出来的代码会很自信地错，而且专挑「看起来跑通了」的地方错—— 这一版 48 个 fix: 里相当一部分正是这类：抓取在第一段之后停住却报告 「跑完了」、连续性证明活不过一次崩溃、6 条单页路线整场显示「进行中」而它们第一秒就结束了。 这类 bug 不会抛异常，它们只是给你一个比事实更好听的结论。

所以这个项目的很多取向，与其说是洁癖，不如说是对这一点的对冲：

• 零依赖、零构建步骤——不引入没人读过的第三方代码， 仓库里的源码就是浏览器里跑的东西。要审计它，不需要先信任一条流水线。
• 51 个测试文件，npm test 零安装就能跑，你可以自己验。
• 凡是结论都对着真实数据验：判定器拿 6341 个真实页面校准， 设计判断拿一份 782 MB 的旧档案复核—— 其中一条当场被推翻了。
• 不可逆的那一步反复推翻重来，可逆的那一步干脆还没开始写。 档案格式改了十几轮才定；解析器一行都还没有，因为它随时可以重跑。

换句话说：别信这段代码，去读它、去跑它的测试、去看它产出的档案能不能被 别人的工具打开。这个项目的每一个设计决定，都是为了让你有能力不相信它。

怎么装

后来（2026-08-15）：已经上架了，直接装就行 —— Chrome 应用商店。 下面这段是写这篇时的装法，留着不改：开发日志记的是当时的状态， 把旧文改成现在的样子，等于把「当时不知道」这件事从记录里抹掉。

Chrome 网上应用店还在准备上架，现在请用开发者模式加载：

git clone https://github.com/Doubak/doubak-extension.git

# Chrome / Edge:
#   打开 chrome://extensions
#   → 打开右上角「开发者模式」
#   → 「加载已解压的扩展程序」
#   → 选中刚 clone 下来的目录

零依赖、零构建步骤，仓库里的源码就是浏览器里跑的东西， 不需要 npm install。装完点工具栏图标进面板， 先在「调试」页跑一次演练（零网络请求），再跑一次小范围试跑， 然后再开始正式抓。

什么样的反馈最有用

面板的「日志」页可以整份复制出来，里面是抓过的 URL、重试、停机原因和错误。 提 issue 时带上它最有用。 特别想知道这几件事：

• 抓到一半停下来了，停机原因写的是什么
• 覆盖率页上出现了缺口，是哪条路线、哪一页
• 豆瓣声称的数量和实际抓到的数量对不上（这个本身就是有价值的数据，见 这一篇）
• 界面上哪句话让你产生了错误的理解——这个和 bug 一样重要

日志里可能有你的用户名和条目链接，觉得敏感就删掉那部分再贴，不影响定位问题。