如果你已經(jīng)開始用 Claude Code 處理日常編碼任務(wù)大概率遇到過這樣的局面它寫得很快但改完的代碼格式化風格跟項目規(guī)范完全不是一回事它偶爾會提出一個看起來很合理的 bash 命令但你沒仔細看就批準了測試它也提可更多時候是建議你“自己跑一下試試”。這些問題不是模型能力不夠而是缺少一套強制性的機制在工具調(diào)用鏈路里卡點。Hooks 就是干這個的。這篇文章我會用 6 個可直接抄走的配置把代碼格式化、安全防護和自動測試這三件事焊死在 Claude Code 的工作流里涵蓋 PreToolUse、PostToolUse、Stop、Notification 等觸發(fā)時機和完整腳本適合所有用 Claude Code 寫代碼、并且希望少一點失控感的人。先說清楚一件事hook 不是讓你在 prompt 里多寫幾行“請遵守項目規(guī)范”而是在 Claude 調(diào)用工具Bash、Edit、Write、Read的前后掛上外部腳本。腳本不滿足條件工具調(diào)用就直接被攔下。這種“硬約束”和“軟提示”的區(qū)別就是為什么很多人配置完 hooks 之后代碼合入 CI 的一次通過率明顯提升。1. Hooks 到底解決了什么問題先看三個最常見的失控現(xiàn)場1.1 失控現(xiàn)場一格式化規(guī)則全憑心情我用 Claude Code 做過一個小型 TypeScript 項目。模型默認的代碼風格跟項目里 prettier 配置不能說一模一樣只能說是各寫各的。單引號、雙引號混用對象末尾逗號時有時無縮進偶爾從兩個空格跳成四個。最頭疼的是它每次 Edit 只改一小塊格式化問題被分散在十幾個文件里肉眼根本盯不過來。你可以在系統(tǒng)提示詞里寫“請始終使用項目 prettier 配置”但模型記不住每一條規(guī)則的細節(jié)更不會在每次寫入前主動跑一遍格式化。等 CI 跑完報錯再回頭修一個下午就沒了。Hooks 的正確姿勢是在文件落盤之后、或者寫入之前由外部腳本強制執(zhí)行 prettier不讓模型的“個人風格”有機會進入代碼庫。1.2 失控現(xiàn)場二危險命令說跑就跑Claude Code 的 Bash 工具權(quán)限很大。它可能因為你的某句“清理一下項目”就執(zhí)行rm -rf node_modules這還算可控但它也可能在改依賴時順手執(zhí)行npm install --unsafe-perm或者在你沒注意的時候往~/.bashrc里追加內(nèi)容。AI 沒有“這個操作影響范圍是否超出當前項目”的常識它只有“用戶讓我完成目標”的指令。我見過有人被 Claude 連續(xù)執(zhí)行了git push --force覆蓋遠端提交也見過它在排查問題時把.env里的密鑰cat到了對話上下文里這些事后都很不好收拾。Bash 類的 hook 就是最后一道閘門命令在執(zhí)行前先過一遍規(guī)則命中風險項直接阻止并告訴 Claude 為什么不行。1.3 失控現(xiàn)場三測試永遠“我建議你跑一下”另一個讓我比較無語的行為模式是Claude 改完代碼它的收尾往往是“測試已更新建議你運行npm test驗證”。如果你不追問它就當你已經(jīng)跑過了。偶爾它會主動跑但改一次跑一次全量測試幾分鐘就浪費在等待上。自動測試類的 hook 能解決兩個層面一是強制改完代碼后自動觸發(fā)相關(guān)測試沒有通過就繼續(xù)修二是精準不是所有變更都跑全量測試而是根據(jù)變更文件反推對應的測試范圍。后面我會給出具體的實現(xiàn)思路。2. 開工前必讀settings.json 和 Hook 觸發(fā)機制的基礎(chǔ)2.1 配置文件放哪項目級與用戶級Claude Code 的 hooks 配置寫在settings.json里。項目級位置是.claude/settings.json用戶級位置是~/.claude/settings.json。項目級配置隨倉庫走適合團隊統(tǒng)一約束用戶級配置只對本機生效適合放個人習慣類的 hook。我建議大部分自動化規(guī)則放項目級這樣團隊里任何人用 Claude Code 都會被同一套規(guī)則約束。需要說明的是項目級配置默認情況下對協(xié)作者可見你最好在 README 里寫清楚每個 hook 的用途免得別人 clone 項目后第一次跑被攔截腳本嚇一跳。2.2 六類事件與 matcher 匹配規(guī)則Hooks 的配置結(jié)構(gòu)大致是{ hooks: { PreToolUse: [ { matcher: Edit|Write, hooks: [ { type: command, command: node .claude/hooks/check-format.js } ] } ] } }PreToolUse是事件名表示“工具執(zhí)行之前”。官方支持的事件類型主要有這些事件名觸發(fā)時機典型用途PreToolUse工具調(diào)用前攔截危險命令、檢查寫入內(nèi)容PostToolUse工具調(diào)用后格式化、Lint、自動測試NotificationClaude 等待用戶確認時桌面通知提醒StopClaude 回復生成完成運行完整校驗、輸出摘要SessionStart會話開始環(huán)境檢查、項目信息注入UserPromptSubmit用戶提交提示詞時內(nèi)容過濾、追加上下文PreCompact上下文壓縮前保存任務(wù)進度摘要matcher是一段正則表達式用來限定 hook 作用于哪些工具或哪些調(diào)用。比如Edit|Write表示匹配編輯文件和新建文件操作Bash表示匹配所有 bash 命令也可以寫成Bash\\(.*git.*\\)這類更精確的形態(tài)去匹配包含 git 的命令。2.3 退出碼、stdin JSON 與超時三個決定成敗的細節(jié)hook 命令執(zhí)行時Claude Code 會通過 stdin 傳入一段 JSON里面至少包含{ session_id: xxx, cwd: /home/user/project, hook_event_name: PreToolUse, tool_name: Bash, tool_input: { command: rm -rf node_modules } }腳本要做的就是讀取這段 JSON然后根據(jù)tool_input內(nèi)容決定返回什么退出碼。我這里約定退出碼0放行工具繼續(xù)執(zhí)行。退出碼2阻止工具執(zhí)行stdout 內(nèi)容會返回給 Claude讓它知道被攔的原因。其他非 0 退出碼表示 hook 自身出錯Claude Code 會記錄 warning但不會強制阻止工具。所以攔截類邏輯務(wù)必用2。還有一個容易被忽略的是timeout。hook 命令默認超時時間是 60 秒超過會被終止。如果你的自動測試腳本可能要跑幾分鐘一定要在 hook 配置里顯式調(diào)大{ type: command, command: node .claude/hooks/run-tests.js, timeout: 120 }另外hook 腳本的 stdout 和 stderr 會被 Claude Code 捕獲并放進模型上下文。這意味著你可以在腳本里輸出給模型看的提示信息但不要打印一堆無關(guān)日志否則會白白消耗 token還會干擾模型對工具調(diào)用結(jié)果的理解。3. 前兩個配置用 PreToolUse 和 PostToolUse 把格式化和 Lint 焊死在編輯動作上3.1 配置一文件落盤后自動格式化不用再跟模型強調(diào)“別用雙引號”這是我在所有項目里第一個配的 hook。先給結(jié)論用 PostToolUse 而不是 PreToolUse 做格式化。原因在于調(diào)用時序。PreToolUse 發(fā)生在 Claude 的 Edit/Write 工具真正寫入文件之前這時你拿到的file_path是目標路徑但文件內(nèi)容還沒寫入或者寫入的是舊版本。如果你在這個時機去prettier --write格式化的是舊文件等 Edit 執(zhí)行完新內(nèi)容覆蓋上去格式化又被沖掉了。所以正確做法是 PostToolUse。腳本在 Edit/Write 完成后拿到文件路徑立刻執(zhí)行格式化命令#!/usr/bin/env node // .claude/hooks/format-on-write.js const fs require(fs); const { execSync } require(child_process); let input ; process.stdin.on(data, (chunk) (input chunk)); process.stdin.on(end, () { try { const payload JSON.parse(input); const filePath payload.tool_input?.file_path; if (!filePath) process.exit(0); const ext filePath.split(.).pop(); const supported [ts, tsx, js, jsx, json, css, md]; if (!supported.includes(ext)) process.exit(0); // 跳過 node_modules 和生成目錄 if (filePath.includes(node_modules) || filePath.includes(dist)) process.exit(0); execSync(npx prettier --write ${filePath}, { cwd: payload.cwd, stdio: pipe, }); console.log([format] ${filePath} 已按項目 prettier 配置格式化); process.exit(0); } catch (e) { // 格式化失敗不阻斷工具調(diào)用避免惡性循環(huán) console.error([format] 格式化失敗: ${e.message}); process.exit(0); } });配置代碼里注冊它{ hooks: { PostToolUse: [ { matcher: Edit|Write, hooks: [ { type: command, command: node .claude/hooks/format-on-write.js } ] } ] } }你可能會擔心一個問題格式化之后的文件內(nèi)容和 Claude 在上下文里看到的“剛寫入的內(nèi)容”不一致。實際影響不大因為 Claude 下次讀取文件時讀到的是格式化后的內(nèi)容它自然會基于這個版本繼續(xù)改。還有一個坑是 Windows 環(huán)境。npx prettier --write里的路徑如果有特殊字符引號轉(zhuǎn)義容易出問題。建議所有 hook 腳本都用 Node.js 寫避免直接依賴 bash 語法。后面所有示例我都用 Node。3.2 配置二Lint 結(jié)果自動回流給模型從源頭減少“改完又錯”的來回格式化解決的是風格Lint 解決的是“代碼有沒有明顯問題”。我在這個 hook 里跑的是 ESLint并且只針對 Claude 改過的文件不做全量掃描。#!/usr/bin/env node // .claude/hooks/lint-on-write.js const { execSync } require(child_process); let input ; process.stdin.on(data, (chunk) (input chunk)); process.stdin.on(end, () { try { const payload JSON.parse(input); const filePath payload.tool_input?.file_path; if (!filePath || filePath.includes(.test.)) process.exit(0); try { const out execSync( npx eslint ${filePath} --max-warnings0 --format compact, { cwd: payload.cwd, stdio: pipe } ).toString(); // 無錯誤則靜默退出 process.exit(0); } catch (e) { const output e.stdout?.toString() || ; // 只輸出錯誤摘要最多截取 1500 字符避免刷爆上下文 const summary output.split(\n).slice(0, 20).join(\n).slice(0, 1500); console.error([lint] ESLint 檢測到問題請修復后再繼續(xù): \n${summary}); process.exit(0); } } catch (e) { process.exit(0); } });注意這里我讓 exit code 保持 0沒有用 2 阻止寫入。為什么不攔截因為有些 lint 錯誤是結(jié)構(gòu)性的Claude 需要先寫入代碼、看到報錯、再修復這是一個迭代過程。如果你在寫入時就把它攔住模型會陷入“不知道代碼哪里有問題”的困境。更好的做法是把錯誤信息喂給它讓它自己判斷怎么改。--max-warnings0這參數(shù)很有用。它把 warning 也當作 error 處理防止項目里積累一大堆“不痛不癢”的警告。對 Claude 這種大模型來說警告太多會稀釋注意力寧可讓 hook 直接暴露出來。有人會問eslint 的--fix能不能直接放在 PostToolUse 里自動修可以但建議單獨跑。因為--fix可能改出模型意料之外的結(jié)果尤其是一些涉及代碼結(jié)構(gòu)的規(guī)則。我的經(jīng)驗是格式化可以自動lint 修復盡量讓模型自己來否則它下次可能重復犯同樣的錯。4. 中間兩個配置給 Bash 命令套上安全圍欄給寫入內(nèi)容加上敏感信息閘門4.1 配置三危險命令黑名單 項目目錄白名單雙管齊下Bash hook 是整個安全體系里最重要的一環(huán)因為 Claude Code 的大多數(shù)破壞性操作都是通過 Bash 完成的。我的攔截腳本分兩層第一層是黑名單直接命中關(guān)鍵詞就阻止。這里列幾個我實測下來比較實用的規(guī)則const BLOCKED_PATTERNS [ /rm\s-rf\s\//, // 刪除根目錄 /rm\s-rf\s~/, // 刪除用戶目錄 /mkfs\./, // 格式化磁盤 /git\spush\s.*--force/, // 強推 /curl.*\|\s*(ba)?sh/, // curl 管道執(zhí)行腳本 /npm\sinstall\s-g\s.*--unsafe/, /chmod\s-R\s777/, /sudo/, ];第二層是白名單思路這個更重要。對rm、mv、chmod這類具有破壞性的命令我會校驗目標路徑是否在項目目錄內(nèi)。路徑不在項目內(nèi)直接阻止。實現(xiàn)得并不復雜關(guān)鍵在于用 Node 的path.resolve把相對路徑轉(zhuǎn)成絕對路徑再做前綴比較。// .claude/hooks/guard-bash.js const path require(path); let input ; process.stdin.on(data, (chunk) (input chunk)); process.stdin.on(end, () { try { const payload JSON.parse(input); const command payload.tool_input?.command || ; const cwd payload.cwd; for (const pattern of BLOCKED_PATTERNS) { if (pattern.test(command)) { console.error([guard] 命令命中危險規(guī)則: ${pattern}\n已阻止執(zhí)行。如果你確實需要執(zhí)行請手動在終端操作。); process.exit(2); } } // 對 rm/mv 做路徑范圍檢查 if (/^(rm|mv|chmod)\b/.test(command)) { const unsafe command .split(/\s/) .filter((arg) arg.startsWith(/) || arg.startsWith(~) || arg.startsWith(../)) .some((arg) { const abs path.resolve(cwd, arg); return !abs.startsWith(path.resolve(cwd)); }); if (unsafe) { console.error([guard] 檢測到目標路徑超出當前項目目錄已阻止執(zhí)行。); process.exit(2); } } process.exit(0); } catch (e) { process.exit(0); } });這個腳本的思路是“默認信任但有限制”。Claude 在項目里跑npm install、git diff、ls這類命令基本不受影響一旦碰到影響范圍超出項目的操作就會被攔截。exit 2的關(guān)鍵在于Claude 能看到 stderr 里的提示它會自己調(diào)整方案。我見過一個有意思的案例Claude 想把日志寫到/tmp/debug.log被這個 hook 攔了。它看到提示后改為寫到項目下的.logs/debug.log還順手把.logs/加進了.gitignore。這說明給模型一個“為什么不行”的反饋比單純阻止更有效。4.2 配置四敏感信息檢測防止密鑰被寫入代碼或進入對話上下文Claude 在寫代碼時偶爾會“好心”把真實密鑰寫進.env文件旁邊或者在測試代碼里硬編碼一個 API Key。更隱蔽的是它可能在排查問題時直接cat .env把密鑰讀進上下文然后這些內(nèi)容就可能出現(xiàn)在日志里。敏感信息 hook 我配在 PreToolUse分別攔截兩類場景Edit/Write檢查tool_input.content和file_path如果發(fā)現(xiàn)密鑰特征阻止寫入。Bash檢查命令里是否有讀取敏感文件或把敏感信息寫入文件的操作。// .claude/hooks/guard-secrets.js const SENSITIVE_PATTERNS [ /sk-[A-Za-z0-9]{20,}/, // OpenAI / Anthropic 風格 key /AKIA[0-9A-Z]{16}/, // AWS Access Key /ghp_[A-Za-z0-9]{36,}/, // GitHub Token /BEGIN (RSA|EC|OPENSSH) PRIVATE KEY/, // 私鑰塊 ]; const SENSITIVE_FILES [.env, .env.local, .pem, id_rsa, id_ed25519]; let input ; process.stdin.on(data, (chunk) (input chunk)); process.stdin.on(end, () { try { const payload JSON.parse(input); const tool payload.tool_name; const inputData payload.tool_input || {}; if (tool Edit || tool Write) { const content inputData.content || ; const filePath inputData.file_path || ; const fileBasename path.basename(filePath); if (SENSITIVE_FILES.includes(fileBasename) SENSITIVE_PATTERNS.some((p) p.test(content))) { console.error([guard] 檢測到疑似敏感信息被寫入已阻止。請改用環(huán)境變量或 .env.local 維護密鑰。); process.exit(2); } } if (tool Bash) { const command inputData.command || ; if (SENSITIVE_FILES.some((f) command.includes(cat ${f}) || command.includes(cat ./${f}))) { console.error([guard] 阻止讀取敏感文件避免密鑰進入上下文。); process.exit(2); } } process.exit(0); } catch (e) { process.exit(0); } });這個 hook 的難點在于誤報控制。比如.env里本身可以不寫密鑰只放配置項名稱項目文檔里也可能出現(xiàn)類似sk-xxx的示例占位符。解決方案是只攔截“文件路徑本身很敏感且內(nèi)容命中密鑰特征”的情況。普通代碼文件里出現(xiàn)sk-開頭的測試占位符我選擇放行因為那很可能是 mock 數(shù)據(jù)。配好之后我建議你在測試環(huán)境故意觸發(fā)一次確認攔截生效、模型能被正確引導。如果發(fā)現(xiàn)誤報就調(diào)整正則的嚴謹度不要因為“寧可不攔也不誤判”而把規(guī)則關(guān)掉安全這種事兒寧可多攔幾次。5. 最后兩個配置文件變更后自動跑測試、任務(wù)完成時主動提醒5.1 配置五PostToolUse 精準觸發(fā)相關(guān)測試而不是傻等全量執(zhí)行自動測試最簡單的實現(xiàn)是監(jiān)聽PostToolUse的Edit|Write事件文件一變就跑npm test。但全量測試在稍大一點的項目里可能要好幾分鐘Claude 每改一次文件就觸發(fā)一次交互體驗會非常差。我采用的策略是根據(jù)文件路徑縮小范圍// .claude/hooks/test-on-change.js const { execSync } require(child_process); const path require(path); let input ; process.stdin.on(data, (chunk) (input chunk)); process.stdin.on(end, () { try { const payload JSON.parse(input); const filePath payload.tool_input?.file_path || ; const cwd payload.cwd; // 只對 src 下的業(yè)務(wù)代碼觸發(fā) if (!filePath.startsWith(src/)) process.exit(0); if (filePath.includes(.test.) || filePath.includes(.spec.)) { // 改動的是測試文件直接跑這個測試 execSync(npx vitest run ${filePath} --reporterdot, { cwd, stdio: pipe, timeout: 60000, }); console.error([test] ${path.basename(filePath)} 測試通過); } else { // 改動的是業(yè)務(wù)代碼跑相關(guān)測試 execSync(npx vitest run --changed --reporterdot, { cwd, stdio: pipe, timeout: 60000, }); console.error([test] 相關(guān)測試通過); } process.exit(0); } catch (e) { console.error([test] 相關(guān)測試失敗請查看上面的報錯并修復\n${e.stdout?.toString().slice(0, 1000)}); process.exit(0); } });如果你用的測試框架不是 vitest思路完全一致Jest 可以用jest -o只跑發(fā)生變更的文件相關(guān)的測試其他框架可以通過 git diff 計算變更文件再傳給測試命令。這里有兩個細節(jié)值得說。一是timeout我給的是 60 秒因為測試命令本身要預留執(zhí)行時間如果你在 hook 配置里又設(shè)了一個更小的 timeout頂層的會先生效導致命令被提前 kill。所以建議兩處都設(shè)成一致。二是失敗時不要 exit 2。為什么因為測試失敗不代表代碼寫入是錯誤的Claude 需要先完成這次工具調(diào)用、看到測試失敗的反饋然后進行下一輪修復。如果我們把 exit 2 當作“阻止工具執(zhí)行”相當于 Claude 寫了一個代碼但因為測試沒過就不讓它寫這會陷入奇怪的狀態(tài)。測試 hook 的核心價值是“反饋”不是“阻斷”。每次測試失敗Claude 都會在下一輪嘗試修復直到通過。5.2 配置六Stop 和 Notification 事件把等待時間變成可控提醒最后兩個配置解決的是“人機協(xié)作時的通知”問題。用 Claude Code 時它經(jīng)常會停下來等人批準一個 bash 命令或者問一個問題這時候如果你切到別的窗口可能很久都不知道需要你確認。Notification 事件能在這里觸發(fā)一個桌面通知。// .claude/hooks/notify-done.js let input ; process.stdin.on(data, (chunk) (input chunk)); process.stdin.on(end, () { try { const payload JSON.parse(input); const event payload.hook_event_name; const title event Notification ? Claude Code 需要確認 : Claude Code 待辦提醒; // macOS const { execSync } require(child_process); try { execSync(osascript -e display notification 請查看 Claude Code with title ${title}); } catch (e) { // Linux try { execSync(notify-send ${title} 請查看 Claude Code); } catch (_) {} } process.exit(0); } catch (e) { process.exit(0); } });注冊到 Notification 事件即可。至于 Stop 事件我把它用作“任務(wù)收尾檢查”。Claude 每次回復完成后這個 hook 會檢查一下 git 狀態(tài)如果有未格式化的文件直接輸出提醒讓它主動處理。// .claude/hooks/stop-check.js const { execSync } require(child_process); let input ; process.stdin.on(data, (chunk) (input chunk)); process.stdin.on(end, () { try { const payload JSON.parse(input); const cwd payload.cwd; const changed execSync(git status --porcelain, { cwd, stdio: pipe }).toString(); const unformatted changed .split(\n) .filter((line) /\.(ts|js|tsx|jsx|json|css|md)$/.test(line) line.startsWith( M )); if (unformatted.length 0) { console.error( [check] 以下文件有修改但可能未格式化如果確認已完成所有任務(wù)請運行 prettier --write 處理\n${unformatted.slice(0, 5).join(\n)} ); } process.exit(0); } catch (e) { process.exit(0); } });這個 hook 不會阻止任何操作只是提供一個“事后提醒”。它的價值在于解決 Claude 的“總覺得自己干完了”問題——每次回復完它都能看到還有哪些代碼處于臟狀態(tài)從而決定是否繼續(xù)收拾。6. 完整配置匯總與排錯實錄一份可直接抄走的 settings.json6.1 六合一配置示例把上面六個 hook 合并到項目.claude/settings.json里大概長這樣{ hooks: { PostToolUse: [ { matcher: Edit|Write, hooks: [ { type: command, command: node .claude/hooks/format-on-write.js }, { type: command, command: node .claude/hooks/lint-on-write.js }, { type: command, command: node .claude/hooks/test-on-change.js, timeout: 60 } ] } ], PreToolUse: [ { matcher: Bash, hooks: [ { type: command, command: node .claude/hooks/guard-bash.js }, { type: command, command: node .claude/hooks/guard-secrets.js } ] }, { matcher: Edit|Write, hooks: [ { type: command, command: node .claude/hooks/guard-secrets.js } ] } ], Notification: [ { matcher: .*, hooks: [ { type: command, command: node .claude/hooks/notify-done.js } ] } ], Stop: [ { matcher: .*, hooks: [ { type: command, command: node .claude/hooks/stop-check.js } ] } ] } }請把format-on-write.js、lint-on-write.js、guard-bash.js、guard-secrets.js、test-on-change.js、notify-done.js、stop-check.js這幾個腳本放到.claude/hooks/目錄下。文件路徑按你項目實際情況調(diào)整。6.2 排錯實錄我踩過的四個坑第一個坑是 matcher 寫太寬。我一開始把 PreToolUse 的 matcher 寫成.*結(jié)果 Claude 每次調(diào)用任何工具都要跑一遍 guard 腳本雖然腳本本身很快但大量 JSON 解析和正則匹配拖慢了整體交互。后來改成了Bash才清爽。第二個坑是 hook 腳本里忘了讀 stdin。Claude Code 通過 stdin 傳入 JSON如果你的腳本不讀 stdin 直接開始執(zhí)行是拿不到tool_input的。最穩(wěn)妥的寫法就是我上面反復用的那套process.stdin.on(data)累積后在end事件里處理。第三個坑是 exit code 語義混淆。早期我把攔截函數(shù)寫成process.exit(1)結(jié)果工具并沒有被阻止只是 Claude Code 報了個 warning。后來查文檔確認PreToolUse 場景下必須用exit(2)才會真正攔截。所以攔截類邏輯請務(wù)必記住2。第四個坑是 Windows 下路徑和 shell 雙引號問題。在 Windows 上用npx prettier --write ${filePath}如果路徑里帶空格Node 的execSync會解析出錯。我的解決辦法是統(tǒng)一用spawnSync搭配參數(shù)數(shù)組避免 shell 轉(zhuǎn)義或者把路徑中的空格做轉(zhuǎn)義處理。最簡單的方案是讓所有腳本都用 Node 編寫盡量不依賴 shell 特殊語法。6.3 還能怎么擴展這 6 個配置是我的基礎(chǔ)配置你可以按需升級。比如在SessionStart事件里注入一個“當前項目測試命令”的提示讓 Claude 一開始就知道用什么命令跑測試。在UserPromptSubmit事件里檢查 prompt 里是否包含“忽略所有規(guī)則”這類注入嘗試遇到可疑內(nèi)容直接攔截。在PreCompact事件里把當前未完成的任務(wù)摘要保存到文件上下文壓縮后 Claude 還能記得之前做到哪一步。我個人在實際操作中的體會是hooks 配置完成后最明顯的變化不是“代碼變好了”而是“規(guī)則沖突變少了”。格式化、安全、測試這三件事從“需要時刻盯著”變成了“系統(tǒng)自動守門”我只需要在 Claude 被 hook 攔住時看一眼原因然后決定是調(diào)整規(guī)則還是讓它換個方案。這種“定好規(guī)則再放手”的開發(fā)方式才是 Claude Code 這類工具真正讓人放心的用法。最后再分享一個小技巧所有 hook 腳本里那兩行process.stdin.on(data)的讀取邏輯是同一個套路建議你封裝成一個readPayload()公共函數(shù)放到hooks/util.js里每個腳本都 require 它。這樣以后新增 hook 時代碼能少寫一大半也方便統(tǒng)一處理異常。