▍前言
前段時間領導需要一份半年前的 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 自帶的搜索功能就能精確搜索出我們需要的文件。
當按照這種規則執行了一段時間後，你會發現：咦，放棄「分類法」之後，本地文件也沒有想像中看起來這麼亂嘛？
本地文件看起來也並沒想像中亂
這是因為我們在上文制定的規則里將 放在文件名的開頭，這使文件可以按照類別自動排序，相同主類別的文件總是集中在一起。這也回答了前文拋出的問題，即使放棄「分類法」，通過瀏覽文件資源管理器，我們也可輕鬆找回在記憶中丟失的文件。
聰明的讀者其實已經發現，「分類」並不是被我拋棄了，而是以另一種形式存在於文件名里。「分類法」中文件被保存在多個層級；而基於本規則，文件被平鋪在單一層級，因此瀏覽效率實際上也會高出不少。
簡單總結一下到此為止的內容，基於搜索的文件管理方案最重要的要求只有兩點：
-
只使用一個文件夾管理
-
制定規範的文件命名規則
但光是如此並無法解決我的痛點之二：文件管理混亂，接下來就讓我們解決這個問題。
▍使用「鏈接」而不是「複製」
文件混亂的罪魁禍首就是「複製」。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」，也不需要正則語法就能達到如此高效的搜索，著實令我驚喜。
