29个项目文件夹95GB，他让本地模型逐个判生死

桌面上的 ~/Desktop/Project 文件夹里躺着29个项目，加起来约 95GB 。哪些能安全归档、哪些删了会后悔，作者自己也没数。手工盘点这种事，正好是"国际树懒日"该干的活——于是他写了个工具替自己干。 GraphSloth 会扫描一个装着多个项目的文件夹，对每一个项目提取真实事实：磁盘占用、git 提交距今多久，对 git 仓库还会做一次真正的 Graphify 结构抽取——基于 tree-sitter 的 AST 解析，不花一分钱 LLM 成本——给出节点数、边数和被引用最多的符号。随后一个本地 Gemma 模型读取这些事实，返回三种判定之一：ACTIVE、DORMANT 或 ARCHIVE-CANDIDATE，并附一句必须引用真实数字、不许凭空编造的理由。 没有任何东西会被自动删除。输出是一份静态报告；可选的 --apply 参数只会把归档候选逐个移进同级的 _Archive/ 文件夹，每移一个都先问一遍。 在作者真实的桌面上跑了一遍：29个文件夹全部审完， 10个 被标为 ARCHIVE-CANDIDATE（若信它，可回收 29.4G ），16个 ACTIVE，3个 DORMANT。其中9个因为带有真实的部署信号被自动挡在归档堆之外，包括作者自己那个还在运营的电商店铺，以及一个生产环境的考试评分后端。 它抓到了自己撒谎 下面三件事都是拿 GraphSloth 跑作者自己线上生产文件夹时发现的，不是测试套件跑出来的，而且每一个都在发现当天修掉。 一家真实运营、有真实订单的店铺 Srijan Saree 被判成了 ARCHIVE-CANDIDATE。原因是部署信号检查只看文件夹顶层，而这家店的代码和 .vercel 配置都在下一层。修法是：当顶层本身不是 git 仓库时，往子文件夹里再查一层。 一个 26.8G、装着34个独立 git 克隆的仓库，差点因为其中一个克隆很活跃就被整体判成 ACTIVE。第一版嵌套仓库修法挑出最近被碰过的那个克隆，用它代表整个 26.8G 文件夹——而34个克隆里过去30天真正有动静的只有10个。修法是识别多仓库容器，报告真实分布而不是单点采样，并加一条硬规则：近期仓库里混着陈旧仓库的容器，永远不许判 ACTIVE。 一次原始异常差点被当成判定结果发出去。重启后的一次 Ollama 超时，几乎让某个文件夹的"理由"字段里直接写上 [Gemma call failed after 3 attempts: timed out] 。原因是模型在给出答案前会先输出思维链，复杂的事实块在纯 CPU 推理下把这一步推过了300秒超时。修法是传入 think: false 并限制 num_predict ——同一个调用从无限挂起变成个位数秒返回——再加一道检查，在发布前捕获并重试这类错误。 它真的死过一次 真实运行到一半，操作系统把进程杀了。不是代码的 bug——Gemma 常驻内存约 8GB ，审计跑着的时候笔记本后台内存吃紧。29个文件夹里已有27个完成，但它们只以文本形式存在于一个日志文件里。作者不得不另写一个脚本，把已完成的判定从 stderr 输出里解析回来。 这正是 Temporal 工作流要解决的问题，于是他把审计循环重建成一个工作流。 temporal_audit.py 跑同样的逐文件夹审计，但每个文件夹的结果变成一个持久化的 activity，而不是 Python 列表里的一行。他没有只停留在声称，而是做了验证：启动一次5个文件夹的运行，让其中2个完成，在 activity 执行中途对 worker 进程 kill -9 ，用 temporal workflow describe 确认工作流仍在服务器上存活、2个结果完好，然后重启 worker，看着它从第3个文件夹接着跑，而不是从头再来。 Temporal 的工作流代码必须确定性，因此禁止在工作流定义本身里访问文件系统和子进程。这意味着要把工作流逻辑和 activity 实现拆成两个文件： ta_workflow.py 保持沙箱干净， ta_activities.py 干真实的 I/O，只由 worker 进程导入。 差点发出去的那个 bug 第一版主要按 git 提交时间给文件夹打分。这对任何已部署且稳定的项目都是错的：一个很少需要碰的线上后端，看起来会和一年前真正废弃的东西一样"陈旧"。作者自己就有好几个文件夹是线上生产服务，在第一版逻辑下，它们离被打上归档标记只差一次不走运的 LLM 响应。 所以 GraphSloth 在 Gemma 看到文件夹之前，先检查便宜、本地、不联网的部署信号—— vercel.json 、 .vercel 、 docker-compose.yml 、 render.yaml 、 fly.tom