AI 根因分析教學：用證據鏈與反證避免修錯問題

10月 23, 2026

原內容日期：2026-10-16。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

找到第一個合理解釋，不代表找到真正根因

問題發生後，團隊往往很快就會出現一個故事：「剛好更新過，所以是新版程式」「現場說畫面很慢，所以是網路」「某位同事按錯，因此是操作疏失」。這些說法可能正確，但在證據完成前，它們只能算候選假設。

生成式 AI 讓報告整理變快，也讓一個尚未證明的說法更容易被寫得完整、順暢、有說服力。真正的風險不是 AI 完全胡說，而是它把團隊已有的偏見整理得太像結論。

先把問題和原因分開

好的問題陳述只描述實際發生什麼，不預先指定原因。至少包含對象、時間、實際結果、預期結果與影響。

例如，不要寫「因網路不穩造成電子秤資料遺失」，而是寫：「10 月 14 日 09:10～10:05，設備 B 有 42 筆量測資料未在 30 秒內入庫；設備 A、C 同時段正常，造成報表缺漏與 55 分鐘人工補登。」

這個寫法保留了調查空間，也提供了重要反證：同一網路上的其他設備正常。

時間線不是流水帳，而是因果檢查工具

完整時間線要區分事件發生、第一個訊號、人工發現、處置與恢復。每一筆附上來源，才能判斷兩件事究竟誰先誰後。

若只知道 09:17 有人回報畫面慢，卻不知道 09:08 已經出現欄位錯誤，就很容易把網路延遲當成主因。時間線能揭露：畫面慢可能只是同時發生的現象，而解析錯誤更早出現。

不要只問「最可能是什麼」

根因分析最常見的偏誤，是先選一個最符合直覺的答案，再找支持它的資料。較可靠的做法是建立幾個競爭假設，例如：設備沒送資料、中介服務解析失敗、資料庫交易回滾、報表查詢漏掉，或監控延遲造成誤判。

接著為每個假設預先寫下：若為真應看到什麼？若為假應看到什麼？哪一筆證據會迫使我們放棄它？

這一步很重要，因為不可被反駁的說法不是好假設。如果無論看到什麼結果，都能說「仍有可能」，那就無法有效驗證。

正常案例是最容易被忽略的反證

很多調查只盯著異常資料，卻不比較正常案例。若三台設備使用同一個交換器與同一版服務，只有一台異常，那麼單純的「整體網路不穩」解釋力就會降低。

Is／Is Not 比較能幫助團隊找出差異：問題出現在哪些設備、版本、批次、資料類型與時段？又沒有出現在哪裡？異常與正常之間的差異，往往比異常本身更接近可驗證原因。

5 Whys 為何常常不夠？

5 Whys 是簡單好用的提問方式，但如果每一層都沒有證據，就會變成一條順暢的故事。不同主持人可能從同一事件問出完全不同的第五個「為什麼」。

比較穩健的做法是：保留多條候選路徑，讓每一層都標示事實、推論或假設，並建立證據矩陣。當新證據出現時，更新各假設的支持與反對狀態，而不是硬把新資料塞回原來故事。

根因不只有一層

一個事件通常同時存在近因、促成因素與系統性根因。解析器無法處理額外欄位可能是近因；錯誤資料沒有隔離佇列、監控沒看拒絕筆數是促成因素；設備與服務之間沒有版本化介面契約，才可能是讓同類問題持續發生的系統性根因。

如果只修近因，下次換一個欄位、格式或版本，問題仍可能重演。

AI 在根因分析中最適合扮演什麼角色？

AI 適合整理大量事件、統一時間格式、比對不同人的說法、產生候選假設、檢查證據缺口，以及設計低風險驗證計畫。它也能提醒團隊主動尋找反證，避免只收集支持原判斷的資訊。

但 AI 不知道紀錄是否完整、訪談是否準確、環境是否真的一致，也不能替有權限的人判定責任。輸出必須保留來源、信心等級與未排除假設。

15 步實作摘要

定義不含原因的問題。
框定範圍與結案條件。
建立事件時間線。
分開事實、推論、假設與未知。
比較異常與正常情況。
列出競爭假設。
為假設寫預測結果。
建立證據矩陣。
主動尋找反證。
依資訊價值排序驗證。
分開近因、促成因素與系統性根因。
把人為錯誤往系統追問。
分開止血、矯正與預防措施。
用修正後結果驗證因果。
保留信心等級與重開條件。

結語

真正可靠的根因報告，不一定最早交出，也不一定最肯定；它會清楚說明哪些是已知事實、哪些仍是假設、哪個證據支持或反對哪個解釋，以及下一步如何安全地區分它們。

行動邀請：挑一個最近重複發生的小問題，先不要問 AI「根因是什麼」。把異常案例與一個正常案例一起提供，要求它產出競爭假設與反證清單，你會得到更值得調查的起點。

逐步操作

第 1 步：先定義問題，不急著說原因

用「對象、時間、地點、實際結果、預期結果、影響」描述問題：

10 月 14 日 09:10～10:05，三台設備中的第二台有 42 筆量測資料未進入資料庫；同期間另外兩台正常。預期每筆量測應在 30 秒內入庫，實際造成批次報表缺資料與 55 分鐘人工補登。

避免一開始寫「因為網路不穩導致資料遺失」，因為那已把未證實原因塞進問題陳述。

第 2 步：明確框定分析範圍與結案條件

先說清楚：

哪些設備、版本、批次或使用者在範圍內？
哪些相似問題暫時不納入？
需要回答「為何發生」「為何未被及時發現」還是兩者都要？
什麼證據才算結案？

根因分析不能以「會議結束」或「大家同意」作為結案條件。

第 3 步：建立可回查的事件時間線

至少整理：

正常運作的最後時間
變更、部署、設定、交班或外部事件
第一個異常發生時間
第一個可見訊號
問題被人發現的時間
每次處置與系統回應
恢復時間與恢復依據

每一筆都附來源編號，例如紀錄檔、工單、截圖、Email 或訪談紀錄。

第 4 步：把內容分成四層

觀察事實：可由紀錄或重複觀察確認。
推論：由事實推導，但尚未證明。
假設：可被驗證或推翻的候選原因。
未知：目前沒有資料，不能判斷。

例如「09:08 發生三次逾時」是事實；「網路品質惡化」是推論；「交換器埠錯誤導致封包重送」是假設。

第 5 步：比較有問題與沒問題的情況

用 Is／Is Not 比較法，檢查：

哪些設備有問題？哪些沒有？
哪個時段發生？哪些時段正常？
哪個版本、帳號、資料類型或流程特別不同？
問題是全部發生、偶發，還是只在某個邊界條件出現？

正常案例不是背景雜訊，而是排除錯誤假設的重要反證。

第 6 步：先列多個競爭假設

不要只問「最可能是什麼」，而要列出 3～5 個能解釋相同症狀的候選：

H1：設備端未送出資料。
H2：通訊成功，但中介服務未正確解析。
H3：資料已寫入，但被後續交易回滾。
H4：資料存在，但報表查詢條件排除。
H5：監控延遲造成「看似遺失」。

假設要能被觀察結果證明或推翻，而不是「系統有問題」這種無法測試的說法。

第 7 步：為每個假設寫預測結果

問：「如果 H1 為真，我們應該看到什麼？如果為假，又應該看到什麼？」

例如：

若設備未送出，設備端序號會出現缺號，中介服務也收不到封包。
若解析失敗，中介服務應收到封包，但會出現格式或欄位錯誤紀錄。
若資料庫回滾，應有交易錯誤、鎖定或 rollback 紀錄。

預測結果能防止團隊看到任何證據都說「也可能符合」。

第 8 步：建立證據矩陣

每項證據標示：

支持哪個假設
反對哪個假設
是否與假設無關
來源可靠度
時間與版本是否匹配
是否仍可能有其他解釋

不要只收集支持證據。真正有辨識力的證據，通常能同時支持一個假設並排除另一個。

第 9 步：主動尋找反證

對目前最熱門的假設，刻意問：

有沒有正常案例也具備相同條件？
有沒有異常案例不具備這個條件？
是否在修正之前問題就已停止？
是否有另一個原因也能產生相同現象？
哪一筆資料會迫使我們放棄這個假設？

如果團隊說「任何結果都能解釋」，代表假設不可被反駁，需要重寫。

第 10 步：依資訊價值排序驗證

優先做：

能一次區分多個假設的檢查。
成本低、時間短、風險小的測試。
不會破壞正式資料的唯讀查證。
能重現問題或確認必要條件的最小實驗。

不要直接在正式環境反覆嘗試，尤其是可能重複寫入、寄送、扣款或刪除資料的操作。

第 11 步：分開近因、促成因素與系統性根因

近因：直接觸發事件，例如服務在解析空值時拋出例外。
促成因素：讓事件更容易發生或更難發現，例如測試資料未涵蓋空值、警報延遲。
系統性根因：讓同類問題持續出現的管理或設計缺口，例如介面契約沒有定義必填欄位與版本相容規則。

只修近因，問題常會換一個欄位再次發生。

第 12 步：把「人為錯誤」再往系統追問

若初步結論是操作錯誤，繼續檢查：

正確操作是否容易理解？
介面是否允許危險輸入？
權限是否過大？
是否缺少確認、預覽、撤銷或第二人複核？
時間壓力、交班與工作量是否影響判斷？
訓練與 SOP 是否對應實際版本？

這不是免除責任，而是避免把可改善的系統條件藏在個人標籤後面。

第 13 步：分開止血、矯正與預防措施

止血：立即限制影響，例如暫停自動匯入、切回人工覆核。
矯正：修復已確認原因，例如修正解析器空值處理。
預防：降低同類問題再發，例如加入契約測試、版本檢查與監控。

每項措施都要有擁有者、期限、完成證據與風險。止血措施也可能長期留下成本，需有退出條件。

第 14 步：用修正後結果驗證因果

修正後至少檢查：

原問題能否被穩定重現？修正後是否不再發生？
相鄰功能有沒有回歸問題？
監控是否真的能提早發現？
在足夠樣本、時段與負載下是否維持正常？
若撤回修正，問題是否再現？這項測試是否安全、必要？

「上線後一天沒再發生」通常不足以證明根因正確。

第 15 步：留下信心等級與重開條件

根因結論可標示：

已確認：有一致證據、反證已處理、修正後驗證通過。
高度支持：證據一致，但仍有一項關鍵驗證未完成。
暫定：目前最符合，但仍有合理競爭假設。
未確認：資料不足，不能判定。

同時記錄：若哪個新訊號出現，必須重新開啟分析。不要為了報告漂亮，把暫定結論寫成已確認。

可直接複製的完整提示詞

你是一位無責備、證據導向的根因分析促進者。你的任務不是替團隊快速選一個責任對象或最像答案的原因，而是根據我提供的資料，建立可回查、可反駁、可驗證的根因分析。

【任務】
1. 將問題改寫成不含原因假設的問題陳述，包含對象、時間、實際結果、預期結果與影響。
2. 檢查分析範圍、排除範圍及結案條件；不足時列為待補資料。
3. 依時間排序所有事件，保留來源編號，並標示時間衝突或不確定性。
4. 將輸入逐項分類為：觀察事實、推論、候選假設、未知事項、已否定說法。
5. 製作 Is／Is Not 比較，找出異常與正常案例的關鍵差異。
6. 建立 3～5 個競爭假設。每個假設都要能被證明或推翻，不得只是籠統描述。
7. 為每個假設列出：若為真應觀察到什麼、若為假應觀察到什麼、目前支持證據、目前反證、缺少證據。
8. 建立證據矩陣，評估來源可靠度、時間匹配、版本匹配與替代解釋。
9. 設計最小驗證計畫，優先選擇資訊價值高、成本低、風險小且不破壞正式資料的測試。
10. 區分近因、促成因素與系統性根因；若目前不足以判定，清楚標示。
11. 產出止血、矯正、預防及監測措施，包含負責人、期限、完成證據、風險與退出條件。
12. 產出給主管的一頁式摘要與人工覆核清單。

【輸入資料格式】
事件名稱：【事件名稱】
分析日期：【YYYY-MM-DD】
問題發生範圍：【設備／流程／版本／批次／人員角色】
預期結果：【原本應發生什麼】
實際結果：【實際發生什麼】
業務影響：【時間、數量、金額、品質、客戶或法規影響】

事件時間線：
- 【時間｜事件｜來源編號｜可信度】

已知變更：
- 【時間｜變更內容｜核准／部署證據｜是否可回復】

異常案例：
- 【案例編號｜條件｜症狀｜版本｜時間】

正常對照案例：
- 【案例編號｜條件｜版本｜時間】

現有證據：
- 【證據編號｜內容｜來源｜取得時間｜涵蓋期間】

團隊目前說法：
- 【說法｜提出角色｜依據｜是否已驗證】

可執行的測試與限制：
- 【測試環境｜可用時段｜禁止事項｜正式環境限制】

【限制】
- 只能把輸入中有來源支持的內容列為事實。
- 不得虛構紀錄、時間、數字、測試結果、責任歸屬或根因。
- AI 新提出的解釋一律標為「候選假設」，不可標成已確認。
- 不把同時發生、先後發生或高度相關直接寫成因果。
- 不把沒有紀錄解讀為沒有發生；標示為資料缺口。
- 不把訪談記憶、傳聞與系統紀錄視為同等證據。
- 不使用「人員疏失」作為分析終點，必須再檢查介面、流程、權限、訓練、防呆與工作條件。
- 不建議在正式環境執行可能造成資料破壞、重複交易、寄送、扣款、停機或安全風險的測試。
- 5 Whys 每一層都必須有證據或標示為假設，不能用順暢故事取代驗證。
- 若證據不足，輸出「目前無法確認根因」，不要勉強排名第一。
- 使用繁體中文，語氣專業、清楚、無責備。

【輸出格式】
A. 無原因假設的問題陳述
B. 範圍、排除範圍與結案條件
C. 事件時間線：時間｜事件｜分類｜來源｜信心｜衝突／缺口
D. 事實與說法分層：內容｜事實／推論／假設／未知／已否定｜依據
E. Is／Is Not 比較表
F. 競爭假設表：編號｜假設｜若為真應看到｜若為假應看到｜支持證據｜反證｜缺口
G. 證據矩陣：證據編號｜支持假設｜反對假設｜可靠度｜時間／版本匹配｜替代解釋
H. 驗證計畫：優先序｜測試｜可區分的假設｜所需資料｜風險｜負責人｜預期完成證據
I. 因果分層：近因｜促成因素｜系統性根因｜信心等級｜尚未排除項目
J. 措施表：止血／矯正／預防／監測｜措施｜負責人｜期限｜證據｜退出或重開條件
K. 主管一頁摘要：發生什麼、已知什麼、仍不知道什麼、下一步、需要決策
L. 人工覆核清單

【輸出前自我檢查】
1. 是否把推論或團隊看法寫成事實？
2. 是否只保留一個假設，形成確認偏誤？
3. 是否主動尋找反證與正常對照？
4. 是否有測試會破壞正式資料或造成不可逆影響？
5. 是否把症狀、近因或人員操作當成最終根因？
6. 是否有措施沒有完成證據、監測或退出條件？
7. 目前證據是否真的足以使用「已確認」？

可替換欄位快速表

欄位	填寫方式	範例
【事件名稱】	中性描述，不先放原因	第二台電子秤資料入庫缺漏
【發生範圍】	設備、版本、時段、批次	設備 B／v2.4.1／09:10～10:05
【預期結果】	可量測的正常標準	每筆資料 30 秒內入庫
【實際結果】	數量、頻率或症狀	42 筆未入庫
【來源編號】	可回查的證據代碼	LOG-03、DB-02、INT-01
【正常對照】	同時期未出問題案例	設備 A、C 同版本正常
【禁止事項】	不能在測試中做的事	禁止重送正式批次

實際教學範例

問題背景

10 月 14 日上午，三台電子秤中只有第二台出現資料缺漏。現場第一個說法是「網路不穩」，因為同時有人回報畫面反應較慢。但初步查看後，另外兩台使用相同網路與同一版中介服務，並未出現缺漏。

無原因假設的問題陳述

10 月 14 日 09:10～10:05，設備 B 的 42 筆量測資料未在 30 秒內寫入資料庫；設備 A、C 同時段正常。事件造成批次報表缺漏、55 分鐘人工補登，且其中 6 筆缺少原始重送證據。

關鍵時間線

時間	事件	分類	來源
08:40	設備 B 更換產品批次，匯入新版配方	事實	操作紀錄 OP-01
09:08	中介服務出現第一筆 `field_count mismatch`	事實	LOG-03
09:10	第一筆資料未入庫	事實	DB-02＋設備流水號
09:17	現場回報畫面較慢	訪談紀錄	INT-01
09:42	操作員重新登入，問題仍持續	事實	OP-02
10:02	切回舊版配方後新資料恢復	事實	OP-03＋DB-04
10:05	監控顯示待處理佇列歸零	事實	MON-02

競爭假設

假設	若為真應看到	現有證據	反證／缺口	暫定判讀
H1 網路封包遺失	設備 B 封包缺號、重送或斷線	畫面較慢的訪談	A、C 同網路正常；尚缺交換器埠紀錄	支持不足
H2 設備未送出資料	設備端流水號直接缺少	部分原始資料缺證據	其餘異常筆在設備端可找到	僅能解釋部分案例
H3 新版配方多一欄，解析器拒絕	異常筆應伴隨欄位數錯誤；舊版配方恢復	LOG-03、配方差異、切回後恢復	尚需在測試環境重現	高度支持，未確認
H4 資料庫交易回滾	應有 rollback、鎖定或交易錯誤	無	DB 記錄未見相符事件	目前反對
H5 報表查詢漏資料	原始資料應已入庫，只是報表未顯示	無	DB 查詢確認記錄不存在	已否定此事件主因

最小驗證計畫

在隔離測試環境匯入新版配方，重送三筆去識別化樣本。
比對設備輸出欄位數、中介服務契約與錯誤紀錄。
將解析器加入明確拒絕原因與隔離佇列，再測一次相同資料。
用舊版與新版配方各跑 100 筆，確認不是偶發網路問題。
檢查正常設備是否也曾使用相同新版配方；若有且正常，必須重新評估 H3。

暫定結論

近因候選：中介服務遇到新版配方額外欄位時拒絕解析。
促成因素：錯誤資料未進隔離佇列、監控只看服務存活而未看拒絕筆數。
系統性根因候選：設備輸出與中介服務之間沒有正式版本化介面契約，也缺少配方變更的契約測試。
信心等級：高度支持，尚待隔離環境重現，不可寫成已確認。

改善措施

類型	措施	完成證據	退出／重開條件
止血	新版配方暫停套用設備 B，新增人工核對	暫停紀錄與每日核對表	契約測試與重送驗證通過後退出
矯正	解析器接受新版欄位或明確隔離拒絕資料	測試報告、錯誤佇列畫面	同樣樣本仍缺漏則重開分析
預防	建立介面欄位版本與配方變更契約測試	介面規格、CI 測試證據	任一未核准欄位變更進入正式環境
監測	新增拒絕筆數、佇列延遲與流水號缺口警報	儀表板及警報演練紀錄	警報延遲超過 5 分鐘即檢討

常見錯誤、隱私與使用注意事項

常見錯誤

把最早發現的人當成造成問題的人：發現者、操作員與根因可能完全不同。
把變更時間接近當成因果：變更只是候選，需要版本、差異與重現證據。
只畫一條 5 Whys：單一路徑容易把團隊帶向預設答案，應保留競爭假設。
用會議共識代替證據：多人同意只能代表目前共識，不代表因果已證明。
只找支持材料：沒有刻意尋找反證，結論可信度通常被高估。
用「無法重現」宣布問題消失：可能只是條件尚未還原或監測不足。
把暫時止血當成永久改善：人工覆核能降低影響，但也可能增加新錯誤與成本。
修正後沒有回歸測試：解決一個欄位，可能破壞其他格式或版本。

資料隱私

上傳前移除姓名、帳號、客戶識別碼、設備序號、內網位址、金鑰與正式資料內容。
記錄檔可能含 Token、路徑、查詢內容與個資，不能未檢查就整包交給外部 AI。
使用案例編號、角色、遮罩欄位與區間值，保留分析所需結構即可。
先確認公司核准的 AI 工具、資料保存、訓練使用與跨境傳輸政策。
涉及資安事件、法規、醫療、財務或人員績效時，必須依正式通報與調查流程處理。

使用注意事項

AI 產出的假設只是調查方向，不是責任判定。
根因分析應由真正了解系統、流程與現場的人員共同覆核。
高風險驗證先在隔離環境、資料副本或模擬器進行。
不可為了驗證因果，故意讓正式系統再次發生可能傷害人員、資料或客戶的事故。
對外報告應保留信心等級與限制，不用絕對語氣掩蓋資料缺口。