Arize 的 AI 產品經理 Aman Khan 在 AI Engineer World’s Fair 的工作坊中，從自駕車到 LLM Agent 的經驗出發，系統性地介紹了 AI 產品評估（Eval）框架。他強調「Vibe Coding」不足以應付生產環境的需求，提出「Thrive Coding」的概念——用數據驅動的評估方式取代直覺判斷，並透過現場 Demo 演示如何建立、執行和迭代 Eval，幫助 AI 產品經理在快速變化的 AI 時代中交付可靠的產品。
原影片連結：https://www.youtube.com/watch?v=2HNSG990Ew8
影片重點
- LLM 的非確定性本質使得傳統軟體測試方法不適用於 AI 產品，需要專門的評估（Eval）框架
- OpenAI 和 Anthropic 的產品負責人都公開承認模型會產生幻覺，Eval 正在成為 AI 新創公司的真正護城河
- 「Vibe Coding」只適合原型開發，生產環境需要「Thrive Coding」——用數據來驗證產出品質
- LLM as a Judge 是目前最具規模化潛力的評估方式，但仍需人類標註來校驗 Judge 的準確性
- 評估不只是看單一輸出，而是要在完整資料集上進行 A/B 測試，比較不同 Prompt 和模型的表現
- 作為 AI 產品經理，Eval 可以取代傳統 PRD 成為新型態的需求規格——「Eval 即需求」
- 建立 Eval 資料集是持續迭代的過程，類似自駕車從直線行駛到處理行人左轉的漸進式改善
- AI 時代的產品經理需要更高的技術素養，能夠直接使用 Cursor 等工具與程式碼互動
詳細內容
[00:00] 開場與自我介紹
Aman Khan 是 Arize 的 AI 產品經理，擁有工程背景。他的職涯從 Cruise 的自駕車評估系統開始（2018-2019），之後到 Spotify 負責機器學習平台與推薦系統（如 Discover Weekly、搜尋的 Embedding 應用），最後加入 Arize 已超過三年半，持續專注於 AI 評估系統。
Arize 的客戶包括 Uber、Instacart、Reddit、Duolingo 等技術前沿公司，從傳統機器學習（排序、迴歸、分類）起步，現已擴展到生成式 AI 和 Agent 應用領域。他們的核心使命是確保客戶的 AI 應用和 Agent 能如預期運作。
[02:30] 為什麼 Eval 如此重要
Aman 引用了多位業界領袖的觀點來強調 Eval 的重要性：OpenAI 的首席產品長 Kevin Weil、Anthropic 的 CPO Mike Krieger 都在 Lenny’s Conference 上公開表示他們的模型會產生幻覺，並強調撰寫 Eval 的重要性。Greg Brockman（OpenAI 共同創辦人）和其他業界人士也指出「Eval 正在成為 AI 新創公司的真正護城河」。
關鍵訊息是：當賣給你產品的人都告訴你產品不完全可靠時，你確實應該認真看待。許多來自自駕車領域的經驗教訓同樣適用於當今的 AI 應用開發。
[05:00] AI 產品經理的學習曲線
Aman 用類似 Dunning-Kruger 效應的曲線來描述 AI PM 的成長旅程。即便他本人在一家 Eval 公司工作，也經歷了同樣的過程：從學習如何在工作中使用 AI，到用 AI 工具建立原型，再到面對「如何將帶有 LLM 或 Agent 的產品推向生產環境」的挑戰。
在這個過程中，信心會經歷一個低谷——你會發現缺乏工具支援、缺乏關於如何可靠建構這些系統的教育資源。產品管理角色的期望正在改變，「AIPM」（AI 產品經理）的概念正在興起，來自利害關係人和工程師的期望也在不斷提高。
[07:30] 什麼是 Eval——與傳統軟體測試的關鍵差異
Eval 類似於軟體測試，但有幾個關鍵差異：
- 確定性 vs 非確定性：軟體中 1+1 永遠等於 2，但如果你說服 LLM Agent 1+1=3，它會贊同你。這些系統高度可操控。
- 多路徑執行：LLM Agent 可以走不同路徑，這和確定性的單元測試完全不同。你其實希望 Agent「以正確的方式產生幻覺」，這讓測試更加困難。
- 依賴數據而非程式碼：整合測試依賴既有的程式碼和文件，但 Agent 依賴的是你的數據。使用者選擇你的 Agent 而非其他方案，很大程度上是因為你的數據。
[09:30] Eval 的四個組成部分
一個 Eval 由四個部分組成：
- 角色（Role）：告訴 Agent 要完成什麼任務
- 上下文（Context）：提供要評估的文本內容
- 目標（Goal）：Agent 要判斷的標準（例如文本是否有毒）
- 術語與標籤（Terminology & Label）：給出好壞的範例和輸出選項
重要觀念：不要讓 LLM 直接產生數字分數，因為即使是 PhD 等級的 LLM 在處理數字時仍然很不擅長。應該使用文字標籤（如「toxic / not toxic」），再將標籤映射到分數。Arize 有研究證實這在大規模和多數模型上都成立。
[12:30] 從 Vibe Coding 到 Thrive Coding
「Vibe Coding」的現狀是：大家用 Bolt、Lovable 等工具寫程式碼，看起來差不多就行了，不太會仔細審查 AI 生成的程式碼。這在原型開發階段沒問題，但在生產環境中行不通。
Aman 提出用「Thrive Coding」取代——核心概念是仍然快速建構應用，但用數據來驗證輸出品質，從而對產出有更高的信心。
[14:00] 現場 Demo：AI 旅行規劃器
Aman 展示了一個用 LangGraph 和多 Agent 系統建構的 AI 旅行規劃器。這個應用接收目的地、天數、預算和興趣等輸入，由多個 Agent 協作產生完整的旅行行程。
系統底下有四個 Agent 協同工作：
- 預算 Agent：處理費用計算
- 在地體驗 Agent：尋找當地特色活動
- 研究 Agent：收集目的地資訊
- 行程 Agent：整合以上三個 Agent 的輸出，產生最終行程
[18:00] 可觀測性（Observability）：看見 Agent 的運作
透過 Arize 平台（也有開源版 Phoenix），可以視覺化 Agent 系統的運作方式。每個請求會產生 Trace（追蹤記錄），由多個 Span（工作單元）組成。Span 有三種類型：Agent、Tool（使用結構化數據執行動作）和 LLM（根據輸入和上下文產生輸出）。
對產品經理而言，能夠回到團隊並詢問「我們的 Agent 實際上長什麼樣」，看到系統的視覺化表示，這是非常有價值的。Arize 新推出的 Agent 視覺化功能可以清楚呈現平行呼叫和 Agent 間的資料流動。
[22:00] Prompt Playground 與迭代
Arize 提供 Prompt Playground，可以將追蹤到的 Prompt 及其變數拉入互動式環境進行修改和測試。這讓產品經理能夠：
- 直接修改目的地、行程天數等變數
- 切換不同 LLM 模型（如從 GPT-4o 換成 4.1 Mini）
- 添加新的 Prompt 指令（如「保持在 500 字以內」、「用超級友善的語氣」、「提供折扣以換取用戶 Email」）
- 版本控制 Prompt，類似 GitHub 儲存庫
一個值得思考的問題：撰寫 Prompt 應該是工程師還是產品經理的責任？如果你是產品負責人，對最終產品結果負責，你可能需要對 Prompt 有更多的掌控權。
[28:00] 從單一範例到資料集——規模化評估
用單一範例做「好或壞」的判斷無法規模化。團隊需要建立包含 10 個、100 個甚至更多範例的資料集，然後在整個資料集上進行 A/B 測試。
現場演示中，Aman 建立了兩個實驗：Prompt A（原始版本）和 Prompt B（修改版——限制字數、要求友善語氣、要求提供折扣）。結果顯示修改後的 Prompt 回應速度更快（因為限制了字數），但原始 Prompt 平均要 32 秒才能完成，因為沒有限制輸出長度。
[33:00] 建立與執行 Eval
Aman 展示了兩個 Eval 的實際建立過程：
- 友善度 Eval：判斷 Agent 回應是「friendly」還是「robotic」，定義了友善語氣的具體標準（upbeat、cheerful 等）
- 折扣 Eval：檢查回應中是否包含折扣優惠
執行結果顯示：修改後的 Prompt B 在所有範例中都成功提供了折扣（100% 通過）。原始 Prompt A 沒有折扣，但 LLM Judge 仍將其評為「friendly」——而 Aman 個人並不同意這個判斷，因為原始回應太冗長、太像機器生成的文字。
[38:00] 為 Eval 加上人類校驗——Eval 你的 Eval
核心觀念：你不能只信任 LLM as a Judge 的結果，還需要人類標註來驗證。流程是：
- 將資料集分配給主題專家進行人工標註
- 用程式化 Eval（如字串匹配）比較人類標籤和 LLM 標籤
- 找出兩者不一致的地方，改進 Eval Prompt
在演示中，比較結果顯示 LLM Judge 的友善度判斷幾乎完全不符合人類標籤——這正是需要改進 Eval 的信號。改進方式包括：增加 Few-Shot 範例、更嚴格定義「friendly」的標準、降低 Temperature 以減少變異、多次執行取平均。
Arize 平台也提供 Copilot 功能，可以幫助撰寫和優化 Eval Prompt。重要的是：你可能需要 5-10 次迭代才能得到一個與人類標籤吻合的 Eval，這是正常的。
[44:00] Eval 即需求——AI PM 的新定位
Aman 認為 Eval 正在成為一種新型態的需求規格。想像如果你能用 Eval 資料集和驗收標準取代 PRD 交給工程團隊，這將大大提升溝通效率和產品品質。
開發週期的循環是：開發階段用 CSV 資料和手動範例 → 持續策展資料集和重跑實驗 → 團隊有信心後推向生產 → 在生產環境中繼續用真實數據評估 → 將新發現的問題範例回饋到開發環節。
[47:00] 自駕車的啟示——漸進式改善
Aman 用自駕車的經驗做比喻：在 Cruise 時，車子一開始連一個街區都開不完。先解決直線行駛，然後左轉成了問題，就建立「左轉」資料集。左轉過關後，遇到行人在人行道上的情境，又需要建立「左轉 + 行人」的資料集。
關鍵啟示：你不會事先知道所有困難場景，只有在實際遇到時才會發現。所以要接受 Eval 資料集會隨時間不斷演進的事實，持續加入新的「困難範例」（hard examples）——那些模型判斷模糊、人類也覺得主觀的邊界案例。
[53:00] Q&A 精華：團隊建設與 PM 角色演變
工作坊的 Q&A 環節涵蓋了多個實務議題：
如何建立 Eval 團隊：建議先親自體驗撰寫 Eval 的痛點，了解什麼是困難的，再去面試和招聘。
PM 如何變得更技術化：在公司內部推動 AI 工具使用（如讓 PM 用 Cursor 存取程式碼），透過建構原型展示可能性，進而影響團隊文化。
技術人員是否也在變得更像 PM：當建構成本下降時，「建構什麼」變得比「如何建構」更重要。未來可能不再以角色定義自己，而是以技能組合（Skill Stack）來互補。
Human in the Loop 的新模式：有公司正在嘗試將人類設定為 Agent 的工具——當 Agent 遇到無法處理的事務時，自動透過 Slack 發送訊息給 CFO 等人獲取資訊，再繼續執行。
我的想法
這場工作坊最打動我的觀點是「Eval 即需求」的概念。傳統上產品經理用 PRD（產品需求文件）和 User Story 來規範產品行為，但在 AI 產品中，自然語言描述的需求天然地充滿模糊性——而 Eval 提供了一種更精確、可量化的替代方案。如果團隊能夠共同定義「什麼算好的輸出」並用資料集驗證，這比任何文件都更有說服力。
另一個值得關注的洞察是 LLM as a Judge 的可信度問題。演示中 LLM Judge 幾乎完全不符合人類的友善度判斷，這提醒我們即使在「用 AI 監督 AI」的模式下，人類校驗仍然不可或缺。對於高風險領域（醫療、法律、金融），這個人機驗證的閉環更是不能省略。
最後，自駕車漸進式改善的比喻非常實用。許多團隊在 AI 專案中追求「一次到位」的完美 Eval，結果反而拖延了上線。更務實的做法是：先用基本的 Eval 達到「足夠信心」就上線，然後在生產環境中持續收集困難案例，逐步提高系統可靠性。這種迭代心態可能是 AI PM 最需要培養的核心能力。
進階測驗：AI 產品經理的評估框架
共 5 題，包含情境題與錯誤診斷題。
