將評測視為產品規格

資料來源#

• Boris Cherny: We Cut 80% of Claude Code's Prompt
• 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
• Sidekick's continual learning loop
• The Founder's Playbook: Building an AI-Native Startup
• Thread by @AndrewYNg

摘要#

Cat Wu 闡述了為何撰寫評測是 AI 產品的新興核心 PM 技能——它不是 QA 工作，也不是 ML 工程師的職責，而是產品定義本身。一項評測是對「這項功能的成功標準是什麼？」所寫下、可執行的回答。在模型幾乎能對任何提示產出流暢內容的世界裡，產品品質的瓶頸不再是「我們能不能推出產品？」，而是「我們能不能分辨推出的功能究竟有沒有用？」評測把這種判斷編碼下來，讓模型與 harness 改變時，重新測試的成本變得低廉。

核心論點（Cat Wu）#

「只要打造 10 個優質評測，就能幫助團隊量化目標、掌握進展，以及看見還缺少什麼。所以我認為評測是個遭到低估的領域，更多 PM 和工程師都應該投入其中。」

「這就是產品管理的未來：撰寫評測，因為問題是成功的標準是什麼？讓我實際、具體地定義出來，之後我們就會知道了。」

轉變在於：PM 過去會撰寫 PRD（「我們想要這些」）。PRD 描述意圖；評測則定義完成標準。在 AI 產品中，PRD 位於上游，但團隊最終會以評測為共同依據，並由它判斷模型與 harness 是否已能完成目標。

為什麼十個優質評測勝過一百個平庸評測#

Cat 明確提出數量：10 個優質評測，而不是一百個平庸評測。為什麼？

• 每個評測都必須能解讀。 評測失敗時，必須告訴你出了什麼問題以及為什麼，而不能只亮起紅色勾選標記。平庸的評測會以無法拆解的方式失敗。
• 每個評測都必須涵蓋一項原本會在審查中爭論的判斷。「這個輸出好不好？」是評測要大規模回答的問題；糟糕的評測只會驗證大家早已認同的表面特性。
• 維護成本確實存在。 數百項評測需要基礎設施、資料集整理和回歸問題分流。少量精心挑選的評測才能持續發揮關鍵作用。

還有一項容易忽略的第四個要求：當評測由 LLM judge 評分（多數模糊功能評測皆如此）時，「優質」還必須代表經過驗證。Norman et al. (2026) 顯示，實務工作者信任的指標——完全一致率——會把經機率校正後的可靠度高估 33–41pp；而一個重測結果近乎完美的 judge，仍可能有嚴重的位置偏差（一致性與偏差悖論）。評分者未經機率校正與偏差稽核的評測，只是個無法信任的紅綠勾選標記——撰寫正確的評測，以及驗證為它評分的 judge，是兩種不同的專業，而 PM 最可能跳過的是後者。

對照模型進步後 harness 縮減——Cat 認為提示鷹架會隨每次模型發布而縮減。評測不會以同樣方式縮減：它們編碼了我們想要什麼，即使模型變得更強，仍然必須依此衡量模型。

但評測的耐久性比「持久資產」這種說法暗示的還短。 Boris Cherny 為其設下半衰期（YC 訪談，2026 年 7 月，practitioner-opinion）：當被問到評測是否是跨模型發布的穩定資產時，他提出異議——「它們比 harness 多存活一小段時間，但也沒多太久。某個評測也許能維持一、兩、三代模型……我們往往很快就把評測做飽和了，接著必須丟掉它，再想出新的評測。」持久的資產不是評測檔案，而是實踐——使用產品、觀察模型在哪裡遇到困難，然後據此重建評測集。評測比提示長壽，卻不如產生評測的專業實踐持久。

評測在 Cat 的除錯架構中的位置#

Cat Wu 的完整 PM 除錯架構分為三部分：

1. 請模型內省（Model Introspection Feedback）——模型做出意料之外的事時，詢問原因。模型的回答反映 harness 的缺口，而非模型本身的缺口。
2. 向小群品味敏銳的人快速取得回饋——五位具備判斷力、能說明模型與 harness 組合為何出色的人。Cat 在團隊午餐時做的 vibe-check 是標準範例。
3. 建立評測——第三種工具，速度較慢，但更持久。當 (1) 和 (2) 提出假設（「模型沒有充分測試自己」）時，評測就能大規模驗證假設，並避免修正後問題再度出現。

這三種工具彼此互補：

• (1) 提供假設（模型的自我回報）
• (2) 提供方向（品味敏銳者的判斷）
• (3) 提供證據與回歸防線（評測）

記憶是最需要評測的典型功能#

Cat 指出，記憶是最需要評測的功能：

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

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

• 輸出要回答的是「系統有沒有在正確時間記得正確的事？」——若沒有真值資料集，這種判斷就帶有主觀性。
• 失敗模式很容易誤診（「模型很愛寫記憶，但我們不確定品質好不好」）。
• 沒有評測時，修正循環很慢：你得讓真實使用者試用，才知道記憶改動究竟改善還是退步。

沒有評測，記憶功能的工作就會淪為憑感覺和軼聞判斷。有了評測，團隊就能量化「對我們在意的工作流程而言，這版記憶功能是否比上一版更好？」

怎樣才算「擅長評測」#

Cat 提出兩個參考案例：

• Amanda——Anthropic 中負責塑造 Claude's character 的成員。「這真是很難的職務，因為任務太模糊了。即使是程式設計也比較容易，因為你可以驗證成敗；但要塑造角色，就得非常堅定地相信 Claude 應該成為什麼樣的存在。」這項技能是把模糊目標說得夠精確，讓你能據此衡量進展。
• Claude Code 團隊午餐時的 vibe-check——像「這個模型沒有充分測試自己」這類回饋，會轉化成「好，那我們看哪些資料來確認這是不是一種模式？」接著變成「好，什麼評測能證明或推翻這個假設？」

模式一樣：對何謂良好有明確看法，並能把這種看法轉化為可衡量的產物。這就是以函式呼叫形式呈現的品味。

與 Matt Pocock 的驗證觀點連結（Design Concept Grilling）#

Matt Pocock 不使用「評測」這個詞；他的教學框架談的是「驗證」和「回饋循環」。但根本論點相同：在代理程式撰寫程式碼的工作流程中，回饋循環的品質決定了輸出的品質上限。Pocock 的深模組模式將整合測試列為 harness 的關鍵資產之一，因為模型需要能在循環中自行執行的驗證方式。

兩者的交集在於：PM 端的評測（Cat）和工程師端的整合測試（Matt）是同一種基本工具——可執行、能編碼判斷的產物——只是應用在產品的不同層級。

與《創辦人手冊》的連結（AI-Native Startup Lifecycle）#

手冊中的相關概念是在 MVP 階段**「於推出前建立衡量架構」**：

「把早期成長誤認為產品市場契合的創辦人，往往也是在產品推出後才開始追蹤資料，並使用只衡量哪些做法有效、無法揭露哪些做法無效的指標。解方是在第一位使用者出現前，先建立衡量架構。」

這是高一層的同一項技能：不是「這項功能的成功標準是什麼？」，而是「在這個市場、面對這些使用者，這項產品的成功標準是什麼？」手冊讓 Claude 成為評測設計夥伴（透過諮詢 Claude，「在推出前設計你的衡量架構」）。

創辦人若同時採納兩種觀點，就應撰寫產品層級指標（CAC、留存率、Sean Ellis score）以及功能層級評測（這項功能是否做到我們想要的事？最新版模型讓它改善還是退步？）。前者用來判斷公司是否繼續推進；後者用來判斷每項已推出的變更是否繼續推進。

轉折：評測撰寫本身也開始自動化（Google，2026 年 6 月）#

Google 的 Agent Quality Flywheel 是首個以這個前提推出的產品：**Cat Wu 認為新興核心 PM 技能的評測撰寫工作，也能由程式碼代理程式自行完成。**開發者只需用白話說出一項顧慮（「我的代理程式有沒有遵守對話中途的修訂？」）並批准；這項技能會讀取程式碼、選擇指標、設計客製評分規準、合成測試情境，並回報前後差異——「你完全沒寫這些……你只描述目標。」這並未推翻原論點，而是重新定位它，如同 PRD 的重新定位（Prototype Over PRD）：持久的人類技能會濃縮成精確說明成功標準、足以表達顧慮，以及判斷機器撰寫的評測是否真的編碼了這項標準。十個優質評測的原則也依然成立——飛輪的關鍵作法，是把一項顧慮轉化為一個穩定且可解讀的指標，而不是不斷累積一百個混雜指標。

規格成為獎勵訊號，規格本身也接受可證偽性測試（Shopify，2026 年 8 月）#

Shopify 的 Sidekick 說明（McNamara 與 Mazza-Anthony，Shopify Engineering，2026-08-05，case-study——第一手資料，尚未複驗）將本文論點重新表述為正式訓練循環的第一階段，並把利害關係再提高一層。Cat Wu 認為評測定義完成標準；Shopify 則認為評測也會成為目標本身：

「定義品質是循環中最重要的一步，也是團隊最常草率帶過的一步。一開始它是對良好標準的規格描述，之後便成為推動學習的獎勵訊號。若一開始定義錯誤，後續的一切就會朝錯誤行為最佳化。」

他們描述的評分規準幾乎逐字符合本文的用語——少數帶有具體評分依據的評分標準，「你的產品團隊對好與壞的定義」、「所有後續工作的品質契約」——但 PRD 規格錯誤會推出一項糟糕功能，評分規準規格錯誤則會訓練出糟糕的模型，而且每天持續訓練。這是目前最有力的論據，足以說明撰寫規格的技能為何稀缺；提出這項論據的團隊，動機在於描述工程工作，而非產品管理。

三項具體補充：

**在任何內容以規格為基礎建置之前，先對規格做可證偽性測試。**兩位專家標註者，針對草擬評分規準，對 25 個隨機抽樣的正式環境對話進行盲標註，並以 Cohen's kappa 衡量標註者間一致性；若約在 κ ≈ 0.2，便判定評分規準模糊並重寫——*「如果每天都在處理這項產品的幾位專家都會被評分規準搞糊塗，LLM 也會搞糊塗。」*本文語料中的其他內容都沒有測試產品規格作為規格是否成立。PRD 沒有這種關卡；一組十項手寫評測也沒有。這種做法成本低廉（兩個人、25 個項目），而且失敗時會清楚顯現。

明確規定：只有黃金集並不足夠。「真值也應包含隨機抽樣的流量，而不能只有精選範例。黃金集會測試你已經知道該留意的案例；隨機樣本則能揭露正式環境中好與壞實際是什麼樣子。」對照本文的核心建議來看，這是個實質限定：**十個優質評測就是一組黃金集**，由已經知道該擔心什麼的人挑選；黃金集的失敗模式則必然無法被看見。這是以正式環境資料為來源的評估論點，以撰寫指引而非基準測試方法的形式呈現。

還要要求解釋理由，而不只是分數。「只有分數和一句話，不足以讓校準演算法學習。你需要每個分數背後的理由*，這些推理非常寶貴。」*標註格式取決於下游最佳化器可以使用哪些資料，這是本文尚未涵蓋的評測撰寫限制：若評測要用來訓練某個系統，就必須能說明自身，而不只是給出判定。

評測還會指向另一個對象：代理程式本身的設定（Anthropic，2026 年 8 月）#

以上內容都把評測指向產品。Anthropic 的 Applied AI AI-Native SDLC playbook（vendor-claim，2026-08-21）則把評測指向 harness，並將它定位為 AI 原生 SDLC 移除的某項流程之直接替代方案：*「評測是 AI 原生的階段關卡 QA。」*過去 QA 在階段交界設關卡，如今只要代理程式設定變更，測試套件就會執行。

這套做法簡單而具體：平台工程師從近期工作中蒐集 20-50 項真實任務及其已接受的結果；每項任務都轉化為一項提示，以及定義可接受結果的檢查項目（測試通過、lint 無誤、行為不變、遵守政策）；測試套件依排程在 CI 中以非互動方式執行，並且在任何 CLAUDE.md、技能或 hooks 變更時執行——*「因為這些設定會引導代理程式，應該接受和程式碼一樣的回歸測試。」*若設定變更導致通過率下降，合併前就會接受審查，且通過率門檻會作為合併檢查強制執行。

三項特點讓這成為真正的新內容，而非重述舊觀點。

**受測單位改變了。**Cat 的評測固定模型，檢查功能是否正確；這裡則固定功能，檢查 CLAUDE.md 編輯或技能重寫是否讓負責建置功能的代理程式退步。這以評測形式回應了 Agent Context Files 從另一面記錄的缺口——人們不斷編輯脈絡檔案，卻無從得知修改是否有幫助——也最接近本文語料中將技能檔案視為具有測試套件之程式碼的做法；該文指出，53% 曾重複使用的技能從未修改過。

**每起事件都應由負責團隊撰寫一項評測。**永久性的回歸測試能避免修正只適用於單一案例，也是維護循環手冊的最後一步：控制區間遭到突破，接著進行診斷、修正，最後將案例納入測試套件。真正重要的落後指標是同類事件是否再度發生；若測試套件確實吸收了問題，這類事件就應減少。

測試套件明確具有時效性。*「隨著模型進步，曾經能分辨好壞的案例會失去效果；持續監測時出現的新案例則必須加入。」*這正是 Cherny 對本文第三個開放問題所提出的淘汰並重建方案，只是兩者獨立得出，且和他不同的是，這裡指出了替代案例的明確來源（正式環境監測，而非觀察到模型遇到困難）。這也承認了縮減問題，並未解決它。

全文都有原始資料本身的限制：沒有通過率、沒有測試套件規模、沒有成本數字；也承認有些團隊會依固定週期離線執行，而非每次變更都跑一次，因為代理程式評測會花費實際的 API 預算。階段架構請參閱已提交產物鏈。

十項評測從何而來（Shankar，2026 年 7 月）#

「十個優質評測勝過一百個平庸評測」的前提，是你知道該選哪十個。Cat Wu 的說明著重於評測的用途——編碼完成標準——大致沒有談到如何找出並列出評測。[[ai-assisted-error-analysis|Shreya Shankar 的錯誤分析工作流程]]正好補上這一步，並帶來本文欠缺的兩項內容。

**一項選擇規則。**資料中約 80% 的問題來自約 20% 的失敗模式，所以十項應該是最常見的失敗模式，而且常見程度是在發現之後測得，不是事前猜測的。如此一來，數量有限是失敗模式呈現 Pareto 分布的結果，而不是維護成本的預算——它用不同於本文原有兩項論據的理由，支持相同數量。

**自動化能推進到什麼程度的界線。**本文的轉折一節指出，評測撰寫本身也開始自動化，人類角色濃縮為說明顧慮並批准計畫。Shankar 將界線往下移一格，並認為這是結構上的限制：代理程式可以把人類撰寫的準則套用到整個語料，但要它提出準則，會產生比它所解決的撰寫問題更棘手的驗證問題——*「我不太喜歡只是試著驗證代理程式的品味這種做法。」*依照這個觀點，「表達顧慮」不是被濃縮的人類角色，而是不可再減少的角色；自動化只能到此為止。

她也指出本文視為一致的一項特徵：**不同應用需要的標準並不相同。**內部摘要工具和面向客戶的功能，值得投入的評測資源不同；應先推演最糟的使用者結果，再據此決定標準——規格涵蓋的範圍，首先是產品決策，之後才是撰寫決策。

為什麼這項技能在 2026 年「遭到低估」#

Cat 認為這項技能遭到低估，原因有三：

1. **文化。**2023 年前受訓的 PM 不寫程式，更不用說評測。撰寫評測需要熟悉資料集、評分函式和機率輸出——過去培養 PM 的流程並不會挑選出具備這組技能的人。
2. 地位。「撰寫測試」向來是地位不高的工程工作。評測也是測試，只是換了個包裝。撰寫評測的 PM 看起來像是在做 QA，實際上做的卻是產品規格。
3. **可行性。**多數 PM 沒發現自己其實可以撰寫更多評測，因為工具落差大，而且沒人教這項專業。Cat 所說的「十個優質評測」有一部分是在給予許可：不需要一百個，十個就夠了。

這預示近期職務定義會改變：能撰寫評測的 PM，推出產品的速度會勝過不會寫評測的 PM。Engineer PM Convergence 正是這項觀點所適用的框架——工程師和 PM 會融合成混合職務，而評測正是兩者最後都會負責的工作之一。

開放問題#

• 要如何為角色這類由品味驅動的功能撰寫評測？Amanda 的職務是評測難以處理的典型例子；Cat 在這裡稱她擅長評測，卻沒有說明方法。部分解答：如何為品味撰寫評測？以角色作為極限案例——方法是一套流程（信念 → 從親自使用中取得的失敗模式 → MSM-style 變體 A/B 測量 → 約 10 項可解讀的評測）；已在安全與價值核心案例中證實，但溫暖、風趣的美學表現仍未明確說明。
• 提出的 10 對 100 數字沒有理由。是否存在最適範圍，或要看功能涉及的面向多廣？Client-Side Agent Optimization 對組合的描述顯示，評測也有組合爆炸問題。部分解答（2026-08-13），並重新界定了衡量面向：Sidekick's continual learning loop（case-study）建議「讓每個 judge 保持精簡並專注，而不是把產品的所有行為都塞進一個 judge……專注的 judge 讓測試更容易解讀，也讓產生的指標更值得信任。你隨時可以再增加 judge。」因此需要限制的數量是每項工具涵蓋的行為數，而非每項產品使用的工具數——數量會隨產品面向擴大，單一工具仍能保持可解讀。實際理由比「維護成本」更精確：混合型 judge 無法通過逐項標準退化測試，因此拆解能讓評測在標準層級上可證偽，不只是可讀。數量本身仍是開放問題——沒有資料衡量拆分到什麼程度才不再有收益；這也是一項未經複驗的第一手說明。
• 評測如何與模型進步後 harness 縮減互動？模型可以原生處理某項工作時，harness 資產會縮減；圍繞舊 harness 建立的評測可能變成歷史產物，而非防線。Anthropic 會淘汰評測，還是重新利用？部分解答：Boris Cherny（YC 訪談，2026-07-27，practitioner-opinion）選擇淘汰：評測能維持「一、兩、三代模型」，之後便飽和、遭丟棄，再根據觀察到的困難重建；持續存在的是撰寫評測的實踐，而非評測本身。仍待解答：有沒有任何評測類型（安全、角色）能免於飽和循環？
• 是否有非 Anthropic 的 PM 撰寫評測案例可引用，還是這目前只是 Cat Wu 的個別觀點？Matt Pocock 的工作坊以不同詞彙得出相同結論，但還沒有納入第三個來源。**部分解答（但有轉折）：**Google 的 Agent Quality Flywheel 是第三方提出「評測就是品質核心」的案例，但其解方是讓程式碼代理程式撰寫評測，把人類角色濃縮為表達顧慮並批准計畫。第二個非 Anthropic 的案例（2026-07-03）則反對這種濃縮：Shankar & Husain 教導實務工作者把評測視為核心專業，並主張自動化的效益到撰寫階段就已用盡。但這仍不是由PM撰寫評測的案例——Shankar 是 CS 教授，Husain 是 ML 工程師，因此 Cat 主張的職務轉移部分仍只有 Anthropic 一例。

延伸閱讀#

• Skill Lift——把原則推到極致的案例：NVIDIA 直接從技能規格產生評測集，因此規格的精確度會成為衡量精確度的硬上限——廠商將此列為關鍵發現（「技能能被衡量到多精確，完全取決於評測集對工作描述得多精確」）；由於受測產物也替自己撰寫考題，因此形成循環論證

• Cat Wu——主要闡述者；在這個概念中居於核心地位

• Cost-per-Task Over Cost-per-Token——規格成為採購決策的案例：Anthropic 的選擇架構把最棘手的兩個問題（這項任務難不難？單位經濟是否可行？）交由「建立評測」來回答，因此真正用來選擇模型的是評測

• Claude Code / Cowork / Anthropic——這個概念發展的背景

• Claude Character as Product——Amanda 的職務；仍將難以評測的品味編碼下來

• Model Introspection Feedback——互補的除錯技巧（提供假設，而非證據）

• Harness Shrinkage as Models Improve——哪些事物不會縮減；評測是持久資產

• Engineer PM Convergence——融合後職務要求具備的混合技能之一：撰寫評測

• AI Native Product Cadence——只有評測提供回歸防線，快速產品週期才得以持續

• AI-Native Startup Lifecycle——「推出前建立衡量架構」是產品層級的對照概念

• Design Concept Grilling / Deep Modules for Agents——Matt Pocock 以驗證循環提出的框架；從工程角度切入同一種基本工具

• Claude Code Best Practices——以驗證為核心的開發方式；評測是更嚴格的版本

• Claude Character as Product——角色工作是難以評測、卻仍須評測的功能之極限案例

• Model Spec Science——對齊研究中的類比：實證衡量哪些規格特性能夠泛化，並將規格本身視為可透過評測測試的對象

• Verification as the New Bottleneck——Fiona Fung 提出組織層級的主張：程式撰寫變得便宜後，驗證（由評測編碼）成為稀缺資源

• Dogfooding as Product Discipline——評測會編碼品味；親自使用產品（「螞蟻食物」、午餐時的 vibe-check）能養成評測所編碼的品味

• The Verifiability Thesis——Karpathy 提出的「把能驗證的事自動化」；評測是以產品規格形式撰寫的驗證

• 如何為品味撰寫評測？以角色作為極限案例——最困難案例（品味／角色）的綜合方法：信念、親自使用產品、MSM 變體比較如何結合成可執行評測

• DRACO Benchmark——將評測延伸至基準測試規模：以專家評分規準作為評測集，自動評分

• LLM-as-a-Judge——以評分規準式評測衡量開放式輸出的方法；也是 DRACO 背後的評分基本工具

• Production-Sourced Evaluation——在基準測試規模上落實「從真實使用中建立衡量架構」

• Telemetry vs. Survey Measurement——Faros AI 提出的「衡量實際推出的內容，而非人們的感受」，是工程指標中偏好可執行評測而非自我回報的類比

• The Three Loops of AI-Native Building——對何時撰寫評測的實質分歧：Andrew Ng 把評測視為對重複失敗的反應（「如果你發現系統反覆遇到特定問題，建立一組評測就會很有用」）；Cat Wu 則在一開始就把評測寫成規格。Ng 的做法成本較低；當功能模糊到「它失敗了」無法不言自明時，你就需要 Cat 的做法

• Agent Quality Flywheel——自動化撰寫評測：程式碼代理程式把白話顧慮轉化為指標選擇、評分規準設計和前後差異；人類說明目標並予以批准

• LLM-Judge Validation——judge 評分的評測要值得信任所需的專業方法：機率校正、位置交換、複驗、跨基準測試，以及一致性與偏差稽核；「優質評測」的前提是 judge 有效

• AI-Native Organization——把評測用在組織自身的路由層：Tan 提出的「trigger evals」（正確的技能檔案有沒有載入？）在他的組織基本單位映射中，就像績效考核

• AI-Assisted Error Analysis——產生十項評測的發現步驟，以及評測撰寫自動化的極限所在；詳見上文

資料來源#

• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — 主要論述（時間戳約 55:00：「為何評測撰寫遭到低估」）；除錯架構一節也多次提及
• 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 — 以程式碼代理程式撰寫評測的示範（「你完全沒寫這些……你只描述目標」）（vendor-claim）
• Thread by @AndrewYNg — Andrew Ng，《The Batch》（2026-06-30），practitioner-opinion：評測是對重複失敗的反應，而非事前撰寫的規格
• 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 評分的評測，其主要指標可能不可信（kappa 低估、一致性與偏差悖論）；參見 LLM-Judge Validation
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Cherny，YC 訪談（2026-07-27，practitioner-opinion）：評測比 harness 多存活 1–3 代模型，就會飽和；持久的是實踐，而非產物
• Sidekick's continual learning loop — Andrew McNamara 與 Cody Mazza-Anthony，Shopify Engineering，2026-08-05，case-study（作者自家正式環境系統的第一手說明；未複驗，沒有對照組）：「先定義品質，它會成為獎勵訊號」一節——評分規準作為品質契約、兩位標註者／25 個隨機樣本／Cohen's-κ 模糊性關卡、隨機樣本不可只有黃金集的規則、分數必須附上推理，以及保持 judge 精簡的建議。完整來源分析見 Agent Quality Flywheel；judge 驗證部分見 LLM-Judge Validation