跳轉到主要內容
你可以把一個防護欄綁定到單一 API 金鑰，但大多數團隊想要一個底線：一份套用於工作區中每一把金鑰的內容政策，除非某把金鑰選擇了其他東西。那個底線就是工作區預設值——一個標記為 is_default 的防護欄，每當一把金鑰沒有明確綁定時閘道就會回退到它。 本頁涵蓋預設 AI 防護欄：如何設定它、解析如何運作，以及一個值得記住的不變量——每個工作區一個預設值。完整的引擎參考請見 防護欄參考。
這裡的一切都是託管閘道（api.orcarouter.ai）上的一個主控台動作，在你自己的工作階段下執行。只有最後的 /v1/* 呼叫使用 sk-orca-... 中繼金鑰。晉升或降級一個預設防護欄需要工作區中的 Developer+。

​
1. 為何設定一個預設 AI 防護欄

逐金鑰綁定很精確但容易忘記——簽發一把新金鑰、跳過下拉選單，那把金鑰就帶著零審查出貨了。工作區預設值填補了這個缺口：

無綁定的金鑰繼承它

任何 guardrail_id 未設定（0／null）的金鑰都會自動被預設值審查——包括你設定它之後建立的金鑰。

編輯一次，切換整個工作區

預設值存在於閘道中，而不是在每一把金鑰上。編輯它，每一把繼承的金鑰就會在下次呼叫時切換——無需重新部署，無需修改 SDK。
一個常見模式：把一個保守的 PII Shield 設為工作區預設值，這樣就不會有東西意外洩漏，然後讓特定金鑰在需要時綁定一個更嚴格或更寬鬆的政策。

​
2. 將一個防護欄晉升為預設值

在主控台中開啟 Guardrails，編輯你想當作底線的防護欄，並切換 Set as workspace default。儲存。
1

建立或選擇一個防護欄

像往常一樣撰寫一份政策——例如 PII Shield 預設，一條在 both 階段遮罩的 pii 規則。
2

標記為預設值並儲存

開啟 Set as workspace default 並儲存。防護欄的 is_default 旗標會翻為開啟。
3

讓金鑰保持未綁定

任何沒有明確防護欄的金鑰現在都會繼承這一個。已經指向不同防護欄的金鑰會保留它們的綁定。
預設值還必須是已啟用的才會生效。一個標記為 is_default 但已停用的防護欄會解析為不執行強制——這個切換與啟用狀態是各自獨立的開關。

​
3. 每個工作區一個預設值——晉升是原子的

這是不變量：每個工作區最多一個防護欄帶有 is_default。你永遠不必手動取消設定舊的那個。 當你把一個新防護欄晉升為預設值時，閘道會在同一交易中降級先前的預設值——晉升與降級要嘛都生效，要嘛都不生效。永遠不會有兩個防護欄同時為預設值的窗口，也永遠不會有沒有任何一個為預設值的窗口。 
Before:   billing-pii   ← is_default ✓
          legal-redact

Promote "legal-redact" to default
          (single transaction)
          ┌─────────────────────────────────────────┐
          │  legal-redact  → is_default = true       │
          │  billing-pii   → is_default = false       │
          └─────────────────────────────────────────┘

After:    billing-pii
          legal-redact  ← is_default ✓
你不必先降級。只要晉升新的那個——舊的預設值會被原子地為你清除。被降級的防護欄仍然存在並保持啟用；它只是不再作為回退。明確綁定到它的金鑰不受影響。
無論你是在建立時晉升（把一個全新的防護欄標記為預設值）還是在編輯時晉升（在一個現有的防護欄上翻動旗標），都套用相同的原子交換。

​
4. 解析如何使用預設值

對任何請求，閘道會按此固定順序解析出恰好一個防護欄（或無）：
順序套用什麼
1金鑰明確的 guardrail_id——如果它存在且已啟用。
2工作區已啟用的 is_default 防護欄（金鑰沒有綁定）。
3無——請求與沒有政策的工作區位元組完全一致。
明確的金鑰綁定永不會靜默回退到預設值。如果一把金鑰指向一個防護欄而那個防護欄被停用了，該金鑰就解析為不執行強制——而不是工作區預設值。停用一個綁定的防護欄是那把金鑰的關閉開關。（防火牆政策在這裡行為不同——一個已停用的綁定防火牆政策確實會回退到工作區預設值。參見 防護欄與防火牆。）
所以預設值只是未綁定金鑰的回退。它永不會覆寫一把做出明確選擇的金鑰。
設計上的失敗開放（fail-open）。 如果預設值解析遇到暫時性錯誤，閘道會降級為不執行強制，而不是讓請求失敗。安全性降級；可用性得以保留。

​
5. 實作範例

假設你的工作區有兩個防護欄和三把金鑰：
  • pii-shield——標記為工作區預設值，已啟用。
  • strict-block——封鎖信用卡，非預設值。
  • 金鑰 A——無綁定。金鑰 B——綁定到 strict-block。金鑰 C——綁定到一個你之後停用的防護欄。
一個提及電子郵件的請求會這樣解析：
guardrail_id 未設定，所以解析落到已啟用的 is_default 防護欄 pii-shield。電子郵件在模型看到之前就被遮罩為 [EMAIL]。
明確綁定勝出。strict-block 套用；預設值永不被諮詢。
綁定存在但它的防護欄已停用，所以解析傳回無——它不會落到 pii-shield。請求未被審查。
現在把 strict-block 晉升為預設值並儲存。在一個交易中 strict-block.is_default 變成 true 而 pii-shield.is_default 變成 false。金鑰 A 會在它下次呼叫時立即繼承 strict-block——而無需對金鑰本身做任何變更。

​
6. 確認請求命中了預設值

用一把未綁定的金鑰發送請求，並檢查 匹配動態——一筆記錄在你預設防護欄下的匹配就確認回退觸發了： 
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": "Reply to jane@acme.com please"}
    ]
  }'
如果預設值是一份遮罩 PII 政策，閘道會在轉送前把電子郵件改寫為 [EMAIL]。如果它封鎖，呼叫會傳回 HTTP 400 guardrail_blocked——它不消耗配額並被標記為 skip-retry。完整的回應形狀請見 guardrail_blocked 錯誤。
想在任何金鑰依賴它之前就證明預設值的行為？在防護欄編輯器中開啟 Test 分頁並在 input 階段執行一個樣本——沒有上游呼叫，不消耗配額。參見 測試與評測。

​
7. 下一步去哪裡

綁定到單一金鑰

當一把金鑰需要與工作區底線不同的政策時。

建立你的第一個防護欄

端到端的流程——建立、測試、綁定、發送。

解析與範圍

金鑰、政策與工作區如何組合。

版本控制

每次晉升都會寫入一筆歷史列——比對與還原。
晉升或降級預設值本身就是一次版本化的變更——在防護欄上開啟 History 以查看 is_default 何時翻動以及是誰做的。完整引擎請閱讀 防護欄參考。