System One 模型是什麼？從 Jev 看 AI Engineer 怎麼重新分配 LLM 的工作
2026 年 9 月，TypeSafe 發布了 Jev，並把它歸類成一種新的模型：System One model。它不聊天、不寫程式，只做一件事：讀進一段狀態，回傳程式可以直接用的判斷。
這對 AI Engineer 是一個新選項。workflow 裡很多 LLM 呼叫只是在做判斷，有了 System One 模型，這些工作可以重新分配。這篇從 Jev 出發，談哪些工作可以移出去、移出去要付出什麼、哪些還是該留給 frontier model 或傳統模型，最後是我對 AI Engineer 工作方式的反思。
讀完這篇，你會知道：
- System One 模型是什麼，為什麼 Jev 對外是一個 model，裡面卻是一整個 stack
- workflow 裡哪些 LLM 的工作可以移給 System One，代價是什麼
- 哪些工作還是該留給 frontier model 或傳統分類器
- 有了 System One，AI Engineer 該怎麼重新分配任務
LLM 在 workflow 裡被拿來做什麼？
很多 workflow 裡呼叫 LLM 的步驟，要的只是一個判斷：這封客訴該分給哪個團隊、這段 agent 的輸出有沒有越權。答案是一個選項、一個分數，或是一個是與否。
LLM 是為了產生給人讀的文字設計的，拿它做判斷要多繞一圈。TypeSafe 的文件這樣描述這個落差：
「When you need a model to make a judgment that your code will consume, that creates a mismatch: you are coercing a text-generation system into outputting structured decisions, then parsing the results back into something your code can depend on.」（TypeSafe docs，Introduction）
逼模型吐出 JSON，再 parse 回程式裡的型別。逐字生成很慢，輸出 token 比輸入貴，形狀不對還要重試。這些成本花在一個只需要回答「A、B 還是 C」的步驟上，並不划算。
System One 模型是什麼？
System One 模型是一種專門做判斷的模型：讀進一段狀態，對一組事先定義好的問題，一次回傳型別化的答案和機率。TypeSafe 對 Jev 的描述是：
「Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.」（TypeSafe，Introducing System One Models and Jev）
名字來自 Kahneman《快思慢想》裡的系統一，也就是快速、直覺的判斷。Jev 提供三種問法，TypeSafe 的 CEO 在 Hacker News 上把它們對應到程式裡的控制結構：
| 問法 | 回傳 | 對應的程式結構 |
|---|---|---|
| Choice | 從選項裡選一個，附上每個選項的機率 | match |
| Score | 依評分標準打分，附上每一級的機率 | 排序 |
| Noul | 一個 0 到 1 的機率，代表「是」的可能性 | if |
Jev 讀一次狀態，所有問題並行、各自獨立地計算，所有機率一次輸出，不逐字生成。因此多問幾題，回應時間也幾乎不變。輸出的形狀事先定義好，模型不會回傳選項以外的值，但官方也提醒：「Jev guarantees the shape of its answers, not that every decision is correct.」
Jev 是閉源的，怎麼做到一次並行輸出並沒有公開。可以拿來觀察的是 Laya：Jev 發布三天後出現的開源專案，用同一套名詞和 API 格式，權重和程式碼都公開。這篇把 Laya 當成觀察和推測的參考，兩者實際的做法很可能不同。Laya 用一個現成的 encoder 對每個選項打分，一次 pass 就得到所有機率，至少說明這種使用方式不需要逐字生成也做得出來。
TypeSafe 為什麼把 Jev 包成一個 model 來賣？
TypeSafe 交付的是一整個 stack，對外只露出一個 model 的介面。發布文描述自己做了什麼時，列的是三樣東西：
「We built a new stack entirely focused on automation: with a new model architecture, parallel sampler for maximum efficiency, and training method we call Reinforcement Learning for Calibrated Decisions (RLCD).」（TypeSafe，Introducing System One Models and Jev）
新的模型架構、並行 sampler、RLCD 訓練方法，三樣少一樣，「一次並行輸出、附帶校準過的機率」就做不出來。其他官方資料也看得到同樣的設計：
- 介面強制並行。 CEO 說「strings (and all sequential data structures) are not allowed at all」，這也是 output token 能免費的原因。
- 選項多時不只一步。 Choice 最多 255 個選項，選項多時用「a 2 stage-system」：先各自打分，再明確選一個。
- 所有客戶同一組權重。 「the same weights serve every account」，不提供微調，架構也不公開。
Laya 可以拿來推測這個 stack 要處理哪些事。它沒微調過的模型，表現比全部猜最多數那一類還差；要堪用，得在模型外補上校準、選項篩選、輸出約束和 serving。這四件事，剛好都對得上 Jev 官方提過的設計。光有模型權重，離能放進 workflow 的產品還很遠。
使用者看到的，是一個 API、一個型號 jev-1.13.0、一個按 input token 計價的價格。我的判讀是：TypeSafe 刻意把架構、sampler、訓練方法和介面約束收在同一個名字後面，對外賣的是一個 model，價值在整個 stack 上。只拿到其中一塊，複製不出 Jev。
workflow 裡哪些 LLM 的工作，可以移給 System One？
可以移出去的，是 workflow 裡的判斷節點，也就是原本寫成 if-else、但規則太脆弱寫不好的地方。TypeSafe 列出的用途有四類：
| 用途 | 例子 |
|---|---|
| 智慧分支（smart if-statements） | 分類、路由、打分、抽取欄位 |
| 檢查 LLM 的輸出 | 評分、驗證、guardrail、偵測 jailbreak |
| 大量資料的 map-reduce | 對上萬筆紀錄逐筆判斷 |
| 即時應用 | 延遲預算只有幾百毫秒的場景 |
官方的標準是：「the kind of judgment a highly knowledgeable person could make in a few seconds given the right context.」懂行的人看幾秒就能下的判斷，就適合交給它。
需要長推理、要產生內容的步驟，留給 frontier model。官方也畫了這條線：數學和規劃類的任務「may be better suited to large reasoning models」，Jev 也「is not a drop-in replacement for the LLM behind Claude Code, Cursor」。它換的是 workflow 裡那些夾在中間、只負責做判斷的呼叫。
移出去，要付出什麼？
代價是一些準確率，換到的是延遲和成本的數量級差距。TypeSafe 在自家四個 workflow eval 上公布的數字：
| 模型 | 準確率 | 每案成本 | 每案時間 |
|---|---|---|---|
| Jev | 67.8% | $0.0004 | 0.4 秒 |
| Claude Opus 5 | 73.1% | $0.1761 | 37.8 秒 |
少了約 5 個百分點，快了約 90 倍，便宜約 440 倍。這組數字要打折看：eval 是 TypeSafe 自己設計的，參考答案取 GPT-6 Astra 和 Claude Fable 5.1 的平均，官方也承認這會「biases answers towards OpenAI and Anthropic’s models」。
客戶案例比較有說服力。Jack & Jill 在候選人篩選把 Gemini 3.1 Flash Lite 換成 Jev，成本降了 88%，品質差異在統計上不顯著。
所以要不要移，問的是：這個節點多錯幾個百分點，代價是什麼？每天跑幾十萬次的分類步驟通常划算；錯了就會寄出錯誤通知的步驟，就要再想想。
沒把握的判斷，怎麼交回 frontier model？
切換的訊號是 confidence。Jev 的每個答案都附帶機率，confidence 是從機率分布算出來的：機率越集中在一個選項上，confidence 越高。
workflow 因此可以分層：confidence 高的直接往下走，低的交給 frontier model 或人。官方的建議是「Escalate uncertain cases to a person or a more expensive reasoning model」，而且做錯代價越高的動作，門檻要設得越高。這個升級機制 Jev 沒有內建，要由呼叫端自己設計。
機率可不可信也要自己驗。TypeSafe 說 Jev 的機率是校準過的，但沒有公開量測結果；Laya 出廠的機率則明顯過度自信，要自己重新校準。門檻設在哪裡，要用自己的資料去校。
跟傳統分類器比，工作該怎麼分？
文字判斷可以交給 System One，數值和表格還是交給傳統模型。System One 換掉的是「每個任務訓練一個模型」這套流程，換不掉的是評估和校準。Hacker News 上有人把 Jev 形容成 zero-shot 分類器，TypeSafe 的 CEO 接受這個說法：「1. yes a general model 2. no training at all 3. but it is focused on “System 1” tasks」。
傳統做法不管是 logistic regression 還是 fine-tune BERT，都要先標註資料、訓練一個標籤固定的模型，標籤或資料分布一變就重新訓練。Jev 把任務定義搬進 request 裡。社群有人這樣說：「I don’t want to maintain my corpus and retrain as my product’s data distribution shifts.」
Laya 反而站在傳統這一邊，README 自己寫「Laya is a fast base to specialise, not a zero-shot decision engine.」要先 fine-tune 再用。
| 傳統分類器 | Jev | |
|---|---|---|
| 任務怎麼定義 | 訓練時固定在模型裡 | 呼叫時寫在 request 裡 |
| 標註資料拿來做什麼 | 訓練 | 評估、設門檻 |
| 標籤或分布改變 | 重新訓練 | 改 request，重新評估 |
| 擅長的輸入 | 表格和數值是強項 | 只吃文字 |
數值和表格資料，還是交給傳統模型
場景有硬限制。Jev 只接受文字，官方也承認「It struggles with tasks that require numeric precision.」文件的分工原則是：
「Extraction is a judgment, so give it to the model. Arithmetic is not, so keep it in code.」（TypeSafe docs，Model jaggedness）
詐欺偵測、流失預測、需求預測這類以數值特徵為主的任務，仍然是 gradient boosting 這類模型的範圍。官方給的方向是兩者搭配：用 Jev 把文字轉成一組帶機率的特徵，再和結構化欄位一起交給傳統模型訓練。文件裡用葡萄酒評論預測分數的範例，把 Jev 的判斷當成 CatBoost 的特徵後，誤差（RMSE）從只用字數統計的 2.47 降到 1.77。
ML 的重心會從訓練移到評估和校準
我的判讀是，ML 這門學科不會退場，重心會移動。標註資料沒有消失，用途從訓練變成評估和設門檻。官方文件的建議也落在這裡：「Choose production thresholds using labeled examples and the cost of incorrect actions and human review.」
校準本身就是 ML 的老問題：機率 0.8 的判斷，應該大約八成是對的。要驗證這件事，需要的是一份有標註的資料和一張 confidence 對 accuracy 的圖。TypeSafe 沒有這樣說，這是我的推論：要把 Jev 用好，訓練模型的技能用得少了，評估和校準的技能用得更多。
AI Engineer 該怎麼重新分配 LLM 的工作？
我的答案是：先看懂每一步在做什麼，再替每一類任務挑模型。判斷的成本降了兩個數量級，原本放不進流程裡的判斷現在放得進去，分配的選項也變多了。這一節是我看完 Jev 之後的反思，有不少推論。
TypeSafe 替 Jev 取名，是取自經濟學家 Jevons：
「Every order of magnitude drop in the cost of intelligence unlocks orders of magnitude more use cases.」（TypeSafe，Introducing System One Models and Jev）
我覺得這句話落到 AI Engineer 身上，會有三個變化。
原本受延遲限制的判斷，放得進即時路徑。 很多任務本質上就是判斷，交給 frontier model 時卻多了一層生成和推理。一次判斷要幾十秒，只能放在背景跑；降到幾百毫秒，就能放進使用者等待的路徑上。前提是懂行的人幾秒就能下的判斷，要算數、繞好幾層邏輯的不算。
架構可以從一次大呼叫，拆成很多個小判斷。 判斷貴的時候，大家把所有事塞進一次 LLM 呼叫；判斷便宜了，就可以在每一步都放一個：
| 系統 | 可以交給 System One 的判斷 | 仍然需要 LLM 的部分 |
|---|---|---|
| Agent memory | 這段資訊要不要記、該取哪幾條記憶 | 抽取記憶、寫摘要 |
| Agentic RAG | 檢索結果重新排序、要不要再查一次 | 產生最後的回答 |
官方文件的重新排序範例裡，top-1 命中率從 5% 提升到 18%。整個系統換不掉，但裡面的判斷節點一變便宜，架構就可以重新設計。
「分給合適的模型」本身變成一層有價值的判斷。 官方已經示範了基本版：讓 Jev 決定一個請求該交給寫死的程式、專門的 LLM，還是人。再往外推是我的想像：未來可能是多個 agent，加上很強的路由分類器，再加上各產業自己的分類器和 SLM。文字判斷、數值預測、長推理各有最適合的模型，路由的價值就在把任務送到做得最好的那一個。
對 AI Engineer 來說，這是一種新的工作方式：把流程拆開，看懂每一步在做什麼，替每一類任務挑模型。做對了，使用者等得更短，單位成本降一個數量級，一些原本算不過來的服務，可能就算得過來。
回頭看，這整篇反覆出現的是同一組技能：用自己的資料評估、設門檻、看 confidence 準不準、決定錯了怎麼兜底。只要系統裡有會給出機率、會出錯的元件，不管是 System One、frontier model 還是 agent，都需要有人知道怎麼量它、怎麼信它。模型越容易取得，這組技能越決定一個人能把系統做到多好。我認為這是現在的 AI Engineer，甚至所有 Software Engineer，都需要補上的能力，而且只會越來越重要。