將 System One 模型整合至功能中
System One 模型在一次前向傳遞中回答類型化問題。它不產生任何文字。 輸入狀態，輸出帶有校準機率的類型化答案。它是一個能「讀取」的條件式判斷。
在決策狹義、預先指定且重複時使用。不要用於任何需要書面解釋的事物——那仍然是 Claude 的工作。
首要之務：這真的是正確的工具嗎
回答以下三個問題。若任何一個答案是「否」，請停止並保留 LLM 呼叫。
- 可能的答案是否預先已知？ 選項上限為 255 個。
- 呼叫者是否只需要標籤，而非推理過程？如果後續有人類讀取理由說明，你需要散文體輸出，而這不是正確的工具。
- 是否為高流量，或有人在等待？ 這是一項延遲與成本的最佳化，而非能力提升。它並不知道 Claude 不知道的事情。若僅是夜間 cron 任務處理五十筆記錄，它只帶來一個依賴關係，別無其他。
根據三個任務共 150 筆人工標註記錄的測量（我們 2026 年 9 月 20 日的測試）： Jev 以 145/150 的成績與 GPT-5.2 持平，但成本低 46 倍（每千筆記錄 $0.036 對比 $1.64），然而端到端速度僅比 GPT-4.1-mini 快 1.7 倍——公佈的 40 倍至 200 倍是相對於 3-329 秒的多步驟前沿流程，而非單一呼叫。
開放複製品並非直接替代品。 同一測試：Von 1.0.1（395M）92/150（61%），Laya（421M）62/150（41%）。它們會坍縮到單一類別而非降級——Von 在包含五個命令的 50 命令集合中預測了 exfiltration 25 次。信心門檻無法挽救此情況：捕捉 Von 錯誤意味著升級 92% 的流量，Laya 為 100%，而 Jev 僅為 8%。只有在你自己標註的資料集上測量過後，才能使用它們。
三種問題類型
"lead_type": {"type":"choice", "instructions": "...", "criteria": {"opt_a":"desc","opt_b":"desc"}}
"is_urgent": {"type":"noul", "instructions": "..."} # -> 0.0–1.0
"priority": {"type":"score", "instructions": "...", "criteria":["ignore","low","high"]}
在一次呼叫中詢問所有需要的問題——它們都在同一次前向傳遞中解析，因此四個問題的成本約等於一個問題。
回應結構（Jev 和 Von 皆同）：
r["answers"]["lead_type"]["choice"] # 標籤
r["answers"]["lead_type"]["probabilities"] # 完整分佈
r["answers"]["lead_type"]["confidence"] # 用於門檻
r["answers"]["is_urgent"]["noul"] # 0.0–1.0
r["answers"]["priority"]["score"] # 在尺度上的位置，例如 2.41
工作流程
1. 先建立標註集——最少 50 筆記錄
不可妥協，且是單一最有價值的步驟。在撰寫任何標準之前，從你打算指向的串流中手動標註真實記錄。沒有它，你無法區分是問題不佳還是模型不好，且失敗是無聲的——請見 jev-eval。
2. 像向新進員工解釋一樣撰寫標準
針對相同問題的四種措辭，每個任務 50 筆記錄的最差至最佳分數範圍（我們 2026 年 9 月 20 日的測試）：
| 任務 | Jev | Von (395M) | Laya (421M) |
|---|---|---|---|
| 代理命令風險 | 44-49 (10 分) | 9-23 (28 分) | 18-28 (20 分) |
| 線索分流 | 47-49 (4 分) | 22-34 (24 分) | 15-24 (18 分) |
| 工單路由 | 41-47 (12 分) | 23-41 (36 分) | 22-36 (28 分) |
包含 LLM 在內的相同命令任務掃描：Haiku 4.5 46-48 (4 分)，GPT-4.1-mini 45-50 (10 分)，Jev 44-49 (10 分)，GPT-5-mini 41-49 (16 分)。
Jev 在措辭穩健性上並不比小型 LLM 更強——它同樣波動約十分，而 Haiku 是測試中最穩定的模型。請看下限，而非分數範圍：每個託管模型的最低點都在 82-92% 並保持可出貨狀態，而 Von 最低點為 18%，Laya 為 36%。不要解讀為「寫更好的標準，開放模型就會追上」——早先一個 15 筆記錄的測試正是得出此結論，而且是錯誤的。更豐富的標準並不可靠地幫助：在線索分流任務上，Von 在簡潔措辭下得分 34/50，而在仔細撰寫的措辭下只有 28/50。影響這些數字的是對表面形式的敏感度，而非理解力，因此每一次未來的標準編輯都是一次未經宣布的回歸風險。
撰寫每個選項時包含：它是什麼、它不是什麼，以及可能導致錯誤答案的邊緣案例。當某個選項應主導時，明確命名預設值。
3. 根據標註集校準閾值——切勿假設 0.5
noul 是一個機率，而非布林值。Jev 的 noul 有下限：在明顯乾淨的記錄上，它仍回傳 0.2–0.5，而 Claude 回傳 0.0。在測量資料上，有用的臨界值約為 ~0.85，而非 0.5。閾值無法在模型之間轉移——切換模型時需重新掃描。
不要手寫掃描。jev-eval 負責校準並提供工具：
python ~/.claude/skills/jev-eval/scripts/sweep.py labelled.json configs.json \
--backend jev --question <name>
4. 設計信心門檻
將低信心的答案閘道到 Claude。同一腳本會報告兩個關鍵部分——門檻捕捉到多少比例的錯誤，以及它升級了多少比例的流量——並標記結果。一個能捕捉所有錯誤但升級 73% 流量的門檻被評為 無助益，因為它是一個帶有額外步驟的慢路徑。若看到此情況，解決方法是更好的標準或使用託管模型，而非調整不同的閾值。
a = r["answers"]["lead_type"]
if a["confidence"] < GATE:
return escalate_to_claude(state) # 慢路徑
return a["choice"] # 快路徑
5. 在功能旗標後發佈，記錄兩條路徑一週
記錄 System One 的回答以及舊路徑原本會說的內容。在轉換之前，先比較真實流量。絕不要僅依據評估集的數字就進行轉換。
存取路徑
# 1. TypeSafe 直接——金鑰在 macOS 鑰匙圈中，服務為 `typesafe-api-key`
export TYPESAFE_API_KEY="$(security find-generic-password -s typesafe-api-key -w)"
curl -X POST https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" -H "Content-Type: application/json" \
-d '{"model":"jev-latest","state":"...","questions":{...}}'
// 2. Cloudflare Workers AI——無需等候清單
await env.AI.run('typesafe/jev', { state, questions })
# 3. Von——本地、免費、Apache-2.0、395M ModernBERT
# pip install von-sdk
import von
r = von.system_one(state="...", questions={"x": von.Noul(instructions="...")})
r.answers["x"].noul
陷阱
- Von 的
Choice使用criteria=，而非choices=。 猜錯的話會出現 Pydantic 錯誤。 - Von 回傳
.answers[k]，而非.nouls[k]/.choices[k]。LangChain 包裝器在此處與原始 SDK 不同。 - Von 的 34 秒冷啟動會載入權重。請在啟動時預熱；切勿在延遲中測量它。
- 不要將 noul 的閾值設為 0.5。 請見步驟 3。
- Jev 處於早期存取階段、單一供應商、無 SLA。 請勿將客戶面向的關鍵路徑放在其上而無備用方案到 Claude。
- 小型評估集會誤導。 15 筆記錄兩個託管模型都得分 100% 幾乎證明不了什麼。請使用數百筆。
相關
jev-eval 建立並執行標註集。jev-audit 找出程式碼庫中哪些現有 LLM 呼叫值得轉換。