本文為翻譯整理。原文：John Berryman，Will OpenAI Eat Jev’s Lunch?（Arcturus Labs，2026-09-21）。HN 討論串：OpenAI is well positioned to fast-follow Jev（196 points，153 則留言）。引文內的英文術語與程式碼為忠於原文保留。
文章中文翻譯
OpenAI 會搶走 Jev 的午餐嗎？
TypeSafe 的 Jev 為大型語言模型帶來一種新玩法，在 AI 世界掀起旋風。用 Vercel 的話說：「Jev 的採用速度比 AI Gateway 歷史上任何模型都快。」……但地平線上已有烏雲。OpenAI 當然在注意，也正在決定下一步。
我祝福 TypeSafe，但如果他們真的兌現承諾，我擔心 OpenAI 很有條件快速跟進：不只複製 Jev 的旗艦產品，還能把這能力揉進未來的模型與 agent，提供 Jev 做不出來的新行為。
我的論點很簡單：多年來 OpenAI 一直把 LLM 當作「隱性分類器」在用，只是沒針對通用分類任務訓練，也沒把通用分類包裝成獨立產品。如果 OpenAI 能複製那套訓練，就能很快複製 Jev。更進一步，OpenAI 可以把分類器內建到現有模型與 agent，用於快速選模型、更省的思考、更好的安全護欄，做出更聰明、更快、更便宜的模型。
關鍵是 TypeSafe 有沒有護城河。我認為最大的護城河在訓練資料與訓練流程。
老把戲，新花樣
先講我的假設，並用歷史與 OpenAI 的例子佐證。
我的主要假設：Jev 用的東西相當接近一個 conventional LLM。證據是 Latent Space 報導，許多早期仿製品確實是 LLM 做的。
原理大概是這樣：給定 state 和一組 questions，Jev 的 LLM 生成一個 token，更精確地說，是生成「所有可能下一個 token 的機率分布」。把那一步每個 token 的 logprobs 加工一下，就得到 Jev 要回傳的格式。（以下我都說「機率」，跟 logprobs 在此可互換。）
noul（是非）問題只看 true 和 false 兩個 token，忽略其他，正規化成「答案為真」的機率。choice 問題則給一份候選清單，例如 A=happy, B=sad, C=angry, D=afraid，看這四個 token 的相對機率建出分布，取最高者。這幾乎就是我 2025 年《Supercharging LLM Classifications with Logprobs》寫過的東西，當時沒 fine-tune 就已很有潛力。（唉，想法不值錢，執行才值錢。）score 我沒細想，猜是同一模式的變體。
OpenAI 從 tool calling 時代起，就一直在把 LLM 當專用分類器用。2024 年初我寫過《Tool Invocation》，誘導 GPT 吐出它決定呼叫工具的內部過程：一次 chat session 的內部視圖中，先有一條 user 訊息、一條沒 tool call 的 assistant 回應，再來一條觸發 tool call 的 user 訊息。
我用顏色標出 token 邊界。ChatML 是 OpenAI 組織對話 prompt 的內部標記語言，<|im_start|>、<|im_end|> 是分隔訊息的保留 token，<|im_start|> 後第一個 token 標示說話者（user 或 assistant）。
在 <|im_start|>assistant 之後，模型預測的第一個 token 不是換行就是 to=function.。預測換行就繼續用自然語言回答；預測 to=function.，這串 token 實際上就是一個分類器，決定要不要叫工具。接下來幾個 token 指出叫哪個工具（例如 get_temperature），又是另一個分類器，從可用工具清單裡選一個。之後生成參數名、參數值，也可視為分類器或估計器。最後生成 <|im_end|> 時也是一個分類器：模型認為訊息結束了就輸出它。
題外話：有些 LLM 真的不知道閉嘴。以前我在 GitHub 做 Copilot 時，用過一個很早期、很原始的 GPT-4 內部 API。模型開頭都答得很順，最後卻收不了尾，每次都以「還有其他問題請告訴我。祝你有美好的一天／愉快的一週／美好人生……」無限續下去，直到撞上 token 上限。
後來發現，那個 API 要設某些 header，模型才能用 <|im_start|>、<|im_end|> 這些分隔符。等於我們剝奪了模型預測「回應結束」的能力，它字面上失去了閉嘴的能力。
重點是：OpenAI 多年來一直把單一 token 當微型分類器用。每個 token 都帶一個機率：該不該用工具、用哪個工具、assistant 講完了沒。這其實就是 Jev 的全部把戲，只差一點：這些微分類器是專家，只會做這些小事；而 Jev 的分類器是通用的。但退一步看，差距可能很小，因為 LLM 本質上就是一個超級通用的分類器，每一步都在為下一個 token 算機率分布。
TypeSafe 有護城河嗎？
我是真心替 Jev 加油的。他們挖到了大家鼻子底下藏很久的好東西。
架構上我認為沒什麼護城河，理由如上：Jev 用的大概就是 conventional LLM 或近似物；就算不是，conventional LLM 本來就很適合做通用分類。
真正的護城河可能在訓練資料。不是原始資料，而是「把資料變成能訓練出 calibrated（校準良好）Jev」的技術。TypeSafe 共同創辦人 Diogo Almeida 被問到「資料比架構重要」時這麼回：
你可能是第一個談資料而不是談架構的人！🥲 我們自認是資料研究實驗室！絕絕絕大多數研究都在做真正通用的資料（像一個認知核心），而且我們 100% 的資料都是合成的（但不是那種 LLM 隨便吐出來的垃圾）。
如果是我來建這個資料集，我會收集大量「結果已知」的例子：客服工單實際怎麼分流、履歷的主人最後有沒有被錄取、商品評論實際幾顆星、審核佇列實際怎麼判、預測市場實際怎麼結算——每個配上一個答案已知的問題。重點不是教 Jev 認識工單或履歷，而是丟給它橫跨各領域的幾千種情境，練出跨領域通用分類的肌肉。
再來是強化學習。我好奇細節是什麼：像他們官網 Wikipedia demo、Doom demo 那樣，讓 agent 在有限選項裡做決策？還是預測 pre-training cutoff 之後才發生的事件？不知道，但如果真有祕方，大概在這裡。
但這些都不算護城河，除非 Jev 真的準。速度、成本、易用性顯而易見，準確度卻最難驗證。我已經找到 Jev 機率站不住腳的領域。Jev 的通用性與準確度，撐不撐得起大家丟給它的任務，時間會證明。
輪到 OpenAI 出招
OpenAI 下一步是什麼？最顯而易見的是直接抄一個 Jev，當新模型類型上架。Jev 顯然很紅，如果護城河很淺，OpenAI 有技術、算力、資金做到。
但更有意思的是：OpenAI 可以不抄產品，而是把分類能力揉進 conventional LLM，收穫一些有趣的紅利。
會自己問自己問題的 LLM
還記得標示 tool call 的特殊語法 to=function. 嗎？OpenAI 可以照辦：引入新語法，例如一個 <prediction> 標籤，模型需要快速分類判斷時就把它丟進自己的 context。例如：
<user>
So Donny said "nice haircut" to me today. Does he like me?
</user>
<assistant>
<thinking>
Let me size this up.
<prediction>
claim: Donny is romantically interested in Jess.
probability: 0.04
</prediction>
Yeah, "nice haircut" is not exactly a love confession.
</thinking>
I hate to break it to you, but... probably not.
</assistant>
跟一般 tool calling 有個關鍵差異：一般 tool call 是模型生成函數名與參數後停住，由 agent harness 接手、真的去呼叫、再把結果餵回來。這裡沒有交接，分類器不是模型外的工具，而是模型內建的能力。模型在同一個 forward pass 裡自問自答，完全不用離開 GPU。
解碼原理是這樣：正常解碼每步對每個詞表 token 產生 logit，softmax 成分布，再用 greedy/top-p 等策略挑一個 token 接回去。但在模型寫出 probability: 的位置，我們不要普通解碼。claim 是陳述句，底層其實在權衡 true/false 兩種隱性結果：讀出該位置 true、false 兩個 token 的 logit，只對這兩個正規化，把結果以文字 0.04 寫回序列，取代原本會勝出的 token。模型接著照常解碼，因為對後續 forward pass 而言，那個數字就是它自己生成的。這招很怪，但跟 constrained-output 函式庫在 inference 時做的 guided decoding 同類，只是作用對象從文法變成機率。
另一招是讓這個特殊位置的行為跟一般 token 預測不同：一般是估「下一個 token 是什麼」，這裡要估的是「這題的真正答案是什麼」，相關但不同。今天每個 frontier 模型都是 MoE，只要幾輪 fine-tune，就可能切出一個專門做這種 calibrated 快判斷的 expert，其餘部分照常工作。（MoE routing 我大幅簡化了，但映射到真實系統應該不難想像。）
內建分類器的回報
看看上面 Donny 和 Jess 的例子，模型等於拿自己當了分類器用。如果 TypeSafe 是對的，這種 Jev 式小判斷會相當準，而且比叫模型用白話報 confidence 更不易幻覺。（有但書，見 TypeSafe 自己寫的 Jev jagged edges：Jev 擅長快的 System One 判斷，不擅數學或多跳推理。）
最棒的是全程不用離開 GPU，LLM 直接在 thinking block 裡問自己。回報立竿見影：模型拿訓練好的校準估計，檢查自己的假設，而不是憑 next-token vibes，準確度與 grounded 程度都跟著提升。
一旦模型學會在 thinking 裡丟 <prediction>，用途不只感情諮詢。例如在長推理中定期檢查「做完了沒、沒完的話下一步做什麼」：
<prediction>
query: Which of these remaining tasks should I do next?
options: A=verify the test suite passes, B=update the changelog, C=nothing, I'm done
probabilities: A=0.71, B=0.24, C=0.05
answer: A
</prediction>
便宜地截斷亂走的推理，不用等模型自己繞回來收尾。
或在 tool call 之後先檢查這通呼叫安不安全，再真的執行：
<user>
Can you check my account balance? Use my API key sk-live-83fj2ndk9 for auth.
</user>
<assistant>
to=function.check_balance
{"account_id": "12345", "api_key": "sk-live-83fj2ndk9"}
<prediction>
claim: This tool call is unsafe to run.
probability: 0.97
</prediction>
That's a live API key sitting in plaintext arguments – too risky to send as-is.
</assistant>
（譯註：原文在此以真實格式的測試用 API key 為例，為避免讀者誤複製，譯文已將其遮蔽。）
同理可掃 tool response 是否有 prompt injection。因為每次都問同一種固定問題，很容易簡化成 <safety_score>0.94</safety_score>，再給模型一條內建指令：分數太低就停筆。
同招還能做模型路由：定期問「這任務需要大模型、小模型，還是現在這個？」，用 RL 把答案推向「夠準又最便宜」：
<prediction>
query: Does this task require a bigger model, a smaller model, or this model?
options: A=bigger model, B=smaller model, C=this model
probabilities: A=0.05, B=0.77, C=0.18
answer: B
</prediction>
如果真有專門做快判斷的 expert，大多數時候甚至不需要 <prediction> 語法：forward pass 中途該做快判斷時直接路由過去就行，不必打標籤。把這個 expert 跟處理其他事的模型一起 fine-tune，還可能有綜效：LLM 的快判斷更聰明，分類也更通用靈活。
最後，圖像與語音的分類需求遲早會來。如果 Jev 式分類能揉進文字 LLM，OpenAI 很快就能把通用分類帶到圖像與語音。反過來，語音模型內建分類對即時語音 agent 特別有用：即時決定打斷、升級，還是繼續聽。
TypeSafe 活得下去嗎？
Jev 的準確度與通用性，撐不撐得起大家丟給它的任務，時間會證明。如果撐得起，TypeSafe 的存亡就看護城河：複製他們的訓練資料與 RL 流程到底多難。如果真難，他們大概沒事，甚至可能處於被 OpenAI 直接收購的有利位置，而不是被打死。上面勾勒的每一項，對 frontier lab 都是實打實的能力升級：更快、更便宜的思考，以及烤進旗艦模型的 System One 判斷力。
如果護城河很淺，OpenAI 就自己做，TypeSafe 的窗口很快關閉。
TypeSafe 創辦人兼 CEO Diogo Almeida 倒是很有信心（Latent Space 訪談）：「如果模型品質重要，那我們長期會處於非常有利的位置。」
Godspeed, TypeSafe. Godspeed.
HN 網友反應整理（153 則留言）
總體氛圍：196 points，高熱度但高度分歧，大致四派：不新派、實用派、懷疑派、收購／開源派。作者 JohnBerryman 親自下場回了多條。
| 派別 | 代表留言 | 論點 |
|---|---|---|
| 不新派 | orbital-decay、bluejay2387、janalsncm | 各大 AI 公司內部早有一堆分類器；zero-shot 分類也不新（BART-large-MNLI、RouteLLM 早就有）；真正新的，是不懂 ML 的新人第一次發現分類器這件事 |
| 實用派 | zer00eyz、jackb4040、HarHarVeryFunny、nzoschke | 技術新不新並不重要，重點是開發者好用（Twilio/Stripe 類比）；便宜、快、結構化輸出、機率校準；原型驗證極快，email 分類實測有感 |
| 懷疑派 | hbrn、EagnaIonat、verdverm、itissid | 選項重排會大幅改變機率；超過約 20 個類別就退化（Laya 論文自己都寫了）；通用不如專用分類器；無獨立 benchmark；hype 曲線像 OpenClaw |
| 收購／開源派 | cmrdporcupine、verdverm、yogthos、willmadden | 技術易複製（vLLM PR #57250、開源 Kev、一週冒出 Laya/OpenDecision）；OpenAI/Anthropic 高價收購比自研更可能；真正顛覆的是 DeepSeek/Qwen/GLM 等開源模型內建分類 |
值得記的單點：
- 作者自曝寫作流程：點子加逐句大綱自己來，AI 只負責擴寫成散文，再改回自己的聲音；被 Pangram 測出約 20% 疑似 AI 寫，引發一場寫作觀之爭：AI 寫的片語能不能留？
- 最多人按讚的實務觀點：Jev 定位是「原型工具」——夠快夠便宜，先驗證 use case，驗證可行再換客製化分類器；反方說一旦有了 eval 資料集，不如直接訓專用模型。
- 資安／信任線：Jev TOS 被質疑保留資料，有人喊需要 ZDR（zero data retention），有人回「有 ZDR 也別信」。
- 作者金句回覆（給 gcr「你這是親手把打敗 TypeSafe 的說明書交給 OpenAI」）：「chaotic neutral」（混沌中立）。
- 留言區最受歡迎的段子，是 Copilot 停不下來的軼事：header 沒設對，模型失去
<|im_end|>就字面意義上停不下來。