Eval 能自動化多少，取決於你寫下了多少標準

2026 年 7 月 11 日，Hamel Husain 與 Antaripa Saha 在 Parlance Labs 的部落格發表了一個對照。Hamel Husain 在文中自述是 AI Evals 課程的共同講師與 O'Reilly《Evals for AI Engineers》的共同作者，Saha 的職稱文章沒有交代。他們拿 100 筆真實租屋客服 AI 的 trace（一次對話從頭到尾的紀錄，含工具呼叫），請領域專家手標出 39 個失敗，再遮起標記，交給三個評測平台和三個 coding agent 各自去找。找回最多的一個，找回其中 87.2%。

你可能已經對 Claude Code 說過「幫我評估這個 app」，手上也有一個裝滿 trace 的資料夾。Shreya Shankar 說，這樣做五分鐘後 AI 會交回一份看起來很合理的清單。她在演講開頭自我介紹是電腦科學教授，與 Hamel 共同創作 AI Evals 課程；演講在 2026 年 7 月 3 日上傳到 Hamel 的 YouTube 頻道（只標上傳日，現場日期未說明），內容是這份清單漏掉什麼，以及她改用什麼流程。

快速回答 Eval 的步驟可以請 AI 幫忙，但「什麼算好」要由看過資料的人自己說出來。Shreya Shankar 2026 年 7 月的演講列出三個常見錯誤：叫 coding agent 直接評估、只看一遍資料、所有應用共用同一個準確度標準。Hamel Husain 團隊的 100 筆 trace 對照中，最好的系統找回 87.2% 的人工標記失敗，六個系統都漏掉看起來正確、卻沒達成產品目標的對話；樣本只有 39 個失敗。

三個錯誤各長什麼樣子？

Shankar 在演講裡列出三個用 AI 自動化 Eval 時容易犯的錯：叫 coding agent 直接評估整個 app、只看一遍資料、所有應用共用同一個準確度標準。下表整理她的說法，「修正」欄對應她結尾投影片的三條建議；每一列在後面有各自的一節。

表裡的「品味」是 Shankar 的用詞，指做產品的人心裡對好壞的判斷。她的主張是這份判斷沒寫下來之前，AI 讀不到。

Eval 的哪幾步適合交給 AI？

Shankar 的答案是越後面的步驟越能交給 AI：找出錯誤最依賴品味，量測與改進這兩步，AI 幫得上更多。

她把 Eval 拆成三步循環。分析（analyze）是讀 trace，找出失敗模式（failure mode，指一類反覆出現的錯）；量測（measure）是估每一類多常發生；改進（improve）是回頭修產品，例如加一條 prompt 指令、換模型或微調。她說分析最難，因為「壞」沒有標準答案：監督式機器學習有標籤，失敗就是預測不等於標籤；寫作助理的「AI 腔」卻帶著「know-it-when-I-see-it」（看到才認得出來）的性質。量測這一步，她提到 Pareto 原則：資料裡 80% 的問題，常由 20% 的失敗模式造成，所以先處理最常見的幾類。

她對 AI 角色的說法是：「AI is not very good at automating the early parts, the error analysis parts.」（約 5:25）越往循環後面走，AI 能代勞的越多。

評測工具的廠商走另一個方向。LangChain 在 2026 年 5 月 13 日發表 LangSmith Engine，部落格作者 Ben Tannyhill 寫它「replaces the manual cycle of reading traces, spotting patterns, and writing fixes」（取代讀 trace、找規律、寫修正的人工循環）。Braintrust 的文件說 Loop 會依排程調查 trace，把反覆出現的問題記成附證據與建議修法的 pattern（文件頁沒有標日期，本站 2026-10-23 讀取）。Arize 的文件把 Alyx 定位為 Arize AX 內建的「AI engineering agent」，能「Investigate failures, build evaluations」（調查失敗、建立評測）。以上都是廠商自己的說法。

Shankar 把這些工具的願景概括成端到端：接上 trace，它告訴你哪裡壞了，還替你修。她說「I would love for it to be true」，但經驗是這些工具「can find some errors, they're not a cure-all」（約 1:40）。理由她稱為認識論上的：「What good means for your product is living in your head.」（約 1:45）工具若能完整替你建出並修好產品，也能替所有競爭對手做同一件事，產品就沒有差異，所以她說判斷力是產品唯一的差異化因素。Hamel 與 Shankar 在 2026 年 3 月 2 日合寫的〈Evals Skills for Coding Agents〉（8 月 31 日修改）開頭寫：「Eval tools often get in the way. They nudge you toward generic off-the-shelf metrics and fully automated evals before you've looked at your data.」

歸納一下，分歧在順序。評測平台的流程是 trace 進、問題清單出；Shankar 與 Hamel 要人先看資料，AI 負責整理、回掃與提建議，收不收由人決定。重疊的地方也看得到：Hamel 與 Saha 的實測裡，六個系統都找到人工標記漏掉的問題，Shankar 的主張是 AI 找得到一部分，找不齊。

錯誤一：叫 coding agent「評估這個 app」，會漏掉什麼？

Shankar 指出三個問題：agent 找不到沒寫進 trace 或 prompt 的品味問題、排不出真正的優先順序、結果也無法重複使用。

她用自己研究裡在做的 AI 寫作助理示範常見的用法：打開 Claude Code，指向存了所有輸出的檔案，請它評估。投影片 15（約 6:35）是 Claude 的回報，四項依序是：口吻重複（21% 的 AI 文章以「I used to...」開頭，人寫的文章是 0%；58% 以第一人稱軼事開頭，人寫的是 2%）、結構公式化（軼事、轉折、4 到 6 個 H2、樂觀收尾）、慣用語（「the good news」在 AI 文章出現 9 次，人寫的 0 次；平均每句 13.4 個字，人寫的 17.4 個字）、長度太一致（AI 文章集中在 930 字上下，範圍 868 到 1,032；人寫的從 453 到 5,086）。

這份清單不差，她說「I'm sure many of these are issues we want to fix」（我相信其中很多是我們想修的）。她的三個批評是：第一，「anything that lives in your head that's not externalized in the traces or in the prompt, you're never going to find it.」（約 6:51）第二，清單把「口吻重複」排第一，這個說法本身就很模糊，也未必是最該先修的；她說 agent 常常連最高優先的問題都會編出來，真正的重點可能是別的怪句或幻覺。第三，每次請 AI 找問題，它都從頭讀資料、重新想失敗模式，下次換一批 trace，前一次的成果沒有留下。她想要的是把中間產物存起來，例如失敗模式的定義，放在記憶或程式裡。

她的修正：沿用自己的流程，只請 AI 做其中幾段

Shankar 的做法是不把整件事交出去，只請 AI 設計人在迴圈裡的介面，寫成 error-discovery skill（skill 指寫給 coding agent 的工作說明檔）。以下依公開版 SKILL.md 整理，本站 2026-10-23 讀取，該檔最後一次改動在 2026-08-16。

1. 理解資料：讀 5 到 10 筆紀錄，判斷是文章、輸入輸出配對、多輪 agent trace、程式碼還是結構化輸出。
2. 設計視覺編碼：每個變動維度只用一種視覺通道，例如顏色表示說話者。有一條規則很具體：不要依角色淡化內容，因為系統訊息、工具結果與思考區塊裡都可能藏著真正的 bug。
3. 建審查介面：Python 標準函式庫的 HTTP 伺服器加一個單檔 HTML，沒有依賴。三個視圖：逐筆內容、全部紀錄的二維分布圖、進度。人選取文字、輸入一句話、按 Enter 就存成標註。
4. 分群與取樣：分群是把相似的樣本歸成一堆，讓人只看每堆的代表；分成 6 到 10 群；資料超過 50 筆時先取 15 到 25 筆，約六到七成是各群的代表，三到四成隨機抽，補分群沒抓到的維度。SKILL.md 寫明取樣只為了找出各種失敗模式，每一類多常發生，留給量測那一步去估。
5. 互動審查迴圈：人標註，agent 持續監看並整理分類，細節在錯誤二那一節。

現場示範的資料是 33 篇 AI 生成的文章；agent 分成 6 群、挑出 21 篇給人審，建完介面花了 4 分 42 秒。她留的註記包括：不要每句都帶冒號、要用完整句子、不喜歡先否定一個說法再改說另一個的對比句型。agent 把註記歸成兩個失敗模式：口語片段與冒號插入語，以及對比式句型。她說這讓她意識到這些偏好該寫進系統提示：「I thought the AI should simply know.」（約 18:25）分析產出的是一組你從沒寫下的標準，改進這一步才是回頭修改 system prompt。

她也直接講缺點。取樣方面，她說讓 LLM 找特徵來分群「is very much a guess」（約 12:37）；最初的版本要 agent 做 embedding 再 K-means，後來發現 embedding 不一定合適（約 13:04）。她說：「I don't know of anyone who has a great error discovery skill.」（約 14:04）現場的介面也粗糙，同一個顏色用了兩次；agent 一開始沒有照 skill 用 Monitor（Claude Code 內建、讓背景指令的輸出變成通知的工具）監看標註，她當場追問（約 17:02），監看事件才出現，她說這種時候要連哄帶勸（「coax and cajole」，約 17:17）。

工程上的意思： 這套流程拆成三個元件。一是審查介面，人在原文上標註、每次標註自動存檔。二是監看程序，把檔案變動變成 agent 的事件。三是會留下來的分類清單，換一批 trace 還能接著用，對應她批評的「每次從頭來」。SKILL.md 把資料放在 error_discovery_data/ 目錄的五個 JSON 檔：samples、annotations、graph、patterns、suggestions。監看方式，Claude Code 用 Monitor 工具（persistent 模式），每 2 秒比對 annotations.json 的內容；其他 agent 則寫一支輪詢腳本，輸出附加到 log 檔，SKILL.md 明說不要用 inotifywait 這類檔案系統事件，理由是跨平台可靠。

本站建議： 想自己驗證，最小的監看程序只要會比對檔案內容。下面是依上述描述寫的簡化版，skill 的實際寫法請看它的 review-loop.md；標註檔假設是一個 JSON 陣列，每筆有 id 與 note。

import json
import time
from pathlib import Path


def snapshot(path: Path) -> dict | None:
    """讀出目前所有標註，回傳 {id: 標註}；檔案寫到一半（解析失敗）時回傳 None。"""
    try:
        rows = json.loads(path.read_text(encoding="utf-8"))
    except FileNotFoundError:
        return {}
    except json.JSONDecodeError:
        return None
    return {row["id"]: row for row in rows}


def watch(path: Path, every: float = 2.0, rounds: int | None = None) -> None:
    """每隔 every 秒比對一次，新增或被刪掉的標註各印一行。"""
    seen = snapshot(path) or {}
    count = 0
    while rounds is None or count < rounds:
        time.sleep(every)
        count += 1
        now = snapshot(path)
        if now is None:  # 這一輪讀到半寫入的檔案，下一輪再比
            continue
        for note_id in sorted(now.keys() - seen.keys()):
            print(f"+ {note_id}: {now[note_id]['note']}", flush=True)
        for note_id in sorted(seen.keys() - now.keys()):
            print(f"- {note_id}", flush=True)
        seen = now

本站用一個先寫入 a1、再加入 a2、最後刪掉 a1 的測試檔，以 watch(path, every=2.0, rounds=3) 跑過，輸出依序是三行：

+ a1: 句子不要用冒號
+ a2: matters 出現太多次
- a1

三行都出現，代表新增與刪除都偵測得到。演講現場，是監看事件觸發之後，agent 才去讀新標註並歸類（約 17:32）。

錯誤二：只看一遍資料，為什麼會漏掉新的失敗模式？

因為標準是在看資料的過程中長出來的：看過的樣本越多，腦中能互相比對的組合越多，才發現原本沒想到的失敗。Shankar 說「when you've seen more traces, you have more traces living in your head, then you can actually do better analysis」（約 19:46）。

她的例子發生在同一場示範：審到第三篇文章時，她注意到「matters」這個字每篇都有，包括前兩篇已經審過的。她說「Once I tell you this matters thing, you're never going to unsee it.」（約 20:25）她說這是看過這個字很多次之後才發現的。

這個現象有研究依據。Shankar 與四位共同作者在 2024 年的 arXiv 論文〈Who Validates the Validators?〉（作者全名見參考資料）裡，把它命名為 criteria drift（標準漂移）：使用者要有標準才能評分，而評分的過程又幫使用者定義標準。論文還指出，有些標準取決於實際看到的輸出，不能事先定義。Hamel 在 2026 年 3 月的〈The Revenge of the Data Scientist〉寫過同一件事：「It is impossible to know what you want unless you look at the data.」Hamel 與 Saha 的實測也遇到了：他們做租屋客服 AI 時，是讀到一筆潛在租客轉身離開的對話，才發現需要處理銷售異議。

她的修正是讓 agent 幫忙回頭掃。標完約 5 筆之後，每出現一個新的失敗模式，agent 就去已標與未標的資料裡找同一種問題：命中已看過的資料，可能是你當時還沒有這個標準而漏標（criteria drift）；命中沒看過的資料，是新的覆蓋。她在現場接受了 agent 建議的幾筆口語片段，也接受了一筆她漏掉的對比句。投影片 21（約 22:40）的三條結論是：不要一次定案所有失敗；同時做外圈（outer loop，反覆讀整批資料）與內圈（inner loop，同一筆資料裡輪流驗證不同的失敗假設）；每新增一個失敗模式，請 agent 回頭檢查舊紀錄再交你審。

review-loop.md 對這個機制寫得更細。

• 約標註 5 筆不同紀錄之後，才做第一次全量掃描，因為更少的標註不足以代表你認為什麼是失敗。
• 每個失敗模式派一個背景子任務（subagent），回傳 {record_id, text, start, end} 形式的建議。
• 建議偏重召回率，精確率其次：誤報很快就能略過，漏掉真實的例子代價高；建議與人的標註分開顯示，由人逐條接受或略過。
• agent 在人讀完一批、發現新模式後，會提醒回頭重讀舊紀錄；新發現的比例下降時，建議停止或收斂範圍。文件沒有給固定的輪數。

她刻意沒讓 agent 提新的失敗類型。以前的版本要 agent 建議，她發現有些同意、有些不同意，「I don't love the experience of just trying to validate the agent's taste」（約 22:06）。她要自己說，再讓 agent 把這句話套到更多筆資料上。agent 能標出同一種問題的實例，但並不窮盡；她把它定位成加速自己審查的工具。

工程上的意思： 掃描是「每個失敗模式一個工作」，輸出是建議佇列，每筆帶「已看過、當時漏標」或「沒看過、新覆蓋」兩種標籤。人的標註檔就是這個迴圈的輸入來源，所以標註要存成機器讀得到的格式，留在人的筆記裡就沒有用。

本站建議： 想自己看這兩個標籤長什麼樣，下面用五筆自編的短文，並以字串比對代替 agent 的子任務，只示範「已看過」與「沒看過」怎麼分流。

RECORDS = {
    "essay-1": "Container gardens matter. Start small.",
    "essay-2": "Pick the right pot. Why it matters: drainage.",
    "essay-3": "Water daily. This matters in summer.",
    "essay-4": "Herbs grow well on a sunny sill.",
    "essay-5": "Light matters most for tomatoes.",
}
REVIEWED = {"essay-1", "essay-2", "essay-3"}


def scan(records: dict, reviewed: set, phrase: str) -> dict:
    """在所有資料裡找 phrase，分成「已看過的」和「還沒看的」。"""
    hits = sorted(rid for rid, text in records.items() if phrase in text.lower())
    return {
        "已看過、當時漏標": [rid for rid in hits if rid in reviewed],
        "沒看過、新覆蓋": [rid for rid in hits if rid not in reviewed],
    }


print(scan(RECORDS, REVIEWED, "matters"))

本站實際執行的輸出是：

{'已看過、當時漏標': ['essay-2', 'essay-3'], '沒看過、新覆蓋': ['essay-5']}

essay-1 寫的是「matter」，字串比對沒有抓到，這是關鍵字做法的限制。Shankar 用 agent 掃而不用關鍵字，本站推測是為了抓這類變形說法；她說 agent 找得到實例但並不窮盡，演講沒有給召回率。

錯誤三：所有應用共用同一個準確度標準，會出什麼問題？

準確度的門檻要看應用的使用情境：Shankar 說內部工具可以容忍較低的準確度，面向客戶的流程要高很多，所以不該對每個應用投入同樣的 Eval 力氣。

她舉的內部工具是自己用的 Slack 討論串摘要與資料摘要，不必完美準確，不值得花太多時間做 Eval；面向客戶的東西，則要花更多力氣把準確度拉高。投影片 22（約 23:20）寫成三行：沒有通用標準，內部工具可容忍低準確度，面向客戶的管線需要高準確度。

她決定嚴格度的方法，是先推想最壞情況：把一批 trace、應用的描述，或整個程式碼庫交給 Codex 或 Claude Code，請它站在使用者的立場想最糟的事。以寫作助理為例，她提到引用出了問題（自動字幕寫成「sabotaging the citation」，原意以影片為準），以及洩漏私人資訊：記者寫稿時蒐集的資料，不應該出現在文章輸出裡。這些最壞情況告訴她要設哪些 eval 和護欄。

Hamel 與 Saha 的實測顯示這件事為什麼重要。租屋客服 AI 的「該轉真人的對話沒有轉」，沒有任何系統可靠抓到：物業規定某些對話要轉人工，trace 裡卻沒有說哪些情境承諾要升級。我的歸納：這類失敗的線索在產品規則裡，事先想過最壞情況，才寫得出對應的檢查。

工程上的意思： 最壞情況清單決定每個應用要做哪一層的 Eval，之後每一條再分流到檢查方式。Hamel 的 evals-skills 在 2026 年 9 月 24 日新增了 write-code-eval：外部貢獻者 Randy Olson（GitHub 帳號 rhiever）提交，Hamel 修改措辭後合併。這份 skill 開宗明義：「Start with a failure mode found through error analysis. Write one check for that failure mode, much like a unit test that asserts what should hold for each trace.」它的對照表給了幾種做法：輸出結構無效就解析並檢查必要欄位；出現缺漏或禁用文字就比對字串或樣式；引用不在檢索結果裡，就比對引用的 ID 與檢索到的 ID；工具呼叫錯誤就對照工具的 schema；值錯誤就和參考值比較。規則需要解讀的，改用 write-judge-prompt，也就是 LLM 評審。

我的看法：每個應用在 Eval 開工前先寫一張最壞情況清單。內部工具寫三行就好；面向客戶的，寫到每一行都有人說得出「擋住它的檢查是什麼」，說不出來的那幾行，就是還沒有 Eval 保護的地方。這個做法是本站的建議，Shankar 的演講只講到用最壞情況決定 Eval 與護欄，沒有談到清單格式。

現成的自動化工具實際找得到多少？

在 Hamel Husain 與 Antaripa Saha 的對照裡，六個系統找回 74.4% 到 87.2% 的人工標記失敗，精確率落在 77.4% 到 91.0%。

資料是前面提過的 100 筆 trace，來自 Nurture Boss（一家做租屋管理 AI 助理的公司），資料不公開。所有系統收到同一段刻意簡短的提示，沒有提到已知的失敗。召回率是 39 個失敗找回幾個；精確率是被標出的問題裡有幾個是真的，其中包含人工審查漏掉的真問題；新發現是人工審查沒有的有效標記。

文章寫到，每個系統在失敗一眼可見時都表現得好：沒有依據的排程說法、一再重複索取用戶已給過的確認、承諾後續卻沒有做、回答和工具輸出矛盾；每個系統也各找到 17 到 20 個人工審查漏掉的小問題。各系統的特點：Braintrust Loop 召回率最高，常見的誤報原因是對完整性要求太嚴；Arize 的 Alyx 精確率 91.0%，只有 3 個誤報，召回率較低；LangSmith 的介面最適合逐筆看 trace，但專找重複問題的 Engine 只找出很少的問題，計分改用它的 chat agent，且有幾個錯誤發現被標成高嚴重度，會誤導該先修什麼。

所有系統共同漏掉的，是 trace 看起來正確、卻沒達成產品真正目標的情況：業務型的 agent 在第一個異議出現就放棄，沒有處理客戶的顧慮；簡訊裡用了 Markdown，到手機上變成多餘的星號與井字號；語音 agent 搶話；以及前面提到的該轉真人卻沒轉。這四類單看 trace 都看不出來，因為 trace 沒有說明對話是簡訊，也沒有說哪些情況承諾要升級。作者預料到「那你把背景給它不就好了」這個反駁，回答是團隊無法提供自己還沒發現的背景，這也是 criteria drift。

Shankar 的演講與這篇文章有一處說法不同，值得並排看。演講（7 月 3 日上傳）的投影片寫「General purpose coding agents > dedicated discovery platforms」，她說通用 coding agent 往往比一些專門平台更全面，這讓她很意外（約 24:47）。7 月 11 日的文章則寫：只看發現的品質，coding agent 和專門平台「roughly even」（大致相當），平台的優勢在周邊流程，例如把發現連回來源 trace、提供審閱與標註的地方、新 trace 進來能重跑。我的歸納：表中 coding agent 的召回率是 79.5% 到 84.6%，平台是 74.4% 到 87.2%，範圍重疊，單看這張表很難支持「通用 agent 勝出」。作者也明說，這是一個資料集、39 個失敗，差距只差幾筆 trace，無法證明哪家廠商更好；他們說與任何廠商沒有關係、沒有收到贊助。

還有一件事要先講明：Hamel 與 Shankar 都開 AI Evals 課程，Shankar 在演講結尾提到今年秋天的新版課程，Hamel 的文章結尾也附了課程連結。「人要留在迴圈裡」同時是他們的主張，也是他們教的內容。

兩人的結論有交集。Hamel 與 Saha 的建議是自己標 trace，讓 AI 從標註持續學習，他們寫道沒有任何系統做到最有幫助的一件事：訪談使用者。Shankar 在演講最後也指向人這一端：「I don't know of a way for AI to probe you 20 questions style for how to externalize taste very good.」（約 27:03，自動字幕）她說看資料是最好的辦法，因為資料會觸發你對應用的疑慮，再把它說給 AI 聽。

演講之後，這套 skill 改了什麼？

公開紀錄顯示，改動集中在三處：第一次全量掃描的門檻、監看方式能在 Claude Code 之外使用，以及從單一 skill 擴成含 9 個技能的 plugin。

這個倉庫原本是 shreyashankar/error-discovery-skill，後來改名為 ai-evals-course/evals-skills（GitHub 自動轉址）。演講在 7 月 3 日上傳，下表是之後的提交紀錄，本站 2026-10-23 讀取。

最後兩列（8 月 31 日改名與 Codex 套件、9 月 24 日 write-code-eval）都在演講上傳約兩個月之後。目前的 README 列了 9 個技能，error-discovery 是其中之一。要安裝 error-discovery，README 的指令是：

npx skills add https://github.com/ai-evals-course/evals-skills --skill error-discovery

資料可以是 JSONL、CSV 或 JSON，內容是 LLM 的輸出或 trace。SKILL.md 寫明這個 skill 只用在互動式 session；如果是 codex exec 或 claude -p 這類非互動執行，agent 只建好並測試介面就停下來，給出之後啟動的指令，不會宣稱審查迴圈跑過。

有一處說法值得留意。Shankar 在演講裡說她的 skill 沒有指定怎麼分群；但公開的 SKILL.md，2026-06-25 的版本與目前的版本都寫「Cluster using KMeans or similar on normalized features」，要求 6 到 10 群。兩者並存，文件沒有說明差異的原因，本站也無法判斷她在演講裡指的是哪一版。

還沒有答案的三件事

1. 取樣怎麼取才好。 Shankar 說 LLM 取樣「very much a guess」，skill 讓 agent 自己找特徵分群，演講沒有給驗證取樣好壞的方法，Hamel 與 Saha 的文章也沒有談取樣。
2. agent 不照 skill 做事怎麼辦。 演講現場 agent 一度沒用 Monitor 工具，她得當場追問；文件沒有說明怎麼讓 agent 穩定照做。
3. 品味有沒有比看資料更省力的說出方式。 Shankar 說她不知道有什麼辦法讓 AI 用 20 個問題問出品味；Hamel 與 Saha 試過的系統，也沒有一個先訪談使用者。

AI 讀不到你沒寫下的標準。

常見問題

Eval 可以直接叫 Claude Code 全部做完嗎？

Shankar 的看法是不行：agent 會找到一些問題，但抓不到沒寫進 trace 或 prompt 的品味問題，優先順序常常排不出來，甚至會編，每次還要從頭來。Hamel 與 Saha 的對照裡，Claude Code（Opus 4.8）找回 79.5% 的人工標記失敗，精確率 77.4%，有 14 個誤報。這只是一個資料集的結果。

error-discovery skill 怎麼安裝？需要什麼資料？

用 npx skills add https://github.com/ai-evals-course/evals-skills --skill error-discovery 安裝。資料是 JSONL、CSV 或 JSON 檔，內容是 LLM 的輸出或 trace。SKILL.md 寫明只用在互動式 session，非互動執行只會建好介面並停下來。

trace 要看幾輪才夠？

文件沒有給固定的輪數。SKILL.md 的做法是約標註 5 筆不同紀錄後做第一次全量掃描，每次發現新模式就提醒你回頭重讀舊紀錄，新發現的比例下降時才建議停止或收斂範圍。

內部工具和面向客戶的應用，Eval 要差多少？

Shankar 沒有給數字。她的說法是內部工具可以容忍較低的準確度，面向客戶的流程需要高很多；嚴格度用最壞情況來定，把 trace、應用描述或程式碼交給 AI，請它站在使用者角度想最糟的事。

延伸閱讀

• LLM Eval 怎麼做才不會被騙？跑越多組，第一名越可能只是運氣（2026 實驗設計懶人包）
• AI 寫的測試全過，為什麼功能還是錯的？驗證閉環完整懶人包（2026）
• Agent Memory 是什麼？AI 該記什麼、誰批准、何時刪？（2026 完整懶人包）

參考資料

• Shreya Shankar, How to Automate AI Evals (Correctly)（Hamel Husain 頻道，YouTube，上傳 2026-07-03；引言依 YouTube 自動字幕，投影片依影片畫面核對） https://www.youtube.com/watch?v=tqUDjc1HzO4
• Antaripa Saha 與 Hamel Husain, Do Automated Evals Work?（Parlance Labs，2026-07-11） https://parlance-labs.com/blog/posts/auto-evals/index.html
• Hamel Husain 與 Shreya Shankar, Evals Skills for Coding Agents（Hamel's Blog，2026-03-02 發表，2026-08-31 修改） https://hamel.dev/blog/posts/evals-skills/
• Hamel Husain, The Revenge of the Data Scientist（Hamel's Blog，2026-03-26） https://hamel.dev/blog/posts/revenge/
• Shreya Shankar, J.D. Zamfirescu-Pereira, Björn Hartmann, Aditya G. Parameswaran 與 Ian Arawjo, Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences（arXiv:2404.12272，2024-04-18） https://arxiv.org/abs/2404.12272
• ai-evals-course, evals-skills：README、skills/error-discovery 的 SKILL.md 與 review-loop.md、skills/write-code-eval 的 SKILL.md、提交紀錄（2026-10-23 讀取） https://github.com/ai-evals-course/evals-skills
• Ben Tannyhill, Introducing LangSmith Engine（LangChain，2026-05-13） https://langchain.com/blog/introducing-langsmith-engine
• Braintrust, Patterns（Braintrust 文件，未標日期，2026-10-23 讀取） https://www.braintrust.dev/docs/observe/patterns
• Arize, Alyx（Arize AX 文件，未標日期，2026-10-23 讀取） https://arize.com/docs/ax/alyx