AI File Sorter：用本機視覺模型整理圖片與文件的 C++ 桌面工具
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++ 撰寫、AGPL-3.0 授權的跨平台桌面程式，能對圖片、文件與影音檔產生分類與改名建議，並在使用者確認後才實際搬移。它真正值得注意的地方，是把審核權留在人手裡，以及可以完全離線跑本機模型。
- 適合誰用？
- 如果你手上有一批命名雜亂的圖片、文件或影音檔，而且不願意把內容上傳到雲端，AI File Sorter 的離線視覺模型加上審核表格是合理的起點：先複製 20 到 50 個檔案到暫存資料夾試跑，確認產生的分類與檔名符合你的命名習慣再擴大。若你需要的是持續監看、自動觸發的整理流程，或你的環境無法執行 Vulkan、CUDA、Metal 這類後端，這個工具不會幫上忙，因為它的設計前提就是使用者逐次確認。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 C++（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「命名雜亂」而不是「檔案太多」
多數整理工具處理的是位置問題：把檔案從 A 搬到 B。AI File Sorter 處理的是命名問題。README 給的例子很直接，一張 IMG_2048.jpg 可以被建議改名為 clouds_over_lake.jpg。這是兩件不同的事，因為位置可以靠規則決定，命名卻需要知道內容。
目標使用者是那些面對 Downloads、外接硬碟或 NAS，明知裡面有東西卻找不到的人。README 描述的使用情境包含檢視、封存與長期保存。這三種情境的共同點是：檔名會在幾年後成為唯一的檢索線索，而 IMG_2048 這種名字在那時候等於沒有資訊。
它不處理重複檔案，也不處理容量問題。README 沒有提到任何去重或空間回收的功能，所以帶著這類需求進來會失望。
分類建議是怎麼被約束住的
README 對機制的描述集中在「不是只依賴固定規則」這句話上。實際運作是把幾種訊號混在一起：檔名、檔案類型、所在資料夾的上下文，以及過去的整理結果。
其中兩個機制值得單獨看。第一個是分類白名單（category whitelists），它讓使用者事先限定可接受的分類集合，模型只能在這個集合裡選。第二個是分類快取與學習行為，README 的目錄裡有「Categorization cache and learned behavior」一節，說明相似檔案會被參照先前的結果。這兩者合起來的效果是：同一個資料夾反覆整理時，分類不會每次都不一樣。
這是設計上的取捨。約束越強，一致性越好，但模型能給出的意外洞見越少。如果你要的是讓模型自由發想分類體系，白名單反而是阻礙。分類語言也可以另外選擇，這對非英語環境的檔名一致性有實際影響。
視覺模型、文字模型與純 metadata 三條路徑
這個專案對不同檔案類型走不同的分析路徑，差別在於成本與可靠性。
圖片走視覺 LLM。README 提到需要「Required visual LLM files」，也就是本機推論需要額外準備模型檔，並非安裝完就能用。這是最重的一條路徑，也是唯一真正讀取內容的路徑。
文件走文字 LLM，README 有「Supported document formats」一節列出可處理的格式。這條路徑讀的是文字內容。
影音檔走的是第三條路：不分析內容，只讀檔案內部既有的 metadata。README 的說明是，如果 year、artist、album、title 這些標籤存在，就能組成 2024_artist_album_title.mp3 這樣的建議。這條路徑最便宜也最可靠，但前提是標籤本來就存在。標籤缺失的檔案，這條路徑無能為力，而 README 沒有描述任何從音訊內容推測的替代方案。
安裝與第一次執行的具體步驟
README 依平台分成 Linux、macOS、Windows 三種安裝方式，另外也提供 SourceForge 與 Microsoft Store 的下載入口。
真正需要事先準備的是本機模型。README 在圖片分析一節要求「Required visual LLM files」，也就是說，想完全離線使用視覺分析，得先自行取得並放置這些檔案。若不打算跑本機模型，另一條路是在設定裡填入 OpenAI 或 Gemini 的 API key，README 有獨立的「Using your OpenAI API key」與「Using your Gemini API key」兩節。第三條路是自訂端點，對應「Using a custom OpenAI-compatible API」，適合已經有自架推論服務的情況。
在跑正式資料之前，README 明確建議先做一次安全試跑：從 Downloads、截圖、照片或文件中複製 20 到 50 個檔案到暫存資料夾，跑分析，檢查審核表格，再決定要不要套用。若套用後想還原，路徑是 Edit 選單下的 Undo last run。這是整份文件裡最具體的操作建議，值得照做。
環境方面，README 有「System compatibility check」與「Requirements」兩節，並在專案頁面標示 Vulkan、CUDA、Metal 三種後端。實際能不能跑取決於你的 GPU 與驅動，這點必須以官方相容性檢查的結果為準，我無法在此代為判斷。
審核表格是核心設計，也是它的天花板
整個流程是：指向資料夾、分析、產生建議、人工檢視後才套用。README 反覆強調「在你批准之前不會有任何搬移或改名」。
這個設計解決了 AI 分類最實際的風險：錯誤的搬移比錯誤的建議難收拾。但它同時定義了這個工具的上限。它是一個逐次執行的工具，不是常駐服務。README 沒有描述排程、檔案系統監看或自動觸發的機制，所以「下載完成就自動歸位」這種需求不在它的範圍內。
另一個限制是檔案數量。每一張圖片都要經過視覺模型推論，這是整個流程裡最貴的一步。README 建議的 20 到 50 個檔案試跑，某種程度上也反映了這個成本結構。要一次處理數千張照片，得先評估本機硬體或遠端 API 的實際耗時與費用，而這兩者都不在文件能回答的範圍內。
還有一個容易被忽略的點：Undo last run 只還原最後一次執行。連續套用多個批次之後，前面幾次的結果不在還原範圍內。
與規則式工具（例如 Hazel 或 AutoHotkey 腳本）的差異
拿 Hazel 這類規則式自動化工具來比最清楚，因為兩者的假設完全相反。
規則式工具靠的是可預測的條件：副檔名、修改日期、檔名中的字串。它的優點是行為完全可解釋，出錯時你能指出是哪一條規則。缺點是它對內容一無所知，所以無法把一張沒有 EXIF 的風景照命名為 clouds_over_lake。
AI File Sorter 走的是相反的路：它讀內容，代價是結果不保證可重現，也不保證可解釋。你今天得到的分類，明天跑同一批檔案未必一樣。分類白名單與快取機制就是為了壓縮這個不確定性而存在的，但它壓不到零。
如果你的檔案命名本來就有規律，規則式工具更快、更省資源，也更好除錯。如果你面對的是一堆毫無規律的既有檔案，而且願意逐次審核，那 AI File Sorter 補上的正是規則式工具做不到的那一段。
AGPL-3.0 與後續維護成本
授權是 AGPL-3.0。這對個人使用沒有實質影響，但對想把它包進內部服務、或修改後提供給外部使用的團隊，授權條款會牽涉到原始碼揭露的義務。這部分的判斷需要法務意見，本文不提供法律結論，只指出授權類型是採用評估中必須先確認的一項。
維護節奏方面，從發布紀錄看，1.9.0、1.9.1、1.9.2 三個版本集中在 2026 年 8 月，主線在 2026 年 9 月仍有推送。這是相對密集的更新期，意味著介面或設定項目有可能在版本之間變動。
對使用者的實際成本落在兩處。一是本機模型檔案，這類檔案通常不小，且會隨模型更換而需要重新下載。二是分類快取，它會隨使用累積；README 有獨立一節說明其行為，在跨版本升級時值得回頭確認快取是否需要重建。README 也提到測試相關內容，包含選用的 headless live LLM 測試，這對想自行編譯的人是必要資訊。
編輯結論
如果你手上有一批命名雜亂的圖片、文件或影音檔，而且不願意把內容上傳到雲端，AI File Sorter 的離線視覺模型加上審核表格是合理的起點：先複製 20 到 50 個檔案到暫存資料夾試跑，確認產生的分類與檔名符合你的命名習慣再擴大。若你需要的是持續監看、自動觸發的整理流程，或你的環境無法執行 Vulkan、CUDA、Metal 這類後端，這個工具不會幫上忙，因為它的設計前提就是使用者逐次確認。採用前先確認兩件事：AGPL-3.0 對你散布方式的影響，以及 Edit 選單的 Undo last run 是否涵蓋你實際執行的批次。
社群筆記