將 evals 視為產品規格

資料來源#

• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog
• Full Walkthrough: Workflow for AI Coding — Matt Pocock
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias
• The Founder's Playbook: Building an AI-Native Startup
• Thread by @AndrewYNg

摘要#

Cat Wu 闡述了為什麼撰寫 evals 正成為 AI 產品的新興核心產品經理技能——它不是 QA 工作，也不是 ML 工程師的職責，而是產品定義本身的介面。eval 是一個以文字寫成、可以執行的回答：這項功能成功的樣貌是什麼？ 在模型幾乎能為任何提示產生流暢輸出的世界裡，產品品質的瓶頸不再是「我們能不能發布？」而是「我們能不能分辨一項已發布、確實運作的功能與一項不運作的功能？」evals 將這種判斷編碼下來，當模型與 harness 改變時，也能低成本重新測試。

核心論點（Cat Wu）#

「只建立 10 個優秀的 evals，對幫助團隊量化目標、了解朝目標前進的程度，以及看見缺少了什麼，非常重要。所以我認為 eval 是一件被低估的事，應該有更多產品經理、更多工程師投入其中。」

「產品管理的未來就是撰寫 evals，因為問題就在於：成功的樣貌是什麼？讓我實際、具體地定義它，然後我們就會知道。」

轉變在於：過去產品經理會撰寫 PRD（「這是我們想要的東西」）。PRD 描述意圖；eval 定義完成。在 AI 產品中，PRD 位於上游——但團隊最終會收斂到 eval，而 eval 會告訴團隊模型加上 harness 是否已經能做到這件事。

為什麼十個優秀的 evals 勝過一百個平庸的 evals#

Cat Wu 給出的數字很明確：10 個優秀的 evals，不是一百個平庸的 evals。為什麼？

• 每個 eval 都必須具備可解釋性。 失敗的 eval 必須告訴你哪裡壞了以及為什麼，不能只產生一個紅色勾選記號。平庸的 eval 會以無法拆解的方式失敗。
• 每個 eval 都必須捕捉一個你原本會在評審中爭論的判斷。「這個輸出好嗎？」是 evals 在規模化後回答的問題；糟糕的 eval 只會驗證大家早已同意的表面屬性。
• 維護成本是真實存在的。 數百個 eval 需要基礎設施、資料集整理與回歸分流。一小組精心挑選的 evals 才能持續承擔關鍵作用。

還有第四個容易被忽略的要求：當 eval 由 LLM judge 評分（多數模糊功能的 eval 都是如此）時，「優秀」還必須包含經過驗證。Norman et al. (2026) 顯示，實務工作者信任的標題數字——完全匹配的一致率——會高估經機率校正後的可靠性 33–41 個百分點；而且，即使某個 judge 的重測結果近乎完美，仍可能存在嚴重的位置偏差（一致性–偏差悖論）。評分器未經機率校正與偏差稽核的 eval，只是一個你無法信任的紅／綠勾選記號——撰寫正確的 eval，以及驗證負責評分的 judge，是兩門分開的學科，而第二門最容易被產品經理跳過。

可參考 Harness Shrinkage as Models Improve——Cat Wu 主張提示 scaffolding 會隨每次發布而縮減。evals 不會以同樣方式縮減：它們編碼的是我們想要什麼，即使模型變得更強，仍然必須拿這個標準來衡量模型。

evals 在 Cat Wu 的除錯堆疊中位於何處#

完整的 Cat Wu 產品經理除錯堆疊分成三部分：

1. 請模型進行內省（Model Introspection Feedback）——模型做出預期之外的事情時，詢問原因。模型的回答是 harness 缺口的訊號，不是關於模型本身的訊號。
2. 從一小群品味引領者取得快速回饋——五位具備合格回饋、能說明模型／harness 組合為何優秀的人。Cat Wu 在團隊午餐期間進行的 vibe-check 是典型例子。
3. 建立 evals——第三個工具，也是較慢但持久的工具。當 (1) 與 (2) 浮現出一個假設（「模型沒有充分測試自己」）時，evals 會在規模化下驗證這個假設，並在修正後防止回歸。

三種工具彼此互補：

• (1) 提供假設（模型的自我報告）
• (2) 提供方向（品味引領者的判斷）
• (3) 提供證明 + 回歸護欄（eval）

記憶：最需要 eval 的典型功能#

Cat Wu 指出，記憶是 evals 最重要的功能：

「像記憶這類功能，從這件事中獲益很多。」

為什麼特別是記憶？記憶是典型案例，因為：

• 輸出是「系統是否在正確時間記住了正確的事情？」——沒有真值資料集時，這個問題很主觀。
• 失敗模式很容易被誤診（「模型很喜歡寫記憶，但我們不確定它們的品質是否高」）。
• 沒有 evals 的修正迴圈很慢：你需要真實使用者試用，才能知道記憶的改動究竟改善了事情，還是造成回歸。

沒有 evals，記憶功能的工作會陷入感覺與軼聞。有了 evals，團隊就能量化：「對我們在乎的工作流程而言，這個版本的記憶比上一版更好嗎？」

怎樣才算「擅長 evals」#

Cat Wu 提到兩個參考案例：

• Amanda——Anthropic 中塑造 Claude's character 的人。「這真的是一個非常困難的角色，因為任務太模糊了。就連寫程式都比較容易，因為你可以驗證成功與否；但塑造角色需要非常強的信念，知道 Claude 應該成為什麼樣子。」 這項技能是：把模糊的目標表述得足夠精確，讓你能以它衡量進展。
• Claude Code 團隊在午餐時進行的 vibe-check——像是「這個模型沒有充分測試自己」的回饋，會被轉換成「好，那我們要看哪些資料，才能驗證這是不是一種模式？」接著變成「好，那要用什麼 eval 證明或推翻這個假設？」

模式是一樣的：對美好樣貌有強烈看法 + 能把這個看法轉換成可衡量的產物。這就是被渲染成函式呼叫的品味。

與 Matt Pocock 驗證方式的連結（Design Concept Grilling）#

Matt Pocock 不使用「evals」這個詞——他的教學框架是「驗證」與「回饋迴圈」。但底層論點相同：在 agent coding 工作流程中，回饋迴圈的品質限制了輸出的品質。Pocock 的 deep-module pattern 將整合測試放在承重的 harness 資產之中，因為模型需要能在迴圈中自行執行的驗證。

兩者的匯流在於：產品經理側的 evals（Cat Wu）與工程師側的整合測試（Matt）是同一種原語——一個編碼判斷、可執行的產物——只是應用在產品的不同層次。

與 Founder's Playbook 的連結（AI-Native Startup Lifecycle）#

Playbook 中相鄰的概念，是 MVP 階段的**「在發布之前建立你的衡量框架」**：

「那些把早期 traction 誤認為 product-market fit 的創辦人，通常也是那些在發布後才開始追蹤資料的人；他們使用的指標是為了評估哪些事情運作良好，而不是揭露哪些事情沒有運作。解方是在第一位使用者出現之前，先建立衡量框架。」

這是高一層的同一項技能：不是「這項功能成功的樣貌是什麼？」而是「對這項產品、這個市場、這些使用者而言，成功的樣貌是什麼？」Playbook 讓 Claude 本身成為 eval 設計夥伴（透過諮詢 Claude，「在發布前設計你的衡量框架」）。

對同時採用兩種觀點的創辦人而言：撰寫產品層級指標（CAC、留存率、Sean Ellis score）以及功能層級 evals（這項功能是否做到我們想要的事？最新模型讓它改善還是退步？）。前者用來決定公司是否 go/no-go；後者用來決定每個已發布改動是否 go/no-go。

轉折：eval 撰寫本身也被自動化了（Google，2026 年 6 月）#

Google 的 Agent Quality Flywheel 是第一個基於這項前提發布的產品：Cat Wu 所稱、正成為核心產品經理技能的 eval 撰寫工作，可以由 coding agent 自己完成。 開發者的全部貢獻是一個自然語言的擔憂（「我的 agent 是否遵守對話中途的修訂？」）以及一次核准；這項技能會讀取程式碼、選擇指標、設計自訂評分規準、合成測試情境，並回報前後差異——「你什麼都沒有寫……你描述了目標。」這並未駁斥該論點，而是將它重新定位，就像 PRD 被重新定位一樣（Prototype Over PRD）：持久的人類技能濃縮為精確表述成功樣貌，精確到足以說出這份擔憂，並判斷機器撰寫的 eval 是否真的編碼了它。十個優秀 eval 的紀律也依然成立——flywheel 的關鍵動作，是把一項擔憂提升為一個穩定、可解釋的指標，而不是累積一百個混合在一起的指標。

為什麼這在 2026 年「被低估」#

Cat Wu 認為這項技能被低估，可以從三個角度理解：

1. 文化。 在 2023 年以前受訓的產品經理不寫程式，更不用說 evals。撰寫 eval 需要熟悉資料集、評分函式與機率輸出——過去的產品經理培養管線並未篩選這套技能。
2. 地位。「撰寫測試」歷來是低地位的工程工作。evals 就是披上不同外衣的測試。撰寫 evals 的產品經理所做的工作看起來像 QA，但實際上是產品規格。
3. 可處理性。 多數產品經理沒有意識到自己能撰寫多少 eval，因為工具不夠均勻，且這門學科沒有被教授。Cat Wu 的「十個優秀 evals」部分是一張許可證：你不需要一百個，只需要十個。

這預示近期的角色重新定義：能寫 evals 的產品經理，會比不能寫的產品經理發布更多產品。Engineer PM Convergence 正是它所屬的框架——工程師與產品經理會匯流成混合角色，而 evals 是兩者最終都會從事的活動之一。

開放問題#

• 要如何為 character 這類由品味驅動的功能撰寫 eval？Amanda 的角色是 eval 抗性的典型；Cat Wu 指出她在這裡擅長 evals，但沒有描述技術。部分解答： How Do You Write Evals for Taste? Character as the Limit Case——技術是一條管線（信念 → 來自 dogfood 的失敗模式 → MSM 風格的變體 A/B 衡量 → 約 10 個可解釋的 eval）；它已在安全／價值核心上獲得證明，但在溫暖／機智的美學表層仍是默會知識。
• 10 對 100 的數字沒有附帶理由。是否存在 Goldilocks zone，還是取決於功能的表面積？Client-Side Agent Optimization 對組合的框架暗示，evals 也有組合爆炸問題。
• evals 如何與 Harness Shrinkage as Models Improve 互動？當 harness 資產因模型現在能原生處理它而縮減時，圍繞舊 harness 建立的 eval 可能會變成產物，而不是護欄。Anthropic 會淘汰 evals，還是重新利用它們？
• 是否有一個可引用的、非 Anthropic 的產品經理作為 eval 撰寫者案例，還是目前只有 Cat Wu 的單一框架？Matt Pocock 的工作坊從不同詞彙抵達相同位置，但目前還沒有攝入第三個來源。部分解答（帶有轉折）： Google 的 Agent Quality Flywheel 是第三方對 eval 作為品質介面的回應——但它的答案是讓coding agent 撰寫 eval，把人類角色壓縮為陳述擔憂並核准計畫。

相關連結#

• Cat Wu — 主要闡述者；貫穿此概念的主聲音
• Claude Code / Cowork / Anthropic — 這個概念發展的背景
• Claude Character as Product — Amanda 的角色；即使抗拒 eval 的品味仍被編碼
• Model Introspection Feedback — 伴隨的除錯技術（假設，而非證明）
• Harness Shrinkage as Models Improve — 不會縮減的部分；eval 作為持久產物
• Engineer PM Convergence — 匯流後的角色所需的混合技能：撰寫 eval
• AI Native Product Cadence — 只有因為 evals 提供回歸護欄，快速節奏才得以維持
• AI-Native Startup Lifecycle — 「在發布前建立衡量框架」是產品層級的鏡像
• Design Concept Grilling / Deep Modules for Agents — Matt Pocock 的驗證迴圈框架；工程側的同一種原語
• Claude Code Best Practices — 驗證驅動開發；evals 的嚴格版本
• Claude Character as Product — 角色工作是 eval 抗性功能的極限案例，但仍需要 evals
• Model Spec Science — 對齊研究的類比：以經驗衡量哪些規格特徵能泛化，將規格本身視為可用 eval 測試的對象
• Verification as the New Bottleneck — Fiona Fung 對組織層級的主張：當 coding 變得便宜後，驗證（由 evals 編碼）成為稀缺資源
• Dogfooding as Product Discipline — evals 編碼品味；dogfooding（「螞蟻食物」、午餐時的 vibe-check）是取得 evals 所編碼品味的方式
• The Verifiability Thesis — Karpathy 的「自動化你能驗證的事」；evals 是以產品規格形式撰寫的驗證
• How Do You Write Evals for Taste? Character as the Limit Case — 最困難案例（品味／角色）的綜合技術：信念 + dogfooding + MSM 變體比較如何結合成可執行的 eval
• DRACO Benchmark — evals 外化至 benchmark 規模：專家評分規準作為 eval 集，自動評分
• LLM-as-a-Judge — rubric 風格的 eval 如何擴展至開放式輸出；DRACO 背後的評分原語
• Production-Sourced Evaluation — 在 benchmark 規模下「從真實使用建立你的衡量框架」
• Telemetry vs. Survey Measurement — Faros AI 的「衡量實際發布的內容，而不是人們的感受」是偏好可執行 evals 而非自我報告的工程指標近親
• The Three Loops of AI-Native Building — 關於何時撰寫 evals 的有效分歧：Andrew Ng 將其視為對重複失敗的反應（「如果你發現系統反覆遇到某些問題，建立一組 evals 就會很有用」），而 Cat Wu 則在一開始就把它們寫成規格。Ng 的方式更便宜；Cat 的方式則是當功能足夠模糊、以至於「它失敗了」不再不言自明時所需要的
• Agent Quality Flywheel — eval 撰寫自動化：coding agent 將自然語言的擔憂轉換成指標選擇、評分規準設計與前後差異；人類陳述目標並核准
• LLM-Judge Validation — judge 評分的 eval 要值得信任所需的學科：機率校正、位置交換、複製、跨 benchmark，以及一致性–偏差稽核；「優秀 evals」預設了有效的 judges
• AI-Native Organization — 將 evals 應用於組織自身的路由層：Tan 的「trigger evals」（正確的 skill file 是否真的載入？）是他在組織原語映射中的績效評估

資料來源#

• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — 主要闡述（時間戳約 55:00：「Why building evals is underappreciated」）；也在除錯堆疊章節中多次提及
• Full Walkthrough: Workflow for AI Coding — Matt Pocock — 驗證迴圈框架；來自工程教學的匯流論點
• The Founder's Playbook: Building an AI-Native Startup — 「在發布前建立衡量框架」的產品層級類比
• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog — coding-agent-as-eval-author 示範（「你什麼都沒有寫……你描述了目標」）（vendor-claim）
• Thread by @AndrewYNg — Andrew Ng，《The Batch》（2026-06-30），practitioner-opinion：evals 是對重複失敗的反應，而非預先撰寫的規格
• Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias — Norman et al.（arXiv 2606.19544，2026 年 6 月，empirical）：為什麼 judge 評分的 eval 其標題數字可能不可信（kappa 通縮、一致性–偏差悖論）；見 LLM-Judge Validation