一個看起來很浪費的決定

四個任務有很多共同點：都要組脈絡、都要生成初稿、都要送審、都要記錄。用一套共用的指令集（我在專案裡稱為 SKILL）來驅動，聽起來是理所當然的工程實踐。

我沒有這樣做。四個任務各有各自獨立的 SKILL，重複的部分就讓它重複。

今天講為什麼。

SKILL 裡有什麼

一個任務的 SKILL 包含：

• 該任務的 system prompt 與規則
• 脈絡組裝的欄位定義與順序
• 輸出的格式規範
• 拒答與降級的邊界
• 審核送出的條件
• 錯誤處理的行為

四個任務的這些內容，看起來有 60–70% 是相似的。

理由一：規則的變動是任務特定的

先看一個具體的例子。

Day 18 講到顧問問答的 D 類（法規合規）有一條規則：

不得對法規做延伸解釋或推論適用範圍。

這條規則對顧問問答是必要的。但如果放進共用的 SKILL，它會影響到事件報告——而事件報告的「建議處置」段落確實需要一定程度的延伸推論（從觀察到的行為推論該做什麼）。

如果 SKILL 共用，我會面臨兩個選擇：

1. 把規則寫成有例外的複合規則（「除了在事件報告的建議段落之外…」）
2. 放棄這條規則

兩個都不好。第一個會讓規則越長越複雜，最後沒有人（也沒有模型）能正確遵守。第二個是放棄品質。

規則的複雜度會隨共用範圍指數成長。 四個任務各自的規則都很簡單清楚，合起來會變成一份沒人看得懂的文件。

理由二：拒答邊界必須是任務特定的

這一條最重要。

四個任務的合理拒答邊界完全不同：

看第一欄與第二欄的對角線：新人訓練需要最寬鬆的技術討論邊界，顧問問答需要最嚴格的法規發言邊界。

如果用共用 SKILL，你只有兩個選擇：取交集（最嚴格），或取聯集（最寬鬆）。

• 取交集：新人訓練會拒答它該答的教學內容，任務廢掉。
• 取聯集：顧問問答會開始對客戶解釋法規適用性，這是專業事故。

安全邊界不能取交集也不能取聯集，它必須是逐任務定義的。

這一點是我對整個 agentic 架構最強的一個主張：能力可以共用，權限與邊界不行。

理由三：可獨立測試與獨立變更

測試：四個獨立的 SKILL，可以四組獨立的測試案例。改動任務三的 SKILL 只需要重跑任務三的測試。

如果共用，任何一次改動都要重跑全部四組，而且要擔心對其他三個任務的副作用。在一個沒有確定性輸出的系統裡，這個副作用非常難驗證。

變更：客戶要求調整月報格式，我改任務三的 SKILL，其他三個完全不受影響，也不需要重新驗證。這在維運上的價值非常大。

理由四：故障隔離

如果任務二的 SKILL 出問題（規則寫錯、prompt 有 bug），影響範圍就是任務二。

共用的話，一個錯誤會同時影響四條產線。而且這種錯誤不會像程式碼那樣直接崩潰——它會安靜地降低所有輸出的品質，可能好幾天才被發現。

那共用的部分怎麼辦？

我不是完全放棄重用，而是在下面一層重用。

        任務一 SKILL   任務二 SKILL   任務三 SKILL   任務四 SKILL
              ↓             ↓             ↓             ↓
        ┌──────────────────────────────────────────────────┐
        │  共用的底層元件（工具，不含規則）                  │
        │  ・RAG 檢索介面                                   │
        │  ・脈絡組裝的資料結構                             │
        │  ・審核佇列與狀態機                               │
        │  ・稽核軌跡記錄                                   │
        │  ・模型呼叫封裝                                   │
        └──────────────────────────────────────────────────┘

分界線是：機制共用，政策不共用。

• ✅ 「怎麼呼叫 RAG」——機制，共用
• ❌ 「該檢索什麼、檢索不到時怎麼辦」——政策，不共用
• ✅ 「怎麼把文件送進審核佇列」——機制，共用
• ❌ 「什麼條件下才能送審」——政策，不共用
• ✅ 「怎麼記錄稽核軌跡」——機制，共用
• ❌ 「哪些欄位必須記錄」——政策，不共用

這條線在資安架構裡其實很熟悉——它就是機制與政策分離（separation of mechanism and policy），一個很老的系統設計原則。我只是把它套用到 AI agent 上。

這個決定的代價

我不假裝這沒有成本：

一、四份 SKILL 要各自維護。 如果有一條規則真的四個任務都要改，我要改四個地方。

二、可能出現不一致。 四份文件可能慢慢漂移，同一件事在不同任務有不同做法。

三、初期開發較慢。 寫四份比寫一份慢。

我的處理是：接受代價一與三，用文件與 review 管理代價二。 四份 SKILL 放在一起做定期的交叉檢視，看有沒有不該存在的差異。

但我不會為了消除這些代價而去共用。 因為理由二（拒答邊界）是一個安全問題，而其他理由是工程便利性問題。安全問題永遠優先於工程便利。

第三部總結

九天下來：

1. 一條共同的流程語法，四個任務都走（Day 15）
2. Incident Data Pack——別把原始資料丟給模型（Day 16–17）
3. 快慢兩條路徑與「該轉人就轉人」的分類設計（Day 18）
4. 知識飛輪，以及它會放大偏誤的風險（Day 19）
5. 月報是續寫，統計歸程式敘事歸模型（Day 20）
6. 出處比答案重要，好的干擾選項本身就是教材（Day 21）
7. 系統報告事實，人做判斷（Day 22）
8. 機制共用，政策不共用（Day 23）

如果第二部的結論是「搞清楚模型不該做什麼」，第三部的結論就是「把它不該做的事，一件一件交給對的人或對的程式」。

明天進入最後一部：這套東西要怎麼測、怎麼治理，以及為什麼模型可以換而治理不能換。

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