模組一｜為什麼把小說當專案管（Day 1–4）

昨天講了四個「這其實是工程問題」的瞬間。今天講第一個具體做法。

先講一個很多人會做、而且做得不錯，但只做一半的事：把設定集中到一個檔案裡。

這件事本身是對的。散在各章的設定必然會互相矛盾，因為你不會為了確認一個細節去翻 200 個檔案。集中管理是最基本的一步。

但我做完之後遇到了新問題。

問題：設定集中了，但沒人（包括我）會去讀

我的世界觀文件長這樣：

docs/WORLDVIEW.md    1,113 行    42,390 字元

六個大章：核心命題、歷史層、地理層、文化層、敘事整合、據點循環。裡面有大靜默的三種互相矛盾的說法、島上五個深度的存在權分層、香門四式的戰法規則、靜默紀的食衣住行，寫得很完整。

然後我開始寫第 37 回。

我要寫一個角色在夜市買東西的場景。按理說我應該先去查「靜默紀的市街民生層」那一節，確認交易方式、貨幣、有沒有電。

但我沒有。 因為那一節在第 435 行，而我腦子裡想的是這一回的鉤子要怎麼收。

於是我憑印象寫了。寫完隔兩天回頭看，發現跟設定對不上。

這就是集中管理的極限：一份 42,390 字元的文件，不會有人在每次動筆前讀完。 它解決了「設定在哪裡」，但沒解決「動筆前要看什麼」。

怎麼做：把知識和執行拆成兩份文件

我後來加了一份很短的檔案：

docs/NOVEL-STATE-SYSTEM.md    79 行    2,730 字元

它的開頭第一句話就把定位講死：

用途：這是每次寫、改任何一章前的「執行表」，不是給讀者看的設定集。先讀本檔與 WORLDVIEW.md，再寫場景。世界觀只在角色必須做選擇時出現；沒有改變選擇的設定，一律不進正文。

注意兩份文件的比例：

1 : 15.5。 每次都要讀的那份，只有知識庫的十五分之一。

這個比例不是省出來的，是篩出來的。執行表裡只放「會改變我下一步怎麼寫」的東西，其他一律留在知識庫。

執行表裡實際有什麼？舉兩個例子。

一、寫章節的固定流程

1. 從台帳讀「本章結束狀態」與「下一章不得忘記」。
2. 先寫一個封面兌現的畫面，再寫衝突；不可先講設定。
3. 寫完檢查：刪掉所有未改變任務、關係或伏筆的段落。
4. 更新台帳：只記角色關係、傷／物件、未解問題的狀態改變。

四步，沒有一句在講世界觀。它講的是動作。

二、刪稿判準

一段文字若拿掉後，角色仍會做同樣的選擇、讀者仍知道下一步要做什麼、伏筆也沒有少，該段就刪或縮成一句。

一句話，可以當場判定。這種東西放在執行表裡；「大靜默有三種未證實的說法」放在知識庫。

於是變成四份文件

後來又拆出兩份，最後穩定成這個結構：

前面講的是按「讀取頻率」拆（知識庫 vs 執行表）。這裡多了第二個切法：按「可公開性」拆。

lore-internal.md 的標題是這樣寫的：

# 矽墟 SILICA HOLLOW — 隱藏真身備忘（INTERNAL / DO NOT SHIP）

裡面是零號原型的真身、大靜默的真相、已埋伏筆對照、十四～十五章的編劇鎖。這些東西如果混進 glossary.md，就等於在讀者面前劇透。

而 glossary.md 標題寫著「公開版」，是可以直接給讀者的用語表。

這個切法工程師應該很熟：這就是 public API 和 internal implementation 的差別。 不是內容不同，是受眾與洩漏後果不同，所以必須是不同的檔案，而不是同一個檔案裡的不同章節。

同一個檔案裡的「以下內容請勿外流」，遲早會外流。

代價

代價一：五份文件會不同步。

這是最真實的代價，而且我還沒解決。

我在寫這系列的時候實測發現：NOVEL-STATE-SYSTEM.md 裡的「已落地連載狀態」表只記到 02.10，但 novel/短篇/ 裡實際已經有 200 回全部完稿，共 61,405 字元。

換句話說，那張狀態表落後了 180 回。

**集中管理沒有讓文件自動同步，它只是讓「哪裡該同步」變得明確。**而明確不等於會做。Day 9 講狀態表的時候會回來面對這件事。

代價二：拆得愈細，忘記某一份的機率愈高。

四份變五份的時候，我有一陣子完全忘記 lore-internal.md 的存在，伏筆對照表停更了兩週。

文件數量本身就是維護成本。 如果你的專案還小，一份就夠了，別學我一開始就拆五份。

代價三：執行表的「短」需要持續守護。

執行表會自然長胖。每次遇到新狀況，最順手的動作就是往執行表裡加一條。加到第 300 行的時候，它就變成第二個知識庫，而你又會開始不讀它。

我目前守住 79 行，但我不確定寫到第 300 回還守不守得住。

帶走什麼

一、集中管理只是第一步，第二步是按讀取頻率分層。

問自己一個問題：這份文件，我每次動工前會不會從頭讀完？

• 會 → 它是執行表，必須夠短
• 不會 → 它是知識庫，可以長，但你需要另外做一份執行表

這件事在技術文件上完全一樣。你的 CONTRIBUTING.md 如果有 2000 行，那它不是給人讀的，是給人搜的。你還缺一份 checklist。

二、判斷一條資訊該放哪裡，只問一句話：它會不會改變我下一步的動作？

會 → 執行表。不會 → 知識庫。

「大靜默有三種說法」不會改變我下一句怎麼寫，進知識庫。「先寫封面兌現的畫面，再寫衝突」會，進執行表。

這條判準也可以拿去砍會議記錄、砍 spec、砍 README。

三、按可公開性拆檔案，不要按章節。

**只要一份文件同時裝「可公開」和「不可公開」的內容，它就是一顆遲早會爆的雷。**用檔案邊界隔離，不要用標題隔離。

判斷方式很簡單：這個檔案有沒有可能整份被貼給別人？ 如果有，那不能外流的東西就不該在裡面。

明天 Day 3，講一個比「文件放哪」更硬的東西：有些設定不是拿來查的，是拿來擋的。我會拆一張六條規則的表，它的關鍵不在規則本身，而在每條規則旁邊那一欄。