實戰範例 002：一句指令，分類數千筆資料

背景：什麼任務適合

用一句話判斷：任務數量非常大，而且每一筆資料都在問同一個問題。

符合這個特徵的任務，以前用大模型逐筆跑是「做不起」的——慢又貴；交給 Jev 批次處理，成本可以壓到幾美分、時間壓到幾十秒。反之，如果每筆資料要問的問題都不一樣、或需要深入推理，那就不適用。

先看看影片整理的實測規模¹：

（對照：同一份留言任務若交給 Opus 5 跑，影片實測是 34 分鐘、$23，還有遺漏。）

通用流程

① 準備 state        → 把資料整理成文字或結構化欄位（CSV / JSON）
② 定義題目          → Choice：屬哪一類？ Score：給幾分？ Noul：是否成立？
③ 一句指令給 Claude → 讓 Claude 依 TypeSafe skill 寫出批次呼叫與彙整
④ 輸出與後處理      → CSV / Excel / dashboard；門檻與排名在程式端決定

情境 A：分類（Choice 題型）

以留言分類為例，給 Claude 的指令可以長這樣：

請使用 TypeSafe skill，把 data/comments.csv 裡的每一則留言
分類成五類：正面、負面、產品建議、未回覆的問題、已回覆過的問題。
用 Jev 批次處理（注意 API 的 context 與速率限制，分批並行），
最後輸出 results.csv，並產生一份分類統計的 dashboard。
題目定義與門檻放在 jev.yaml，方便我調整。

實作要點：

• 選項要互斥且窮盡：分類題的選項就是 Choice 題的 criteria；若有「以上皆非」情境，記得放一個 catch-all 選項。
• 一次呼叫多題：同一批資料的多個判斷可以打包進同一請求平行評估（speculative fan-out），比逐筆呼叫便宜且快得多²。
• 批次與並行：幾千筆資料要切成多個請求分批送出，注意 API 速率限制（官方 SDK 預設會處理重試³）。

情境 B：打分（Score 題型）

適合「排序與篩選」而不是「非黑即白」的場景：

• 潛在客戶意向：先問兩個核心條件（是不是決策者？人在不在美國？），再加上一套簡單評分規則。
• 會員流失風險：以加入天數、發文量、最後登入時間、留言互動數、活動參與次數為 state，每人打 1–10 分；匯出 Excel 時依風險高低自動標色。
• 內容精華度：見下一節。

實作要點：

• 分數的語意要定義清楚：Score 的每個等級要有具體情境描述，例如「1 = 幾乎不互動且近期未登入」到「10 = 高頻互動核心成員」。
• 排名與門檻留在程式端：Jev 給分，要不要行動由你的門檻決定；調整門檻不需要重跑推論⁴。

情境 C：即時分流

貼文分流（產品回饋／技術問題／業務諮詢／商業合作／自我介紹／成果分享）不只可以批次跑，因為 Jev 反應極快，還能做到毫秒級即時分流：新貼文一進來就判斷類別，自動派給對應負責人（例如技術問題直接轉工程主管）。

創作者加碼：長片精華片段評分

影片作者自己也用這個模式挑短影音素材：

1. 把一小時左右的訪談按語意切成幾百個候選片段。
2. 一口氣丟給 Jev 評「這段適不適合剪成精華」。
3. 拉出排名前 10 的高分片段再人工後製。

作者的做法不是讓 AI 完全取代審美，而是把逐字稿評分當作第二雙眼睛——把自己手挑的名單與 Jev 的高分名單交叉比對，撈回疲勞時漏掉的金句。

把流程封裝成 skill 與排程

流程跑順後，請 Claude 把它封裝成一個 skill；之後遇到同類任務就是一句指令。需要定期執行的（例如每兩週跑一次會員流失風險），再設定排程自動跑——影片案例中，這套流程就是這樣變成例行公事的。

品質與適用判準

• 適用：每筆資料問同一個問題（這張發票是否可疑？這封 Email 是不是垃圾信？這則留言有沒有踩到版規？這張退款申請符不符合資格？）。
• 不適用：需要生成內容、深度推理、或多步驟處置的任務——那些留給 Claude。
• 封閉式分類的準確度：影片指出 Jev 在此類場景不輸大模型；但語言是變數，中文資料務必抽樣人工比對，並留意 confidence 偏低的樣本⁵。
• 先小批試跑：抽 50–100 筆跑一輪，人工檢查過再全量。

驗收清單

• 題目定義（categories / score levels）集中在單一檔案，可審閱。
• 抽樣人工比對通過（例如隨機 50 筆，錯誤率可接受）。
• 全量輸出為乾淨的 CSV / Excel / dashboard。
• 重複性任務已封裝成 skill，可一句指令重跑。