屏幕记忆不靠截图：纯文本转Markdown的轻量方案

一种轻量的屏幕记忆方案

在 Hacker News 的 Show HN 板块，一个名为「Screen memory without screenshots, just text to Markdown」的项目引发了关注。它提出了一个与主流屏幕记忆工具截然不同的思路：不依赖截图，而是直接将屏幕上的文本内容提取并保存为 Markdown 格式。

近年来，随着微软 Recall、Rewind 等个人记忆助手类产品的兴起，屏幕记忆逐渐成为热门赛道。微软 Recall 是 2024 年随 Copilot+ PC 发布的功能，通过每隔数秒对屏幕截图并利用本地 AI 模型建立语义索引，让用户可以用自然语言回溯任何曾在屏幕上出现的内容——该功能发布后因隐私争议曾被推迟上线。从技术架构看，Recall 基于 NPU（神经处理单元）加速的本地推理，利用 Windows 内置的 AI 模型对截图进行语义编码，生成向量嵌入后存储在本地加密数据库中。NPU 是专为矩阵运算和张量计算优化的协处理器，与传统 CPU 和 GPU 相比，在低功耗条件下执行推理任务时具有显著优势——高通骁龙 X Elite、Intel Meteor Lake 和 Apple M 系列芯片都集成了 NPU 单元。NPU 的核心优势在于其针对稀疏矩阵运算和低精度整数计算的专用电路设计。与 GPU 的 SIMT（单指令多线程）架构不同，NPU 通常采用脉动阵列（Systolic Array）或数据流架构，减少数据搬运的能耗开销。微软选择 NPU 而非 GPU 进行本地推理，核心考量是功耗效率：NPU 在执行 INT8/INT4 量化模型推理时，每瓦性能可达 GPU 的 3-5 倍，这对于需要持续后台运行的屏幕记忆应用至关重要。Copilot+ PC 要求设备 NPU 算力达到 40 TOPS 以上——意味着设备每秒能执行 40 万亿次整数运算，这对于运行 INT8 量化的小型 transformer 模型（如 BERT-base 的 1.1 亿参数）已绰绰有余，确保了 Recall 能在不显著影响电池续航的前提下完成实时语义编码。

向量嵌入（Vector Embedding）是 Recall 等工具实现语义检索的核心技术——它将文本或图像转化为高维数值向量，使得语义相似的内容在向量空间中距离接近。嵌入向量的维度通常在 384 到 1536 之间，例如 OpenAI 的 text-embedding-3-small 输出 1536 维向量。用户进行自然语言检索时，查询语句被编码为向量，通过余弦相似度（计算两个向量夹角的余弦值，值域为 [-1,1]）或近似最近邻（ANN）算法快速找到语义最相关的历史记录。ANN 算法（如 HNSW、IVF-PQ）通过牺牲少量精度换取数量级的速度提升，使得在百万级向量库中的检索延迟降至毫秒级——这对于积累了数月屏幕记录的个人记忆库尤为关键。

其隐私争议的核心在于：即使数据存储在本地，持续截图仍可能捕获密码输入、私密聊天、金融信息等敏感内容，且早期版本的数据库加密机制被安全研究员发现存在漏洞。Rewind（后更名为 Limitless）则是一款第三方个人 AI 助手，同样采用持续截图加 OCR 的方式记录用户活动，并结合会议录音等多模态数据构建个人知识库。Rewind 在 macOS 上利用系统级的屏幕录制权限，以压缩视频流而非独立截图的形式存储数据，配合本地 Whisper 模型进行音频转录，构建跨模态的个人记忆索引。这两款产品共同验证了市场对个人记忆助手的需求，但也暴露了截图方案在隐私合规、存储膨胀和计算开销方面的结构性难题。它们代表了「个人计算全量记忆」的产品范式，其核心假设是：如果能记录一切，AI 就能帮你回忆一切。

这类工具的核心目标是记录用户在电脑上看到、做过的一切，方便日后通过自然语言检索。然而，主流方案几乎都采用了「持续截图」的技术路径——每隔几秒对屏幕截图，再通过 OCR 或多模态模型进行内容识别。OCR（Optical Character Recognition，光学字符识别）是将图像中的文字转换为可编辑文本的技术，传统引擎如 Tesseract 依赖规则和模式匹配，而现代方案越来越多地采用深度学习模型。多模态模型（如 GPT-4V、Gemini）则更进一步，不仅能识别文字，还能理解图像中的布局、图表、UI 元素等语义信息。在屏幕记忆场景中，截图方案需要依赖这些技术将像素级信息转化为可检索的语义数据，这一过程本身就引入了额外的计算成本和识别误差。以 Tesseract OCR 为例，处理一张 1080p 截图通常需要 200-500ms 的 CPU 时间；如果使用更精确的深度学习 OCR 引擎（如 PaddleOCR、EasyOCR），虽然识别准确率提升到 95% 以上，但单帧处理时间可能增加到 1-2 秒，且需要 GPU 加速。多模态大模型的推理成本则更高——即使在本地部署量化版本，每帧处理也需要数秒。这意味着如果每 5 秒截一张图，系统需要维持接近实时的推理管线，对笔记本电脑的电池续航和散热都构成显著压力。

部分方案通过帧间差异检测（只在屏幕内容变化时才触发处理）来缓解这一问题。帧间差异检测的基本原理是将当前帧与前一帧进行像素级比较，计算变化区域的面积占比或均方误差。更高级的实现会结合感知哈希（pHash）——将图像压缩为 64 位或 256 位的指纹值，通过汉明距离快速判断图像相似度，避免因压缩伪影或微小渲染差异导致的误触发。感知哈希的工作原理是将图像缩小到固定尺寸（如 32×32），进行离散余弦变换（DCT）后取低频分量生成指纹。两张图像的汉明距离小于阈值（通常为 10/64 位）即判定为相似。工程实践中还会结合平均哈希（aHash）和差异哈希（dHash）构建多级过滤管线，先用计算量小的 aHash 快速排除明显不同的帧，再用 pHash 做精确判断。但这些优化在用户快速滚动网页、播放视频或进行代码编辑时效果有限，因为几乎每帧都会产生显著变化，且引入了额外的工程复杂度。

这个项目反其道而行之，主张用纯文本捕获替代图像捕获，在存储效率、隐私安全和可检索性上寻求突破。

为什么放弃截图选择纯文本？

存储与性能的现实考量

持续截图最直接的问题是存储成本。一张全屏截图动辄数百 KB 到数 MB，若以每几秒一张的频率长期记录，磁盘占用会迅速膨胀到数十甚至上百 GB。而纯文本的体积几乎可以忽略不计——同样的信息量，Markdown 文本可能只占截图的千分之一。

此外，截图方案还需持续调用 OCR 或视觉模型来「读懂」图像内容，这会带来可观的 CPU/GPU 开销，甚至影响电池续航。直接抓取文本则绕开了这一环节，从源头获取结构化信息，处理链路更短、更省资源。

隐私保护与数据可控性

截图本质上是对屏幕的无差别记录，包含大量视觉冗余信息，也更容易在无意中捕获敏感画面。相比之下，文本提取更容易做精细化的过滤和脱敏——用户可以更清楚地知道系统究竟记录了什么，也更方便对内容进行编辑、删除或分类。

Markdown 作为开放、可读的纯文本格式，天然具备可移植性和长期可维护性，不会像专有的图像数据库那样形成数据锁定。

Markdown 作为记忆载体的独特价值

选择 Markdown 而非纯 TXT 或 JSON，是这个项目值得关注的设计决策。Markdown 由 John Gruber 于 2004 年创建，是一种轻量级标记语言，使用纯文本符号（如 #、*、- 等）表示文档结构。其最大优势在于人类可读性与机器可解析性的平衡——既可以用任何文本编辑器直接阅读和编辑，又能被程序解析为结构化的文档树。

Markdown 的影响力已远超其最初作为博客写作工具的定位。GitHub 于 2009 年将 Markdown 作为 README 和 Issue 的默认格式，直接推动了其在开发者社区的普及。此后，Notion、Obsidian、Logseq 等知识管理工具都以 Markdown 为核心存储格式，形成了庞大的工具生态。值得注意的是，Markdown 最初的规范相当松散，导致不同解析器对边界情况的处理不一致。2014 年，Jeff Atwood 等人发起 CommonMark 项目，试图建立严格的 Markdown 规范。GitHub Flavored Markdown（GFM）是 CommonMark 的超集，增加了表格、任务列表、删除线等扩展语法。这种生态碎片化对屏幕记忆项目的影响在于：从不同应用提取的文本需要统一的格式化规则，否则后续的解析和检索可能出现不一致行为。选择哪种 Markdown 方言、如何处理格式化边界情况，是工程实现中需要明确的设计决策。

在 AI 领域，CommonCrawl 和 The Pile 等主要训练数据集中包含大量 Markdown 格式内容，这使得 LLM 对 Markdown 语法有着近乎原生的理解能力。此外，Markdown 的扩展变体如 MDX（支持嵌入 JSX 组件）和 Markdoc 正在成为技术文档的新标准，进一步巩固了其作为结构化文本通用格式的地位。

Markdown 在保持纯文本轻量特性的同时，还保留了基本的结构信息——标题、列表、链接、代码块等。这意味着提取出的屏幕内容不仅是一堆文字，而是带有语义层级的结构化记忆。

这一点对于后续的检索和 AI 处理尤为关键。在 LLM 时代，Markdown 已成为模型训练数据和输出的事实标准格式，几乎所有主流大语言模型都对 Markdown 有极好的理解和生成能力，这使其成为 AI 处理管线中理想的中间表示格式。在 RAG（检索增强生成）系统中，Markdown 的层级结构（标题层级、列表嵌套）为文档分块（chunking）提供了天然的语义边界。RAG 的核心流程是将文档切分为语义完整的片段，为每个片段生成向量嵌入，检索时找到与用户查询最相关的片段，将其作为上下文注入 LLM 的提示词中。分块策略直接影响检索质量：按固定字数切分（如 512 token）可能将一个完整概念拆散；而 Markdown 的层级结构提供了天然的语义分割点——一级标题标记主题边界，二级标题标记子话题，列表项通常是独立的信息单元。LangChain 和 LlamaIndex 等框架都内置了 Markdown 感知的分块器（MarkdownTextSplitter），能自动按标题层级递归分割文档，保持每个片段的语义完整性。相比纯文本按字数切分，这种方式能显著提升检索召回率和生成质量。

除了基于结构的分块，业界还发展出更精细的策略：递归字符分块（设定多级分隔符优先级，如先按标题分、再按段落分、最后按句子分）、语义分块（通过计算相邻句子嵌入向量的相似度变化检测语义边界，当相似度骤降时切分）和父子文档策略（检索小片段以保证精确匹配，但向 LLM 提供包含上下文的大片段以保证理解完整性）。Token 预算也是关键约束：虽然 GPT-4 的上下文窗口已达 128K token，但研究表明将最相关的内容放在上下文的开头和结尾能获得最佳生成质量——这就是所谓的「Lost in the Middle」现象，即模型对上下文中部内容的关注度较低。因此，检索阶段返回的片段排序策略同样重要。结构化文本能显著提升检索与问答的准确度。相比对着一张截图做视觉推理，直接输入一段干净的 Markdown，无论在成本还是效果上都更具优势。

可以说，这个项目押注的是一个趋势判断：在大语言模型时代，文本才是最通用、最高效的记忆媒介，而图像更多是文本无法覆盖时的补充手段。

纯文本方案的局限与挑战

纯文本路线并非没有代价。屏幕上并非所有信息都能以文本形式提取——图表、图片、视频画面，以及部分使用 Canvas 或自绘 UI 的应用，其内容往往无法通过常规文本抓取获得。

HTML5 Canvas 的设计哲学是「即发即忘」（fire-and-forget）：JavaScript 通过 2D 或 WebGL 上下文向画布写入像素，但画布本身不维护绘制内容的语义信息。这意味着即使一个 Web 应用在 Canvas 上绘制了大量文字（如 Google Docs 的编辑器在某些模式下使用 Canvas 渲染、Figma 的整个界面基于 WebGL），外部程序也无法通过 DOM 查询获取这些文字内容。Google Docs 为解决无障碍问题，在 Canvas 层之外维护了一个隐藏的 ARIA 文本层，但并非所有 Canvas 应用都做了这样的适配。桌面端情况类似：Unity、Unreal 等游戏引擎，以及 Flutter（Google 的跨平台 UI 框架）默认使用 GPU 直接渲染所有 UI 元素，不通过操作系统的原生控件体系。Flutter 在 2021 年才开始逐步改善其桌面端的 Accessibility 支持，至今仍有诸多限制。在这些情况下，屏幕上可见的「文字」实际上只是像素图案，无法通过 Accessibility API 或 DOM 解析获取，只能退回到截图加 OCR 的路径。这是纯文本屏幕记忆方案最根本的覆盖盲区。在这些场景下，截图方案反而具备天然优势。

从技术实现看，跨应用、跨平台地稳定抓取屏幕文本本身也是一大挑战。该项目的文本提取很可能依赖操作系统提供的 Accessibility API（无障碍接口）——这是操作系统为辅助技术（如屏幕阅读器）提供的编程接口，允许第三方程序读取当前 UI 元素的文本内容、层级结构和状态信息。macOS 的 AX API 通过 Core Foundation 框架提供，应用需要在 System Preferences 中被授予辅助功能权限才能调用；Windows 的 UI Automation 是 .NET 框架的一部分，支持模式匹配和事件订阅，其架构分为 Provider（应用端实现）和 Client（消费端调用）两侧，通过 COM 接口通信，支持多种控件模式（Control Pattern），如 TextPattern 允许程序获取文本内容及其格式属性；Linux 的 AT-SPI（Assistive Technology Service Provider Interface）基于 D-Bus 消息总线，理论上支持任何 GTK/Qt 应用，但实际覆盖率受桌面环境和应用适配程度影响较大，且 Wayland 显示协议对屏幕读取的安全限制比传统 X11 更为严格。

操作系统对 Accessibility API 的访问施加了严格的权限控制，这既是安全保障也是技术限制。macOS 自 10.9 起引入了 per-app 的辅助功能权限授予机制，应用必须在系统偏好设置中被用户显式授权才能调用 AX API，且该权限会在应用更新后被重置。Windows 的 UI Automation 虽然不需要类似的显式授权，但在 UAC（用户账户控制）高完整性级别的进程中运行时，低完整性级别的程序无法读取其 UI 元素——这意味着以管理员权限运行的应用对普通权限的屏幕记忆工具不可见。此外，某些安全软件和 DRM 保护的应用会主动禁用或欺骗 Accessibility 查询，以防止敏感信息泄露。

通过这些接口，程序可以直接获取窗口中的文本，而无需对屏幕截图再做 OCR。然而，各平台实现差异大，且部分应用（特别是使用自定义渲染引擎的游戏、Electron 应用的某些组件、Canvas 绑定的 Web 应用）可能不暴露完整的文本信息，导致抓取覆盖率不稳定。Electron 是基于 Chromium 和 Node.js 的跨平台桌面应用框架，VS Code、Slack、Discord、Notion 等大量主流应用都基于 Electron 构建。Chromium 的 Accessibility 实现将 DOM 树转换为平台原生的 Accessibility 树（AXTree），但这一转换的质量完全取决于 Web 内容的语义化程度：如果开发者大量使用 div+CSS 布局而不使用语义化 HTML 标签和 ARIA 属性，生成的 Accessibility 树会丢失大量结构信息。Electron 在 v9 之后默认启用了 Accessibility 支持（此前需手动开启），但仍存在已知问题：WebView 嵌套场景下的树合并困难、Web Worker 中动态更新的内容可能延迟同步到 AXTree 等。此外，虚拟列表（Virtual Scrolling）这一现代 Web 应用中极为常见的性能优化技术，只渲染视口内可见的列表项，导致 Accessibility API 只能获取当前可见的少量内容而非完整列表。许多 SPA（单页应用）在 Accessibility 方面的实现并不完善，导致通过 Accessibility API 获取的文本可能不完整或结构混乱。因此，这类工具的实际覆盖率和可靠性，很大程度上取决于底层实现的工程质量。

该项目目前在 Hacker News 上获得少量关注，社区对其具体实现细节和覆盖范围仍在观望。想法新颖，但能否落地为一款好用的产品，仍需时间验证。

小结：屏幕记忆的另一种可能

这个项目提供了一个值得深思的反向视角：在屏幕记忆几乎被截图方案垄断的当下，回归纯文本或许是一条更轻量、更快速、更隐私友好的道路。它不一定能取代截图方案，但很可能成为更适合开发者、写作者等以文字为主要工作媒介的人群的选择。

在 AI 记忆助手日益普及的趋势下，「记录什么」和「怎么记录」的问题变得越来越重要。文本转 Markdown 的思路，正是对这一命题的一次有价值的探索。