履約週報裡出現了一個紅色數字。運營主管想知道為什麼變差，但在解釋業務之前，還有一個更基礎的問題：這周和上週，算的是同一批物件、同一個口徑，而且資料都到齊了嗎？
Agent 可以整理檢查記錄、定位受影響行、準備異常清單。指標怎麼算、多少算異常、誰來調查，仍由團隊決定。流暢的分析不能替代這些輸入。
先固定一張指標定義卡
假設一個虛構履約團隊提供兩份獲准使用的 CSV：訂單表、發貨事件表。這是方法示例，不是真實客戶案例或已執行實驗。團隊把“超期訂單”定義為：承諾發貨期限已過，截至週報截止時仍無發貨事件的訂單。分母是承諾期限落在本週視窗內的全部訂單，包含尚未發貨的訂單；取消訂單是否剔除，按團隊書面規則處理。
比較相鄰兩個完整七天：週一零點到下週一零點，結束時點不包含在內，統一時區。定義卡記錄截止時間、匯出時間、來源覆蓋區間、訂單 ID、承諾期限、實際發貨時間。下載日期不是業務日期；如果發貨表沒采全，“沒有發貨記錄”也不能直接等同於超期。
三種異常，進入三個分支
| 虛構輸入 | 已知證據 | 應如何處理 |
|---|---|---|
| A：來源晚到 | 發貨事件只到週日，報表截止到週一 | 標記資料缺口，不釋出全周超期率 |
| B：口徑變了 | 退款從歸屬下單週，改成歸屬退款發生周 | 標記不可比，統一口徑重算或展示可比切片 |
| C：業務偏差 | 兩窗來源齊全，定義一致 | 先算真實變化，再對照團隊閾值 |
A 的輸出首先是缺失區間和受影響訂單 ID。缺失值保留 null，不填成 0。上一份完整報告可以保留，但必須帶原日期，不能冒充本週結果。區域性統計若有用，應明確覆蓋區間和分母，不與完整週直接比較。
B 中，退款事件可能完全真實，錯誤發生在比較方式。它與超期訂單指標分開處理。讓指標負責人確認歸屬規則，記錄版本後重算兩窗。Agent 不能為了讓圖表順眼，悄悄選一套更方便的定義。
C 的虛構源表顯示：本週 200 單中 20 單超期，上週 200 單中 8 單超期。超期率從 4% 升至 10%，增加 6 個百分點，絕對增加 12 單。假設團隊事先設定的調查條件是“至少上升 5 個百分點，且至少多 10 單”，本例同時透過兩條條件。這是示例團隊規則，不是行業標準，也不是讓模型自己猜的預設值。
異常清單要能交接，不要提前寫因果
每行保留：異常編號、型別、受影響指標、來原始檔與行 ID、定義版本、本期值、前窗值、閾值、待確認問題、實際提供的負責角色、下次核查條件和狀態。沒有指定負責人，就寫“待分派”，不要虛構姓名。
“多了 12 單超期”是觀察；“承運商故障導致增加”是待驗證假設。地區彙總和裝置彙總也不能拼成某地區某裝置導致異常的確定結論。可以提出要查的交叉切片，但不能把調查建議寫成原因。
摘要首層直接展示：已確認偏差、來源缺口、需要誰決定什麼。原始行與計算過程保持可查。安靜的一週可以沒有已證業務異常，同時仍有未補齊的資料缺口。
先把檢查方法留下，再考慮排期
在 Buda 運營場景裡，可以把指標卡、獲准輸入副本、帶日期的報告和異常表放在 Drive。Drive 與記憶保留的是檔案；執行時仍需明確讀取哪個版本，資料夾名稱本身不是許可權策略。
先拿一份脫敏歷史週報手動試跑。要求 Agent 輸出三類判定、計算和未決清單，不發告警、不改正式記錄。人工確認後，再把方法沉澱為 Skill；可在 Buda AI 的 Marketplace 搜尋並安裝合適的 Skill，安裝前先閱讀說明。Skill 與自動化能讓方法複用或按計劃執行，但不代表所有來源介面、審批流程都已配置。
這與把並行 Agent 產物整合成一份交付不同：這裡檢查的是每一期比較是否成立，而不是怎樣合併多份結果。晚到資料補齊後保留 v1，新出 v2，明確哪項輸入變了、哪些異常被重核。
常見問題
閾值由誰定？
由負責業務結果的人決定。事先記錄業務理由、百分點條件與最小絕對量。沒有規則時，先展示觀察並請求確認，不把模型建議寫成已批准標準。
晚到資料回來，舊報告怎麼辦？
保留舊版和原始輸入；新匯出另存版本，重跑受影響指標及完整度檢查。缺口關閉後可能出現新的業務異常，兩件事分別記錄。
訂單很少，百分比很誇張怎麼辦？
同時展示分子分母。5 單裡 1 單是 20%，但首先是 1 單。使用團隊確認的最小數量條件，先看具體訂單，不只按百分比升級。
可以用三個故意破壞的歷史副本試驗：缺一段來源、改一個定義、加入越過閾值的樣本。這是建議測試，並非已完成效果。確認三個分支都走對，再決定是否排期。