Hook 只能用來擋東西嗎？可以用來主動加東西進對話裡嗎？
可以。Hook 除了攔截跟阻擋，也能用來主動注入資訊。例如 SessionStart 這個事件會在每次對話開始時觸發，你可以綁定一個指令，自動抓取當下的 git 分支名稱，把它當成額外的背景資訊塞進對話一開頭，不需要你每次手動告訴 Claude「我現在在哪個分支」。
這跟 PreToolUse／PostToolUse 的攔截型用法是同一套機制、不同的應用方向：攔截型是「這件事不該發生時擋下來」，注入型是「這個資訊每次都該存在時自動補上」，兩者都是把「應該穩定發生的事」變成機制保證，而不是依賴口頭提醒。
為什麼不能把所有 CLAUDE.md 裡的規則都改用 Hook，一次解決漏執行的問題？
因為兩者適合處理的規則性質不一樣。Hook 的強項是「判斷條件明確、動作固定」的規則，例如「偵測到特定字串就擋下」「檔案寫入後就跑格式化指令」，這類規則不需要理解上下文、不需要判斷力，純粹是條件符合就執行，很適合寫成腳本。
但有些規則需要判斷「是否符合專案風格」「這段程式碼的命名是否清楚」，這類需要理解語意、沒有絕對是非對錯的規則，很難寫成一個簡單的 shell 腳本去判斷，這時候留在 CLAUDE.md 裡讓 Claude 用理解力去判斷，反而比硬寫死規則更合適。實務上比較好的分工是：機械化、非黑即白的規則交給 Hook，需要語意判斷的規則留在 CLAUDE.md，兩者搭配使用，而不是二選一。
設定 Hook 會不會很複雜，需要很深的技術背景嗎？
門檻其實不算高，最基本的 Hook 就是一段 shell 指令加上你要綁定的事件類型，寫在設定檔裡。以最常見的自動格式化為例，你只需要指定「PostToolUse 事件」「符合 Write 或 Edit 這類工具」，然後綁定「執行格式化工具的指令」，不需要寫複雜的程式邏輯，很多常用場景其實是複製官方文件或社群分享的範例、微調路徑跟工具名稱就能用。
真正需要多花心思的是「攔截型」的 Hook，例如判斷指令裡是否包含危險字串，這類需要寫一點條件判斷的邏輯，但也不到需要深厚程式背景的程度，網路上已經有大量現成範例可以直接參考、依自己的專案需求做調整，不需要從零開始設計。
如果我設了 Hook，之後想改變主意，例如某次不想跑格式化，會很難繞過嗎？
這要看你怎麼設計。如果是綁在 PostToolUse 上的格式化指令，通常你還是可以事後手動改回去，或是暫時把那條 Hook 從設定檔裡拿掉再繼續，Hook 保證的是「條件符合就會執行」，不是「執行後不能再被人工調整」；但如果是 PreToolUse 綁的阻擋型 Hook（例如攔截刪除指令），這類 Hook 的存在意義就是不希望被輕易繞過，設計上通常也不會留一個簡單的例外開關，你想真的執行那個被擋下的動作，得手動去改設定檔本身，而不是在對話裡跟 Claude 商量。
這也是設計 Hook 時值得先想清楚的一點：這條規則你希望它是「大多數情況下自動生效、偶爾可以彈性調整」，還是「無論如何都不該被繞過」，兩種心態會讓你把 Hook 設計成不同的嚴格程度。
你在 CLAUDE.md 裡寫了「每次改完程式碼要用 Prettier 格式化」，Claude 大部分時候都會照做，但總有那麼幾次漏掉——這不是 Claude 故意偷懶，是 CLAUDE.md 本質上是「指示」，Claude 會盡量遵循，但它仍然是模型自己判斷要不要執行的一句話，跟你寫在 shell 腳本裡、電腦保證一定會跑的指令，是完全不同等級的可靠度。Hooks 解決的正是這個落差：它讓某個動作在特定時機一定會執行，不是「Claude 記得就做」，是「不管 Claude 怎麼想，這件事都會發生」。
Hook 是你在設定檔裡定義的 shell 指令，綁定在 Claude Code 生命週期裡的特定事件上——例如「工具呼叫前」「工具呼叫後」「對話開始時」。當那個事件真的發生，你綁定的指令就會自動執行，不需要 Claude 主動決定要不要做。這個概念跟 Git hooks 很像：Git 在 commit 前後有固定的觸發點，你可以掛上自己的腳本，Hooks 在 Claude Code 的操作生命週期裡也是同樣的邏輯。
PreToolUse 在 Claude 要執行某個工具「之前」觸發，可以用來擋下危險操作——例如偵測到指令裡包含 rm -rf 這類刪除語法，直接擋下這次執行，不讓它真的跑。PostToolUse 在工具執行「之後」觸發，最常見的用法是自動格式化：只要 Claude 寫入或編輯了檔案，立刻自動跑一次 Prettier 或你慣用的格式化工具，不需要在 CLAUDE.md 裡反覆提醒「記得格式化」。
CLAUDE.md 或 Prompt 裡寫的規則，Claude 有可能因為對話夠長、規則被稀釋，或是任務本身讓它判斷「這次好像不需要」而跳過；Hook 不會有這個問題，因為它根本不經過 Claude 的判斷——事件觸發，指令就跑，這是機制層面的保證，不是說服層面的請求。這個差異在「必須每次都成立」的場景特別關鍵：例如保護敏感檔案不被意外覆寫、確保測試在每次改動後都真的跑過一次，這些事情你不會希望它「大部分時候」發生，你會希望它「每次」都發生。
不需要一次把所有事件類型都學會，從三個最實用的組合入手就夠：自動格式化（PostToolUse 綁定格式化工具）、保護敏感檔案（PreToolUse 攔截對 .env 這類檔案的寫入）、危險指令攔截（PreToolUse 偵測刪除類指令並擋下）。這三個涵蓋了新手最常見的「明明講過、還是被漏掉」的痛點，熟悉之後再依自己的工作流程慢慢加。
每次 Claude 漏掉一個你以為講清楚的規則，代價不只是那一次的疏失，而是你得花額外的對話輪次去發現問題、解釋規則、要求修正——這些都是實質的 token 花費，而且往往是在專案已經進行到一半、修正成本最高的時候才發現。把真正不能妥協的規則從「寫在 CLAUDE.md 裡的請求」升級成「用 Hook 保證執行的機制」，前期設定花的時間，換來的是後續不用再為同一件事反覆糾正、反覆浪費對話輪次的長期節省。