Jev Capability Atlas

September 21, 2026 · View on GitHub

🇹🇼 中文（本頁）｜🇬🇧 English

Jev Capability Atlas

獨立、非官方、非 TypeSafe 贊助的社群專案。 這個 repo 存在的目的，是幫你、我、還有任何想用 Jev（TypeSafe 的 System One 模型）的人，正確識別手上的任務適不適合交給它——用真實 API 呼叫的收據，畫出它「校準決策」這個宣稱在哪裡站得住、在哪裡站不住的邊界地圖。給人看怎麼用，給 agent 帶進專案看哪裡能試著換上去，也給任何做過真實驗的人一個把結果貢獻進來的地方。

不是排行榜（市面上已經有 jev-benchmarks、thaiexam-jev-charts 在做這件事，做得很紮實，我們引用它們、不重做）。這裡要回答的是更根本的問題：什麼情況下它強，什麼情況下它弱，為什麼。

30 秒版

先講它是什麼：Jev 適用的情境很「橫切」（cross-cutting）——不是侷限在少數幾個產業，是任何系統裡「窄判斷」這一層，不管屬於瀏覽器自動化、程式碼審查、內容審核、金融交易、新聞分類、電玩，都用得上，見 capability-map.md 收錄的十幾種完全不相干的產業案例。💭 它本身內建的世界知識有限，但只要資訊在你餵給它的 state 裡給得夠齊，閱讀理解/擷取能力好到誇張——這是我們累積幾十個真實案例（🔬 自己測的、📚 第三方跑分）後歸納出的核心特徵，細節見下面「核心發現：一條軸」。

機制上：它很快、很便宜，只能做「選一個選項/打個分/回答是非」這種窄判斷，不會寫文字解釋自己在想什麼。因為答案空間是你自己先定義好的，它結構上不可能吐出選項清單以外的東西——這跟自由生成文字的模型偶爾格式跑掉、甚至生出一個你沒列的分類，是不同等級的保證，不是機率低，是型別上不可能（但這只保證答案落在清單裡，不保證選到的那個是對的，細節見下面「不是瞎猜」那節）。

它在「答案就寫在你餵給它的文字裡」的任務上很準（分類、判斷兩段文字關不關聯、抓語意層的矛盾），也適合把「候選項雖多但內容都給齊」的操作一次批次問完——例如瀏覽器自動化裡「畫面上這些元素該點哪個」，見下面案例。反過來，它的判斷完全建立在你給的文字上——文字有錯時，它不會提醒你題目怪怪的，照樣很有把握地選。🔬 我們自己踩過一次：一道歷史選擇題的正確選項被我們打錯一個字，它以 0.90 的信心選了錯的答案；只修正錯字重問，它就不再選那個錯的（見 suites/history-recall-context/；這個錯是讀者在 issue #2 抓到的，這一段的舊版也因此更正）。需要你沒給它的外部知識時，它知不知道你事前看不出來——📚 第三方真實案例裡，它在文章沒寫的背景關聯上比大模型弱（見 translations/libukai-hubei-news-classification-zh/），🔬 但我們自己的冷門史實題它不給背景也以 0.87 的信心答對。需要的資料放進 state 最保險。

它不是狀態機，也不是瞎猜——但也不是「會思考」的推理模型

看到上面「只能做窄判斷、不解釋自己」，很容易腦補成「它就是個狀態機/查表機」或「它在瞎猜」——兩者都不對，錯的方向還不一樣。

這個比喻不是空穴來風：「語意層的窄判斷」這個架構位置，過去一年通常是規則狀態機+反應快的小模型在填，代價是死板、能力上限低。Jev 想填的正是同一個位置，但底層換成真正的語言理解——這也是為什麼「狀態機」這個詞會自然冒出來，但直接套用又不準確。

為什麼不是狀態機：狀態機的核心是有限離散狀態+事先寫死的轉移規則。Jev 底層是真的訓練過的語言模型，做的是分布式語言理解，不是規則比對——證據見 suites/citation-support-check/ 的兩組對照案例：paraphrase_support（宣稱跟引文字面幾乎不重疊，但語意上真的支持，它判對了）、reversed_meaning_high_overlap（除了一個字幾乎逐字重疊，但那個字把意思整個反過來，它也判對了）。🔬 純規則/關鍵字系統做不到這兩件事。

但「狀態機」這個比喻有一件事講對了——不是它的內部運作，是它在系統裡該被放的位置。TypeSafe 自己的定位：「code needs a narrow decision it can inspect and act on」「99% machine-to-machine interactions」📖——它該被當成嵌進你自己程式邏輯裡的一個元件用，不是自主對話的夥伴。把它當「狀態機的一個節點」是對的架構直覺；把它的內部運作想像成狀態機是錯的。

為什麼不是瞎猜：confidence 不是另一個獨立的「自信心」機制，是從它已經給出的機率分布算出來的統計量。📖 這個數字值得信任是因為訓練目標本身就衝著它去：TypeSafe 把後訓練分三條路——RLHF（對話模型，目標是「人喜歡聽」）、RLVR（推理模型，目標是「推導對」）、RLCD（Jev 用這條，目標明講是「機率越高，答案正確的機會應該越大」）。📖 我們自己的測試裡多次看到這個數字隨案例難度真實起伏：反諷偵測跨句版的兩個刻意寫模糊的對照案例，一個信心掉到 0.19（接近丟銅板），另一個維持 1.00；🔬 歷史題那組也看得到：一道本身沒有唯一答案的題（「清朝第七任皇帝」，從努爾哈赤、皇太極、順治開始數答案各不相同，三個選項剛好各對一種），三次重問機率都接近打平、信心只有 0.07–0.13；同一組裡有唯一答案的題則是 0.87–1.00。🔬

但誠實的但書要講：calibration（校準）是群體統計性質，不是對單一答案的保證，TypeSafe 自己這樣寫。📖 我們找到的第三方跑分證實這會壞：DAIR Emotion 那組任務，Jev 平均信心 0.819，實際只對了 48%，還有 16% 的題目給「正確答案」的機率剛好是零。📚 這才是「瞎猜」疑慮真正該落地的地方——不是它到處在瞎猜，是它的信心機制在某些任務（類別本身重疊、糊在一起的那種）上會失準，而且失準的方向是「顯得比實際上更有把握」，這是最危險的失準方向。

還有一個常被搞混、值得跟「不是瞎猜」分開講的保證：因為 Choice/Score/Noul 的答案空間是你自己先宣告好的，它結構上不可能選到清單以外的東西——TypeSafe 自己的說法是「producing an invalid value or a hallucinated answer is mathematically impossible」。📖 這跟一般自由生成文字的模型不一樣：後者可能格式跑掉、答非所問，甚至生出一個你選項裡沒有的新分類，你得另外寫解析器去接住這些偏差；Jev 結構上沒有這個問題，回傳的值保證落在你定義的選項/等級裡。但這是型別保證，不是正確性保證——上一段 DAIR Emotion 就是活生生的反例：答案永遠落在六個情緒選項裡（型別保證成立），但選到哪一個常常是錯的（正確性保證不成立）。兩種保證分開看，才不會把「不會選單外」誤解成「不會選錯」。

那它到底是什麼：一個訓練過真正語言理解、但被限制成只能吐出型別化答案、且訓練目標鎖定「讓機率數字可信」的模型。跟狀態機的差別在於真正的語言理解；跟瞎猜的差別在於信心數字有實證支持（但不是無限可信，見上一段但書）；跟現在講的「推理模型」（o1/DeepSeek-R1 那類）的差別在於它不做展開式、多步驟、自我承接的推導——TypeSafe 把它放進第三個類別，不是簡化版推理模型，是不同的優化目標。三個否定句合起來才誠實，單挑一個標籤套上去都會失真。

具體案例：為什麼「瀏覽器自動化」測起來這麼強

有兩個獨立的第三方專案把 Jev 接進瀏覽器自動化，結果一致：jev-browser（獨立開發者做的 MCP 伺服器，對照 Playwright MCP 快 1.5 倍、便宜 1.6 倍、準確度打平）跟 jev-ultrafast（Browser Use 官方整合，單一任務中位數快 25%、瀏覽器協定呼叫少 91%）。📚 兩個專案分開的完整方法論、數字、誠實但書，見 capability-map.md ——這裡不重複，只講機制。

這不是「Jev 很會看網頁」——它現在只吃文字，不吃截圖，文件寫得很清楚。厲害的地方是這兩個整合都精準命中上面兩條原則：

  1. 把「看畫面」換成「讀給定文字」：不用截圖，改用結構化的 DOM 快照文字當 state——原本需要視覺理解的任務，被轉譯成純文字、訊號自足的判斷，正好落進它的能力圈。
  2. 把「一次一步」換成「一次批次」：不是每走一步就問一次慢模型「該點哪裡」，是把畫面上所有候選元素的判斷一次平行問完（TypeSafe 自己的說法叫「speculative fan-out」）——這正是它的強項：大量、窄、平行的判斷。

換句話說，強的不是模型本身多會逛網頁，是有人把它放對了位置——這正是上面「元件定位」那句話的活教材，不是例外。但這條原則的邊界也被同一組跑分抓到了：jev-browser 那組資料裡，一個純文字擷取（沒有操作動作）的任務，Jev 反而比單獨用 LLM 更慢更貴——訊號自足的優勢只在「要對頁面採取行動」時成立，「純閱讀理解」不是它的地盤，細節同樣見 capability-map.md。

已經看完這些證據、決定要把自己的系統接上去的人或 agent，讀 browser-automation.md——參考架構（一次呼叫問三題）、打字問題怎麼解、三個真實實作可以參考、接自己系統前的檢查清單，這裡不重複。

核心發現：一條軸

我們（用真實 API 呼叫，不是估的）加上讀到的第三方跑分，反覆驗證出同一條軸：

正確答案能不能完全從你餵給模型的 state 裡讀出來，還是需要外部知識/比較，而那些不在 state 裡？

訊號自足（state 裡有）訊號不自足（需要外部知識）
✅ 分類任務（AG News 91%、Banking77 87%——jev-benchmarks）⚠️ 需要文章沒寫的外部知識才能判斷的題（第三方真實案例：湖北新聞分類；它不一定不知道，但知不知道事前看不出來——見 suites/history-recall-context/）
✅ 引用支持度判讀（claim+quote 都給齊——見 suites/citation-support-check/）⚠️ 需要跟整個領域比較的評分（論文新穎性、专案重要性）
✅ 反諷/諷刺偵測（觸發線索在給定文字裡，即使跨對話回合——見 suites/sarcasm-vs-sincere-praise/）⚠️ 類別本身就重疊、糊在一起的分類（DAIR Emotion 48%，而且信心值同時失準——jev-benchmarks）

這條軸還有一種更隱蔽的違反方式：不是任務需要外部知識，是呼叫方自己沒把該給的內容放進 state。真實案例：有人試著用 Jev 判斷該不該砍掉 Agent 自己過去的工具呼叫紀錄（context 壓縮）——真實測試中，預設設定下打分看不到輸出內容本身，256 筆結果裡 0 筆保留信心值超過 0.3，等於幾乎每次都判定「可以刪」。這裡的判斷失敗好修，但「砍掉的內容不一定能復原」這個風險改不掉——這正是 AGENTS.md 已經講的「不可逆動作不該交給機率模型」原則，只是它藏在「內部清理」裡不容易被認出來。我們不建議把它做成無人監督、預設自動開啟的東西。完整追蹤見 translations/jev-context-compaction-debate-zh/。

完整方法論、來源分級（🔬 我們自己測的 / 📚 第三方跑分 / 📖 TypeSafe 官方文件 / 💭 我們的綜合分析）、逐項數據，見完整評測報告：Jev Evaluation Report（中英雙語）。

我能怎麼用 Jev？（給人看）

  1. 先讀 TypeSafe 官方的 skill，學怎麼呼叫 API、怎麼設計 Choice/Score/Noul 題目——那件事他們寫得很好，我們不重複。
  2. 再讀這裡的 capability-map.md（English），對照你要做的任務屬於「訊號自足」還是「需要外部知識」，校準你該有的期待值。
  3. 信心閾值自己在你的資料上驗，不要照抄任何一份報告（包括這份）裡的數字——TypeSafe 自己的文件也這樣講。三段式起點：高信心→自動執行；中信心→先確認；低信心→升級給人或給完整推理能力的模型。
  4. 遇到需要「知道什麼」而不是「判斷什麼」的任務，先做檢索、把資料放進 state——不是因為它一定記不得（我們自己的冷門史實題它不給背景也以 0.87 的信心答對），是因為記不記得你事前看不出來；放進 state 後同一題升到 1.00。見 suites/history-recall-context/ 跟第三方真實案例 湖北新聞分類。
  5. 單題判斷真的弱，才拆成多個原子化問題疊加，不要預設拆解一定比較準——一份第三方跑分量出來：拆解在三個任務上確實拉高準確率，但在「看起來危險、其實無害」的困難良性案例上，誤判率從單題的 1.5% 惡化到拆解版本的 37.2%，約 25 倍；多分類問題也別一題問到底（12 選項單題判斷準確率只有 0.3998，是那份跑分裡最差的結果）。拆解結果適合當第二意見疊加，不建議單獨扛安全把關這類判斷。細節見 capability-map.md。
  6. 先問你現在的判斷成本是不是已經是零，再決定要不要接 Jev——如果你本來就在用訂閱制的工具（Claude Code、Codex 這類），一次額外的大模型判斷邊際成本本來就接近零，插一層 Jev 進去只會多一層延遲、多一次出錯機會，省不到錢；Jev 真正划算的地方是原本要為每次判斷額外付費呼叫大模型的場景。另外，「快」真正的意思是沒有長尾，不是中位數領先——跟另一份第三方跑分／我們自己重跑的量測都顯示，Jev 中位數延遲不一定贏過輕量大模型，但幾乎不會出現讓人等到抓狂的離群慢查詢，這對使用者可見的即時互動場景比單純比中位數更重要。細節見 capability-map.md、suites/jev-latency-distribution/。

給 Agent：哪邊能嘗試改用 Jev、怎麼回報結果

直接讀 AGENTS.md，不要從這頁散文推——那份文件分兩種情境：被叫去評估別的專案哪裡適合換 Jev（掃描判準+檢查清單），或被叫進這個 repo 本身跑測試/加測試（含跑既有 suite 的指令、新增 suite 的步驟、以及回報結果的具體協定——有沒有 push 權限分別該怎麼做、回報裡一定要包含什麼）。也有正式打包成 Claude Skill 的版本，見 skill/jev-fit-check/，可以用 claude plugin install 直接裝（僅涵蓋「評估別的專案」那部分）。

貢獻真實實驗結果

歡迎三種貢獻：①新的測試組 ②翻譯與整理國外的跑分結果 ③純分析/心得。收據優先，不收手打數字——①要附真實 API 回應的原始 log，②要附可查證的原始出處連結。完整規則見 CONTRIBUTING.md。

目錄結構

README.md / README.en.md   本頁雙語（含機制說明，不是另開檔案）
AGENTS.md                  給 agent 讀的掃描判準
capability-map.md / .en.md 那條軸的彙整表，持續更新
browser-automation.md / .en.md  瀏覽器操作的實作指南（架構、打字問題、真實實作）
CONTRIBUTING.md            貢獻規則
skill/jev-fit-check/       打包成 Claude Skill 的 AGENTS.md
suites/                    每組實測（方法論＋協定＋真實 log＋報告）
translations/              國外跑分的翻譯與整理（只翻結果，不翻題目）
analysis/                  沒有單一既有條目可掛的純分析（跨條目觀察、判準軸本身的批評）
scripts/common/            共用的 API 呼叫樣板，不用各自重寫

授權

程式碼與原創內容 MIT（見 LICENSE）。translations/ 裡是我們自己寫的摘要與查證，不是原文翻譯稿；被引用內容的權利仍屬原作者，詳見 NOTICE。貢獻條目前請先讀 CONTRIBUTING.md——要轉載超過短句的原文，得先確認原始授權，這不是形式，是真的法律風險。

本專案與 TypeSafe 無關，未受其委託或贊助。「Jev」「TypeSafe」為其各自所有者之商標，此處僅作指涉之用。