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

模組五收尾。今天講一份稽核報告，55 行，寫於 2026-07-24。

它是這整個系列裡唯一一個「發現問題之後真的修掉了」的案例。前面講的四次漂移——說的都是同一件事：某份文件或某段程式，曾經跟實際狀況一致，後來實際狀況走遠了，而它沒跟上，也沒有任何機制會叫它跟上（Day 9 的狀態表落後 180 回、Day 12 的重複索引、Day 15 的規格紀錄、Day 16 的 skip 邏輯全失效）——到今天全都還在。

所以今天講兩件事：這份稽核為什麼有效，以及它揭露的一個很不舒服的事實。

那個不舒服的事實

先看檢查結果表：

上半部四項，全部 200/200 通過。下半部四項，全部不通過。

而上半部那四項，正好是全部可以自動化檢查的那些：檔案存不存在、連結對不對、句數在不在範圍內。

Day 6 我還特地為「200/200 句數合規」寫了一篇。那個 100% 的合規率是真的，而且完全沒有意義。

因為報告的結論寫得很直接：

200 個 Markdown 稿與 200 個 HTML 閱讀頁均存在，檔名、章回順序與 HTML 的 data-source 連結完整；這是結構合格。

但正文不能以此視為完稿。 第 03–20 篇的 180 回幾乎全是拆章表加上制式填充。

結構合格，內容不合格。

這是 Day 7 講的「形式 vs 意義」在完整規模下的樣子。我的自動化檢查涵蓋了 100% 的形式，而形式佔實際品質的比重是零。

具體壞在哪

報告點名了三種病：

一、制式回顧開場。 180 回全部以類似「上一回的懸念沒有落空」的句子開頭。

這是拆章的後遺症：每一回都要接住上一回的鉤子（Day 7 的規格要求「前 3 句就要回報」），而最省事的接法就是直接告訴讀者「上一回那件事沒事」。

它形式上滿足規格，實質上是用摘要代替場景。

二、作者旁白，110 回。 「這一回先能驗證的是⋯⋯」這種句子。

這是作者跳出來替讀者整理重點。它違反執行表明訂的「先動作、由選擇帶出設定」。

三、篇章封面說明混入正文，19 回。

昨天講的「封面不改，故事為封面兌現」，執行時走偏了：它描述封面的畫面，而沒有讓故事把封面的畫面演出來。

為什麼這份稽核有效

我對照了一下這份稽核跟專案裡其他失效的機制，差別有三個。

差別一：它有明確的判定基準

每一條「不通過」都對應到一條既有的規則：

• 制式開頭 → 違反「先動作、每回一個立即問題、由選擇帶出設定」
• 作者旁白 → 違反同一條
• 過短 → 沒有完成「鉤住→回報→加碼→人物獎勵→更大問題」（Day 7 的五段追讀引擎：一回 20 句要走完這五個節拍，每一段都要留下一個讓讀者想追下一回的理由）

稽核沒有發明新標準，它只是拿既有的規則去對照實際產出。

這是它跟「我覺得寫得不夠好」的根本差別。有基準，才有「不通過」這個判定；沒有基準，你只能得到一個意見。

（模組二那五天寫的規格，價值在這裡兌現了。規格的用處不在寫作當下，在稽核的時候。）

差別二：它給了執行順序

報告最後一段：

先重寫 03–10（據點隊伍成形）並二校 01–02；再重寫 11–16（香門下潛）；最後重寫 17–20（會師、舊院與點名）。

180 回要重寫，這個數字大到會讓人癱瘓。

而拆成「先 80 回、再 60 回、最後 40 回」，而且每一批有主題，就變成三個可以開始的任務。

一份沒有執行順序的稽核報告，會變成一份沒人動的清單。

差別三：它有逐項的驗收動作

每一回交稿前，實際標出五個節點：鉤住／回報／加碼／人物獎勵／更大問題，不用「上一回的懸念沒有落空」或任何作者說明句代替。

不只說「要重寫」，還說了重寫完怎麼確認它好了。

好消息：真的修掉了

我今天回去驗證。稽核點名的三個制式句：

「上一回的懸念沒有落空」   0 回
「這一回先能驗證的是」     0 回
「眼前的關係和代價都得留下」 0 回

全部 0 hit。

抽樣看 03–20 篇的首句：

03.01  綠語把第三次擲出的陰筊擦乾淨。
05.01  零式把第二枚假殘象排到真的旁邊。
10.01  小船漂到銹潮海口時，信匣還綁在甲板。
15.01  半截繩的鈴在裂縫口自己響了。
20.01  紅線先切開的是大廳中央的空氣。

五個抽樣，五個都是具體動作開場。 沒有一個是回顧摘要。

被點名過短的兩回：

11.06_不准一個人答   20 句
12.06_可回返的線     20 句

也補齊了。

180 回真的被重寫了。 這是這個專案裡唯一一次，一份文件發現的問題被完整執行到底。

代價

代價一：這份稽核報告自己過期了。

它現在還寫著 18 篇「重寫」，但那些重寫已經完成了。

今天有人打開這份報告，會以為專案有 180 回待處理。報告是一個時間點的快照，而它沒有任何欄位可以表達「已解決」。

這跟 Day 15 那個「定稿」條目被推翻卻沒標記，是完全一樣的問題。我在 Day 15 之後替開發日誌加了「已被推翻」的標記機制，但這份稽核報告我還沒處理。

代價二：稽核是人工的，而且很花時間。

200 回逐回讀、逐回對照規格、逐回判定。這不是跑個腳本。

而它不能自動化，正是因為它檢查的是「意義」而不是「形式」（Day 7 講過的那條線）。

所以它是一次性的。我沒有在後續每加一批內容時重跑稽核，因為成本太高。

代價三：稽核發生得太晚。

180 回已經寫完才發現有系統性的問題。如果在第 30 回就做一次抽查，後面 150 回就不會用同一種壞方法寫。

批次做完才驗收，等於把錯誤複製 180 次再一起修。

正確的做法應該是每一篇（10 回）做一次抽查。我知道，但我沒做。

帶走什麼

一、自動化檢查的通過率，跟品質沒有關係。

我的數字：可自動化的檢查 200/200 通過，人工稽核 180/200 不通過。

這不是說自動化檢查沒用：它擋住了另一類問題（檔案缺失、連結錯誤）。

但它會給你一種「都檢查過了」的錯覺，而那個錯覺很危險，因為它讓你不去做真正需要做的檢查。

判斷句：我的檢查涵蓋的是形式還是意義？ 只有形式的話，通過率再高也不代表東西是好的。

二、一份能被執行的稽核報告，要有三樣東西。

1. 判定基準——每一條「不通過」要對應到一條既有規則，不是意見
2. 執行順序——大批量的問題要切成可以開始的批次
3. 驗收動作——修完之後怎麼確認它好了

我看過很多稽核只有第一項（甚至只有「這裡不夠好」）。沒有第二、三項的報告，會變成一份沒人動的清單。

三、規格的價值在稽核時兌現，不在寫作時。

模組二那五天訂的規格，寫作的當下其實常常覺得綁手綁腳。

但這份稽核之所以能判定「不通過」而不是「我覺得怪怪的」，完全靠那些規格。沒有規格，這 180 回只會停留在「總覺得有點不對」的階段，然後被放過。

如果你在寫規格的時候覺得它沒用，那是因為它的用處在後面。

四、稽核要早、要抽樣，不要等做完。

180 回做完才稽核，等於把同一個錯誤複製 180 次再一起修。

抽樣稽核的成本低很多：每完成一個批次抽 10%，用同一份基準判定。

早期抽樣抓到的一個系統性問題，價值等於後期稽核抓到的一百個。

模組五到此結束。四天講的是：頁面怎麼生成（Day 26）、網站怎麼在零建置下活著（Day 27）、大規模重構怎麼降低成本（Day 28）、以及怎麼知道自己做出來的東西到底行不行（Day 29）。

明天 Day 30，完賽。我會結算這 30 天、講一個人到底維護得動多少，以及這整套「創作工程化」的方法裡，哪些真的有效、哪些是我的自我感動。