Hooks：自动化安全检查

Hooks 是 Claude Code 生命周期里的自动化动作。它比提示词和 CLAUDE.md 更硬，所以更需要谨慎。

Hooks 适合什么

Hooks 是自动触发的动作，适合做“必须稳定执行”的安全检查。它比提示词更硬，也更危险：一旦配置错，可能每次工具调用、每次修改后都会触发错误动作。

• 工具调用前提醒或拦截高风险动作。
• 文件修改后自动检查敏感信息。
• 权限请求时输出额外审查信息。
• 团队希望稳定执行的安全检查。
• 提交前固定检查，比如密钥扫描、格式检查、危险命令提醒。

Hooks 不适合什么

• 普通任务提示词。
• 项目说明，应该放 CLAUDE.md。
• 可选流程，优先做 Skill。
• 不理解风险时直接运行脚本。
• 需要人工判断的复杂流程。
• 会修改大量文件的自动动作。

第一次只做审查，不创建 Hook

请检查当前项目是否已经配置 Claude Code Hooks。

要求：
1. 只读检查，不要创建或修改任何 Hook。
2. 说明 Hook 来源、触发事件和执行动作。
3. 判断是否有高风险命令。
4. 如果没有 Hooks，请说明适合先用 CLAUDE.md、Skill 还是 Hook。
5. 不要建议一上来创建会修改文件的 Hook。

Hook 适合放在哪些边界

• 执行命令前：提醒危险命令，例如删除、重置、推送。
• 文件写入后：检查是否写入密钥、token、私钥。
• 提交前：检查测试、构建、格式、敏感信息。
• 权限请求时：输出风险解释和替代方案。

可以按这个表判断：

Hook 越靠近“自动执行”，风险越高。新手优先做提醒，不做修改。

设计 Hook 前先问

请帮我评估是否需要 Hook。

场景：
【描述想自动化的检查】

请回答：
1. 这个需求适合 Hook、Skill、CLAUDE.md 还是普通提示词。
2. Hook 的触发时机应该是什么。
3. Hook 是否只读。
4. Hook 失败时应该阻断还是提醒。
5. 可能误伤哪些正常操作。
6. 第一次如何在安全环境验证。

Hook 失败时要能看懂

一个好的 Hook 失败后应该告诉用户三件事：为什么拦截、影响什么、怎么处理。不要只输出一段报错。

请审查这个 Hook 的失败提示是否清楚。

要求：
1. 用户能不能知道 Hook 为什么触发。
2. 用户能不能知道是否阻断了当前任务。
3. 用户能不能知道下一步该怎么处理。
4. 是否有误报时的处理说明。
5. 不要让失败提示只剩脚本堆栈。

新手第一个 Hook 只做提醒

不要第一个 Hook 就自动改文件。先做只读提醒或检查。

请设计一个只读 Hook 方案。

目标：
【例如：发现疑似密钥时提醒】

要求：
1. 不修改文件。
2. 不删除文件。
3. 不自动提交。
4. 只输出风险提醒。
5. 给出测试方式。
6. 说明误报时怎么处理。

看到这些 Hook 要谨慎

• 自动删除文件。
• 自动格式化整个项目。
• 自动提交或推送。
• 自动读取 .env 或密钥。
• 自动访问生产服务。
• 失败时没有明确提示，导致任务静默中断。

Hook 误报怎么处理

Hook 太严格会打断正常工作。遇到误报，不要直接删除 Hook，先调整规则：

这个 Hook 似乎误报了，请先只读分析。

请判断：
1. 它为什么触发。
2. 当前操作是否真的危险。
3. 是规则太宽，还是当前操作需要特殊说明。
4. 如何收窄规则，减少误报。
5. 是否需要保留人工确认。

Hooks 和 Skills 的选择

• 需要用户主动调用：优先 Skill。
• 需要长期项目规则：优先 CLAUDE.md。
• 需要每次固定触发：才考虑 Hook。

验证 Hook

请验证 Hook 是否安全。

要求：
1. 用低风险测试文件验证。
2. 说明触发条件是否正确。
3. 说明是否误伤正常操作。
4. 说明失败时用户能不能看懂原因。
5. 不要在真实敏感文件上测试。

Hook 上线前清单

验收结果

• 你知道 Hooks 是自动化安全层。
• 你知道新手先审查，不先创建。
• 你知道 Hooks 适合必须自动执行的检查。
• 你知道第一个 Hook 应该只读、可解释、可回退。