39张截图没一个能搜，他用本地Gemma自动改名

截图文件夹里躺着39个文件，三种命名格式混在一起，因为它们是从一台Linux笔记本上迁移过来的。没有一张图的名字能说明图里是什么。要找某张截图，只能一张张打开缩略图翻。

这是开发者omlahore在Hacktoberfest开源AI挑战赛第三周提交的项目slothshot要解决的问题。它用本地视觉模型给每张截图重新命名：Screenshot 2026-10-03 at 08.15.44.png 变成 2026-10-03 railbook-e-ticket-pnr-4421907736.png，日期留在最前面，文件夹依然按时间排序，后面的词则说明画面内容。

手工改名当然能解决，但他一直没动手。于是现在由跑在笔记本上的视觉模型逐张看图，挑出名字：应用或网站，加上屏幕上那个具体的东西。

怎么跑起来

模型是Gemma 4 E4B，谷歌的开源权重模型，量化到4位（ggml-org的Q4_0 GGUF），由llama.cpp的llama-server在本地端口提供服务。命令行工具约230行Go代码，只有一个依赖golang.org/x/image，用来缩放图片。

每个文件的处理流程分三步：

• 用正则判断文件名是否为默认截图名（macOS、GNOME、Flameshot、Android、CleanShot）。已经被改过名的文件日期后面带词，不会再匹配，所以跑第二遍什么也不会发生。
• 图片长边缩放到1536像素，发到llama-server兼容OpenAI的接口，提示词很短：3到6个词，只有应用名出现在屏幕上才写应用名，必须包含具体内容（报错、商户和金额、页面标题）。
• Go把回答转成slug：小写、连字符、最多六个词。名字被占用就加-2。每次改名都追加到.slothshot.tsv。

默认是试运行，只打印新名字。-apply 执行改名，-undo 从日志文件把旧名字全部还原，-watch 1m 让它常驻，每张新截图拍下后一分钟内拿到名字。

两个坑

第一次跑，所有回答都是空的。Gemma 4默认先思考再回答，max_tokens设成40时，全部额度都花在了"Thinking Process: 1. Analyze the Request"上。传入 chat_template_kwargs: {"enable_thinking": false} 关掉思考，回答大约一秒返回。

第二个坑更麻烦。在1024像素下，模型把PNR 4421907736读成了44197736，少了两位。文件名里写错PNR比不写更糟——你搜正确的号码，它不在那里。1536像素下十个数字全部读对。每张图耗时从1.3秒涨到约2.5秒，但一个文件只改一次名，他选了慢而正确的版本。

它并不完美

它把SanDisk拼成了"sandsik"。在一张Go测试截图上，它写的是"test-monthly-rollup-fail"，漏掉了真正的panic信息，而那恰恰是他会去搜的词。在自己的文件夹里，它把一张纯黑截图命名为the-image-provided-is-completely-black，倒是准确。

大部分正确的名字，仍然比 Screenshot 2026-10-16 at 16.30.00.png 好搜。

为什么不上云

在看到slothshot给自己文件夹提的名字之前，他没把截图文件夹当成隐私重地。里面有和朋友的聊天、有别人出镜的视频通话、还有几个登录页面。用托管API命名，意味着把这些全部上传，开着-watch的话，每张新的也要传。

Gemma跑在llama.cpp上，什么都不离开笔记本。断网也能用，没有按张计费，常驻监听文件夹不产生成本。模型是磁盘上一个5GB的文件。出了更好的开源模型，改一个参数就行；就算某家服务商明年下架这个模型，他手里的副本照常工作。

省下的时间

在真实文件夹上试运行的结果：39张截图，1分47秒给出全部名字，单张0.6到3.8秒，机器是16GB的MacBook Air，全程不用盯着。

手工做的话，每张要打开、判断内容、输入名字，按30秒算，总共约20分钟。这件事他从最老那张文件（2025年12月）一直拖到现在。

10月6日到17日之间他拍了13张截图，大约一天一张。用LaunchAgent常驻-watch（plist在README里），每张在他想起来找之前就已经有了名字，全程不用动手。以前找图靠滚缩略图，-apply之后，在Finder里输入"mailbox"或"pnr"就行。

39张里有9张来自同一个仪表盘，其中4张拿到了完全相同的名字。-apply会给它们编号-2、-3、-4，不会覆盖任何文件。

项目地址是omlahore/slothshot，运行需要llama.cpp和Go。