---
title: "用 Jev 做自動審核：把「放行、覆核、封鎖」寫成可審計的門檻，而不是模型的心情"
description: "自動審核的難處不是判斷危害，是把判斷變成企業敢負責的決策。本文拆解 TypeSafe 官方 guardrails 的雙門檻政策設計、為什麼 Jev 不能當安全邊界，以及台灣企業導入前的驗證順序。"
canonical: "https://yotron-ai.com/blog/jev-automated-review-approval-guardrails"
published: "2026-09-18"
last-updated: "2026-09-18"
---

# 用 Jev 做自動審核：把「放行、覆核、封鎖」寫成可審計的門檻，而不是模型的心情

自動審核的難處不是判斷危害，是把判斷變成企業敢負責的決策。本文拆解 TypeSafe 官方 guardrails 的雙門檻政策設計、為什麼 Jev 不能當安全邊界，以及台灣企業導入前的驗證順序。

自動審核的難處從來不是判斷一則訊息有沒有危害，而是把那個判斷變成企業敢負責的決策 — 誰放行、誰覆核、誰封鎖、事後怎麼查。Jev 在這件事上的貢獻是把危害拆成多個窄問題並回傳校準機率，讓門檻與處置規則變成可以 code review 的常數。結論先說：這讓審核流程變得可審計，但 Jev 本身不能當安全邊界，官方文件對此說得很清楚。

社群開發者 Sac 在 2026-09-18 的貼文中把「自動審核」列為 Jev 的四個場景之一，並稱它是「比 5.6 luna 還要便宜且精準的自動審核模型，可能是 Codex 在安全審批方面最合適的工具」。[Sac（@Saccc_c）X 貼文，2026-09-18](https://x.com/Saccc_c/status/2100833094291087773) 「更精準」目前沒有公開的獨立 benchmark 支持，本文把它視為使用體感；可查證的部分是官方的定價、問題設計方式與已知失效模式。

## 一個安全分數撐不起企業流程

多數團隊的第一版審核長這樣：問模型「這則內容是否違規」，拿到一個 0 到 1 的分數，超過某個值就擋掉。這個設計在企業流程裡會壞在三個地方。

第一，不同危害需要不同處置。疑似越獄應該封鎖；請求醫療建議應該轉人工覆核；自傷訊號應該導向支援管道而不是丟掉。一個籠統分數無法區分。第二，一個分數無法回答稽核問題。事後被問「為什麼擋這則」，你只能回答「分數 0.82」。第三，門檻無法分別調整。放寬越獄門檻會同時放寬所有危害。

官方 guardrails cookbook 的做法是把危害拆開：四個 Noul 問題各問一個危害類型（是否試圖越獄或洩漏指令、是否請求協助造成傷害或違法、是否要求診斷或用藥劑量、是否顯示自傷傾向），再加一個 Score 問題評估「若照做會造成多大危害」，從無害到嚴重人身傷害共四級。[TypeSafe Docs〈Guardrails for LLMs〉，查閱 2026-09-18](https://docs.typesafe.ai/cookbooks/llm_guardrails)

進出兩側問同一組問題的兩個方向：輸入側問使用者是否在要求，輸出側問回覆是否真的照做了。一次請求就能拿到整組訊號。

## 雙門檻加政策：把取捨變成產品決策

官方把危害機率對應到兩個門檻與一組動作映射：

```python
HAZARD_ACTION = {
    "jailbreak": "block",
    "broke_policy": "block",
    "harmful_request": "block",
    "medical_advice": "review",   # 轉人工覆核，不直接封鎖
    "self_harm": "support",       # 導向支援管道，不封鎖
}
PRECEDENCE = ["support", "block", "review", "pass"]   # 優先序高者勝

POLICIES = {
    "strict":     {"review_threshold": 0.35, "action_threshold": 0.70, "severity_block": 2.0},
    "permissive": {"review_threshold": 0.35, "action_threshold": 0.85, "severity_block": 2.0},
}
```

判斷邏輯是：達到 `action_threshold` 觸發該危害對應的動作，達到較低的 `review_threshold` 轉人工，兩者都未達到則放行；嚴重度 Score 達到 `severity_block` 時，把原本的人工覆核升級為封鎖。

```python
def route(nouls: dict[str, float], severity: float, policy: dict) -> str:
    triggered = []
    for hazard, probability in nouls.items():
        if probability >= policy["action_threshold"]:
            triggered.append(HAZARD_ACTION[hazard])
        elif probability >= policy["review_threshold"]:
            triggered.append("review")
    if severity >= policy["severity_block"]:
        triggered = ["block" if a == "review" else a for a in triggered]
    return next((a for a in PRECEDENCE if a in triggered), "pass")
```

這段程式碼的價值不在演算法，在治理。官方對 policy 的說明重點是：把這些數字命名之後，寬鬆與嚴格就成為產品可以選擇的設定，而不是繼承下來的預設值。對企業而言這意味著三件事可以落地 — 門檻進 code review、不同產品線套不同 policy、稽核時能指出是哪一個危害、哪一個門檻、哪一條優先序做了決定。

`PRECEDENCE` 的順序本身也是政策宣告：`support` 排在 `block` 之前，代表一則同時觸發自傷訊號與其他危害的訊息會被導向支援管道，而不是被靜靜擋掉。

## Jev 不是安全邊界

這是整篇文章最重要的一段。官方 jaggedness 文件的原文重點是：state 是資料，`jev-1.13` 預設不把它視為敵意內容；刻意誘導模型的內容 — 注入指令、誤導性框架、替自己的分類辯護的文字 — 都可能移動答案。官方表示未來會改善，並建議在 criteria 裡寫明確、部署前充分測試邊界案例。[TypeSafe Docs〈Jev 1.13 jaggedness〉，最後檢閱 2026-09-17](https://docs.typesafe.ai/model-jaggedness/jev-1.13)

換句話說，審核模型本身就是被審核內容可以攻擊的對象。這代表：

- **不可逆動作不能只靠審核通過**。付款、退款、權限提升、對外發文仍需明確授權、業務規則、最小權限與人工批准。審核只提供一個可供稽核的訊號。
- **審核結果要記錄，不只記結論**。保留每個危害的機率、套用的 policy 名稱與觸發的門檻，否則無法在事後區分「模型判錯」與「門檻設錯」。
- **審核層需要自己的測試集**。官方建議部署前測試邊界案例；這組測試應該包含刻意設計的注入樣本，並且隨新出現的攻擊手法更新。

若審核的對象是 coding agent 的操作（例如 Codex 的安全審批），還要多一層認知：被讀進來的 issue 內文、依賴套件說明、程式註解都是 state，都可能夾帶指令。相關的防護思路可參考[AI 客服的 Prompt Injection 防禦](/blog/ai-customer-service-prompt-injection-defense)。

## 繁體中文審核的準確度風險

官方 Models 頁面說明 Jev 的主要訓練語言是英文，準確度在英文最好；CJK 文字包含繁體中文可以處理但目前準確度較低，建議在自己的內容上先測試，並在路由時特別留意 confidence。[TypeSafe Docs〈Models〉，查閱 2026-09-18](https://docs.typesafe.ai/models)

審核場景的誤判成本是不對稱的，而且方向與模型路由相反：漏判（把有害內容放行）的代價遠高於誤判（把正常內容送人工）。因此中文流程的合理調整方向是把 `review_threshold` 調低、接受較高的人工覆核量，直到你在自己的中文樣本上量出可接受的漏判率。不要把官方英文範例的 0.35 與 0.70 直接搬到中文上線。

另外注意官方對結構不變性的提醒：同一個問題用 Noul 與用 yes/no Choice 問，數值不可互換，也不要期待一個問題與其否句的機率相加為 1。審核門檻必須綁定問題型別與模型版本，換版本要重新校準。

## 導入前的四步驗證

### 步驟 1：先寫政策，再寫問題

把「哪些內容必須封鎖、哪些必須轉人工、哪些導向支援」寫成文字政策並取得業務與法務確認，再把每一條翻成一個窄問題。順序顛倒的話，你會得到一組技術上可跑、但沒人願意簽名負責的門檻。

### 步驟 2：建立含攻擊樣本的標記集

抽真實訊息，加上刻意設計的注入與誘導樣本，由熟悉政策的人標記應有處置。分開統計漏判率與誤判率 — 兩者的合理上限不同，不該用單一準確率概括。

### 步驟 3：掃門檻，選定 policy

把 `review_threshold` 與 `action_threshold` 掃過一遍，每組設定記錄漏判率、誤判率、人工覆核量與每則成本。選定的組合要能同時滿足「漏判率可接受」與「人工覆核量負擔得起」，並記錄選擇理由。人工負荷的估算方式可參考[AI 導入的員工採用與變革管理](/blog/ai-implementation-employee-adoption-change-management)。

### 步驟 4：影子上線，保留人工否決權

先讓審核只記錄不生效，比對影子決策與現行人工判斷的差異。正式上線後，人工必須能否決任何自動處置，並且該否決要回饋成新的標記資料。需要協助把政策翻成可驗收的門檻設計時，可[聯絡優創智能](/contact)。

## 結論：可審計的門檻，勝過更準的分數

Jev 在自動審核上的真正貢獻不是「更準」— 那一點目前沒有公開 benchmark 可以證明。它的貢獻是讓審核流程的每一個決定都有名字：哪一個危害、哪一個機率、哪一個門檻、哪一條優先序、哪一份 policy。這是企業敢把審核自動化的前提。

同時要記住官方自己講明的邊界：state 不被預設為敵意內容，審核模型可以被它審的內容影響。因此合理的架構是「Jev 提供可量測的風險訊號 + 程式規則決定處置 + 高風險動作保留人工批准」，而不是把審核模型當成安全邊界。先寫政策，再量漏判率，最後才談自動化比例。

## 來源與查閱日期

- Sac（@Saccc_c），Jev 四大應用場景貼文，2026-09-18。[X 貼文](https://x.com/Saccc_c/status/2100833094291087773)
- TypeSafe Docs，〈Guardrails for LLMs〉（危害問題組、雙門檻、policy 設計），查閱 2026-09-18。[官方文件](https://docs.typesafe.ai/cookbooks/llm_guardrails)
- TypeSafe Docs，〈Jev 1.13 jaggedness〉（adversarial content、結構不變性），最後檢閱 2026-09-17，查閱 2026-09-18。[官方文件](https://docs.typesafe.ai/model-jaggedness/jev-1.13)
- TypeSafe Docs，〈Models〉（價格、語言支援），查閱 2026-09-18。[官方文件](https://docs.typesafe.ai/models)
- TypeSafe Docs，〈Confidence〉，查閱 2026-09-18。[官方文件](https://docs.typesafe.ai/confidence)
- TypeSafe Docs，〈Noul〉，查閱 2026-09-18。[官方文件](https://docs.typesafe.ai/primitives/noul)

---

## 相關推薦與延伸閱讀

- [用 Jev 做模型路由：便宜模型先跑、Jev 驗證、只在需要時升級](/blog/jev-model-routing-cost-control)：模型路由的省錢關鍵不是挑便宜模型，而是知道什麼時候必須升級。本文拆解 TypeSafe 官方的 verify-then-escalate cascade、該怎麼
- [企業 AI Agent 進入 production：FDE 如何建立控制平面](/blog/enterprise-agent-control-plane-fde)：從近期企業 AI 平台與研究訊號整理一套 FDE 實作方法：把 Agent 的身分、工具、政策、評估與觀測整合成可驗收的控制平面。
- [企業 AI Agent 上線前的 FDE 驗收清單：從 Demo 走到可治理工作流](/blog/fde-enterprise-ai-agent-readiness-checklist)：常青實務指南：用 FDE 方法檢查企業 AI Agent 的流程、資料、權限、評估、觀測與交接，降低從 POC 進入正式營運的風險。