自动化照片初选：3478 张 RAW，只用了 977 次视觉模型调用
文章摘要
作者 NJ 在肯尼亚马赛马拉经营一家旅馆，同时做 AI 工程咨询。他桌上的一块 SSD 里躺着一万两千多张尼康 Z8 拍的 RAW 文件，其中单是去年八月一次客人的 safari 行程就有 3478 张。而这个文件夹里名为 processed 的子目录中只有 13 个 JPEG——其中两张还来自同一帧。换句话说，那趟行程他真正修完并交付的，只有十二张照片。其余的，以及其他几块硬盘上同样形状的文件夹，全都还是未经处理的 RAW。
这篇文章是他五月那篇「用本地模型索引一整年视频」的续集。那次讨论里他自己留言点出了下一个问题：对任何一趟旅程而言，真正的问题是 1500 张里哪 150 张值得处理。这篇就是对那个问题的回答。
核心思路：先分组，再只对代表帧调用模型
他的工具 framedex 原本是视频索引器，为每个片段生成一个纯文本 .description.md 旁车文件，记录 GPS、转录、人脸和一个 keep/review/cull 评级——赌的是「原文件旁边的一个文本文件，比任何应用都活得久」。照片支持在六月加入，七月做了信任机制和 Lightroom 导出。这次新增的关键能力是连拍分组：同一台相机上间隔两秒以内的帧，以及 RAW+JPEG 配对，共享同一次评估结果。
具体流程是：先渲染每个 RAW 的内嵌预览图，用拉普拉斯方差（一个纯本地计算、不需要模型的清晰度指标）给每帧打分，只把组内最锐的那张送给视觉模型。其余帧拿到的是「桩」旁车文件——复制主帧的评估结论，但保留自己的 EXIF 和清晰度分数，并在纯文本里明确写清「模型没有看过这一帧」。
一个 16 张照片的测试样本里，旧流程要做 16 次视觉调用，新流程只用了 4 次：8 张斑马连拍合成 1 次，3 组 RAW+JPEG 配对合成 1 次，两张独立帧各 1 次。
把方法推到整个文件夹
分组只需要 EXIF、不需要模型，所以他以只读方式把分组逻辑指向了全部 3478 个 NEF 文件。exiftool 那一遍耗时 53 秒，给 2886 张预览图打清晰度分在笔记本上花了八分钟。结果是：385 个连拍组覆盖 2886 帧，另有 592 张独立帧，视觉调用数从 3478 降到 977。
作者对自己方法的诚实批评
这篇文章最值得读的部分，是他毫不掩饰地列出方法失效的地方：
- 长链问题：最长的连拍链有 103、62、60 帧。一条 103 帧的链根本不是「一个瞬间」，而是 Z8 以每秒 17 帧连拍、中间停顿不足两秒、跨越了重新构图甚至不同主体。把一个判断复制到 103 个桩上「形状是错的」。他打算给链长或时长加上限，在那之前提供
--no-group开关。 - 清晰度不等于好照片：他亲手修过的十二张里有十一张来自连拍组，而清晰度分数只有一次会选中和他相同的那一帧。在那条 62 帧的链里，他选的两张在清晰度排名中位列第 45 和第 55；另一条 32 帧的链里排第 29。他的结论很干脆——清晰度是决定「哪一帧值得送给模型」的好办法，但完全不是决定「哪一张是照片」的办法。
- 385 组的清晰度跨度中位数是 27%，只有 48 组低于 5%，说明那个「八帧几乎一模一样」的斑马组其实是最容易的特例。
接回 Lightroom，以及 3 星天花板
fdx-xmp 在每个 RAW 旁写 .xmp 旁车文件，把 keep/review/cull 映射成 3 星/2 星/1 星加红标，从不触碰原始文件，而且只覆写那些字节与自己写入内容一致的 xmp，因此不会破坏 Lightroom 自己的 develop 设置。他验证了完整的闭环：在聊天窗口里把某一帧标为 cull，旁车文件重新生成，Lightroom 里执行「从文件读取元数据」后，网格中那张图一分钟内就从 3 星变成 1 星带红标。
关于 3 星天花板，他的理由很清楚：技术性废片（脱焦、运动模糊、过曝、闭眼、误触快门）模型几乎每次都判对，组内近重复也靠分组机制天然解决；但4 星和 5 星的区别模型做不了——每一帧都是孤立判断，没有对他个人品味的记忆，也没有跨整组的一致性，而它对「好构图」的理解就是图库风格的构图。所以顶上那两颗星留给人类。
他还提出了改进方向：模型比较的能力远强于打分的能力，所以下一步应该是把整组的联系表（contact sheet）给模型看，问「哪两张最强」，成本仍是每组一次调用，而且「很难比十一分之一更糟」。另外他手上还有一个多年积累的 Lightroom 目录，里面全是他自己打的星级——那是一个他一直忽略的已标注数据集，一个下午就能测出模型离他的品味有多远。
其他值得注意的细节：fdx-mcp 把整个归档暴露成 MCP 工具（六个工具，核心是一个最多 20 张图的联系表和一个写入用户评级的接口），宿主可以是 Claude Desktop 或搭配本地视觉模型的 LM Studio，framedex 自己完全不调用模型。他也公允地评价了竞品：Lightroom Classic 自带的 Assisted Culling 面板对「在 Lightroom 里挑一次拍摄」是大多数人的正确答案，他的三点批评是——结论无法离开目录（没有一个 2040 年还能 grep 的文本文件）、无法在不重新导入的情况下重跑、以及任何 agent 都无法向它提问。
代码在 GitHub 上（Simbastack-hq/framedex），已发布 0.2.0。他还向读者征集数据：跑一下自己的 RAW 文件夹，把连拍组内的清晰度跨度开 issue 告诉他。
HN 评论精华
这个帖子几乎没有讨论。 提交后只有 3 分、1 条评论。我们已在 Algolia 上按标题和域名搜索，确认不存在评论更多的重复提交帖。
唯一一条回复来自 toomuchtodo：他称赞了这项工作，并提出了一个很实际的问题——把这个能力扩展到 Immich（开源自托管相册方案）上难度大不大。
这条短评其实点中了这个项目最现实的扩展方向。framedex 目前的输出终点是 Lightroom 的 .xmp 旁车文件，而 Immich 作为自托管照片库的事实标准之一，用户群与「本地优先、不上传云端」的理念高度重合。作者在文中反复强调的设计赌注——元数据要以纯文本形式躺在原文件旁边，而不是锁在某个应用的数据库里——恰恰意味着接入 Immich 在理论上只是多写一个导出适配器的事。截至抓取时作者尚未回复。
由于讨论稀少，此处不做额外发挥。读者若对方法本身感兴趣，原文中关于「清晰度分数选不出好照片」和「模型不会打 4、5 星」的两段自我批评，比任何评论区都更有信息量。