你可能也遇到过这种场景：刚才还刷到过一个很关键的技术帖子，等想回去翻的时候，就是找不到；开会时有人提到一个数据，你记得之前看到过，但死活想不起来在哪看到的；或者说，你想复盘自己一天的工作，却完全不记得下午两三点那会儿到底在忙什么。
这种“想不起来”的问题，本质上不是记性差，而是信息进来的时候没有建立索引。很多所谓的碎片化阅读，真正浪费的不是你读的那几分钟，而是你读完就忘、下次想用却找不到的那一次搜索。
我最近就在做一个叫“hindsight”的小项目，想解决的就是这件事。hindsight 这个词本身是“后见之明”的意思，心理学里也有个著名的“后见之明偏差”，说的是事后觉得自己早就知道。把项目起名叫 hindsight，我其实想表达的是：让电脑帮你记住那些你当时没在意、事后才觉得重要的信息，让你每次回溯，都有一种“原来这里我看过”的确定感。
这篇文章就把这个项目的完整思路、技术方案和实操过程拆开来讲，包括每一层模块怎么选型、核心代码怎么写、会遇到哪些坑、以及我做了哪些隐私保护取舍。如果你也想过“能不能给自己的电脑装一个外部记忆库”，这篇应该能帮到你。
1. 我为什么要做 hindsight，以及它到底解决什么问题
1.1 先想清楚：你的信息为什么总是“找不到”
我们每天接触到的信息量，其实远超自己能用语言描述出来的部分。你读了一篇文章、看了一段视频、浏览了一个网页、甚至只是瞟了一眼微信群里的某张截图，这些信息都进入了大脑，但绝大多数没有被“编码”成可以检索的记忆。
人类记忆的机制很有意思，它在编码阶段就会做筛选和压缩。你当时觉得不重要的东西，大脑直接就丢掉了，不会给你事后检索的机会。但问题在于，你事后是否觉得某条信息重要，和你当时看到它时是否觉得重要，其实经常不是一回事。大多数信息都是“事后才显得有价值”的，等你想用的时候，记忆早就没了。
所以我想要的这个系统，不应该依赖人的主动记录，因为人做不到每次都主动记录。它应该像一个后台进程，不动声色地把你接触过的信息全部留存下来，建立一个可检索、可回溯的外部记忆库。简单说，就是给电脑装一个自动运行的“记忆存档器”。
1.2 hindsight 的核心思路：用外挂记忆弥补大脑的截断
一句话概括这个项目的思路：持续截屏，光学识别，向量化存储，自然语言检索。
听起来不复杂，但每个环节其实都有讲究。持续截屏解决的是“获取信息”的问题；光学字符识别（OCR）解决的是“把图像变成文字”的问题；向量化存储解决的是“让文字可以被语义检索”的问题；自然语言检索解决的是“你想不起来关键词，但记得大概意思”的问题。
这四个环节串起来，就是一个最小可用的个人记忆系统。你不需要给每条信息手动打标签，也不需要维护什么复杂的分类目录，你只需要在键盘上敲一句“我上周好像看过一篇讲 RAG 优化的文章”，系统就能帮你把相关的屏幕截图翻出来。
这就好像给大脑加了一块外置硬盘，还是带全文检索那种。虽然不能真的增强你的记忆，但它能帮你找到那些已经被大脑丢弃的信息痕迹。
1.3 为什么我不直接用现成的记录工具
市面上其实有不少可以替代的成品工具，比如截图笔记软件、浏览器历史记录、甚至像 Rewind 这样的自动回放工具。但我自己动手做，是因为几个现有方案都不太合手。
浏览器历史记录只能管浏览器里的内容，你打开本地文档、看视频、用聊天软件，它都管不到；截图笔记软件靠的是手动截图，你忘了截，它就什么都没有，而我自己恰恰就是老忘；重放类工具又太“重”了，它会把所有操作都录下来，隐私风险比较高，而且检索能力一般，你想找一条几个月前的信息，缩略图翻起来非常痛苦。
自己做一个 hindsight，好处是可以完全按照自己的使用习惯来定制。我可以控制哪些目录不记录、哪些应用不参与、数据存在本地、检索逻辑自己调。这种可控感，是成品工具给不了的。
1.4 这个项目适合谁来参考
如果你是想做一个能长期用的效率工具，这个项目很适合拿来改造成你自己的版本。如果你正在学习 AI 应用开发、想练手 RAG（检索增强生成）操作链路，那 hindsight 就是一个非常典型的落地场景：从数据采集、离线处理、向量检索到生成式回答，整条链路都覆盖了。
它的代码量其实不大，核心部分几百行就能跑起来，但对理解“信息处理管道”这件事非常有帮助。不像很多教程里用现成 PDF 文档做 RAG 演示，hindsight 的数据是从真实场景里实时采集的，噪音更多、格式更乱、清洗起来更真实，你做完以后，对检索系统的理解会比看十篇理论文章都深刻。
2. 架构设计与技术选型，我是怎么权衡的
2.1 整条数据管道的四个核心环节
先看整体流程。hindsight 的核心链路是：屏幕画面采集 -> OCR 提取文字 -> 文本清洗和切分 -> 向量化 -> 写入检索库 -> 查询时做语义匹配 -> 可选地交给大模型生成答案。
这条链路里，每个环节的输入输出都是明确定义的。屏幕画面是一张 PNG 或者 JPEG 图像；OCR 环节把它变成一段带坐标的文字；文本清洗把无关的符号、排版噪声去掉；切分逻辑把长文本切成适合检索的小段；向量化把每段文本变成一个高维数组；检索时把你的查询转成同样的数组，然后做相似度搜索。
这里面最容易被低估的其实是“切分”这个环节。很多人以为，做个人记忆系统，只要把 OCR 出来的文字整段存进去就行了。但实际上，一屏截图里的文字内容，往往混杂着窗口标题、页签名称、正文内容、按钮文案等等。如果整段存，检索效果会非常差。等会儿在实操部分我会详细讲怎么切。
2.2 截图模块的选型逻辑与跨平台差异
截图是整个系统的数据入口。它最核心的要求不是清晰，而是“稳定、不打断你”。
在 macOS 上，screencapture命令就够用；在 Linux 上可以用scrot或者gnome-screenshot；Windows 上可以用 PowerShell 配合 .NET 方法，或者用 Python 的mss库，mss是跨平台的，性能也不错，支持指定显示器区域。
我自己是在 macOS 上用的screencapture -x，-x参数表示不播放快门声音，这样截屏的时候不会有任何感知。采集频率设置在 5 秒左右一次，这个频率能保证大多数操作都有记录，又不会产生太多重复内容。如果调成 1 秒一次，可能一分钟就攒好几十张几乎一样的图，全是无效冗余，存储和 OCR 的压力都会上去。
这里有个取舍要讲清楚：截全屏还是截当前窗口。我一开始是全屏截，后来发现多个显示器的时候，全屏截图会捕获到一堆无关区域，比如另外一个显示器上开着的视频画面，OCR 出来全是噪声。后改成只截主屏的当前活动窗口，信息密度高很多。如果你的使用场景比较固定，建议优先考虑活动窗口截图。
2.3 OCR 选型：Tesseract 够用，但你要会调参数
说到 OCR，中文场景下最容易踩坑的是编码和语言包问题。Tesseract 是老牌开源 OCR，胜在免费、离线、部署简单，但它在中文识别上需要你额外下载中文语言包，而且默认参数对中文的识别效果只能说一般。
我在项目里用的是 Tesseract 5 的 LSTM 引擎，配合--psm 3模式，这个模式是自动版面分析，适合截屏这种整页内容。如果识别率不理想，还可以试试--psm 6，它把整页当作一个文本块处理，在内容比较规整的网页截图上效果更好。
如果你对中文识别精度要求更高，可以换成 PaddleOCR，它在中文上的表现确实比 Tesseract 好不少，尤其是手写体和带背景的截图。代价是依赖更重，PaddleOCR 需要安装 PaddlePaddle 框架，部署体积大很多。我做这个项目的时候先用了 Tesseract，后面再考虑要不要切换。
2.4 向量存储与嵌入模型的选择判断
OCR 出来的文字变成向量之后放在哪里、用什么模型嵌入，是决定查询效果的关键。
嵌入模型方面，我选了开源的中文向量模型。OpenAI 的 embedding 接口效果确实好，但这是纯本地项目，每屏截图都去调远程接口，不但会积累 API 费用，还有隐私问题。你要记录的是自己的一切屏幕内容，这本身就是非常私密的数据，我坚持一切都用本地模型处理。
从 embedding 模型输出的向量维度这一块，本地开源的小模型一般在 768 到 1024 维之间，检索精度和性能的平衡点也在这一区间。至于存储端，我早期用的是 Chroma 这类向量数据库，后来发现对纯本地单机场景有点杀鸡用牛刀，直接换成 SQLite + numpy 余弦相似度计算，几十万条文本向量检索全表也就是几十毫秒级别，完全够用，而且备份、迁移都非常简单。
2.5 隐私和合规设计：为什么一切都要留在本地
隐私这块，我的原则很简单：数据不出本机。所有 OCR、向量化、存储、检索都在本地完成。截屏图片在 OCR 完成后会做压缩处理，只保留 JPEG 缩略图；原文文本和向量存在本地数据库；未来如果接大模型做摘要，我也是打算用本地跑的小模型，比如 Ollama 加载 Qwen 或者 Llama 的量化版。
这里提一个很多人会忽略的点：OCR 出来的文本里可能包含密码、验证码、聊天隐私这类敏感内容。我在设计里加了一层脱敏策略，用正则把可能是密码、Token、手机号、邮箱的片段，在存储前替换成占位符。这个操作不能说绝对安全，但至少让数据即使被误看到，也不会直接泄露完整敏感信息。
工具本身是一个提高效率的东西，但前提是它不能成为新的隐私风险点。把自己的完整屏幕内容毫无保护地扔在云端，那等于把家门钥匙放在脚垫底下，还是写着“钥匙在这”那种。
3. 实操过程：从零搭一套可用的 hindsight
3.1 环境准备和依赖安装
我先说下我的运行环境，macOS + Python 3.11。各平台的安装命令不太一样，但依赖的核心库就几个。
# macOS brew install tesseract tesseract-lang # Ubuntu/Debian sudo apt install tesseract-ocr tesseract-ocr-chi-sim # Python 依赖 pip install pillow pytesseract numpy openai-chatbot我还额外用了sqlite-vec这个扩展来做向量索引，它比我自己手写 numpy 全表扫描要规范一些，还支持 SQL 查询，管理数据方便很多。如果你不想引入这个依赖，直接用 numpy 算余弦相似度也行，数据量不大的时候性能差距可以忽略。
需要说明的是，pytesseract只是 Python 调用 Tesseract 的封装，真正的识别引擎还是系统里装的那个 Tesseract 二进制文件。所以装完 tesseract 之后，要先在命令行里执行一下tesseract --version验证是否装好，再检查一下语言包是否存在。
3.2 核心代码：自动截屏 + OCR 文本提取
先看第一段，截屏和 OCR 的主流程。
import time import subprocess import os from datetime import datetime from PIL import Image import pytesseract SCREENSHOT_DIR = "~/hindsight/captures" INTERVAL = 5 # 秒 def capture_screen(): timestamp = datetime.now().strftime("%Y%m%d_%H%M%S") path = os.path.expanduser(f"{SCREENSHOT_DIR}/{timestamp}.png") # macOS 截屏命令，-x 表示无声截屏 subprocess.run(["screencapture", "-x", path], check=True) return path def ocr_image(path): # 中文 + 英文识别 text = pytesseract.image_to_string( Image.open(path), lang="chi_sim+eng", config="--psm 3" ) return text.strip() def main(): while True: try: img_path = capture_screen() text = ocr_image(img_path) if text: print(f"[{img_path}] OCR 文字长度: {len(text)}") # 下一步：写入存储（见 3.3） else: # 没识别出文字，删掉截图，不留垃圾 os.remove(img_path) except Exception as e: print(f"处理失败: {e}") time.sleep(INTERVAL) if __name__ == "__main__": main()这段代码看起来简单，但有几个细节值得说。一是空文本处理，如果 OCR 一个字都没识别出来，大概率是截到了桌面壁纸或者纯色界面，这种图直接删除，不进入存储链路，省存储也省向量化的开销。二是异常处理，OCR 偶尔会崩溃，尤其是跑久了之后，一定不能让主循环因为一次异常就整体退出。三是INTERVAL = 5这个间隔，我测试过 3 秒、5 秒、10 秒三档，5 秒是最平衡的，3 秒产生的重复图片太多，10 秒容易漏掉一些短暂停留的弹窗信息。
3.3 数据入库：文本切分、向量化和存储
OCR 出来的长文本，不能直接整篇入库。一屏内容里可能包含了正在编辑的文档、聊天窗口、状态栏时间，这些信息的“主题”完全不同。如果把整篇文本作为一个向量存进去，检索时它的语义会被稀释掉。
我的做法是按段落切分，再用滑动窗口合并短段落。具体逻辑是：把 OCR 出来的文本按空行分成若干块，如果一块的长度超过 200 字，再按句号或逗号二次切分；如果相邻两块都很短（加起来不超过 150 字），就合并成一块，因为它们大概率在描述同一件事。
import re import sqlite_vec import sqlite3 from sentence_transformers import SentenceTransformer # 加载本地中文向量模型 model = SentenceTransformer("shibing624/text2vec-base-chinese") def split_text(text, max_len=200, min_merge=150): blocks = [b.strip() for b in re.split(r"\n\s*\n", text) if b.strip()] merged = [] for block in blocks: if len(block) > max_len: # 长文本按句子切分 sentences = re.split(r"(?<=[。！？；])", block) merged.extend([s.strip() for s in sentences if s.strip()]) else: if merged and len(merged[-1]) + len(block) < min_merge: merged[-1] += block else: merged.append(block) return merged def store_text(timestamp, text): conn = sqlite3.connect("hindsight.db") conn.enable_load_extension(True) sqlite_vec.load(conn) conn.execute("CREATE TABLE IF NOT EXISTS memory (id INTEGER PRIMARY KEY, time TEXT, text TEXT, vec BLOB)") segments = split_text(text) for seg in segments: vec = model.encode(seg).astype("float32").tobytes() conn.execute("INSERT INTO memory (time, text, vec) VALUES (?, ?, ?)", (timestamp, seg, vec)) conn.commit() conn.close()这一段代码的关键点是split_text函数里的合并逻辑。很多人做 RAG 切分文本，只会用固定长度硬切，结果就是语义片段被从中劈开，检索时精确度很差。这里的段落合并逻辑虽然朴素，但对“截屏文本”这种天然带段落结构的输入，效果远好于固定窗口切分。
模型为什么用 text2vec-base-chinese？因为它是专门针对中文语义匹配训练的小模型，维度是 768，模型文件只有几百 MB，在 CPU 上 encode 一段文字只要几十毫秒，对个人项目来说非常合适。做个人记忆系统，嵌入模型用通用型还是中文专用型，差距在“你搜一个意思，但它没命中原文关键词”这种场景下体现得最明显。中文专用模型对这种泛化问题处理得更好。
3.4 查询入口：语义检索 + 大模型生成回答
存储做好了，查询就是把这个过程反过来。你输入一个自然语言问题，先转成向量，然后在库里找最相似的文本片段，再把这些片段拼成上下文，交给本地大模型生成回答。
def query(memory_db, question, top_k=5): conn = sqlite3.connect(memory_db) conn.enable_load_extension(True) sqlite_vec.load(conn) q_vec = model.encode(question).astype("float32").tobytes() rows = conn.execute( "SELECT text, time, distance FROM memory WHERE vec MATCH ? ORDER BY distance LIMIT ?", (q_vec, top_k) ).fetchall() return rows执行查询后，你会拿到top_k条历史记录，每条带原始文本、截图时间戳、相似度距离。
如果你只是想知道“我之前看到过什么东西”，那直接看这些片段就够了。但如果你希望它像 ChatGPT 一样直接给你一个总结性回答，就需要把这些片段拼进一个 prompt 里，再调用本地 LLM。
ollama pull qwen2.5:7b ollama run qwen2.5:7b "以下是从你的历史记忆库中检索到的相关片段：... 请根据这些片段回答用户的问题。"大模型这一步是可选的，它最大的价值是从多个碎片信息里帮你拼出前后关联来。比如你搜“我们什么时候讨论过数据库选型”，检索片段可能分别来自三个不同日子的截屏，大模型可以把它们整理成“本周三会议上你提到想用 PostgreSQL，原因是……”。
3.5 实测效果与性能数据
我跑了大概一周，每天工作 8 小时，看看整体数据情况。
表一是采集规模的数据，方便你对这个量级有概念：
| 指标 | 数据 |
|---|---|
| 平均每天截屏数量（5秒间隔） | 约 2400 张 |
| OCR 后识别出文字的占比 | 约 35% |
| 每天实际入库的文本片段数 | 约 600 段 |
| 一周数据库体积 | 约 1.2 GB（包含向量和缩略图） |
| 单次语义检索耗时（CPU） | 120 ms 左右 |
| 平均每日 OCR 计算耗时 | 并行处理后约 25 分钟 |
这个体积如果用纯 JSON 存原始文本，其实只有几十 MB，大头都在向量化数据和截图缩略图。考虑到现代硬盘容量，这个成本完全可接受。
但这里要提醒一句：OCR 每天消耗 25 分钟 CPU 时间，对笔记本来说是个不小的热量和耗电负担。我后来优化成“只在插电时运行”，电池模式下自动暂停，这样能显著延长笔记本续航。还有一个优化方向是内容去重——如果两张截屏的 OCR 文本完全一样（比如你停在一个页面看了很久），就不再入库，只更新时间戳。这个优化能再省掉大约 40% 的无效存储。
4. 常见问题与排查技巧
4.1 OCR 识别出来的中文是乱码或者空白
这个是我被问得最多的问题。如果你安装 Tesseract 后直接跑中文 OCR，很可能输出一堆乱码，或者干脆什么都没识别出来。原因基本只有一个：语言包没装对。
你要确认三件事。第一，tesseract --list-langs命令的输出里要有chi_sim。第二，pytesseract调用时，lang参数要写成chi_sim，不是chinese，也不是chn。第三，确认你的 Tesseract 是 5.x 版本，4.x 的老版本 LSTM 模型对中文支持要差不少。
如果语言包没问题但识别率还是低，试试把截屏区域放大两倍再做识别，Tesseract 对字号太小的文字识别率会断崖式下降。PIL 里加一行img = img.resize((img.width * 2, img.height * 2), Image.LANCZOS)就能看到明显改善。
4.2 向量检索结果不准确，搜出来的东西不相关
如果你搜“我们上周讨论的数据库方案”，出来的结果却是“数据库备份脚本报错”之类的，别急着怪向量模型。问题多半出在文本切分的粒度上。
OCR 文本天然带排版噪声，比如左侧文件列表、底部状态栏，这些内容会污染整个片段的语义。我的建议是：先在切分前做一次针对性过滤。比如你的工作环境里经常出现“Chrome 书签栏”“Terminal — 80x24”这类固定文本，可以维护一个停用词表，OCR 之后先把这些模式匹配掉。
另一个技巧是提高相似度阈值。sqlite-vec返回的 distance 是越小越相似，你可以根据实测数据画一个分布，看看相关结果和不相关结果的 distance 分界线在哪，然后把阈值设在那里。我自己的场景里，0.5 以下的结果基本可用，0.65 以上的基本就是噪声了。
4.3 磁盘空间被截图塞满，怎么控制体积
截图文件如果以 PNG 格式保留，一张 1440x900 的屏幕截图大概是 2 MB 到 4 MB，一天就能攒出近 2 万张图，硬盘根本撑不住。
我的处理方案是分三级：原始 PNG 只在 OCR 完成后保留 24 小时，超过 24 小时自动转成 JPEG 缩略图（质量 60%，宽度 800px），再超过 7 天直接删除图片，只保留文字片段和向量。毕竟这个系统的核心价值在文字检索，截图只是辅助你查看上下文。数据库里那条time字段就是干这个用的，定期跑一个清理脚本，按时间删除旧图片就行。
4.4 隐私与密码泄露风险，是否要脱敏
最后郑重提一下安全问题。hindsight 记录的是你屏幕上的所有内容，包括你可能在网页表单里输入的密码、聊天软件里发的验证码、文本编辑器里临时粘贴的 Token。如果不做任何处理，这些信息长期躺在数据库里，一旦数据库文件被别人拿到，等于所有密码裸奔。
我的做法是在 store_text 之前加一道脱敏正则，匹配常见的敏感模式：
SENSITIVE_PATTERNS = [ (r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}", "<EMAIL>"), (r"\b\d{11}\b", "<PHONE>"), (r"(?i)\b(api[_-]?key|token|secret|password)\b.{0,20}", "<CREDENTIAL>"), ] def desensitize(text): for pattern, placeholder in SENSITIVE_PATTERNS: text = re.sub(pattern, placeholder, text, flags=re.IGNORECASE) return text这个脱敏方案不是百分百安全，但能过滤掉大部分直接暴露的敏感信息。你再怎么设置密码也架不住手滑，最好的方法是不给明文密码留在索引里的机会。
我在实际使用中还发现一个更隐性的风险点：hindsight 里存的不只是你的信息，还有你屏幕上看得到的别人的信息。比如同事发的文档、网页上展示的陌生人隐私，这些数据同样敏感。所以如果你要把这个项目分享给别人用，记得把脱敏模块做成默认开启的，别让用户觉得“我本地的东西没事”。
4.5 性能与耗电：笔记本用户必须考虑的优化
hindsight 持续跑 OCR 和向量化，CPU 占用会稳定在 20%~30%。对台式机无所谓，但如果你用笔记本，键盘会发烫，风扇会起飞，电池会掉得肉眼可见。
我的解决方案是加一个电源状态监听，只有在接电源时才执行 OCR；电池模式下降级为只截屏，等插电后再统一补处理。这个逻辑在 macOS 上可以通过pmset -g batt解析电池状态实现，Linux 上读/sys/class/power_supply/AC/online就行。
另外，OCR 和向量化可以并行跑。截图是串行采集，处理是并行消费。用 Python 的concurrent.futures.ThreadPoolExecutor开 4 个线程，处理速度能提升 3 倍左右。实测下来 OCR 的数字识别确实快不少，Tesseract 本身会释放 GIL，线程并行有效果。
5. 从背后的想法到可用的工具，我踩过最有价值的几个坎
这项目做到最后，我发现重要的其实不是截图和 OCR，而是“你如何面对自己每天产生的信息”。之前我一直觉得，碎片信息自己会沉淀，想看的时候翻一翻就找得到。事实证明不会。自己做的 hindsight 虽然在技术上还有很多粗糙的地方，但确实能帮我找回不少“脑子里只剩个模糊印象”的旧信息。
依赖本地端到端跑，模型全部用开源，确保数据闭合在自己可控的范围内。坦白讲初期性能不高，但调了几天之后逐渐发现这种模式的不可替代性——系统和系统之间的顺畅感，是云服务给不了的。
有一个很容易被忽略、但实际很影响体验的小细节：时间线浏览界面。检索只是一个入口，有时候你连自己“要找什么”都说不上来，只是想来翻一翻“这周都干了什么”。所以我在查询入口旁边加了一个按时间倒序排列的浏览视图，每行显示“某年某月某日某时 + 文本片段摘要”。这个功能让我用起来舒服很多，也让这个工具真正具有“回看”的自然体验。
我把整个项目的代码量控制在了一千行左右，后续打算再加三个东西：一是把前端从终端命令改成 Web 界面，方便手机上也能查；二是在录入数据时就做增量摘要，这样长时间区间回看的时候，可以直接读摘要，不拖一堆原始文本；三是增加一个“主动遗忘机制”，允许用户对某段时间的数据做永久删除，而不是把数据存在那里永远不碰。
如果你也想复刻一个这样的系统，我的建议是：第一版千万不要贪全，只要能解决“截屏 + OCR + 存文本 + 关键词搜索”这四件事，就已经能带来明显的效率提升。向量检索和大模型回答是后面慢慢加都来得及的优化项。
就个人体验来看，所有碎片化阅读习惯的症结，不在“使用时长”，而在于我们只在意“读过了”的即时感受，从来没有为“顺藤摸瓜”留下后路。hindsight 至少能让你想要那个后路的时候，它还在那里。
