AI File Sorter：用本地视觉模型给文件分类和改名
Cross-platform desktop application for content-aware file organization and renaming. Supports local and remote LLMs, preview-based workflows, and fully user-controlled changes.
秒懂
- 它是什么？
- 这是一个 C++ 编写的跨平台桌面程序，用本地或远程 LLM 为图片、文档和音视频生成分类与文件名建议，在用户确认前不改动任何文件。它的价值在于把「批量重命名」这件高风险操作拆成了先预览、再执行两步。
- 适合谁用？
- 适合手里有大量命名混乱的图片、文档或音视频，且愿意在本地跑模型、逐条审查建议的人。不适合希望一键全自动整理整个磁盘、或不愿配置本地推理后端的用户。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 C++（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它替换的是手工重命名，不是文件管理器
IMG_2048.jpg 这类文件名不携带任何信息，几年后回看只能逐个打开。AI File Sorter 要解决的就是这一步：让模型看一眼图片内容，给出 clouds_over_lake.jpg 这样的名字。README 里的例子正是这个。文档类文件走另一条路，读取文本内容后提出更清晰的文件名。音视频则更简单，直接读取文件内部已有的元数据，如果存在 year、artist、album、title 这类标签，就拼成 2024_artist_album_title.mp3 形式的建议。目标用户是那些 Downloads 目录、外接硬盘或 NAS 上堆了几百上千个文件，又不想写正则脚本的人。它不是文件管理器，不负责浏览、搜索或同步，只负责在整理的那一刻给出建议。
三步流程：分析、建议、确认后才落盘
README 把流程写成四步：指向文件夹或驱动器，用选定的本地或远程模型分析文件（图片还会分析图像内容），生成分类和重命名建议，用户审查调整后才会执行。关键在于最后一步之前什么都不发生。确认之后，程序才会自动创建所需文件夹并移动文件。撤销入口在 Edit 菜单下的 Undo last run，也就是说它保留了一次回退的机会。分类逻辑不是纯规则匹配，而是把 AI 建议、可选的类别白名单、近期相似结果和用户此前批准的审查决定放在一起考虑。README 的说法是这能让排序随时间保持更一致，代价是行为会受历史决策影响，同一批文件在不同历史状态下可能得到不同分类。
本地推理与远程 API 是两条独立路径
隐私方面 README 说得很直接：使用本地模型时文件、文件名、图像和元数据都留在本机，不发遥测，只有选择远程模型时才需要联网。本地路径依赖视觉 LLM 后端，仓库里给出了 Vulkan、CUDA、Apple Metal 三套平台标识，说明推理是走 GPU 加速的。README 中有一节标题为 Required visual LLM files，意味着本地视觉分析不是装完即用，需要用户自己准备模型文件。远程路径则分别有 OpenAI API key、Gemini API key 和自定义 OpenAI 兼容 API 三节说明，覆盖了自建推理服务的场景。这个设计把「用哪个模型」的决定权完全交给用户，同时也意味着首次配置成本不低。
分类模式、语言和白名单是三个可调项
README 目录里列出的 Categorization 一节包含三个子项：categorization modes、category language selection、category whitelists。分类模式影响建议的粒度，类别语言决定生成哪一语言的类别名，白名单则限制模型只能在给定集合里选。白名单这一项值得单独看：它是把开放式的模型输出收敛到可控集合的唯一手段，如果不用白名单，模型每次可能给出措辞相近但字面不同的类别，长期会积累出一堆近义文件夹。文档分析只支持特定格式，音视频元数据建议同样有格式限制，README 用 Supported document formats 和 Supported audio/video formats 两节分别列出，具体清单需要以仓库中的这两节为准。
安装：Linux、macOS、Windows 各有入口
README 的 Installation 一节按平台分了三块，另有 SourceForge 下载按钮和 Microsoft Store 入口（apps.microsoft.com 上的 9npk4dzd6r6s）。也就是说 Windows 用户可以直接从商店装，Linux 和 macOS 用户走仓库说明的路径。程序内置了系统兼容性检查，README 里对应 System compatibility check 一节，界面截图中也有一张标注为 compatibility benchmark 的对话框，说明它会在正式使用前评估当前机器能否跑得动所选后端。这一步对本地推理尤其重要，因为 Vulkan、CUDA、Metal 的支持情况取决于显卡和驱动。首次使用 README 建议不要直接对着整个归档或磁盘跑，而是从 Downloads、截图、照片或文档里复制 20 到 50 个文件到临时目录，跑完分析后先看审查表格再决定是否应用。
缓存与「学习行为」带来的一致性代价
README 专门有一节叫 Categorization cache and learned behavior。结合前面提到的「近期相似结果」和「已批准的审查决定」，可以确认程序会把历史决策纳入后续建议。这解决了一致性问题，但引入了两个后果。一是可解释性下降：同一张图片在缓存为空和缓存已满时可能得到不同建议，用户很难从界面判断某个建议来自模型还是来自历史。二是迁移成本：如果换机器或清空缓存，此前积累的一致性就没了。README 没有说明缓存存储位置或清除方式，这一点在正式采用前需要自己去仓库里确认。
什么时候它不合适
最明显的一类场景是文件量极大且无人愿意逐条审查。流程要求用户确认，确认本身就是人力成本，几千个文件意味着几千次判断，这时它并不比写脚本快。第二类是文件名本身已经规范、只是需要按规则移动的场景，固定规则脚本更可预测，模型在这里只会增加不确定性。第三类是没有合适 GPU、又不愿意把文件内容发给远程 API 的机器：本地视觉分析需要用户自备模型文件并跑在 Vulkan、CUDA 或 Metal 上，远程路径则意味着图片内容要离开本机。README 把隐私作为设计前提，但这条前提只在选了本地模型时才成立。
与规则型重命名工具的差别
常规做法是 ExifTool 这类工具加一段脚本，或者用文件管理器自带的重命名模板。它们的共同点是输入必须结构化：ExifTool 读的是 EXIF 字段，重命名模板读的是文件名里的模式。AI File Sorter 的差别在于它处理的是非结构化输入，一张没有任何有意义元数据的手机照片，ExifTool 只能给出拍摄时间，而视觉 LLM 能给出画面内容。反过来说，凡是元数据已经齐全的场景，ExifTool 更快、更确定、更容易在 CI 里复现，也不需要 GPU。两者不是替代关系：元数据驱动的重命名交给 ExifTool，内容理解交给 AI File Sorter，是更合理的分工。
许可证与维护成本
项目采用 AGPL-3.0。这是一个强 copyleft 许可证，如果把它集成进网络服务或分发修改版本，需要按 AGPL 的条款处理源码开放义务。内部个人使用和自用修改通常不涉及分发，但把它的代码并入闭源产品前应当自行确认条款，这里不构成法律意见。维护方面，README 提供了 Testing 一节，其中包含可选的 headless live LLM 测试，说明项目有面向 LLM 调用的自动化测试路径。版本节奏上，1.9.0、1.9.1、1.9.2 三个版本集中在 2026 年 8 月发布，间隔很短，属于快速迭代期，升级前值得看一眼 changelog 里是否有影响分类行为或缓存格式的改动。
编辑结论
适合手里有大量命名混乱的图片、文档或音视频，且愿意在本地跑模型、逐条审查建议的人。不适合希望一键全自动整理整个磁盘、或不愿配置本地推理后端的用户。上手前先用 20 到 50 个文件建一个临时目录跑一遍，确认分类语言、类别白名单和视觉模型文件路径都符合预期，再决定是否对真实目录执行。
社区笔记