很多人用 Claude Code 写代码时，最先感受到的是“它能改很多文件”。但真正把它放进日常项目后，问题很快会变成另一个：怎么让 AI 每次改完代码都自动格式化、跑测试、拦住危险命令，而不是靠人反复提醒？这就是 Claude Code Hooks 最适合解决的场景。
如果你已经看过老达之前写的 Claude Code 新手工作流，这篇可以看作进阶篇：不再只讲安装和权限，而是把 AI 编程流程里最容易漏掉的检查，沉到工具层自动执行。
Claude Code Hooks 到底是什么
按官方文档的说法，Hooks 是在 Claude Code 生命周期中特定时机自动执行的用户自定义命令、HTTP 端点或提示。更直白一点说，它就是给 Claude Code 加“自动闸门”和“自动收尾”的机制。
官方 Hooks reference 里列出了很多事件，常见的包括 PreToolUse、PostToolUse、PostToolBatch、Notification、Stop、SessionStart 等。第一次上手不需要全记住，先抓住三个就够了：
PreToolUse：工具执行前触发，适合拦截危险命令，比如rm -rf、直接改生产配置。PostToolUse：工具执行成功后触发，适合在 Claude 写入或编辑文件后跑格式化、lint、类型检查。Stop：Claude 本轮回复结束时触发，适合做最终检查、生成变更摘要或提醒你 review。
这和 AI编程工具专题 里常说的“让 AI 变成协作者”有关。真正稳定的 AI 编程，不是每次提示词写得更长，而是把重复规则固化进项目。
为什么 Hooks 比“多写一句提示词”更可靠
提示词的问题是容易被上下文冲掉。你可以在开头写“每次改完都运行测试”，但一次长任务里，Claude 可能会先读文件、再改文件、再修 bug、再整理说明，中间任何一步都可能忘记跑检查。
Hooks 的价值在于它不是建议，而是流程。只要配置正确，Claude Code 每次走到对应事件，都会把 JSON 上下文传给你的脚本。脚本可以允许、拒绝、提示，也可以把额外上下文返回给 Claude。
这也是我建议站长、独立开发者和内容工具开发者优先学 Hooks 的原因：项目越小，越经不起一次误删文件、一次未格式化提交、一次没有测试的线上改动。
一个最小可用的 Hooks 配置思路
不要一开始就把所有事件都配满。更实用的顺序是：先拦危险命令，再自动格式化，最后补测试和通知。
第一步：用 PreToolUse 拦住高风险 Bash 命令
最值得优先处理的是 Bash 命令。AI 编程工具能读写文件，也可能执行 shell。平时你不会手滑执行的命令，AI 在长任务里也应该被二次检查。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/block-dangerous-command.sh"
}
]
}
]
}
}
脚本里可以检查输入的命令文本，遇到 rm -rf、git reset --hard、直接操作 .env、生产服务器命令，就返回拒绝原因。这样做不是为了限制 AI，而是把人本来就会做的安全判断，提前写成规则。
第二步：用 PostToolUse 接格式化和 lint
Claude Code 改完文件后，最常见的问题不是大错，而是风格不一致、少了 import、类型没过。把这些交给 PostToolUse，比每次人工提醒更稳定。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/format-and-lint.sh"
}
]
}
]
}
}
脚本里可以按项目类型判断：前端项目跑 npm run lint、npm run format；Python 项目跑 ruff check；WordPress 主题项目可以检查 PHP 语法、CSS 构建和关键模板文件。
如果你做的是个人网站或自动发文系统，可以把这个思路和 AI 自动发布 WordPress 文章流程 结合起来：文章发布前检查正文 h1、摘要、内链、特色图 alt，代码修改后检查主题文件语法。
第三步：用 Stop 做最后一轮结果汇总
Stop 适合做任务结束前的收口动作。比如生成一份本轮改动清单、提醒哪些测试没跑、把日志写入本地文件，或者给团队聊天工具发通知。
这一步不要做太重。测试和格式化更适合放在文件改动后，Stop 更适合做“给人看的结论”。否则每轮对话结束都跑一大堆命令，反而拖慢工作。
适合个人项目的 5 个 Hooks 场景
如果你不知道从哪里开始，可以直接从下面 5 个场景挑一个：
- 阻止危险命令：拦截
rm -rf、git reset --hard、直接覆盖配置文件。 - 自动格式化：Claude 改完文件后运行 formatter，减少 review 时的噪音。
- 自动跑轻量测试：只跑受影响模块或快速单元测试，不要一上来就跑完整 CI。
- 检查敏感文件：当 AI 尝试读取或写入
.env、密钥文件、服务器配置时给出明确提示。 - 任务完成提醒：Claude 停止输出时，把变更摘要、测试结果和待人工确认项汇总出来。
如果你正在比较不同 AI 编程 Agent，可以顺手看 Claude Code vs Gemini CLI 和 2026年AI编程工具推荐。工具之间的差异不只在模型能力，也在能不能把工程流程接稳。
配置 Hooks 前要注意的坑
第一，Hooks 脚本本身就是代码，也要进版本管理或至少有备份。不要把一堆临时 shell 命令散落在电脑上，几周后没人知道它们为什么存在。
第二，项目级配置和个人本地配置要分清。适合团队共享的规则可以放项目配置，涉及个人路径、个人通知、私有 token 的内容应该留在本地配置，避免把密钥写进仓库。
第三，Hook 不能代替 review。它能拦一部分明确风险，但不能判断产品方向、业务逻辑和用户体验。尤其是涉及数据库迁移、权限系统、支付流程，仍然要人工看 diff。
第四，自动测试要分层。轻量检查可以频繁跑，完整测试放到任务结束或 CI。否则 Claude 每改一个小文件都跑几分钟测试，整个 AI 编程流程会被拖慢。
老达点评
Claude Code Hooks 的意义不是“更炫的自动化”，而是把 AI 编程从一次性对话变成可复用流程。普通用户会把提示词越写越长，真正做项目的人应该把稳定规则写进 Hooks、脚本和项目文档。
我建议的入门路线很简单：先配置一个危险命令拦截，再配置一个文件修改后的格式化检查。等这两件事稳定后，再考虑测试、通知、MCP 工具审计和团队级策略。这样做比一次性追求完整自动化更容易落地。
后续如果你想把 Claude Code 放到更大的自动化体系里，可以继续看 AI智能体与自动化专题，里面会持续整理 MCP、n8n、Dify、Codex 和 Claude Code 的真实工作流。
参考资料：Claude Code Hooks 官方文档。
