「跑分漂亮卻一上線就崩潰？」用 Claude Code 打造 AI 評測的 5 個殘酷步驟

開場：你的 AI 模型不是不夠強，而是根本沒被正確評估

先問一個刺骨的問題：你有多信任自己手上的 AI 模型？別急著回答引用哪份 bench-mark 數字——我問的是，當你把模型丟到真實世界、面對那些完全不按牌理出牌的使用者時，它是否還能維持那張漂亮的成績單？

如果你正點頭苦笑，那恭喜，你撞上了 2026 年 AI 圈最致命的隱形天花板：評測不到位。我們花了大把時間微調模型、催 prompt、串接 agent 流程，卻常常用最敷衍的方式「確認」這套系統能不能打——拿十幾個樣本跑一遍，看輸出「感覺不錯」就上線。結果呢？模型在 demo 場子裡是天才，碰到真實用戶就變成語無倫次的應聲蟲。

這就是為什麼 Peter Yang 頻道上那支與 Shreya 和 Hamel 的深度訪談（53 分鐘，一刀未剪）會如此重要。兩人不僅拆解了 AI 評測（AI evals）被誤解又怠慢的本質，還給出了一套可以立刻落地的 5 步指南，而且全程聚焦在 Claude Code——Anthropic 那個已經不再只是「編碼助手」、如今幾乎是 agent 開發者必備底層工具的產物上。

Hamel 在訪談裡說了一句值得裱框的話：

「如果你不能為你的 AI 建立一套好的評測，那你不只是在瞎搞，你是在幫使用者建立一套『如何被你的模型氣走』的 SOP。」

本文我將不藏私地拆解這 5 個步驟，並補上兩位講者對當前工具生態、數據蒐集與「兩條腿走路」開發哲學的深入剖析。準備好把你的模型從「自嗨天堂」拉回「人間煉獄」了嗎？我們開始。

核心概念：AI 評測不是「事後驗收」，而是「開發的骨架」

很多人聽到「評測」兩個字，直覺反應是：「喔，那是要上線前跑一下的 checklist 吧。」如果你也這樣想，那你已經把順序搞反了。

評測不該是開發流程的最後一站，而該是起點。 這就像蓋房子，你不能先把牆壁砌好，才開始思考地基要用什麼材質。Hamel 在訪談中強調，評測的本質是「把模糊的期望值變成可追蹤的規格」。沒有評測，你的 AI 產品就只是一團沒有形狀的黏土，開發者用直覺捏，設計師用信仰塑，最後 PM 用時程壓——做出來的東西能看嗎？運氣好可以，但大多時候只是災難。

尤其當你開始使用 Claude Code 這類 agent 框架時，問題會指數級放大。因為 agent 不像傳統程式碼是「寫死」的邏輯，它是動態的決策過程。每一次工具呼叫、每一串 prompt 組合、每一個觸發條件，都可能讓輸出內容偏移到無法預期的方向。沒有評測，你根本不知道是哪個環節的哪個參數讓模型突然發瘋。

Shreya 在訪談中點出一個很務實的痛點：現在的 AI 開發者太沈迷於「加功能」——多串接幾個工具、多塞幾層 context、多設計幾個 few-shot 範例——卻鮮少回頭問：「我怎麼知道這些改動是真的變好，還是只是在騙自己？」

這正是這篇文章要解決的問題。接下來，我將完全按照影片中兩位專家的說法，拆解這 5 個步驟，而且我會把話講白：這些步驟既不性感，也不高科技，甚至有點像在寫枯燥的測試文件。但如果你想做出一個真正能用的 AI 產品，這 5 步就是你的護身符。

步驟一：先定義「理想輸出」，再開始碰鍵盤——不要急著寫測試

反直覺真相：模型跑不起來，通常是因為你連「什麼是好」都不知道

這一步聽起來簡單得可笑，但 Hamel 和 Shreya 都不約而同地指出：超過一半的 AI 專案死在這個環節，不是因為技術難度高，而是因為「標準」太模糊。

多數開發者拿到任務時，動作很快，迫不及待地打開 Claude Code，輸入 prompt，然後對著螢幕上的第一個輸出大聲讚嘆：「哇，好厲害！」接著就把這個輸出當成「預期基準」。但問題來了：你之所以覺得這個輸出好，是因為你有一雙人類的眼睛、一顆有長期記憶的大腦，以及一種無法言喻的「語感」。這些能力，你的評測程式一項都沒有。

所以，步驟一的核心任務是：把所有「你覺得對」的判斷，轉化成「可以被程式驗證」的規則。

比如說，假設你在做一個客服 chatbot。你的「理想輸出」是什麼？不是「回覆得很有禮貌」——這種描述誰看得懂？你必須把它拆解成可測試的子項目：

答案是否包含正確的退貨政策編號？（事實正確性）
回覆字數是否介於 50 到 150 字？（長度合理性）
是否在任何情況下都不得出現「我不知道」以外的推託詞？（語氣合規）

Shreya 建議，最好的方式是直接抓 10 到 20 個從真實使用者抽樣而來的失敗案例，然後問自己：「如果這是我的模型表現，我會打幾顆星？原因是一個一個列出來。」把那些原因寫下來，你就擁有了評測的第一塊基石。

為什麼這極度重要？ 因為只有當你把「好」的定義拆解到可以量化時，Claude Code 才有所謂的「目標」可以最佳化。否則你只是在進行一場大型的「擲骰子」遊戲，中了開心，沒中也只能摸摸鼻子繼續改 prompt，完全沒有迭代邏輯。

步驟二：勇敢面對「兩條腿走路」——寫測試與跑 prompt 必須同時進行

不是先寫程式再測，也不是先測再寫程式，而是「邊走邊修正」

這裡可能是整場訪談中最有價值的實戰建議：不要試圖把所有的測試都寫完，再一次餵給 Claude Code 去執行。 那是瀑布式開發的遺毒，在 agent 時代根本行不通。

Hamel 用一個很生活化的比喻說明：這就像學騎腳踏車，如果你堅持先把平衡感練到完美再上車，你一輩子都學不會騎。你必須兩隻腳輪流踩踏板（寫測試）跟調整龍頭（改模型），在動態中尋找平衡。

具體操作上，他建議的流程是：

先建立一個「失敗案例」的輸出樣本。
讓 Claude Code 針對這個樣本產生診斷：它會告訴你，這個輸出到底哪裡不理想（例如「事實錯誤」「邏輯跳躍」「語氣過於官腔」）。
根據診斷，修正評測基準：不是直接改 prompt，而是把焦點放在評測本身。
重新執行模型，看新的輸出有沒有改善。 如果有，就收錄這個案例成為正式的回歸測試；如果沒有，那就代表你的評估標準有問題，或 context 不夠，必須再回去調整。

這整個過程聽起來很費工，但兩位講者一致強調：這才是讓 AI 開發「可持續」的唯一方法。你現在多花 30 分鐘寫清楚一個評測，三個月後當你的模型改了 50 版，你會感謝當初那個願意慢下來的自己。

這裡最容易犯的錯就是「求快」。很多人會想：「反正評測之後再補就好。」但 Hamel 直接打臉這種想法：

「你以為你在節省時間，其實你只是在把『除錯成本』轉嫁給未來的自己，而且還加上了高達數倍的利息。」

步驟三：投入 80% 的時間在「資料收集」，而非 Prompt 工程

關鍵不是模型不夠聰明，而是你餵給它的「真實世界樣本」太少

這是整場訪談中我最想大聲叫好的觀點。Shreya 與 Hamel 都指出，目前 AI 開發者最大的時間分配誤區，就是把 80% 的時間花在嘗試不同的 prompt 寫法，卻只留給「整理評測資料」一點點零頭時間。 這完全本末倒置。

為什麼資料收集比 prompt 重要？因為 prompt 是「讓模型發揮既有能力」的手段，而資料是你「定義什麼叫做表現好」的唯一依據。你沒有足夠多樣化、貼近真實的失敗案例，你的 prompt 再怎麼寫，都只是在一個空殼子上塗鴉。

具體要收集什麼資料？

這裡有個很關鍵的細節，兩位講者特別提醒：不要只收集來自標竿測試集（benchmark dataset）的資料。 那些資料太乾淨、太理想化、太、無、聊、了。你要收集的是「真實使用者在失控狀態下產生的輸出」。

具體來源可以是：

客服系統中使用者明顯不滿意的歷史對話
Discord 或社群上，用戶抱怨 AI 行為怪異的截圖
你內部測試人員故意惡搞的對答記錄
產品日誌中，模型呼叫工具失敗的所有錯誤訊息

Shreya 特別強調「失敗」這件事的價值：

「你蒐集的不是成功的例子，而是失敗的場面。失敗案例才是評測的燃料，因為它們不會說謊、不會迎合你的期待，只會誠實地告訴你模型哪裡破了洞。」

因此，請把那些「歪掉的輸出」當成寶藏。你不需要去找 10,000 個，你只需要 100 個高品質的、帶有明顯缺陷的輸出，你的評測集就比 90% 的新創公司還要完備了。而這，正是你砸錢去調模型參數之前，CP 值最高的投資。

步驟四：讓 Claude Code 幫你寫評測，但「專家」負責審判結果

機器可以產生候選方案，但人類必須握有最終否決權

現在，許多人的第二個迷思是：「既然 Claude Code 那麼強，乾脆叫它全自動寫評測、跑評測、最後總結報告就好了，人類完全放手。」如果你也贊成，那我只能說：準備迎接災難吧。

Hamel 在這裡提了一個極具洞見的警示：Claude Code 是順從性極高的工具。它會努力迎合你的指令，甚至會在你沒有明確指定「什麼是失敗」時，自行腦補一套隱藏的標準，然後用這套標準去評估自己寫的程式——結果就是做出一個「完美但不實用」的評測組，通篇都是綠燈，滿分過關，但產品一上線，用戶罵聲連連。

為什麼會這樣？因為 AI 沒有「常識」，只有「統計規律」。它可以幫你把測試腳本寫得結構漂亮、變數命名清楚、並行處理效率拉滿，但它缺乏對你產品「意圖」的理解。它無法判斷「使用者真的感到滿意嗎」這種帶有情感溫度的問題。

所以，正確的做法是：

讓 Claude Code 負責生成初版的評估樣本與測試腳本（加速流程）
你（人類專家）必須逐條審核這些範例的分數是否正確
建立一個「黃金測試集」（golden dataset），這些是經過人工確認、無懈可擊的標準答案，任何未經人類批准的新評測都不能進入黃金測試集。

這個概念在軟體工程裡叫「程式碼審查」（code review），但在 AI 評測領域，它的重要性被嚴重低估。你不信任 AI 寫的程式碼，為什麼會信任 AI 寫的測試？ 這個邏輯荒謬到……偏偏就是很多公司正在做的事。

步驟五：建立「定期回歸儀式」，讓評測成為動態護照

不要期待一次到位，因為模型永遠會變，世界也是

最後一步，也是最容易被忽略的：把評測當成「持續執行的日常儀式」，而不是一次性的專案。

Shreya 和 Hamel 都強調，AI 模型的行為不是靜態的。每一次你更新底層模型（例如 Claude Code 換版本）、調整 system prompt、甚至只是改變了工具呼叫的順序，都可能讓原本「通過評測」的輸出突然一片混亂。這就是所謂的**「回歸事故」**（regression incident）。

要防範這類事故，你必須建立以下機制：

每次 code merge 前，自動跑完整的評測套件（類似 CI/CD 的概念）
每週固定檢視一次評測數據的分布趨勢，確認模型輸出品質沒有悄悄下滑。
建立「評測通過率」的歷史曲線，當你看到曲線在某天突然以斷崖式下跌時，你就能迅速回溯是哪一次改動造成的。

Hamel 提出了一個辛辣的比喻：

「你的模型評測就像是機場的安檢系統。你不會在旅客已經登機完、飛機起飛之後，才想起來今天忘了檢查行李。你得讓安檢在每個入口、每一次登機前都執行。」

在 2026 年的開發環境中，這已經不是一個「加分項」，而是生存基本盤。因為現在的用戶對 AI 的容忍度空前低落——他們已經受夠了「beta 版」的藉口，要求的是「每一次都好用」的承諾。而這份承諾的唯一證明者，就是你的回歸測試報告。

深度解析：為什麼這集訪談值得你反覆重看？（市場與趨勢的後座力）

如果你認為這只是兩個技術宅在聊測試方法，那你就低估了它的市場含金量。這支影片發佈於 2026 年 8 月，正是 Agentic AI（代理式人工智慧）從「炫技」走向「可量產」的關鍵轉折點。這一年，各家公司都發現光靠砸錢買模型授權已經無法拉開差距，真正決定輸贏的反而是那些看起來「無聊」的工程基本功——而評測正是基本功中的基本功。

為什麼是 Claude Code？

Anthropic 的 Claude Code 之所以在 2026 年成為這波評測討論的中心，並非偶然。它不像 OpenAI 的商業模式那麼封閉，也不像開源模型那樣需要太多的自架構維護。Claude Code 提供了一個「介於中間」的完美甜點區：它夠強大、夠靈活，而且它可以被程式化控制的程度遠高於一般聊天介面。

更重要的是，Claude Code 的生態系越來越像一個「作業系統」——它不只是生成程式碼，它還能呼叫外部工具、操縱檔案系統、執行測試腳本。換句話說，它本身就是一個可以被評測的 agent。這讓開發者得以在「自己開發的 AI 應用」與「開發工具的 AI 能力」之間，建立一套統一的評測標準。

AI 職缺的新變種：AI 評測工程師

兩位講者也在訪談中預告：現在市場上最熱門、薪資漲幅最快的職缺，不再是「機器學習工程師」，而是一群被稱為「AI 評測工程師」或「模型行為分析師」的新物種。這些人的工作內容，就是你剛剛看到的那 5 個步驟——但他們做得更系統化、更深入。

為什麼這很重要？因為大模型本身正在變成「大宗商品」。各家 API 的基礎能力差距已經縮小到 5% 以內（在某些任務上甚至更少）。那麼，產品之間的差異化在哪裡？就是在於「誰能把模型調教成符合特定情境需求的形狀」。而調教的過程，靠的就是評測。評測能力，就是 2026 年 AI 產業的「護城河」。

重點整理：一目了然的評測對照表

為了方便你日後快速複習，我把這 5 個步驟的核心概念、常見錯誤、以及實戰關鍵整理成下面的表格：

步驟	核心行動	常見迷思	實戰建議	最重要心法
步驟一	定義理想輸出	覺得看到「感覺好」就是及格	將「好」拆解成可驗證的子問題	沒有量化標準的讚美，都是噪音
步驟二	兩條腿走路，寫測試與跑模型並行	先全部寫完再一次執行	用失敗案例動態循環修正	邊學騎車邊調整龍頭，才是磨練
步驟三	重金投資資料收集	把時間過度花在 prompt 工程	收集 100 個真實失敗案例	失敗案例是燃料，不是垃圾
步驟四	人類審核 AI 生成的評測	放任 AI 全自動評估	建立「黃金測試集」並人工標註	AI 可以當助手，但必須有最終裁判
步驟五	建立回歸測試儀式	評測做完就束之高閣	與 CI/CD 流程綁定，每週檢視趨勢	模型會變，評測必須在線

這個表格濃縮了約一小時的深度對談，但真正的血肉與細節，還是要回到影片中聆聽他們舉的實際案例與失敗故事——光是聽 Hamel 描述那些「看似正常卻一敗塗地」的評測結果，就值得你一再重播。

未來的方向：留給所有 AI 開發者的一道考題

我們正處於 AI 開發史上一個非常特殊的時刻：工具已經強到讓每個人都能做出「看得出是 AI 做出來的東西」，但很少人能做出「讓使用者真心喜歡」的產品。 這兩者的差距，就是評測的品質。

也許我們不該再把評測視為「為了防止模型出錯而做的事」，而該把它視為「為了理解模型到底擅長什麼而做的事」。當你不再急著征服下一個數學題庫，而是願意花一個下午，好好檢視那些模型答錯的對話、搞砸的任務、誤解的指令，你會突然發現：你對 AI 的理解，遠比任何 benchmark 的數字來得深刻。

所以，我的問題是：在你的評測資料夾裡，你存放的是讓自己安心的通過紀錄，還是那些會讓你刺痛的真實失敗紀錄？ 前者讓你舒服，後者讓你進步。你會選哪一個？好好想一想，因為這決定你 2027 年時，是在舞台上分享成功案例，還是在台下默默修改履歷表。