每天有一千封信、一堆客服單，或幾十個可用工具等著分類，真正耗時間的常常不是寫出漂亮答案，而是先決定「這件事交給誰」「接下來做什麼」，Jev 就是為這類判斷設計的模型，把狀態與問題送進去，拿回程式可以直接使用的選項、分數與機率。
Jev 最適合放在 AI 工作流的分類、路由與檢查關卡，先由它整理判斷，再由程式控制流程，需要寫信、寫程式或解釋事情時，才交給生成模型，這樣的分工，比把所有步驟都寫成一大段提示詞更容易調整與驗證。
內容目錄
Jev 是什麼？先理解 System One 的用途
TypeSafe AI 在 2026 年 9 月 15 日的發布文章中，把 Jev 稱為 System One Model。它接收一份狀態與一組有明確型別的問題，平行評估後回傳結構化結果，不提供一般聊天模型那種自由文字回答。
System One 是借用快速判斷的概念來命名，不能直接拿來斷言模型擁有人類直覺。
可以把工作拆成三層：程式處理查資料、計算與執行動作，Jev 處理模糊語意的判斷，生成模型處理開放式產出。
例如帳單是否超過期限，已有日期就直接計算，客人的文字是在催款、抱怨，還是要求退款，才需要模型理解，這也呼應 CrewAI 工作流裡的角色與流程分工，框架負責安排工作，模型只是其中一個元件。
Choice、Score、Noul：三種問題怎麼選
| 題型 | 要解決的問題 | 怎麼理解答案 |
|---|---|---|
| Choice | 客服單要交給帳務、技術還是業務 | 從預先列出的選項選一個，並附各選項機率與 confidence |
| Score | 故障有多嚴重、客人的情緒有多強烈 | 依具體描述的有序等級評分，可落在兩級之間 |
| Noul | 客人有沒有明確要求退款 | 回傳「是」的機率，介於 0 與 1 |
Choice 適合互斥分類，選項要寫出差異，也要替不符合任何分類的輸入保留「其他」或「資訊不足」。若一封信能同時是發票與合作邀約，就拆成兩個是非問題，不要強迫它只能選一個身分。
Score 的重點是描述等級。例如從「外觀問題，不影響操作」「功能受影響，但有替代方式」到「主要流程無法使用」。目前官方文件寫明接受 2 至 10 個等級，從 0 開始編號。回傳 1.4 代表分數落在等級 1 與 2 之間，不能解讀成「有 140% 的把握」，也不代表 40% 的客人受影響。
Noul 則用來判斷一個命題是否成立。接近 1 是偏向肯定，接近 0 是偏向否定，接近 0.5 是肯定與否定的機率相近。若想問「情緒有多憤怒」，應該使用 Score，不能把 Noul 的 0.5 當成「中等憤怒」。
五個 Jev 實作場景，逐一拆開看
範例一：辨認退款是否已完成
給模型一段客服紀錄，問題只問「退款是否已執行」，紀錄寫著「已全額退款，案件結案」，與「我們會在三個工作天內審核退款申請」，是兩種完全不同的狀態，前者描述完成，後者描述等待處理。
這個場景適合用 Noul 讀出語意，但金流狀態仍應以交易系統為準，如果後台已經有明確的退款完成欄位，就直接查欄位。模型讀到一封寫著「已退款」的信，不代表它驗證了銀行入帳，更不代表它取得再次退款的權限。
範例二：客服單一次判斷五件事
假設客人寫「我被重複扣款，今天一定要處理」，後台也提供方案與帳戶年資，一次請求可以同時判斷分類、嚴重程度、是否要求退款、是否提供重現步驟，以及情緒強度，分類用 Choice，嚴重程度與情緒用 Score，另外兩題用 Noul。
接著由程式決定分派規則，例如帳務問題交給帳務組，明確的付款異常加上強烈急迫性才提高優先順序，「被重複扣款」也不必然等於「明確要求退款」，問題文字要區分推測需求與直接表達，遇到前後矛盾的描述，就標記待確認。
官方的 多題評估說明指出，同一個請求裡的問題各自依據原始狀態作答，某一題的答案不會自動變成下一題的輸入，只有需要先取得答案、再查新資料或建立新選項時，才拆成第二次請求。
範例三：便宜模型與強模型之間的路由
同樣是使用 AI，「修正幾個錯字」與「設計含過期機制、測試與並行控制的快取系統」，需要的能力不同。可以讓 Jev 依任務條件選擇處理路徑，再交給對應模型完成工作。
路由選項要描述適用條件，而不是只有模型名稱。簡單改寫走快速路徑，涉及跨檔案修改、複雜除錯或需要更多上下文的工作走較強路徑，無法確定時保留升級處理。是否真的省錢，要把路由費、生成費、重試與分錯之後的修正成本一起計算。
選模型與接外部工具是不同層次。像 AISA 這類 Agent 能力與 API 整合層處理的是資源入口，Jev 處理的是在既定選項裡做判斷，兩者可以互相配合。
範例四：內容審核先拆問題，再決定處置
輸入留言文字、必要的討論上下文與檢舉資訊，分別判斷是否為垃圾訊息、是否含人身攻擊，以及是否需要人工檢查。不要把所有不喜歡的內容統稱為「有害」，否則模型再快，也只是在加速模糊的標準。
較穩妥的導入方式，是先讓系統提出允許、待審或限制顯示的建議，由既有政策決定動作。低把握的案例進待審區，並保存原文與判斷依據，方便回頭找出錯誤分類。先跑一段時間的影子模式，再決定哪些判斷可以自動執行。
範例五：替生成模型的回覆做最後檢查
生成模型寫好客服回覆後，把客人問題、回覆草稿與相關規範放在一起，再問幾個獨立問題：是否回答到問題、語氣是否適當、是否洩漏不該對外的內部規則。只要任一重要項目不合格，就退回重寫或交給人員確認。
這能增加一道檢查，但不能保證攔下所有幻覺。涉及訂單金額、退款狀態、方案權益等事實，還是要對照可靠資料。輸出能被程式讀懂，也不等於內容可信，這與 用結構化規格控制 AI 圖表產出的道理相通，格式驗證與內容驗證都要做。
把五個範例串成一條可用的客服工作流
客服單進站 → 取得必要的帳戶與交易資料 → Jev 分類與評估 → 程式分派 → 生成模型撰寫草稿 → Jev 與確定性規則檢查 → 通過後依既有權限送出，否則人工處理。
這條流程的價值在於責任清楚。模型不需要自己猜去哪裡查帳，也不負責決定誰有退款權限。每次判斷都能記錄輸入、題目版本、模型版本與結果，錯了之後才知道應該補資料、改分類標準，還是更換模型。
郵件、遊戲與瀏覽器：延伸案例應該看什麼
大量郵件分類很適合檢查這種分工。先區分發票、合作邀約、需要親自回覆與垃圾信件，再讓程式標籤或排入待辦。可以從 大量郵件分類示範與 Ryan Vogel 的信箱整理案例觀察流程，費用與耗時則要依自己的信件長度、併發量與錯誤率重測。
遊戲展示最有意思的地方，是把世界狀態轉成可判斷的選項。例如 官方 DOOM 示範使用結構化遊戲狀態選動作，不能據此推論模型直接看懂每個畫面。像 TypeSafe Mario同樣從模擬器狀態選擇操作。虛擬小鎮 NPC、棋局或 駕駛模擬示範也應視為特定環境的展示，不能延伸成一般推理、棋力或真實道路安全的證明。
browser-use/jev-ultrafast把網頁整理成可操作元素，讓 Jev 選動作與目標，需要輸入文字時再搭配生成模型。它展示的是整套瀏覽器流程的改善，模型延遲、頁面載入與瀏覽器操作次數都會影響最後耗時。
Unclutter則讓 Jev 分類頁面上不必要的區塊，再保存可重用的隱藏規則。專案提供手動分析與造訪頁面時分析兩種模式，預設是手動。擴充功能程式碼公開，不代表推論永遠免費，仍需要對應服務的 API Key 與使用額度。
如果 Agent 手上有大量技能，還可以參考 官方 Skill suggestion 範例，先篩選候選技能，再讀取完整說明重新判斷。這是特定模型與測試集下的流程實驗，不能把其改善幅度直接當成所有 Agent 的保證。
Jev 真的快 200 倍、便宜 400 倍嗎？
這類數字要連同比較條件一起讀。官方發布文章展示特定工作流中接近兩百倍的加速與數百倍的成本差距，並不代表任何輸入、任何地區或任何替代模型都會得到同樣結果。一般聊天 API 逐步生成答案，與專門評估固定選項的 API，本來就在做不同形狀的工作。
官方評測網站採用固定工作流比較不同模型，參考答案來自指定大型模型的評估。這衡量的是與參考答案的一致程度，不能直接當成人工確認的真實正確率。比較時還要看重試、提示格式、輸入長度與是否要求其他模型回傳機率，避免只挑最大倍率下結論。
截至 2026 年 9 月 22 日，TypeSafe 發布頁列出的價格為每百萬輸入 token 0.042 美元，輸出不收費。這裡的輸出是決策結果，不能理解成可以免費生成無限文章。以下只按公布的輸入單價試算，不含前處理、其他模型、重試與周邊服務。
| 累計輸入量 | Jev 輸入費用試算（美元） |
|---|---|
| 10 萬 token | 0.0042 |
| 100 萬 token | 0.0420 |
| 1,000 萬 token | 0.4200 |
另外，Vercel 的接入公告寫有截至 2026 年 9 月 25 日的 AI Gateway 免費活動。它是有期限的平台活動，與模型的常態定價分開看，實際使用前仍要確認帳戶當下適用條件。
怎麼開始用？先選官方介面，再做小規模驗證
想直接試題目，可以從 官方 Quick start 與 Playground開始。API 使用 state、model 與 questions 三個主要欄位。
直連 TypeSafe 的模型名稱是 jev-latest，端點為 https://api.typesafe.ai/v1/systemone。帳戶是否已取得權限，以控制台顯示為準。
若透過 Vercel AI Gateway，官方公告的方式是 AI SDK 7.0.105 以上搭配 experimental_evaluate，模型識別字為 typesafe-ai/jev。
兩條接入路徑的欄位與回傳格式不要混用，AI SDK 範例中的 boolean 與 TypeSafe 原生 Noul 也不是可以直接替換名稱就完成的同一份請求。
想交給 Coding Agent 實作，可先讀 TypeSafe 官方技能專案，再讓它依工作流挑出適合做語意判斷的步驟。這套技能與部分示範程式公開，不代表 Jev 模型權重已開放下載。本次整理依據公開文件與示範，未另行呼叫付費 API 做效能實測。
上線前，比速度更重要的三件事
- 準備真實且有標註的測試資料。除了一般案例，也放入模糊、互相矛盾、繁體中文、混合語言與不屬於任何分類的輸入。先建立既有規則或既有模型的基準，才知道更換後有沒有改善。
- 把 confidence 當成分流訊號。依 官方 confidence 說明，它反映 Choice 與 Score 機率分布的集中程度。高 confidence 仍可能判斷錯誤，門檻要用自己的驗證資料設定，不能一律套用同一個數字。
- 量完整工作流。除了平均耗時，也記錄較慢案例、錯誤分流、人工接手比例與重試成本。分類容易自動化，不代表寄信、刪除資料或退款也應一起放行。
我會先從信件標籤或客服單分派做起，保留人工對照。只有當錯誤率、延遲與維護成本都符合需求，才逐步接到更重要的流程。Jev 值得研究的地方，是讓 AI 判斷變成可以組合與檢查的小步驟，而不是用一個誇張倍率取代驗證。
常見問題
Jev 的型別安全代表不會判斷錯嗎？
不代表。輸出符合指定型別，與語意判斷正確是兩件事。仍應提供資訊不足的處理方式，並以真實資料驗證錯誤率。
Jev 的 Score 與 Noul 有什麼不同？
Score 衡量有序等級上的程度，Noul 衡量是非命題成立的機率。Noul 接近 0.5 表示肯定與否定的機率相近，不是程度中等。
多個問題一定要分成多次 API 呼叫嗎？
不需要。能依據同一份狀態獨立判斷的問題，可以放在同一個請求。若後一步必須先取得前一步答案，再查新資料或建立選項，才分開呼叫。
Jev 現在完全免費，而且可以本機部署嗎？
官方發布頁提供按輸入 token 計費的方案，Vercel 的免費活動有期限
近期留言