这项目我先没看代码，先看了评论区。一帮工程师没在聊“你的模型分类准不准”，也没聊“gemma3 比 llama 强哪儿”，而是死抠几个问题：移动操作和清单提交之间崩了怎么办，WAL 的 fsync 什么时候落盘，外部备份把文件倒回来你怎么认。这个观察比项目简介有意思——用户对自动整理工具的第一道关从来不是 AI，是“它会不会在我不在的时候把我文件搞丢、搞重、搞没”。
Dhruv Jani 这兄弟干的事，账面上是个 AI 文件整理守护进程，Slothd，MIT 开源，Hacktoberfest 第 3 周交的作业。我估计很多人划过这篇 dev.to 的时候会把它归成“又一个本地 LLM 小工具”，但它骨子里其实是在反 AI。不是反 AI 技术，是反“先联网再说”的默认路径。银行回执、配置文件、PDF 合同堆在下载目录里，为什么用户一直不整理？不是没有工具，是用户信不过把这种文件扔给云端 AI。他抓的需求不新，但执行路径刁：本地优先、零凭据、默认离线、强制 dry-run、移动可撤销、崩溃可对账。你问模型聪明不聪明？谈不上——第二阶段才上个 gemma3:4b，还不如云上随便一个廉价 API 强。但这条路它走通了，而且账算得过来。
为什么说账算得过来，就一条：它拿一个小模型，换掉的是用户对“文件主权”的焦虑。
先算笔账。你要是做云端文件整理，随手接一个强模型，单次分类成本低到你自己都不管；但用户每一次点“授权访问我的下载目录”，脑子里都在算一笔账：我的文件数据给你，你能给我什么，数据泄露了谁兜底。这个获客成本高到什么程度？高到你的 AI 再聪明，也不会有多少人愿意把银行回执交给你。账面上开发成本趋近于零，账本里信任成本翻车——这就是“AI 再强也没用”的典型死法。
再看 Slothd。本地 Ollama 跑 gemma3:4b，支持图像输入，模型输出拿 Pydantic JSON 模式给锁死。整个管道只在 idle 五分钟后才动，最多 20 个文件，用户一碰键盘鼠标就让出资源。重活留到第二层视线模型，第一层用七维特征做轻量判读——什么扩展名类别、文件大小对数值、路径深度、文件名长度、修改时间的小时星期，硬拿表格特征筛掉一批明显文件。这一层零凭据、不联网，TabPFN 批处理 15 到 25 毫秒，启发式回落不到 1 毫秒。哪怕不接 Ollama，它也能纯规则先分类，避免 CLI 卡死。说白了，它设计得不像一个在秀 AI 能力的项目，像在给用户做“我能不联网就不联网，能安全就安全，能给你兜底就给你兜底”的活儿。
插一句和 AI 没关系但挺要紧的：如果你自己做过这类“自动整理文件”的需求，你大概率会卡在“批处理时怎么不把用户机器卡死”跟“误移了怎么恢复”这两件事上，而不是“模型哪个更强”。市面上很多小工具没扛过这两件事就上了云，结果要么卡机器，要么出错不可逆，用户跑了还赖 AI。Slothd 把这两件事当主线设计，所以同行看得进去。
这项目的护城河在哪儿？我一开始以为是那个拆成两层的判读漏斗——TabPFN + 元数据引擎 + 本地 VLM——但细想一下，那东西谁都能抄。特征向量就 7 个，启发式规则几行代码，MIT 摆着，我拿完就能照着搭一套。gemma3:4b 更不用说，公有权重，模型层没有任何护城河。真正有点意思的反而是那组“防翻车”的执行细节：移动前先写一条 SQLite WAL pending 记录，启动时再跑对账，检查 pending 跟磁盘实际状态对没对得上；每个文件留 SHA-256，倒回来后认得出归档位置，跳过重复推理；同名不覆盖，只加 _1、_2；移动保留 original mtime、atime，还能 undo 整批按反序退回。122 个 pytest 用例、31 秒跑完、ruff 干净——这些放在创业 BP 里不性感，放在实际跑起来的本地进程里就是用户续用的理由。我一直说工具本身没护城河，护城河在工作流嵌入和切换成本里；这项目还够不上“护城河”三个字，但它踩在了那条潜力的缝上。
说句扫兴的：这套东西窗口期很短。就这条本地优先、默认 dry-run 的路，一旦被某个大厂或者已有的文件管理工具抄走，几乎不用花什么力气。Slothd 自己没有商业模式，没有分发，没有留存飞轮。最快把它吃掉的，不是更强的开源项目，是 Finder 或 Windows 资源管理器哪天内置了一个“离线 AI 整理建议 + 一键撤销”的按钮。到那时这个 repo 就变成一本很好读的实现笔记，账本上留不下多少价值。
那怎么办？对作者这种还在赶毕业考试的实习生，我倒不觉得该急着把它商业化。这种活儿最值的地方是它证明了一件事：你能处理真实文件系统里的崩溃、恢复、去重、撤销，而不只是把一堆 JSON 输出到临时目录里逼用户自己动手看。这在工程边界很挑的圈子里，是给简历加分的东西。对想在这个方向捞红利的开发者，窄路只有一条：别卖“AI 自动整理”这个叙事，卖“这套兜底机制我替你去掉了多少恐惧”。前者的天花板很低，用户眨眼就忘；后者的整套工程纪律，不是靠调 API 就能过来的。
说完回正题，Slothd 最打动我的是作者在评论区那些补充。评论区逼着他把崩溃窗口、备份恢复、WAL fsync 的边界补了三项；他也不装，直接把还没搞定的“崩溃后源文件与目标文件同存残留清理”、synchronous=NORMAL 下断电可能丢最后一次提交的坑放进 v0.2 todo。作者自己清楚模型不如工程可靠，所以模型才被死死锁在 Pydantic 模式、断连回落、改名回退的笼子里。这个姿态比“AI 重塑文件管理”的屁话实在多，因为你把它当工具用，不把它当教主供。
最后一笔账没得跑：做工具，尤其是要碰用户文件系统的工具，第一道护城河不是模型多强，是用户敢不敢把文件交给你。敢按下那个 --go 的，绝大多数不是因为爱你那个 3B 模型，而是因为它默认不动，动之前先记账，错了能退。这笔账，打算进场的人自己算。咱下篇见。