混乱的名字长什么样
手机拍的照片自带 IMG_ 加一串数字；浏览器重复下载同名文件会自动加"(1)(2)(3)"；微信、邮件客户端传文件时经常整个丢掉原始文件名；截图统一是 Screenshot 加时间戳。这些命名规则各自都"合理"，凑在一个文件夹里就是灾难——你没法从名字判断任何一个文件是关于什么的，除非点开看一眼。同一个文件夹里同时出现这几种命名习惯的情况并不少见——一部手机截图、一封邮件附件、一次浏览器下载，各自带着完全不相关的命名逻辑落进同一个地方，谁都不欠谁一个解释。
靠改名规则解决不了这个问题
批量重命名工具能做的是"把文件名 A 的格式转换成文件名 B 的格式"——比如统一加日期前缀、替换某些字符。但如果原始文件名本身不包含"这是什么"的信息（IMG_4821 天生就不知道自己是什么），任何格式转换规则都变不出这个信息，这是规则类工具改名的天花板：garbage in, garbage out，输入没有的信息，输出也生不出来。
从内容反推出该叫什么名字
真正能解决问题的思路是不看文件名、直接看内容。Filewise 打开文件本身——PDF 读文本，截图和扫描件走 Apple Vision OCR——识别出结构化信息：这是谁开的、什么类型的文件、日期是哪天，如果是发票还会读出金额。这些信息拼起来变成「何时_谁_类型_关于什么」的命名，比如一张原名叫 IMG_4821.PDF 的宜家发票，会被命名建议为「2026-06-18_宜家_发票_¥1280.pdf」。文件名和文件内容第一次真正对上号。这套命名不是简单粗暴的"加个日期前缀"，而是先理解文件属于哪一类场景，再按场景选择该保留哪些信息——发票要金额，合同要看是否已签署，报告要主题，各自的命名侧重点并不相同。
不是所有文件都能这样处理
诚实地说，这套逻辑依赖文件本身带有"谁、类型、主题"这类结构化信息——发票、合同、报告、截图这类文件天然具备，但源代码文件、日志文件、纯配置文件通常没有这种结构，模型没有强信号可用时，Filewise 不会硬编一个名字出来，而是保留原名，把判断权交还给你。这不是功能缺陷，是"读不懂就不装懂"这条设计原则的自然结果。
信心来自可以验证
你不需要一开始就信任它的判断——每次改名之前都会出一张方案表，「原名 → 新名 + 改名理由」列清楚，你确认了才执行，不满意也可以整批撤销。想知道这套命名逻辑具体怎么落到下载文件夹的日常整理里，看这篇；如果你更关心找旧文件的问题，见下载的文件突然找不到了怎么办。
