寫在前面#
國慶假期，工作室有幸參與了 《CCTV 央視 2025 品牌強國工程發布會》 開場片的製作。全程不能說是磕磕絆絆吧，簡直是連滾帶爬。這種專案的節奏非常快，製作週期一共只有 20 天時間，沒得商量，而視頻規格卻高的離譜，時長 90 秒，出片解析度：7036 x 1000 像素，30fps。
更兇殘的是迭代速度，專案完成後我自己統計了一下，別的同事不知道，光我一個人負責的鏡頭，在進組的 12 天內，就修改迭代了 70 稿，整個專案的資料夾有 280G 的數據。
團隊一共 10 個人，同時又分散在多個省市遠程協作。排除技術難點，如此緊張的節奏，高效的流程把控和檔案管理也是完成這類大型專案的必要條件。這篇文章不會大篇幅描述讓人犯困無聊的專業知識，主要分享可以應對大部分場景下的遠程數位化協作都有幫助的檔案管理和命名規範，也是自己對這次經歷踩過的各種坑進行一次復盤。
清晰的目錄結構#
曾在 《2024 年，如何優雅使用 WindowsPC》 中一筆帶過我的工作目錄模板，如下：
project name
- doc
- pj
- render
然而，由於涉及團隊協作，目錄結構根據這次的專案做了相應調整：
project name #專案名稱
- 01-in #上游同事提供的檔案
- 02-doc #文檔和參考資料
- 03-pj #工程檔案
- tex #工程檔案會調用到的素材
- 04-export #輸出目錄
- pre #用於審核的預覽檔案
- render #輸出給下游同事的檔案
這樣做有幾個好處：
- 頂級目錄手動加入序號前綴，可以強制按照輸入 ➡ 輸出的順序排列，檔案流向清晰直觀。
- “in” 目錄下，上游同事發來的檔案不做任何改動，自己再另存一份到工程目錄下，以防不慎修改後再向同事要一次，節約他人時間。
- 依然儘可能保持最少粒度的目錄數量，充分利用電腦自帶的 “按類型 / 日期 / 名稱” 等排序功能減少不必要的目錄，節約查找時間，同時還可以減少打開的窗口數量，螢幕空間也是很寶貴的。
- 有利於版本回溯，雖然不像 Git 這種先進版本控制系統快捷方便，且 Git 更擅長程式碼或純文本類型的檔案處理，但是依舊可以相對快速的定位檔案，幫助專案的優化和品質把控。
有利就有弊，這麼做缺點也有：
- 由於專業軟體的插件等特性，建議目錄最好為非中文，這樣別人不易看懂，有效解決方法是用中文名打包，若結構更複雜一些可在專案根目錄寫一份 “說明文檔”。
- 新上手的夥伴需要一定的學習和理解成本，在專案緊急或突發狀況下反而會拖慢效率。
- 目錄結構相對僵化，專案一旦規模超預期，多出很多分支任務的時候，子目錄極易趨於複雜，一定程度上會增加誤操作的機率。
- 可能不適用於搜索，因為動畫專案輸出的序列和檔案數量巨大，搜索反而更耗時。
先讓自己看得懂#
無論做什麼類型的數位化工作，清晰的目錄結構和檔案命名習慣都起着至關重要的作用。在我看來首當其衝的關鍵在於先讓自己看得懂，準確地講，是讓未來的自己看得懂。
這樣就算以後搜索的時候，即便已經忘記了很多細節，無需預覽，只看目錄結構和名字也更容易確認檔案的大致用途。
說句題外話，相信我，一定要對過往的專案進行整理和復盤，無論商業還是原創，你的隱形財富就藏在裡面。
檔案命名規範的要點#
一句話總結：在系統的整體命名規範下，以你的生產流程為準則。
接下來分別說明。
Windows 下的檔案命名準則#
其實 微軟在官方文檔中 是對檔案命名有詳細說明的，我整理了一些需要注意的要點：
- 所有檔案系統都遵循單個檔案的相同常規命名約定：基檔名和可選擴展名，用句點分隔。
- “目錄” 只是具有特殊屬性的檔案，該屬性將其指定為目錄，但不管怎樣，必須像常規檔案一樣遵循所有命名規則。因此，除非另行指定，否則檔案的任何命名或使用規則或示例也適用於目錄。
- 不要假定區分大小寫。例如，將名稱 OSCAR、Oscar 和 oscar 視為相同，即使某些檔案系統可能將其視為不同。我自己雖然會在磁碟和專案根目錄使用大小寫區分，但僅僅只是為了方便查看和美觀，他們的內容本質沒有區別。
- 不要用空格或句點結束檔案或目錄名稱。
macOS 下其實大同小異。
規範命名的構成要素#
具體到實際工作，我習慣的命名十分精簡。以這次三維動畫專案為例：
其中製作花苞的 c4d 工程檔案名為 “huabao-anim-1004.c4d”，整個名稱分為：
命名詞：huabao（花苞）
所屬類別/狀態：anim（表示是用來製作動畫的工程）
創建時間/版本：1004（10月4日創建）
另外一個 “牡丹” 的工程檔案也是：
命名詞：Mudan（因為它在模型結構上屬於花苞的父級，因此大寫）
所屬類別/狀態：solo（表示單體靜態模型，裡面沒有製作動畫）
創建時間/版本：0929（9月29日創建）
是不是非常簡單，這樣無論是我還是同事，很容易就可以看出每個檔案的作用和狀態。不用檢索，只要正常保持按名稱排序可非常容易找到。
另外值得一提的是分隔符的使用，一般為短橫線 - 和下劃線 _，短橫線在英文中作為連字符，但在檔名內可以非常好的用於劃分信息類別，而我不使用下劃線做分隔是因為在程式中，下劃線通常被等同於空格。
不斷測試和優化#
羅馬不是一天建成的。當你給自己制定好一個初步的命名規範之後，最好先在小規模的專案中試用一段時間。在推進過程裡觀察同事和自己是否能夠很快適應並接受這種方式，就像遊戲內測一樣。
如果同事提出了困惑和建議，一定要詢問清楚理解困難和感受不方便的地方。弄明白到底是命名規範不合理，還是團隊之間的溝通問題。
之後再通過更大規模的合作和專案需求，進一步擴展和迭代更多的命名規範，這樣團隊的配合效率才會無形中提升。
總結#
規範的檔案命名背後意味著高度的概括和歸納能力。這種能力不僅是職場專業人士的必備技能，也是作為設計師或工程師對其領域專業程度的一種體現。
給檔案命名是一個思考的過程，人是愛偷懶的，大腦本身更偏愛低能耗的運作方式。人類焦慮和煩惱永遠來自於 “趨利避害” 與 “急於求成”，而我更願意相信 “慢就是快”。
如果你有更好的檔案命名方式，歡迎留言討論分享。
參考：#
本文首發在 CGArtLab