今天講那個模板裡最難做到的一格。
#### ④ 驗證（Verify）— 七日內回填
- 驗證方法：<如何驗證「問題機率下降」>
- 結果：⬜ ✅ 有效｜⬜ 🟡 部分有效｜⬜ ❌ 無效
配套的規定是：
每條登錄七日內需回填驗證結果。
若七日未驗證，視為「效果不明」，須排入下週重新評估。
我認為這是整套束縛工程裡最難做到、也最有價值的一條。
因為加護欄的當下，你已經覺得自己解決問題了。
那個心理歷程是這樣的：發現一個反覆出現的問題 → 想通原因 → 寫了一支腳本 → 跑起來是綠的 → 完成。
「完成」的感覺在腳本跑綠的那一刻就滿足了。
而七天後回頭問「那個問題的發生機率真的下降了嗎」。這個動作沒有任何即時回饋、不會產出東西、而且有可能得到你不想要的答案。
所以它是所有步驟裡最容易被跳過的。
那份日誌的選項是三個，不是兩個：
✅ 有效 🟡 部分有效 ❌ 無效
中間那個很重要。
如果只有「有效／無效」，人會傾向填「有效」。因為填無效等於承認自己做白工。而「部分有效」提供了一個誠實的中間地帶：擋住了一部分、但還有漏網、或者擋住了但誤報太多。選項的設計會影響誠實度。 這是我從那份日誌學到的一個小技巧。
比結果更重要的是它上面那一行：驗證方法。
因為「這個改動有沒有效」如果沒有事先定義怎麼量，七天後你只會憑感覺回答。看幾條實際填的內容，就知道差別在哪：
✅ 有效；三個錯誤路徑都正確退出，並給出修復命令
✅ 有效；實測 G5 13/13 PASS、G6 純新增、G7 6/6、G8 正確捕捉 6 個敏感檔案
✅ 有效；H1/H2 正確 exit 2，H3/H4 正確產出訊息，H5 正確注入
✅ 有效；pipe-test 通過。觀察未來一週是否有實際大改動觸發並帶動 review
**這些不是「我覺得有用」，是「我餵了什麼進去、它回了什麼」。**第二條特別具體——八道閘門逐一實測，每一道的結果都列出來。第四條則誠實地標明「這次只驗到管線能通，實際效果還要再觀察一週」。
現在講我最欣賞這份日誌的地方。
翻那 22 條，有相當一部分的 ④ 驗證欄位長這樣：
結果：⬜ ✅｜⬜ 🟡｜⬜ ❌ （2026-04-27 前回填）
結果：⬜ ✅｜⬜ 🟡｜⬜ ❌ （2026-05-04 前回填）
結果：⬜ ✅ 有效｜⬜ 🟡 部分有效｜⬜ ❌ 無效
空的。到期日都過了，還是空的。
還有幾條填了但帶保留：
（建立當下全綠，待某項議題釐清）
（範例已就緒，待實證）
（建立當下 4 項驗證全綠，待第二份同型規格實證）
（建立當下 5 項驗證全綠，待後續實作新規格觀察）
「建立當下全綠」不等於「有效」。他們自己標出來了。
我覺得這比全部填滿 ✅ 有價值得多。因為：
一、它是真的。 那些護欄確實還沒被驗證。
二、它讓已填的 ✅ 可信。 如果 22 條全部是 ✅，我會懷疑那是儀式性的。有空格在，填的那幾條就有重量。
三、它自己就是待辦清單。 那些空格不是遺漏，是「還沒做完的事」被留在看得見的地方。
這跟 Day 25 講的那個「⚠️ 這個 100% 是假的」是同一種紀律，也跟 Day 20 講的「有一個 100%，然後自己在旁邊註明它是假的」是同一件事。在同一個團隊裡，這種紀律出現在三個不同的專案。那不是巧合，那是文化。
那個案子還有一個東西我很喜歡：一份「下次開工三分鐘內就能決定今天做什麼」的檔案，裡面有一張本週束縛迭代的狀態表：
累計條目 8
最近 7 日新增 7
待驗證（7 日內到期） SL-001、SL-004、SL-005、SL-006、SL-007
✅ 有效率 100%（4/4 已驗證）
本期重點 三項精華 + 開發啟動腳本（降低日常摩擦）
四個數字，一眼看完。
而且注意第三行——「待驗證」是被列出來的，不是被遺忘的。這就是那個「七日未驗證須排入重評」的規定在實際運作的樣子。
至於「有效率 100%（4/4）」——分母是 4。這個數字看起來很漂亮，但它同時誠實地告訴你：**只有 4 條被驗證過，其他都還在待驗證區。**如果只寫「有效率 100%」而不寫分母，那就是另一回事了。
回到最根本的問題：為什麼要驗證？
因為護欄本身也會出錯。而且出錯的方式不只一種：
| 失效方式 | 症狀 | 如果不驗證會怎樣 |
|---|---|---|
| 沒擋到 | 問題照樣發生 | 你以為有防護，其實沒有 |
| 誤報太多 | 一直紅燈，但都是假的 | 大家開始習慣忽略（Day 22 講過） |
| 範圍太寬 | 擋到不該擋的東西 | 開發被拖慢，最後被關掉 |
| 範圍太窄 | 只擋到一種變形 | 換個寫法就繞過去了 |
這四種裡面，只有第一種是「顯然無效」。另外三種都會通過「腳本跑得起來」這個測試。你寫完當下跑一次，綠的，收工。問題要一週後才會浮出來。 而如果沒有那個七天回填的規定，它永遠不會被發現。
明天會講四個實際的例子，剛好對應這四種失效。
我想把這件事推得更遠一點。
Day 25 講量測的時候，我說「有量測比沒量測好太多」。但那是在講產出。工廠跑出來的東西好不好。今天講的是治理本身的量測。你為了改善品質而做的那些動作，有沒有效。
而後者幾乎沒有人在做。
大部分團隊的治理動作是這樣的：出事 → 開會 → 決定「以後要 XXX」→ 寫進文件 → 結束。沒有人回頭問：那條「以後要 XXX」，後來真的降低了問題發生率嗎？
所以你會看到一份三年沒清過的規範文件，裡面有幾十條「以後要」，而沒有人知道哪幾條真的有用。
那個七天回填的規定，本質上就是在對治這件事。
七天回填會逼出一件事：很多護欄不是「有沒有裝」的問題，是「裝了之後要怎麼調」的問題。
第三條處理的是誤報：
簡體字偵測器校正 —— 字典外置、消除假陽性、補上漏抓
情境是：某個案子的交付物要求必須是繁體中文，所以做了一支偵測器掃簡體字。
問題是有些字在兩種字體系統裡是同一個字。
像「消」「禁」「默」這類字，簡繁同形。偵測器如果只是拿一份簡體字表去比對，就會把這些字誤判成違規。
而誤報的後果，Day 22 講過：
紅字變成常態，這層驗證就失效了。
三個改進動作：
第三點值得注意：校正誤報的時候，順手處理了漏抓。
因為這兩件事其實是同一個判斷準則的兩端。你在調整判準的時候，本來就該同時看「抓錯的」和「沒抓到的」。只調一邊，另一邊會惡化。
這條對應「誤報太多」。
第四條處理的是範圍太寬：
守門 hook 改為「認得 repo」—— 只守程式碼 repo 的主分支
原本有一道 hook 在守「不可以直接動主分支」。立意良好。
但那個工作區裡不只有程式碼 repo。
還有文件、專案管理紀錄、交付物。這些東西的版控節奏跟程式碼完全不同，被同一道 hook 擋住只會造成摩擦。改進是讓那道 hook 知道自己在哪個 repo，只在程式碼 repo 生效。這條我覺得特別有代表性，因為它示範了一件事：
護欄過度攔截，最後的下場是被關掉。
而被關掉之後，它本來要守的東西就完全沒人守了。所以「縮小範圍」不是妥協，是保住這道護欄的存活。昨天那張表的第三種失效：範圍太寬 → 開發被拖慢 → 最後被關掉。
把四條放在一起：
| 紀錄 | 失效類型 | 動作 | 一句話 |
|---|---|---|---|
| 貼警語 → 機器擋 | 沒擋到 | 升級 | 同一條規則換一層 |
| 單一真相過期 | 沒擋到 | 修補 + 擴充 | 把「不會再發生」寫成閘門 |
| 偵測器假陽性 | 誤報太多 | 校準 | 同時調兩端，不只調一邊 |
| hook 範圍太寬 | 範圍太寬 | 縮範圍 | 縮小是為了保住存活 |
注意四條裡有三條是在「修既有的護欄」，只有一條是在「加新的」。這推翻了一個我原本的直覺：我以為束縛工程主要是「不斷加新規則」。實際上不是。大部分的工作是在調整既有的護欄。升級它、修補它、校準它、限制它。
而這正好解釋了為什麼一定要有日誌。加新規則你記得住，調整既有的規則三個月後就忘光了。
兩天下來：
如果 Part 3 你只帶走一件事，我希望是這個問題：
你上一次「加強規範」是什麼時候？那次加強，後來有效嗎？
如果答不出來，那不是你的問題。是因為沒有人設計那道驗證。
明天開始 Part 4，換一個案子、換一個角度。
前面二十七天，我一直在講「怎麼讓產出是對的」。規範、範例、檢查、護欄、迭代。
而 Part 4 要處理一個更前面的問題：
你怎麼知道你「驗證過了」？
那個案子的回顧文件第一句話是這樣寫的：
整段過程中，最貴的錯誤都不是技術不會，而是「以為驗證過了，其實沒有」。
它有 221 筆動作日誌、14 個綠燈標記、17 篇編號的知識點回顧。而排在最前面的五篇，全部是驗證方法論。
iThome鐵人賽
看影片追技術