给几百 G 的本地截图做一个能搜内容的引擎，我踩过的坑

MaskerPRC · 2026-09-11T21:02:00+08:00

最近做了个小工具：把我攒了几年、按字节算快 1T 的电脑截图（微信聊天截图、网页截图、报错截图、PPT 截图……）做成一个能直接搜内容的引擎。比如搜「上次那个 nginx 502 的报错」，直接把当时那张截图翻出来。功能听起来不新鲜，但自己动手做一遍，坑比想象的多。这里把踩过的坑记录一下，给同样有这个需求的朋友参考。坑一：OCR 不是「接个库」那么简单一开始想当然：截图 → OCR → 存文本 → 搜，完事。实际：- 中文截图里夹杂的英文报错、路径、代码，混排识别率惨不忍睹。纯中文 OCR 库对 Error: EACCES: permission denied '/var/log/...' 这种行基本全军覆没；- 后来换成多模型互补：通用 OCR 打底，对识别置信度低的行再走一次视觉模型重读，准确率才到了能用的水平；- 坐标信息别丢——OCR 返回的文字块位置留着，后面高亮定位全靠它。坑二：索引体积失控几个月的截图，全量向量化之后索引文件比截图本体还大。两件事必须做：- 切分粒度：按文字块切，不要按整张图切。一张 1080p 截图 OCR 出来可能有 40 个块，大部分是时间戳、水印、无关 UI 文字——先过一遍规则过滤（正则 + 长度 + 位置），能砍掉六成索引量；- 分层检索：先文本关键词粗筛（ SQLite FTS5 就够），命中候选再走向量精排。别一上来就全库 ANN 搜，慢且贵。坑三：查询理解是最容易被忽略的一环用户搜「那个 502 」，你拿什么去向量库里匹配？查询改写这层一定要做：- 把口语查询改写成「可能出现在截图里的文字形态」（比如把「报错」扩写成 error / failed / 错误）；- 时间限定词（「上个月」「上周」）单独解析出来，转成过滤条件，别混进向量里。效果现在 300+ 天的截图，一次搜索 1 秒内出结果，准确率主观评价八成以上。最大的收益是「再也不用翻聊天记录找那张图了」。最后这个项目的启发是：RAG 这套东西落到个人小工具上，工程量最大的不是向量检索本身，而是数据清洗和查询理解——七成时间花在了这两块。代码还在整理，如果大家有兴趣，后续开源出来。也欢迎交流你们做本地内容检索的思路。

1314

MaskerPRC2026-09-11
66681
最近做了个小工具：把我攒了几年、按字节算快 1T 的电脑截图（微信聊天截图、网页截图、报错截图、PPT 截图……）做成一个能直接搜内容的引擎。比如搜「上次那个 nginx 502 的报错」，直接把当时那张截图翻出来。
功能听起来不新鲜，但自己动手做一遍，坑比想象的多。这里把踩过的坑记录一下，给同样有这个需求的朋友参考。
坑一：OCR 不是「接个库」那么简单
一开始想当然：截图 → OCR → 存文本 → 搜，完事。实际：
- 中文截图里夹杂的英文报错、路径、代码，混排识别率惨不忍睹。纯中文 OCR 库对 Error: EACCES: permission denied '/var/log/...' 这种行基本全军覆没；
- 后来换成多模型互补：通用 OCR 打底，对识别置信度低的行再走一次视觉模型重读，准确率才到了能用的水平；
- 坐标信息别丢——OCR 返回的文字块位置留着，后面高亮定位全靠它。
坑二：索引体积失控
几个月的截图，全量向量化之后索引文件比截图本体还大。两件事必须做：
- 切分粒度：按文字块切，不要按整张图切。一张 1080p 截图 OCR 出来可能有 40 个块，大部分是时间戳、水印、无关 UI 文字——先过一遍规则过滤（正则 + 长度 + 位置），能砍掉六成索引量；
- 分层检索：先文本关键词粗筛（ SQLite FTS5 就够），命中候选再走向量精排。别一上来就全库 ANN 搜，慢且贵。
坑三：查询理解是最容易被忽略的一环
用户搜「那个 502 」，你拿什么去向量库里匹配？查询改写这层一定要做：
- 把口语查询改写成「可能出现在截图里的文字形态」（比如把「报错」扩写成 error / failed / 错误）；
- 时间限定词（「上个月」「上周」）单独解析出来，转成过滤条件，别混进向量里。
效果
现在 300+ 天的截图，一次搜索 1 秒内出结果，准确率主观评价八成以上。最大的收益是「再也不用翻聊天记录找那张图了」。
最后
这个项目的启发是：RAG 这套东西落到个人小工具上，工程量最大的不是向量检索本身，而是数据清洗和查询理解——七成时间花在了这两块。
代码还在整理，如果大家有兴趣，后续开源出来。也欢迎交流你们做本地内容检索的思路。
主楼
stonesirsir2026-09-11
42300
先期待一下
#1
zq112112772026-09-11
67201
支持感觉这个很有用
以后我们可以 1 分钟电脑截屏保存一次，然后利用楼主这个引擎进行回忆
#2
wises2026-09-11
1617
期待开源...
#3
gswgudujian2026-09-11
49513
期待开源...
#4
Orangeee2026-09-11
42457
👍多谢分享
#5
crackhopper2026-09-11
47964
6 ，应该直接卖钱，订阅。
#6
HeyWeGo2026-09-11
2119
手机里的搜索图片里内容原理是不是类似
#7
homcrazy12026-09-11
44932
不错哦，别了一些灵感
#8
paradoxs2026-09-11
67202
应该是有一些办法可以减少索引量的，百度网盘，onedrive 之类的，很早之前就可以实现对截图中的文字实现 OCR
#9
needpp2026-09-11
2383
牛，期待开源
#10
babyedi319962026-09-12
1545
这……immich 不就是有这功能吗
#11
MaskerPRC2026-09-12
66681
云端做 OCR 的那些（网盘、相册类）思路确实类似，都是「图片 → 文字 → 建索引」。不过我最后选本地自建，主要是两个现实原因：
一是隐私和范围。云端方案只能扫「传上去的」，我这堆截图里不少是工作相关的（配置、代码片段、聊天记录截屏），不太想整包交给云。本地跑 OCR 虽然慢点，但几百 G 的历史截图一次索引完，之后查询都在自己机器上。
二是查询这一环。识别出文字只是一半，真正的难点是我记不清原话——只能描述「那个带 redis 配置的报错截图」。所以后端对查询做了不少容错（同义改写、拼音、部分匹配），这部分反而是比 OCR 更花时间的坑。
7 楼问的手机相册搜索，原理确实是一个路子，只不过人家是在端侧跑的小模型，精度和吞吐都是另一个量级的取舍了。
#12
MaskerPRC2026-09-12
66681
更新：没想到这么多朋友感兴趣，坦白说下——这就是我们在做的产品，叫快咔截图，官网 kuaika.app ，上面说的这套引擎就是它的核心。目前可以下载用了，Windows / macOS 都有。帖子里踩的坑基本都还在持续优化（尤其是查询理解和多语言混排这两块），大家用了有任何问题直接在这里回或者私信我，都欢迎。开源的事我们在认真考虑，有进展会第一时间在这个帖子里更新。
#13
morota2026-09-13
66382
@MaskerPRC
点击下载就报错
<Error>
<Code>NoSuchKey</Code>
<Message>The specified key does not exist.</Message>
<RequestId>6AA6085A98945C3636A33ADF</RequestId>
<HostId>jieshi-self-system.oss-cn-beijing.aliyuncs.com</HostId>
<Key>deploy-artifacts/kuaika/20260910-094058-5de5/pc/快咔-Setup-0.0.41.exe</Key>
<EC>0026-00000001</EC>
<RecommendDoc>https://api.aliyun.com/troubleshoot?q=0026-00000001</RecommendDoc>
</Error>
#14

发表回复

登录后回复