跳轉到主要內容
你有一份絕不能抵達模型或從模型回來的詞彙清單——一個競爭對手的名稱、一個內部代號、一個被禁的辱罵詞、一個尚未發布的產品。針對這點最快的控制是一個關鍵字封鎖清單：一份字面詞彙的清單，閘道會在每次呼叫上掃描它，然後封鎖、遮罩或標記。 這是禁用詞使用情境的一個聚焦落地頁。完整的防護欄引擎——每種規則類型、欄位與路由——請見 防護欄參考。

​
1. AI 敏感詞過濾使用情境

一條 keyword 規則是引擎中最簡單的規則：你給它一份詞彙清單，閘道就會在某階段針對文字比對其中任何一個。比對是不分大小寫的子字串——BadWord、badword 和 BADWORD 都會匹配，而且即使該詞嵌在一個更長的詞中也會匹配（所以 class 也會匹配 classic）。每個詞被視為一個字面字串，而非模式；你不必跳脫正規表示式的元字元。 在主控台中儲存規則一次，把防護欄綁定到任何 API 金鑰（或將它設為工作區預設值），那把金鑰上的每次呼叫都會被審查，無需修改 SDK，無需重新部署。政策存在於閘道中，而不是你的應用程式中——你的應用程式像以前一樣繼續呼叫 /v1/chat/completions。
當你的封鎖清單是一組有限的字面詞彙時，使用 keyword 規則。當你需要萬用字元、字邊界或結構（一個 SKU 格式、一個訂單號形狀）時，改用 正規表示式偵測器。

​
2. 在主控台中撰寫規則

這裡的每個步驟都是你自己工作階段下的一個主控台動作。建立與編輯防護欄需要工作區中的 Developer+。只有最後的 /v1/* 呼叫使用 sk-orca-... 中繼金鑰。
1

建立防護欄

在主控台中開啟 Guardrails 並按一下 New guardrail。把它命名（≤ 64 字元），例如 banned-terms。
2

新增一條關鍵字規則

新增一條規則：
  • 類型： Keyword denylist (keyword)
  • 階段： Both（請求與回應）
  • 動作： Block
  • 關鍵字： 你的禁用詞，每列一個
儲存。
3

測試它

開啟 Test 分頁，貼上一個包含禁用詞的樣本，選擇一個階段，並在本機執行政策——沒有上游呼叫，不消耗配額（參見 §5）。
4

綁定一把金鑰

編輯一個 API 金鑰並從 Guardrail 下拉選單選擇 banned-terms（在金鑰上設定 guardrail_id），或將防護欄標記為工作區預設值。參見 綁定到金鑰 和 帳戶預設值。
規則的 JSON 正是你會預期的樣子： 
{
  "type": "keyword",
  "stage": "both",
  "action": "block",
  "keywords": ["project-orca", "competitor-name", "unannounced-sku"]
}

​
3. 選擇動作

一條關鍵字規則每條規則挑選一個動作：
任何匹配都會以 HTTP 400 guardrail_blocked 拒絕請求。一個被封鎖的請求不消耗配額——輸入階段封鎖在計量之前觸發；輸出階段封鎖會退還已預先扣除的配額——並被標記為 skip-retry。用於絕不能在任一方向通過的詞彙。參見 guardrail_blocked 錯誤。
每個匹配項會就地替換為一個隱碼標籤，而請求以淨化後的文字繼續——上游模型永遠看不到原始詞彙。參見 動作。
記錄一個匹配且不改變流量的任何部分。用它來在切換到強制執行之前衡量一個詞彙多常出現。
把匹配到的文字包裹在分隔符中（例如 ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧），讓模型把它當作資料而非指令——一種輸入階段的提示注入防禦。文字仍會抵達模型，只是被圍起來。參見 動作。
階段很重要。 input 掃描呼叫方的請求，output 掃描模型的回應，both 各自獨立掃描兩側。你的使用者輸入的一個禁用詞與一個模型可能發出的禁用詞是不同的問題——挑選符合的階段。參見 輸入階段規則 和 輸出階段規則。

​
4. 串流覆蓋

你挑選的動作會與回應是否串流互動：
動作非串流串流
block（輸出）強制執行強制執行——掃描器切斷串流
mask（輸出）強制執行尚未——遵守封鎖決策，遮罩後的文字不轉送（規劃中）
輸入階段規則在上游呼叫之前執行，所以它們不受串流影響——一個輸入 mask 無論回應是否串流都會淨化請求。一個禁用詞 block 在兩種情況下都得到完整覆蓋。然而，一個輸出 mask 今天只在非串流回應上遮罩：在一個串流回覆上，掃描器仍會對封鎖決策採取行動，但串流文字的帶內改寫仍在規劃中，尚未上線。參見 串流覆蓋。

​
5. 綁定前先測試

在任何金鑰指向它之前，先證明規則如你所期望地運作。開啟編輯器內的 Test 分頁，貼上一個樣本，選擇階段，然後執行： 
Tell me about Project-Orca and our competitor-name
沙盒會在本機評估目前的政策並傳回裁決——不會向上游傳送任何東西，也不會計量任何東西。用 block 動作時樣本會被拒絕；用 mask 時渲染後的文字會回傳，每個詞彙都被遮罩。 若要針對一個語料庫進行 A/B 網格測試——以確認一份封鎖清單捕捉到它該捕捉的東西而不標記良性流量——評測工具 就在隔壁分頁。

​
6. 發送請求

用一把綁定到 banned-terms 的金鑰，像以前一樣呼叫 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": "Summarize Project-Orca for me"}
    ]
  }'
用 block 動作時，呼叫會在抵達模型之前就以 HTTP 400 guardrail_blocked 被拒絕。把動作換成 mask，該詞彙就會改為在轉送前就地被遮罩。

​
7. 查看觸發了什麼

每條觸發的規則都會記錄一個 match——規則類型、動作、階段，以及一個詳情字串（對於關鍵字規則，是有多少個詞彙匹配）——呈現在工作區 Matches 動態中。
匹配到的詞彙本身只在 Log raw content 開啟時才會記錄，而它預設為關閉——隱私保守姿態。在它關閉時，你仍能看到某條關鍵字規則觸發了以及多常觸發，只是看不到字面詞彙。當你需要子字串進行分流時，逐個防護欄開啟它；該設定不可追溯生效。參見 匹配動態 和 日誌與隱私。
如果一個良性詞彙持續匹配（一個是常見詞子字串的封鎖清單項目），從 Matches 動態把它標記為誤報並收緊該項目。參見 調校誤報。

​
8. 下一步去哪裡

正規表示式偵測器

當字面封鎖清單不夠時，匹配結構化模式——SKU、訂單號、格式。

品牌安全

建立在關鍵字規則之上的髒話、競爭對手提及與兒童安全預設。

動作

block、mask 與 flag 有何不同，以及何時使用各自。

防護欄參考

完整引擎——每種規則類型、欄位與路由。
一個關鍵字封鎖清單治理內容。若要治理一個代理的工具呼叫——拒絕破壞性動作、遮罩工具呼叫引數、要求審批——請使用 防火牆。對於任何字面清單都無法表達的模糊政策（有害性、離題、注入意圖），一條 llm_judge 規則 會針對一個工作區模型執行語意檢查。