Jev（只做決策的校準模型）＋ Treg（便宜的資料 API）如何讓商業自動化的可信度與單位經濟同時成立

文字解析 · 1 支影片 · 產生於 2026-10-01 00:54

🎧 語音解析✍️ 練習

1. Outline

1. 起點 · Jev + Treg is a crazy combo for automation...
   從「強模型為何不敢用在商業流程」出發，介紹 Jev 的能力邊界與 API 形狀，再用三條真實管線示範 Jev + Treg 如何改變自動化的單位經濟。

2. YouTuber 的思維推導

Jev + Treg is a crazy combo for automation...

AI Jason · 14m29s · 字幕 en · vision=on （input 指定 vision=true；影片是螢幕錄影，比較表、API 呼叫範例、信心分數決策樹與成本對照都在畫面上，字幕只說「like this」。） · YouTube

作者（AI Jason）從一個矛盾出發：最新的大模型能解奧林匹亞等級的數學、寫程式，卻沒有公司敢讓它全自動處理牽涉帳務的客服單。他把原因歸結為兩點——模型過度自信、沒有校準過的信心值，以及商業流程量大、成本與速度必須划得來——並指出兩者都是 RLHF 這種訓練方式帶出來的副作用。接著他介紹 Jev：一個用「reinforcement learning for calibrated decisions」訓練、只在給定選項中做決策、不生成文字的模型，因為不逐 token 生成，所以比最便宜的大模型快 5–7 倍、便宜 5 倍，而且輸出的是整個選項的機率分佈。

有了信心分數，就能在模型外面寫業務邏輯（門檻、分流、人工審查），這正好補上第一個弱點；快與便宜補上第二個弱點。他用 API 的形狀（state ＋ 三種問題）與引導技巧（描述、範例）說明怎麼把商業判斷「翻譯」成 Jev 能答的選擇題，再把自己公司真正在跑的三條管線（註冊詐騙偵測與升售分類、LinkedIn 買家意圖 lead 篩選、Twitter 爆紅貼文 organic/paid 篩選）攤開來，說明 Treg 這個「資料與工具的 open router」負責便宜地把外部訊號抓進來、Jev 負責便宜地做判斷，兩者一起讓原本單位經濟不成立的自動化變得划算。結論是：Jev 開了很多以前做不到的自動化機會，Jev ＋ Treg 則從根本改變了這類自動化流程的單位經濟。

3. 逐段說明

Jev + Treg is a crazy combo for automation...

2. Jev 是什麼：只做決策、不生成文字 0:58–2:22

一般大模型走 RLHF，Jevi 走的是「reinforcement learning for calibrated decisionsi」：專為可靠、高品質決策設計，而不是創作或協助人類。它只能在給定選項中挑，不能自創選項、不能輸出文字、不能寫程式、不能逐步推理。因此它不是逐 token 預測，而是一次輸出所有選項的機率。作者實測比最便宜的智慧模型快 5–7 倍、便宜 5 倍；限制是 context windowi 只有 32K，太長要自己做 map-reducei。

承上 承接上一段留下的問題：既然 RLHF 為聊天助理而訓練會帶來過度自信與高成本，那就需要一個用不同目標訓練、專門做決策的模型——這段介紹的 Jev 正是這個答案。

推理因為上一段把弱點歸因到訓練目標，所以作者先對比兩種訓練方式：一般模型走 RLHF，Jev 走「reinforcement learning for calibrated decisions」，目標是可靠的決策而不是創意或協助人類。接著他用四個「不能」（不能自創選項、不能輸出文字、不能寫程式、不能逐步推理）畫出能力邊界，再從邊界推出好處：不逐 token 生成，所以一次輸出所有選項的機率、又快又便宜；他用自己做的對照表佐證（比最便宜的智慧模型快 5–7 倍、便宜 5 倍），並誠實列出限制（32K context window），最後點出「輸出的是機率分佈i」——這是下一段所有新用途的來源。

• CJev 是只在給定選項中做決策、不生成文字、一次回所有選項機率的模型→ 畫地圖
• RJev 的四個「不能」→ 存＋回想
• RJev 的 context window 是 32K→ 存＋回想
• EJev 比 GPT-5.6 Luna 快 5.9–7.0 倍；成本在 2k 輸入只便宜 1.7 倍，8k 以上才 5.7 倍→ 存＋演練
• P輸入超過 32K 時用 map-reduce 拆問→ 練習

AI 補充作者說「所以它快」，但沒解釋為什麼「不生成文字」會帶來速度。關鍵在自回歸生成：一般大模型每產生一個 token 都要跑一次完整的前向傳播，回答越長越慢、越貴；Jev 只需要對整個輸入跑一次，然後對 N 個選項各算一個分數（可以理解成一次分類），所以延遲幾乎跟輸出長度無關。從畫面上的對照表可以看到更精細的數字：Jev 每次呼叫約 0.39–0.51 秒，對照 GPT-5.6 Luna 約 2.35–2.74 秒，速度倍數 5.9–7.0 倍符合作者說法；但成本倍數在 2k 輸入時只有 1.7 倍，要到 8k 以上才穩定在 5.7–5.8 倍——「便宜 5 倍」在短輸入時是高估的。另外 32K 的限制不是小事：許多商業文件（長對話紀錄、整頁 DOM）都超過 32K，作者提到的 map-reduce 意思是先把長輸入切塊各問一次、再把各塊結果合起來再問一次。

術語:token-by-token generationi

✕

Jev

Jev 決策模型

一個只在給定選項中做決策、不生成文字、一次回傳所有選項機率的模型。

Jev 的定位跟大模型不同：它不是「更小的 GPT」，而是刻意放棄生成能力（不能自創選項、不能輸出文字、不能寫程式、不能逐步推理），換來三樣東西——校準過的信心分數、極低延遲、極低成本。你可以把它想成一個可以用自然語言描述任務的高品質分類器。限制是 context window 只有 32K，超過要自己切塊。它由作者在影片中提到的團隊訓練，訓練方法叫 reinforcement learning for calibrated decisions。

相關術語: reinforcement learning for calibrated decisions (訓練方法)、probability distribution (輸出形式)、RLHF (Reinforcement Learning from Human Feedback) (對照組)

出處：第 2 段「Jev 是什麼：只做決策、不生成文字」

✕

reinforcement learning for calibrated decisions

為校準決策而做的強化學習

以「機率是否校準、決策是否可靠」為獎勵目標的強化學習訓練方式，而非以人類是否滿意為目標。

這是 Jev 團隊對自家訓練法的稱呼，跟第 1 段的 RLHF 形成對照：RLHF 獎勵的是人類覺得回答好，會把模型推向自信與討好；這裡獎勵的是「你說 80% 就真的要 80% 對」，模型反而學會在不確定時把機率攤開。影片沒有講技術細節，可以理解成把校準誤差當作訓練訊號的一種 RL。

相關術語: RLHF (Reinforcement Learning from Human Feedback) (對照組)、calibration (優化目標)

出處：第 2 段「Jev 是什麼：只做決策、不生成文字」

✕

token-by-token generation

逐 token 生成（自回歸生成）

一般大模型每次只產生一個 token，再把它接回輸入去產生下一個，回答越長要跑越多次。

這是大模型慢與貴的根本原因：每一個 token 都是一次完整的模型前向傳播。Jev 不走這條路，它對輸入跑一次就對所有選項打分數，所以延遲跟輸出長度無關。理解這點就能理解為什麼作者說 Jev 比最便宜的大模型還快 5–7 倍——不是模型比較小，而是根本不用「生成」。

相關術語: Jev (相反做法)

出處：第 2 段「Jev 是什麼：只做決策、不生成文字」

✕

context window

上下文視窗

模型一次能讀進去的最大輸入長度（以 token 計），Jev 是 32K。

32K token 大約是兩萬多個英文字或一萬多個中文字。對客服單、一則貼文夠用，但整頁 DOM、長對話紀錄、整份文件常會超過。作者說超過就得自己做 map-reduce：把輸入切成多塊分別問 Jev，再把各塊的結果合成一個新的輸入再問一次。

相關術語: map-reduce (超限時的解法)

出處：第 2 段「Jev 是什麼：只做決策、不生成文字」

✕

map-reduce

分治合併

把太長的輸入切成多塊各自處理（map），再把各塊結果合併成最終答案（reduce）。

原本是分散式運算的模式，在 LLM 應用裡常用來繞過 context window 限制。以 Jev 為例：一份 100K 的文件切成四塊各問「這塊有沒有提到 X」，再把四個答案合起來問一次「整份文件是否提到 X」。代價是多次呼叫與可能漏掉跨塊的關聯，但因為 Jev 很便宜，多幾次呼叫通常划得來。

相關術語: context window (繞過其限制)

出處：第 2 段「Jev 是什麼：只做決策、不生成文字」

✕

probability distribution

機率分佈

Jev 對每個選項各給一個機率、全部加總為 1 的輸出形式，而不是只回一個答案。

這是 Jev 跟「只回一個標籤的分類器」的差別：你不只知道它選了哪個，還知道它有多確定、第二名差多少。因為第 2 段提到的訓練目標是校準，這些機率可以被當成真實的信心值來用。它是後面所有「圍著機率寫業務邏輯」做法的基礎。

相關術語: calibration (前提)、Jev (輸出於)

出處：第 2 段「Jev 是什麼：只做決策、不生成文字」

見仁見智 1:57

「quite consistently Jeff is around five to seven times faster and five times cheaper」

「便宜 5 倍」只在較長輸入成立。作者自己畫面上的對照表顯示成本倍數在 2k 輸入時只有 1.7×，8k／16k／32k 才是 5.8×／5.8×／5.7×；速度倍數（約 5.9–7.0×）則各長度都符合。短 prompt 的場景成本優勢會比作者說的小。

依據: 影片 1:55 處作者自製的 Jev vs GPT-5.6 Luna 對照表（frames/s02_115.jpg）

留給下一段 Jev 回傳的不是單一答案，而是每個選項的機率分佈——這個「附帶信心分數」的特性到底能解鎖什麼以前做不到的用途？作者接著舉例。

3. 機率分佈解鎖的新用途 2:22–4:46

每個答案都附信心分數i，所以終於可以圍著它寫商業邏輯、讓模型全自動運作。作者列出以前做不到的用途：即時決策的遊戲、直播監控通話並即時分類詐騙／不滿；瀏覽器與電腦操作——DOM 很雜亂，大模型不是點錯就是吃光 context，Browser Usei 已整合 Jev：送任務、互動歷史與 DOM 元素清單，Jev 只預測下一步是 click 還是 type、對哪個元素，再交給小型語言模型生成文字；還有 SEO 內部連結對映i，Claude Opus 5 要幾小時，Jev 掃 500 多頁不到 50 秒。

承上 承接上一段留下的線索：Jev 回傳的是每個選項的機率分佈，這個「附帶信心分數」到底能解鎖什麼——這段把它跟「快、便宜」合在一起，列出以前做不到的用途。

推理因為上一段建立了 Jev 的三個特性（校準的信心分數、極快、極便宜），所以作者這段依序用每個特性推出一類用途：信心分數讓你能圍著它寫業務邏輯，模型才第一次可以全自動運作；「快」解鎖需要即時決策的場景（玩遊戲、直播監控通話即時分類詐騙／不滿）；「選項有限＋快」解鎖瀏覽器與電腦操作——DOM 很雜亂，大模型不是點錯就是吃光 context，Browser Use 把 Jev 放進流程，只讓它決定「下一步是 click 還是 type、對哪個元素」，文字生成交給小型語言模型；「便宜」解鎖大量資料的批次任務，例如 SEO 內部連結對映，Claude Opus 5 要幾小時、Jev 掃 500 多頁不到 50 秒。每個例子都是「Jev 做選擇、別的東西做生成」的分工。

• C每個答案附機率，你才能圍著它寫業務邏輯、讓模型全自動運作→ 畫地圖
• C把「決定」跟「生成」拆開：Jev 選、語言模型寫→ 畫地圖
• EBrowser Use 讓 Jev 只決定 click/type 與目標元素，文字交給小模型→ 存＋演練
• E內部連結對映：Jev 每次呼叫 302 tokens、Opus 5 4,483 tokens；500 頁 < 50 秒→ 存＋演練

AI 補充作者說 DOM「很雜亂」但沒讓人看到有多雜亂；畫面上他打開一個 Airbnb 訂房頁的 DevTools，可見一頁的 HTML 是幾十個 async script、巢狀 div 與長 class 名，把它整份塞給大模型，一頁就可能吃掉大半個 context window，而且模型要在幾百個候選節點裡「生成」正確的 selector，錯一個字就點錯。Jev 的做法把它改成分類問題：候選元素清單就是選項，模型只要回「哪一個」的機率，所以既不會生成不存在的 selector，也不需要長輸出。這正是作者分工的核心：把「決定」跟「生成」拆開，決定交給 Jev（便宜、校準、快），生成才交給語言模型。內部連結對映那個 demo 畫面也值得看：兩邊同時起跑，Jev 一側已讀 76 頁、放了 1,201 個連結、每次呼叫約 302 個 token，Opus 5 一側只讀 6 頁、每次呼叫 4,483 個 token——差距不只是模型速度，而是 Jev 不需要把推理過程寫出來，每次呼叫本身就短。注意「Opus 5 要幾小時」是作者的說法，畫面上是模擬跑（simulated run），實際時間會依實作而異。

術語:DOM (Document Object Model)i

✕

confidence score

信心分數

Jev 對某個選項給出的機率值，用來表示它對該答案的把握程度。

它就是第 2 段機率分佈裡單一選項的那個數字。因為 Jev 的訓練目標是校準（見第 1 段），這個數字可以被當成真實的可信度來用：高於某個門檻就自動執行、落在灰色地帶就交人、低於門檻就放行或拒絕。作者說「你可以圍著它寫業務邏輯」指的就是拿這個數字當 if/else 的條件——這是 Jev 跟只回一個標籤的模型最大的差別。

相關術語: probability distribution (其中一個值)、calibration (前提)

出處：第 3 段「機率分佈解鎖的新用途」

✕

DOM (Document Object Model)

網頁文件物件模型

瀏覽器把 HTML 解析成的樹狀結構，每個按鈕、輸入框、文字都是一個節點，agent 操作網頁就是在這棵樹裡挑節點。

真實網站的 DOM 往往非常龐雜：巢狀十幾層、class 名是編譯後的亂碼、幾十個 script 標籤、還有看不見的 tracking 元素。agent 要「點搜尋按鈕」得先在幾百個節點裡找出對的那個。把整棵樹丟給大模型有兩個問題：吃掉大量 context、且模型要「生成」一個 selector，很容易產生不存在的元素。所以 Browser Use 的做法是先把可互動的節點列成清單，再讓 Jev 在清單中挑。

相關術語: Browser Use (操作對象)、context window (容易撐爆)

出處：第 3 段「機率分佈解鎖的新用途」

✕

Browser Use

Browser Use（開源瀏覽器 agent 框架）

一個讓 AI agent 操作瀏覽器的開源框架，已把 Jev 整合進決策步驟。

它的流程在影片中是：把任務描述、到目前為止的互動歷史、以及當前頁面可互動的 DOM 元素清單一起送給 Jev；Jev 只回答兩層選擇題——動作類型（click／type／…）與目標元素——各附機率；決定後若需要打字，再叫一個小型語言模型產生要輸入的文字。這樣大模型只在真的需要生成時才被呼叫，整體更快也更便宜。

相關術語: Jev (整合於決策步)、DOM (Document Object Model) (讀取)

出處：第 3 段「機率分佈解鎖的新用途」

✕

internal link mapping

內部連結對映

SEO 做法：判斷網站內哪些頁面應該互相連結，讓相關頁面串起來以提升排名。

要做好這件事，模型得讀完網站上幾百頁的內容，再對每一對頁面判斷「A 該不該連到 B、用什麼錨點」，這是典型的「量大、每題小」任務。用生成式大模型逐頁推理，幾百頁乘上每次數千 token，時間與費用都很高；Jev 把每一題變成選擇題（這頁該連到哪幾個目標？），每次呼叫只要幾百 token，所以 500 多頁可以在一分鐘內跑完。作者也提到 AEO（Answer Engine Optimization，針對 AI 搜尋引擎的優化），需求相同。

相關術語: Jev (適合的批次任務)

出處：第 3 段「機率分佈解鎖的新用途」

留給下一段 這些用途聽起來都是「給 Jev 一組選項、它回機率」，那實際上 API 要怎麼呼叫、問題要怎麼寫成 Jev 能答的形式？作者接著拆 API 的形狀。

4. 怎麼呼叫：state ＋三種問題 4:46–6:31

呼叫 Jev 很像大模型的 structured outputi：傳一個 prompt（Jev 叫它 statei）加一組 questions。以客服單為例：問題是「哪個部門處理」，附上決策指引與選項清單，每個選項可加描述，Jev 回每個選項的機率。問題有三種：多選題i（部門路由）、true/false（每個使用者輸入先問「這是 jailbreak 嗎」，拿到機率再寫業務邏輯）、score（給貼文一個 organic 分數，選項從「clearly manipulated」到「clearly organic」，每加一個選項 index 加一，最後得到一個分數）。

承上 承接上一段留下的問題：那些用途都是「給 Jev 一組選項、它回機率」，實際的 API 要怎麼呼叫、商業問題要怎麼寫成 Jev 能答的形式。

推理因為上一段的用途都需要把任務轉成選擇題，所以作者這段從讀者熟悉的東西類比進來：呼叫 Jev 很像大模型的 structured output——傳一段 prompt（Jev 叫它 state）加一組 questions。他先用客服單當範例把請求與回應的形狀走一遍（問題「哪個部門處理」、指引、選項清單、每個選項可加描述、回傳每個選項的機率），再把問題歸納成三種型別：多選（部門路由）、true/false（每個使用者輸入先問「這是 jailbreak 嗎」拿機率再寫業務邏輯）、score（給貼文一個 organic 分數，選項從 clearly manipulated 排到 clearly organic，每多一個選項 index 加一，最後得到一個分數）。三種型別剛好對應上一段三類用途：路由、守門、排序。

• C呼叫 Jev = 一份 state ＋ 一組 question；每題有 type、instructions、criteria→ 畫地圖
• R三種問題型別與典型用途→ 存＋回想
• A呼叫 Jev 很像大模型的 structured output→ 批判類比
• Ascore 題是把有序選項當刻度做機率加權平均→ 批判類比
• P把一個商業判斷寫成 Jev question→ 練習

AI 補充畫面上的 JSON 把作者口頭省略的細節補齊了：一個 question 是一個具名的鍵（例如 department），裡面有 type（choice／score／true-false）、instructions（給模型的判斷指引）與 criteria（選項）；choice 型的 criteria 是「選項名 → 描述」的字典，score 型則是有序陣列，每個選項有 summary 與 signals（判斷特徵）。這個 signals 欄位很重要但作者沒講：它就是你把領域知識塞進去的地方——「rates far off、bot replies」告訴模型什麼叫 clearly manipulated。另外 score 型「index 加一、最後給一個分數」的意思是：Jev 仍然對四個選項各回機率，最終分數是把選項當 0、1、2、3 的刻度做機率加權平均，所以它是一個連續值，不是四選一；順序因此有意義，選項必須從一端排到另一端。畫面右側也顯示一次呼叫只花 0.38 秒。true/false 本質上是只有兩個選項的 choice，作者分開講是因為它的典型用法不同——每個輸入都問一次、拿機率當守門門檻。

術語:question (Jev)itrue/false questioniscore questionijailbreak / prompt injectioniorganic vs paid engagementi

✕

structured output

結構化輸出

要求大模型依指定 JSON schema 回傳結果的功能，讓程式可以直接讀取欄位而不必解析自然語言。

作者拿它當類比：用過 structured output 的人會覺得呼叫 Jev 很熟悉，因為同樣是「給一個 schema（問題與選項），拿回填好的欄位」。差別在大模型的 structured output 是「生成」一份符合 schema 的 JSON，仍然逐 token 產生、仍然可能填錯；Jev 則是對每個既定選項打分數，不會生出 schema 以外的值，也附帶每個值的機率。

相關術語: Jev (類比對象)

出處：第 4 段「怎麼呼叫：state ＋三種問題」

✕

state

狀態（Jev 對輸入內容的稱呼）

呼叫 Jev 時傳入的情境資料，相當於大模型的 prompt 內容，例如一張客服單的原文或一則貼文的數據。

叫 state 而不叫 prompt，是在強調它描述的是「當下的情況」而不是「指令」：指令寫在 question 的 instructions 裡，state 只放要被判斷的東西。這個分離讓同一份 state 可以一次問多個 question（哪個部門、是否緊急、是否 jailbreak），也讓 state 可以由程式自動組裝（Browser Use 就是把任務、互動歷史、DOM 清單組成 state，見第 3 段）。它受 32K context window 限制（見第 2 段）。

相關術語: question (Jev) (搭配)、context window (受限於)

出處：第 4 段「怎麼呼叫：state ＋三種問題」

✕

question (Jev)

問題（Jev 的判斷單位）

對 state 要 Jev 回答的一道題，含型別、判斷指引與選項；Jev 對每個選項回機率。

畫面上一個 question 是一個具名鍵，內含 type、instructions、criteria 三部分。criteria 在 choice 型是「選項名 → 描述」，在 score 型是有序的選項陣列，每個選項可附 summary 與 signals（判斷特徵）。設計 question 的功夫其實跟寫 prompt 一樣：選項要互斥且涵蓋所有情況，描述要能區分邊界案例。

相關術語: state (作用於)、choice question (型別之一)、true/false question (型別之一)、score question (型別之一)

出處：第 4 段「怎麼呼叫：state ＋三種問題」

✕

choice question

多選題

從多個具名選項中挑一個的問題型別，Jev 回每個選項的機率，典型用途是路由。

客服單分派到 billing／technical／sales 就是這種。因為回的是整個分佈，你不只拿到最高的那個，還知道第二名差多遠——兩個部門機率接近時，可以視為「模糊案例」交人判斷，這是單純分類器做不到的。

相關術語: question (Jev) (一種)

出處：第 4 段「怎麼呼叫：state ＋三種問題」

✕

true/false question

是非題

只有 true／false 兩個選項的問題，Jev 回 true 的機率，典型用途是守門（例如判斷是否 jailbreak）。

本質上是兩選項的 choice，但用法不同：它通常對「每一個進來的請求」都問一次，拿到的機率當門檻用。因為 Jev 便宜又快（見第 2 段），對每個使用者輸入多打一次 Jev 在成本上可以接受，這是用大模型當守門員做不到的。

相關術語: question (Jev) (一種)、jailbreak (典型用途)

出處：第 4 段「怎麼呼叫：state ＋三種問題」

✕

score question

評分題

選項是從一端到另一端的有序刻度，Jev 對每格回機率，再合成一個連續分數。

作者說「每加一個選項 index 加一、最後給一個分數」——意思是把選項當 0、1、2、3…的刻度，用機率加權平均得到最終分數，所以選項的排列順序有意義，必須單調（例如 clearly manipulated → suspicious → probably organic → clearly organic）。它適合排序與排名（哪些 lead 最值得追、哪篇貼文最可疑），而不只是分類。

相關術語: question (Jev) (一種)

出處：第 4 段「怎麼呼叫：state ＋三種問題」

✕

jailbreak / prompt injection

越獄／提示詞注入

使用者用特殊措辭讓模型繞過原本的限制（jailbreak），或在輸入中夾帶指令讓模型改做別的事（prompt injection）。

對開放給大眾的 AI 聊天平台這是每天都會遇到的攻擊。用大模型自己判斷「這是不是攻擊」有兩個問題：貴（每個請求多一次大模型呼叫）、而且判斷的模型自己也可能被同一段文字注入。Jev 不生成文字、不逐步推理，只回機率，天生比較不會被「請忽略以上指示」這類文字帶著走，又便宜到可以每個請求都問。

相關術語: true/false question (用它偵測)

出處：第 4 段「怎麼呼叫：state ＋三種問題」

✕

organic vs paid engagement

自然互動 vs 付費灌流量

貼文的按讚、留言、瀏覽是真實使用者自發產生（organic），還是靠廣告、買互動或 bot 撐出來（paid／boosted）。

畫面上作者用的訊號是互動比率（views_per_follower、留言與讚的比例）與留言品質（bot replies vs real replies）：比率偏離常態太多、回覆像機器人，就往 manipulated 那端；比率普通、回覆像真人，就往 organic。這是 score 型問題的示範，也是後面作者自己要用的判斷。

相關術語: score question (用它評分)

出處：第 4 段「怎麼呼叫：state ＋三種問題」

留給下一段 三種問題都回機率，作者反覆說「拿到機率之後可以在上面寫業務邏輯」——具體要怎麼寫？門檻怎麼訂？又怎麼引導 Jev 往你要的方向判斷？作者接著給出決策樹與引導技巧。

5. 用信心分數寫決策樹、用描述引導答案 6:31–7:58

信心分數是 Jev 的關鍵特色，讓你在上面蓋自己的業務邏輯提高可靠度。以 prompt injection 為例：危險分數 > 70% 自動擋、35–70% 交人工審、其餘正常放行。引導技巧：每個問題可只給簡短描述，也可給很詳細的描述，選項裡還能放範例，接近 few-shot promptingi。同一張「匯出按鈕重複扣款、發票錯誤」的單子，指引只寫「哪個團隊處理」會路由到 billing；加上「路由給能修根因的人」就會轉到 technical。

承上 承接上一段留下的兩個問題：拿到機率之後業務邏輯具體怎麼寫、門檻怎麼訂；以及怎麼引導 Jev 往你要的方向判斷。

推理因為上一段三種問題都只回機率，所以作者先示範怎麼把機率變成動作：以 prompt injection 為例畫一棵決策樹——危險分數 > 70% 自動擋、35–70% 交人工審、其餘照常放行，說明「圍著信心分數寫業務邏輯」的具體形狀是分層門檻，把「機器很確定」「機器不確定」「機器確定沒事」三種情況分派給不同的處理者。接著他處理第二個問題：怎麼讓 Jev 答得更準、更貼近你的意圖——每個問題可以只給簡短描述，也可以給很詳細的描述，選項裡還能放範例，接近 few-shot prompting。他用同一張「匯出按鈕重複扣款、發票錯誤」的客服單證明指引會改變答案：只寫「哪個團隊處理」會路由到 billing，加上「路由給能修根因的人」就轉到 technical——選項描述與指引就是你把公司自己的判斷標準交給 Jev 的地方。

• C分層門檻：機器很確定 → 自動；不確定 → 交人；確定沒事 → 放行→ 畫地圖
• E門檻 0.70／0.35 來自 TypeSafe cookbook 的 strict policy（jev-1.12），不是通用常數→ 存＋演練
• P建信心分數決策樹並用自己的資料校門檻→ 練習
• C選項當 rubric：what／not_for／examples，把分派 SOP 寫進選項而不是長 prompt→ 畫地圖
• E同一張重複扣款單：指引「哪個團隊處理」→ billing；「路由給能修根因的人」→ technical→ 存＋演練
• P把每個選項寫成 what / not_for / examples→ 練習

AI 補充畫面上的決策樹比口頭版更完整，值得補三點。第一，它不是對單一「jailbreak」問，而是一次呼叫同時回多個危害維度（jailbreak、harmful、medical、self_harm）加一個 severity 分數——這就是上一段說的「同一份 state 問多個 question」；樹的第一層是「任何一個危害 ≥ 0.70？」，是的話走那個危害自己的動作（block／review／support），且 severity ≥ 2 會把 review 升級成 block；否則再問「任何一個 ≥ 0.35？」→ review，否則 pass。第二，門檻 0.70／0.35 不是通用常數，畫面註明是「TypeSafe cookbook 的 strict policy、jev-1.12」——你應該用自己的資料回頭校驗：把一批已知標籤的案例跑過，看每個門檻區間的實際錯誤率，再依人工審查的容量調整灰色地帶的寬度。第三，引導技巧的畫面標題是 OPTIONS AS RUBRICS：每個選項有 what（涵蓋什麼）、not_for（不該歸這裡的邊界案例）、examples（範例句），其中 not_for 是最有力的欄位——「billing 不處理 bug 造成的錯誤扣款」正是讓那張重複扣款的單子從 billing 轉到 technical 的關鍵，因為它直接描述了兩個選項的交界。這等於把公司內部的分派 SOP 寫進選項，而不是寫進一段長 prompt。

術語:decision tree on confidenceihuman-in-the-loopirubric (option description)i

✕

decision tree on confidence

以信心分數分層的決策樹

依機率高低把案例分派到不同處理路徑（自動執行／人工審查／放行）的規則結構。

這是把 Jev 校準過的機率轉成動作的標準寫法：高於上門檻的機器自己處理、介於兩個門檻之間的交人、低於下門檻的放行。它的價值在於把人工只花在「機器不確定」的那一小塊，而不是全部人工或全部自動。門檻該多寬取決於兩件事：錯放一個的代價，以及人工審查的容量；用自己的歷史資料校驗門檻是必要步驟，不要直接抄影片裡的 0.70／0.35。

相關術語: confidence score (以它為條件)、human-in-the-loop (中間路徑)

出處：第 5 段「用信心分數寫決策樹、用描述引導答案」

✕

human-in-the-loop

人工介入

流程中保留一段由人來審查或決定的環節，通常只放模型不確定的案例。

在 Jev 的決策樹裡它是中間那條路（35–70%）。跟傳統「全部人工看一遍」的差別是：人只看灰色地帶，量可能只有原本的一兩成。它也是校準能發揮價值的地方——如果模型的機率不可信，灰色地帶就會抓不到真正該看的案例，人工反而白費。人工的判斷結果還可以回頭當標籤，用來檢驗與調整門檻。

相關術語: decision tree on confidence (實作於)

出處：第 5 段「用信心分數寫決策樹、用描述引導答案」

✕

few-shot prompting

少量範例提示

在指令裡附上幾個「輸入 → 正確答案」的範例，讓模型照樣判斷。

作者說在 Jev 的選項描述裡放 examples「幾乎就是 few-shot prompting」。差別在位置：大模型的 few-shot 是放在 prompt 裡的幾段範例對話；Jev 是把範例放進「該選項」底下，等於告訴模型「長這樣的就是 billing」。因為範例是綁在選項上的，它比一般 few-shot 更像是給每個類別一份判定手冊。

相關術語: rubric (option description) (實作於)

出處：第 5 段「用信心分數寫決策樹、用描述引導答案」

✕

rubric (option description)

選項的判定規準

每個選項附帶的 what／not_for／examples 描述，告訴 Jev 這個選項涵蓋什麼、不涵蓋什麼、典型長什麼樣。

畫面標題就叫 OPTIONS AS RUBRICS。what 定義涵蓋範圍，examples 給典型句，not_for 描述邊界案例——這一欄最容易被忽略卻最有效，因為分類錯誤幾乎都發生在兩個選項的交界，而 not_for 正是在交界處畫線（「billing 不處理 bug 造成的錯誤扣款」）。把公司的分派 SOP 寫成 rubric，比寫一段長 prompt 更容易維護，也更容易讀出是哪一條規則造成了某個判斷。

相關術語: choice question (附屬於選項)、few-shot prompting (包含範例)

出處：第 5 段「用信心分數寫決策樹、用描述引導答案」

留給下一段 到這裡 Jev 的用法已經齊了：state、三種問題、門檻、rubric。但這些都是「判斷」——判斷要有東西可判斷，那些註冊資料、貼文、公司資訊要從哪裡便宜地抓進來？作者接著用自己公司的真實案例引入第二個角色 Treg。

6. 案例一：詐騙偵測到註冊分析（引入 Treg） 7:58–10:23

作者團隊有兩個產品：Super Design（vibe design 平台）與 Tregi（資料與工具的 open router，接數千個 API），兩者常被 bot 攻擊，甚至在 log 看到 prompt injection。詐騙者一直換 domain，程式規則抓不到，於是每 15–30 分鐘抓一批註冊者與產品使用量丟給 Jev 分類詐騙機率，超過門檻自動封鎖。Treg 整合 3,000 多個資料點（人與公司 enrichment、buying signal 等），只收使用量、0% 加價，同樣 enrich 290 人只要 $1.49 對 Clay 約 $10.3，便宜 85%。後來把詐騙偵測擴成完整的註冊分析：Treg 驗證 email 並 enrich → 合併產品使用量 → Jev 分類成詐騙／可升售i／聯盟或網紅，一天約 $1 掃數百筆註冊，觸發不同的 outreach 或封鎖。

承上 承接上一段留下的問題：Jev 只負責判斷，那要被判斷的註冊資料、使用者資訊要從哪裡便宜地抓進來？作者用自己公司真正在跑的第一條管線引入 Treg。

推理因為前面已經把 Jev 的用法講完，所以作者轉向「真的在生產環境跑的例子」增加說服力。他先交代動機：團隊兩個產品（Super Design、Treg）都常被 bot 攻擊，log 裡甚至看得到 prompt injection；詐騙者一直換 domain，寫死的規則抓不到，所以改成每 15–30 分鐘抓一批註冊者與產品使用量丟給 Jev 算詐騙機率，超過門檻自動封鎖——這就是上一段決策樹的實際版本。接著他順勢引入 Treg：一個接了 3,000 多個資料端點、只收使用量、0% 加價的資料與工具 open router，並用 enrich 290 人 $1.49 對 Clay 約 $10.3 的對照證明它便宜 85%。最後他把兩者合起來推出結論：便宜的判斷（Jev）加便宜的資料（Treg），才讓「把詐騙偵測擴成完整的註冊分析」變得划算——每個註冊先由 Treg 驗證 email 並 enrich，合併使用量丟給 Jev 分類成詐騙／可升售／聯盟或網紅，一天約 $1 就能掃數百筆，觸發不同的 outreach、站內支援或封鎖。

• C單位經濟：判斷已便宜到不是瓶頸，資料的價格才決定管線划不划算→ 畫地圖
• E註冊分析管線每步單價：verify $0.0015、enrich $0.0026–0.03、Jev $0.00008→ 存＋演練
• ETreg vs Clay：290 人 $1.49 vs $10.3（便宜 85%）；precision 91.3% vs 93.6% 略輸→ 存＋演練
• A寫死規則抓特徵、Jev 看整體樣貌，所以換 domain 騙不過 Jev→ 批判類比
• RTreg：3,000 多個資料端點、只收使用量、0% 加價→ 存＋回想
• R詐騙偵測每 15–30 分鐘跑一批→ 存＋回想

AI 補充三個作者沒展開、但畫面有的細節。第一，管線的單價：畫面寫 email → treg verify（$0.0015）→ treg person enrich（$0.0026–$0.03）→ jev（$0.00008）→ {segment, is_fraud, upsell_value}。可以看到 Jev 那一步的成本幾乎可以忽略，整條管線的錢都花在資料抓取上——這解釋了為什麼作者強調「Jev 加 Treg」而不只是 Jev：判斷已經便宜到不是瓶頸，資料的價格才決定單位經濟i成不成立。第二，作者說 Treg「準確度相近甚至更好」，但他自己貼出的對照表更微妙：找到人數 289 vs 280、地址精確比對 90.4% vs 89.7% 是 Treg 略勝，但 precision 91.3% vs 93.6% 是 Clay 略勝，所以「差不多」成立，「更好」要看你看哪個指標；真正拉開差距的是成本（每列 $0.0051 vs $0.0354）與延遲（命中中位數 0.44 s vs 11.2 s）。第三，為什麼寫死規則抓不到詐騙：規則是對「特徵」寫的（某個 domain、某種 email 格式），攻擊者改特徵就繞過；Jev 是對「整體樣貌」判斷（註冊資訊加產品使用行為），改單一特徵不容易騙過，而且改判斷標準只要改 rubric，不用改程式。另外「Jev 輸出 segment、is_fraud、upsell_value」正是上一段「同一份 state 問多個 question」的實際用法：一次呼叫同時得到分類與兩個分數。

術語:data enrichmentiusage-based pricingi

✕

Treg

Treg（資料與工具的 open router）

作者團隊的產品：一個統一介面接上數千個資料與工具 API，只依使用量計費、0% 加價。

畫面上的標語是 OpenRouter for agent tools——OpenRouter 是把許多 LLM 放在同一個 API 後面的服務，Treg 做同樣的事但對象是資料端點：人與公司 enrichment、email 驗證、LinkedIn／Twitter 貼文、職缺、buying signal 等 3,000 多個資料點。對自動化來說它解決的是「資料太貴」：影片中同樣 enrich 290 人，Treg $1.49 對 Clay 約 $10.3。在作者的架構裡它負責「抓」，Jev 負責「判」，兩者都便宜到可以每 15–30 分鐘掃一次。

相關術語: Jev (搭配)、data enrichment (提供)、usage-based pricing (計費方式)

出處：第 6 段「案例一：詐騙偵測到註冊分析（引入 Treg）」

✕

data enrichment

資料充實（補齊人／公司背景）

拿一個 email 或名字去查出職稱、公司、規模、社群檔案等背景資訊，讓一筆註冊變成可判斷的完整輪廓。

註冊表單本身只有 email 與幾個欄位，靠這些既判不出詐騙也判不出升售機會。enrichment 把外部資料接上來：這個人是誰、在哪家公司、公司多大、有沒有社群影響力。這是傳統上最貴的一步（Clay 之類的工具以 credit 計費），所以 Treg 把它壓到每人幾分之一美分是這條管線成立的關鍵。enrich 完的資料就是 Jev 的 state（見第 4 段）。

相關術語: Treg (由它提供)、state (成為 Jev 的 state)

出處：第 6 段「案例一：詐騙偵測到註冊分析（引入 Treg）」

✕

usage-based pricing

依用量計費

不收月費或訂閱，每一次 API 呼叫或每一筆資料各自計價。

作者強調 Treg「不收訂閱、依用量、0% 加價」有兩個含意：一是小團隊可以先用幾美元跑實驗，不用先買一個 seat；二是自動化管線的成本可以精確算到每一筆（畫面上每個註冊約 $0.004–$0.03），這樣才能判斷「掃幾百個註冊一天 $1」划不划得來。與 Jev 的每次呼叫計費是同一邏輯，所以兩者合起來整條管線的單位成本可以直接相加。

相關術語: Treg (採用)、unit economics (讓其可計算)

出處：第 6 段「案例一：詐騙偵測到註冊分析（引入 Treg）」

✕

unit economics

單位經濟

做一單位工作（處理一筆註冊、篩一個 lead）的成本與它帶來的價值是否划得來。

這是全片的核心論點：很多自動化不是技術上做不到，而是每一筆的成本高於價值。用大模型逐筆判斷加上傳統 enrichment，一筆可能要幾十美分，掃幾百筆註冊找幾個升售機會就不值得；把判斷壓到 $0.00008、資料壓到幾分之一美分後，同一條流程變成一天 $1，單位經濟就翻過來了。看自動化該不該做，先算這個數字。

相關術語: usage-based pricing (前提)、Jev (壓低判斷成本)、Treg (壓低資料成本)

出處：第 6 段「案例一：詐騙偵測到註冊分析（引入 Treg）」

✕

upsell

升售

向既有使用者推銷更高價的方案或更多功能。

在註冊分析裡，Jev 除了判斷詐騙，還回一個 upsell_value 分數：enrich 出來這個人是某家公司的決策者、公司規模夠大、又有實際產品使用量，就是值得業務主動聯繫的對象。這把原本純防守的詐騙偵測變成同時找機會的流程——同一次呼叫、同一份 state，多問一題就多一個用途。

相關術語: data enrichment (依據)

出處：第 6 段「案例一：詐騙偵測到註冊分析（引入 Treg）」

見仁見智 9:17

「track is achieving similar even better accuracy」

「更好」要看指標。作者自己貼出的 Treg vs Clay 對照表：找到人數 289 vs 280、地址精確比對 90.4% vs 89.7% 是 Treg 略勝，但 precision 91.3% vs 93.6% 是 Clay 略勝。「差不多」成立，「更好」不全面；明確拉開差距的是成本（每列 $0.0051 vs $0.0354）與延遲（0.44 s vs 11.2 s）。

依據: 影片 9:15 處作者於 2026-09-16 發表的 Treg vs Clay 對照表（frames/s06_555.jpg）

留給下一段 作者說這種工作流「在 Jev 與 Treg 出現前單位經濟就不成立」——那除了對內的註冊分析，同樣的「Treg 抓訊號 → Jev 篩選」還能往外用在哪？作者接著講第二個案例：找買家意圖。

7. 案例二：買家意圖的 lead 篩選 10:23–11:53

這種工作流在 Jev 與 Treg 出現前，單位經濟就不成立。第二個案例找高買意圖的 lead：用 Treg 抓某垂直領域（如 enrichment）的熱門 LinkedIn 貼文，再抓互動、留言的人，因為那些人可能是買家；全部丟給 Jev 做資格審查、評分、分 personai 與角色，只有排名前段的才進正式 enrichment 拿聯絡方式。分析 20 篇貼文、近 400 個 lead 幾乎不用錢。作者延伸：公司在 LinkedIn 發職缺配對候選人庫、職缺趨勢等，Treg 對每種訊號都有端點，讓 Claude Code／Codex 寫抓取腳本很容易，創意在於你設計的 filter → qualify → reachi 流程。

承上 承接上一段留下的問題：同樣的「Treg 抓訊號 → Jev 篩選」除了對內的註冊分析，還能往外用在哪——這段把它轉向對外找買家。

推理因為上一段已證明「便宜的資料＋便宜的判斷」讓對內的註冊分析划得來，所以作者把同一個模式轉向對外的業務開發：先點明這類工作流在 Jev 與 Treg 之前單位經濟不成立，再走一遍第二條管線——用 Treg 抓某個垂直領域（例如 enrichment）的熱門 LinkedIn 貼文，再抓在底下互動、留言的人（會對這主題互動的人可能就是買家），全部丟給 Jev 做資格審查、評分、分 persona 與角色，只有排名前段的才進正式 enrichment 拿聯絡方式；分析 20 篇貼文、近 400 個 lead 幾乎不花錢。接著他把這個案例抽象成一個可複製的模板：Treg 對每種 buying signal 都有端點（LinkedIn 發職缺的公司、職缺趨勢……），叫 Claude Code／Codex 寫抓取腳本很容易，所以真正的創意在你怎麼設計 filter → qualify → reach 的流程。

• Cfilter → qualify → reach：便宜的判斷放前面、貴的資料抓取放後面→ 畫地圖
• ELead 漏斗：20 篇貼文 → 3 篇 on-topic → 80 人 → 56 決策者／24 使用者 → 前 16 找 email 命中 13→ 存＋演練
• P設計一條 filter → qualify → reach 管線→ 練習

AI 補充作者說「成本幾乎為零」，畫面上的儀表板把漏斗與每一步的錢都攤開了，值得看清楚。整條管線是 Relevant LinkedIn post commenters → Jev qualify and score → Treg enrich，分析 20 篇貼文、80 個人，Jev 花 $0.00273、Treg 花 $0.280；整批 368 人排名完 Jev 只用 42.8 秒、$0.013，Treg $0.87。漏斗是：Treg search ×4 抓到 20 篇貼文 → Jev「on topic」×20 只留 3 篇 ≥ 0.70 → Treg 抓這 3 篇的 80 個互動者 → Jev rank ×80 分出 56 個 decision maker（fit ≥ 1.5：heads、VPs、founders）、24 個 user（fit ≥ 0.8：growth／ops／data 的 IC）、0 個 not a lead → 只對前 16 個做 Treg email find，找到 13 個（81%）。兩點作者沒明說：第一，Jev 在這裡被用了兩次而且是不同題型——先用 true/false 式的「這篇貼文跟主題有關嗎」把 20 篇濾到 3 篇，避免抓不相關貼文的互動者浪費 Treg 的錢；再用 score 式的 fit 分數對人排序。第二，最貴的一步（email find，每次命中約 $0.02）被放在漏斗最尾端、只對前段做，這就是「Jev 便宜所以先篩、Treg 相對貴所以後抓」的排序原則——花錢的動作永遠放在便宜的判斷之後。另外儀表板的每一個 Jev／Treg 步驟都有 fit 門檻（0.70、1.5、0.8），跟第 5 段的決策樹是同一個想法。

術語:buyer intentilead qualificationi

✕

buyer intent

買家意圖

某人近期行為顯示他正在考慮購買某類產品的訊號，例如在該主題的貼文下留言、互動。

傳統名單是照職稱與公司規模抓的（誰「應該」會買），buyer intent 是照行為抓的（誰「正在」關心這件事）。作者選的訊號是「在 enrichment 主題的熱門 LinkedIn 貼文下互動的人」——會主動評論這主題的人，比名單上的人更可能正在評估工具。Treg 的角色是把這些行為訊號抓下來，Jev 的角色是判斷這個互動者是不是真正的買家。

相關術語: lead qualification (作為依據)、Treg (抓取來源)

出處：第 7 段「案例二：買家意圖的 lead 篩選」

✕

lead qualification

潛在客戶資格審查

判斷一個潛在客戶是否值得業務投入時間：角色對不對、公司對不對、意圖夠不夠強。

在畫面上這一步由 Jev 做，輸出是一個 fit 分數加一個 persona（decision maker／user／not a lead）——同時是 score 型與 choice 型問題。傳統上這一步要人看 LinkedIn 檔案一個一個判斷，或是用大模型逐個推理，都貴；Jev 每個人 $0.00003，368 人 42.8 秒排完。qualification 放在 enrichment 之前的意義是：只有過關的人才值得花錢查聯絡方式。

相關術語: buyer intent (依據)、score question (用它評分)、persona (輸出之一)

出處：第 7 段「案例二：買家意圖的 lead 篩選」

✕

persona

人物類型（角色分類）

依職務把 lead 分成幾種典型角色，例如決策者、實際使用者、非目標，之後用不同方式接觸。

畫面上 Jev 把互動者分成 founder／exec、GTM ops、engineer、vendor，再依 fit 門檻歸成 decision maker（heads、VPs、founders）、user（growth／ops／data 的 IC）與 not a lead（學生、招募者、代理商、供應商）。分 persona 的目的不是排除，而是決定後續動作：對決策者談價值與價格，對使用者談功能與試用，對供應商不追。這是第 4 段 choice 型問題在業務流程裡的典型用法。

相關術語: lead qualification (輸出)、choice question (用它分類)

出處：第 7 段「案例二：買家意圖的 lead 篩選」

✕

filter → qualify → reach

篩選 → 審查 → 接觸

作者對這類自動化的三步模板：先用便宜的判斷把大量訊號濾小，再對留下的做資格審查與排序，最後只對前段花錢取得聯絡方式並接觸。

這是把兩個案例抽象後的通式，也是成本排序的原則：每一步都用 Jev（幾乎免費）決定下一步 Treg（相對貴）要不要花錢。在 lead 案例裡是 20 篇貼文 → 3 篇 → 80 人 → 56 個決策者 → 16 個查 email；在註冊分析裡是所有註冊 → 非詐騙 → 有升售價值 → 業務接觸。作者說創意在於你怎麼設計這三步，因為抓資料的腳本讓 Claude Code／Codex 寫就好。

相關術語: unit economics (為了它排序)、buyer intent (第一步的訊號)

出處：第 7 段「案例二：買家意圖的 lead 篩選」

留給下一段 作者把團隊的工作流放在 treg.to/jev 並邀請觀眾分享自己的流程——但他還有一個更貼近自己日常痛點的案例：每週看到的百萬曝光產品發表，哪些是真的？接著講第三條管線。

8. 案例三：篩掉付費灌流量的爆紅貼文 11:53–13:34

團隊做的工作流已放在 treg.to/jev，每個都附可貼進 Claude Code 的 prompt。第三個案例是 viral 貼文篩選：作者看到有人用 Jev 即時分類 Twitter 上的 AI 生成內容，聯想到自己的需求——身為 AI 創業者，每週看到百萬曝光的產品發表，很多是付費灌流量而非真實訊號。管線：Treg 抓過去 24 小時的熱門貼文、數據與留言 → Jev 篩出跟產品發表有關的 → 分類 organic 或 paid/boosted 並濾掉噪音，每天得到一份值得學習的趨勢清單。同一管線做成免費工具：貼任何 Twitter 貼文連結，就抓貼文、作者檔案、回覆，讓 Jev 判斷 organic 或 paid 並附完整理由。

承上 承接上一段留下的線索：團隊的工作流已放在 treg.to/jev，而作者還有一個更貼近自己日常痛點的案例——每週看到的百萬曝光產品發表哪些是真的。

推理因為上一段已把模式抽象成 filter → qualify → reach，所以作者先交代資源（treg.to/jev 上每條工作流都附一段可貼進 Claude Code 的 prompt，讓 agent 幫你把 Treg 與 Jev 接起來寫腳本），再用第三條管線示範同一模式可以用在「學習」而非業務：他看到有人用 Jev 即時分類 Twitter 上的 AI 生成內容，聯想到自己身為 AI 創業者的需求——每週看到百萬曝光的產品發表，很多是付費灌流量而非真實訊號，他只想學那些真正引起共鳴的。管線是 Treg 抓過去 24 小時的熱門貼文、數據與留言 → Jev 篩出跟產品發表有關的 → 再分類 organic 或 paid/boosted 並濾掉噪音，每天得到一份值得學的趨勢清單。最後他把同一條管線做成免費工具：貼任何 Twitter 貼文連結，抓貼文、作者檔案、回覆，讓 Jev 判斷 organic 或 paid 並附完整理由——這正是第 4 段 score 題那個 organic 分數的實際產品化。

• EViral 篩選用互動率當 state：paid 例子 likes 0.15%、generic 回覆 11%、reposts 0→ 存＋演練
• R資源：treg.to/jev 有 recipe 與可貼進 Claude Code／Codex 的 prompt→ 存＋回想

AI 補充畫面上的儀表板把「用什麼判斷 organic」講清楚了，這是作者口頭沒說的。管線 Viral X posts & comments → Jev classify，2026-09-19 那次跑：Treg search ×13 抓到 168 篇 24 小時內的貼文、Treg profiles ×162 抓作者的追蹤數／簡介／是否驗證、Treg reply samples ×168 各抓前 20 則回覆，然後 Jev judge ×60、每篇問 5 個問題，60 篇 169 秒判完，Treg $0.105、Jev $0.017。結果 64 篇裡 organic launch 18、paid launch 5、irrelevant 41（其中 8 篇是別種發表、33 篇根本不是發表）。每張卡片底下列的訊號就是 Jev 的 state：各種互動率（likes、replies、reposts、bookmarks、quotes 各佔瀏覽數的百分比）與回覆中「generic」留言的比例——organic 的例子 likes 0.31%、generic 0%，paid 的例子 likes 0.15%、generic 11%、reposts 0.000%；每篇同時得到 organic／paid reach 機率、authenticity 分數（x/3，就是第 4 段那個四格 score 題）與產品類型。兩個可學的設計：第一，先抓回覆樣本再判斷，因為付費灌流量最露餡的地方是留言像機器人、轉推為零；第二，「irrelevant 41」這個桶說明篩噪音跟分類是同一次呼叫裡不同的 question，不用先跑一個模型過濾再跑另一個。要注意這套判斷是啟發式的：互動率低也可能是內容本身不吸引人而非付費，所以工具附上 full reasoning 讓人自己再看一眼是必要的。

術語:viral post screeningiengagement rate signalsinoise filteringi

✕

viral post screening

爆紅貼文篩選

從一段時間內的高曝光貼文裡，自動分出哪些是真實引起共鳴、哪些是付費或 bot 撐出來的。

這是第 4 段 organic vs paid 判斷的完整流程版。輸入不只貼文本身，還有作者檔案（追蹤數、是否驗證）與回覆樣本，因為單看曝光數分不出來，要看互動的「形狀」：各種互動率跟追蹤數的比例、回覆是不是通用留言。作者的用途是每天篩出一份值得學習的產品發表清單，也做成貼連結就能判斷的免費工具。

相關術語: organic vs paid engagement (判斷目標)、engagement rate signals (依據)

出處：第 8 段「案例三：篩掉付費灌流量的爆紅貼文」

✕

engagement rate signals

互動率訊號

把 likes、replies、reposts、bookmarks、quotes 各除以瀏覽數（或追蹤數）得到的比例，以及回覆中通用留言的佔比。

畫面上每篇貼文卡片底下就是這組數字。真實爆紅的貼文各項比例大致落在常見範圍，轉推與書籤不會是零；買曝光的貼文瀏覽數很高但按讚、轉推比例異常低，回覆裡「great!」之類的通用留言比例高。這些比例會作為 state 交給 Jev，rubric 裡的 signals（見第 4 段的 rates far off、bot replies）就是在描述這些訊號的樣態。它是啟發式的，低互動也可能只是內容不好，所以要保留理由讓人複核。

相關術語: viral post screening (輸入)、state (組成 state)

出處：第 8 段「案例三：篩掉付費灌流量的爆紅貼文」

✕

noise filtering

噪音過濾

在分類之前（或同一次呼叫中）先把跟任務無關的項目挑掉，例如不是產品發表的爆紅貼文。

畫面上 64 篇裡有 41 篇被歸到 irrelevant——不是產品發表就不進 organic／paid 的判斷。作者的做法是把「這是不是發表」當成同一次 Jev 呼叫裡的一個 question，而不是先跑另一個模型過濾。這跟第 7 段先用 on-topic 濾貼文是一樣的原則：便宜的判斷放前面，避免對無關項目花後續的錢或注意力。

相關術語: viral post screening (其中一步)、filter → qualify → reach (對應 filter)

出處：第 8 段「案例三：篩掉付費灌流量的爆紅貼文」

留給下一段 三條管線都示範完，作者回到開頭的兩個弱點（信心與單位經濟）收尾，並交代資源在哪。

4. 總結

作者先把「大模型做不了商業自動化」拆成兩個獨立變數：不可信（RLHF 帶來的過度自信、沒有校準）與不划算（逐 token 生成又慢又貴）。Jev 用 reinforcement learning for calibrated decisions 訓練、只在給定選項中分配機率、不生成文字，因此一次呼叫就能回校準過的信心分數，且比最便宜的大模型快 5–7 倍。這個「附機率的選擇」解鎖了即時決策、瀏覽器操作（Jev 選元素、小模型生文字）與大量批次任務。呼叫形狀是 state ＋ 三種 question（choice／true-false／score），拿到機率後用分層門檻（≥ 0.70 自動、0.35–0.70 交人、其餘放行）寫業務邏輯，並用 what／not_for／examples 的 rubric 把公司的分派標準寫進選項。最後作者用 Treg（3,000+ 資料端點、0% 加價）補上「便宜的資料」這一半：詐騙偵測→註冊分析、買家意圖 lead 篩選、viral 貼文 organic/paid 判斷三條管線都遵守同一模板——便宜的判斷放前面、貴的資料抓取放後面（filter → qualify → reach），讓以前單位經濟不成立的自動化一天只要約 $1。

勘誤總整理

確定錯誤／已過時見仁見智（取決於版本或情境）

5. 推薦三個下一步