把 AI 放上線前，先照這八步測一遍：GitHub 用這套把誤報砍掉 95%（2026 官方做法）

「這個 prompt 好像比較好」——很多人的 AI 評估就停在這裡。GitHub 在 2026-08-25 公布了他們自己的做法，把這件事變成有紀律的工程流程。查核日 2026-09-08。

先看結果：他們在自家的密鑰掃描（secret scanning）上，把離線資料集上的誤報降低了 95%，同時把召回率守在事先定義好的護欄內。

「同時守住召回率」這半句才是重點——降誤報很容易，代價是漏抓；能同時守住才叫改善。

一、八個步驟（照做順序）

官方描述的生命週期是：產品決策 → 代表性資料集 → 離線評測 → 錯誤分析 → 針對性修改 → 回歸評測 → 線上實驗，中間帶回饋迴圈。

1. 先定產品目標，不要先調模型

先寫清楚三件事：

• 主要成功指標（例如：降低誤報率）
• 安全底線（例如：召回率不得低於某個值）
• 營運護欄（延遲、成本、可靠度）

沒有這三行，你後面所有的比較都沒有標準。

2. 一次只改一個變數

每次評測都記錄：prompt 版本、模型版本、關鍵指標（precision／recall／延遲）、對照的基準線。

官方的原則是「一次只改一個主要變數」——否則你會知道變好了，但不知道是哪一步造成的。

3. 評測資料要像正式環境

離線評測要貼近真實工作流：包含周邊脈絡、模稜兩可的案例、真實的干擾項，不要只用乾淨、孤立的漂亮例子。

這是最多人踩的坑：用理想化的題目測出高分，上線後撞到真實輸入就垮。

4. 人要親自看標籤

官方的提問是：「這個標籤，跟評測想回答的問題是同一件事嗎？」

正式環境的標籤記錄的是流程結果，不一定等於正確答案。所以要抽樣人工核對。

5. 資料集用混合的

把三種來源疊起來：正式環境資料 + 針對罕見失敗樣態的合成例子 + 學術基準／公開資料集，補上覆蓋不到的角落。

6. 錯誤要分類，不是只算比例

人工抽樣看失敗案例，然後按來源分類：模型、prompt、輸入框架、流程管線、資料集、標註。

這一步決定你接下來要修哪裡。 不分類的話，所有問題看起來都像「模型不夠好」。

7. 用 LLM-as-judge 做分流

自動分類把案子分三堆：明確的案例自動處理、低信心／高影響的送人工、定期抽樣檢查系統性錯誤。

注意順序：judge 是用來省人力的分流器，不是用來取代第 4 步的人工核對。

8. 永遠跟基準線比

沒有基準線的數字沒有意義。官方的密鑰掃描案例就是這麼報的——95% 的誤報降低，是「在所評估的離線資料集上」相對於基準線的結果，而不是一句「變好了」。

二、上線前檢查表（可直接抄）

官方列的準備度檢查：

• 產品決策與成功指標已明確定義
• 評測資料與正式環境的工作流相似
• prompt／模型／資料集的版本都有紀錄
• 誤報與漏抓已按類別檢視過
• 離線結果已與已知基準線比較

五項全過才叫做「測過了」。

三、對個人使用者的縮小版

你不是 GitHub，不需要整套流程。但這套邏輯縮小到個人尺度仍然成立：

1. 寫下你要它做好的那一件事，以及不能犧牲的那一件事（就是步驟 1）。
2. 準備十個真實例子——你自己工作中真的遇過的，不是想像的（步驟 3）。
3. 一次只改一件事，跑同樣那十個例子（步驟 2）。
4. 失敗的例子分類：是模型不會，還是我沒講清楚，還是資料沒給（步驟 6）。

光是第 2 步（十個真實例子）就能解掉大部分「感覺哪個比較好」的爭論。

四、最後一句

官方強調的是：評測是持續的工程，不是上線前的一次性關卡。

模型會更新、你的輸入分布會變、使用者會找出你沒想過的用法。那十個例子要留著，每次改動都重跑一次——這是這篇最便宜也最有效的一句話。

榜單分數為什麼不能取代自己的測試，見 AI2 拆解 34,000 道題的發現；相關術語（harness、hill climbing）的白話解釋，見 AI 黑話翻譯。

本文依據 GitHub 官方部落格 How to evaluate LLMs before production（2026-08-25）於 2026-09-08 直讀整理。八步生命週期、各步驟原則、上線前檢查表，以及密鑰掃描案例「在所評估的離線資料集上降低 95% 誤報並將召回率維持在既定護欄內」皆為該文所載。本站未重跑其評測，該 95% 為 GitHub 自行公布之離線結果。 第三節的個人縮小版為本站建議。