今天講一個很細、但我認為會改變工作方式的區分：

讀原始碼得到的是假設。要在執行中的程式量到數據，才叫驗證過。

為什麼這件事重要

升級或改造既有系統的時候，大量的判斷來自「讀原始碼」：

• 「這個設定還在被使用」
• 「這條樣式掛在那一層」
• 「這個屬性有預設值保底」
• 「這個方法沒有被呼叫」

這些推論有相當比例是對的。

問題是錯的那些——它們會靜默地放過真實的缺陷。因為你已經「查過了」，所以你不會再查第二次。一個錯誤的推論比沒有推論更危險，因為它會終止調查。

三個把推論升級成實測的例子

那個案子留下三個很好的示範，我覺得每一個的手法都可以直接抄。例一：這條 CSS 覆蓋真的生效了嗎推論：讀完框架原始碼之後判斷「把圓角寫在外層容器上會失效，因為它掛在內層」。實測的做法是寫一支腳本，在執行中的應用程式量 computed style，用三個對照情境：

B 那一列是關鍵證據。

它證明了「有寫進去 ≠ 有效果」。而這種失效模式沒有錯誤、沒有警告、編譯與測試全綠。如果只讀原始碼推論，你會得到「應該失效」這個結論；但你不會知道「屬性確實有被設定」，也就無法解釋為什麼開發者工具裡看得到那條規則。

而且那支腳本用注入的方式測試，完全不修改專案檔案。所以可以放心測任意多種情境。這個設計讓「多加一個對照組」的成本趨近於零。例二：這個變數改名之後還有效嗎某一版的 migration 把一個 CSS 變數改了名字。

推論：讀原始碼確認新名字仍被使用 → 應該沒問題。

實測：在同一支腳本加上第四個對照情境——用舊名字。

D 證明了什麼？**如果那次 migration 沒有幫你改名，圓角就會在那一版靜默壞掉。**它把「schematic 這次幫了我們」從一個猜測，變成了一個事實。

注意這個動作的性質：它驗證的不是「現在對不對」，是「如果沒做某件事會怎樣」。 那是反事實的驗證，而反事實通常只能靠推論。除非你像這樣把它做成一個對照組。例三：最初的版本到底是不是好的昨天提過的那個對話框破圖。要確認「破圖是某一版引入的」而不是「一直都這樣」。

推論：讀主題檔的內容，判斷最初版本應該正常。

實測：從最初的基準標籤開一個獨立的工作副本、獨立安裝那個版本的一千九百多個套件、實際啟動起來擷取畫面。

結論：最初的版本確實正常。破圖是後來引入的。

成本紀錄寫著：約五分鐘（含安裝 16 秒、建置、啟動）。

五分鐘換一個直接證據。

什麼時候該實測

不是每個推論都值得實測。那份回顧給了一張判斷表，我覺得很實用：

第二列是重點：**如果推論錯了會立刻編譯失敗，那你不需要另外驗證。編譯本身就是驗證。**這條讓你可以省下大量不必要的實測。真正需要花力氣的，是那些「錯了不會有任何訊號」的推論。

而怎麼判斷「錯了會不會有訊號」？回想 Day 06 那組對照：

違反型別      → 編譯失敗
違反 schema   → 寫入失敗
違反設計稿    → 什麼都不會發生
CSS 沒生效    → 什麼都不會發生

「什麼都不會發生」那幾類，就是必須實測的區域。

三個可重複的手法

那份回顧把手法整理成三種，我直接列給你：

手法 A：量 computed style。驗證 CSS 是否真的生效
用自動化瀏覽器開真實應用、注入待測規則、量計算後的樣式。不改專案檔案。

手法 B：從舊標籤開獨立工作副本——驗證歷史行為

git worktree add --detach <路徑> <標籤>
cd <路徑> && npm install
# 該版本特有的環境需求要記得
git worktree remove --force <路徑>   # 用完立刻移除

手法 C：檢查打包產出——驗證改動真的出貨了
直接 grep 建置產出，確認新規則、新版本標記真的在裡面。

手法 C 那裡有一個很小的踩坑紀錄，我覺得很有教育意義：

⚠️ 開發建置不會壓縮，grep 樣式要留意空白——
我曾因為 grep :8px 而漏掉 : 8px，誤報「未含新規則」。

驗證工具自己出錯，然後給了一個錯誤的結論。 這正好呼應昨天那句「驗證機制也是程式」。

一個推廣

我想把這個區分推到更廣的地方，因為它不只適用於前端升級。Part 1 講的所有東西，都可以問這個問題：

• 「這條 hook 有生效嗎」→ 讀設定檔是推論，故意違規看它擋不擋是實測
• 「這條規範被遵守了嗎」→ 問團隊是推論，掃 codebase 數違規數是實測
• 「這個護欄有效嗎」→ 覺得有效是推論，Day 28 那個七日回填是實測

而 Part 2 那個 43 次的量測、Part 3 那個七日驗證，本質上都是同一件事：

把「我認為」換成「我量到」。

這也是為什麼 Day 25 我要花那麼多篇幅講「這些數字不能證明什麼」。因為量到的東西才算數，而量到的範圍就是它能證明的範圍，一寸都不能多。

小結

• 讀原始碼得到的是假設，在執行中的程式量到數據才叫驗證
• 錯誤的推論比沒有推論危險，因為它會終止調查
• 三個示範：驗證 CSS 是否生效、驗證改名後是否失效（反事實對照）、驗證歷史行為
• 判斷是否值得實測：錯了會靜默放過缺陷 → 必須實測；錯了會編譯失敗 → 不用
• 手法：量 computed style、開舊版工作副本、檢查打包產出
• 推廣：把「我認為」換成「我量到」

明天講一個更讓人不安的主題：官方的工具和文件也不可全信。