我在自己做的自媒體成長工具裡，故意把程式弄壞了 12 次，看自動檢查會不會叫。第一次跑，只有 9 次被抓到。
不是隨便弄壞。是照著這個工具真的會出事的方式弄壞，例如：整頁橫向捲動、分頁列多一顆變孤兒、按鈕小到按不到、點下去就丟錯、連結指到不存在的檔案、手機深色模式變成黑底、存檔其實沒寫進資料庫、刪帳號漏刪某一張表、新人被舊公告擋住走錯路。每一種都是真實會發生的錯，不是挑好弄壞的地方。
結果 3 種沒被抓到。
一種是手機深色模式變黑底。這條已經明文寫進規則、AI 仍犯過四次，檢查器卻從來沒有真的用深色模式打開過網站量過底色。另外兩種，檢查真的有變紅，但整支測試崩潰了，前面已經抓到的紅燈也一起看不到，人看到的只有一片錯誤訊息，不知道它到底抓到了什麼。
故意在自己的網站上弄壞 12 種真實會發生的錯，第一次跑自動檢查，只有 9 種被抓到。沒被抓到的 3 種裡，有一種是已經明文寫進規則、AI 仍犯過四次的規定（手機深色模式不准出現黑底），檢查器卻從來沒有用深色模式量過網站。
這個做法軟體工程有個正式名字，叫突變測試（mutation testing）。查了維基百科的定義（維基百科 Mutation testing 條目，查證於 2026-09-21）：刻意對程式做小幅修改，每一個改動版本叫一個突變體；測試如果失敗，代表偵測到了這個突變體，叫「殺死」；測試如果沒反應，這個突變體就「存活」下來。它驗的不是程式有沒有 bug，是測試本身夠不夠強，用途是幫忙找出測試資料裡的弱點。存活的突變體代表測試有漏洞，不代表程式沒問題。
補完那 3 種之後，同一批 12 種全部被抓到。順便，弄壞測試的過程還意外抓到一個真的存在的 bug：刪帳號的功能一路漏刪了 6 張後來才加的表，那 6 張表存著使用者的行為紀錄、靈感收件匣、成長點和帳號診斷報告，刪帳號的人以為資料清乾淨了，其實沒有。
比 12 種弄壞更重要的是，同一天還挖到 3 個讓檢查自己在說謊的洞。
第一個，假資料少一個欄位，整張畫面直接壞掉，檢查照樣全部通過。原因是頁面丟出的錯誤訊息，被寫進一個本來就藏起來的載入區塊裡，人看不到，檢查也沒去看那個區塊，兩邊都以為沒事。
第二個，Windows 上關掉測試伺服器的指令，只殺得掉外層那個殼，底層真正在監聽的程式活下來繼續佔著同一個埠。下一次測試打過去的請求，打到的是上一輪還沒關掉的舊程式碼。程式改壞了，測試量到的還是改之前那份，一樣全過。
第三個，分頁列的檢查只認得後台那一種按鈕的樣式，前台換了一種寫法的按鈕列，多一顆變成孤兒，檢查完全沒發現，因為它壓根沒去看那一類元件。
三個洞的共同點：檢查通過，只代表量到的那個維度沒事，不代表會出事的那個維度沒事。
同一天，我用一樣的手法測了另一支檢查器，專門查對外文案有沒有破折號、半形標點、星號這些禁用格式的那支。故意放進 16 種常見錯誤，15 種被抓到，漏掉的是用單顆星星包住文字的斜體寫法，像「重點」這樣。原因是那支檢查器以前只認雙星星包住文字的粗體寫法，單星斜體從來沒被納入判斷範圍。補完後另外多測了一種底線斜體「字」，也確認網址裡本來就會出現的底線不會被誤判成斜體。
做法其實很簡單，三步：找出這個地方真的會出事的樣子並故意弄壞一次，跑檢查看它會不會叫，不管有沒有叫，都要把程式碼換回原樣。整套跑完一次，大約 10 到 12 分鐘。
沒被抓到的那幾種，不是靠加強紀律去記得要小心，是回去改檢查本身，而且要改成量結果，不是量程式碼裡有沒有寫某個字：量畫面實際的底色，不是量有沒有加某個 CSS class；量資料庫裡剩幾筆，不是量介面有沒有回傳成功；量使用者每走一步之後停在哪一頁，不是量 API 有沒有回 200。
一個檢查如果從來沒被弄壞過，就等於沒被驗證過。AI 幫你寫測試很快，但寫測試的人跟被測的程式碼是同一個腦袋，兩邊一起盲掉是常有的事。真正知道一個檢查有沒有用，只有一個辦法：故意弄壞，看它會不會叫。