已驗證情境
已驗證情境會把一段專家判斷保存下來，讓團隊在 Agent 修改後仍能重新檢查。
Agent 裡有 instructions、資料來源與工具；情境則讓你看見這些設定在一個可辨識工作裡會產生什麼結果。兩邊都需要：只有 instructions，行為仍然只是推測；只有一堆 cases，卻沒有定義工作，就會變成零散檢查表。
從真實工作開始
請按照下一個要做的決定來選擇情境。可以分成四類：
- 核心情境：Agent 現在就應該處理的工作
- 邊界情境：需要先釐清、小心處理或交由專家 review 的工作
- 超出範圍情境：Agent 應拒答、交接或導向其他地方的工作
- 動作情境：需要工具、表單、付款、預約、API 呼叫或其他 Agent 的工作
不要只收理想問題。安全的第一版也要證明資訊不完整，或請求應留給真人時，Agent 會怎麼做。
讓案例集符合下一個決定
沒有所有 Agent 都適用的第一批固定題數。請建立足以支持下一個決定的最小案例集。
| 階段 | 要做的決定 | 證據重點 |
|---|---|---|
| 第一個行為 | Agent 是否已經足夠理解這份工作，值得繼續？ | 一個真實情境與相鄰邊界 |
| 受控 pilot | 一小群使用者是否可以使用核准範圍？ | 常見且高後果的 must-pass 行為、工具與交接 |
| 擴大 rollout | 下一版能否處理更多工作，又不破壞可信行為？ | 新範圍，加上 regression、邊界、工具與交接 cases |
| 正式驗收 | 雙方是否對交付內容有共同認定？ | 鎖定的 Agent version、case set、Standards、must-pass cases、已知限制與結果紀錄 |
請按照頻率與後果選擇案例。有些情境很少發生，但一旦答錯會帶來嚴重安全、財務、服務或信任問題，仍應列為 must-pass。
把每個情境變成 case
在 Test Suite 裡，一個有用的 case 會包含：
- 真實感的
Input - 足夠的對話或工作脈絡
- 說明回覆必須做什麼、不能做什麼的
Standard - 當 Agent 不應完成工作時的交接條件
Ideal Response 是選填欄位。只有在範例真的能改善 review 時才使用，不要用單一範例回答取代背後的品質條件。
好的 Standard 必須可以觀察。另一位 reviewer 應該只看結果，就能判斷 pass 或 fail，不必猜作者的意思。
標記不能退步的行為
當某個 case 失敗就應停止發布時，把它視為 must-pass。常見原因包括：
- 這個行為是 Agent 工作的核心。
- 錯誤會造成高後果動作或宣稱。
- Agent 必須交接，不能繼續處理。
- 這個行為屬於已核准的 pilot 或驗收邊界。
不是每個 case 都必須阻擋發布。請把診斷覆蓋和發布條件分開，讓團隊同時看得見哪些事情仍在探索，以及哪些行為一定要保持正確。
修改 Agent 前先診斷
Case 失敗時，先判斷哪一個約定錯了或不完整：
- 當
Standard要求錯誤結果時，修正Standard。 - 當判斷規則不清楚時，修正
Instructions。 - 當必要來源缺少、過期或難以檢索時，修正 Knowledge Base。
- 當動作或調用邊界錯誤時，修正工具。
- 當情境超出核准範圍時，保留安全 fallback。
除非這個 case 代表真實且通用的規則，否則不要只為了讓單一案例通過就新增狹窄 instruction。
用 version 擴大範圍
當你希望 Agent 處理更多工作時：
- 加入新情境與 Standards。
- 確認下一次發布有哪些 cases 是 must-pass。
- 只更新 failure 證明有必要修改的 instructions、資料來源或工具。
- 執行受影響 cases。
- 修改可能影響可信行為時，執行更廣的 regression cases。
- 只有在發布條件通過後，才發布新 version。
這會讓每次修正累積成專業資產，而不是變成一連串 prompt patches。
讓責任保持清楚
- Expert 或 owner 核准品質條件與邊界。
- Operator 從真實模式建立並維護 cases。
- Implementer 連接資料來源與工具。
- Release reviewer 判斷 must-pass 條件是否通過。
同一個人可以兼任多個角色，但每個決定背後的責任仍應保持可見。