前言

昨天我們處理了「AI 自己編造內容」這種幻覺問題。今天要處理一個相關但更廣泛的情境:當你丟給 AI 的資料本身就不完整、格式跑掉、或出現異常時,該怎麼辦?

這不只是幻覺的問題,而是整個自動化流程能不能「撐過現實世界的髒資料」的關鍵。第二階段最後一天,我們要建立一套完整的「安全降落」邏輯。

一、為什麼「資料異常」是自動化流程裡最容易被忽略的一環

在設計範本的初期階段,你手上測試用的資料通常是乾淨、完整的——這會讓你誤以為「範本已經很穩了」。但真實情況是:只要這套流程長期運作下去,遲早會遇到資料不完整的那一週——監控平台當機少匯出一筆資料、某個欄位忘記填、資料格式因為系統更新而跑掉。

如果範本只在「資料乾淨」的情況下測試過,遇到這些狀況時,行為會完全不可預測——這正是回到 Day 2 談的「穩定性」問題:一套系統的穩定性,不是看它在理想狀況下表現多好,而是看它在意外狀況下,會不會整個崩潰或亂猜。

二、常見的資料異常情境分類

在設計「安全降落」規則之前,先把可能遇到的異常情境分類清楚,通常可以分成三大類:

1. 資料缺漏(Missing Data)
某個欄位是空的、或整筆資料完全沒有匯出。這是 Day 11 已經觸及的情境,今天會更完整地涵蓋。

2. 資料格式異常(Malformed Data)
欄位順序跟平常不一樣、日期格式突然變了、原本該是數字的欄位出現文字。這種情況下,AI 有可能誤判資料的意義,把不該對應的內容配錯位置。

3. 資料內容矛盾(Inconsistent Data)
例如同一筆事件,狀態欄位寫著「已結案」,但備註欄位卻寫著「持續觀察中」——這種內部邏輯衝突的資料,AI 該相信哪一個?如果沒有事先規定,它可能會隨機選一個、或試圖「合理化」兩者矛盾之處,反而生出更混亂的內容。

三、針對每一種異常,設計對應的安全降落規則

針對資料缺漏:

延續 Day 11 的做法,明確規定缺漏時的替代行為:

若某欄位資料缺漏,該欄位標註「未提供」,不得留空或自行填入推測值。
若整份資料明顯不完整(例如少於平常慣例的最低事件數量門檻),請在報告開頭加註提醒:「本次資料可能不完整,建議人工確認來源完整性」。

針對格式異常:

這裡的重點是「不確定時,不要硬猜」:

若資料格式與預期結構不符(例如欄位缺失、順序錯亂、型別不對),請不要嘗試自行推測欄位對應關係。請在報告最上方註明「本次輸入資料格式異常,以下內容可能不完整或有誤,建議人工複核原始資料」,並盡力就可辨識的部分整理內容。

針對內容矛盾:

這裡的原則是「誠實呈現矛盾,而不是替使用者做決定」:

若同一筆資料中出現欄位間邏輯矛盾(例如狀態與備註不一致),請如實列出兩者矛盾之處,並標註「此筆資料存在欄位矛盾,建議人工確認實際狀態」,不得自行判斷以哪個欄位為準。

四、一個核心原則:「降低自信」比「假裝正常」更安全

這三類規則背後,其實貫穿著同一個核心原則:當 AI 不確定的時候,它應該做的事,是把不確定性明確表達出來,交還給人類判斷,而不是裝作一切正常、生出一份「看起來完整,實際上可能錯誤」的報告。

這一點特別值得强調,因為對很多人來說,「看起來完整」往往比「誠實標註問題」更讓人有安全感——但在資安治理這種場景,一份「看起來沒問題,實際上藏著錯誤」的報告,風險遠高於一份「誠實地說『這裡有問題,需要人工確認』」的報告。寧可讓報告看起來不夠完美,也不要讓它看起來完美卻藏著錯誤。

五、安全降落規則不是「一次寫完就結束」

要注意,今天列出的規則,是根據「常見情境」預先設計的,但真實世界的異常狀況往往比你事先想到的更多樣。這也是為什麼 Day 20 要安排「用一週的真實資料進行壓力測試」——很多異常情境,是實際跑過真實資料之後才會被發現的,今天建立的是一套基礎框架,後續會隨著實戰不斷補充新的例外規則。

六、今天的行動練習

回顧你過去實際遇過的資料異常經驗(不管是手動處理報告時,還是初步測試 AI 範本時),對照今天的三大分類(缺漏、格式異常、內容矛盾),看看哪些情境你已經遇過、哪些還沒發生過但可以預先想到。針對已知的情境,把今天的句型範本套進你的 System Prompt 裡。

小結

第二階段到這裡告一段落。這十二天,我們從「怎麼系統化描述你要什麼」(CO-STAR、Context、Role、格式、語氣、範例),一路走到「怎麼教 AI 面對不確定時該怎麼辦」(幻覺防呆、異常資料的安全降落)。這兩塊合起來,構成了一份範本的完整規則骨架。

下一階段,我們要把焦點從「怎麼寫規則」轉移到「怎麼處理你丟進去的資料本身」——包括認識你的資料來源、應付篇幅過長的問題,以及讓 AI 做出更可靠的簡單推理判斷。