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

01解決的工作問題

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

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

什麼情況下該用這一套

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

什麼情況下別用

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

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

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

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

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

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

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

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

誰會用到

數據分析

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

主管

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

行銷

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

會計／財務

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

所屬工作情境

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

一句話版（快速回顧）

1. 先定義異常規則：多少變化幅度算異常、跟哪一期比、看哪些指標。
2. 讓 AI 掃描本期資料，只列出觸碰門檻的項目與數字，不寫任何原因。
3. 針對每個異常，AI 分兩欄寫：Observed Fact（只描述數字變化）與 Possible Hypothesis（可能原因，附類別與需要的證據）。
4. 人拿著「需要的證據」清單去查（促銷排程、系統紀錄、客服單、競品動態）。
5. 查有證據支持的 Hypothesis 才能改寫成 Confirmed Cause，查不到的維持「尚未確認」。
6. 人審過沒有把未查證的假說寫成原因，才定稿發布。

完整版（每一步誰做、產出什麼）

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 的系統指令。三種都附可替換變數、使用範例、預期輸出與人工確認點。

以下是本期與基期的報表資料。請找出異常並分類，不要直接下結論：
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當天營收僅為平常單日均值的三成，其餘6天接近正常區間。
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%，成長集中在8/20後三天。
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筆訂單在此期間無法完成付款，估算影響營收約45,000元，佔本週營收缺口的多數。
查證來源：金流服務商後台交易失敗紀錄（8/19 14:02-16:11）。
註記：仍有部分缺口（約本週均值的-3%）未被此事件完全解釋，維持觀察，不排除疊加其他因素。

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%，成長集中在8/20後三天。
Possible Hypothesis：
(a)〔內部動作〕行銷投放新廣告或社群貼文帶量。→ Evidence Needed：行銷排程與廣告後台曝光/點擊來源。
(b)〔外部環境〕該類目被外部平台或KOL提及。→ Evidence Needed：社群聲量或外部連結來源。
目前狀態：Hypothesis（尚未確認）
尚缺查證：行銷排程表、外部連結來源分析

08工具怎麼挑

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

09會卡住與會做錯的地方

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

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

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

Hypothesis 偷偷升級成 Cause

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

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

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

Evidence Needed 清單沒人去查

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

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

其他注意事項

• AI 把產業裡最常見的說法當成預設答案（營收跌就寫「需求下降」），沒有你們家的證據。
• 「可能是」在轉手報告的過程中被拿掉，變成「因為」，沒人發現用詞被升級了。
• 把資料品質問題（例如某天漏傳資料、口徑不一致）誤判成業務異常來歸因。

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