前言
前兩階段,我們把「規則該怎麼寫」這件事處理得很完整了。從今天開始進入第三階段,焦點要轉移到硬幣的另一面:你丟進去的資料本身。再好的規則,如果建立在「你其實不夠了解自己資料」的基礎上,遲早會出問題。
今天要做的事情看似基礎,卻是很多人會跳過、事後才後悔的一步:徹底盤點你的輸入資料。而這一步,還有一件更重要的事必須在這裡先立下規矩——機敏資料的處理原則,必須在你把第一筆真實資料丟給 AI 之前就先確立,而不是等到自動化都做完了才想起來。

一、為什麼「先盤點資料」比「先寫 prompt」更根本
回顧 Day 4 的變數化思維,我們談過要區分「固定不變」跟「每次變動」的元素。但要能做出這個判斷,前提是你得先清楚知道你的資料,到底有哪些欄位、哪些欄位穩定、哪些欄位常常變動。如果你對自己的資料來源都還沒摸透,前面十二天學的所有框架,都會建立在一個不牢靠的地基上。
二、盤點資料的四個面向
以監控平台匯出的事件資料為例,盤點時建議至少涵蓋以下四個面向:

1. 欄位清單與定義 列出匯出檔案裡實際包含哪些欄位(例如:事件時間、事件類型、風險等級、處理狀態、負責人、備註),並且針對每個欄位,確認公司內部對它的明確定義是什麼——尤其是像「已結案」跟「處理中」這種狀態欄位,不同部門有時候對同一個詞的認定標準不一樣,這個定義差異必須先搞清楚,才不會讓 AI 依照錯誤的認知去判斷。
2. 資料的穩定性 哪些欄位幾乎不會改變格式(例如事件類型通常是固定的幾種分類)?哪些欄位比較容易因為系統更新、人工填寫習慣不同而產生變化(例如備註欄位常常是自由文字,格式最不固定)?這個盤點結果,會直接影響 Day 15 資料預處理時,你該把重點放在哪些欄位上。
3. 資料的量級 一般情況下,一週大概會有多少筆事件資料?這個資料量,轉換成文字之後大概會佔多少篇幅?這個問題聽起來單純,但直接關係到明天要談的 Token 限制議題——如果你完全沒概念自己一週的資料量有多大,遇到資料量突然暴增的那一週,範本很可能會出狀況卻搞不清楚原因。
4. 已知的例外情況 有沒有你已經知道、會發生但不常發生的特殊狀況?例如某類事件偶爾會缺少特定欄位、或某些舊資料的格式跟現在的匯出格式不太一樣。這些已知的例外,可以直接補進 Day 11、Day 12 建立的防呆規則裡,不需要等到真的踩到雷才臨時處理。
   三、機敏資料原則:必須提前建立的第一道防線
   這是今天最重要的一部分。在你開始用真實資料測試範本之前,必須先明確回答這幾個問題:

• 哪些欄位屬於機敏資料,絕對不能原封不動丟給 AI 工具?(例如可能包含個資的欄位、內部系統的實際 IP 位址或帳號名稱等)
• 這些機敏欄位,是完全不能使用,還是可以經過處理後使用?(例如把實際 IP 位址替換成通用的分類標籤,保留分析價值但移除可識別的原始資訊)
• **公司對於「哪些資料可以餵給 AI 工具」,有沒有既定的資安規範?**這一步,身為資安治理單位的一員,你應該比多數人更清楚該去找誰確認、該遵守什麼標準。
  這個原則必須寫成明確的資料前處理規則,並且在你進行 Day 20 的壓力測試、使用第一批真實資料之前就要落實——而不是像原本大綱規劃的那樣放到最後一天才討論。順序上,機敏資料保護是地基,不是收尾。
  四、盤點結果怎麼運用到後續的範本設計
  今天盤點出來的結果,會直接餵給接下來好幾天的內容:
• 欄位定義 → 補進 Day 7 的 Context 設定,讓 AI 對這些名詞有正確認知
• 資料穩定性分類 → 呼應 Day 4 的變數化思維,決定哪些規則該寫進骨架的哪一層
• 資料量級 → 明天 Day 14 處理 Token 限制議題的基礎
• 已知例外情況 → 補進 Day 11、12 的防呆規則清單
• 機敏資料原則 → 成為 Day 20 壓力測試前,一份不可省略的檢查清單
  五、今天的行動練習
  實際拉出一份監控平台的匯出檔案,對照今天的四個盤點面向(欄位定義、穩定性、量級、已知例外),寫成一份簡單的資料盤點紀錄。同時,針對機敏資料原則這一項,列出你目前不確定、需要進一步跟主管或資安規範確認的問題清單。

小結
今天沒有寫任何一句 prompt,因為在設計資料處理邏輯之前,你得先徹底了解自己每天/每週在跟什麼樣的資料打交道——尤其是機敏資料的紅線,必須是整個工作流程裡最早確立、而不是最後才想起來的規則。這步驟做得紮實,後面的資料預處理、Token 管理、例外規則設計,才會建立在真正了解自己資料的基礎上。
下一篇,我們會處理一個很實際的技術限制:當一週的資料量超出 AI 一次能處理的長度上限時,該怎麼辦?