在資安與稽核工程中，直覺常告訴我們「門檻調高一點比較安全、不易誤報」。然而 75 筆真實改動數據卻揭露了一個殘酷事實：盲目拉高門檻，只會親手閹割模型最核心的語意理解能力，讓它退化成陽春 Regex。
1. 負例分得很乾淨： 60 筆負例分數全在 0.04 以下。這意味著將門檻從 0.50 調高到 0.90，完全沒有減少任何誤報（因為誤報本來就是 0）。
2. 模型猶豫才是真實價值： 那些變數叫 auth_token 或藏在 JSON 深處的難題，模型給出 0.61 ~ 0.75。這就是模型「在猶豫」的樣子。當你切在 0.90，正好親手抹殺了這 6 筆，模型當場退化回陽春 Regex！
答案是不算。 證據必須具備「可重算、可拆解、可反駁」的性質（如 Hash 吻合或 AST 語法樹比對）。模型給的 0.68 既不可重算（重跑可能抖動），也無法拆解神經網路內部的因果權重。
但機率能做「路由 (Routing)」： 決定「要不要叫人來看」。只要比隨機盲猜好、且誤報處置成本可接受即可發揮巨大戰力。
jev-1.13.0）存檔確保溯源。
| 維度 | 當成「客觀證據」 (Evidence) | 當成「分流路由」 (Routing) |
|---|---|---|
| 本質要求 | 必須可重算、可拆解、可反駁 | 只要比盲猜好、且誤報成本可接受 |
| 出錯代價 | 整份稽核報告作廢、結論在法庭或主管前站不住腳 | 資安人員多看一筆排查，或漏看一筆，代價有限 |
| 適合工具 | Git Commit Hash、AST 抽象語法樹、Diff 比對 | AI / LLM 機率模型（如 Jev、語意分類器） |
| 落地實踐 | 直接作為審查阻擋依據，寫入日誌作為不可篡改證詞 | 機率不進結論，只進待看清單，指引人工審查優先序 |
Regex 寫 \btoken\b，被命名中的底線吃掉單字邊界。
auth_token = "ghp_98a7x..."
沒有 apikey_ 前綴，藏在深層配置結構中。
{"auth": {"secret": "sk-live..."}}
開發者隨手寫在註解裡的測試憑證，非正式變數。
// temp test: AKIAIOSFODNN...
變數名無 token 字眼，但字串熵值與上下文具機密特徵。
client_signature = "e4d909c..."
透過物件賦值，Regex 規則無法鎖定賦值語法。
config.headers["X-API"] = "sec_..."
直接以位置參數傳遞長字串密鑰，缺少關鍵字錨點。
connect("prod-db", "d8f1e29...")