模組五｜閱讀端與規模化（Day 26–29）

今天講一次大規模重構：20 章的長篇，改成 200 回的短篇連載。

內容形式全變、節奏全變、每一回都要重新設計結構。而最貴的那批資產，一張都沒動。

問題：長篇的節奏跟連載不合

原本是 20 章的長篇。每章篇幅完整，起承轉合在章內完成。

問題出在追讀動機。

長章的鉤子密度低：一章可能三千字，中間有大段的鋪陳與描寫。這在一次讀完整本的情境下沒問題，但連載不是那樣讀的：讀者今天讀一章、明天可能就忘了，中間的鋪陳會變成「我為什麼要繼續」的空窗。

所以要拆。20 章拆成 200 回，一回 20 句。

但拆章會撞到一個很貴的東西

每一章都有一張封面圖。

這些封面不是隨手產的：

• 一張要走完整條產線（Day 10–15 講的那些：參考圖上雲、雙參考生成、解析度處理）
• 中間有失敗、有內容審核誤判、有重試
• 每一張都經過人工驗收

20 章 = 20 張封面。

如果我照直覺做「一回一張封面」，那 200 回就需要 200 張。十倍的產線成本、十倍的驗收工作、十倍的失敗機率。

而且更麻煩的是：既有的 20 張要不要重做？如果拆章之後每一章的內容邊界都變了，原本的封面可能不再對應任何一回的內容。

解法：把最貴的資產宣告為不可變

重構藍圖的第一句話：

原則：封面不改，故事為封面兌現。

拆章表也重複了一次：

原二十章保留為 20 個篇章封面／主視覺；每篇拆成 10 回，共 200 回。

封面使用：原第 X 章封面是 X.01–X.10 的篇章封面，不另改圖。

一張封面從服務 1 章，變成服務 10 回。

原本   20 張封面 : 20 章    = 1 : 1
現在   20 張封面 : 200 回   = 1 : 10

封面重製數：0

實測 assets/ 目錄，確實是 20 個不重複的章號（novel-ch01 到 novel-ch20），沒有為了拆章新增任何一張。

「故事為封面兌現」是把順序反過來

一般的流程是：先有內容，再配圖。 圖服從內容。

這裡是反的：封面固定，內容必須滿足封面。

重構藍圖裡有一張表，每一章都寫著「本章固定封面必兌現的畫面」：

這一欄是約束，不是描述。 第 07 篇的十回裡，一定要出現「日光工坊、牧械與小機器群、綠語修機、焰刃旁觀」這個畫面，因為封面已經這樣畫了。

執行表（NOVEL-STATE-SYSTEM.md，Day 2 講過的那份動筆前必讀的執行表）裡的寫章流程也把它列成第二步：

2. 先寫一個封面兌現的畫面，再寫衝突；不可先講設定。

為什麼這比「重畫封面」好

因為它把不確定性推到了便宜的那一端。

當兩個東西必須互相配合，讓便宜的那個去適應貴的那個。

這在工程上是很常見的模式，只是通常不會這樣講：

• 資料庫 schema 難改，所以應用層去配合
• 公開 API 難改（別人在用），所以內部實作去配合
• 已發布的檔案格式難改，所以讀取端做相容處理

先問「哪一邊改起來比較貴」，再決定誰配合誰。

四幕：拆完之後用什麼維持整體感

拆成 200 回之後，最大的風險是變成 200 個獨立的小段落，失去整體結構。

重構藍圖用四幕來擋這件事：

注意最後一欄：它記的不是劇情，是讀者應該有的感受。

這一欄的作用是驗收：我寫完第 10 篇，可以問「讀者現在會覺得這支隊伍像隊伍了嗎」。如果不會，那不管每一回寫得多好，這一幕沒有達成。

拆得愈細，愈需要一個粗顆粒的層級來檢查整體。 200 回不可能逐回檢查整體感，但 4 幕可以。

代價

代價一：封面固定會反過來限制故事。

如果我在寫第 14 篇的時候，發現故事應該往另一個方向走（但封面已經畫了「深不見底的垂直裂隙、垂進黑暗的繩、底下的緋紅光」），那我要嘛改故事，要嘛推翻原則。

我沒有遇到需要推翻的狀況，但那可能只是因為封面畫得夠模糊。 這條原則的韌性沒有被真正測試過。

代價二：一張封面服務 10 回，那 10 回的視覺是重複的。

讀者連讀十回，看到的是同一張圖。視覺上的新鮮感是被犧牲掉的。

我後來的補救是替短篇另外做插圖（工作流文件裡寫著「每回一張 3:2 插圖，放在正文中段」），但那是另一條產線、另一筆成本，而且它並沒有真的完成。這是一個開著的坑。

代價三：四幕的驗收欄我沒有真的執行過。

「讀者應留下的感受」這一欄很漂亮，但我從來沒有在寫完第 10 篇之後，真的停下來問「這支隊伍像隊伍了嗎」。

它是一個很好的設計，也是一個沒有被使用的設計。 跟 Day 9 那張狀態表一樣，它不在我的工作路徑上。

帶走什麼

一、重構的時候，先找出「不可變的那一邊」。

大部分重構的成本估算會算「要改多少東西」。更有用的問題是：哪些東西我不打算改？

明確宣告不可變的部分，重構的範圍就自動收斂了。而且它會逼出好的設計，因為你必須讓其他東西去配合它。

二、讓便宜的一邊去適應貴的一邊。

判斷「貴」的方式不是看它多複雜，是看改它要付出什麼：要不要重跑產線？要不要別人配合？可不可逆？失敗率多高？

我的封面貴在「每次重做都是一次會失敗的 AI 生成 + 人工驗收」。我的文字便宜在「我打字就好」。

所以文字配合圖。這個判斷跟藝術無關，純粹是成本。

三、資產攤提是重構時可以主動創造的收益。

同一批資產，從服務 20 個單位變成服務 200 個單位。沒有新增成本，單位成本降到十分之一。

重構的時候不要只想「這樣改要花多少」，也要想「有沒有既有資產可以在新結構下服務更多東西」。

四、拆得愈細，愈需要一個粗顆粒的檢查層。

200 個單位無法逐個檢查整體性。你需要一個中間層（我的是「幕」）來承接那個檢查。

而那一層的驗收標準應該是結果導向的——不是「這一幕有沒有寫完」，是「這一幕結束時，該發生的變化發生了嗎」。

（然後你要真的去執行它。我沒有。）

明天 Day 29，模組五收尾，講一份稽核報告：200 回結構全部合格，但正文有 180 回被判定必須重寫。 我會講那份報告怎麼寫的，以及一個好消息——這是這個專案裡唯一一次，發現問題之後真的修掉了。