Anomaly Detection

異常偵測指的是：請 Claude 在一批資料裡，找出跟正常範圍明顯偏離的項目，標記出來並附上可能的原因方向，作為後續判斷的起點。這是一個定位問題的動作，不是解決問題的動作——異常偵測的產出是一份「這裡跟平常不一樣」的清單，不是「這裡是錯的」的結論。這個區分很重要，因為 Claude 通常沒有足夠的上下文（例如那個部門這週是否有特殊交易）去判斷一個異常是不是真的錯誤，異常偵測負責找出來，判斷交給有上下文的人。這跟後續該怎麼處理異常是分開的兩件事——異常偵測完成後，通常要接著判斷這個異常會不會影響核心結論，決定是否需要走 escalation path（升級路徑）。

這個做法會被需要，是因為人在看一大批資料時，注意力天生沒辦法均勻分配——多數項目正常，只有少數幾項有問題，人眼很容易在看過前面十幾項正常資料後開始疲乏，反而漏看真正藏著問題的那幾項。這個現象在批次任務跑完之後特別明顯，因為批次結果通常量大，人不太可能逐項細看，快速掃過去的方式恰好最容易漏掉異常值（因為異常值往往就藏在一堆看起來大同小異的正常資料裡）。異常偵測存在的理由，就是把「找出哪裡不一樣」這個需要耐心跟系統性比對的工作，交給不會疲乏、能一次比對整批資料的 Claude，人的注意力則保留給異常標記出來之後，真正需要判斷力的部分。

實務上分兩層。第一層是定義「正常範圍」：明確告訴 Claude 什麼算正常，例如「跟過去四週平均值相差超過某個百分比」，這個範圍要根據任務性質定義，不能只寫模糊的「找出異常」讓 Claude 自己猜標準。第二層是要求輸出格式：每個標記出來的異常，要附上原始數值、跟正常範圍的差距、以及可能的原因方向（例如重複計算、單一大額事件、計算邏輯改變），這些原因方向不是最終結論，是給後續判斷的人一個切入點，讓他們不用從零開始猜。異常偵測的產出品質，很大程度取決於「正常範圍」定義得夠不夠具體——如果定義太寬鬆，會漏掉真正該標記的項目；定義太嚴格，又會把大量正常的自然波動也標成異常，讓後面的人淹沒在假警報裡。

對你來說，異常偵測真正的價值在於：把「這批資料裡有沒有問題」這個原本要靠人逐項瀏覽才能回答的問題，變成 Claude 可以系統性完成、不會因為疲乏而漏看的工作。這個做法特別適合資料量大、正常項目佔絕大多數的情境——愈是這種情境，人工逐項核對愈容易失去耐心，異常偵測的效益也愈明顯。要留意的是：異常偵測標記出來的東西，不等於「已確認的錯誤」，如果把異常偵測的輸出直接當成結論使用（例如自動改掉標記為異常的數字），就是把定位問題跟解決問題這兩個階段混在一起了，正確做法是異常偵測完成後，還要有一個判斷步驟決定這個異常該怎麼處理，通常是走升級路徑找有能力判斷的人確認，而不是自己代替他們下結論。