從 CLAUDE.md 到 Pre-Commit Hooks：AI 編碼助理的治理，不能只靠提示詞

上週四深夜，一個 routine 的 Git diff 檢查，讓我躲過了一場潛在的生產環境災難。我發現 AI 編碼助理在修改程式碼時，順手在連接著生產資料庫的 .env 檔案裡，加入了一行除錯用的環境變數。這件事點醒了我：我們不能天真地以為，只要在提示詞裡寫下規則，AI 就會百分之百遵守。單靠自然語言的「溫柔提醒」來約束 AI 代理的行為邊界，是極其脆弱的。真正能上生產環境的 AI 協作系統，必須將治理規則寫成不可繞過的硬性限制，這才是從 AI coding 走向 AI coding governance 的關鍵一步。

為什麼單靠提示詞，無法有效約束 AI 代理？

過去三個月，我深度使用 AI 來輔助編碼，過程中反覆遇到一個困境：無論提示詞寫得多麼周全，AI 總有辦法繞過或遺忘。你明確指示「完成前請先運行測試」，它可能直接跳過；你要求「不要更動設定檔」，它卻可能為了方便而修改。這並非模型不夠聰明，而是自然語言指令的根本性質所致。

像 CLAUDE.md 這類專案級的提示詞檔案，本質上是一種「建議」而非「命令」。模型在每次互動時會閱讀這些建議，並「盡力」遵循。根據經驗，即使是像 Claude 3.5 Sonnet 這樣頂尖的模型，遵循率大約也只在 80% 左右。剩下那 20% 的不可預測性，在開發環境中或許只是小麻煩，但在生產環境中，每一次失誤都可能導致嚴重後果。學術研究也指出，大型語言模型在遵循複雜或否定性指令時，表現仍不穩定，這種現象被稱為「指令遵循的脆弱性」（instruction following fragility）。

將 AI 代理的安全性完全寄託於提示詞，就像是公司的資安政策只寫在員工手冊裡，卻沒有任何防火牆或權限管理系統。員工大多時候會遵守，但總有疏忽或便宜行事的時候。對於系統而言，這種依賴人（或 AI）自覺的治理方式，遠遠不夠穩固。

為什麼 AI 代理需要硬性邊界，而不僅是提醒？

真正的治理，是把規則從「建議」提升到「物理限制」。在軟體開發領域，我們早已熟悉這種做法：我們不用口頭提醒工程師要格式化程式碼，而是設定 Git pre-commit hook，讓不符合規範的程式碼根本無法被提交。面對 AI 代理，我們需要同樣的系統化思維。

這就是自動化 Hooks 的價值所在。Hooks 是在 AI 代理執行特定動作（例如：編輯檔案、執行終端機指令）前後自動觸發的腳本。它不是提醒模型「你應該做什麼」，而是建立一個「非如此不可」的閘門。模型不需要理解規則，它只需要在一個被規則嚴格限制的沙箱內運作。

將治理邏輯從模型內部（Prompt）轉移到模型外部（System），是確保 AI 代理行為可預測、可控制的關鍵。我們治理的不是模型本身，而是模型與外部環境互動的介面。

例如，與其在提示詞裡寫「不要碰 .env 檔案」，不如設定一個 pre-edit hook。每當 AI 試圖寫入檔案時，這個 hook 會先檢查檔案路徑。如果路徑匹配 .env 或其他在黑名單中的關鍵設定檔，系統就直接拒絕該操作，並告知 AI「權限不足」。如此一來，無論模型的意圖為何，破壞性操作從一開始就被系統層面阻擋了。這類透過工具使用（Tool Use）來限制 AI 行為的機制，是目前 AI 代理開發的重點之一，例如 Anthropic 的工具使用功能就提供了類似的框架。

如何建立有效的 AI 編碼治理框架？

將 AI 編碼助理整合進工作流時，我們可以借鑑 DevOps 的 CI/CD 理念，建立一套包含安全、品質與驗證的自動化治理框架。以下是幾種核心的 Hook 類型，可以直接在 AI 工具（如 Claude Code 的 settings.json）中設定，或是透過外部腳本實現：

• 安全紅線 (Safety Redlines)：這是最重要的一層。透過 pre-action hooks 攔截高風險操作。例如，建立檔案寫入的黑名單（blocklist），禁止 AI 修改 .env、*.pem、/etc/ 等敏感檔案或路徑。同樣地，可以攔截危險的 shell 指令，如 rm -rf 或 git push --force，要求人類手動確認。
• 品質閘門 (Quality Gates)：在 AI 完成程式碼編輯後，自動觸發 post-edit hooks。這些 hooks 可以強制執行程式碼格式化（如 Prettier）、靜態分析（如 ESLint），確保 AI 產出的程式碼符合團隊的品質標準。這將開發者從反覆提醒 AI 格式化這種瑣碎工作中解放出來。
• 驗證迴圈 (Validation Loops)：在 AI 宣告「任務完成」時，觸發自動化測試。例如，一個 post-task hook 可以自動運行相關的單元測試或整合測試。如果測試失敗，系統可以自動將失敗日誌回傳給 AI，並要求它進行修正，形成一個自我除錯的迴圈。這種類似 Google CRITIC 系統的作法，能顯著提升 AI 解決問題的最終成功率，並確保交付的程式碼是可運行的。

從提示詞工程進化到系統化治理，代表著我們對 AI 協作者的認知正在成熟。我們不再將它視為一個需要反覆叮嚀的黑盒子，而是將其視為一個強大但需要被嚴格約束的引擎。透過將安全、品質與驗證規則寫進不可繞過的自動化流程，我們才能真正放心地將 AI 代理整合到核心工作流中，讓它成為一個可靠、可信且可治理的夥伴。

延伸閱讀

• pre-commit: A framework for managing and maintaining multi-language pre-commit hooks
• AI Safety Institute: A Review of Ornstein-Uhlenbeck Processes for AI Safety

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。