模組二｜敘事規格化（Day 5–9）

模組一講的是設定要放哪裡。從今天開始講一個更難的題目：怎麼把「好不好看」變成可以驗收的規格。

這個模組是整個系列裡唯一沒有腳本、沒有 API、沒有指令輸出的區段。所以我會用另一種東西當證據：我對已完稿的 200 回實際跑出來的統計。

先交代這個「200 回」怎麼來的，因為後面每一天都會用到它：這部小說是兩層結構——20 個篇章，每篇章拆成 10 回，20 × 10 = 200 回，一回 20 句左右。篇章是規劃與封面的單位，回是連載與驗收的單位。（怎麼從原本的 20 章長篇變成這個樣子，Day 28 會完整講。）

先從最基礎的一條規則開始。

問題：章節超載沒有症狀

寫東西的人都遇過這件事：某一章寫完，自己覺得資訊很豐富、劇情推進很多、很充實。

然後讀者說看不懂。

這裡有個很不直覺的地方：超載的章節在作者眼裡不是「太多」，是「很滿」。滿是褒義詞。你不會在寫的當下覺得「我塞太多了」，因為你腦子裡每一件事都有位置。

問題是讀者沒有那些位置。

而且這件事跟名詞失控（Day 4 講的）不一樣。名詞至少有個可以數的東西。「這章推進了多少」沒有單位，你要怎麼量「劇情推進」？

沒有單位，就沒有上限；沒有上限，就會超載。

怎麼做：先定義單位，再定上限

我的執行表裡第一條規則是這樣：

一章只允許推進三件事

1. 一個外在問題：這章要處理什麼危機或任務？
2. 一個關係變化：誰因何事更靠近、立下界線，或改變看法？
3. 一個未完問題：章末只留一個可在後章回收的鉤子。

關鍵不在「三」，在於它先定義了「一件事」是什麼。

「劇情推進」量不了，但「外在問題有幾個」數得出來。「關係變化有幾組」數得出來。「章末留了幾個鉤子」數得出來。

先讓東西可數，上限才有意義。 這跟 Day 4 的名詞預算是同一個手法。

三件事對應三種讀者需求

為什麼是這三種，而不是別的三種？

拆開來看，這三件事各自回答一個讀者會問的問題：

三個少一個，讀者就會在那個位置流失。

而三個各只有一個的理由是：這三種東西是互相搶注意力的。同一章塞兩個外在問題，讀者對兩個都不會投入；塞兩組關係變化，兩組都不會被記住。

不是「三件事剛好夠」，是「這三種各一件的時候，彼此不會互相稀釋」。

證據：這條規則長成一張表

規則好定，難的是執行。我怎麼確認第 13 章沒有超載？

答案是把它變成一張台帳。這是我的 20 章狀態表，欄位設計直接對應那三件事：

第二欄是關係變化，第三欄是未完問題。 每一格都只有一句，寫不下第二件事。表格的欄寬本身就是上限的執行機制。

（外在問題不在這張表裡，因為它在拆章表；這張表管的是跨章要記住的東西。）

第四欄才是真正的發明

「下一章不得忘記」這欄，是我後來才加的，而它現在是這張表最有價值的部分。

看它裝的是什麼：

• 「焰刃不是武器，是主動留下守人的人」
• 「綠語不替人抹掉傷，只讓傷不再擴大」
• 「霜瞳一直未完全斷線，不是自行醒來」
• 「名冊不能拿來勾掉人」
• 「零式不是單獨進門」

幾乎每一條都是否定句。

前三欄記的是「發生了什麼」，第四欄記的是「接下來不准怎麼寫」。

這個差別很重要。記錄劇情只能幫你回想，記錄約束才能擋住你犯錯。

而且這些約束都很具體：不是「保持焰刃的角色一致性」，是「焰刃不是武器」。前者無法判定，後者可以：我寫到某個場景，如果焰刃的行為只是「被指向哪裡就砍哪裡」，那就違反了。

這跟 Day 3 那六條不可覆寫規則是同一個設計：能擋住人的東西，必須落在動作層級，而且要說出替代方案。

代價

代價一：節奏會變得可預測。

實際跑完 20 章之後，我回頭看台帳發現一件事。20 章裡有 9 章的「關係變化」是加入一名新成員：01 焰刃、02 綠語、03 霜瞳、04 零式、06 鎮嵐、07 牧械、08 默娘、09 季讀、16 共弦。

差不多每兩章增一人。

這不是我刻意排的，是規則的產物：一章只准一個關係變化，而「新成員加入」是最強、最好寫的關係變化，所以它會反覆勝出。

規則保證了節奏穩定，同時也讓節奏變得可預測。讀到第 8 章，敏感的讀者已經知道第 9 章大概會有人加入。

這是規格化的通病：一致性的另一面就是可預測性。 我沒有解掉它，只能在別的維度（鉤子、反轉）製造變化。

代價二：有些章天生就想推進四件事。

有幾章我確實覺得三件不夠。第 17 章要處理十一人會師、主律被命名、據點分工，擠得很難看。

處理方式是拆章或把某件事往後推，但兩個做法都有成本：拆章會讓節奏變慢，往後推會讓那件事失去它原本的時機。

規格不是沒有代價的，它只是把代價從「讀者困惑」換成「作者受限」。 我認為這筆交易划算，但它是一筆交易。

代價三：這張表還是沒有自動檢查。

跟 Day 3 一樣。我可以寫得很整齊，但沒有任何機制會在我寫出第二個外在問題的時候攔住我。

它靠的是每次動筆前讀台帳這個習慣。而習慣會斷。

帶走什麼

一、想控制什麼，先讓它可數。

「這章推進太多」是感覺，「這章有兩個外在問題」是事實。

前者無法討論，因為兩個人的感覺不會一樣；後者可以當場驗證。

任何你想控制的品質，第一步都不是定標準，是定義單位。 code review 說「這個 PR 太大」沒有用，說「這個 PR 改了 4 個不相干的關注點」才有用。

二、狀態表要記約束，不要記劇情。

這是我覺得最能直接搬走的一條。

• 記劇情 → 只能幫你回想
• 記約束 → 能擋住你犯錯

檢查方式：你的狀態表裡有幾個否定句？ 如果一個都沒有，那它是筆記，不是防呆。

這件事在工程上完全對應：一份「我們做了什麼」的決策紀錄，價值遠低於一份「所以之後不准做什麼」的紀錄。ADR 真正值錢的是 Consequences 那一節。

三、上限的作用是防止互相稀釋，不是防止太累。

我一開始以為「一章三件事」是為了避免讀者累。後來發現不是，是因為同類的東西會互相搶注意力。

所以定上限的時候要問的不是「幾個會太多」，是「哪些東西放在一起會互相抵銷」。同類的要限量，不同類的可以並存。

明天 Day 6，把規格再推進一層：20 到 35 句、第 5／10／15／20 句必須有反轉。我會講一個實測結果：200 回全部落在規格內，但193 回剛好 20 句。規格的上限根本沒被用到，而這件事告訴我一些關於「範圍型規格」的事。