用Jev分類1852篇文章只花0.12美元｜初步篩選的成本變了

大家好，我是TIMEWELL的濱本。

上週我讓AI把自家網站上的1,852篇文章一篇一篇讀過，每篇回答兩個問題：這篇是不是在談出口管制、以及讀完的人最適合我們哪一項服務。花了49秒。依照官方價目表換算，大約0.12美元。這件事我們拖了好幾年，理由每次都一樣：要有人坐下來把全部讀完，而沒有人挪得出那一週。

用的是TypeSafe AI在2026年9月15日（美國時間）發表的Jev¹²。剛發表時，大家的切入點是「不寫文章的AI」「快40到200倍」，我一開始也是這樣讀的。自己跑過一次之後想法變了。重點不是快，而是初步篩選的成本已經低到不必再衡量該不該做。

先講結論。

• Jev不寫文章，只回傳選項、分數或真偽的機率。輸出免費，正是因為沒有書寫這道工序
• 我們的1,852篇：49秒、約0.12美元，平均一篇約0.00007美元（依價目表推算）
• 成本消失之後，「抽樣來看」和「做一次就好」這兩個前提都不成立了
• 但是，真偽問題的精確率有96.4%，九選一只有36%。門檻要用自家資料量過再決定
• 圖片和聲音都送不進去，算術和計數也不在行

以下，開發者依自身條件公布的數字會註明是「本人的說法」。我們的數字是自己跑出來的實測，但費用是依價目表推算，不是帳單金額。

初步篩選的成本，差了兩個位數

假設收到一封客服來信。給人看的對話型AI會客氣地回你一句「看起來是帳務相關的問題，我幫您轉給負責的同仁」。可是背後執行的程式要的不是這句話，而是「轉給帳務」這個判斷，以及這個判斷有多確定。用文章回覆，程式還得再解讀一次、轉成能拿來分支的形式。Jev的做法是一開始就不產生那句話。

要送進去的是一段描述狀況的文字，加上想問的問題。問題只有三種：從選項中挑一個的Choice、依自訂尺度給分的Score、回傳某個敘述為真之機率（0到1）的Noul。Choice和Score會附上每個選項的機率與整體的信心值。一次呼叫可以混進幾十個不同類型的問題³，而且是平行評估，所以問題變多，等待時間幾乎不變。

TypeSafe AI把這類模型稱為System One，名字取自心理學家康納曼所說的「快而直覺的思考」。官方文件寫得很直接：這類模型「不寫回覆、不產生程式碼，也不產生推理過程的說明」⁴。創辦人Diogo Almeida曾在OpenAI參與ChatGPT背後的研究，他說花了兩年用一種叫RLCD的訓練法做出這個模型²，目的是讓回傳的機率和實際命中率對得起來¹。

以上都還是機制。真正影響生意的是這一點：因為不寫字，所以輸出不計費。 輸入每百萬token 0.042美元，輸出免費⁵。初步篩選的成本，幾乎只剩下送進去的文字長度。

實際花了多少

前兩列是我們自己跑的，其餘是官方與開發者公布的數字。

做什麼	數量	費用	時間
自家文章分類（本公司，一次三問）	1,852篇	0.12美元	49秒
自家文章的導流判定（本公司，一次五問）	1,852篇	0.10美元	約2分鐘
程式碼變更檢查（本人的說法）	1,000件	0.07美元	每件約0.5秒
判例重排序（官方手冊）	1,200次	0.0645美元	未記載

我們這兩次，每篇送進約2,000字，一次問三到五個問題。換算下來一篇約0.00007美元。就算跑一萬篇，也到不了一美元。

做程式碼檢查的Paolo Rosson在貼文裡寫「1,000件7美分，換成大型模型大約要14.50美元」⁶。那是他自己條件下的比較，不能照單全收，但兩個位數的差距，和我們量到的感覺一致。

成本到這個水準，就不會再用花費來決定一件事做不做了。這是這次感受最強的一點。1,852篇用人工看，一篇一分鐘也要31小時；發包出去就是一筆實際支出。所以它在待辦清單上躺了好幾年。二十美分的話，想到就跑。

成本消失之後，設計會改變

便宜不只是做得比較快，有三個前提會失效。

第一，可以不用抽樣了。 過去的分析都從「全部看不完，先抽一百件看趨勢」開始。如果全量跑得起，就沒有抽樣的理由。我們自己整理時，抽40篇來看只有30%一致，差點就下了「不能用」的結論。跑完全部1,852篇才看出來，不一致集中在特定分類，問題出在我們的分類本身。抽樣看不到這個結構。

第二，可以不用「做一次就好」。 多寫一篇文章就重跑全部，也才二十美分。想改判定條件，把問題改寫再跑一次就好。原本那張「不知道上次什麼時候做的盤點表」，變成每次都能重新產生的輸出。

第三，可以不用先篩再問。 問題是平行評估的，多問幾個幾乎不影響等待時間。不必設計成「先問急不急，急的再往下問」，可以一次全部問完，組合方式交給程式決定。官方的設計指引也是同樣的意思：「程式負責確定性的處理並掌握流程，模型只出現在需要常識判斷、或需要解讀非結構化資料的地方」，而問題要「盡可能明確、狹窄、具體、單一」⁷。

取代人工初步篩選的20個用法

以下取自發表後幾天內公開的實作，以及官方手冊。排序從「以前靠人讀來分類的工作」開始，接著是「在昂貴的模型看到之前先丟掉」、操作畫面，最後是速度本身就是重點的實驗。遊戲和自駕的試作我也看了，難以換算成業務判斷的這次就不收。

以前靠人讀來分類的工作

01｜用14個項目檢查程式碼變更。 Paolo Rosson把pull request的差異貼進去，一次呼叫就拿回14個檢查項目的機率：機密資訊外洩、SQL注入、測試被刪掉等等。他說一件0.00007美元、半秒回覆。這不代表品質等同人工審查，但作為人看之前的初步篩選，數字很實際⁶。

02｜用61個角度一次評分一則貼文。 經營SuperX的Rob Hallam把61個問題一次丟給貼文草稿，評估擴散的可能性。他說61個答案約一秒、一則0.0004美元，用207位創作者的9,481則貼文調校，兩則中挑出較會擴散的那則，三次會中兩次⁸。這是把「問題不用錢」用得最直接的例子。

03｜把直播留言分成提問、感想、需求。 日本開發者kogiso做了一個把留言分到四類的示範。只把提問推到主持人的畫面，需求留到事後統計。他自己也寫「適合把應用程式或工作流程裡的小判斷交給AI」⁹。

04｜用文字的語意過濾資料庫。 Zachi在PostgreSQL裡加了一個能用文字寫條件的函式。寫成 WHERE jev(people, 'could work from home')，就會逐列讀過再判斷。不用索引也不用向量，他說129列約一秒、0.0009美元。重點在於模型不是在寫SQL，而是在SQL裡逐列作答¹⁰。

05｜打上欄位名稱，每一列就自動分類。 nader dabit的預測型試算表，在欄位標題打上「Urgency（急迫度）」，就會讀過每一列的內容給出分級。他說一列約100毫秒。就像公式會重算數值一樣，這是會重算語意的表格。不過急迫的標準各家不同，光給欄位名稱不能完全交出去，把分級的定義講清楚才是落地的工作¹¹。

06｜決定交給哪一個機器人、哪一個模型。 Milind S做了一個參謀長的角色：讀進來的任務，決定叫醒哪一個待命的機器人、給它哪一個模型。不必再靠人記得「這種小事別用貴的模型」。官方也把模型路由列為主要用途之一¹²¹³。

07｜用「剛才那份PDF」找到檔案。 同一位dabit做的預測型啟動器，就算不記得檔名，打上「剛才下載的PDF」也會把符合的候選排到上面。傳統啟動器靠別名、部分比對與使用頻率排序，這裡則是每敲一個字就讀一次意圖，他說約100毫秒重排¹⁴。

08｜依照講者說的內容自動切換投影片。 Rinte的示範會挑出符合當下發言的那一頁投影片。它不製作資料，只從既有的頁面中挑。他在後續貼文說明，對話的來回交給另一個語音對話模型，只把判定切出來，理由是讓對話模型來判定會拖慢輸出¹⁵。

在昂貴的模型看到之前先丟掉

09｜在摘要之前，先決定要留什麼。 tamara的「instant compaction」開頭一句話很到位：都2026年了，為什麼脈絡壓縮還在用摘要提示詞？她的做法是把整個工作階段裡所有的工具呼叫拿去評分，把無關的丟掉，壓縮就在一瞬間完成¹⁶。摘要是「寫」的工作，所以慢，而且重要的細節會掉。先決定留什麼，要寫的量本身就變少了。這是全文最能套用到別處的想法。

10｜挑選要送進程式輔助AI的紀錄。 中文圈的帳號梭哈.AI發了一篇解說上述做法的貼文。寫長程式時，脈絡一滿，每次都要停個幾秒到十幾秒做摘要；改成把累積的無用紀錄評分後丟掉，就不用停¹⁷。發表兩天就出現中文解說，本身就說明了擴散的速度。

11｜把檢索到的候選重新排序。 官方手冊用3,565筆判例做了示範：先用全文檢索抓出前30筆，再對每一筆問一個真偽問題「這一筆是被引用的判例嗎」，依回傳的機率重排。40個檢索問題中，正解排第一的比例從5%升到18%，進入前十的比例從38%升到62%，1,200次呼叫共0.0645美元。但官方也明寫了限制：「沒被快速檢索選進來的段落，它救不回來」¹⁸。檢索這張網還是得另外準備。

12｜加進筆記軟體的搜尋。 Ian Nuttall把它接進筆記軟體keep.md的搜尋，表示「重排序比現行做法快7倍，標記比另一個小型模型快50倍且沒有失敗」¹⁹。也有像jev-search這種小工具，讓Obsidian的筆記可以選擇性加上重排序。如果你注意到04、09、11是同一個形狀，就抓到本文的重點了：把候選排開，逐一問「有關嗎」，用門檻留下。

面對畫面與現實

13｜約7秒完成一次機票查詢。 瀏覽器操作代理「Browser Use」的創辦人Gregor Zunic，讓它在Google Flights查蘇黎世到倫敦的班機。貼文寫7秒、0.0039美元。做法是把頁面上的按鈕與輸入欄位編號列成清單，讓模型選「哪個操作、對哪個元件」。需要輸入城市名這類文字時，才交給另一個小型語言模型。示範到看見結果為止，沒有走到購買²⁰。

14｜把畫面轉成文字，再決定點哪裡。 Milind S的做法不把螢幕截圖送到任何地方。Mac上跑的小型影像模型切出畫面元件，裝置內的OCR讀出標籤，只把那些字串送出去。回傳每個元件的機率，點機率最高的，然後重新偵測。他說一次判斷約90毫秒²¹。對一個看不見圖片的模型來說，這是目前最直觀的「讓它看畫面」的辦法。

15｜用講的操作瀏覽器。 Moritz Kremb把語音指令接到瀏覽器操作上。一開口，逐字稿送出，回傳操作目標的機率，瀏覽器就點下去。他說判斷約300毫秒、一次0.0002美元。要注意這不是從語音到畫面反應的總時間²²。

16｜把判斷放進Chrome擴充功能。 RaZaan公開了一個擴充功能，代理會看頁面決定要點哪裡、做什麼操作。常駐在瀏覽器裡，很適合接手公司內部的申請畫面或SaaS上的例行操作²³。

17｜操作iOS模擬器。 iOS開發者camsoft2000把它接進自己做的模擬器操作工具，讓它做出新增提醒這類操作。工具取出畫面的元件結構並精簡，模型決定下一步，工具執行後再問一次「要繼續還是停下」。這還沒解決實機的權限與連線條件，而且他說串接的部分尚未公開²⁴。

速度本身就是重點的實驗

18｜在Doom裡連續做短判斷。 這是TypeSafe AI自己的發表示範。把遊戲狀態變成結構化文字送出，回傳下一個動作。官方部落格說每秒約10次呼叫，費用約每小時7美元；也寫明輸入不是圖片，而且「不用AI的傳統Doom機器人有時玩得更好」¹。在自家的宣傳示範上主動加註保留，這點我是有好感的。

19｜把即時反應和計畫分給不同模型。 Wuyang Zhou把Jev和OpenAI的GPT-6 Astra組起來玩Minecraft。依他的說明，殭屍來襲這類突發狀況由Jev即時反應，通關這種大目標則由Astra提前規劃²⁵。和08是同一個結構，換到業務上就是「第一線反應交給快的，複雜判斷交給大的」。

20｜把買賣判斷接到下單。 Jarrod Watts的「jev-trader」讀貨幣對的價格資訊，回答買或賣，然後對交易所下單。那個環境約每300毫秒產生一個區塊，所以判斷與下單都要塞進這個間隔。公開的儲存庫裡有「沒設定私鑰就不會真的下單」的設定，以及取代Jev的模擬模型，而且預設就是模擬模型。這不是「會賺錢」的證據²⁶。

便宜，不等於可以隨便用

前面一直在講成本，這裡講反面。我們那1,852篇同時也是一次準確度的實測，拿來當正解的是每篇文章原本就帶的分類。

問真偽，也就是「這篇是否以出口管制、經濟安全保障、制裁為主題」時，門檻0.20下精確率96.4%、召回率87.9%。1,547篇不屬於該主題的文章裡，誤抓的只有10篇。中文與日文能到這個水準，拿來做業務上的初步篩選綽綽有餘。

但改成從九個分類挑一個，只有**36%**一致。這個落差才是重點。追下去發現，錯的與其說是模型，不如說是我們的分類：有一個分類變成了大雜燴，裡面塞了892篇。與其用多選硬猜，不如把真偽問題並排問、再用門檻決定，準確度和可解釋性都比較穩。 這也算是用實際資料印證了官方那句「問題要狹窄、具體、單一」。

門檻也不能憑感覺。用預設的0.5去切，召回率掉到75%。降到0.2，誤抓也只有1,547篇裡的10篇。而且錯的方式有跡可循：資安人員適任性審查、防諜法規這類「出口管制的周邊」，都集中在0.40到0.49之間。要不要連周邊一起撈，是可以自己決定的，前提是有量過。

官方也沒有藏起弱點：按字面解讀、不擅長算術與計數、日期大小的比較不可靠、無關資訊一多準確度就掉²⁷。另外，能照格式作答和不會答錯是兩回事。官方網站寫「不會產生幻覺」，意思是不會吐出格式以外的值；Hacker News和The Register都指出「格式正確但內容錯誤」仍然可能發生²⁸。所以才會附上機率與信心值。官方建議的是三段式運用：信心高就自動執行，中等要謹慎，低的話「不要執行，轉給人、請對方補充，或退回另一套機制」²⁹。

關於費用還要補一句。便宜的只有判定本身。把畫面轉成文字、語音辨識、OCR、檢索那張網，這些周邊的費用和工夫都要另外算。既然圖片送不進去，想處理影像就一定要有前置的一段⁴。請養成看總額的習慣。

要接進RAG的話，官方手冊寫得很具體。其中一種是在檢索與生成之間放一層分類，對撈出來的每一段問四件事：有沒有處理到主題、有沒有可以拿來作答的資訊、有沒有和前提矛盾、以及這段是不是在試圖操控回答的系統。最後一項是提示詞注入的偵測，超過門檻的就在送進生成模型之前丟掉³⁰。即使如此，官方仍提醒「這是檢查，不是安全邊界」。我們的企業級AI「ZEROCK」以GraphRAG為底，從那邊的經驗來看，檢索的準確度往往不是取決於方法，而是取決於「送什麼、丟什麼」的設計，這種判定角色放進去很自然。基本功整理在提升RAG準確度的七個實務技巧。

不寫程式的人可以帶走的三件事

第一，把「因為太貴而放棄的工作」想起來。 全量盤點、所有詢問的重新分類、把所有會議紀錄裡的待辦抓出來。這些都卡在「做得到就好，但沒人力」。知道二十美分就能跑完的那一刻，判斷的前提就變了。先在自己的部門列出三項因為成本而擱置的初步篩選。這份盤點比選工具更該先做。

第二，不要說「你看著判斷」，要把真偽問題並排交出去。 我們的實測就是依據：九選一36%，真偽96%。不要問「急迫度多高」，而是拆成「客戶是不是希望有人來處理」「以前有沒有問過同樣的事」「有沒有提到金額」，組合方式交給程式決定。這種拆解，只有熟悉業務的人做得到，沒辦法整包丟給工程師。

第三，門檻和喊停的方式要先決定。 要在哪裡切是量出來的，用預設值就會安靜地漏掉東西。官方之所以建議信心低時轉給人，正是因為這是把判斷自動化的工具，所以更要先畫好停下來的那條線²⁹。便宜不是可以隨便用的理由；反過來說，因為便宜，才能多量幾次。

最後一件事。把這次發表當成性能競賽來讀，會覺得它很小：不寫文章、不看圖片、也不會算。但放在同樣能力的價格持續下滑的2026年來看，多出一個「只回傳判斷、而且很便宜」的零件，意義並不小。就像我在自主性與成本的兩條曲線寫過的，接下來AI的差距，不在於用哪一個模型，而在於怎麼運作、記錄什麼、由誰喊停。想一起盤點貴公司業務裡的判斷分歧點、以及要交出去到哪裡、從哪裡收回給人，歡迎透過WARP的個別諮詢聊聊。

參考文獻

Footnotes

1. Introducing System One Models and Jev（TypeSafe AI、Diogo Almeida）。System One模型的定義、回應時間70〜500毫秒、快40〜200倍的主張、輸入0.042美元/百萬token與輸出免費、RLCD、Doom示範（每秒約10次、約每小時7美元、輸入不是圖片而是結構化資料、傳統機器人有時玩得更好）皆出自該篇（筆者譯）。頁面顯示日期為2026年9月18日（應為更新日），發表日見註2 ↩ ↩² ↩³

2. Diogo Almeida的發表貼文（2026年9月15日，美國時間）、TypeSafe AI官方帳號的貼文（同日）。「共同發明ChatGPT之後，以隱形模式花兩年做出RLCD這個新訓練法與Jev」出自前者（筆者譯）。報導見The Register（2026年9月16日） ↩ ↩²

3. Introduction（TypeSafe AI Docs）。Choice、Score、Noul三種、回傳值、一次呼叫可混用，以及 "No text generation, no parsing." ↩

4. System One（TypeSafe AI Docs）。原文 "System One models do not write replies, produce code, or generate explanations of their reasoning." 與 "Jev currently accepts text input only. It evaluates strings, JSON objects, and arrays of text. Images, audio, and video are not supported (yet)."（筆者譯） ↩ ↩²

5. Models（TypeSafe AI Docs，2026年9月19日取得）。現行jev-1.13.0、輸入42美元/十億token（0.042美元/百萬token）、輸出免費、脈絡64k、僅限文字，原文 "English is the primary training language and where accuracy is currently best"，其他語言則是 "handled but not equally well; test on your own content before relying on Jev for a non-English workload"（筆者譯） ↩

6. Paolo Rosson的貼文（9月17日）。一件0.00007美元、半秒、「1,000件7美分，大型模型約14.50美元」皆為本人的報告值 ↩ ↩²

7. How to build with TypeSafe（TypeSafe AI Docs）。原文 "Code handles deterministic work and owns the control flow. The model appears only where the system needs programmable common sense or needs to interpret unstructured data." 與 "Ask the most explicit, narrow, specific, atomic questions you can."（筆者譯） ↩

8. Rob Hallam的貼文（9月18日）、同日另一則 ↩

9. kogiso的貼文（9月18日） ↩

10. Zachi的貼文（9月18日）、儲存庫 ↩

11. nader dabit的貼文（9月18日） ↩

12. Example use cases（TypeSafe AI Docs）。原文 "Replace or supplement embeddings in RAG pipelines with semantic search, scoring, and ranking"、"Use Jev to build a custom router that chooses which LLM receives each prompt"（筆者譯） ↩

13. Milind S的貼文（9月17日） ↩

14. nader dabit的貼文（9月18日）、實驗的儲存庫 ↩

15. Rinte的貼文（9月18日） ↩

16. tamara的貼文（9月18日）、儲存庫 ↩

17. 梭哈.AI的貼文（9月18日） ↩

18. Re-ranking（TypeSafe AI Cookbooks）。CLERC判例3,565筆、40個查詢、BM25前30筆以Noul重排、Top-1 5%→18%、Top-10 38%→62%、1,200次共0.0645美元，原文 "It cannot add a passage that fast search did not select."（筆者譯） ↩

19. Ian Nuttall的貼文（9月18日）。7倍、50倍皆為本人條件下的報告值 ↩

20. Gregor Zunic的貼文（9月17日）、公開儲存庫。儲存庫的說明為含載入與輸入共7.1秒 ↩

21. Milind S的貼文（9月18日） ↩

22. Moritz Kremb的貼文（9月17日）、儲存庫 ↩

23. RaZaan的貼文（9月18日）、公開頁面 ↩

24. camsoft2000的貼文（9月18日）、AXe的儲存庫 ↩

25. Wuyang Zhou的貼文（9月18日） ↩

26. Jarrod Watts的貼文（9月17日）、儲存庫 ↩

27. Jev 1.13 jaggedness（TypeSafe AI Docs）。按字面解讀、算術與計數與日期比較的弱點、無關資訊使準確度下降，以及 "jev-1.13 is not trained to generate text." ↩

28. Introducing System One Models and Jev（Hacker News，2026年9月）。2026年9月19日時為1,890分、495則留言。「格式正確但值可能是錯的」的指出與Almeida的回應皆在該討論串。The Register（2026年9月16日）也有同樣的保留 ↩

29. Confidence（TypeSafe AI Docs）。信心值是由機率分布算出的0〜1數值、Noul沒有、High自動執行、Medium謹慎、Low為 "Do not act. Route to a human, request clarification, or fall back to a different system."（筆者譯） ↩ ↩²

30. Classifying RAG passages（TypeSafe AI Cookbooks）。相關性、可否作答、與前提矛盾、是否操控系統四問，門檻集中以常數管理，原文 "Nothing here is a security boundary."（筆者譯） ↩