為什麼需要狀態機

第三部把四個任務都做出來了。但有一件事一直沒有正面處理：這些文件在系統裡到底處於什麼狀態，誰可以對它做什麼？

沒有明確的狀態定義，會出現這些問題：

• 一份還沒審核的初稿被寄給客戶
• 一份被退回的初稿被誤當成範本
• 一份含有客戶資訊的報告被拿去當訓練資料
• 出事之後查不出這份文件是誰在什麼時候核可的

四個問題裡，第三個最嚴重，因為它的後果不可逆——資料一旦進了模型參數，就拿不出來了。

狀態定義

   ┌─────────┐
   │  Draft  │  AI 產生，尚未有人看過
   └────┬────┘
        │ 送審
        ▼
  ┌───────────┐
  │ In Review │  審核者已認領，尚未決定
  └─────┬─────┘
        │
   ┌────┴────┬──────────┐
   │核可      │修改後核可  │退回
   ▼         ▼          ▼
┌──────────────┐   ┌──────────┐
│  Approved    │   │ Rejected │
└──────┬───────┘   └──────────┘
       │ 交付
       ▼
┌──────────────┐
│  Delivered   │  已送達客戶
└──────┬───────┘
       │ 去識別化 + 二次核可
       ▼
┌────────────────────────┐
│ Approved for Training  │  可作為訓練資料
└────────────────────────┘

每個狀態的規則

Draft

• 只有系統與指派的審核者可見
• 不可對外輸出，不可作為任何範本，不可進入 RAG 庫
• 有時效：超過一定期限未審核則自動標記過期

In Review

• 已被具名的審核者認領
• 同時間只能有一個審核者持有（避免兩個人各自修改）
• 從這一刻起，所有操作都要進稽核軌跡

Approved

• 必須有具名核可者與時間戳
• 可作為 RAG 檢索來源，可作為未來的格式範本
• 不可再修改；要改就產生新版本，舊版保留

Rejected

• 保留，不刪除
• 標記退回原因（用 Day 19 那六個分類）
• 這是負面樣本的來源，價值不低於 Approved

Delivered

• 已交付客戶，具有對外效力
• 這個狀態之後如果發現錯誤，走的是「更正通知」流程，不是修改文件

Approved for Training

• 這是唯一可以進訓練集的狀態
• 進入條件有三個，缺一不可

Approved for Training 的三個條件

這是整個狀態機最重要的一段，所以單獨講。

條件一：來源狀態必須是 Approved 或 Delivered。 初稿不行、退回的不行、修改中的不行。只有經過人核可的最終文字。

條件二：必須完成去識別化，且去識別化本身要通過驗證。 客戶名、人名、主機名、IP、網段、案件編號、任何可回推到特定客戶的內容，全部要處理掉。而且處理完要驗證——自動掃描 ＋ 抽樣人工檢查。

條件三：必須有第二次的、獨立的核可。 核可「這份報告可以交給客戶」和核可「這份報告可以拿去訓練模型」，是兩個不同的決定，應該由不同的判斷做出。

第三個條件是我後來才加的，加的理由是我意識到一件事：一份報告寫得好不好，跟它適不適合當訓練資料，完全是兩回事。

一份寫得很好的報告，可能因為它涉及的情境太特殊，拿去訓練反而會讓模型學到偏誤。而一份普通的報告，可能因為它的格式標準、情境典型，是很好的訓練樣本。

判斷前者的是資深分析師，判斷後者的應該是懂訓練的人。

狀態轉換的稽核軌跡

每一次狀態轉換都要記錄（合成範例）：

{
  "doc_ref": "IR-2026-0731-014",
  "transitions": [
    {
      "from": null, "to": "Draft",
      "at": "2026-07-31T15:12:00+08:00",
      "by": "system",
      "detail": {
        "datapack_version": "1.0",
        "model_version": "sec-e4b-v0.3",
        "prompt_template": "incident_report_v2",
        "source_case_id": "CASE-2026-0731-0042"
      }
    },
    {
      "from": "Draft", "to": "In Review",
      "at": "2026-07-31T16:03:00+08:00",
      "by": "analyst-lin"
    },
    {
      "from": "In Review", "to": "Approved",
      "at": "2026-07-31T16:21:00+08:00",
      "by": "analyst-lin",
      "detail": {
        "action": "modified_then_approved",
        "modification_types": ["遺漏", "語氣"],
        "diff_ref": "DIFF-8821"
      }
    }
  ]
}

Draft 那一筆的 detail 是關鍵。 它記錄了這份初稿是用哪一版模型、哪一版 prompt、哪一版 Data Pack 組裝程式產生的。

為什麼重要：如果三個月後發現某一版模型有系統性的問題，你可以立刻查出所有受影響的文件。沒有這個記錄，你只能猜。

Approved 那一筆的 modification_types 就是 Day 14 的「審核修改幅度」指標與 Day 19 飛輪的資料來源。稽核軌跡不只是為了合規，它同時是系統改進的燃料。

一個實務上的細節：不可逆的方向

狀態機的箭頭是單向的。特別是：

• Approved 不能退回 Draft。 要改就開新版本。
• Delivered 之後不能修改內容。 錯了要發更正。
• Approved for Training 一旦被用於訓練，該次訓練的資料清單要凍結留存。

最後一條的意思是：每一次訓練，都要留下一份「這次用了哪些文件」的清單。這樣如果某份文件事後被發現不該用（例如去識別化沒做乾淨），你能查出它進了哪幾次訓練、影響了哪些模型版本。

這是資料的召回能力。 你沒辦法從模型參數裡把資料拿出來，但你至少要知道它在裡面。

明天講測試，從三條不能破的鐵律開始。

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