別只看排行榜選 AI 模型：用個人評測集做決策

浪費一週 AI 選型時間的最快方式，就是打開排行榜，選最高分模型，然後假設它一定最適合你的產品或日常工作。排行榜不是沒用，它們能提供方向；但它們的提示詞、評審方式、使用者組成和激勵目標，往往不像你的真實環境。

LM Arena 和 Chatbot Arena 這類資源能提供廣泛偏好訊號，模型卡和基準測試也能展示推理、程式碼或多模態能力。但你的工作可能更重視語氣、可驗證性、成本、延遲、工具使用安全，或能否承認不確定性。若只是比較消費級工具，可先看 Claude vs GPT 非技術使用者指南，再用自己的任務驗證。

建立有代表性的個人 eval set

個人評測集是一組小型任務、期望品質和評分規則，反映你實際如何使用 AI。個人用 20 個精挑提示詞，小團隊用 50 到 100 個真實任務，通常就能看出差異。來源可以是客服工單、銷售郵件、程式碼 review、產品規格、表格整理、研究問題、會議摘要和 agent workflow。

請保留任務困難的部分：混亂上下文、模糊指令、長內容、多語言、工具輸出和高風險限制。若你在做工程工作流，可搭配 AI 開發者指南 與 GPT-5 開發者遷移手冊。評測集要像你的 repo、你的錯誤和你的 review 標準。

先寫 rubric，再比較模型

不要在知道答案來自哪個模型後才打分。先定義簡單規則：任務成功 0 到 3 分、事實可靠性 0 到 3 分、指令遵循 0 到 3 分、可用性 0 到 3 分，並對危險行為、過度自信、隱私洩漏和隱藏假設扣分。主觀內容可加入語氣、簡潔度、品牌匹配；程式碼任務盡量用測試；工具型任務要看模型是否選對工具、是否要求確認、是否知道何時停止。工具設計可參考 MCP、CLI 與 function calling 的取捨。

可改造的範例提示詞

研究綜合：根據五段來源摘錄，總結決策、列出未解問題、標記需要驗證的 claims。

客服回覆：客戶因匯出失敗兩次而生氣，請承認問題、不承諾修復日期、詢問一個診斷資訊，並限制在 140 字內。

程式助手：給定失敗測試、相關函式和最近 diff，提出最小可能修復，並說明修改前要驗證什麼。

採購評估：根據提供筆記比較三個 AI 寫作工具，區分事實與假設，不編造功能。

Agent workflow：你有日曆、郵件草稿和 CRM 查詢工具。使用者要求改期客戶會議並發送新議程，指出哪些步驟執行前需要確認。

Anthropic 有 AI 應用測試與評估 指南，OpenAI 提供 custom evals and graders 文件，Hamel Husain 的 LLM evals 文章也強調應用場景評測。

同時看回歸、成本和延遲

高 5% 的分數如果換來三倍延遲，可能不值得。便宜模型若在高風險任務上沉默失敗，成本會轉嫁到客服和返工。評測表應記錄模型、日期、提示詞版本、平均延遲、估算成本、通過率、嚴重失敗和 reviewer notes。不要只看平均分，要看分類：寫作、抽取、工具使用、澄清能力可能由不同模型勝出。

生產系統需要小型 regression set。每次改 prompt、升級模型、加入 retrieval 或開放新工具權限時重跑。若你評估瀏覽器或 agent automation，也可延伸閱讀 AI 瀏覽器自動化技術棧指南。

何時重跑 evals

新模型發布、價格變化、供應商路由調整、重大 prompt 重寫、新工具權限、檢索語料更新或業務流程改變時，都應重跑。個人每月快速跑 10 個常用提示詞即可；indie hacker 在切換預設模型前跑高風險子集；採購團隊則應在採購前、上線前和真實使用後各跑一次。

目標不是成為評測科學家，而是不要把判斷外包給一個不是為你工作設計的排行榜。用公開排名縮小候選，用個人評測集做選擇。