Day 63 驗證迴圈與 Eval——怎麼確保 Claude 的產出是對的

延續前面的記憶管理、持續學習、省 token，今天來聊品質保證。不管你的 workflow 設計得多好、agent 分工多精細，如果沒有驗證機制，你就是在迷霧裡開車。

為什麼需要驗證

Claude 很強，但它不是 100% 可靠的。它可能寫出看起來正確但邏輯有漏洞的 code，可能在重構時悄悄引入 regression，可能在長時間 session 裡逐漸偏離原本的目標。

這跟信不信任 Claude 沒關係，重點是你需要一個系統化的安全網。

可觀測性：先看得見才能管

在開始驗證之前，你需要先能 "看見" Claude 在做什麼。兩種做法：

有了這些 log，你才能事後回顧和分析。

兩種 Eval 模式

Checkpoint-Based：在工作流的每個階段設定明確的檢查點，驗證通過才能往下走。

Continuous：每隔 N 分鐘或每次重大改動後自動跑完整的 test suite + lint。

怎麼選？看你的工作性質。有明確階段的任務用 checkpoint-based，沒有明確里程碑的探索性工作用 continuous。

用 strict rules 搭配驗證，Claude 就不會亂生 .md 檔案、不會產生重複的檔案、不會留下一堆 dead code。再加上持續更新的 codemap，你就有了一個在 repo 之外的 source of truth，記錄著 codebase 隨時間的演變。

Benchmark 你的 Skill

想知道某個 skill 或 workflow 到底有沒有效？用 worktree 做 A/B test：

這個方法也可以用來 benchmark 不同模型在同一個任務上的表現。

評級的類型

Anthropic 的 eval 指南把評級分成三種：

Code-Based：字串比對、測試通過與否、靜態分析、產出驗證。快、便宜、客觀，但對合理的變化比較脆弱——可能結果是對的，但格式不同就被判錯。

Model-Based：用 rubric 打分、自然語言斷言、兩兩比較。彈性好、能處理細節，但不穩定，而且比較貴。

Human：專家 review、crowdsource 判斷、抽樣檢查。品質最高，但慢又貴。

實務上通常是混合使用：先用 code-based grader 做初步篩選，有爭議的再用 model-based 或 human 判斷。

兩個衡量指標

pass@k：k 次嘗試中至少成功一次就算過。k=1 時 70% 成功率，k=3 就有 91%，k=5 有 97%。適合 "只要能 work 就好" 的場景。

pass^k：k 次嘗試全部都要成功。k=1 時 70%，k=3 剩 34%，k=5 只有 17%。適合需要一致性和確定性產出的場景。

簡單說：pass@k 測的是 "能不能做到"，pass^k 測的是 "能不能每次都做到"。

建立 Eval 的路線圖

Anthropic 的建議是：

系列回顧

TLDR

驗證迴圈與 Eval——怎麼確保 Claude 的產出是對的