Hook 的邊界與安全

接入真實工作流，先停一下

學了 Hook 的基本觀念，很多人會興沖沖地直接開始設定：把 Hook 接進工作資料夾、讓它自動移動檔案、自動改名、自動提交——

然後踩到第一個坑。

Hook 是自動執行的腳本。這代表它不會停下來問你「確定嗎？」它觸發了，就直接做。你在這裡犯的錯，會比手動操作更難發現、更難還原。

所以在把 Hook 接進真實工作流之前，要先建立幾個好習慣。

---

從測試資料夾開始

最重要的一條規則：先在測試資料夾跑，確認行為正確，再接到真實環境。

建立一個 ~/hook-test/ 或 ~/sandbox/ 這樣的資料夾，把假資料丟進去，讓 Hook 在那裡練習。

在這個「沙盒」裡，你可以放心觀察 Hook 的行為：

• 觸發條件對了嗎？
• 它動到的是正確的檔案嗎？
• 有沒有意外的副作用？

確認一切符合預期之後，再把設定指向真實資料夾。

涉及以下動作的 Hook 尤其要謹慎：

• 移動或重命名檔案
• 刪除任何東西
• 自動填表或提交表單
• 改寫設定檔

這些動作一旦執行，復原成本比你想的高。

---

Token 成本：Hook 觸發 AI 的那種

上一課說過，大部分 Hook 本身不耗 token——它就是一段腳本，跑完就結束。

但有一種情境要特別注意：Hook 觸發了一個 Skill，而那個 Skill 呼叫了 AI 模型。

舉個例子：

你設了一個 Hook，每次存檔就自動叫 AI 幫你 review 剛剛修改的段落。

這個流程跑起來很爽——存個十次，AI 自動給了十次回饋。然後你看到帳單。

這不是說這種用法不行，而是你要先想清楚：

• 這個 Hook 一天大概會觸發幾次？
• 每次觸發送給 AI 的 prompt 有多大？
• 這個成本是你願意接受的嗎？

如果是低頻觸發（例如「任務全部完成時」才叫一次 AI 產報告），成本通常很合理。如果是高頻觸發（例如「每次按下存檔」），就要特別評估。

---

不要一次設太多 Hook

Hook 跟 Skill 一樣，設太多會讓系統變得難以維護。

你的 AI 工作流是一個整體，Hook 是裡面的自動觸發點。當你設了二十個 Hook，每個都在不同時刻觸發、做不同的事，幾個月後回頭看，你自己都搞不清楚這些 Hook 是在什麼情況下跑、它們之間有沒有衝突。

從少開始，確認穩定之後再增加。

一個確實在用的 Hook，勝過五個你忘記設定了什麼的 Hook。

---

好的 Hook 設計習慣

每個 Hook 只做一件事

一個 Hook 做太多事，除錯就變得很麻煩。你不知道是哪一步出問題。

把複雜的流程拆成幾個單純的 Hook，每個只負責一個動作，清楚很多。

命名要讓人一眼看懂

format-edits.sh        ✅ 清楚
notify-done.sh         ✅ 清楚
run-after-commit.sh    ✅ 還行
script1.sh             ❌ 是什麼？
final_v3.sh            ❌ 更不知道是什麼

檔名是你未來的自己、或是隊友看到的第一個線索。

記錄每個 Hook 的用途

在 Hook 腳本開頭，加幾行說明就夠了：

這不是文件主義，這是你未來的保險。

---

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

你現在知道 Hook 的邊界在哪裡。下一步是讓 AI 幫你設計出符合這些邊界的 Hook。

你的人類優勢

• 你知道哪些資料夾裡放的是不能出錯的東西
• 你能判斷一個 Hook 在你的工作流裡會觸發多少次
• 你能評估哪些動作需要人工確認、哪些可以全自動

可以這樣跟 AI 說

我想設一個 Hook，在 Claude Code 每次寫入檔案後，自動把那個檔案複製一份到 ~/backup/ 資料夾。
但我希望：1. 只有在 ~/projects/ 底下的檔案才觸發；2. 如果複製失敗要在終端機顯示錯誤；3. 不要叫 AI 做任何事，就是純腳本。
幫我寫這個 Hook 腳本，然後說明怎麼設定進 Claude Code。

---