ClaudeDevs 分享用代表正式環境的測試案例，逐輪改善應用程式，並用保留測試集確認修改是否真的有效。
ClaudeDevs 在官方帳號貼文介紹流程；Lance Martin 的完整文章則示範如何用 Claude Code 的 build-eval 建立評測、再用 hillclimb 調整 prompt、skill、工具或模型設定。Eval 是一組能重複執行的任務與評分方法；hillclimb 則是一次改一項，觀察評分變化，留下有效改動、撤回退步版本。
先做出能代表工作的測試 任務分布應接近應用程式實際要處理的正式工作，不要只挑容易生成或容易評分的題目。案例可以從去識別的正式對話、bug 回報與客服票單抽樣，也可手寫 5–10 題或根據程式碼合成，但須由人確認它們確實代表目標使用情境。只挑目前模型做錯的題目會得到它的「失敗指紋」，不一定涵蓋產品真正重要的難題；應先由領域專家說明某題為何困難，再納入測試。
好的評測還要能區分不同設定：較強模型或較高 effort 通常應能提高分數；若沒有，先查題目是否含糊或 grader 是否校準錯誤。最強設定也不應接近滿分，否則沒有空間量出改善；但低分不能只是因為題目不可能完成。每次執行的波動要小到足以分辨團隊在意的改善幅度，並固定模型、effort、工具與執行環境，避免前次留下的檔案或 Git 狀態偷偷提供答案。
評分器也要驗證 答案範圍有限時，優先用程式檢查，例如 exact match、固定標籤、JSON schema 或測試是否通過。答案開放，但品質條件能拆成具體檢查項時，才用另一個大型語言模型充當評分器（LLM-as-judge）。先由人工抽查一批判分，確認結果和人工判斷一致，再擴大使用。基線執行還要重複評同一輸出，檢查評分器（grader）是否前後一致，並排除執行逾時（timeout）、API 錯誤與截斷造成的假波動。若結果雜訊大於最小可接受改善，就增加題目或重複次數，先別把微小分差當進步。
用訓練集找方向、保留集驗證 把案例分成可供調整流程查看的 train，以及 hillclimb 不可讀取的 held-out test。每輪只改一件事，例如移除多餘工具呼叫、修正一條衝突指示，或調整模型／effort；對照修改前後兩組分數。若 train 進步、test 沒動，表示可能過度配合已看過的案例；若任一組退步就還原。不要把失敗逐字稿塞回 prompt，也要防止 harness 加入只對特定題目有利的工具。連續幾輪停滯時，檢查剩餘失敗是否來自題意歧義、grader 校準錯誤、harness 錯誤或執行環境波動，再決定是否補案例，而不是持續改寫措辭。
文章中的實例 Claude.dev 以 44 張客服票單示範：30 張用來搜尋改法、14 張保留驗證。原設定是 Opus 4.8（預設 high effort），search 正確率 74.4%、每票成本 4.6 美分。流程先移除強制工具儀式、scratchpad 與互相矛盾規則，再測 Opus 5.5 low effort，得到 87.8%、每票 1.9 美分；接著換更便宜的 Sonnet 5 low，最後加入路由規則與退款上限交叉檢查。最終 held-out 正確率由原設定 78.6% 升到 90.5%，成本約為原來五分之一。這是文章中的內部案例，不是獨立 benchmark；它展示的是如何用保留資料驗證變更，而非保證同一改法適用其他產品。
可以照做的起點 先收集一批經人工確認的真實任務，定義「合格答案」的明確條件，再固定模型與 harness 跑基線；保存每題輸入、輸出、判分和錯誤類型。抽查 grader、估計分數波動後，切出不供修改者查看的 test 集。每輪只提交一個可歸因的變更，將成本、延遲與品質一起記錄；只有 test 集的改善超過雜訊且沒有品質回退，才保留。這樣能把「改了之後感覺更好」換成可重現的比較。
原文：https://easyvibecoding.app/curated/3402-claudedevs-improve-applications-iteratively-with-evals
