因、果、與一個切面

• 機制（因）：規則涵蓋範圍超出意圖，叫 over-match（過寬匹配）。
• 結果（果）：守衛因此被形似但非真意圖的輸入觸發，叫 false trigger（誤觸）。
• linter 切面：靜態分析報的偽警告，叫 spurious warning。

怎麼想這件事

誤觸不是「偵測器壞了」，是規則的範圍沒收好。收窄規則時要拿捏：太寬會誤觸（誤報），太窄會漏掉真的（漏接）。這個拉扯就是怎麼量偵測器裡 precision 與 recall 的取捨。

從這裡往下讀

• over-match：規則過寬而誤命中。
• false trigger：守衛被誤觸。
• spurious warning：linter 的偽警告。

兩種錯

• 說「有」但其實沒有 → 誤報（false positive）。
• 說「沒有」但其實有 → 漏接（false negative）。

把判斷（有/無）對上真實（有/無），剛好四格——這張判斷×真實的對照表叫混淆矩陣，false positive 那篇有完整版。

為什麼值得分清楚

因為兩種錯的代價往往不對稱，而且通常此消彼長：壓低一種會抬高另一種。癌症篩檢寧可誤報也不能漏接；自動封鎖寧可漏放也別誤殺。先想清楚「哪種錯更貴」，才知道偵測器該往哪邊偏。

從這裡往下讀

• 想徹底搞懂這兩種錯：false positive、false negative。
• 統計課對這兩種錯的編號：Type I error（= 誤報）、Type II error（= 漏接）。
• 想用數字衡量這兩種錯有多少：見怎麼量一個偵測器準不準。

從一條誤報到沒人看

這是一條因果鏈：

• 一條監控的誤報叫 false alarm（偽警報）。
• 大量誤報累積、淹沒真訊號，這個狀態叫 noise（噪音）。
• 人因此對告警麻木、連真的也忽略，這個後果叫 alert fatigue（告警疲勞）。

為什麼是設計問題

因為每一條告警單看都「沒錯」，問題出在總量。所以解法是系統性降噪：提高告警的 precision、分級、讓每條告警都可行動。降噪不是美觀問題，是讓偵測系統還有人看的前提。

從這裡往下讀

• false alarm：監控的偽警報。
• noise：淹沒真訊號的誤報。
• alert fatigue：告警疲勞。

兩把尺

• precision（精確率）：報出來的之中，有多少是真的？被誤報拉低。
• recall（召回率）：真的之中，抓到了多少？被漏接拉低。

為什麼要兩把

因為只看一把會被騙。一個偵測器只要「什麼都不報」，就永遠不誤報、precision 看起來無敵——但 recall 是零，全漏了。反過來「全部都報」recall 滿分、precision 慘不忍睹。兩把一起看，才知道它是真準還是在作弊。

兩者通常此消彼長，調和成單一數字是 F1 score。要偏哪一把，回到誤報與漏接哪個更貴的判斷。

從這裡往下讀

• precision：報出來的有多少是真的。
• recall：真的之中抓到多少。

兩種「假紅燈」

• flaky：同一份程式碼、什麼都沒改，卻時過時不過。問題在測試的不穩定（競態、時序、共用狀態）。
• spurious failure：這次失敗的原因不是被測對象——是環境、網路、CI 機器的暫態。

為什麼要分清楚

因為修的地方不同：flaky 要修測試本身的不穩定，spurious failure 要修環境或基礎設施。更重要的是，把假紅燈和真失敗混在一起，會讓人養成「紅了先重跑」的反射，久了連真 bug 都被當假紅燈忽略——這就是測試版的告警疲勞。

從這裡往下讀

• flaky：時綠時紅的測試。
• spurious failure：偽失敗。