TypeSafe Use Case Map 怎麼用：挑出能交給 Jev 的一秒判斷

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Jev 發表滿三天，官方文件也長成一套完整的方法論。9 月 15 日TypeSafe AI 亮相並發表這個不聊天的決策模型時，文件主要是 API 說明；現在 docs.typesafe.ai 上多出一整套方法論：一張按產業整理的 Use Case Map、一份「如何用 System One 蓋軟體」的建構指南，還有一頁官方自己承認的模型缺陷清單。同一天，9 月 18 日，開源社群交出一個附完整原始碼、可以直接下載重跑的 Jev 實作，評測平台 Braintrust 也掛上官方整合。這批新頁面合起來，剛好構成一套能直接帶回自己流程用的篩選法與拆解法。

先講結論。Use Case Map 不該當成客戶名單或案例型錄來讀，官方在頁面開頭就把用法講清楚：打開最接近你自己產業的區塊，掃過裡面的範例決策，再改編成你流程裡實際出現的文件與動作。真正有價值的內容也藏在這句話底下：每個產業案例拆到底，都會落到同一層「決策形狀」。你的流程裡哪一段判斷，答案可以事先列舉、有經驗的人一秒能判、程式拿到答案能直接動作，那一段就是候選。接下來的問題是怎麼把候選挑出來、拆開來，以及哪些東西官方明言不該交給它。

先看形狀再看產業：地圖底層那張十行表

Use Case Map 頁面把案例分成五個大類。AI 自動化軟體類的賣點是背景跑一百萬次也不用人陪；即時應用類強調判斷快過人眼感知；大量資料處理類靠便宜換處理量；通用驗證類反過來檢查別的 AI 的輸出有沒有犯特定錯誤；最後一類掛的名字是系統工程，對象是模型周邊的路由、檢索與監控。五個類別的共同點一句話就講完：判斷很多，答案有限。

比五分類更實用的是頁面底部那張任務表。官方把適合的判斷整理成十種決策形狀：分類、偵測、評分、路由、搜尋、檢索、排序、驗證、機器學習特徵擷取、結構化資料擷取，每一種都附了「什麼時候伸手拿它」的條件與例子。產業區塊只是這十種形狀的變奏，頁面上十九個產業區塊，從客服、招募、法遵一路排到遊戲與知識圖譜，每格裝的仍是同一批形狀套不同領域的詞。讀的時候跳過產業名稱直接對形狀，效率高得多。

Pin

判斷一段流程適不適合，文件裡給了一個很好用的測試：問自己，這是不是一個有足夠背景的人在一秒內能做的判斷。「這則訊息有沒有急迫性」是一秒判斷；「分析這則訊息並決定最佳處理方式」就不是，後者需要慢的推理，官方的建議是把後者拆成前面那種小問題，再讓程式組合答案。反過來說，如果答案的選項沒辦法事先寫死，或是程式拿到答案後沒有明確的下一步可以走，這段就不適合，交給一般模型或人反而單純。

官方自己劃的紅線：九種失敗模式

這份文件裡對採用者最有價值的一頁，可能是不太顯眼的那份模型缺陷清單。頁面標題叫 Jev 1.13 jaggedness，開頭明寫 Jev 不完美，以下是他們知道的毛邊，適用於目前版本 jev-1.13，頁面標註的最後檢視日期是 2026 年 9 月 17 日，也就是發表後第二天還在更新。清單列了九種失敗模式，每一種都附「替代做法」欄，等於官方親手把不該交給它的工作畫出來。

Pin

第一個要記住的是逐字解讀：Jev 回答你寫出來的問題，心裡想的那個不算。範圍詞、否定、言外之意都會被照字面讀，當你看到一個錯誤答案才開始解釋「我其實是想要」，那段解釋就是題目裡漏寫的一半。數字與計數是第二條紅線，官方直接寫 Jev 不是計算機，連數一個詞在段落裡出現幾次都不可靠，建議一律改由程式算。日期時間的比較也一樣，Jev 把日期當文字讀，不當有順序的量，誰先誰後、差多久、是否落在區間內都不可靠；文件示範的正確做法是把抽取交給模型做，用列舉選項的方式抽年月日，組裝成真正的日期後，排序與期間計算全部留在程式裡。

比較反直覺的是結構恆等式這條。你會以為同一個問題用 Noul 問和用 Choice 問，答案應該一致，官方用實例打消這個期待：同一張「我不滿意合身度，還有什麼選擇」的工單，Noul 問「客戶在要求退款嗎」得到 0.22，Choice 問同一件事，yes 的機率卻只有 0.01、confidence 高達 0.97；另一組例子裡，某事成立的機率 0.72 加上不成立的機率 0.47，加起來 1.19。結論是不要期待跨問型的恆等式成立，在某個 Noul 上調好的門檻，不要直接搬到 Choice 上用。

剩下的紅線看起來像常識，但每一條都對應一種真實的踩雷方式：指示裡的雙重否定與多步推理會掉準確率；state 塞滿無關細節會淹沒判斷，文件把這種衰退叫做 context rot；對抗性內容預設不被當成敵意文字處理；指示與選項定義互相矛盾時模型會混亂；最後，生成，Jev 沒有被訓練來生成文字，硬用串選項的方式逼它寫字，又慢又糟。這份清單的正確用法是在挑選階段就拿著對：候選判斷如果命中任何一條，先在程式端解掉再考慮送進模型。

拆解的紀律：一個大問題換六個小問題

挑出候選之後，成敗幾乎都壓在拆解這一步。官方建構指南在拆解段落放了一句自我標註：這大概是整份指南最重要的概念。理由寫得直白，大問題把好幾個判斷藏在一個答案後面，原子問題把這些判斷攤開，你才能個別檢查、個別調整、在程式裡個別加權。指南用的對照組是一封詐騙郵件：懶的問法是一個問題問「這是垃圾郵件嗎」，拆開後變成六個各自獨立的問題，訊息有沒有要求提供帳號密碼、有沒有宣稱意外獎勵、有沒有製造時間壓力、寄件者名稱與網域是否對不上、連結網域與寄件者是否矛盾、連結文字有沒有掩飾真正目的地。六個答案分開看，錯在哪一環一目了然；一個總分則把誤差糊在一起。

拆解有配套的三件紀律。輸入端，state 只放這批問題需要的欄位，官方連指向方式都規定好，用反引號包住的路徑指名你要判斷的是哪個欄位，例如 ticket.messages[0].text，模型就不會猜錯對象。問句端，同一份 state 的問題全部一次送出，這是這套 API 用法跟過去直覺差最多的地方：問題平行計價，多問幾題幾乎不影響回應時間，文件甚至鼓勵連現在用不到的問題都先丟進去，事後由程式挑答案，他們叫它投機式問句；現行文件的數字是十三題合併成一個呼叫，比逐題分開問便宜 11.5 倍、快 9.6 倍。輸出端，答案的組合發生在你的程式裡，不是模型裡，需要綜合判斷就用加權總分，權重寫在程式碼，優先順序變了改數字就好，不用重寫提示詞。

最後一塊是信心的路由。文件對 confidence 的定位一句話講得很重：一個系統如果不能表達誠實的不確定，就不能被信任。實作上他們建議把信心分三段處理，高信心自動執行、中段要求覆核或補資料、低段直接轉人或換系統；文件裡的範例拿 0.5 當地板，真正危險的動作再往上加碼，查餘額這種錯了可復原的操作門檻低，動用資金的操作要 0.9 以上而且保留一道確認。門檻不是寫死就結束，文件提醒要用自家資料畫出信心對實際正確率的分布，再回頭校門檻。這也是驗收拆解成果的畫面：每個原子答案可以個別查看、可以被程式重新加權、低信心的案件有明確去向，三件事都成立，這個設計才算拆乾淨。

9 月 18 日交卷的成績：一個能下載重跑，一個平台整合

方法講完，看實作。9 月 18 日當天最有分量的是一個開源稅務文件分類器，repo 名叫 tax-doc-classifier，掛在 kyotofin 帳號下，Apache-2.0 授權，TypeScript 寫成。倉庫在當天下午 2 點 40 分（UTC）建立，提交紀錄的作者署名 Nedwize，與約一小時後在 X 上分享這個分類器的帳號同一個名字，帳號顯示名稱為 Nakshatra Saxena。內容是把報稅文件的每一頁文字交給 Jev，在 261 種 IRS 表格與 7 種頁面類型裡做分類。

它值得看的地方在於整套架構就是官方方法論的照做版。一頁一個請求，第一輪先問頁面種類，再用 230 個選項加一個 not_in_this_list 問表格編號，五種結構複雜的企業表格（5471、8865、8933、1118、5713）另外進第二輪，把 35 張附表吸收進去，這正是官方 cookbook 裡階層式分類的兩段 Choice 作法。評測口徑也可以直接抄：README 定義嚴格模式，答錯或信心低於 0.95 都算錯。成績單上，314 頁填寫過的表格零答錯、零嚴格錯；753 頁空白官方表格同樣零答錯，但 38 頁、約百分之五，因為信心不到 0.95 被計入嚴格錯，作者拆解這 38 頁的組成：不寫明表格編號的說明頁、企業表格的深層頁，以及對母表拿不準的單一附表頁。換句話說，答案沒有分錯，但離自動通過還差一道信心門檻，這兩件事被這套口徑誠實地分開了。

Pin

對照組數字由作者在同一批頁面、同一台機器上量得：前一版用 Claude Sonnet 做的分類器每頁成本 0.039 美元、回應約 3.3 秒、能指名的表格 30 種；Jev 版每頁 0.00115 美元、約 0.5 秒、261 種，便宜 34 倍、快 6 倍。這些是作者提供的數字與環境，不是第三方驗證，門檻 0.95 也是作者自設，採用前仍要用你自己的文件重跑。同日的第二個事件是評測平台 Braintrust 的官方整合文，把 Jev 掛成 judge scorer，用來對 agent 回答打分，呼叫可以從 JavaScript 或 Python SDK 追蹤，畫面上直接看選項機率與信心；他們文件裡的示範答案，billing 選項機率 100%、信心 100%，格式乾淨得像教科書。

同一天 X 上還有三個展示級的嘗試，證據強度要另算一層。有人把 AIS 船舶與 ADS-B 航機的真實流量放上地圖，讓 Jev 對模擬事故挑選改道目的地；有人預告一個用 agent 跑端到端測試的開源框架，標訂 available soon，作者公司掛著 YC P26 的徽章；還有一個免喚醒詞的語音控制原型，讓電腦持續聽、由 Jev 判斷這句話是指令還是閒聊。三個都只有貼文與影片，沒有測試集，也沒有效能數字，看點是別人怎麼切問題，不能當成效保證。把證據分層是必要的：可重跑的開源、平台方的整合、個人的原型，三種能支撐的結論完全不同。

動手前要先對齊的現實：中文降幅未知、只吃文字、候補制

最先該看的一條跟語言有關，也是中文圈需要優先確認的。官方文件明寫，Jev 的主要訓練語言是英文，準確度目前以英文最好，其他語言包含 CJK 文字可以送、但表現不等值，建議先在自己的內容上測過再依賴。官方沒有給中文的量化數字，降幅多大是未知數，所以中文場景的合理做法是把小樣本測試當成採用前提：拿一批有人工答案的歷史資料，量出你自己的正確率與信心分布，再決定要不要往下走。輸入形態是另一條先天的邊界，Jev 只吃文字，state 必須是字串、JSON 物件或文字陣列，圖片、音訊、影片要先在程式端轉成文字或結構欄位才能送。

存取與產能則是會直接影響排程的現實條件。到 9 月 18 日為止，TypeSafe 首頁的入口仍是 Join Waitlist，排進候補後才在 console 後台拿到 API 金鑰；文件與範例本身公開可讀，playground 則需要登入。價格維持輸入每百萬 token 0.042 美元、輸出免費。產能上限方面，現行文件寫每秒 25 萬 token、每分鐘 1,200 次請求，同時附了一段少見的坦白：需求量太大，限流正在動態調整，數字可能無預警變動。資料處理上官方承諾不拿客戶的請求與回應做訓練，企業方案另有零資料保留的選項，合規評估可以從這兩條開始問。

不用金鑰就能開始：把功課做在候補排到之前

候補制不是空等的理由，這套方法論裡最重的部分本來就不需要 API。起手是盤點：把既有流程攤開，列出所有一秒判斷的候選，再拿九種失敗模式逐條對照，命中數學、計數、日期比較或多步推理的，先在程式端解掉。接著替存活下來的候選寫設計草稿，state 放哪些欄位、原子問題清單、每題用 Choice、Score 還是 Noul，原則官方給了：選程式拿到答案後能直接動作的那一種。歷史資料的整理也要提前做，把過去案子的人工答案與最終處理結果對齊，這批資料之後量信心校準時就是地基。最後預畫門檻，按動作的風險分級列出誰能自動執行、誰要覆核、誰轉人。

驗收點也先定好。拿到存取後的第一件事，是用自家歷史資料畫出信心對正確率的分布，看 0.95 這種別人量出來的門檻在你的資料上是不是站得住，再決定每個動作的門檻；中文內容的正確率沒有量化前，任何全自動的動作都應該緩一緩。三個訊號值得回頭重新檢視這套判斷：early access 轉正式開放的時間表、獨立第三方的評測數字，以及有人公布中文場景的實測結果。在那之前，Use Case Map 的正確姿態是拿來縮小範圍的需求訪談工具，選出來的判斷先在自己資料上證明可靠，再談自動化。