LifeVal 把評測帶進日常生活：高分之外，怎樣才算把事情辦完？

請 AI 整理一份週末採買清單，和讓它替一家人完成採買，是兩種驗收。清單可以看內容是否合理；後者還得確認品項、預算、配送時段，以及最後究竟有沒有下單。當助手開始操作工具，「回答看起來不錯」就不足以描述結果。

OpenAI 於 2026 年 11 月 2 日公布的 LifeVal 評測生活任務。選題參考美國 ATUS、跨國 MTUS 時間使用研究，另調查 3,995 人了解需求。這個人數是調查受訪者數，不是測試題數。官方展示的是個別任務例示分數，不能讀成整體成功率或現實交付機率。

本文接著討論的是如何閱讀這類評測，以及替自己的助手設計驗收。以下採買情境由本文設計，不是 LifeVal 題目，也不是本文實測結果。

需求調查回答「值得做什麼」，驗收回答「做到哪裡」

一件事讓人耗時，或是很多人想請助手代勞，都能成為選題理由。但知道需求存在，並不等於已經量到代理做得多可靠。讀評測時，可以先分開兩個問題：它選的事情是否貼近生活，以及它如何判斷事情完成。

以採買為例，使用者說「幫我準備週末的食材」，可能只想取得清單，也可能期待比較商店、放進購物車，再交自己確認。若驗收只檢查文字建議，再漂亮的結果也回答不了後面幾個問題。反過來，若任務要求停在購物車，代理直接付款也不能因為食材買到了，就被算成更好的表現。

因此，我認為日常代理的第一份測試文件應該是交付約定：要產出什麼、要停在哪裡、哪些偏好還缺答案。這是本文的設計建議，並非 LifeVal 已公開採用的評分規則。

一個分數，還需要哪些條件才能比較？

本次讀取的 LifeVal 公告主文與五個可見例示，未完整交代模型版本、全套題數與評分細則；互動「See more」未逐項核讀。這是公開頁面的資訊邊界，不能推論研究沒有這些設計；同樣也不能自行補出分數的分母、重試次數或整體平均。

理解這個缺口，可以參考 OpenAI 在 2026 年 5 月 29 日的舊背景文章：第三方評估原則。它指出，代理周圍的執行安排，也就是 harness，會影響測得的表現；比較系統時，要交代任務、工具、評分及預算條件。這篇文章提供閱讀框架，不是 LifeVal 的方法補充文件。

放回採買情境，同一個模型若只能搜尋商品，或已能存取商店帳戶和購物車，遇到的任務就很不同。允許花多久找替代品、工具失敗後能重試幾次，也會改變結果。這些是本文的示意推演，並未在此執行比較。

所以，當條件未明時，較有用的閱讀方式是保留問題：測的是哪一套系統、允許哪些動作、結果如何判定。先記下未知，比替展示分數加上「這次委託大概有幾成會成功」更能幫助後續判斷。

自己驗收時，把「失敗後怎麼辦」也寫進去

如果想把評測觀念用在自己的助手上，可以先挑一件重複發生、結果能查核的小事。以下仍以採買為例，提出一組本文設計的驗收條件：

這些條件不必合併成一個總分。把錯誤分開記，才能看出是推薦內容不合適、工具參數錯了，還是代理在不該繼續時繼續操作。對使用者來說，能清楚停下並交回決定權，也可能是一次符合約定的交付；是否算成功，應先由任務定義決定。

OpenAI 的 Evaluation best practices 現行文件 建議按具體任務設計測試，以人類判斷校準指標，持續加入新案例，也涵蓋邊界情況。這些原則可以用來逐步修訂上述驗收表；它們不證明 LifeVal 已逐項實作相同檢查。

讓生活任務成為自己的測試，而非直接套用展示分數

對日常代理，我更想知道的是：在自己的預算、資料與授權條件下，它能穩定完成哪一段工作；遇到另一種說法、缺少資訊或網站出錯時，還能不能交代清楚。

可以先保留幾次人工查核過的結果，再把新遇到的失敗加回測試。比較下一個版本時，沿用相同任務與條件，同時看有沒有少犯錯、需要多少人工補救。這是本文建議的使用方式，不是 LifeVal 公告提供的個人部署保證。

LifeVal 值得關注的問題，是生活中的需求能否成為更貼近使用者的評估對象。至於一項具體委託能不能交給代理，仍要回到可觀察的交付、操作邊界，以及失敗時可接手的證據。