用 OpenRouter 對 RP 角色卡做 A/B 測試。用 OpenRouter 對角色卡
做一次認真的 A/B 測試。

分享過角色卡的創作者都有過這個感受：你寫了 4,000 token 的人設，把開場白在常用模型上反覆打磨到位，朋友換一個 host 載入同一張卡後回報——「禮貌但乾」、「老是破第四面牆」、「什麼都拒絕」。

卡沒變，變的是模型。Alignment 訓練、預設採樣行為、指令遵循偏差、長上下文衰減，這些都會把角色推往不同方向。誠實的做法是停止爭論「哪個模型最好」，改去測量「哪個模型對這張卡最好」。

一次對話只是樣本量 1。對 RP 角色卡來說，純憑感覺的評估有三個問題，會主動誤導你：

• 人設漂移（persona drift）。 有些模型能撐二十輪不掉戲，有些到第六輪就漂回 RLHF 基線。你只有真的把長場景跑完才會察覺。
• 拒答邊界（refusal surface）。 衝突、NSFW、身體恐怖、灰色道德選擇——每個 provider 的紅線都不同，而且會隨 system prompt 措辭浮動。「它拒絕過一次」這種觀察幾乎沒資訊量。
• 語氣指紋。 兩個模型都能在線上保持人設，但感覺天差地遠——一個冗長真摯，一個簡潔冷淡。哪個適配你的角色是品味決定，但你需要可比的輸出才能下決定。

解法不是 benchmark 套件——那些測的是推理，不是 RP。解法是一組固定的小場景集，在多個模型上重放，用更強的評審模型打分。

可用的評估有四個零件：場景、執行次數、評審模型、評分維度。每個都不需要花俏，重點是一致。

1. 5 到 8 個場景。 覆蓋卡的表面：日常互動、危機或情緒崩潰、NSFW 或邊界場景（若相關）、性格衝突場景（有人挑戰角色價值觀）、長程記憶測試（呼應二十輪前提過的細節）。
2. 每場景跑 5 到 10 次。 生成是隨機的，一次取樣等於雜訊。5 次是「能把模型分出來」的底線，10 次比較舒服。
3. 評審模型要強於被測模型。 self-eval 有偏差，模型會系統性偏好自己的輸出。用一個獨立的、能力更強的評審模型（Claude Sonnet、GPT 級、Gemini Pro 等級），把卡、場景、候選回覆一起餵進去。
4. 4 到 6 個評分維度。 人設一致性、拒答/破戲、語氣匹配、callback 準確度、文采、總分。每項 1–5 分，附一句理由。理由才是你真的會讀的東西。

這比較像試吃，不是 benchmark，這正是重點。你不是要發 leaderboard，是要決定你的卡上架時要不要掛一個「推薦模型」徽章，寫 claude-opus 還是 gemini-flash。

你可以串五個 SDK、管五把 key、自己把五種訊息格式正規化。試過一次的人通常不會試第二次。OpenRouter 在整個模型生態前面架了一層 OpenAI 形狀的 API，每個 model 的價格在回應裡直接給，換 provider 只要改一個字串。

執行環境就簡化成這樣：

POST https://openrouter.ai/api/v1/chat/completions
Authorization: Bearer $OPENROUTER_API_KEY

{
  "model": "anthropic/claude-3.5-sonnet",
  "messages": [
    { "role": "system", "content": cardToSystemPrompt(card) },
    { "role": "user",   "content": scenario.opening }
  ],
  "temperature": 0.85,
  "max_tokens": 600
}

把 model 換成 google/gemini-2.0-flash、 deepseek/deepseek-chat、 x-ai/grok-2 或 z-ai/glm-4.6，其餘程式碼一字不改。每次呼叫的 token 成本在 usage 區塊裡回來，不用另外打 billing API 就能加總開銷。

舉個具體例子。假設你的場景平均 3,000 token 輸入（卡 + system + 場景歷史）、500 token 輸出。8 個場景、每個 5 次、6 個候選模型、每筆生成一次評審：

• 生成：8 × 5 × 6 = 240 次呼叫。混合平均下，輸入大約 $1–$3 / M token、輸出 $3–$15 / M token，候選混合大約是 $2–$6 的生成成本。
• 評審：240 次評審呼叫，每次讀卡（約 3k token）+ 回覆（約 500 token），輸出短評（約 150 token）。Haiku 級評審大約再花 $1–$2。
• 總計：整張矩陣評估 不到 $10， 改卡之後想重跑就重跑。

這些數字是說明用的，不是報價——OpenRouter 價格每週都動，各 provider 也有差。重點在數量級：一次認真的評估只要一杯咖啡的錢，不是研究預算。

幾乎每個人第一次嘗試都會踩到下面三個：

1. 評審模型偏好冗長。 LLM 評審被問「品質」時，會系統性偏好更長、更冗長的回覆。要嘛在 prompt 裡明確要求權衡簡潔，要嘛加一個長度正規化步驟（超過閾值就扣分），不然你測的其實是字數。
2. System prompt 解析有差。 有些模型會老實照長而結構化的 system prompt 執行；有些則把它當建議。重度使用 XML 標籤的卡在 Claude 上看起來完美，在不懂標籤的模型上會混亂。把哪些模型需要簡化版 system prompt 當成評估結果的一部分，不要當成雜訊。
3. Temperature 0 不等於確定性。 Provider 端的 batching、prompt cache、tie-break，都會在 temperature: 0 下引入變動。多取幾個樣本還是必要的。若你要 release-blocker 級的可重現性，就在 API 支援的地方固定 seed，並接受「差不多一樣」就是實務上限。

上面這套方法對熟 OpenRouter API 的人來說大概是三個下午的膠水程式碼。對其他人——以及對未來不想再維護膠水的自己——這正是 tavernai.cards Studio 在打磨的形狀。

• 場景庫 — 每張卡可重用的場景模板，常見原型（日常、危機、衝突、長程呼應）內建。
• 矩陣執行器 — 從 OpenRouter 目錄勾選候選模型、設定每場景的執行次數，剩下交給它跑。
• 內建評審 — Claude 等級的評審 + 長度正規化評分，讓你不會無意間優化成「誰寫得長誰贏」。
• 自動報告 — 每個模型的優勢、最弱場景、建議掛在卡公開頁上的「推薦模型」。

Studio 是付費檔（大約一週一杯咖啡），矩陣執行器是核心。免費檔仍會提供 linter、converter，以及前幾期講過的多 host 匯出。