報表異常自動註記：只描述數據，不替數字找理由

01解決的工作問題

每天、每週或每月的 Dashboard 都會跑出幾個異常紅字：營收掉了 8%、某頁流量暴增三倍、退貨率突然升高。最常見的做法，是叫 AI「幫我看一下這份報表，為什麼會這樣」。AI 幾乎每次都會給出一個聽起來很合理的原因：「可能是市場需求下降」「可能是季節性因素」「可能是競品促銷影響」。這些話術之所以危險，是因為它們讀起來像結論，但其實只是 AI 根據數字形狀腦補出的最常見解釋——它沒有查過你們家有沒有促銷、沒有比對過競品動作、也沒有看過客服單。管理層一旦把這句「可能」直接寫進月報或轉述給老闆，「可能是需求下降」很快就會變成「因為需求下降」，接著整個部門的下一步動作就建立在一個沒人查證過的假設上。要讓 AI 在異常報表上真正好用，就必須先切斷它「看到數字掉→自動生成合理故事」這個反射動作，逼它把「看到什麼」跟「猜測是什麼」分成兩欄，而且未查證的猜測，永遠不能升級成報表上的「原因」。

02什麼時候用、什麼時候別用

什麼情況下該用這一套

• 有固定週期的 Dashboard 或報表日、週或月，常需要人工看數字、寫一段「發生什麼事」的摘要文字。
• 報表使用者會往上呈報或據此做決策主管、老闆會直接引用報表上的一句話，錯誤歸因的代價高。
• 有能力另外去查證能翻系統紀錄、促銷排程、客服單或競品情報，把 Evidence Needed 清單真的追下去，而不是只看數字猜。

什麼情況下別用

需要即時自動化決策的場景

例如自動喊停廣告投放、自動扣款攔截。這個方法產出的是給人看的報表註記，不是決策引擎，中間一定要有人核准。

資料還沒做基本清洗或口徑校對時

異常有可能只是口徑不一致或欄位缺漏，不是真的業務異常，先處理資料品質，可另外參考 KPI 口徑檢查的方法。

只有單一資料點、無法建立基線的情況

沒有近 8-12 期的歷史區間可比對，AI 很容易把正常波動誤判成異常。

需要法律、醫療或資安等專業判斷的異常歸因

這些領域的「可能原因」必須由對應的專業人員認定，AI 的假說清單只能當輔助，不能替代專業判斷。

誰會用到

數據分析

你是最常被要求「幫我看一下為什麼」的人，也最容易在時間壓力下把第一個聽起來合理的解釋直接寫進報表。母提示詞的嚴禁事項就是為了擋這個反射動作。

主管

你收到的往往是別人整理過的版本，容易看不出「可能」有沒有被偷偷拿掉。定稿前的用詞檢查這一步，你要親自看一次再往上送。

行銷

流量或轉換率異常常常牽涉你手上的廣告排程，Evidence Needed 清單裡「內部動作」那一類多半要靠你提供查證結果，分析師自己查不到。

會計／財務

營收類異常最終要進財務報表，「尚未確認」的假說絕對不能被簡化寫進正式財報附註，這條紅線需要你幫忙守住。

所屬工作情境

04完整步驟圖的文字版，逐步展開

上面三分鐘版那幾步，這裡逐步展開：每一步誰做、做完會有什麼。

05開始前要準備什麼標「必要」的沒備齊就先別開始

定義清楚的異常判定規則必要

變化幅度門檻或標準差、比較基期，事先由人定好，不讓 AI 自己決定多少算異常。

近 8-12 期的歷史資料當基線必要

單期比較容易把正常週期性波動（例如週一離峰）誤判成異常。

可查證的佐證來源清單必要

促銷排程、系統異動紀錄、客服單、競品情報等，列出誰負責哪一類查證。

三分法模板必要

Observed Fact / Possible Hypothesis / Evidence Needed 的固定欄位，讓每次產出格式一致。

誰有權限把 Hypothesis 升級成 Confirmed Cause必要

指定審核人，沒有查證來源不得核准升級。

既有的 KPI 口徑定義文件可選

有的話拿出來對照，避免把口徑差異誤判為業務異常。

餵進去的東西要長這樣

本期與近8-12期的報表資料 ＋ 異常判定門檻與比較基期 ＋（查證階段）人工查證結果。

• 至少要有近8期歷史資料當基線，單期比較容易把正常波動當異常。
• 門檻要先定好（變化幅度或標準差），不要讓AI自己決定多少算異常。
• 資料中若含客戶個資或未公開財務數字，先做遮蔽或彙總再貼給AI。
• 查證結果要註明來源（系統紀錄、排程表、客服單編號等），不能只寫『問過了，沒問題』。
• 資料缺漏的日期要先標明，避免被誤判成業務異常。

【本週vs近8週平均】
- 總營收：238,000元（近8週平均270,000元，變化 -11.9%）
- 網站訂單數：312筆（平均356筆，-12.4%）
- A產品分類頁瀏覽量：18,400（平均4,600，+300%）
- 退貨率：6.8%（平均3.1%，+3.7個百分點）
- 客服來電量：47通（平均22通，+114%）

【異常門檻】營收/訂單±15%、流量成長100%以上、退貨率變化2個百分點以上
【比較基期】近8週均值

06Prompt（快速／完整／進階）

A 快速版貼上就能用；B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足；C 進階版是拿去建 GPT／Skill／Agent 的系統指令，預設收起來，要用再點開。三版都附可替換變數、使用範例與預期輸出；A 與 B 另外列出那一版特有的常見錯誤與人工確認點，C 版的那幾題指向 Agent 專篇。

以下是本期與基期的報表資料。請找出異常並分類，不要直接下結論：
1. 異常判定：變化幅度超過{門檻}或明顯超出正常波動區間的項目才算異常，逐項列出數字與比較基期。
2. Observed Fact：只寫資料本身的變化（例如「較上期下降 12%」），不得包含任何原因推測。
3. Possible Hypothesis：針對每個異常列出 2-4 個可能原因，各自標注類別（內部動作／外部環境／資料品質／季節性）。
4. Evidence Needed：針對每個 Hypothesis，寫出需要看到什麼證據才能確認或排除它。
5. 嚴禁事項：不得把任何 Hypothesis 直接寫成「原因是……」；找不到任何合理假說時要寫【無可用假說，需人工判斷】。
資料：{貼上}

以下是本週與過去8週的營收、流量、退貨率資料，門檻設定為變化幅度超過±15%或超出近8週的常態波動區間。請依母提示詞五條規則找出異常並分類，不要直接下結論。

【本週vs近8週平均】
- 總營收：238,000元（近8週平均270,000元，變化 -11.9%，且8/19單日出現斷崖式下滑）
- 網站訂單數：312筆（平均356筆，-12.4%）
- A產品分類頁瀏覽量：18,400（平均4,600，+300%）
- 退貨率：6.8%（平均3.1%，+3.7個百分點）
- 客服來電量：47通（平均22通，+114%）

【異常清單】
1. 總營收 -11.9%（238,000元 vs 8週均270,000元），且8/19單日出現斷崖下滑
2. 網站訂單數 -12.4%
3. A產品分類頁瀏覽量 +300%
4. 退貨率 +3.7個百分點
5. 客服來電量 +114%

【異常1：總營收下降】
Observed Fact：本週總營收238,000元，較近8週平均270,000元下降11.9%；輸入指出8/19單日出現斷崖式下滑，但沒有提供單日營收數字，下滑幅度標【待補】。
Possible Hypothesis：
(a)〔內部動作〕8/19結帳流程或金流服務可能發生異常，導致訂單流失。→ Evidence Needed：查系統異常紀錄、金流商後台的失敗交易數。
(b)〔外部環境〕市場需求下降。→ Evidence Needed：需比對同業或大盤同期營收數據，目前無此資料，無法佐證。
(c)〔資料品質〕8/19資料是否完整回傳。→ Evidence Needed：查ETL執行紀錄，確認當天資料抓取有無漏傳。
排序建議：先查(a)與(c)，因為異常集中在單日，比全週趨勢性下降更像操作事件。

【異常2：A產品分類頁瀏覽量暴增300%】
Observed Fact：本週瀏覽量18,400，較平均4,600成長300%。輸入沒有逐日數字，成長集中在哪幾天無法判斷。
Possible Hypothesis：
(a)〔內部動作〕行銷是否投放新廣告或社群貼文帶量。→ Evidence Needed：查行銷排程與廣告後台的曝光/點擊來源。
(b)〔外部環境〕該類目商品是否被外部平台或KOL提及。→ Evidence Needed：查社群聲量或外部連結來源。
【無可用假說，需人工判斷】：若查證後兩者皆無，需人工判斷是否為異常流量（機器人）。

【異常3：退貨率+3.7個百分點】、【異常4：客服來電量+114%】：格式同上，各自列出Observed Fact與2-3個Possible Hypothesis及對應Evidence Needed，略。

以下是先前產出的異常清單（含 Observed Fact / Possible Hypothesis / Evidence Needed），以及我實際查證後的結果。請依查證結果改寫報表異常註記：

1.【逐條核對】針對每個 Hypothesis，看我提供的查證結果是「有證據支持」「證據不支持」還是「查無法查證/尚未查」，分別處理。
2.【改寫規則】只有「有證據支持」且證據明確指向該項的 Hypothesis，才能改寫成 Confirmed Cause，並附上查證來源；其餘一律維持原本的 Hypothesis 用語加註「尚未確認」，不得省略或美化。
3.【用詞檢查】逐句檢查是否有「可能」被悄悄拿掉、變成肯定句的地方，若有要改回來並標記【用詞被升級，已改回】。
4.【資料品質異常另外標註】若查證結果顯示是ETL、口徑或資料缺漏問題，不歸入業務異常，改標【資料品質問題，轉XX處理】。
5.【產出報表異常註記定稿】依「已確認原因」「尚未確認假說」「資料品質問題」三類分別呈現，每一類清楚標示狀態。

規則：
- 不得為了讓報表好看而把「尚未確認」的假說寫得像已經確認。
- 有多個Hypothesis都查無法排除時，全部列出，不要只挑一個看起來合理的。
- 查證結果若與Hypothesis完全無關，直接標【與此異常無關，維持原假說】。

異常清單：{貼上}｜查證結果：{貼上}

（貼上前一步的異常清單，並附查證結果：查了8/19的金流後台紀錄，發現當天14:00-16:00結帳API出現502錯誤，導致約180筆訂單無法完成付款；行銷部門確認8/20起在IG限動投放了A產品分類的置頂廣告；退貨率與客服來電量的查證結果尚未取得）

【已確認原因】
1. 總營收下降11.9%
狀態：Confirmed Cause
原因：8/19 14:00-16:00結帳API出現502錯誤，經金流後台紀錄查證，約180筆訂單在此期間無法完成付款。影響金額要用這180筆的實際訂單金額計算，查證結果沒有提供，標【待補】；不用平均客單價推估，因為失敗訂單的金額分布不一定跟平常一樣。
查證來源：金流服務商後台交易失敗紀錄（8/19 14:00-16:00）。
註記：這個事件能解釋多少營收缺口，要等上面的影響金額補齊才能算；在那之前不排除疊加其他因素。

2. A產品分類頁瀏覽量+300%
狀態：Confirmed Cause
原因：行銷部門於8/20起在IG限動投放A產品分類置頂廣告。
查證來源：行銷排程表、廣告後台曝光數據。

【尚未確認】
3. 退貨率+3.7個百分點
狀態：Hypothesis（尚未確認）
可能原因：(a)出貨品質問題 (b)8/19結帳異常導致部分重複下單後取消。查證結果尚未取得，維持未確認，待補查倉儲品檢紀錄與訂單重複率。

4. 客服來電量+114%
狀態：Hypothesis（尚未確認）
可能原因：與異常1、3相關的詢問量增加。查證結果尚未取得。

【用詞檢查】
原Hypothesis草稿中「可能是市場需求下降」一句在轉寫過程中曾被簡化為「因需求下降導致營收下滑」，已改回原始假說用語並標記【用詞被升級，已改回】——且此假說本身查無證據支持，不列入已確認原因。

【資料品質問題】
無。本次未發現ETL或口徑相關問題。

請把以下的異常偵測規則與三分法規範，寫成一份可以直接用來建立「報表異常註記助手」的系統指令。

【系統指令要包含】
1. 角色與任務：只負責掃描報表資料、標出異常、分類為Observed Fact/Possible Hypothesis/Evidence Needed三欄，不負責下結論、不負責查證。
2. 異常判定規則：變化幅度門檻、比較基期、要看哪些指標（照我提供的規則，不得增刪）。
3. 輸出格式的硬規定：
   - Observed Fact只能描述數字，出現任何「因為」「導致」「造成」等因果字眼一律視為違規，要求AI自己刪除重寫。
   - 每個Hypothesis必須標類別（內部動作/外部環境/資料品質/季節性）並附Evidence Needed。
   - 找不到合理假說時輸出【無可用假說，需人工判斷】，不得留白也不得硬湊。
4. 狀態機規則：一則異常只能是「Hypothesis(尚未確認)」或「Confirmed Cause」兩種狀態，只有使用者在對話中明確提供查證結果並指向該項，助手才能把狀態改成Confirmed Cause；使用者沒有提供查證時，助手必須拒絕把任何假說升級，並提醒「需要查證後才能定稿」。
5. 資料品質例外：若使用者提供的查證結果顯示是ETL或口徑問題，狀態改為【資料品質問題】，不進入業務異常分類。
6. 輸出格式：異常清單 ＋ 三欄內容 ＋ 目前狀態（未確認/已確認/資料品質問題） ＋ 尚缺的查證項目。

【另外請給我】
(a) 一份「使用說明」，寫給第一次用的同事看，含三個好例子與三個壞例子。
(b) 一份「維護說明」：異常門檻多久檢討一次、新增指標時怎麼處理、誰負責審核已確認原因。

異常偵測規則：{貼上}｜三分法規範：{貼上}

（貼上異常門檻：營收/訂單±15%、流量成長100%以上、退貨率變化2個百分點以上；貼上三分法規則全文）

【報表異常註記助手 系統指令】

一、你的角色
你是本單位的報表異常註記助手。你只負責掃描資料、標出異常、分類為Observed Fact / Possible Hypothesis / Evidence Needed，不負責下結論，也不負責查證。

二、異常判定規則
（照錄使用者提供的門檻：營收/訂單變化超過±15%、流量成長超過100%、退貨率變化超過2個百分點，比較基期為近8期均值。）

三、輸出格式的硬規定
1. Observed Fact只能描述數字變化，禁止出現「因為」「導致」「造成」等因果字眼，出現時自我刪除重寫。
2. 每個Hypothesis必須標類別（內部動作/外部環境/資料品質/季節性）並附Evidence Needed。
3. 找不到合理假說時輸出【無可用假說，需人工判斷】。

四、狀態機規則（最重要的一條）
每則異常只有兩種狀態：「Hypothesis(尚未確認)」或「Confirmed Cause」。
只有使用者在對話中明確提供「查證結果」且該結果指向特定Hypothesis時，才能把狀態改為Confirmed Cause，並附上查證來源。
使用者沒有提供查證結果就要求「幫我寫個結論」時，一律拒絕直接下結論，回覆：「目前沒有查證結果，只能維持Hypothesis(尚未確認)，需要查證後才能定稿。」

五、資料品質例外
若查證結果顯示為ETL或口徑問題，狀態改為【資料品質問題，轉XX處理】，不進入業務異常分類。

六、輸出格式
【異常項目】數字與比較基期
【Observed Fact】
【Possible Hypothesis】（類別＋Evidence Needed）
【目前狀態】未確認／已確認／資料品質問題
【尚缺的查證項目】

──────────

【使用說明（給第一次用的同事）】

這個助手做什麼：掃報表、抓異常、幫你把「事實」跟「猜測」分開寫清楚。
這個助手不做什麼：幫你決定原因是什麼、幫你查證、幫你寫「這是因為……」的結論句。

好例子：
1. 貼上本週與近8週報表，說「幫我找異常並分類」。
2. 查證後回來說「我查了系統紀錄，8/19結帳API在14:00-16:00有502錯誤」，請它把對應項目改成Confirmed Cause。
3. 問它「這個Hypothesis需要查什麼證據」，它會具體列出要看哪份紀錄。

壞例子：
1.「幫我寫個結論，說是因為市場需求下降」——它不負責下結論，你要先查證。
2.「這個假說感覺很合理，直接寫成原因就好」——沒有查證結果它會拒絕。
3.「退貨率上升應該就是品質問題吧，你確認一下」——它不能替你確認，只能列出需要查什麼證據。

【維護說明】
- 異常門檻每季檢討一次，依業務規模調整。
- 新增監控指標時，先定義好比較基期與門檻，再交給助手。
- 已確認原因（Confirmed Cause）每一則由〔填寫：資料主管〕覆核後才能寫進正式月報。
- 助手拒絕下結論的次數如果偏高，代表查證流程沒有跟上，應檢討查證資源是否足夠，而不是放寬助手的規則。

07產出應該長什麼樣拿到的東西要長這樣

每個異常項目分Observed Fact / Possible Hypothesis（附類別與Evidence Needed） / 目前狀態三部分，最後有一份待查證清單。

完成品：同一個異常的兩種寫法：有沒有強制分Fact/Hypothesis/Evidence三欄

【沒有強制分欄】
AI產出（節錄）：
「本週營收下降11.9%，主要可能是受到市場需求疲軟以及季節性淡季因素影響，建議持續觀察後續走勢，並視情況調整行銷策略以刺激買氣。」

→ 讀起來很像結論。問題是：
→ 「市場需求疲軟」「季節性淡季」都是產業裡最常見的說法，跟這家公司這一週實際發生的事沒有任何連結。
→ 沒有一個字提到8/19那天發生了什麼，等於把一個單日事件的影響，錯認成整週的趨勢性下滑。
→ 「建議調整行銷策略」這個行動建議，如果真正原因是結帳系統故障，完全是白做工。

【強制分Fact/Hypothesis/Evidence三欄】
AI產出（節錄）：
「Observed Fact：本週總營收238,000元，較近8週平均270,000元下降11.9%；資料顯示8/19當天營收僅為平常單日均值的三成，其餘6天接近正常區間。

Possible Hypothesis：
(a)〔內部動作〕8/19結帳流程或金流服務可能發生異常，導致訂單流失。→ Evidence Needed：系統異常紀錄、金流商後台失敗交易數。
(b)〔外部環境〕市場需求下降。→ Evidence Needed：需比對同業或大盤同期營收數據，目前無此資料，無法佐證。

排序建議：先查(a)，因為異常集中在單日，比全週趨勢性下降更像操作事件。」

→ 「其餘6天接近正常區間」這一句是關鍵線索，第一種寫法完全沒有提到。
→ 假說(a)跟假說(b)被清楚拆開，而且各自標明要查什麼才能確認，查證的人一看就知道下一步該打電話問誰。
→ 「排序建議」不是結論，是提示先查哪一項比較有效率，跟「直接說是需求下降」性質完全不同。

【差別在哪】
第一種在替數字找一個聽起來體面的理由，第二種在告訴你數字實際上長什麼樣、以及要去哪裡確認原因。前者讓人停止追問，後者讓人知道下一步該打給誰。

【異常：A產品分類頁瀏覽量+300%】
Observed Fact：本週瀏覽量18,400，較平均4,600成長300%。輸入沒有逐日數字，成長集中在哪幾天無法判斷。
Possible Hypothesis：
(a)〔內部動作〕行銷投放新廣告或社群貼文帶量。→ Evidence Needed：行銷排程與廣告後台曝光/點擊來源。
(b)〔外部環境〕該類目被外部平台或KOL提及。→ Evidence Needed：社群聲量或外部連結來源。
目前狀態：Hypothesis（尚未確認）
尚缺查證：行銷排程表、外部連結來源分析

08工具怎麼挑

這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議，不是限定。

09會卡住與會做錯的地方

會卡住的地方（流程困難點）

AI 把產業常見解釋當預設答案

營收跌就寫「市場需求下降」，這是最常見的說法，但沒有屬於你們公司的證據支持。

Hypothesis 偷偷升級成 Cause

草稿寫「可能是……」，轉手到會議簡報或月報就變成「因為……」，中間沒有任何查證動作。

把資料品質問題誤判為業務異常

例如某天漏傳資料導致數字看起來暴跌，其實是 ETL 或口徑問題，不是真的業務變化。

Evidence Needed 清單沒人去查

異常清單做出來了，但沒有人實際去查證，清單變成擺著好看的免責聲明。

會做錯的地方（常見失敗方式）

10人工把關與安全限制

AI／Agent／Tool 介入在哪幾步

這幾關不下放

異常門檻與比較基期

由人事先設定，AI 不能自己決定多少變化算異常。

Evidence Needed 的實際查證

促銷排程、系統紀錄、客服單、競品動態要人真的去查，AI 不能假裝查過。

Hypothesis 能否升級成 Cause 的最終判定

由指定負責人核准，且必須附查證來源，不得省略。

資料品質類異常的轉介

查證結果顯示是 ETL 或口徑問題時，轉給對應負責人處理，不當業務異常對外發布。

安全與權限限制

報表資料的機密性

營收、訂單、客戶數等屬敏感資料，上傳前確認使用的AI服務是否為企業或合約版本，避免流入公開模型訓練。

客戶個資遮蔽

若異常涉及特定客戶（例如單一大客戶造成的波動），先代稱或彙總，不貼真實姓名與聯絡方式。

查證結果的來源要可回溯

系統紀錄、工單編號等查證依據要保留連結或截圖，事後才能覆核『已確認原因』是不是真的有查過。

已確認原因的發布範圍

報表異常註記若涉及供應商或合作夥伴的問題（例如金流商當機），對外發布前要確認措辭不構成未經證實的指控。

共用助手的系統指令權限

C版助手若設定為custom-gpt或Skill供全公司使用，分享範圍與能否修改狀態機規則的權限要設對。

11Checklist 與驗收標準

做的時候逐項打勾

• 每個異常都先有 Observed Fact，且只描述數字不含推測
• Possible Hypothesis 都標了類別與需要的證據
• 沒有查證的 Hypothesis 沒有被寫成「原因」
• 至少一個異常有實際去查證 Evidence Needed
• 資料品質類異常已跟業務異常分開處理
• 定稿前有人審過用詞（可能／因為 沒有被偷換）

做完了才檢查：全部成立才算完成

1. 每個異常都有Observed Fact，且只描述數字沒有因果字眼。
2. 每個Hypothesis都標了類別，並附具體的Evidence Needed。
3. 沒有查證來源的項目維持Hypothesis（尚未確認），沒有被寫成Cause。
4. 至少有一個異常項目走完查證流程，附上可回溯的查證來源。
5. 資料品質類異常已與業務異常分開標註。
6. 定稿前逐句檢查過用詞，沒有『可能』被偷偷拿掉的句子。
7. 異常門檻與比較基期是人工事先設定，不是AI自己決定。
8. 已確認原因（Confirmed Cause）經過指定負責人覆核。
9. 報表異常註記放在共用位置或固定格式，不同期之間的用語與狀態一致。

12示範情境

13相關方法與下一步

可直接使用RELATED PROMPTS