CCClaude Code中文喂饭教程

低风险 Hooks 实战：先做提醒，不做自动修改

第一个 Hook 不应该自动改文件、删除文件或提交代码。更稳的做法是先做只读提醒，例如在高风险命令、疑似密钥、生产配置修改前提醒用户。

Hooks 很有用，也很容易用过头。新手第一个 Hook 不应该自动修改文件，而应该只做提醒，让用户先看懂 Hooks 的触发时机、输出方式和误报情况。

下面用“高风险操作提醒”做例子。

目标：

当 CC 准备执行可能高风险的操作时，提醒用户先确认风险。

第一个 Hook 的目标不是自动化越多越好，而是先建立“能触发、能解释、能回退”的基本信任。

目标合格标准
能触发高风险动作前有提醒
能解释提醒说清楚为什么危险
不误伤普通读文件和小改动不被拦
可回退出问题能关闭或撤回

第 1 步：先判断是否真的需要 Hook

很多提醒不需要 Hook，用 CLAUDE.md 或 Skill 就够了。

请帮我判断这个需求是否适合 Hook。

需求：
当 Claude Code 准备删除文件、重置 Git、读取密钥或访问生产环境时，提醒我先确认。

请回答：
1. 这个需求适合 Hook、Skill、CLAUDE.md 还是普通提示词？
2. 如果用 Hook，应该只提醒还是阻断？
3. 可能误伤哪些正常操作？
4. 第一次验证应该怎么做才低风险？
5. 不要创建文件，只做方案评估。

如果只是“提交前帮我检查一遍”，优先 Skill；如果是“每次危险动作前都必须提醒”，才考虑 Hook。

第 2 步：设计只读 Hook

第一个 Hook 的原则：

请设计一个只读 Hook 方案。

目标：
发现高风险动作时输出提醒。

高风险动作包括：
1. 删除文件或目录。
2. Git reset、clean、push、force push。
3. 读取 .env、私钥、Token 文件。
4. 访问生产数据库或生产接口。
5. 批量移动或覆盖文件。

要求：
1. 只输出提醒，不自动执行修复。
2. 说明触发时机。
3. 说明误报场景。
4. 说明如何临时关闭或回滚。
5. 不要创建文件，先输出设计。

第 3 步：创建前先审查

Hook 方案出来后，不要马上写入配置。先审查。

请审查这个 Hook 方案。

重点检查：
1. 是否会误伤正常读取文件。
2. 是否会阻断普通开发流程。
3. 是否包含危险命令。
4. 是否会读取敏感文件内容。
5. 失败时用户能不能看懂提示。
6. 是否有回滚方式。

只做审查，不要创建 Hook。

第 4 步：低风险验证

验证 Hook 不要拿真实敏感文件测。用模拟文件、模拟命令、练习项目。

请设计 Hook 验证步骤。

要求：
1. 使用低风险测试文件。
2. 不读取真实 .env。
3. 不执行真实删除。
4. 不执行 Git reset 或 push。
5. 验证提醒是否出现。
6. 验证普通操作不会被误伤。

如果提醒太频繁，先调低敏感度；如果提醒看不懂，先改提示文案。

验证结果怎么判断

结果判断
危险动作触发提醒合格
普通操作也频繁提醒规则过宽
提醒看不懂文案需要重写
Hook 失败但没有说明不适合上线
无法停用风险过高

第 5 步：触发后怎么处理

Hook 触发后，不要直接批准或绕过。让 CC 解释。

刚才 Hook 触发了提醒。

请解释：
1. 触发原因是什么。
2. 你准备执行的动作是什么。
3. 是否真的属于高风险。
4. 有没有更低风险替代方案。
5. 如果我拒绝，会卡在哪里。

不要继续执行，等我确认。

适合新手的低风险 Hook 类型

Hook 类型作用风险
危险命令提醒删除、重置、推送前提醒可能误报，需要清楚文案
疑似密钥提醒写入 token/key/password 字样时提醒不能读取真实密钥内容
生产配置提醒修改 deploy/prod/env 文件前提醒需要项目目录规则清楚
大范围修改提醒修改文件数量过多时提醒需要避免打断正常批量文档任务

不适合第一个 Hook 的事情

什么时候应该升级 Hook

只有满足这些条件，才考虑从“提醒”升级到“阻断”：

  1. 团队已经确认规则。
  2. 误报率很低。
  3. 提示文案清楚。
  4. 有明确回滚方式。
  5. 不会阻断正常开发。
  6. 规则已经在多个任务里验证过。

Hook 收尾总结

请总结这个低风险 Hook 验证结果。

请说明：
1. 触发条件是否准确。
2. 是否有误报。
3. 提示文案是否清楚。
4. 是否保持只读。
5. 是否建议继续使用、调整或撤回。

验收结果

下一篇：MCP