跨平台：支持 Windows、macOS、Linux，单文件便携版无需安装。
安全隐私：本地离线运行、开源可审计、无广告、不收集数据。
功能全面：覆盖重复文件、相似媒体、大文件、空目录、临时文件、损坏文件等。
语言与性能：Rust 编写，扫描极快（约 300MB/s）、内存占用低、启动快。
可使用多种工具：
重复项 – 根据文件名、大小或哈希值查找重复项
空文件夹 – 利用高级算法查找空文件夹
大文件 – 查找指定位置中指定数量的最大文件
空文件 – 查找整个驱动器中的空文件
临时文件 – 查找临时文件
相似图片 – 查找不完全相同的图片（分辨率不同、有水印等）。
相似视频 – 查找视觉上相似的视频
Same Music – 通过标签或阅读内容进行比较来搜索相似的音乐
无效符号链接 – 显示指向不存在的文件/目录的符号链接
损坏文件 – 查找无效或损坏的文件
无效扩展名 – 列出内容与其扩展名不匹配的文件。
Exif 元数据移除工具 – 从各种文件类型中移除 Exif 元数据
视频优化器 – 裁剪静态部分并将视频转换为更高效的格式
不良文件名 – 查找文件名可能不符合预期（例如，包含特殊字符）的文件
Apple 的 Foundation Models framework 之 Python 綁定，提供在 macOS 上存取 Apple Intelligence 核心的裝置端 foundation model。
總覽
適用於 Python 的 Foundation Models SDK 為 Apple 的 Foundation Models framework 提供 Python 式介面。
你可以：
透過從 Python 執行批次推論並分析結果， 評估 Swift Foundation Models 應用程式功能
使用系統 foundation model 執行裝置端推論
串流即時文字生成回應
使用具結構化輸出綱要與限制的引導式生成（guided generation）
使用 Python 裝飾器進行引導式生成，取得型別安全的回應
為不同的模型選項設定自訂模型設定
處理從 Swift app 匯出的逐字稿以進行品質分析
總覽
適用於 Python 的 Foundation Models SDK 為 Apple 的 Foundation Models framework 提供 Python 式介面。
你可以：
透過從 Python 執行批次推論並分析結果， 評估 Swift Foundation Models 應用程式功能
使用系統 foundation model 執行裝置端推論
串流即時文字生成回應
使用具結構化輸出綱要與限制的引導式生成（guided generation）
使用 Python 裝飾器進行引導式生成，取得型別安全的回應
為不同的模型選項設定自訂模型設定
處理從 Swift app 匯出的逐字稿以進行品質分析
Apple Developer Documentation
Foundation Models | Apple Developer Documentation
Perform tasks with the on-device model that specializes in language understanding, structured output, and tool calling.
AI 不會減少工作量，反而加劇工作強度 （★ 251 分）
👥 289 則討論、評論 💬 🔥
https://news.ycombinator.com/item?id=46955703
《哈佛商業評論》HBR（Harvard Business Review）引用加州大學柏克萊分校哈斯商學院（Berkeley Haas School of Business）研究者在 2025 年 4 到 12 月、針對一家美國科技公司 200 名員工的初步調查：AI 在職場上不一定會「減少工作」，反而可能帶來「工作強度升高」。研究描述，員工在沒有被強制使用 AI 的情況下，仍會自發同時維持多個進行中的工作脈絡，例如一邊手寫程式、一邊讓 AI 產出另一個版本；同時開多個代理（agent）並行處理；或把原本長期擱置的事情重新撿起來，因為覺得 AI 可以在背景「幫忙處理」。
問題在於，這種像有了「夥伴」的動能，實際代價是更頻繁的注意力切換、更密集地檢查 AI 輸出，以及待辦事項越開越多。表面上看起來進度飛快、效率很高，但人的大腦需要持續在不同任務間重新切換脈絡，認知負荷上升，容易出現「一直在 juggling」的疲憊感，讓組織更難分辨到底是可長可久的生產力提升，還是不可持續的高強度燃燒。
Simon Willison 以自己使用 LLM（大型語言模型，Large Language Model）的經驗呼應這點：他常被推向同時推進兩三個專案的節奏，短時間能做出大量成果，但一兩個小時後當天的心力就幾乎被榨乾；也聽過有人因為忍不住再用「just one more prompt」多做一個功能而影響睡眠。文章因此主張企業需要建立一套 AI practice（組織內對 AI 使用的制度化作法），用工作規範與流程來降低過勞風險，避免把「強度上升」誤判成「真正的績效提升」，並重新找回可持續的工作平衡。
留言討論多把「加速後更忙」歸因於人性與職場競爭：不少人認為主管甚至不必施壓，FOMO（Fear of Missing Out，害怕錯過）就會驅動大家自我加碼；一旦 AI 輔助的高產出變成新常態，不跟上的人就會被視為「同薪變慢」。也有人用 Parkinson’s law（帕金森定律：工作會膨脹到填滿可用時間）或洗衣機帶來「乾淨衣服標準上升」的歷史類比，指出效率提升常被轉換成更高的產出配額；延伸到更大的爭辯，部分人主張這是市場競爭與管理制度的結果，應靠勞工組織（如工會）或制度調整來對抗；另一派則認為科技進步向來如此，真正的競爭會轉移到產品想像力與價值交付，使用者也確實因「能做更多」而受益。
在更具體的開發者經驗上，很多人把「再試一次提示」形容成賭博或吃角子老虎：因為結果帶有不確定性、偶爾大成功會強化行為，形成類似 variable ratio schedule（變動比率增強時制）的上癮機制。常見困境是 AI 讓你很快到達「80% 完成」，但最後 20% 可能無限迭代、耗掉數小時；加上「氛圍式寫程式」vibe coding（先讓 AI 堆出能跑的樣子、再邊試邊改）容易留下難以維護甚至有資安風險的基底，驗證與理解成本不一定比自己寫更低。相對務實的做法包括：把使用情境切小、時間盒（time boxing）限制探索、先寫清楚規格與設計文件、用測試作為護欄；也有人認為善用工具後，AI 其實能協助讀程式與快速試多種方案，讓原本做不到的專案變得可行，甚至真的騰出時間回到生活。整體共識是：AI 可能加速「產出」，但也把壓力轉移到驗證、專注力管理與流程設計；缺乏紀律時，它更容易把工作推向高強度而非減量。
👥 289 則討論、評論 💬 🔥
https://news.ycombinator.com/item?id=46955703
