Hacker News 中文摘要

RSS订阅

Show HN：macOS 上的 AI 搜索，覆盖每张照片和视频每一帧 -- Show HN: AI search for every photo and every frame of video on macOS

原文链接 | HN讨论 | 2026-10-05 04:30:25

屏幕记忆（SCM）在macOS上对任意文件夹中的每张照片和视频每一帧进行深度AI搜索，本地优先，无账户无云无上传，推理在Mac运行。它支持用自然语言描述记忆来搜索，本地视觉模型处理；视频精确到镜头，场景分割嵌入；通过OCR搜可见文本，Whisper搜台词；可存查询为标签，截图与邮件标签可切换。媒体从不离开设备，权重仅下载一次，之后离线。

正文

SCM 预览图

SCM — Screen Memories

macOS 上对任意文件夹里每张照片、每帧视频的深层 AI 搜索。本地优先——无账号、无云端、无上传。推理在你的 Mac 上运行。

有何不同 - 像思考一样搜索——用自然语言描述记忆，本地视觉模型搞定其余。 - 视频精确到瞬间——场景被分割并向量化，让你定位某个镜头而非整个文件。 - 文字与对白也行——对可见文字做 OCR；通过 Whisper 精确搜索说出的台词，各自独立成模式。 - 你的标签页，你的提示词——任何查询可存为标签页；截图与邮件标签页可开关。 - 自维护媒体库——监听文件夹自动导入，内容哈希对重命名去重，切换模型时在后台重向量化且不阻塞搜索。 - 真正私密——媒体从不离开本机。权重仅下载一次，之后完全离线。

五种搜索方式

搜索模式：文件、场景、对白、OCR、LLM

| 模式 | 找到 | | --- | --- | | 文件 | 按语义找整张照片/视频——视觉排序结合文件名与短语加权 | | 场景 | 视频内的瞬间——搜索镜头，跳到时间码 | | OCR | 图片与帧中可见文字，逐字匹配（Tesseract；英文+35种可开关语言） | | 对白 | 视频中确切说出的词（Whisper），分精确等级 | | LLM（可选） | 针对 Mac 已提取的对白、OCR 和文件名做本地问答——带引用答案 |

要求

  • macOS（electron-builder 打包；菜单栏/托盘仅限 macOS）
  • Bun——项目用 bun 作为包管理器与运行器
  • 安装 Node 模块：bun install
  • 首次使用模型下载权重（默认 CLIP 约 435MB）；之后完全离线。

下载

最简便通过 Homebrew 安装（Apple Silicon, macOS 12+）。该 tap 的 cask 每次安装升级自动清除 macOS 隔离标志，无需手动 Gatekeeper：执行 brew tap allenv0/scm、brew trust allenv0/scm、brew install --cask allenv0/scm/scm。升级同理：brew upgrade --cask allenv0/scm/scm。想最小授权只信任 cask：brew tap allenv0/scm、brew trust --cask allenv0/scm/scm、brew install --cask scm。tap 位于 allenv0/homebrew-scm。

开发

开发命令：bun run dev 构建渲染包并启动 Electron；bun start 不重建直接启动；bun run build 仅重建渲染包到 dist/。

构建应用包 (DMG / ZIP)

bun run dist 若钥匙串有证书则签名；bun run dist:unsigned 跳过签名检测。依次运行两步： 1. vite build——将 React 渲染器编译进 dist/（接管 src/ 下改动）。 2. electron-builder --mac——打包应用，捆绑新鲜 dist/ 与 main.js、preload.js、main-lib/、indexer/（文件列表在 package.json 的 build.files），生成安装器。 输出位于 dist-app/（见 package.json 中 build.directories.output）——找 SCM-0.2.4.dmg 与 SCM-0.2.4.zip。

功能

文件

输入触发文件名关键词预筛，随后视觉模型接手：结果按图像向量余弦相似度评分，带受限短语与文件名加权、按模型校准的诚实下限、近重复多样性过滤。每个方块带“为何匹配”徽章及悬浮分项分数。CJK 查询以重叠二元组搜索（“台北車站”也匹配台北、車站）。

场景

所有视频每个场景片段参与评分，命中即落精确镜头：方块显示带时间码徽章的场景海报，打开视频直跳该时刻。噪声门控返回“无场景匹配”而非刷屏，每视频最多贡献 3 场景。

OCR

按查询词在图像 OCR 文本中逐字可见比例匹配——忽略文件名且不调视觉模型，AI 预热或离线也能用。匹配词在方块和灯箱用琥珀色框出。

对白

基于 Whisper 转录的逐字检索——无向量无阈值，引擎宕机也能用。结果分三级：精确台词（单句连续短语）、精确词（单句或 ≤8秒窗内所有词）、已说词（同视频内所有词）。匹配词高亮，打开直跳该行。

LLM（问答）

可选——设置→LLM 聊天启用前不下载不运行。绑定回环的 llama.cpp 边车基于已提取证据（对白、OCR、文件名）回答，带可点击编号引用，逐 token 流式与实时 tok/s。前置 /screenshots、/videos、/email 收窄语料；停止保留部分答案；证据空则短路。

| 聊天模型 | 大小 | 说明 | | --- | --- | --- | | Qwen3 1.7B（默认） | ~1.1GB | 快速日常；适配 8GB Mac | | Llama 3.2 3B | ~2GB | 更强长答案；需余量 |

标签页与媒体库视图

  • 内置浏览标签页：全部、视频，外加可开关的截图与邮件（设置→智能标签页）。选视频自动启场景模式。
  • 查询存为标签页：搜索栏下保存当前提示及模式（文件/场景/OCR/对白）——最多 20 个可重命名精确还原。
  • 可重映射快捷键后五种语义视图（默认 ⌘1–⌘5），加 ⌘I 导入/AI 洞察，⌘, 设置。
  • 搜索留在所选标签页：选截图、邮件、视频或保存标签，结果过滤到它——先范围后搜索。LLM 聊天同理前置指令收窄。

邮件标签页

浮出可见 OCR 含电邮地址的照片——重叠视图（照片保留原分类）。检测容错 OCR：重组跨词框碎开地址，处理逗号代点（“gmail,com”）、分裂 TLD（“gmail. com”）、括号混淆（“allen [at] gmail [dot] com”）及口述（“allen at gmail dot com”）。方块显联系人条，展开可复制撰写。

截图标签页

截图分类抗重命名。四信号按优先级：手动覆盖（右击）→ 文件名词汇（20+ 语 30+ 本地化名）→ PNG/JPEG 元数据探测（读“screenshot”，故重命名 Bildschirmfoto 仍分类）→ 源文件夹提示。其余归项目。

视觉模型

ONNX Runtime 切换四模型；按库选活跃：

| 模型 | 角色 | 速度(CPU) | 下载 | | --- | --- | --- | --- | | CLIP ViT-L/14@336（默认） | 最佳现实视频场景搜索 | ~480–570ms/图 | ~435MB | | SigLIP-2-B/16 | 最快批量导入 | ~50–100ms/图 | ~412MB | | SigLIP-2-L/16@256 | 高细节（1024维）——小物体、标牌、屏文 | ~200ms/图 | ~850MB | | SigLIP-B/16@384 | 最大细节 | ~480ms/图 | ~214MB |

切换模型重向量化全库：翻转瞬时生效尾部后台填，搜索退化为文件名关键词至完成。按模型文本均值中心化消除偏置使跨模型分诚实。

视频搜索流水线

ffmpeg 扫镜头边界，按设置→视频搜索密度建分段计划——预设提交前显实测时间与磁盘成本：

| 预设 | 每点秒数 | 分段预算 | | --- | --- | --- | | 节能 | 60 | 4–32 | | 均衡（默认） | 30 | 8–128 | | 详细 | 15 | 12–256 | | 极致 | 5 | 16–1024 | | 极致 Pro | 2.5 | 24–2048（需确认） |

每段向量化中心帧留海报；镜头计划按文件缓存（路径+大小+mtime+配置指纹），重导入跳检测。

对白转录： Whisper tiny.en（~150MB 默认）或 base.en（~300MB）——切换重转录每视频。整视频向量化三帧（20/50/80%）平均；GIF 向量化中帧平均。

OCR

Tesseract 在独立 worker，与视觉模型分离。英文常开；35 语可在设置→照片搜索开关（默认简繁中、日、韩）。每语言包下一次（~2.4–5MB；默认集 ~17MB）后离线。词框随文本存以便就地高亮；CJK 无空格连，跨框邮件片段重组。

导入与媒体库管理

  • 通过 ⌘I、拖放或监听文件夹导入——导入即监听（实时 fs.watch 加启动重同步）。问题文件重试 3 次后退出同步至改动。
  • 抗重命名去重：复制前内容哈希（SHA-256），MIME 嗅探规范化谎报扩展名。
  • 命名向量化版本（设置→媒体库）：可搜索状态时间点快照——索引、各模型向量桶、场景与转录边车——带还原（先自动备份）和危险区。上限 10。
  • 一切位于 ~/Library/Application Support/scm（MEMORIESDATADIR 可覆盖）：索引 JSON、每模型 Float32 向量桶、边车、缩略图、海报。

构造即隐私

  • 渲染器沙盒 app:// 包——contextIsolation、OS 沙盒、CSP 锁 'self'（加 Google Fonts CDN 显示字体，离线等宽回退）。
  • 仅主进程 worker 下载每物一次：视觉权重（Hugging Face）、OCR 包（Tesseract CDN）、Whisper 权重，及选时 llama.cpp 边车与 GGUF（GitHub + Hugging Face），下载 sha256 校验。
  • 媒体复到应用库从磁盘流式。无遥测无账号无上传。

设置与润色

macOS 风格设置十页（库、外观、网格、智能标签页、照片搜索、视频搜索、LLM 聊天、全局快捷键、键盘、菜单栏）。核心外：浅深系统主题、灯箱 CRT 效、6 备用图标、仅菜单栏模式、可录全局快捷键、首次导览、后台托盘（场景/转录/OCR）带全局暂停、状态栏含版本与已索引视频数。

说明

  • 首次构建慢： electron-builder 首次下 Electron 与 ffmpeg 一次；后续快。
  • 代码签名： 无 Apple 身份则 DMG 未签。仍本地跑，但 macOS 可能首次需右击打开。
  • 重建拾改动： main.js、preload.js、main-lib/、indexer/ 从源打包非缓存，编辑后 bun run dist 产新鲜包。

测试

测试命令：bun run test:all 跑完整验证；bun run smoke:indexer 做 CLIP 无头冒烟；bun test test/ 跑单元；bun run lint 与 bun run format:check 做检查。 - 单元覆盖纯核：排序、对白精确匹配、CJK 令牌、Whisper 阶梯、MIME 嗅探、转录融合等。 - E2E 冒烟在 Electron 内通过 ELECTRONSMOKE* 跑——十几个场景从启动到搜索矩阵、模型迁移、问答（驱动 scripts/e2e/，分派 main.js；如 smoke:ask、smoke:deep、smoke:grid）。 - 基准： bun run bench:inference、bench:enrich、bench:detect 写 JSON 进 MDs/bench-*。

项目布局

项目布局：main.js 为 Electron 主进程，处理库、IPC、索引器 worker 池与 app:// 协议；preload.js 通过 contextBridge 暴露 window.memories；main-lib/ 含主进程模块（设置、库存储、排序搜索、问答检索、LLM 边车、向量版本等）；indexer/ 含视觉/OCR/ASR worker、视频工具与模型注册表；src/ 为 React 渲染器（网格、搜索模式、灯箱、标签页、设置、导览）；scripts/ 含基准、E2E 驱动与冒烟；test/ 含单元集成测试；MDs/ 含文档报告计划；dist/ 为 vite 输出；dist-app/ 为 electron-builder 输出。

评论

讨论整体认可「按内容搜视频/照片」这个方向，但分歧集中在可用性上：多数人追问索引大型素材库究竟要多久、采样策略会不会漏内容，技术选型则分成 CLIP、小 VLM、Apple Vision、原生/Rust 几派；少数人对产品页面本身就是 AI 生成这件事持保留态度。

索引耗时才是能否落地的门槛

  • 想试但不敢试，核心顾虑是不清楚处理大型视频文件夹、照片库（比如 1.2 万个视频）要占用电脑多长时间（较多人）
  • 有做过类似项目的人指出，帧采样率决定一切，采样密了就按天算，只取关键帧才能压到一夜跑完（高赞）
  • 有人问一部 90 分钟全高清素材要跑多久，讨论里并没有给出答案（少数人）
  • 顺带被问到成本是否昂贵，说明运行开销同样是决策因素（少数人） > 在 M1 上跑 1.2 万个视频，每秒采一帧要花好几天，只取关键帧才能压到一夜跑完。（@hn3ufz62f7）

采样策略会不会漏掉一闪而过的画面

  • 认为「直接跳到视频里正确的时刻」才是真正的价值点，但怀疑均衡采样会漏掉只出现一两秒的内容（较多人）
  • 这构成一个没被解决的张力：想要不漏，就得提高采样率，可索引时间又承受不起

应该改用 Apple Vision 做 OCR，而不是 Tesseract

  • 既然面向 Mac，就应该用 Apple 的 Vision 框架，它在速度和准确度上都明显优于 Tesseract（较多人）
  • 一个反直觉的补充：把标题喂给各家大模型问技术栈，它们居然一致推荐 Apple Vision，最晚还在推荐 Tesseract 的是 gpt-4.1（少数人） > 在 Mac 上，Apple 的 Vision 框架在速度和准确度上都完胜 Tesseract。（@postalcoder）

质疑 CLIP 未必是合适模型

  • 认为小规模视觉语言模型（如 Qwen-VL）自带视频编码器，在这个场景可能表现更好，值得一试（少数人）

想要更接近相册级的体验

  • 希望支持按人物、人脸、宠物搜索，像 iOS 那样（较多人）
  • 有人推荐 Immich，作为跨平台、更整体的替代方案，能对照片和视频做近似的 AI 搜索，但不保证逐帧，也不保证搜索质量可比（较多人）
  • 有人设想在 M1、32GB 内存上拿约 2000 张图库做「棕榈树旁的房子」「厨房」「西南沙漠景观」这类检索（少数人）

不信任 AI 生成的页面内容

  • 认可项目本身，但因为介绍页面像是 AI 写的就不打算用，理由是没兴趣消费别人的「AI 泔水」来判断真假，宁可自己用 AI 做一个（少数人） > 不想靠别人的 AI 泔水来判断真假，我宁愿吃自己做的。（@mannanj）

技术栈选型批评：JS 臃肿，应该写原生或 Rust

  • 既然现在有大模型辅助编码，写原生或 Rust 比以往都容易，没必要做成 JS 臃肿软件（少数人）

偏离主题：大模型时代的「抄袭」边界

  • 提出疑问：过去小公司有好点子会被大厂收购整合或做掉，现在 OpenAI 之类能否直接让模型产出功能类似的东西，从而绕开抄袭问题、也不至于落后（少数人）

有价值的补充

  • 有人希望相机拍摄时就能把图片嵌入向量写进文件，并坦言这只是梦想
  • Immich 被点名为跨平台的现成参照，但明确不覆盖逐帧索引，也不保证搜索质量对等
  • 关于 OpenAI/大模型复刻创意的版权疑问，属于话题外延伸，没有形成结论