前言
前段时间领导需要一份半年前的 xx 项目合同初稿。
当时我已经有分类意识，会在每月末对本月完成的工作文件进行归档，目录结构大致如下：
- 01_工作文件
- 2023 年
- 1 月
- 2 月
- 3 月
- ...
- 2024 年心想：找个文件这不是轻轻松松，但领导只给了一个关键词「半年前」，我回忆了一下，大概是在 2023 年的 6 月份左右？
于是点进「01_工作文件 – 2023 年 – 6 月」文件夹下浏览，其下又是无穷多的子文件夹，一个个核对，但没有在文件夹里找到能对应得上记忆的文件。
在其他分类下搜寻一段时间无果，于是打开 Everything 直接搜索关键词「xx 项目」，这才在「01_工作文件 – 2023 年 – 未归档」文件夹中找到。我才想起来当初此项目因为一些原因被搁置，所以一直躺在「未归档」文件夹中。
事后，让我重新审视文件分类的必要性，当需要查找某份文件时，苦苦维护的文件分类法却完全比不上一条搜索指令来的快。
然而由于 windows 自带的资源管理器的特性，几乎所有人都在用「文件夹分类」作为管理文件的方式。不论是「中图法」还是「杜威十进制分类法」，这些方式从理论上来说确实可以使文件资源管理器「看上去」变得井井有条。
只可惜分类法只是满足了视觉享受，在无形中甚至增大了保存新文件的压力，因为每次都需要思考这个文件该放在什么位置才是正确的。比方说我有一张 xx 项目设计费用的发票，开票时间为 2023 年 5 月，那么我是该按照开票日期保存，还是按照项目类型保存，亦或是按照发票类型保存呢？每次保存文件前都必须谨慎选择，实在令人疲惫，有时直接放到桌面才是最简单直接的选择。
久而久之，分类法成了摆设，本地文件又开始变得混乱。当我试图查找某一份文件，大部分情况下我更依赖「Everything」之类的搜索软件。
我花了些时间进行反思，得出一个结论：
放弃「分类」，拥抱「搜索」。
注：本文并不是完全放弃分类，而是将一些文本、Excel、Word 等单一文件使用本方案管理，其他诸如软件、项目文件等不包含在本文的探讨范围。但本方案实际上能对项目文件进行辅助，各位读后便知。
我的痛点一：分类法的局限性
一句话概括「分类法的局限性」就是：它整理了文件，但没有整理我的脑子。
现在的人们似乎都迈入了一个误区：总是花大量精力把外部系统整理的井然有序，以为内部系统（大脑）会跟着有条不紊。
实则不然，我们对本地文件分类的执着不亚于在笔记系统中对笔记分类的执着：
……此时的笔记软件就像是一座华美的博物馆，你的笔记被精心保存在一个个展柜里，看着它们，心满意足。
打开资源管理器就像欣赏一个博物馆，确实令人心情舒畅，然而一旦试图寻找那些在记忆中变得模糊的文件，这种心情就会转瞬即逝，随之而来的是焦虑和抓狂：
- 这个文件我要在哪个文件夹下找？
- 我明明是放在这个文件夹里的，为什么找不到？
- 咦？怎么有两份名字一模一样的文件？哪份才是我需要的？
- ……
在「文件博物馆」搜寻一番找不到想要的文件后，只能悻悻地打开「Everything」，凭借记忆中的几个关键词才顺利找到。
为什么会出现这种情况呢？主要有以下两种原因：
- 分类法仅适用于「没有明确目的的浏览」
- 大脑不具备连贯性记忆的能力
1. 分类法仅适用于「没有明确目的的浏览」
设想一下，当我们逛图书馆的时候心里想的是什么？我想大部分人逛图书馆应该就是浏览一下感兴趣的分类，看看最近上了什么新书之类的吧。
如果想买特定的书，一般会在网上直接购买或者在图书馆的「图书搜索系统」中搜索，而不是进行「浏览书架」这个行为。
可以看出，逛图书馆这种行为不具备明确的目的，我们仅仅是好奇这里有什么。
由图书分类法延申而来的文件分类法自然也就不太适用于要查找某些特定资料的场景。因为文件的内容可以横跨多个领域，使用分类法会遇到问题：
- 如果只保存在单一分类下，日后随着记忆的模糊，很容易丢失查找此文件的线索
- 如果同时保存在多个分类下，文件版本管理的混乱又接踵而至
2. 大脑不具备连贯性记忆的能力
由理查德·阿特金森（Richard Atkinson）和理查德·谢弗林（Richard Shiffrin）提出记忆形成的三个阶段：
- 编码：获得资讯并加以处理和组合。
- 储存：将组合整理过的资讯做永久纪录
- 检索：将被储存的资讯取出，回应一些暗示和事件。
大脑就像一条流水线工厂按照特定流程将记忆信号分散存储大脑皮层、小脑、海马体、杏仁核等不同部位，并且在需要时根据相关联的刺激或情境来检索这些记忆片段。
当我们试图回想起记忆中的某一件事情，其实很难一开始就回忆起事件的全貌，往往是根据一些细节和线索回忆起另一条线索，进而将所有相关的线索串联起来形成记忆。
所以我们常常会在某个具有既视感的瞬间突然想起一件类似的事情。
使用分类法时，需要寻找某份文件资料时必须形成这种记忆：一级目录 > 二级目录 > …… > 目标文件，一旦中间某个环节的记忆模糊，寻找效率就会大幅下降。
我的痛点二：文件版本混乱
当发现使用分类法完全无法提高找文件效率之后，我决定放弃分类法，探索基于搜索的文件整理方案，但一开始就遇到令人头疼的事情。
由于我之前文件管理的不规范，同一份文件经常被复制到了多个路径，可以试着使用「Everything」搜索一份文件：
像图中所示，同一文件出现在四个不同的路径，并没有进行统一管理。这种情况的弊端是当我修改某一路径下的文件，其他路径并不会同步更新，造成版本混乱。
特别是当某个文件曾经历过多次修订，并且通过微信等通信工具不断转发出现了非常多的「相似版本」，而且现在你也不确定到底哪个版本才是当时领导最终拍版的版本，只能每一份都点进去浏览……这是我经历过最痛苦的事情。
放弃分类，只用一个文件夹
如何解决我的两个痛点呢？先来看看第一个痛点的解法：既然分类无法满足我的需求，那么干脆就不要进行分类。
分类法的核心是运用文件夹对文件归档整理，而基于搜索的文件管理法则完全不需要文件夹的辅助。那么第一步就是把所有类型的文件一股脑儿地丢进同一文件夹（甚至可以直接归入某个磁盘分区），将此文件夹作为资料库（搜索的根路径），即每当我们需要任何资料均在此文件夹下搜索。
这么做有以下几点好处：
- 将文件资料统一管理，避免路径或版本混乱
- 提高搜索性能（本方案可直接使用 Windows 资源管理器自带的搜索功能，只是在文件数达到一定量级后速度会下降）
- 方便被其他项目链接，确保文件的唯一性（后文会对此进行讲解）
当然本文指的文件类型指的是：word、pdf、txt、png、md、mp3、mp4 等文本或媒体文件。诸如系统文件、程序文件之类的不在本文的探讨范围。
可能有读者朋友会觉得，啊？所有文件都放在同一个文件夹，这看起来也太乱了吧！
看上去确实会比使用分类法混乱，但各位仔细回想一下：我们在什么时候才会打开文件资源管理器浏览文件？正如前文所述，大部分情况下我们只有在需要查找某份文件的时候才会进行浏览。基于搜索的方案下，我们完全不需要「浏览」这个动作。
但搜索的前提是你明确知道自己有这份文件（即使记忆有些模糊），如果没有分类法的支持，那些完全消失在记忆中的文件该怎么查找？
稍后再解答这个问题，现在让我们继续。搜索法的核心是搜索文件名，所以还需要制定一个统一的文件命名规则。
制定文件命名规则
在本地磁盘搜索某些特定的文件时，如何才能使搜索结果更加符合预期呢？
试想一下，假设你是一个财务人员，领导要求你收集 2023 年 10 月份的所有发票，在输入框中应该输入什么内容才能覆盖所有符合要求的发票文件（先不考虑正则语法）？
很明显应该输入关键词： +，但这不过是理想化状态。倘若自己的本地文件命名方式十分随意，譬如日期的格式还有可能为：2023-10-06、2023.10.6，那么使用上述关键词并无法覆盖这些发票文件。
所以，文件的命名需要基于一定的规则，这一步中读者朋友们可以使用自己喜欢的命名方式，这里我贴出自己的格式：
主类别子类别文件名补充信息文件日期版本号>
其中：
主类别>：必填，每个文件至少需要一个类别，比如：身份证、劳动合同、发票
- 复合名词而不是单一名词，比如你应该写「劳动合同」而不是「合同_劳动合同」
子类别
文件名>：必填，填写该文件规范的名称
补充信息>：选填，可填写文件的一些方便你精准搜索的补充信息比如：草案、草稿、大纲、测试……
文件日期>：必填，此处可以是文件本身的日期属性（比如发票的开票日期）也可以是文件的保存日期或者其他，按你自己的需求决定就好
YYYYMMDD
版本号>：必填，用于区分同一文件的不同版本，相信经常被甲方更改需求的朋友应该能理解我制定此标签的原因……
其他注意事项：为了保证搜索结果的纯净，文件名中尽量不要包含重复的描述，在下文的示例中：劳动合同_xx 公司劳动合同_20240204_1，是不建议的写法
按照以上规则，下面是几个规范的命名示例：
- 劳动合同_xx 公司_20240204_1.pdf
- 建筑工程设计合同_xx 项目_草案_20240202_1.doc
- 建筑工程设计合同_xx 项目_草案_20240203_2.doc
- 发票_xx 项目_设计费_已支付_未申报_20240201_1.pdf
制定以上规则后，当查找文件时只要使用关键词即可快速筛选文件，比方说我想查找 2 月份所有已支付但还未进行申报的 xx 项目的发票，我可以在 Windows 自带的资源管理器中输入关键词：xx 项目 未申报 202402 即可快速定位符合关键词的文件：
可以看到，使用 Windows 自带的搜索功能就能精确搜索出我们需要的文件。
当按照这种规则执行了一段时间后，你会发现：咦，放弃「分类法」之后，本地文件也没有想象中看起来这么乱嘛？
聪明的读者其实已经发现，「分类」并不是被我抛弃了，而是以另一种形式存在于文件名里。「分类法」中文件被保存在多个层级；而基于本规则，文件被平铺在单一层级，因此浏览效率实际上也会高出不少。
简单总结一下到此为止的内容，基于搜索的文件管理方案最重要的要求只有两点：
- 只使用一个文件夹管理
- 制定规范的文件命名规则
但光是如此并无法解决我的痛点之二：文件管理混乱，接下来就让我们解决这个问题。
使用「链接」而不是「复制」
文件混乱的罪魁祸首就是「复制」。Windows 使用的是 NTFS（New Technology File System）文件系统，在 NTFS 中，每个文件都有一个唯一的标识符（inode），该标识符存储了文件的元数据信息，包括文件名、大小、创建时间、修改时间等。当执行「复制」操作时，操作系统会根据源文件的 inode 创建一个新的 inode，并将源文件的数据块逐个复制到目标位置上。
这就意味着实际上「复制」出来的文件与源文件已经不是同一个文件了，复制出的文件会在磁盘中额外占用一块空间。
假设我有一个「文件 A」，它可能会被多次更改，并且同时被多个项目文件需要，比如以下目录结构：
- G:\资料库
- 文件 A
- F:\建设项目\x 公司建设工程
- 文件 A
- F:\建设项目\y 公司建设工程
- 文件 A
如果使用「复制」，那么「文件 A」会在磁盘中占用三份空间，并且任意目录下对「文件 A」的修改，其改动均不会同步到其他两个文件，这不仅在同步更新三个目录的文件内容时比较费劲，在日后进行搜索回溯时同样会产生巨大的困难。
所以我推荐使用「软链接（Symbolic Link）」的方式处理这种情况。
Windows 下的软链接是一种符号链接，文件后缀名为
.symlink，软连接创建的链接文件只保存了被链接文件的路径等信息，不保存被链接文件的数据。它可以指向另一个文件或目录，有点类似于我们更加熟知的「快捷方式」，有程序经验的朋友也可以将软链接理解为「指针」。它们提供了一种在不复制实际文件的情况下访问源文件的方法。
在我的文件管理方案里，所有文件资料被统一保存在「资料库」中，每当其他项目需要使用其中的文件时我会将「资料库」的对应文件创建一个软链接，以此确保文件的唯一性。
同样以上文的例子说明，我们可以改用「软链接」的方式引用资料库中的「文件 A」。以管理员方式打开「CMD」，输入以下指令：
mklink F:\建设项目\x 公司建设工程\文件 A G:\资料库\文件 A
mklink F:\建设项目\y 公司建设工程\文件 A G:\资料库\文件 A基础语法为：mklink 目标文件地址 源文件地址
此时文件结构就变为：
- G:\资料库
- 文件 A
- F:\建设项目\x 公司建设工程
- 文件 A（.symlink）
- F:\建设项目\y 公司建设工程
- 文件 A（.symlink）
使用这种方法，「文件 A」在磁盘中仍然只占用一份空间，其他路径下的「文件 A」只不过是通过「软链接」的方式建立的一个符号链接，点击后均会打开源文件（G:\资料库\文件 A），不论哪个路径下对「文件 A」的修改都会同步到其他两条路径（因为本质上打开的都是同一个文件）。
结语
到此，我们将文件资料以标准的命名规范统一管理，并且使用「软链接」确保了文件资料的唯一性。
笔者已在自己的办公电脑上进行了两个月的实践，当我需要查找某份文件时，只需要打开「资料库」输入几个关键词即可轻松筛选出需要的文件，不需要「Everything」，也不需要正则语法就能达到如此高效的搜索，着实令我惊喜。
此方案实实在在地解决了我的两个痛点，于是分享出来，欢迎交流讨论。
