混亂的代價
整齊的資料夾不會讓小說變好。
這句話聽起來像是在替懶散找藉口，但認真想一下——多少作家花了整個下午設計完美的資料夾結構，色彩編碼的標籤系統，精心命名的檔案，然後一個字也沒寫？檔案管理變成了一種偽裝成工作的拖延症。
問題是，這個反直覺的觀察只對了一半。
整齊的資料夾確實不會讓小說變好。但混亂的資料夾會讓小說寫不完。Tolkien 花十二年寫《The Lord of the Rings》，五十萬字，三卷本，精靈語有文法手冊，中土世界有等比例地圖，皇室血統有家譜圖。他不是因為資料夾整齊才寫得好——他是因為資料找得到才寫得完。
差別在這裡。
「第三章-最終版-真的最終-這次是真的.docx」。這個檔名背後藏的不只是命名問題。角色設定散在桌面某個角落，三個月前寫的那段對話不知道存在哪個版本，主角到底是獨生子還是有個哥哥——翻了半小時還沒查到。
心理學研究管這叫「任務切換成本」。每一次從寫作模式跳到找檔案模式，大腦都得重新暖機。一次兩次沒什麼。一天十次，一週七天，三個月下來，消耗掉的不是時間，是意志力。坐下來的時候已經累了。還沒開始寫，就想關電腦。
所以真正的問題不是「要不要整理檔案」。是怎麼用最少的力氣建一套系統，讓整理這件事從此不再佔據腦袋。
書籍作為儲存庫
軟體工程師幾十年前就碰過一模一樣的困境。
一個程式碼庫幾百萬行，幾十個人同時在改，版本清楚、歷史可追溯、任何時間點都能回滾。靠的不是超強記憶，是版本控制系統——把整個專案當一個有結構的儲存庫來管。
Slima 做的事情就是把這套邏輯搬進寫作。打開 File Tree，看起來像普通的資料夾。但底層完全不同——每一個檔案的變動被追蹤，每一個歷史版本被保存，任何時候都能回到過去的狀態。
一本書不再是一堆散落的 .docx。它是一個有層級、有歷史、有記憶的儲存庫。創作過程和創作結果，同時被保管。
這聽起來像工程師才需要的東西。但想想看——哪個作家沒有過「早知道不改那段」的懊悔？
建立結構
來談實際操作。
經過驗證的長篇小說結構長這樣：
我的小說/
├── 草稿/
│ ├── 第一部/
│ │ ├── 01-開端.md
│ │ ├── 02-衝突.md
│ │ └── 03-轉折.md
│ ├── 第二部/
│ └── 第三部/
├── 角色/
│ ├── 主角群/
│ ├── 配角/
│ └── 反派/
├── 世界觀/
│ ├── 地點/
│ ├── 歷史/
│ └── 規則系統/
├── 研究資料/
└── 大綱與計劃/
├── 總大綱.md
├── 分章大綱.md
└── 時間線.md
核心原則只有一個：草稿歸草稿，角色歸角色，世界觀歸世界觀。查一個角色的背景不用翻草稿。確認地點描述不用在全文搜尋。東西在哪裡，不需要想就知道。
這種分離帶來一個附加效果——AI Assistant 會變得更聰明。在 AI Chat Panel（Cmd+Shift+A）裡引用「角色/主角群」資料夾，AI 立刻知道語境是角色設定而不是情節推進。結構化的資訊讓 AI 給出的回應精準得多，不會答非所問。
結構也不是刻在石頭上的戒律。寫到一半發現需要一個「刪除片段」資料夾？加就是了。需要拆分世界觀裡的「歷史」成上古和近代？拆就是了。File Tree 支援拖放，改結構跟搬積木一樣。
命名的藝術
檔案命名這件事，九成的人低估了它。
傳統的做法是在檔名前面加數字：01-、02-、03-。工程師這樣做是因為程式碼編輯器按字母排序。但 Slima 的 File Tree 支援拖曳排序——檔案和資料夾都可以直接拖動調整順序，不需要靠檔名。
所以章節可以直接用標題命名：
風暴前夕.md
相遇.md
第一個秘密.md
想調順序？拖。比改檔名快十倍，檔名也乾淨。當然，如果習慣數字前綴，或者需要匯出後在其他工具裡維持排序，數字前綴仍然是好選擇。看個人。
角色檔案建議帶上定位：
李明-主角.md
王教授-導師.md
黑衣人-神秘反派.md
這樣命名的真正好處在搜尋。按下 Quick Open（Cmd+P），輸入「主角」，所有主角相關檔案跳出來。輸入「反派」，所有反派一覽無遺。不用記住每個角色叫什麼名字。
世界觀檔案的命名更直接：
✓ 北方王國歷史.md
✗ 設定3.md
「設定3」在建立的當天可能還記得內容。三個月後？完全不知道。「北方王國歷史」永遠不會有這個問題。
重新命名也簡單——在 File Tree 裡按 F2 就進入重新命名模式，內部連結自動更新，不用擔心斷掉引用。
版本控制：永遠可以回頭的安全感
Tolkien 的筆記系統有一個致命弱點。
改了就改了。舊版本消失。想回頭看三個月前的設定？不存在了。除非他另外抄了一份——但誰會在修改之前先手抄一份備份？
Slima 的 Version Control 從根本上消除了這個問題。按 Cmd+Shift+G（Mac）或 Ctrl+Shift+G（Windows），時間線展開，每一次修改都有記錄。
Snapshot 是手動存檔點。完成一章——存一個。準備大改——存一個。收到 Beta Reader 回饋，要開始動刀——存一個。任何覺得「目前狀態還不錯」的時刻，都值得按一下。
但真正改變遊戲規則的是 Branches。
分支這個功能，目前市面上沒有其他寫作工具提供。概念很直覺：在不碰主線的前提下，開一條平行線去探索可能性。
寫到中段，腦中閃過一個念頭——「如果導師在這裡死掉呢？」。傳統做法是複製整個專案，在副本裡亂改，改壞了刪掉副本，改好了但想兩個版本都留著就陷入管理地獄。
Slima 裡，建一個分支，取名「experiment/mentor-dies」。在分支裡盡情改寫——主線一個字都不會動。滿意就合併回主線。不滿意就切回主線，分支保留在那裡，不干擾任何東西。
這種安全感會改變寫作心態。不是「可能」會改變，是一定會。因為刪掉一整章不再是不可逆的決定，大膽嘗試的心理門檻直接歸零。
整理現有的混亂
已經有一堆散落各處的檔案了。來得及整理嗎？
來得及。什麼時候都來得及。
盤點先做。打開桌面、下載資料夾、雲端硬碟、郵件附件——把所有跟專案有關的檔案列出來。這個過程通常會帶來衝擊：原來東西散成這樣。
分類接著來。草稿內容、角色設定、世界觀資料、研究參考、大綱計劃。有些檔案分不清楚歸哪一類，丟進「待整理」資料夾，別卡在這步。
然後在 Slima 裡建好資料夾結構，把檔案一個一個搬進正確位置，順手按命名規範改名。這個過程繁瑣。但只做一次。
搬完的那一刻，立刻建一個 Snapshot。這個快照標記的是轉折——從混亂到有序。
不確定該怎麼分類？AI Assistant 可以幫忙。打開 AI Chat Panel，把檔案清單貼進去：
這是我的小說專案目前的所有檔案：
[列出檔案清單]
請根據內容類型，建議一個適合的資料夾結構，並說明每個資料夾的用途。
幾秒鐘就會得到一份量身定做的建議。
從零開始的新專案
如果是全新的長篇計劃——恭喜，這是最好的起點。
動筆之前，先把資料夾結構搭好。感覺像在浪費時間？恰恰相反。三週後需要新增一個角色設定，不用猶豫放哪裡。兩個月後需要補一段研究筆記，路徑清清楚楚。前期花十五分鐘，整個專案省下幾十小時的摩擦。
模板檔案也值得準備。在角色資料夾裡放一個「_角色模板.md」，列好記錄項目：基本資訊、外貌、性格、背景、在故事中的功能。新增角色的時候複製一份，填空就好。不用每次重新想該記什麼。
結構會隨專案長大。可能需要新的資料夾，可能發現某兩個資料夾該合併。這很正常。Slima 拖放重組，Version Control 隨時回滾，改壞了就退回去——沒有什麼改動是不可逆的。
Tolkien 靠一套紙本筆記系統管理了十二年的創作。沒有電腦，沒有搜尋功能，沒有版本控制。靠的純粹是紀律和設計。
工具換了。紙本變成 Writing Studio，手抄備份變成 Snapshot，剪刀糨糊變成 File Tree 裡的拖放。但底層的思維沒有變——把書當作一個需要管理的專案，不是一堆隨意堆放的檔案。
好的結構不會限制創意。它做的事情更微妙：把「找東西」這件事從意識層面移除，讓注意力完整地留給故事本身。
下一篇，我們談角色資料庫——怎麼像 Tolkien 追蹤中土世界血統那樣，追蹤故事裡的每一個人物。