跳轉到主要內容
一個過於熱切的防護欄比沒有防護欄更糟——你的團隊學會忽略 Matches 動態，或者你放寬規則並失去你實際想要的捕捉。OrcaRouter 給你一條精確的中間路徑：把單一匹配標記為誤報，引擎就會記住那個發現並在未來請求上略過它——而不觸碰規則、放寬模式或出貨一次 SDK 變更。 這是誤報工作流程的一個聚焦落地頁。完整的防護欄引擎——每種規則類型、欄位與路由——請見 防護欄參考。
這裡的每個步驟都是託管閘道（api.orcarouter.ai）上的一個主控台動作。你在自己的工作階段下分流匹配；只有最後的 /v1/* 呼叫使用 sk-orca-... 中繼金鑰。把一個匹配標記為誤報需要工作區 Admin 角色；讀取 Matches 動態與產生的抑制清單對每個成員開放。

​
1. 在不削弱規則的情況下減少防護欄誤報

當一條規則過度觸發時，本能是放寬它——擴大一個正規表示式排除、丟掉一個實體、把 block 翻成 flag。那是用一個誤報換來政策中的一個漏洞。標記誤報抑制是外科手術式的替代方案：

抑制一個發現

靜音失誤的那個確切匹配——一個特定規則下的一個特定子字串——而非整條規則。下一次真正敏感的命中仍會觸發。

不編輯規則，不重新部署

抑制作為工作區記憶存在於閘道中。規則保持與撰寫時完全一致；你的應用程式繼續不變地呼叫 /v1/*。

工作區範圍的記憶

一個 Admin 標記它一次；抑制在工作區內去重，所以每個成員的流量都受益——無需逐金鑰擴散。

可逆

取消標記匹配（或刪除抑制），該發現就會在下次請求上再次觸發。沒有東西被摧毀。
抑制用於一個你判斷為良性的發現。如果一整條規則校準錯誤——形狀錯、階段錯——請修正規則並在 評測工具 中證明它，而不是一個接一個地靜音匹配。

​
2. 一個匹配如何成為一個抑制

每條觸發的規則都會在工作區 匹配動態 中記錄一個 match——規則類型、動作、階段，以及一個詳情字串。當你把那些匹配之一標記為誤報時，閘道會為該發現推導出一個穩定的指紋並把它寫入工作區的抑制清單。在每個未來請求上，引擎會把每個發現的指紋與那份清單核對，並在一個被抑制的發現能封鎖、遮罩或標記之前略過它。 兩種發現會產生一個指紋：
一個 CVE ／ SBOM 發現已經出貨時帶有一個穩定身份——公告或元件身份隨發現一起傳遞。抑制一個就靜音那個確切的 CVE／元件，而且只有那一個。這是抑制儲存為其建造的原生案例。
關鍵字、正規表示式、PII 與其他確定性規則類型沒有它們自己的身份，所以閘道會從在寫入側（你的 mark-FP 點按）與強制執行側（下一個請求）都相同的資料合成一個：防護欄、規則的匹配身份，以及——當原始擷取開啟時——匹配到的子字串本身。
合成指紋的精確度取決於 Log raw content，而它預設為關閉。在擷取開啟時，指紋以確切的匹配子字串為鍵，所以抑制 ORD-48291507 靜音那個訂單號而非其他任何東西。在擷取關閉時，沒有子字串可作為鍵，所以抑制回退為一個規則層級的靜音——它為工作區靜音那一條規則（在那個階段）。回退永不會延伸到它源自的規則之外。參見 日誌與隱私。

​
3. 一個具體範例

假設你執行一條 regex 規則，遮罩形狀為 ORD- 加上八位數字的內部訂單號。一張客服工單以一種你已決定可以放行的方式合法地引用 ORD-48291507。你不想削弱規則——你只想要這一個號碼停止觸發。
1

開啟 Matches 動態

在主控台中開啟 Guardrails → Matches。按防護欄與規則類型篩選以找到 ORD-48291507 命中的那一列。（若要看到字面子字串，記錄該匹配時防護欄的 Log raw content 必須曾開啟——它預設為關閉。）
2

把它標記為誤報

開啟匹配詳情並選擇 Mark as false positive。作為一個工作區 Admin，這會為匹配蓋章並映射一個以該發現指紋為鍵的工作區抑制。
3

確認它被抑制

開啟 Suppressions 清單——新項目會出現，標記它源自的防護欄與規則，以及理由 “Marked as false positive from Matches”。工作區的每個成員都能讀取這份清單。
4

再次發送相同的請求

用你的中繼金鑰，像以前一樣呼叫 OrcaRouter——無新標頭，無需修改 SDK：
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Status of order ORD-48291507?"}
    ]
  }'
被抑制的發現被略過——ORD-48291507 通過——而任何其他訂單號仍會匹配並像以前一樣被遮罩。

​
4. 抑制對替代方案

抑制是平息一條吵雜規則的四種方式之一。挑選最狹窄的合適方式：
方法它改變什麼何時使用
標記 FP一個發現（或一條規則，擷取關閉）一個特定的良性命中；規則在其他方面是對的
編輯規則匹配本身形狀／階段錯——修正它，然後重新評測
flag 動作僅觀察，不封鎖一條你還不信任的新規則
評測工具無實際生效——只衡量在你出貨前證明精確度
別藉由一個接一個地標記 FP 來掩蓋一條系統性錯誤的規則。如果你反覆抑制相同的形狀，規則就是校準錯誤——為 正規表示式 加上錨點、收窄 關鍵字清單，或挑選一個更緊的 PII 實體，並用一次 評測執行 驗證。

​
5. 逆轉一個抑制

這裡沒有任何東西是單向的：
  • 取消標記匹配——同樣的 Admin 動作，逆轉，移除匹配的 FP 蓋章，並（當沒有其他被標記 FP 的匹配仍映射到它時）丟掉抑制。該發現在下次請求上再次觸發。
  • 直接刪除抑制——從 Suppressions 清單，一個 Developer+ 動作移除該項目。同樣的效果：該發現再次生效。
由於抑制是工作區記憶，逆轉一個就一次性為每個成員的流量還原捕捉——與把它為所有人抑制的方式相同。

​
6. API 介面

這些是主控台路由，由你的工作階段驗證——而非中繼金鑰。為每個動作做角色把關：標記一個匹配 FP 是 Admin；抑制讀取是 Member；抑制寫入是 Developer+。
方法與路徑角色用途
GET /api/guardrail/matchMember列出匹配以分流。
POST /api/guardrail/match/:id/mark-fpAdmin把一個匹配標記為誤報（映射一個抑制）。
DELETE /api/guardrail/match/:id/mark-fpAdmin取消標記——還原該發現。
GET /api/guardrail/suppressionsMember列出工作區作用中的抑制。
POST /api/guardrail/suppressionsDeveloper+直接新增一個抑制。
DELETE /api/guardrail/suppressions/:idDeveloper+移除一個抑制。
mark-FP 端點受限速——它們是一個刻意的、低量的分流動作，而非一個批量 API。當你調校一整個政策時，使用評測工具，而非一個 mark-FP 呼叫的迴圈。

​
7. 下一步去哪裡

匹配動態

每條觸發的規則落地的地方——你在標記任何東西之前分流的地方。

測試與評測

在你出貨前針對一個語料庫證明一條規則的精確度——當抑制只是在處理一個症狀時的系統性修正。

日誌與隱私

Log raw content 如何控制抑制以確切子字串為鍵還是回退為規則層級靜音。

防護欄參考

完整引擎——每種規則類型、動作與路由。
抑制治理內容發現。若要平息一條吵雜的代理防火牆規則——一個你判斷為安全的工具匹配——那是一個獨立的介面；參見 防火牆 及其 異常動態。若要理解防護欄與防火牆在哪裡分界，請閱讀 防護欄與防火牆。