完賽
30 天到了。
這篇不總結內容。前面每一篇的「帶走什麼」已經做完那件事了。這篇講三件更有用的東西：這 30 天的寫作過程本身讓我發現了什麼、這套方法哪些是自我感動、以及一個人到底維護得動多少。
我原本以為這系列是「把做過的事整理出來」。
實際上不是。因為我給自己訂了一條規則：所有數字必須實測，不能憑印象。
於是每寫一篇，我都要回去量一次。而幾乎每一次量，結果都跟我記憶中的不一樣。
清單：
| 我以為 | 實際 |
|---|---|
| 連載狀態表大致跟得上 | 落後 180 回 |
| 「左砍、右報」（第一篇裡兩個主角建立的第一個位置默契）貫穿全書 | 只出現 5 回 |
| 20–35 句的規格有在用 | 193 回剛好 20 句，上限從沒被用到 |
| 封面統一規格是 2528×1696 | 實際 38/40 是 1536×1024，日誌那條已被推翻 |
| 三視圖腳本的 skip 邏輯只是有點問題 | 100% 失效，20/20 會重生 |
| 兩條 3D 路線，先試 SOTA 才手刻 | 手刻早了四天，SOTA 是後來去評估要不要取代它 |
| 我把限制寫下來了 | 沒有，repo 裡找不到那份清單 |
七項，七項都錯。
而且錯的方向有規律：我記得的是「我當時很用力想的事」，不是「後來實際發生的事」。
第一個默契我印象深刻，因為那是我第一次寫默契；繩子佔了 35% 我完全沒印象，因為它是自然長出來的。
所以這 30 天最實用的一句話是：跑一次統計，比回想一小時準。
我把 30 天講過的東西分成三類，照實分。
| 做法 | 為什麼有效 |
|---|---|
| 風格與角色解耦（Day 11） | 把「要固定的」和「要變的」拆到不同輸入通道，一致性變成構造上的性質 |
| prompt 檔案化（Day 12） | 改設定真的不用碰程式，20 個角色零腳本改動 |
| 刪稿判準（Day 8，用刪除測試取代評分：問「刪掉這段，角色的選擇會不會變」，不問「這樣寫好不好」） | 壓出每句中位數 12 字，四千句只有 7 句超過 40 字 |
| qualityContract（Day 23，3D 角色的驗收契約：不准變的六條＋准簡化的三條） | allowedApproximation（那准予簡化的三條）讓手工路線能收工，而不是無限打磨 |
| 封面不改（Day 28） | 20 張封面服務 200 回，重製數 0 |
| 稽核（Day 29） | 180 回被判定重寫，而且真的重寫完了 |
共同點：它們都改變了「最省力的那條路」通往哪裡。
不是靠自律，是靠讓錯的做法變得比較麻煩。
| 做法 | 現況 |
|---|---|
| 不可覆寫規則（Day 3，六條限制角色行為的硬規則，每條成對寫：左欄是規則本身，右欄是它在正文裡該變成的具體寫法） | 六條都對，但沒有任何自動檢查，靠我每次記得讀 |
| 位置型規格（Day 6） | 節拍點寫絕對位置，在規格自己的上限處是壞的，只因實際都是 20 句而沒暴露 |
| 五份設定文件（Day 2） | 執行表活著（因為在流程裡），其餘四份不同程度失效 |
| 四幕驗收（Day 28） | 「讀者應留下的感受」欄設計得很好，我一次都沒執行過 |
targetFidelity: 0.72，它有效，但它的有效是心理層面的。我沒有任何方法量測相似度，那個數字是掰的。
它值得用（它確實讓我停得下來），但我不想假裝它是一個度量。
「六章世界觀 + 五份文件」的結構（Day 2 講的：WORLDVIEW.md 分核心命題、歷史、地理、文化、敘事整合、據點循環六個大章，外加五份各司其職的設定檔），寫的時候很有成就感，實際上每次動筆只讀得到其中一份。另外四份是知識庫，而知識庫在一個人的專案裡，跟「我腦子裡有印象」的差別沒有想像中大。
寫到第 16 天我才發現，前面講的一堆問題其實是同一個：
同一件事實有兩個獨立維護的來源，就一定會不同步。
它在這個專案裡出現了六次：
| 出現在 | 兩個來源 | 現況 |
|---|---|---|
| Day 9 | 手寫狀態表 vs 實際章回 | 已爛（180 回） |
| Day 12 | .md vs prompts.json/.yaml |
未爛，無機制 |
| Day 15 | 日誌寫的規格 vs 實際檔案尺寸 | 已爛 |
| Day 16 | skip 檢查推導的路徑 vs 實際檔名 | 已爛（100% 失效，燒錢） |
| Day 26 | 章節資料寫死在 .py |
同一個錯，第二次 |
| Day 27 | 角色資料寫死在 .js |
同一個錯，第三次 |
六次，四次已經壞掉。
而修法只有三種，沒有第四種：
我大部分用的是第 3 種。第 3 種不會成功，只會還沒失敗。
具體的答案：
維護得動的：
維護不動的：
規律很清楚：
在工作路徑上的東西維護得動，在工作路徑旁邊的東西維護不動。
「寫一回」這件事本身包含了讀執行表，所以執行表活著。「寫完回頭更新狀態表」是額外動作，所以它死了。
這不是紀律問題，是位置問題。 我寫了一整篇文章講狀態表爛掉（Day 9），寫完到現在，它還是四列。
連寫一篇文章罵自己，都不足以讓一個工作路徑外的動作被執行。
按投報率排序：
一、所有會花錢的腳本，預設 --dry-run。
十行程式碼。它會在 16 天前就讓我看到那 20 行 WOULD REGENERATE——那是 Day 16 講的三視圖腳本，skip 檢查因為檔名改過而全部失效，空跑一次會印出 20 個角色「將被重新生成」，也就是 20 次白花的付費呼叫——而不是等到我為了寫文章才發現。
二、限制寫成檔案，而且寫成數字。
一個 constraints.md，五行。它會讓 12.59 MiB——Day 21 那個 SOTA image-to-3D 模型吐出來的 GLB 檔，是最後上線整頁的 376 倍大——在第一秒就出局，而不是讓我在壓縮上耗時間。
而且它會讓我三個月後知道「當時的限制」而不是「現在的合理化」。
三、能推導的東西一律用腳本生成。
那張狀態表的「留給下一回的問題」欄，其實就是每回的最後一句：
for f in novel/短篇/*.md; do
echo "$(basename $f .md) $(grep -v '^#' "$f" | grep -v '^>' | grep . | tail -1)"
done
五行，200 列，永不過期。 而我花了力氣手寫四列，然後讓它爛掉。
四、稽核要早、要抽樣。
180 回全部寫完才稽核，等於把同一個錯誤複製 180 次再一起修。每完成 10 回抽查一次，成本是零頭。
誠實列一下：
這些不是留給下一集的伏筆，是真的還沒做。
回到 Day 1 的那個問題：什麼時候該把創作專案「當專案管」。
30 天之後，我的答案跟第一天一樣，但理由更具體了：
當你開始需要回頭查自己寫過什麼、當同一件事你做了第三次、當你做了一件事卻說不出它為什麼是對的，那時候你需要的不是更努力，是把判斷力外部化成規格。
而這 30 天教我的補充是：
規格會被訂出來，但不會被自動維護。 所以訂規格的時候，第二個要問的問題永遠是：
這條規則如果被忘記，會發生什麼？誰會告訴我？
沒有答案的那些，它們現在就已經在爛了，只是還沒有人發現。
感謝看到這裡的人。
矽墟還在寫。200 回的下一步是 300 回，插圖那條產線總有一天要補上，而那支腳本我真的該修了。
明年見。
iThome鐵人賽
看影片追技術