更新：没想到这么多朋友感兴趣，坦白说下——这就是我们在做的产品，叫快咔截图，官网 kuaika.app ，上面说的这套引擎就是它的核心。目前可以下载用了，Windows / macOS 都有。帖子里踩的坑基本都还在持续优化（尤其是查询理解和多语言混排这两块），大家用了有任何问题直接在这里回或者私信我，都欢迎。开源的事我们在认真考虑，有进展会第一时间在这个帖子里更新。

云端做 OCR 的那些（网盘、相册类）思路确实类似，都是「图片 → 文字 → 建索引」。不过我最后选本地自建，主要是两个现实原因：

一是隐私和范围。云端方案只能扫「传上去的」，我这堆截图里不少是工作相关的（配置、代码片段、聊天记录截屏），不太想整包交给云。本地跑 OCR 虽然慢点，但几百 G 的历史截图一次索引完，之后查询都在自己机器上。

二是查询这一环。识别出文字只是一半，真正的难点是我记不清原话——只能描述「那个带 redis 配置的报错截图」。所以后端对查询做了不少容错（同义改写、拼音、部分匹配），这部分反而是比 OCR 更花时间的坑。

7 楼问的手机相册搜索，原理确实是一个路子，只不过人家是在端侧跑的小模型，精度和吞吐都是另一个量级的取舍了。

刚做完一个类似纠结的决策，说说实操感受。

我们现在把“模块”当成给 AI 的上下文路标来用——不是因为老规矩要求分层，而是发现 agent 在职责清晰的目录结构里干活，改动的爆炸半径小得多。比如有个截图搜索的功能，OCR 、索引、查询这三块从一开始就拆开，后来重做索引策略的时候，AI 只需要动其中一个目录，另外两块的测试全绿直接过。

反过来也试过让 AI 在一个“顺手都写这儿”的项目里加功能，改一处它会把不相干的几个文件也顺手“优化”一遍，review 的成本比写代码还高。

所以我的结论是：AI 时代不是不规划模块，而是规划的理由变了——从“方便人维护”变成“给 AI 划定改动边界”。SQL 那个例子，如果那段 SQL 只有一个地方用，直接写没问题；超过两处就该收拢了，不然让 AI 全局搜索着改的时候，你不知道哪处会漏。

@coefu 私聊，加我微信 QQTommer

感谢几位回复，说两句。 @383394544 你说的「一个事实只有一个权威来源」我很认同，我们实际也是往这个方向收敛：记忆层只留工作流、代码位置和少量关键偏好，事实类的东西宁可现场查，token 换准确性划算。 @coefu 批评「没有理论深度」我接受，我们确实是从工程问题倒推去翻认知科学文献，而不是先有理论再设计，路走得歪但踩过的坑是真的。chenzi0103 的 mermaid 思路也记下了，很多确定性流程确实没必要拉 LLM 进来。这帖就想听坑，收获比预期大。