Evaluations and Improvements

Test Suite 的價值，在於讓一個看起來有效的修正，不會在別的地方偷偷造成 regression。

對 operator 來說，最可靠的 case 通常不是憑空想出來的 prompt，而是那些曾經真的讓使用者或 stakeholder 卡住的真實對話。

步驟 1：從真實失誤開始

最快的做法通常是：

1. 在 Histories 打開一則高風險 thread
2. 讀 stakeholder 回饋，或重新看那則有問題的回覆
3. 問 Copilot 這個行為最可能的成因
4. 判斷問題是出在 instructions、tools，還是 data

如果你很明確地知道這種錯不能再發生，就把它存成 case。

步驟 2：直接在 history thread 用 Add Case

在 history thread 裡按 Add Case。

這是最快的做法，因為原始輸入已經在那裡，而且你保護的是一個真實發生過的失誤。

步驟 3：把 Standard 寫成可檢查的清單

進到 case detail 後，通常最重要的欄位是 Standard。

請把它寫成 checklist，而不是抽象期待。

弱：

• Should answer well

強：

• Must ask at least one clarifying question before recommending a consultation
• Must not jump straight to booking
• Must mention callback when urgency or uncertainty is high

讓標準可以被檢查

一個好的 standard，應該明確到另一位 operator 只看回覆，也能判斷它到底有沒有過關，而不用猜你的意思。

步驟 4：用 Test Suite 跑你要信任的版本

當 case 集準備好之後，就用 Test Suite 去跑目前正在考慮發布的版本。

你主要看兩件事：

• 這個被修正的 case 現在有沒有通過
• 以前本來表現穩定的 case，有沒有被一起帶壞

步驟 5：修 Agent，再反覆重跑到重要案例穩住為止

當 case 沒過時，把它對應到一個明確改動：

• 重寫 Instructions 裡的某條規則
• 收緊 tool 的 When to Use
• 把缺的知識放進 Knowledge Base 或 Attachments
• 重新劃分 Agent 之間的 handoff 邊界

接著重跑同一組 case。重點不是每個地方都拿到完美分數，而是在發布前，把重要行為穩住。

給 operator 的實用原則

• 先從少量高價值 case 開始，不要一開始就做成一大張表
• 先保護那些會影響信任、分流品質，或造成昂貴交接錯誤的失誤
• 盡量保留真實使用者的問法，不要改寫成太人工的 QA 語氣
• 當你心裡出現 這種錯不可以再發生一次 時，就應該把它存成 case

什麼時候才該發布

當這個版本在重要 case 上已經達到你的要求，而且沒有破壞你原本信任的行為時，再發布。

這才是 evaluation 真正的工作：不是為了分數本身，而是提供證據，讓你知道這次 release 比上一次更安全。

相關指南

• Collect Feedback
• Version Management
• Histories