在 Day 6 中，我們定出了欄位的三層境界，定下了不容妥協的資料衛生紀律，並看到了模型（Jev）輸出的極端雙峰分佈。今天，我們直接進入第一組實驗——憑證偵測（n=75）。

我們來看看：面對那些傳統 Regex 規則完全全盲的憑證洩漏，模型到底是如何把它們一筆一筆抓出來的？

實驗一：憑證偵測。它抓到了 regex 漏掉的六筆

在這 75 筆寫檔與工具呼叫紀錄中，有 15 筆真的含有憑證（正例），60 筆不含（負例）。

我原本寫了一條 regex 規則，專門抓 apikey_ 前綴。當我把 regex 的結果與 Jev（在 0.50 門檻下）並排比對時，成績如下：

              抓到    漏掉    誤報
  regex        9      6      0
  Jev（0.5）  15      0      0

regex 漏了六筆，而 Jev 全抓到了，且兩邊都沒有任何誤報。看到這裡，第一個直覺反應通常是：「太好了，模型比較準，我們應該全面換成模型。」

且慢。我們必須先看清楚，這六筆被 Regex 漏掉的憑證，到底是怎麼漏的？而模型又是憑什麼抓到的？

為什麼 Regex 會漏？

這六筆漏掉的憑證，在程式碼裡長這樣：

• 有的是直接宣告 token = "abc123def456"，但因為變數名叫 auth_token，我們原本寫的 \b(token|secret)\b 規則中，\b 單字邊界被底線（_）吃掉了，導致整條 Regex 完美擦過。
• 有的是把金鑰寫在註解裡，或是埋在 JSON 設定檔的深處，沒有任何 apikey_ 的特徵前綴。

這就是傳統 Regex 的硬傷：它對「邊界定義」極其敏感，且對「語意」完全全盲。

只要 Agent 在寫程式時稍微換個命名習慣（例如用 auth_token 代替 token），或者把金鑰放在沒人想到的地方，Regex 就會無聲地放行。

模型是怎麼抓到的？

而 Jev 作為一個會讀語意的模型，它不依賴死板的單字邊界或前綴。它在讀這段 diff 時，能理解「這是一個賦值動作，而右邊那串無意義的隨機字串，極大概率是一把金鑰」。

這就是第二層欄位（它動的是什麼性質）中，模型的真正價值：它用「語意理解」補上了「規則匹配」的死角。

看到這裡，你可能會想：「既然 0.50 門檻下模型這麼準，那我們就用模型，而且為了保險起見，把門檻調高到 0.90，這樣不是更嚴謹、更安全嗎？」

誠實欄

• 這組憑證數據只有一種格式的 key。 所以「15/15 全抓到」講的是「抓到這一種 key」，不能外推成「抓得到所有類型的秘密」。
• 這不是評測集。 樣本來自單一專案的真實改動，沒有設計過的正負例配比。真要下結論得另外做。
• 機率量化到小數第二位，且不會給 0.00 或 1.00，最極端是 0.01 和 0.99。

明天，我們來把門檻拉開，用真實數據拆解那個在安全和稽核領域極其常見、卻又極其致命的直覺陷阱：為什麼調高到 0.90 會把模型的價值整段丟掉？

今天對應的威脅： T1（憑證外洩）。我們用數據證明了，模型能用「語意理解」補上確定性規則的漏抓。

實驗與程式： 2026-09-19 跑、2026-09-20 重算。原始數據 data/day06-jev-secret.json（75 筆）。模型為 jev-1.13.0。本篇沒有引用外部來源。