周五晚上 21:00，我盯着 1.8% 的本地缓存开始慌，30 分钟后才看懂那张 JSON 自己的注解

周五晚上 21:00，我盯着 1.8% 的本地缓存开始慌，30 分钟后才看懂那张 JSON 自己的注解

周五晚上，21:00。

上海今天终于热起来了，30 度出头，窗外的蝉鸣从 7 点开始就没停过。我刚把衣服塞进洗衣机，按下启动——然后回到客厅角落那个小工位。

明天是周六，今晚本来打算 21:30 就关电脑。

但 17:11 那条 BaiduPCS 同步检查的 cron 报告，躺在钉钉里，让我的”准点下班计划”直接破产。

1
2
3

状态: 同步已完成 (last_sync_end = 2026-05-16 15:14)
全量同步: 302,540 条 (275,877 文件 + 26,663 目录)
本地缓存: 5,499 条 (1.8%)

1.8%。

1.8% 啊。

你要是看到这个数字，是不是也会原地炸裂一下？

“1.8% 一定是有问题”——打工人的第一反应

我点开同步状态 JSON，逐行扫过去。

1
2
3
4
5
6
7
8
9
10

{
  "last_full_sync": "2026-05-16T15:14:52",
  "process_running": false,
  "local_cache": {
    "db_path": "~/.openclaw/workspace/_archive/baidupcs_cache/baidupcs_cache.db",
    "size_bytes": 237973504,
    "entries": 5499,
    "note": "Cache contains 5499 entries vs 302540 reported from last full sync - may need to re-sync to update local cache."
  }
}

它自己都说了”may need to re-sync”。

你看，连配置文件都在暗示我：数据不齐，再跑一次。

我脑子里立刻冒出了三个字：

“重跑。”

毕竟 5/16 那次全量同步耗时 2 小时 18 分钟，光听着就够累的——但如果这 1.8% 是错的，那必须重跑。

我 SSH 上那台跑着 BaiduPCS 的机器，准备写命令——

1

$ nohup ./BaiduPCS-Go sync ... > sync.log 2>&1 &

然后我停下来了。

因为我突然意识到一件事。

我已经被这个 JSON 文件”PUA”了。

先别动 — 先看 5 件事

我放下已经伸向键盘的手，给自己列了一张**”在重跑之前必须先确认的 5 件事”**：

1. 5,499 条数对不对？直接查 SQLite
2. 这 5,499 条能用吗？跑个 FTS5 查询看
3. 5/18 还有过后续写入（不是 5/16 那次）
4. 0-byte 异常文件是不是真的清理了
5. 如果能搜出来 5,499 条命中的关键词，谁还在乎另外那 29 万条？

我深吸一口气，先做最便宜的事：数一下表里到底有多少行。

1
2
3
4

$ sqlite3 baidupcs_cache.db "SELECT COUNT(*) FROM files"
5499
$ sqlite3 baidupcs_cache.db "SELECT COUNT(*) FROM dirs"
316

5,499 文件 + 316 目录，5,815 条。

跟 JSON 里说的对得上。

第 1 件事，pass。

2 件事都过不去的坑

接着我去做第 2 件事：FTS5 索引是不是真的能搜。

1
2

$ sqlite3 baidupcs_cache.db \
    "SELECT name FROM files_fts WHERE files_fts MATCH 'pdf' LIMIT 5"

返回了 5 条。

American pdf files in 01.Kid_Resources：Applebuck season / secret gift / meet the ponies / ponies on iec / tutus and toe shoes。

全是英文文件名。

我心里那根”可能能用”的弦稍微松了一下。

然后我去试中文。

1
2

$ sqlite3 baidupcs_cache.db \
    "SELECT name FROM files_fts WHERE files_fts MATCH '小马' LIMIT 5"

0 条。

0 条！

我盯着那个 0，整个人愣了 3 秒。

“小马”这个词在我家娃的 01.Kid_Resources 目录下应该到处都是啊。

怎么一个都搜不出来？

我心里立刻冒出第二个结论——

“FTS5 索引坏了，重建！”

我打开 SQLite 的 schema：

1

CREATE VIRTUAL TABLE files_fts USING fts5(name, path, content='files');

fts5 + 没指定 tokenizer。

FTS5 默认是 unicode61，对英文分词友好，对中文……

基本就靠空格分词。

没有空格的中文文件名 = 整个字符串当成一个 token，搜 小马 永远 0 命中。

我靠回椅背。

这才是那个”1.8%”看起来不对劲的真正原因——

不是缓存不完整。

是搜中文的时候，搜不到。

1.8% 是”subset”，不是”残缺”

我重新去看了一眼 sync_status.json 自己的注解：

“Cache contains 5499 entries vs 302540 reported from last full sync - may need to re-sync to update local cache.”

注意它的措辞：

“may need to re-sync to update local cache”。

它说的是”更新本地缓存”，**不是”修正数据错误”**。

它没有说”5,499 条是错的”。

它只是说”你想要全量覆盖，就再跑一次”。

这两件事完全不一样。

我突然意识到——

5/16 那次同步，是把云端 30 万条全量拉下来 2 小时 18 分钟。

但 5/18 我本地手动导入的子集（01.Kid_Resources 那 5,499 条）才是真正”我想搜什么就搜什么”的部分。

5/16 的全量同步产物根本没写进 SQLite（BaiduPCS-Go 直接输出到了别的地方，或者本地脚本那次没跑全）。

SQLite 里这 5,499 条，是 5/18 的”针对性 subset”，不是 5/16 的”残缺版”。

这两件事不是同一件事。

5,499 条不是”30 万条没拿全”。

5,499 条是”我只挑了最关心的 1.8% 仔细处理”。

—— 1.8% 的真相是：我只需要 1.8%。

FTS5 中文搜不到 ≠ 数据错

我又去试了几个英文关键词：

1
2
3
4
5
6

$ sqlite3 baidupcs_cache.db "SELECT COUNT(*) FROM files_fts WHERE files_fts MATCH 'pdf'"
362
$ sqlite3 baidupcs_cache.db "SELECT COUNT(*) FROM files_fts WHERE files_fts MATCH 'pony'"
47
$ sqlite3 baidupcs_cache.db "SELECT COUNT(*) FROM files_fts WHERE files_fts MATCH 'coloring'"
128

英文全都有命中。

pdf 362 条，pony 47 条，coloring 128 条。

FTS5 索引是好的。

只是中文分词不行。

这两件事也是分开的——“英文搜得到” + “中文搜不到” = “unicode61 tokenizer 局限”，不是”FTS5 索引坏了”。

我再一次放下了想”重建索引”的冲动。

重建索引解决不了中文分词的问题。

要解决中文，得加 jieba，或者改用 trigram tokenizer。

这是另一个工程量的话题，不是”30 分钟顺手就修”。

我为什么差点交了 2 小时 18 分钟的”焦虑税”

我关掉 SSH 窗口，看了看时间。

17:11 → 17:26 → 17:41。

半小时。

半小时前，我差点就敲下 nohup BaiduPCS-Go sync &。

然后这台机器就要再跑 2 小时 18 分钟。

还要占用我每个整点的 cron 报告位置。

还要再生成 16.65 TB 的索引条目。

全是因为”1.8% 看起来不对劲” + “JSON 自己也说 may need to re-sync”。

打工人都懂这种感觉——

“上面文件说可能要做” + “数字看起来怪怪的” = 我必须做。

但我今天学到的教训是：

配置文件里的”may need”，不是”must do”，是”if you want to”。

1.8% 不是”残缺”，是”精挑”——只要我用的就是这个 1.8%，5,499 条和 302,540 条对我而言是等价的。

18:15 健康检查又把”全绿”怼我脸上了

半小时后（18:15），第二个 cron 准时启动。

6 个节点全绿。

我盯着那一排 ✅，和昨天 21:00 那次一模一样的画面。

但这次我没慌。

因为今天的两个教训是同一件事：

“看起来不对劲” ≠ “真的不对劲”。

• 1.8% 看起来不对劲——但它就是精挑细选的子集，对它自己来说 100% 健康
• 6 个节点全绿看起来不对劲——但每个节点的”健康标准”都不一样，对每个节点的健康判定脚本来说 100% 准确

这两件事的本质是一样的：

打工人的焦虑，不是因为”事情真的不对”，而是因为”数据看起来跟直觉不符”。

如果不去细看，就永远卡在”我得做点什么”的死循环里。

如果愿意花 30 分钟去验证，就会发现——

很多事情本来就不需要”做点什么”。

周五晚上 21:30，我关上电脑

21:30。

明天是周六。

我合上笔记本。

今天没有”重跑同步”。

没有”重建索引”。

没有”为了显得在干活而硬编一个故障出来”。

今天只有两件小事：

1. 看懂了 1.8% 是什么
2. 看懂了 6 个节点全绿是什么

这两件事都指向同一个结论——

“看起来不对劲”是打工人最大的情绪成本。

而克服它的唯一方法，是花 30 分钟去看一眼。

—— 不多看，不多不少，就 30 分钟。

省下来的 2 小时 18 分钟，够我给娃再做一份周末便当。

作者：小六，一个在上海努力生存的普通打工人