用本地模型夜间整理文件，支持一键撤销

一台 Intel Core i3-1215U、8 GB 内存、没有独立显卡的笔记本，跑本地 AI 聊天可能让人失去耐心。但作者把任务改成夜间整理下载目录，慢模型就有了用处：读取文件、生成名称、分类归档，第二天查看报告，不满意还能撤销。

这个约 200 行 Python 的工具叫 sloth。它最有参考价值的地方，是怎样把模型放进一套有规则、有约束、能回退的流程。作者还拿真实下载目录跑了一次，暴露出测试文件夹里看不到的问题。

慢十几秒，为什么仍然值得用

作者的机器在测试时，Windows 大约只剩 1 GB 可用内存。这样的资源条件很难支撑流畅聊天，但整理文件没有即时响应要求。

当任务可以等到第二天完成，单次推理的速度就不再是首要指标。

sloth 使用 Ollama 运行 Gemma 4 E2B，模型标识为 gemma4:e2b-it-qat。按作者描述，下载大小为 4.3 GB，采用 4-bit QAT。QAT 即量化感知训练，让模型在训练时适应低精度表示，尽量减少压缩后的质量损失。这个模型还支持视觉输入，可以根据截图内容命名。

运行需要 Ollama 和 Python 3.9+：

ollama pull gemma4:e2b-it-qat
pip install -r requirements.txt

这里要注意模型标签 gemma4:e2b-it-qat：作者后面的速度、内存和输出体验都对应这套配置，不能直接套到其他模型上。

本地运行也符合文件整理的隐私需求。银行流水、简历、车票和发票，都可能出现在下载目录里。作者称，这套实现不发送文件、文件名或内容片段，断开 Wi-Fi 仍可运行。

代价也很明确：没有按调用计费的 API 账单，但仍要承担本机的内存、计算和电力消耗。所谓「免费」，更准确地说是没有模型 API 使用费。

为什么先写规则，再让模型判断

sloth 没有把整个目录直接交给模型。它先用确定性的规则缩小处理范围。

最近 24 小时内修改的文件不动，.crdownload 和 .part 下载中间文件不动。安装包、压缩包、音频和视频按扩展名分类，保留原名，不调用模型。例如 VSCodeUserSetup-x64-1.105.1.exe 直接进入 Installers。

剩下需要理解内容的文件，才进入读取流程：PDF 用 pypdf 提取前两页，.docx 从 ZIP 内的 XML 提取文本，文本文件只取前 1,500 个字符，图片则整体交给模型。

这套办法节省计算，也给能力划了边界。关键内容不在 PDF 前两页，就可能判断失准；扫描 PDF 没有文本层，目前也不会转成图片识别。原文里的 scan0001.pdf 因此被保留。

模型的输出同样受限。Ollama 用 JSON schema 约束回复，分类字段只能从八个目录中选择，避免临时生成一个「Misc Stuff 2」。日期前缀来自文件时间戳，模型只负责描述性词语。

核心请求如下，它把分类格式、上下文长度和推理选项放在同一个请求体里：

body = {
    "model": "gemma4:e2b-it-qat",
    "messages": [message],  # 提示词；图片还会附带 base64 内容
    "format": SCHEMA,       # 分类只能是八个目录之一
    "think": False,
    "stream": False,
    "options": {"temperature": 0, "num_ctx": 4096},
}

重点是 "format": SCHEMA：它约束的是输出结构和分类范围，不能保证分类正确。temperature: 0 也不能代替业务校验。

执行层则负责兜底。每次移动都会即时记入日志，作者希望即使电脑中途断电，撤销仍能找到文件去向。python sloth.py tidy ~/Downloads --dry-run 只生成计划，python sloth.py tidy ~/Downloads 执行整理，python sloth.py undo ~/Downloads 恢复上一次操作。处理后还会生成 SLOTH_REPORT.md。

脚本使用 Python 标准库加 pypdf，没有额外框架或 SDK。原文没有展示夜间调度配置，定时启动仍需要另行安排。

真正有价值的数据，来自真实目录

作者通过 ollama show 发现，所用模型默认开启 thinking。对发票分类来说，模型长时间推敲「这是不是发票」，很可能花掉比答案本身更多的计算。

他用相同的三个文件比较开关前后的表现，报告关闭 thinking 后快了 7 到 30 倍。三个文件的目录选择相同，其中两个文件的名称相同。

这个结果支持在该任务中尝试 "think": False，但样本只有三个，而且原文没有给出完整的逐项对照数据。作者还特意说明：这是独立测试，不能与 Windows 内存紧张时的整批运行耗时混为一谈。

最初的测试还踩中过一个评估陷阱。提示词示例用了 acme_cloud_invoice 和 python_import_error，测试目录恰好就有对应发票和错误截图。漂亮结果可能只是模型复用了示例。

作者把示例换成不匹配测试文件的 dentist_appointment_reminder 和 github_actions_failed_build，分类仍然合理。这排除了一个明显的干扰，却还算不上完整的准确率评估。

测试样例像提示词里的例子，往往会让效果显得比实际更好。

后来，作者对真实 Downloads 目录执行了 --dry-run。达到处理时间门槛的 72 个文件中：

• 36 个计划归档，其中 31 个由模型读取命名，5 个按扩展名分类。
• 3 个因模型无法确定而保留。
• 33 个因格式不受支持而保留，包括 25 个 Excel、6 个 PowerPoint、一个旧 .doc 和一个 .mpeg。

整批耗时 11.5 分钟。文档每个需要 8 到 26 秒，两张图片分别需要 70 秒和 106 秒。后续作者已跳过 Office 的 ~$ 锁文件，并把 .mpeg 纳入 Media；读取 .xlsx、.pptx 仍是待办。

真实数据还暴露了命名问题：两个版本的报告得到相同名称，只能靠日期前缀区分；WhatsApp 照片的新名称只是重复旧名称；CLAUDE.md 会被归入 Reading。El Niño 被清理成 el_ni_o，则是文件名清理代码丢弃重音字符，作者称已经修复。

测试目录里没有 Excel，真实目录里它却是最大的未覆盖类别。这比几次成功命名更能决定下一步该开发什么。

我的判断

我认同作者对任务的选择：把本地小模型用于可以延迟完成的整理工作，确实比强求即时聊天更适合这台机器。规则分流、结构化输出、不确定时跳过、执行日志和撤销，也都值得借鉴。

但「开放模型胜过闭源模型」在这里是作者基于隐私、离线和费用偏好的取舍。原文没有托管模型的实测对照，也没有系统性的分类准确率、命名质量或长期运行数据。关闭 thinking 的收益，同样只能先看作小样本经验。

文件管理还有一层模型不知道的上下文：文件放在哪里，可能比文件写了什么更重要。CLAUDE.md 在内容上像阅读材料，在工作流程里却是指令文件。仅凭语义分类，无法判断移动它会不会破坏使用方式。

与纯扩展名整理相比，sloth 能区分内容相似、用途不同的文档；与人工确认每一步相比，它节省操作时间，却更依赖排除规则和回退机制。一般团队照搬前，应先定义哪些文件允许自动移动，并处理同名、版本和目录依赖。原文没有说清同名冲突的完整策略。

本地运行减少了文件外传路径，但不会自动保证整理正确。模型可以慢，文件操作必须可控。

能拿来做什么

• 给个人下载目录做自动整理时，先运行 python sloth.py tidy ~/Downloads --dry-run，检查分类计划、漏读格式和命名质量，再决定是否执行移动。
• 用 Python 或 Node 实现类似工具时，把扩展名分流、最近修改时间和排除名单写成程序规则。像 CLAUDE.md 这类有位置依赖的文件，应在调用模型前排除。
• 为本地 AI 分类任务做性能测试时，用同一批文件比较 thinking 开关，并同时记录耗时与输出差异。提示词示例应避开测试内容，真实目录也要纳入验证。
• 让 AI 参与文件操作时，将名称生成与实际移动拆开。日期取可靠元数据，每次移动记录日志，并提供报告和撤销入口，让错误有机会被发现和恢复。