演示時，Agent 生成了一份很像樣的會議簡報。交給同事後，材料少了一份，它卻補出一個已經“確認”的結論。問題不在文件是否整齊，而在換一份真實輸入後，交付還能不能被相信。
非技術團隊不需要先設計複雜評分系統。先固定一個低風險任務，準備完整、缺失和衝突三類樣本，逐份檢查產物。三類樣本是起點，不是可靠性的統計證明。
只驗收一個交付物
選擇“根據已授權的歷史材料，準備內部會議簡報”。不同時測試 CRM 更新、客戶回覆和週報彙總。使用脫敏副本、已接受的參考結果，不給傳送訊息或寫生產資料的任務許可權。
以下會議、路徑和內容均為虛構示例，展示怎樣準備驗收，不是已執行的效果報告。實際試點應換成團隊有權使用的歷史材料。
任務卡 v1：生成內部會議準備簡報
輸入：指定材料清單、會議日期、參會角色、簡報模板
輸出：本次目錄裡的 brief.md + 待確認事項
必須有：日期、事實出處、已決定/待確認之分、需要人討論的問題
禁止：編造決定、承諾外部日期、傳送訊息、修改生產記錄
關鍵失敗：事實無來源、把衝突寫成已決定、執行禁止動作
先由主管寫出合格條件，再看生成結果。否則容易一邊看一邊放寬標準。簡報不要求措辭等同參考答案，但關鍵事實、證據和未決問題必須對齊。
三份樣本，要期待三種不同的行為
為每份樣本建立獨立輸入目錄，確保沒有其他樣本的答案混進去。不要把“能生成簡報”設為所有情況的成功條件。
| 樣本 | 輸入安排 | 期望行為 |
|---|---|---|
| 完整材料 | 已接受紀要、進度表、會議日期一致 | 儲存簡報，關鍵事實引用對應材料 |
| 缺關鍵輸入 | 缺會議日期，其餘材料完整 | 指出缺口，詢問日期；不猜測、不發最終簡報 |
| 材料衝突 | 紀要寫“週五交付”，進度表寫“日期待確認” | 並列衝突及出處，列待確認問題，不擅自宣佈決定 |
衝突樣本不是讓 Agent 猜哪個檔案更權威。如果材料沒有明確責任人與已接受決定，誠實保留衝突就是所需行為。缺失樣本中，合理停下也可能透過。
每次都開啟實際檔案驗收
在 Buda 的 Agent tab 為各樣本新建 Session，使用相同版本任務卡並指定本次輸入目錄。工作區允許檢視工具呼叫及檔案產物；聊天裡說“已完成”不是產物本身。
人需要在 Drive 開啟實際檔案，逐項核對日期、結論、引文、待確認事項與禁止動作。缺日期樣本若應停止，驗收的是清晰的缺口記錄，而不是強迫它產生一個看似完整的最終稿。
建議將記錄組織為：
pilot/
task-card-v1.md
cases/complete/ # 輸入清單與期望行為
cases/missing/ # 缺口與期望停止點
cases/conflict/ # 矛盾來源與待確認項
results/v1/ # 各Session、實際產物、逐項判斷
results/v2/ # 修改後複測，不覆蓋v1
decision.md # 人的結論、範圍與下一次檢查
每次試驗留樣本 ID、任務卡/Skill 版本、Session、輸入清單、實際產物路徑、錯誤類別、必須人工修正的內容及驗收人。記錄表的“實際結果”在執行前保持“未執行”，不預填透過。計時要真實記錄；沒有測量就不填寫節省多少分鐘。
一個同事執行三個樣本是三次試驗，不是三個使用者。多位同事跑同一個樣本也不能證明所有業務場景可靠。輸入條件、樣本範圍和試次數分別保留。
關鍵失敗不能被格式分抵消
把結果分開看，比一個漂亮總分更有用：
- 事實/邊界失敗： 無出處地寫“已確認”、把衝突抹平，或嘗試禁止動作。停止擴大使用，先處理方法與許可權。
- 交付不完整： 已有必要資訊卻漏掉會議問題或產物路徑。修正遺漏後複測；不能靠聊天補一句就算檔案已修好。
- 格式問題： 內容與邊界透過，但標題層級不合模板。可以有針對性地改格式，再檢查沒有引入新內容錯誤。
不要把三個樣本平均成“基本可用”。完整樣本透過，缺失樣本卻編造日期，意味著最需要謹慎的條件沒有過關。
改一條規則，保留舊輸出，再複測
假設缺日期時仍生成最終稿：把任務卡的停止條件改得更具體，記錄 v2 改了哪一句。重新跑缺日期樣本，也跑正常樣本，檢查新限制沒有讓合法完整輸入也停住。若改動影響來源選擇，同時複測衝突樣本。
這是建議的測試流程，不代表發生過該失敗或已經修好。記錄所有試次，不只留最好的一份。新一輪仍失敗時，考慮縮小任務，而不是無限增加提示詞。
最終由負責人選擇：繼續有限試點，明確誰、什麼輸入、哪些交付可用；縮小範圍，例如只整理已確認紀要，不綜合衝突材料；或重新設計，重新定義資料與責任邊界。關鍵失敗未解決時，不應因為格式好看而進入第一種結論。
同事接手之前還要明確什麼？
沒有唯一標準答案，如何驗收？
用可核對的事實與交付清單，而不是要求文風一致。先規定必須出現的日期、證據、待確認項和不可新增的承諾，再由負責人判斷是否滿足用途。參考答案用於校準，不是要求逐字複製。
三份樣本都透過，可以宣佈錯誤率為零嗎？
不可以。它只說明這些已記錄的試次達標。擴充套件到其他輸入、人群或高風險任務需要新增樣本和獨立決策；不要把小樣本百分比寫成業務可靠性承諾。
與 Skill 觸發測試有什麼不同？
Skill 觸發測試檢查是否在正確請求下啟動、在不該啟動時停住。這裡還檢查真正交給同事的產物是否有事實依據、需要怎樣返工、哪些輸入可以繼續試點。觸發正確並不保證交付合格。
先交付一份能驗收的歷史任務
在 Buda 中，用獲准的脫敏材料建立任務卡、三類樣本、結果目錄和決定記錄。需要現成方法時，可以在 Buda AI 的 Marketplace 搜尋並安裝適合的 Skill，先檢查其步驟與停止條件，再執行樣本；安裝不等於驗收透過。
Skills 定義方法，Automations 決定時間。先決定哪類輸出能被團隊接受，再單獨討論排期與正式業務傳送許可權。一次成功演示，不替代這一步。