問題
我想掃一遍全站文章，找出「讀者可能看不懂」的那些。做法是寫個腳本量指標、排名、照名單改。
結果指標一再騙人，而且每次騙的方向都是「把好東西判成壞的」。
誤報一：術語密度把用心寫的文章判成最差
第一版用「每千字未解釋的英文術語數」當指標。跑出來，全站大多數文章都被判成高風險。
名單最前面是一組 AWS 系列文章。打開來看：
- 開頭三個反問把讀者拉進場景（「你的 code push 了，然後手動 SSH 進去拉 code？」）
- 每個數字附官方文件連結
- 有明確立場（「不要建 IAM user」）
那是我自認站上比較用心寫的一批。它被判紅的唯一原因，是 AWS 服務名天生密集——ALB、ECS、IAM、CloudWatch 每段都有。
更糟的是方向：指標把「術語多」讀成「寫不好」，而術語密集恰好是深度技術文章的特徵。照這份名單改，會把寫得用心的文章改成囉嗦。
誤報二：換了指標，抽樣還是一大半誤判
改成偵測「開頭有沒有把讀者接上痛點」。抽 14 篇人工讀，9 篇是誤判（約 64%）。
那 9 篇的開頭其實都很好，只是用了詞表外的講法：
| 文章 | 它的開頭 | 為什麼沒命中 |
|---|---|---|
20-dependency-injection | 「初始化順序你要管⋯順序錯了就 crash」 | 「crash」不在痛點詞表 |
09-unit-test-jest-vitest | 「價值不在覆蓋率 100%，在改 code 的時候敢按 Enter」 | 這是立場，但當時沒有「立場」這一項 |
54-binary-lifting | 「要往上跳 100 步，不需要跳 100 次——二進制 100 = 64+32+4」 | 反直覺，但詞表只認「痛」 |
S02-rust-borrow-checker | 「2019 年 Chrome 安全報告：70% 的嚴重漏洞是記憶體安全問題」 | 具體數字＋來源，同樣不在詞表 |
補了痛點詞表、加了「明確立場」這一項，誤判才明顯降下來。
但降下來不是終點——後來判「普通」的文章，人工讀過幾乎都很好。所以結論變成： 只有「有病」值得打開來看，「普通」不要動。
另一支比對規劃清單與實際檔案的稽核腳本也是同一個故事：前後修了很多次，問題全在解析規則（編號格式、欄位位置、子資料夾沒掃到），沒有一次是資料真的寫錯。
為什麼這一族特別難抓
跟比錯基準共享同一個性質：每一次都有輸出，而且輸出看起來很合理。
高風險篇數、誤判率、落差筆數——這些數字都「跑出來了」，有排名、有分佈、有各系列佔比。看起來像個結論。
但多了一層更難抓的東西：指標的錯誤會以「工作量」的形式出現。一大批高風險文章、一長串落差，看起來像「有很多事要做」，不像「指標壞了」。
一個壞指標不會報「我壞了」，它會報「你有很多問題」。 而「有很多問題」正好符合「全站沒整理過」的預期，所以它不觸發懷疑。
四個診斷問句
-
這個指標排在最前面的那幾個，我打開看過嗎？ —— 這一題就夠。名單第一名打開看三十秒，就知道指標壞了。
-
指標的方向對嗎？——它量的東西跟我要的東西是正相關還是負相關？ —— 術語密度跟「寫得好不好」不是負相關；深度文章天生術語多。
-
拿已知答案校準過嗎？ —— 挑一個我人工讀過、知道答案的對象（
backend/queue那章），跑到吻合才信其他的。 -
工具報的問題，是資料的問題還是解析的問題？ —— 稽核腳本修了那麼多次，沒有一次是資料錯。預設先懷疑工具。
怎麼預防再次發生
- 先校準再掃全站。 拿一個人工確認過的對象當基準，跑到吻合為止。沒校準的全站數字不要拿來排工作。
- 指標只能排順序，不能下判斷。 它的產出是「這幾個值得打開看」，不是「這幾個有問題」。
- 數字跳動先問涵蓋率。 落差數字突然變大，不一定是變糟——可能是修了解析之後，更多章節被納入統計。比較兩次數字前先確認分母一樣。
- 工具的誤判要寫進工具自己。 在腳本開頭的註解記下「這個指標會怎麼騙你」和豁免條件，因為下次跑的人不會記得這一輪踩過什麼。
相關
- 檢查跑了、有輸出、結論還是錯的 —— 同一族：檢查跑了、有輸出、結論還是錯的
- 反向驗證也會說謊 —— 反向驗證本身也會失效
- 驗收假綠形態目錄 —— 驗收假綠的形態目錄