三年前簽的一份代理合約要續約，法務請你把「當時雙方用印的最終版」調出來。你打開共用資料夾，裡面躺著 合約.docx、合約_修改版.docx、合約_final.docx、合約_final2.docx、合約_老闆確認.docx，五份的修改日期還全被「另存新檔」洗成了同一天，檔名沒有一個告訴你哪份才是真正用印的版本。當初經手的同事早就離職，於是你花了整個下午，逐字比對五個檔案的差異。
找不到正確版本，很少是誰特別粗心，而是團隊把「記錄版本」這件事，交給了很不可靠的載體：檔名，加上每個人各自的命名習慣。以下八條規則分成四組，講檔名與資料夾怎麼取才禁得起三年後的翻找，每條都附一組錯誤與正確示範；此外也會談到，把檔案搬上雲端協作平台後，哪幾條可以交給工具維持、不必再靠人力盯著。
檔名本身就要能排序、能辨識
好檔名不必打開，光看名字就知道它是什麼、第幾版、能不能用。這一組的三條規則，管的都是檔名字串本身。
日期放最前面，格式用 YYYYMMDD
檔名的第一個欄位放日期，格式固定用 YYYYMMDD（西元年、月、日，中間不加符號）。
錯誤示範：會議記錄.docx、報價單(新).xlsx。正確示範：20260813_業務週會記錄.docx、20260813_大新公司報價單.xlsx。
把年月日由大到小排在最前面是有道理的。維基百科的 ISO 8601 說明指出，日期的基本格式就是 YYYYMMDD，而當時間單位由大到小排列時，較早的時刻在字典序上會先於較晚的，因此有利於按時間排序。白話說，檔案總管照名稱排一次序，就等於照日期排好了，不必再另外整理。反過來，用斜線或國字的寫法（8/13、八月）會讓排序整個錯亂，一律避開。
版本號標在結尾，大改進位、小改點號
同一份檔案的不同版本，用 v1、v2、v2.1 這種版本號標在檔名結尾。
錯誤示範：提案_new、提案_修改、提案_修改後2。正確示範：提案_v1、提案_v2、提案_v2.1。
史丹佛大學圖書館給研究人員的檔案版本建議，其中一條就是在檔名裡放版本號，例如 v1、v2 或 v2.1。落到日常用法很單純：整份大改（換了方向、重寫段落）就進位到下一個整數，小修（改錯字、補一小段）就用點號往下加。這樣任何人看到 v2.1，都知道它是 v2 之後的小改版本、屬於同一份檔案的延續，不必猜。
拿掉「最終版」「真的最終版」
檔名裡永遠不要出現「最終版」「定稿」「真的最終版」這類字眼。
錯誤示範：合約_final、合約_final2、合約_final_真的最終版。正確示範：合約_v3_定稿。
史丹佛圖書館的同一份建議特別提醒：標狀態是可以的（draft 或 final），但別堆疊成 final2、final_revised 這種反而讓人混淆的名字。原因很直白，世界上沒有真正的最終版，永遠會有下一次修改。與其宣稱最終，不如讓版本號自己往上加；真要標「這一版是不是對外定稿」，就用一個固定的狀態詞（例如結尾加 _定稿），而不是把好幾個「最終」疊在一起。
讓檔名帶上歸屬：部門與專案
檔名除了時間與版本，還要回答「這是誰的、屬於哪個案子」，靠的是部門前綴與專案代號。
檔名前面掛部門或負責人代號
會被跨部門共用的檔案，在檔名前段加上部門或負責人的固定代號。
錯誤示範：損益表.xlsx、名單.xlsx（誰的損益？哪來的名單？）。正確示範：FIN_20260813_Q2損益表_v1.xlsx、HR_20260813_到職名單_v1.xlsx。
Lark 的搜尋與資料治理建議也示範過類似做法：文件標題用一致命名，例如「客戶名稱_專案名稱_日期」，群組名稱也加上部門、專案或年份。部門代號建議全公司統一（財務 FIN、人資 HR、業務 SALES），並寫進命名字典，免得張三寫「財」、李四寫「會計」，同一個部門長出三種前綴。
專案代號從開案沿用到結案
每個專案從一開始就給一個固定代號，讓它貫穿所有相關檔案與資料夾。
錯誤示範：同一個案子，業務叫「大新案」、PM 叫「A 客戶」、財務叫「三月那個專案」，三邊的檔案永遠兜不到一起。正確示範：全案統一代號 A2026，檔名寫 A2026_20260813_合約_v1，資料夾也叫 A2026_大新公司。
代號建議短、不帶中文歧義、最好包含年份（例如 A2026、P07）。這套邏輯早就有人在用：連 Lark 審批的流水號編碼常採「名稱＋日期＋序號」，讓單據方便查找與追溯，可見「代號＋日期」是被廣泛驗證過的命名骨架。
資料夾與封存，決定三年後找不找得到
資料夾結構與封存機制，決定的是三年後這份檔案還找不找得到。這一組把「怎麼收」講清楚。
資料夾別堆超過兩三層
資料夾層級壓在兩到三層以內，深度不夠就用搜尋補，不要靠無限往下開資料夾來分類。
錯誤示範：公司/部門/年度/季/專案/子專案/草稿/ 點了七層還沒看到檔案。正確示範：業務/A2026_大新公司/ 兩層到底，其餘靠檔名與搜尋定位。
深層資料夾真正的問題是：每個人心裡的分類路徑都不一樣，你放在「客戶/大新」，同事去「專案/進行中」找，於是同一份東西被存了兩次。搬上雲端後這件事更清楚：Lark 雲端檔案的「我的檔案庫」與知識庫都改用頁面樹的層級來管理、不提供建立資料夾，因為內容可以直接被搜尋，分類的角色被搜尋接手了大部分。
定案後把舊版收進封存
一份檔案定案後，主動把散落的舊版與副本收斂掉，讓現行版只留一個公認的家。
錯誤示範：五個版本永遠並排在資料夾裡，每次要用都得重新猜哪個對。正確示範：定案版留著，舊版轉唯讀或移進 _封存 位置；真的沒用的，刪除進回收站。
封存要看資料的類型。結構化的清單資料（訂單台帳、合約清冊）可以用 Lark 多維表格的封存表，把不再更新的記錄歸檔成唯讀，適合已結束專案、已完成合約，前提是企業已開通這項功能。文件類沒有一鍵封存的按鈕，做法是把定案內容收進知識庫統一維護、舊副本用權限轉唯讀，或直接刪除進回收站（雲端檔案刪除後 30 天內都還能恢復）。這一步和單一事實來源是同一個方向：同一份內容只留一個會被更新的版本，需要開會仲裁「哪份才對」的次數就會往下掉。
把規則寫成一份團隊命名字典
命名規則要真正發揮作用，前提是整個團隊用同一套，而不是每個人有自己的一套。
命名字典就是把整套約定寫下來的那一頁文件：欄位的先後順序、用什麼當分隔符號、部門與專案代號表、狀態詞怎麼寫，全部講清楚。
錯誤示範：規則只存在資深員工的習慣裡，他一離職，命名就開始各行其是。正確示範：一頁命名字典，明訂 部門_日期_內容_版本 的欄位順序、統一用底線當分隔符，附上部門代號表與專案代號表。
命名字典本身就適合放進企業知識庫，當成新人入職指南的一頁；往後有人命名卡住，回覆頁面連結，比每次口頭教一遍省力。字典不必一開始就完美，先把「欄位順序」和「分隔符號」這兩件最容易分歧的訂下來，跑一陣子再補其他。
搬上雲端後，有些規則可以退休
檔案命名規則多半是為「檔案散在各台電腦與共用資料夾」的年代設計的；把檔案搬上雲端協作平台後，其中幾條可以交給工具維持，不必再靠人力盯。
最明顯的是版本尾碼。Lark 雲端檔案的歷史記錄會自動留下依時間倒序、含修改人與修改時間的每一個版本，大家改的是同一份檔案，要回頭就翻歷史記錄。手動把 v1、v2 掛在檔名上的需求因此明顯下降，改壞了也能還原到過去任一版。
其次是深層資料夾。雲端文件與知識庫的內容可以被全文搜尋（搜尋結果仍受權限限制，沒權限的人不會因搜尋而看到內容），要找一份東西，打關鍵字比一層層點資料夾快得多，分類的工作被搜尋接手，資料夾自然可以做淺。
但有兩件事雲端接不住，得說清楚，這也是可信度的一部分。第一，搜尋強不等於可以不命名。談 Lark 搜尋與知識問答的導入說明講得很直接：歷史紀錄適合短期回溯，不應取代正式的文件整理與命名規則；搜尋與知識問答的價值不在功能本身，而在資料治理。命名一致、結構乾淨、同一問題不散落多份版本，搜尋才找得準。第二，歷史版本能保留多久、留幾個、佔多少容量，會因方案與產品設定而不同，建議與我們確認，不憑印象亂給數字。
推行順序：先跑順一類檔案
命名規則的推行不必全公司一起改，從最常出事的那類檔案開始，反而更容易成功。
實際的順序建議是這樣：先挑團隊最常吵「哪份才是最新」的那類檔案（合約、報價單，或某份共用報表），把命名字典的欄位順序與分隔符號先訂下來，只在這一類檔案上先跑。跑順了，再把規則擴到下一類。主管要帶頭用，因為規則對上不對下很快就會失效；有人沒照規則命名時，溫和提醒、給字典連結，而不是罵人。已經被 Excel 綁住的清單型資料若想一併搬上雲端表格，可以參考從 Excel 到自動化的遷移做法。
不用等全公司開一場命名大會。挑那個曾經讓你花一下午比對五個檔案的資料夾，先把它變乾淨，三年後要調閱時，你會謝謝現在動手的自己。
想把散在各台電腦、共用資料夾裡的檔案與版本，一次收斂成一套多人即時共編、自動留歷史的雲端環境，找艾瑞特資訊聊聊。身為 Lark 台灣授權代理商，我們可以用你們的真實檔案，示範命名字典怎麼訂、歷史記錄怎麼看、舊副本怎麼收。
常見問題
以下彙整檔案命名與資料夾整理最常被問到的五個問題。
Q1：檔名到底要放哪些資訊才不會亂？
好檔名建議固定放四個欄位：部門或負責人代號、日期（YYYYMMDD）、內容描述、版本號，用底線串起來，例如 FIN_20260813_Q2損益表_v2。日期放最前面可以讓檔案照時間自動排序，版本號標在結尾方便追最新版；欄位的先後順序全隊統一、寫進命名字典，是不亂的關鍵。
Q2：為什麼檔名不要用「最終版」「真的最終版」？
「最終版」這種字眼不該出現在檔名裡，因為世界上沒有真正的最終版，永遠會有下一次修改，於是長出 final2、final_真的最終版 這種越疊越亂的名字。史丹佛大學圖書館的建議是用版本號（v1、v2、v2.1）標版本、必要時用單一狀態詞（draft 或 final）標狀態，但不要把好幾個修訂標記堆在一起。
Q3：資料夾結構應該分多深才合理？
資料夾建議壓在兩到三層以內，剩下的定位交給一致的檔名與搜尋。層級開太深，每個人心裡的分類路徑不同，同一份檔案會被存到不同地方；雲端協作平台如 Lark 的「我的檔案庫」與知識庫甚至改用頁面樹、不提供建立資料夾，因為內容可以直接被全文搜尋，分類的角色被搜尋接手了。
Q4：有了雲端搜尋和歷史記錄，還需要命名規則嗎？
命名規則仍然需要，雲端搜尋強大不等於可以不命名。Lark 的搜尋與歷史記錄能取代手動的版本尾碼與深層資料夾，但搜尋要找得準，前提仍是文件標題命名一致、內容乾淨、同一問題不散落多份版本；歷史記錄也只適合短期回溯，不能取代正式的文件整理。工具接手的是重複勞動，紀律的部分還是團隊自己的事。
Q5：命名規則要怎麼在團隊推行？
命名規則的推行靠三件事：把約定寫成一份人人看得到的命名字典、主管帶頭遵守、先在一類最常出事的檔案上跑順再擴大。規則對上不對下就會失效，所以主管自己要先照做；有人命名卡住時回覆字典連結、而不是每次重講一遍，讓「照字典命名」慢慢變成團隊的肌肉記憶。