用Claude Code钩子落实自动化规则

Claude Code 的项目约定，能不能从「提醒模型执行」变成「由运行框架触发」？dev.to 的文章给出的机制是：Hooks 在特定生命周期节点自动运行，通过 JSON 配置，并用退出码和 JSON 输出参与流程控制。作者称提供五个配置示例，目前拿到的节选已覆盖核心机制，但尚未展示这些示例，不能据此判断它们是否可以直接用于项目。

目前能确认什么

Hooks 是用户定义的处理器，由 Claude Code 在特定生命周期节点自动运行，例如工具调用前后、会话开始或回复结束。作者把它与 CLAUDE.md 中的指令作比较：后者依赖模型遵循，前者把执行动作交给运行框架。

配置采用 JSON，按「事件、匹配组、处理器」组织。作者将个人通知放在 ~/.claude/settings.json，将团队格式化规则放在纳入版本控制的 .claude/settings.json。不同层级的配置会合并，已有配置应在同一个 hooks 对象中追加，避免覆盖旧规则。

命令型 Hook 通过退出码和输出反馈结果。退出码 0 表示成功，2 可在支持阻断的事件上停止流程；其他非零码属于非阻断错误。JSON 输出还可参与流程控制，但节选没有完整展示其字段。

Hook 被触发，不等于操作一定能被拦截。

例如，PostToolUse 发生在工具执行之后，无法撤销已完成的操作。Stop 则表示 Claude 结束一次回复，不代表任务真正完成。

我的判断

对程序员最实用的变化，是把格式化等重复动作接入明确的执行节点，减少模型遗漏项目约定的机会。团队共享配置也能让这些规则随仓库一起维护。

但规则放在哪个节点，比「有没有 Hook」更关键。需要阻止某次工具操作，应关注执行前的检查；执行后的检查只能处理已经产生的结果。

还要区分自动触发与确定性判断：节选列出的处理器也包含调用模型的 prompt 和 agent，不能把所有 Hook 都理解成固定脚本。五个示例的实现、完整 JSON 控制字段及失败处理方式，仍需原文后半部分或官方文档确认。