第三部開始

前十四天做的事，用一句話說是：造了一個零件。

從今天開始的九天，講的是把這個零件裝進機器裡。而我要先說清楚一件事：這台機器的價值，遠大於那個零件。 Day 14 的修正方案已經預告了這個轉向——模型可換，但流程、脈絡與審核機制不能換。

四個任務的共同語法

Day 2 提過這條骨架，現在把它展開：

[1] 觸發          ← 事件、提問、排程、學習進度
     ↓
[2] 確定性前處理   ← 程式碼負責：欄位擷取、統計計算、資料查詢
     ↓
[3] 脈絡組裝      ← RAG 檢索 + 歷史範本 + 客戶設定
     ↓
[4] AI 生成初稿    ← 微調模型負責：格式、語氣、敘事、判斷
     ↓
[5] 人審閘道 ★     ← 具名的人負責：核可、修改、退回
     ↓
[6] 正式輸出      ← 交付給客戶 / 存檔
     ↓
[7] 回存          ← 成為下一輪的範本或訓練資料

四個任務全部走這條路。差別只在每一步的內容。

為什麼要有第 2 步（確定性前處理）

最容易被跳過的一步，也是最重要的一步之一。

很多人的做法是把原始資料整包丟給模型，讓模型自己看著辦。這在 demo 時效果很好，在生產環境會出事。原因：

一、模型不會算數。 月報裡「本月告警較上月增加 23%」這個數字，如果是模型算的，它會錯。而且它會錯得很自然，你不看原始資料抓不出來。任何數字都必須由程式算完再交給模型敘述。

二、原始資料有雜訊與敏感欄位。 XDR 匯出的 case JSON 可能有上百個欄位，其中大部分對報告沒用，還有一些含有不該進入 prompt 的內容。前處理是過濾層。

三、確定性的東西應該確定。 CVE 編號的查詢、資產清單的比對、時間軸的排序——這些都有唯一正確答案，交給程式做，一次寫對永遠對。交給模型做，每次都有機率錯。

原則：能用程式算出來的，絕不讓模型算。

為什麼要有第 3 步（脈絡組裝）

這一步決定了初稿的品質上限。

脈絡的三個來源：

1. RAG 檢索——CVE 詳情、標準條文、歷史類似案例
2. 歷史範本——這個客戶上一份同類文件長什麼樣
3. 客戶設定——這個客戶的特殊要求、慣用術語、報告偏好

第 3 項是最容易漏掉、但實務上最有價值的。每個客戶都有自己的怪癖：有的要求嚴重性用五級不用四級、有的堅持不要出現英文縮寫、有的要求建議事項一定要分「立即」與「中長期」。

這些東西不該進模型的參數，該進 prompt 的脈絡。 因為它們會變，而且每個客戶不同。這也是 Day 29「資料脈絡層」的核心概念。

第 5 步：人審閘道，以及我為什麼要用「★」標它

我在 Day 2 說過一次，這裡要說得更完整。

人審閘道不是過渡措施。

常見的想法是：現在模型還不夠好，所以先放個人在那裡把關，等模型進步了就可以拿掉，達成全自動。

我不同意，理由有三層：

第一層是責任歸屬。 這些文件會直接影響客戶的資安決策——他們會根據報告去決定要不要停機、要不要通報、要不要花錢買設備。當這個判斷出錯，必須有一個具名的人為它負責。你不能對客戶說「這是 AI 寫的」。

第二層是專業信任。 MSSP 賣的是專業判斷。如果客戶知道報告是全自動產生的，這個服務的定價基礎就崩了。人審不只是品質控制，它是服務本身的一部分。

第三層是回饋迴路。 沒有人審就沒有修改紀錄，沒有修改紀錄就沒有 Day 14 的「審核修改幅度」指標，也就沒有 Day 19 的知識飛輪。人審是這個系統唯一的學習來源。

那 AI 到底省了什麼？ 省的是從空白頁到初稿。審一份好初稿五分鐘，從零寫二十分鐘。這就是全部，而這已經夠了。

V1 明確排除的東西

我在 V1 劃了幾條線：

• ❌ 不做對外部系統的自動處置（封 IP、隔離主機、改設定）
• ❌ 不做未經審核的對外輸出（不直接寄信給客戶）
• ❌ 不做跨客戶的資料串接（A 客戶的事件不能出現在 B 客戶的脈絡裡）
• ❌ 不做自主的多輪 agent 迴圈（不讓模型自己決定要呼叫幾次工具）

最後一條可能最有爭議，因為現在的潮流就是 agentic。我的理由：自主迴圈的每一輪都是一次不可預測的分支，而不可預測性在資安場景是負債不是資產。 V1 的四個任務都用固定的、可預測的流程圖，每一步都知道會發生什麼。

先讓它可預測地會寫，再考慮讓它自主地會做。

四個 Agent 的規格總覽

★ 標的那格是四個任務裡回饋迴路最強的一個，Day 19 專講。

接下來八天，一個任務一個任務拆。明天從事件報告開始，講那個救了我很多次的 Incident Data Pack。

🛡️Instagram： @aid3fend — AI 資安實戰紀錄，歡迎追蹤交流。