總評
Hacker News 的 Show HN 帖「AI search for every photo and every frame of video on macOS」拿到 135 分、64 則留言。主角是開源專案 SCM（Screen Memories）：macOS 本地的照片與影片 AI 搜尋工具，不上雲端、不需帳號。
專案本身評價不差，兩位影片剪輯從業者留言說這對工作有用。但留言區真正吵起來的是兩件事：OCR 不該選 Tesseract，以及這專案看來是 vibe coding 出來的。以下整理兩條主線與其他值得記下的討論。
第一條主線：Tesseract 該換 Apple Vision
postalcoder 開的第一槍：既然只跑 Mac，OCR 就該用 Apple Vision framework，速度與準確度都贏 Tesseract。他還做了個實驗，把貼文標題丟給 Claude、DeepSeek、Qwen、Codex，問它們會推薦什麼技術棧，結果全部推薦 Apple Vision；最後一個還推薦 Tesseract 的模型是 GPT-4.1。言下之意：這選型像出自更早的模型。spiderfarmer 附和：「所以 prompt 大概是：build me x using Tesseract。」
這條主線旁支不斷：
- darepublic 自己實測 Tesseract 表現很不穩，小幅變動就完全失敗；PaddleOCR 單行文字約 95% 準確率。
- vavkamil 講了個對比：模糊的電腦螢幕畫面，用 Astra 讀半天失敗，當晚用手機 Google Lens 圈一下，整段讀出來還滿準。
- robotmay 分享 Apple Vision 的趣聞：同一張圖有正立與倒立文字時，它會把倒立的認成西里爾字母。
作者 allenleee 的回應值得稱讚，直接認了：Apple Silicon 上 Apple Vision 確實更快更準，純 Mac 專案他也會選。選 Tesseract 的理由是可攜性，推論層全程 JavaScript，Transformers.js 加 ONNX 跑 CLIP/SigLIP 與 Whisper、Tesseract.js WASM 做 OCR，全部跑在一般 Node worker 裡，v1 要的就是架構上可攜。他本職是 iOS/macOS 開發，很愛 SwiftUI 與 AppKit，另有一條 Swift 加 MLX 的原生 v2 路線在探索。novok 補充：Apple Photos 資料庫裡其實有一批可直接利用的快取預分析。
第二條主線：vibe coding 老戰爭
nullsanity 一句「這就是 vibe coder 永遠做出劣質軟體的原因」被踩到幾乎隱形，但 daveguy 替他平反：生成的程式碼與最佳實踐是兩套分佈，都來自「最常見」，而最佳實踐很少是最常見的，新建立或冷門領域的實踐尤其如此。
反方陣營的說法：
- thih9：這抱怨太通用了，任何 Electron 專案都會有這場討論，放在這檔專案上偏題。
- baxtr：「誰在乎？只是試水溫、丟出來看大家反應而已。」
- spiderfarmer：反過來說，它也帶來更好的軟體。
- TeMPOraL 描述「最壞情況」：發布 vibe coding 工具，HN 有人留言「你該用 Y 不是 X」，把留言餵給 LLM，LLM 回「他說得對，我馬上換」，發布更好的版本。一個下午完成迭代。
- losteric：大廠與資料供應商花數百萬美元建專家資料集，他曾被以每小時 120 美元請去批改模型產出，那不是網路平均文字分佈。
最狠的一擊來自 radicality：他說作者根本不知道自己在幹嘛、也不知道 CLIP 是什麼，整個專案很可能是一次 prompt 生成後直接推上 GitHub，並指名 screenshot-probe.js「一眼看上去就有邊界條件 bug」。
另有兩發流彈：WokeUp420 酸「原來不經 LLM 也能建東西」；mannanj 直接不看，理由是「不想消費別人的 AI slop 來判斷真假，與其吃別人的不如吃自己的」。
實用關切：到底要跑多久
- stephenitis：最想試但卡在不知要讓電腦跑多久，他的照片庫有 12,000 支影片。
- hn3ufz62f7 做過 CLIP 同類專案，給了最實務的一條：取樣率就是一切。1 秒 1 幀對 12k 影片要跑幾天，只取關鍵幀才壓到一夜。衍生討論包括 proxy 轉碼（pezgordo、Forgeties79）與場景偵測應該比關鍵幀更稀（xnx）。
- Jeeetendra 問 balanced 取樣多久會漏掉只出現一兩秒的畫面，作者未回。
- measure2xcut1x 問 M1 32GB 行不行，作者確認 M1/M2/M3（16g/64g）都能完美運作。
- tredre3 提 Apple Photos 本來就能自然語言搜圖，提問者回：照片在外部 SMB 網路碟，用不上。
其他討論
| 議題 | 內容 |
|---|---|
| JS/Electron vs 原生 | cpursley 問為何是 JS bloatware 不用 Rust；collingreen 反打「LLM 什麼都能做」兩邊都適用，你覺得不值得花時間就別叫別人花。延伸討論期望出現 AI 友好又高效的新 UI 範式；ryandrake 期望 LLM 讓人從此不必再寫 Electron |
| 功能需求 | qprofyeh 問能否搜人臉與寵物；freecodeio 夢想相機直接把 embedding 寫進檔案，collingreen 指出那會被單一模型綁死 |
| 競品 | lucideer 推跨平台的 Immich；mannyv 吐槽 Immich 的縮圖策略與檢視選項，最後一句「我乾脆讓 Gemini 一個週末寫個 DAM」。ryandrake：討厭軟體強加目錄結構 |
| 版權跑題 | alt227 問 LLM 時代創意會不會被大廠直接抄；共識是版權保護程式碼文字、不保護功能，Sherlock 化不侵權 |
| 正面回饋 | 兩位影片剪輯者說對剪輯有用；有人問貴不貴，作者回：100% 免費開源 |
對專案的三個啟示
- OCR 換 Apple Vision 是共識級建議，作者已認，v2 原生路線等於間接答應了這件事。
- 最痛的缺口是效能透明度。多人問常見場景要跑多久，README 的取樣預設檔有時間與磁碟成本，但缺實測數字。
- screenshot-probe.js 被點名，值得實際看一眼有沒有邊界 bug。