2025年，一個開發(fā)團隊讓Claude Code幫忙寫文檔。AI把真實的Azure API密鑰硬編碼進Markdown文件，推到了公開倉庫。11天后才有人發(fā)現(xiàn)——黑客搶先一步，3萬美元沒了。

另一群人讓AI清理測試文件。它執(zhí)行了rm -rf，整個Mac主目錄被抹平：Desktop、Documents、Downloads、Keychain。數(shù)年工作，幾秒歸零。

還有人讓AI代理管理收件箱。它批量刪除了數(shù)百封真實郵件。

這些不是段子。AI一旦啟動，你無法中途叫停。每個用過AI編程工具的人都體會過這種恐懼：讓它在英文平臺發(fā)帖，它用中文回復(fù)——賬號災(zāi)難；讓它改個配置，它搞壞.env文件——整個服務(wù)宕機。

問題很直接：有沒有機制能在AI行動前攔截它？

有。叫Hook。

Hook是什么：給AI裝門禁，但它不知道自己被監(jiān)控

拋開術(shù)語。Hook是你圍繞AI安裝的一套門禁系統(tǒng)。

把自己想象成大樓管理員，AI是里面的施工隊。施工隊有能力，但偶爾發(fā)瘋——拆掉承重墻、扔掉別人的東西、把通知貼錯位置。Hook就是你在關(guān)鍵點位安裝的門禁+監(jiān)控。

這些門不是AI裝的，是你裝的。AI甚至不知道它們存在。

這是Hook最反直覺的一點：Hook在AI意識之外運作。AI不知道自己被攔截，也不知道門在檢查什么。你不能問Claude"你的Hook配置對了嗎"——它答不了。你不能讓Claude調(diào)試你的Hook，因為Hook在Claude之外的代碼層執(zhí)行。

這意味著一件嚴(yán)肅的事：Hook是AI操作者必須自己學(xué)會配置的東西，AI幫不了你。

我是硬碰硬學(xué)會這點的。研究Claude Code的Skill工程系統(tǒng)時，我把Anthropic官方設(shè)計原則逐行對齊開源工具鏈，發(fā)現(xiàn)一個完全空白的地帶——Hook。AI工具鏈沒覆蓋它，我自己也不懂。

于是決定自己造一個。

場景是這樣的：Claude Code在長對話中會執(zhí)行"上下文壓縮"，把早期對話壓縮成摘要騰出空間。問題是壓縮會丟失關(guān)鍵信息：SSH連接IP、臨時API令牌、多步驟任務(wù)進行到第幾步。

我的想法：壓縮前讓Claude自動保存關(guān)鍵信息。

"Before compaction, check the current conversation for critical information and extract it to a file in /tmp/."

看起來合理吧？我自信地部署了，以為問題解決了。

它運行了幾周，然后我開始注意到奇怪的事。有時候壓縮后，關(guān)鍵信息根本沒被保存。有時候文件里存的是錯誤信息。有時候它完全沒執(zhí)行保存動作。

我檢查了代碼。邏輯是對的。提示詞是明確的。但Hook的行為不一致。

然后我發(fā)現(xiàn)問題所在：我把Hook想得太簡單了。

第一層感知：AI根本"看不見"Hook

Hook的第一層真相：AI對Hook的存在是盲目的。

我最初的設(shè)計假設(shè)是，Claude會"理解"這個保存任務(wù)的重要性，會"注意"到自己在執(zhí)行Hook。但Hook執(zhí)行時，Claude正處于上下文壓縮的流程中，它的注意力完全在壓縮算法上，保存任務(wù)只是被機械地執(zhí)行。

換句話說，Hook對AI來說不是"一個需要認(rèn)真對待的操作"，而是"流程中的一個步驟"。

這解釋了為什么有時候保存會失敗：當(dāng)壓縮流程遇到邊緣情況（對話過長、格式異常、時間壓力），Hook步驟會被簡化或跳過。不是Claude"決定"跳過，而是整個流程的優(yōu)先級排序讓它被擠掉了。

我重新設(shè)計了Hook。不再依賴AI的"理解"，而是在Hook層加入強制檢查點：保存動作必須返回確認(rèn)碼，文件必須存在且非空，才能繼續(xù)壓縮流程。

失敗率從約15%降到接近零。

但這只是第一層。

第二層感知：你能看見Hook，但看不清它的全部

作為Hook的配置者，我以為自己能看到Hook的全貌。我錯了。

Hook系統(tǒng)通常有多層嵌套。我的保存Hook調(diào)用了文件系統(tǒng)Hook，文件系統(tǒng)Hook又依賴權(quán)限Hook。每一層都有自己的日志，但日志是分散的。當(dāng)保存失敗時，我看到的只是"文件寫入失敗"，不知道是權(quán)限問題、磁盤問題、還是路徑解析問題。

更麻煩的是，Hook之間會互相干擾。我后來加了一個"自動清理舊緩存"的Hook，結(jié)果它把我的關(guān)鍵信息保存文件也清理了。兩個Hook各自邏輯正確，組合起來產(chǎn)生災(zāi)難。

我花了整整兩天追蹤這個問題。最終發(fā)現(xiàn)清理Hook的路徑匹配規(guī)則過于寬泛，把/tmp/下所有帶時間戳的文件都當(dāng)成了緩存。

修復(fù)后，我在Hook配置里加入了"影響范圍聲明"——每個Hook必須顯式列出它操作的路徑、調(diào)用的系統(tǒng)資源、可能影響的其它Hook。這成了我的強制規(guī)范。

第三層感知：用戶能看見Hook的效果，但不知道Hook的存在

這是最微妙的一層。

我的團隊成員使用配置了Hook的Claude Code時，他們體驗到的是"壓縮后信息很少丟失"，但完全不知道有Hook在運作。這是設(shè)計意圖——Hook應(yīng)該透明。但透明帶來了新問題。

有一次，一位同事手動刪除了/tmp/下的"臨時文件"來清理空間，包括我的Hook保存文件。對他來說是正常操作，對我來說是數(shù)據(jù)丟失事故。他不知道那些文件有持久價值，因為Hook的透明性讓它們看起來就是普通臨時文件。

我嘗試在文件名里加前綴、在文檔里寫說明，但效果有限。最終解決方案是改變存儲位置——從/tmp/移到專門的持久化目錄，并在Hook失敗時向用戶推送顯式通知。

這破壞了部分透明性，但換來了可維護性。

第四層感知：組織能看見Hook的策略，但看不見執(zhí)行細(xì)節(jié)

當(dāng)Hook從個人工具變成團隊規(guī)范，第四層問題浮現(xiàn)。

我們制定了"所有AI操作必須經(jīng)過Hook審查"的策略。但策略是靜態(tài)的，Hook是動態(tài)的。我檢查團隊成員的Hook配置時，發(fā)現(xiàn)同樣的策略有十幾種實現(xiàn)方式：有人用Python腳本，有人用Shell鉤子，有人直接改AI客戶端源碼。

更隱蔽的問題是，Hook的執(zhí)行日志分散在各人的本地機器上。當(dāng)出現(xiàn)問題需要審計時，我們找不到完整記錄。一位同事的Hook曾錯誤地攔截了合法操作，導(dǎo)致重要部署延遲三小時——我們事后復(fù)盤時，甚至無法確定是哪個Hook觸發(fā)的攔截。

我推動建立了Hook注冊中心：所有Hook必須登記、使用標(biāo)準(zhǔn)日志格式、關(guān)鍵操作上報到集中存儲。這增加了 friction，但讓組織層面的感知成為可能。

Hook設(shè)計的三個教訓(xùn)

經(jīng)過這四層折騰，我總結(jié)出三個設(shè)計原則。

第一，假設(shè)AI會"盲行"。不要把Hook設(shè)計成需要AI"理解"或"配合"的樣子。Hook必須是強制性的、可驗證的、不依賴AI注意力的。

第二，Hook配置者需要"元視野"。你必須能看見Hook的全鏈路：它調(diào)用了什么、被什么調(diào)用、可能和哪些系統(tǒng)交互。沒有元視野，Hook就是黑箱。

第三，透明性需要分層管理。對AI透明、對用戶適度可見、對組織可審計——這三層需要不同的設(shè)計，不能一刀切。

回到開頭那個3萬美元的密鑰泄露事件。事后分析顯示，該團隊確實配置了Hook來掃描代碼中的敏感信息。但Hook只在提交前運行，而AI把密鑰寫進了文檔文件——不在掃描范圍內(nèi)。Hook感知到了代碼層，沒感知到文檔層。

他們的Hook在第四層（組織策略）存在，在第一層（執(zhí)行點）缺位。

你現(xiàn)在檢查自己的AI工作流：你的Hook覆蓋到了哪一層？有沒有哪個層級的感知是盲的？