三門診斷法：Hook / Skill / Agent

你撈到了候選，但不是每個都該寫 skill。這課教你怎麼選對「自動化單位」。

課程目標

認識 Hook / Skill / Agent 三種自動化單位的差別
學會三門診斷法：一個候選進來，怎麼決定走哪扇門
看懂 4 個生活化範例，每個範例為什麼進那扇門
知道「不做」也是一個合理選項

一、為什麼要分三門？

第 1 課提過 Skill / Hook / Agent 三者的差別。今天我們真正用它做決策。

核心觀念：Skill 不是萬能的。有些候選寫成 Hook 更好（更自動）；有些候選該寫成 Agent（更靈活）；有些候選根本不該做（一次性 / 太模糊）。

如果你所有候選都寫成 skill，會發生兩件事：

該自動的事還在等你呼叫 → 沒省到注意力
太模糊的事被硬塞進固定流程 → 變維護地獄

所以要學會選對門。

二、三門的本質差別

門 1：Hook（防呆閘門）

觸發：工具事件（PreToolUse / PostToolUse / Stop / UserPromptSubmit 等）
互動：靜默強制——Claude 不需要決定要不要做，hook 自動跑
適合：高頻 + 規則明確 + 防錯

比喻：辦公室門口的刷卡機。你沒刷不能進，刷了就放行。它不問你問題。

例子：

偵測到 rm -rf → 警告
偵測到改 .env 檔案 → 提醒先備份
session 結束時 → 自動 git commit 提示

門 2：Skill（人機協作）

觸發：用戶說某些話（description 比對）
互動：Claude 跑流程，過程中可能會問你問題、確認方向
適合：中/高頻 + 多步流程 + 需要人類在迴圈裡

比喻：你的工具書 + 助手。你說「翻第 3 章」，它翻到並開始照章執行，但中間會問你「這一段要不要客製化？」

例子：

寫週報（要問你下週計畫）
評估廠商（要看你關心哪些面向）
客戶 onboarding（要確認新客戶身份）

門 3：Agent（自主助理）

觸發：你委派一段任務 + 提供工具
互動：自主跑完，過程中不問你——自己判斷
適合：低頻 + 模糊 + 需要自主決策

比喻：派一個實習生去做事。你給目標和工具，他自己跑回來。中間出狀況他自己想辦法。

例子：

「研究一下競品 A 的最新策略」（subagent 跑研究）
「掃過所有 repo 找出含 TODO 的檔案」（自主找）
「分析下季度 OKR 應該怎麼訂」（自主推理）

三、三門診斷法：3 個問題決定你走哪扇門

拿到一個 skill 候選，依序問 3 個問題：

Q1：這件事規則明確到不需要 Claude 判斷嗎？

是 → Hook（門 1）
否 → 繼續 Q2

什麼叫「規則明確」？意思是：輸入決定輸出，沒有灰色地帶。

✅ 「偵測到 rm -rf 一律警告」（規則明確）
❌ 「客戶問題的回覆語氣要適中」（灰色地帶）

Q2：這件事是多步流程，但每次需要你在迴圈裡嗎？

是 → Skill（門 2）
否 → 繼續 Q3

什麼叫「在迴圈裡」？意思是：過程中你還會給意見、看中間結果、決定下一步分支。

✅ 「寫週報，但下週計畫要我講」（在迴圈裡）
❌ 「掃 100 個 repo 找 TODO」（不需要你在迴圈裡）

Q3：這件事需要自主推理 / 跨領域整合嗎？

是 → Agent（門 3）
否 → 不做（候選太模糊或太一次性）

什麼叫「自主推理」？意思是：沒有固定流程，要看情況決定做什麼。

✅ 「研究這個技術趨勢值不值得投入」（自主推理）
❌ 「把 Excel 轉成 CSV」（純機械）

四、決策樹圖

候選進來
  │
  ├─ 規則明確、不需 Claude 判斷？
  │   ├─ 是 ─→ 寫 Hook
  │   └─ 否 ↓
  │
  ├─ 多步流程 + 你在迴圈裡？
  │   ├─ 是 ─→ 寫 Skill
  │   └─ 否 ↓
  │
  ├─ 需要自主推理？
  │   ├─ 是 ─→ Agent
  │   └─ 否 ─→ 不做（太一次性 / 太模糊）

五、4 個生活化範例

範例 1：每次 commit 前要跑 ruff check

情境：你寫 Python，每次 commit 前都要記得跑 ruff check。

Q1：規則明確？是——「commit 前一律跑 ruff」。 → Hook（PreToolUse, Bash, pattern: git commit*，自動跑 ruff）

為什麼不是 Skill？ 因為你根本不需要被問。每次 commit 都該跑，沒有例外。寫成 skill 反而要你說「跑 ruff」才會跑——多一個動作。

範例 2：客戶 onboarding 流程

情境：每個新客戶你要做 4 件事：建 Drive 資料夾、設 Slack channel、寄歡迎信、登 Salesforce。

Q1：規則明確？否——歡迎信內容會根據客戶類型不同。 Q2：多步流程 + 你在迴圈裡？是——你要確認客戶資料、選歡迎信模板、看 Slack channel 名稱。 → Skill（customer-onboarding）

為什麼不是 Hook？ 因為沒有固定觸發點——客戶不會自己出現在某個 tool 事件裡。 為什麼不是 Agent？ 因為流程是固定的 4 步，不需要自主推理。

範例 3：研究新興技術

情境：老闆問你「這個叫 RAG 的東西到底要不要做？」

Q1：規則明確？否。 Q2：多步流程 + 你在迴圈裡？否——你不知道流程是什麼，需要邊查邊想。 Q3：需要自主推理？是。 → Agent（subagent 跑深度 research）

為什麼不是 Skill？ 因為你寫不出固定流程——每次研究的方向會根據查到的資料調整。 為什麼不是 Hook？ 因為這是主動委派，不是事件觸發。

範例 4：寫今年聖誕 party 的策劃

情境：今年聖誕想辦同樂會。

Q1：規則明確？否。 Q2：多步流程 + 你在迴圈裡？是——但只做一次。 → 不做（一次性，不值得寫成 skill）

為什麼？ 寫 skill 的成本是要付的——你要寫 frontmatter、寫 body、想 description。如果這件事只做一次，用普通 prompt 對話就好。

規則：frequency × token_saved 太低 → 不寫成 skill，用 prompt 解決。

六、混合情境：什麼時候要拆？

有時候一個候選橫跨多扇門——這時要拆。

例子：每週五的週報流程

整個流程其實有 3 段：

觸發：週五下午 5 點 → 不需要你想，直接該跑（Hook 候選——時間觸發）
撈資料：git log + memhall episode → 固定流程（Skill 主體）
寫下週計畫：要你想 → 需要你在迴圈裡（Skill 對話）

→ 拆成：

Hook：週五 17:00 提示「該寫週報了，要不要跑 /weekly-report？」
Skill：/weekly-report 撈資料 + 跟你對話寫下週計畫

七、邊界案例：什麼時候想破頭也不確定？

3 個常見的灰色地帶：

灰色 1：「規則明確但 Claude 判斷會更好」

例子：偵測到「commit message 含『WIP』就提醒」——這是 Hook。但如果是「commit message 不夠精確就提醒」——精確度誰判斷？這要 Claude 看，不能寫死。 → 如果需要 Claude 判斷，寫 Skill 不寫 Hook。

灰色 2：「多步流程但有些步驟可以全自動」

例子：客戶 onboarding 4 步驟裡，建 Drive 資料夾完全可自動。但寄歡迎信要你看內容。 → Skill 主體 + Skill 內呼叫某個全自動步驟。整個流程仍是 Skill，因為入口需要你觸發。

灰色 3：「自主推理但流程其實固定」

例子：寫 PR review。看起來要「自主判斷」，但其實流程固定（讀 diff → 跑 lint → 找 risk → 寫 review）。 → 流程固定就寫 Skill。Agent 是當你寫不出流程時才用的。

八、結論

三門：Hook（防呆閘門）/ Skill（人機協作）/ Agent（自主助理）
診斷三問：規則明確？→ Hook / 多步且在迴圈？→ Skill / 需自主推理？→ Agent
「不做」也是合理答案——一次性、太模糊、太低頻就不要寫
候選跨多扇門 → 拆
灰色地帶 → 偏向較簡單那一邊（Skill 比 Hook 簡單，Skill 比 Agent 簡單）

下一課我們真的動手寫第一個 skill。

AI 協作：學了這個，跟 AI 怎麼配合？

三門診斷的 3 個問題框架是固定的，但「規則明不明確」「需不需要在迴圈裡」的判斷常常是灰色地帶——這時候多問人類，少猜。

你的人類優勢：

你知道部門同事跑 skill 時喜歡介入還是放手——這決定該寫 skill 還是 hook
你知道公司風險容忍度——不可逆操作要不要靜默自動，還是該每次問

可以這樣跟 AI 說：

我有以下候選 [描述]。請套用三門診斷法（Q1 規則明確 / Q2 多步 + 在迴圈裡 / Q3 自主推理）給每個候選一個建議。但灰色地帶不要替我決定——標出灰色地帶並列出「往哪邊倒的後果」，讓我選。