Jev 與 System One：把 AI 判斷接進軟體流程

補充教材草稿，供審閱 本文屬 iPAS AI 應用規劃師 66 課之外的選修深入探討，不是新增的官方課次，也不代表 iPAS 官方考試範圍。文中的考題是自編練習題。產品文件查閱日期：2026-10-07。服務功能、模型版本、價格、平台與限制可能更新，實際導入前應查閱當期文件。

本課要學會什麼

讀完本課，你應能針對一項需要理解文字、但答案範圍可以預先描述的企業工作，規劃出一條可檢查的 AI 決策流程：哪些資料交給模型判斷、哪些條件交給程式驗證、何時轉交人員，以及如何用自己的資料檢查結果。

課程以 TypeSafe 的 Jev 為例。TypeSafe 將 Jev 稱為第一個 System One Model，定位為軟體可直接使用的結構化決策模型。它接收一份 state（判斷所需狀態資料）和一組 questions（問題規格），再回傳符合預先定義型別的答案、機率，以及部分題型的 confidence（信心分數）。TypeSafe 的 System One 說明、官方模型文件

先記住本課的分工原則：模型提供語意判斷；程式掌握資料、規則、權限與副作用；人員決定政策、風險門檻和核准責任。 這個分工能讓 AI 參與工作流程，同時保留可追蹤的控制點。

1. 從客服留言看見架構問題

假設企業客服收到一則訊息：

「這筆費用好像扣了兩次；三天前我已申請退款，請盡快幫我處理。」

應用程式可能需要回答幾個不同問題：

這件事應交給哪個承辦佇列？
使用者是否提到先前已提出退款申請？
依文字內容，案件急迫程度如何？
交易系統是否真的記錄兩筆扣款？
是否符合退款政策？
誰有權核准退款？

這些問題看起來都像「判斷」，實際上需要不同的處理方式。前三項需要理解自然語言，Jev 可以提供結構化判斷；第四項應查詢交易紀錄；第五項要依政策和交易資料運算；第六項屬於權限與治理。

如果把所有事情交給生成式大型語言模型（LLM），應用程式要解析文字答案，再檢查內容和格式。如果全部寫成關鍵字規則，語意稍有變化就可能漏接。System One Model 提供另一種介面：把答案範圍先定義清楚，讓模型針對範圍內的問題判斷，再由程式把結果接回原有流程。

這個方法的價值來自責任切分。模型可以協助處理語意彈性，程式保留可確定計算和權限控制，人員負責政策、風險容忍度與例外核准。

2. System One 是軟體決策介面

TypeSafe 將 System One Model 定義為一類面向軟體流程、輸出結構化判斷的模型。Jev 可理解自然語言，但主要輸出是指定型別的答案和機率，而非自由撰寫的說明文字。官方文件也指出，目前 Jev 接受文字、JSON 物件或文字陣列，圖片、音訊和影片需先由其他流程轉成文字或結構化欄位。TypeSafe：System One

「System One」這個名稱借用 Daniel Kahneman 對快速、直覺式思考的描述，作為產品定位的比喻。它不表示模型照著人的心理歷程運作，也不表示它能取代需要長篇推理、創作或討論的生成式模型。TypeSafe 將其訓練方向描述為校準決策，並以 Reinforcement Learning for Calibrated Decisions（RLCD）稱呼相關訓練方法；這是供應商公布的技術描述，實際使用仍要透過任務評估確認效果。TypeSafe 官方介紹、模型文件

Jev 與聊天型 LLM 的工作分工

工作需求	常用工具	系統會取得什麼
撰寫回覆、產生摘要、改寫文字、生成程式碼	生成式 LLM	自由文字或程式內容，適合需要生成的工作
從固定類別選一項、評定有序等級、判斷是或否	Jev 等決策模型	受限型別、各選項或等級機率，以及可用於分流的信心資訊
加總金額、比較日期、確認權限、檢查交易紀錄	一般程式與權威資料來源	可重現、可驗證的計算或查詢結果
訂定退款規則、接受風險、核准重大例外	有權責的人員與正式治理流程	被授權的政策、門檻與核准紀錄

兩類模型可以放在同一套系統的不同節點。例如，Jev 先判斷留言屬於哪個類別；生成式模型再依核准的政策草稿撰寫客服回覆；應用程式最後執行權限檢查並保留寄送核准狀態。

型別安全能讓程式依固定欄位讀取答案，降低格式錯誤和自由文字解析負擔。它保證的是輸出形式符合規格，語意判斷仍須依任務資料評估。若模型把案件分到錯誤部門，回傳值即使完全符合 schema，也仍然是錯誤的分類。

3. 三種問題型別，對應三種答案空間

Jev 的問題型別應由「答案可能長什麼樣」決定，而不是只看業務部門怎麼稱呼這項工作。官方文件列出 Choice、Score 和 Noul 三種基本型別。TypeSafe 的原始問題型別說明

3.1 Choice：從固定類別中選一項

Choice 適合答案屬於彼此區分的類別。例如承辦部門可以是 billing（帳務）、technical（技術）或 account（帳戶）。每個選項都應提供清楚定義，並加入 other、unknown 或「需要人工判定」等實際可能出現的情況，避免所有案件被迫塞進不合適的類別。

Choice 的回傳通常包含選定項目、每個選項的機率分布與 confidence。選項機率呈現模型在各類別之間的分配；信心分數整理分布是否集中，供程式依任務規則分流。TypeSafe：Choice

設計選項時，答案名稱和說明要讓邊界清楚。例如「帳務」要定義為付款、發票與退款問題；「技術」要定義為系統錯誤、整合故障與服務中斷。若兩個選項的描述大量重疊，模型和審查人員都會難以一致分類。

3.2 Score：在有順序的尺度上評分

Score 適合有明確順序的等級，例如一般、優先、緊急，或輕微、中度、嚴重。每一級以文字描述，並依低到高排列。Score 會回傳各等級機率和一個位置分數；分數可能落在等級之間，因為它是依等級機率形成的加權結果，不一定是模型直接挑選某一個整數級別。TypeSafe：Score

假設急迫程度的等級為 0「一般處理」、1「需要優先追蹤」、2「需立即處理」。若機率為 0.05、0.25、0.70，回傳分數可能接近 1.65。這個數值表示機率集中於較高等級，並不代表客觀世界存在一個精確到小數點的「急迫量」。若業務規則只需要分級，應依評估結果設定區間，再由程式套用。

3.3 Noul：判斷一個命題為是的機率

Noul 用於是／否問題，例如「留言是否提到先前申請退款？」回傳值介於 0 和 1，代表模型對「是」的機率；接近 0.5 表示正反兩邊接近。Noul 不另外提供 Choice 或 Score 那種 confidence 欄位，因為這個機率本身描述二元答案分布。TypeSafe：Noul

若回傳 0.93，可解讀為模型對「是」給出 0.93 的機率。系統應以驗證資料檢查此值在本任務中的表現，不宜直接把它當成「這類答案有 93% 實測正確率」。

3.4 同一請求中的多個問題

Jev 可在同一次呼叫中評估多個問題；官方文件指出，各題都根據同一份 state 獨立判斷。這適合把一張客服工單同時分類、判斷是否提到退款，以及評估急迫程度。

「獨立」是設計上的重要限制。如果第二個問題只在第一題選到某個類別時才有意義，程式不能假定第二題已讀取第一題答案。可以選擇將兩題一起送出，再由程式依第一題結果決定是否採用第二題；若第二題確實需要第一題的結果才能形成輸入，則應在程式中分兩階段呼叫。

較好的問題通常一次只要求一個判斷。例如，把「這是不是緊急退款而且符合政策？」拆成「是否提到退款」、「是否呈現急迫性」、「交易是否符合政策條件」等問題。前兩題可交給語意模型，政策條件由程式查證並組合。

4. 參考架構：把判斷接回有責任的流程

一個可審查的 Jev 工作流程，可以分成下列步驟：

使用者訊息
  → 驗證來源與存取權限
  → 程式查詢交易紀錄、政策版本與必要欄位
  → 整理最小必要 state
  → Jev 評估 Choice / Score / Noul
  → 驗證回應欄位與模型版本
  → 程式套用風險政策、權限與確定性條件
      ├─ 低風險且通過門檻：自動分流
      ├─ 資料不足或信心偏低：請求補充或轉人工
      └─ 涉及退款核准等副作用：建立覆核工作
  → 工具依授權狀態執行，並保留稽核紀錄
  → 比對後續結果，持續評估錯誤與門檻

4.1 建立可信且精簡的 state

state 是模型針對問題判斷時可使用的內容。程式應從可信資料來源取回所需欄位，標明欄位意義與資料時間，並移除和問題無關的資訊。客服分類可能只需要留言、已驗證的交易摘要、目前政策條文與案件狀態；整份客戶檔案通常不需要一併傳送。

本案例中的「交易是否重複」應由付款系統或資料庫查證，結果再以明確欄位放入 state。模型可協助理解留言中的意圖，卻不應以語意印象取代帳務事實。

4.2 把問題和準則寫清楚

下面是教學用的請求結構示意，不是可直接投入正式環境的程式。正式 API 欄位和 SDK 用法請以 TypeSafe Quick Start 為準。

{
  "state": {
    "message": "這筆費用好像扣了兩次；三天前我已申請退款，請盡快幫我處理。",
    "verified_transaction_facts": {
      "duplicate_charge_confirmed": true,
      "amount_twd": 1200,
      "refund_window_open": true
    },
    "policy_excerpt": "疑似重複扣款案件需由授權人員覆核後才能核准退款。",
    "policy_revision": "refund-policy-v3"
  },
  "model": "jev-latest",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "這則客服訊息最適合交給哪一個承辦佇列？",
      "criteria": {
        "billing": "付款、扣款、發票或退款問題",
        "technical": "系統錯誤、服務中斷或整合問題",
        "account": "帳戶資料、登入或訂閱設定問題",
        "other": "以上類別均不適用，需人工分類"
      }
    },
    "mentions_prior_refund": {
      "type": "noul",
      "instructions": "訊息是否提到使用者先前已提出退款申請？"
    },
    "urgency": {
      "type": "score",
      "instructions": "依訊息內容評估案件處理急迫程度。",
      "criteria": [
        "一般處理，沒有明確時間壓力或立即影響",
        "需要優先追蹤，有延誤或持續影響的線索",
        "需立即處理，有明確急迫性或重大持續影響"
      ]
    }
  }
}

這個範例把交易事實和文字判斷放在不同欄位。duplicate_charge_confirmed 由付款紀錄計算；Jev 的工作是讀懂文字並輸出承辦佇列、先前申請線索和急迫程度。把 policy_revision 放進 state，也讓後續稽核能知道模型是在什麼政策背景下判斷。

4.3 示意輸出如何回到程式政策

假設教學示意輸出如下：

queue.choice = billing
queue.probabilities = { billing: 0.76, technical: 0.15, account: 0.05, other: 0.04 }
queue.confidence = 0.68
mentions_prior_refund.noul = 0.93
urgency.score = 1.65
urgency.probabilities = { 0: 0.05, 1: 0.25, 2: 0.70 }
urgency.confidence = 0.48

這些數字是為了說明閱讀方式而編寫的示意值，不是實際呼叫結果。程式可以依經驗驗證後的門檻處理：若承辦佇列信心足夠，就先送到帳務團隊；若低於門檻，交由人工分類。mentions_prior_refund 只表示文字中提到先前申請，不能證明申請確實存在；程式仍應查詢案件系統。

對退款動作，流程再檢查已驗證交易、退款期限、政策版本、使用者身份和核准權限。這個例子中的政策要求授權人員覆核，因此系統建立退款覆核工作，保留證據和模型輸出，不直接付款。即使語意判斷的信心很高，系統仍依政策與權限狀態決定能否執行。

5. 機率、confidence 與實際正確率

這是導入者最容易混淆的地方。Jev 輸出的機率和信心資訊可以協助系統表示不確定性，但必須和「答案在實際資料上有多常正確」分開檢查。

5.1 Choice 的 confidence 反映機率分布集中程度

Choice 的 probabilities 會列出每個選項的機率；confidence 依分布形狀整理成 0 到 1 的數值。當機率集中在一個選項時，confidence 通常較高；分布平均或幾個選項接近時，confidence 會較低。TypeSafe：Confidence

依目前官方文件，Choice 有 n 個選項、最高選項機率為 p_max 時，confidence 的計算方式是 (p_max − 1/n) ÷ (1 − 1/n)。本例有四個類別，最高機率 0.76，所以 confidence 為 (0.76 − 0.25) ÷ 0.75 = 0.68。這是對機率分布集中程度的摘要，不是答案實際正確率。TypeSafe：Confidence

程式還可以查看次高選項、任務錯誤代價和資料品質。低信心可以觸發人工分類或補問；高信心則只是多一項分流依據。它沒有替企業設定好通用門檻，也不等於有一個普遍適用的「大於 0.8 就自動核准」規則。

5.2 Noul 的數值是「是」的機率

若 mentions_prior_refund.noul = 0.93，模型給「訊息提到先前退款申請」這個命題 0.93 的機率。它不提供獨立的 confidence 欄位。應用程式可用測試資料檢查 0.8、0.9 等門檻會造成多少誤判與漏判，再依工作風險決定是否採用。

5.3 Score 是沿著等級尺度的位置

Score 的 score 可能是小數，因為它由各等級的機率分布形成。上例分布 (0.05, 0.25, 0.70) 對應的期望位置是 0×0.05 + 1×0.25 + 2×0.70 = 1.65。這表示結果偏向高急迫等級，並非精密量測的 1.65 個單位。Score 的 confidence 也由機率分布計算，並考量各等級距離最可能等級有多遠；以這組示意機率計算約為 0.48。計算方式依官方文件所列公式處理。TypeSafe：Confidence

5.4 校準描述群體表現，不能代替單筆驗證

TypeSafe 將模型機率描述為經過校準，官方文件也提醒校準以一群預測的表現衡量，不能保證某一筆答案正確。企業仍需以自己的語言、流程、客群、資料品質和錯誤代價測試。尤其繁體中文是非英文主要訓練語言的工作負載，官方建議以自己的資料集驗證後再設定自動化門檻。TypeSafe：System One、TypeSafe：模型與語言支援

設計門檻時，至少要回答：

誤把帳務問題送到技術團隊的代價是多少？
漏掉急迫案件會造成什麼後果？
分流錯誤是否容易更正？
哪些錯誤必須由人員攔截？
人工覆核量增加到什麼程度會使流程失去效益？

讀取畫面、建立一般客服工單、核准退款和停用帳號的風險不同，應用不同門檻、權限和人工核准狀態。門檻應由錯誤成本與驗證證據共同決定。

6. 評估方式：用自己的工作流程建立證據

供應商展示能幫助我們提出假設，企業導入決策則需要自己的資料。建議依下列順序進行：

第一步：定義單一決策和成功條件

先選一個範圍明確、答案能描述的工作，例如客服佇列分類。定義哪些案件算成功、哪些錯誤最昂貴、資料會從哪裡來、結果將由誰採用。將成功條件寫成可量測指標，如每類 precision/recall、轉人工比例、錯誤路由成本、處理時間與每筆服務成本。

第二步：建立代表性評估資料

抽取有代表性的歷史案件，移除不必要的個人資料，請熟悉政策的人員標註正確分類和例外條件。資料中要包含模糊訊息、錯別字、縮寫、否定、雙重意圖、缺漏欄位和繁體中文常見寫法。對有爭議的標籤先訂明規則，不能把標註者意見不一致的資料假裝成唯一標準答案。

將資料分成設計、調整與保留測試用途的區段。準則和信心門檻在設計或調整區段形成；最後的保留測試資料用來檢查導入決策，避免反覆看同一批資料後高估成效。

第三步：比較同一流程中的候選方法

用相同輸入和成功條件，比較現有關鍵字規則、Jev、生成式 LLM 或「模型提出分類、人工確認」的方案。不要只比較模型答案；還要計入資料整理、呼叫費用、延遲、重試、人工覆核和錯誤修復的成本。

第四步：分析錯誤與信心區段

檢視各類 precision/recall、混淆矩陣、低信心比例、錯誤發生在哪些語言或案件型態，以及不同信心區段的實際命中率。若模型常把退款查詢與退款核准混為一談，應調整問題與選項邊界、補充 state，或將政策判定移回程式。

第五步：先觀察，再逐步開放自動化

先以 shadow mode（影子觀察模式）讓模型產生建議，但不執行動作；比對人員決策後，再挑選低風險、可回復的節點進行小流量試行。每一步都保留人工接手、回復策略、版本紀錄和監控警示。成效與錯誤型態穩定後，再評估擴大範圍。

7. 失效模式與治理控制

System One Model 適合聚焦的語意判斷；正式流程也要預先設計它容易出錯的位置。TypeSafe 對 Jev 1.13 公布的已知弱點包括字面解讀、精確數字與日期處理、間接推理、冗長且無關的 state、對抗性內容、矛盾條件和自由內容生成等。版本會更新，因此這份清單要依實際使用版本定期核對。TypeSafe：Jev 1.13 已知弱點

對應的工程控制

數字、計數、日期與權限： 由程式和權威資料源處理。模型可抽取文字線索，程式負責計算與比較。
多層判斷： 拆成單一問題，讓程式明確組合依賴關係；避免一個問題混合意圖、政策和核准權限。
選項邊界不清： 寫明涵蓋範圍、排除條件和例子；加入 other、unknown 或人工覆核路徑。
state 過長或資訊矛盾： 先以程式檢索、排序、去重和摘要；保留來源、日期、版本與可信度標記。
對抗性文字與提示詞注入： 將來自信件、網頁和文件的內容視為待分析資料；測試會要求模型改變政策、外洩資訊或跳過核准的輸入。程式的權限和動作白名單仍須獨立有效。
API 逾時、速率限制或服務不可用： 採用明確的失敗路徑，例如延後處理、轉人工或使用既有規則；失敗時不執行退款等副作用。
版本或 alias 更新： 記錄回應中的模型版本。若門檻依特定版本調整，先在測試環境驗證新版本，再安排切換與回復。

資料保護與繁體中文品質

Jev 是雲端 API。TypeSafe 表示客戶 request 和 response 不用於訓練 Jev，但這不等於資料沒有送出企業環境，也不會自動回答保存期間、資料所在地、第三方平台政策或企業授權問題。導入前應核對當期 Data Processing Agreement、隱私文件、帳號方案和企業資料政策；敏感欄位採資料最小化或遮罩處理。TypeSafe：模型與資料處理

官方文件指出 Jev 接受多種自然語言文字，但英文是主要訓練語言，非英文和 CJK 內容需以自己的資料檢驗。對台灣客服或公部門情境，測試集應涵蓋繁體中文、台灣慣用詞、口語、省略主詞、混用英文縮寫、否定句、日期寫法和本地政策用詞，再分別檢視各類錯誤。

8. 導入決策卡：什麼情況值得試用

啟動試行前，團隊可以一起填寫下列問題：

設計問題	本案例的回答示意
這一步要做哪一項語意判斷？	決定客服案件承辦佇列、是否提及先前退款、文字所呈現的急迫程度。
允許的答案範圍是什麼？	帳務、技術、帳戶、其他；急迫程度 0–2；是否提及先前退款。
哪些資料由程式查證？	交易紀錄、金額、退款期限、案件是否存在、政策版本和使用者權限。
模型信心不足時怎麼處理？	轉人工分類或向客服人員補問，保留原始留言和模型分布。
哪些動作需額外核准？	退款核准、付款、帳號停用與政策例外均依權限和核准流程辦理。
如何衡量效益與風險？	分類 precision/recall、錯誤成本、轉人工率、處理時間、服務成本與各信心區段表現。
如何回復？	記錄模型版本、保留既有規則分流、設定停用開關與人工接手佇列。

若團隊無法明確列出答案空間、錯誤成本、資料來源、動作權限和人工接手方式，應先補足流程規格，再考慮呼叫模型。若主要工作是精確計算、複雜長篇生成、多模態理解或政策授權，應由合適工具和明確責任人負責。

9. 本課整理

Jev 和 System One Model 提供一種「讓程式直接讀取 AI 判斷」的設計方式。它的核心價值是明確答案空間、結構化結果和不確定性資訊，讓程式能進行可追蹤的分支，而不是把每一步都包成自由文字。

設計時請依序問：

這是不是需要理解文字的判斷？
答案屬於固定類別、有序尺度，還是是／否？
問題是否足夠聚焦，輸入是否包含必要且可信的狀態？
哪些步驟必須由程式查證、計算或控制權限？
不同錯誤代價如何轉成門檻、人工覆核和回復方式？
我們用哪些本地資料和指標證明這個流程有效？

完成本課後，應能帶著一張有答案規格、信心分流、程式政策、人工核准和評估指標的決策卡，向團隊說明 Jev 適合放在哪個節點、哪些責任不能交給模型，以及如何逐步驗證導入價值。

10. 自編示範考題

以下題目示範概念如何轉成情境題。它們是本課自行編寫的練習，不是 iPAS 官方題目。

第 1 題：選擇適合的處理方式

某客服系統要把自然語言留言分派到帳務、技術或帳戶團隊。系統另需核對交易是否重複扣款，並決定退款是否核准。下列設計何者最適當？

A. 讓 Jev 直接判斷留言、查帳、計算退款額並核准退款。
B. 讓 Jev 判斷承辦分類，程式查交易與政策，退款依權限流程由授權人員核准。
C. 用生成式 LLM 寫出退款核准文字，將文字內容直接當作核准結果。
D. 把整段流程改成關鍵字規則，避免任何語意判斷。

答案：B。 Jev 適合處理受限答案空間內的語意分類；交易事實、精確計算和政策權限應由程式及正式流程負責。A 把模型判斷擴張成事實查核與授權，C 把生成文字當成權限狀態，D 則沒有處理語言變化造成的規則維護問題。

第 2 題：配對問題型別

某企業要完成三項判斷：①選擇承辦部門；②將急迫性評為一般、優先或緊急；③判斷留言是否提到先前已提出退款申請。依序應使用哪種型別？

A. Choice、Score、Noul
B. Score、Choice、Noul
C. Noul、Score、Choice
D. Choice、Noul、Score

答案：A。 承辦部門是無先後順序的類別，使用 Choice；急迫性是有順序的尺度，使用 Score；第三項是是／否命題，使用 Noul。選題型先看答案空間，再看業務名稱。

第 3 題：解讀 Noul 輸出

某題詢問「留言是否明確表示使用者已提出退款申請？」Jev 回傳 noul = 0.93。下列敘述何者正確？

A. 代表使用者有 93% 的實際退款核准機率。
B. 代表模型對「是」這個答案給出 0.93 的機率；實際分類表現仍要以企業資料評估。
C. 代表這筆判斷已經有 93% 的人工審查者同意。
D. 代表 Noul 的 confidence 欄位為 0.93。

答案：B。 Noul 回答的是單一是／否命題，數值代表模型對「是」的機率，不是退款資格、核准機率或人工同意度。Noul 不另回傳 Choice／Score 型態的 confidence 欄位；模型機率仍須對照本地驗證資料。

第 4 題：處理高 confidence 與高風險

模型以高 confidence 將一件案件判為「符合退款政策」。但退款會直接退回大量款項，且交易系統尚未確認是否重複扣款。系統下一步應如何設計？

A. 只要 confidence 超過 0.9，就直接執行退款。
B. 先由程式核對交易資料、金額和政策，再依風險與核准權限決定是否轉人工；模型輸出只作為一項判斷依據。
C. 只要模型是 type-safe，就可以跳過交易查詢。
D. 讓生成式 LLM 讀取模型答案，請它決定是否真的退款。

答案：B。 信心資訊可協助分流，但不能取代交易查證、政策檢查和授權。高風險副作用需要與風險相稱的門檻、程式驗證和人員核准；沒有交易證據時應先補資料或覆核。

第 5 題：理解 Score 數值

急迫性 Score 有三個有序等級：0 一般、1 優先、2 緊急。輸出 score = 1.65，且機率主要落在第 2 級。下列解釋何者較合理？

A. 模型量到案件的客觀急迫程度為 1.65 個單位。
B. 這表示第 2 級是唯一可能答案，應直接執行緊急處置。
C. 這是依各等級機率形成的位置分數，表示分布偏向較高等級；程式仍要按已驗證門檻和流程分流。
D. Score 分數就是模型答案正確率。

答案：C。 Score 可能介於等級之間，因為它反映等級機率的加權位置。它不是客觀量尺，也不等於正確率。實際行動要看完整機率、任務門檻、錯誤成本和必要的人工流程。

第 6 題：建立繁體中文評估

某團隊準備在台灣客服中心使用 Jev 分類中文留言。正式上線前，哪一項工作最能支持有根據的門檻設定？

A. 直接採用供應商展示的英文範例和門檻。
B. 以代表性的台灣繁體中文歷史案件建立保留測試資料，檢查各類 precision/recall、信心區段、人工覆核率和錯誤成本，並先以觀察模式驗證。
C. 只測最清楚、沒有錯別字的留言，以免資料影響結果。
D. 使用 jev-latest 後永久固定門檻，不記錄回應版本。

答案：B。 真正的服務資料會包含口語、縮寫、否定、缺漏和混合意圖，測試資料需要涵蓋這些情境。門檻依本地表現和錯誤代價設定，先觀察再逐步開放低風險自動化，並記錄模型版本與回退方案。

參考來源

TypeSafe AI, System One：產品定位、輸入輸出、問題型別與組合式流程。
TypeSafe AI, Models：可用模型、輸入範圍、語言支援與資料處理說明。規格會更新，導入時需重新查核。
TypeSafe AI, Choice、Score、Noul：答案型別與回傳欄位。
TypeSafe AI, Confidence：機率分布、信心分數和門檻設計。
TypeSafe AI, Jev 1.13 jaggedness：官方列出的已知失效型態。本文將其作為測試情境來源，不視為所有版本永久不變的特性。
TypeSafe AI, Introducing System One Models & Jev：官方產品公告與訓練方向說明；效能數字屬供應商公布的評估結果。
Kyle, KodeLab, Jev 是什麼？TypeSafe System One 決策模型：使用者指定的中文導讀，作為案例索引；產品定義與規格以 TypeSafe 官方文件核對。