很多人想深入接触 Claude Code，都会有一种很真实的崩溃感：
- 能约束
- 也能约束
- 也在影响行为
- 看起来也像规则触发器
那到底什么时候该用哪个？
你可以直接这么记：
- CLAUDE.md：公司总制度
- rules：部门补充规定
- skill：这类工作的 SOP 手册
- hook：门禁 / 安检 / 自动检查脚本
- compact：开会开久了，整理一下桌面和纪要
如果只记这一层意思，已经够用了。
再翻译成人话一点：
- CLAUDE.md：全局长期生效的原则
- rules：局部场景生效的规则
- skill：告诉 AI“这类任务一般怎么做”
- hook：别靠 AI 记，系统到点自动执行
- compact：长对话太乱了，压缩一下上下文
很多人第一次上手就喜欢往 里塞一堆东西，最后写成项目百科全书。
其实它最适合放的是：
- 这个项目默认用什么命令
- 哪些目录不要碰
- 完成任务前要做什么检查
- 哪些原则每次都成立
比如：
- 用 ，不用
- 改完代码先跑 lint 和 test
- 不要修改 generated files
- 涉及支付逻辑先看接口约定
这些都很适合放 。
“我们合作时，有一些长期不变的底线和习惯。”
所以你可以把 理解成：
你和 Claude 之间的长期合作协议
不是团队 wiki，也不是项目知识库，更不是大杂烩。
最重要的原则就一句话：
写长期成立、全局适用、足够稳定的东西。
别写太细，别写得像百科全书，也别把某个目录的局部规则全塞进来。
一个比较顺手的写法
CLAUDE.md 适合写什么？
很适合写：
- 默认命令
- 全局完成标准
- 高风险禁区
- 默认工作方式
- 整个仓库通用的 coding preference
不太适合写什么？
不太适合写：
- 某个目录专属规则
- 某种语言才生效的限制
- 一整套复杂的排障流程
- 很长的业务背景介绍
这些更适合给 、 或其他文档。
什么时候用 CLAUDE.md？
当你心里想的是：
- “这个原则几乎每次都成立”
- “每次开新会话都该知道”
- “这是长期契约，不是局部技巧”
那就放 。
它适合处理这种情况：
- 只有某个目录才有这条规则
- 只有某种语言才有这套规范
- 只有某类文件才需要特殊处理
举个例子。
你项目里可能有这些情况：
- 下的组件必须用函数组件
- 统一用 pytest
- 文件里不允许
- 某个安全目录不允许随便改
这时候 的价值就出来了：
只在相关场景加载，只约束相关范围。
所以它和 的关系不是谁替代谁，而是：
- 管全局
- 管局部
rules 最适合的写法就是：
一条规则只负责一个局部场景。
比如按目录拆，按语言拆，按文件类型拆，都可以。
例子 1：前端组件目录规则
例子 2：SQL 文件规则
例子 3：Python 目录规则
rules 写的时候一个很实用的原则
不要把 rules 写成“再来一份小号 CLAUDE.md”。
- 到了这个目录
- 碰到这类文件
- 就按这里的规则来
一个特别实用的判断方法
如果你脑子里冒出来的是：
“这条规则不是每次都成立，但到了这个目录/文件类型就必须成立”
那它大概率该放 。
这是最容易被误解的地方。
更贴切一点，skill 是某类任务的操作手册。
比如你让 Claude 去做“线上问题排查”，真正需要的往往不是一句 prompt，而是一套步骤：
- 先看日志
- 再看最近发布
- 再确认影响范围
- 再提出假设
- 再做验证
- 最后给 root cause 和修复建议
所以 skill 最适合装这种东西：
- debug 流程
- code review checklist
- 发布 SOP
- 迁移步骤
- 某类业务改动的固定做法
我觉得最形象的比喻是：
字典目录 + 对应章节
- 平时脑子里放一个“目录索引”
- 真遇到这类题，再翻完整章节
这也是为什么 skill 常被说成是“按需加载的工作流”。
Skill 最重要的不是写得多像 prompt，而是把 3 件事写清楚：
- 什么时候用
- 按什么步骤做
- 最后输出什么
一个顺手的 skill 写法
再来一个发版类的 skill
skill 写的时候有几个很实用的建议
什么时候用 skill？
当你想表达的是：
“这类任务有一套固定做法，不能只靠 AI 临场发挥”
那就该用 skill。
如果你觉得 hooks 抽象，那我建议你直接记一个类比：
hook 很像 husky / git hooks。
是不是一下就顺了？
Husky 干嘛的？
- 你 commit 之前，自动跑 lint
- 你 push 之前，自动跑 test
- 不通过就拦住
重点是：
它不是提醒你记得做，而是系统自动帮你做。
比如：
- Claude 一启动会话，自动注入一些上下文
- Claude 改完文件后，自动跑检查
- Claude 尝试改敏感目录时，直接拦住
- Claude 任务结束后，自动发通知
某个时刻一到，系统自动执行一段逻辑
这就和 、、 完全不是一个层级了。
最简单的理解方式就是：
写触发时机 + 匹配条件 + 执行动作。
也就是：
- 在什么事件点触发
- 对什么动作 / 文件生效
- 然后执行什么命令
例子 1：改完 Rust 文件自动检查
这段话翻译成人话就是：
- Claude 刚用了 Edit
- 改的是 文件
- 那就自动跑一次
例子 2：改 ts/tsx 后自动 lint
例子 3：会话开始时注入上下文
这类写法很适合收集当前分支、运行环境、工具版本。
hook 非常适合这类事：
- 改完代码自动 lint / test
- 高风险目录禁止修改
- 会话开始自动收集现场信息
- 任务结束自动提醒
一句话：
凡是“不该靠 AI 自觉记住”的事，都很适合 hook。
hook 写的时候有个特别重要的原则
尽量让它：
- 短
- 快
- 可预测
- 结果清晰
也经常被误解。
它真正的价值是：
长对话里，帮你压缩上下文噪声。
这个问题在 Claude Code 里特别真实。
对话一长，里面会塞满很多东西：
- 已经过时的尝试
- 失败的中间方案
- 很长的日志
- 已经被推翻的结论
- 重复的信息
做的事，就像：
- 不是把整个房间搬空
- 而是把桌上真正有用的东西收拾出来
- 把没用的纸团、草稿、废弃结论扔掉
所以它适合：
- 任务还在继续
- 但上下文已经开始变脏
- 想保留进度，又不想继续带着一堆噪声往前跑
你可以把它理解成：
- 不换任务
- 不完全清空上下文
- 只是把当前会话压缩成“对后续还有价值的版本”
一个很实用的使用场景
- 保留最终确认过的结论
- 保留当前剩余问题
- 保留下一步计划
- 丢掉大部分已经没用的中间过程
一个很实用的区分
- 任务换了：适合 clear
- 任务没换，但对话太乱了：适合 compact
假设你让 Claude 帮你改一个支付页面。
你有下面这些要求：
- 不要改
- 前端统一用 hooks 写法
- 改支付逻辑前要先看接口约定
- 改完必须跑测试
- 发版前要检查埋点和截图
比如：
- 默认用
- 改完代码要跑测试
- 涉及支付相关先看接口契约
这是长期都成立的项目合作习惯。
比如：
- 下面统一函数组件
- 禁止
这是局部场景约束。
比如：
- 支付流程改动的一整套 SOP
- 先看 API，再确认埋点，再改 UI，再补测试，再截图验证
这是“这类任务怎么做”。
一个支付改动 skill 的简化版写法
比如：
- Claude 一旦想改 就直接拦住
- 改完 自动跑 eslint
这是“别靠它记，系统自动检查”。
以后你只要问自己四句话：
这是不是全局长期成立的？
是 →
这是不是只有局部场景才成立？
是 →
这是不是某类任务的一套标准做法？
是 claude code 教程 →
这是不是必须自动执行 / 必须阻断，不能靠 AI 自觉？
是 →
如果任务还没变，但上下文已经乱成一锅粥了：
→
很多人还会好奇：
你可以粗暴但准确地理解成：
是，但不是一开始全塞进去。
skill 更像“先给目录，再按需翻正文”。
也就是说：
- 模型先知道有哪些 skill 可以用
- 当它判断当前任务像某个 skill 的适用场景
- 再把完整内容加载进来
所以 skill 的底层感觉，确实很像“查目录，再翻章节”。
而 hook 则完全不一样。
hook 更像程序世界里的事件监听：
- 某个时刻发生
- 系统检测到
- 自动执行脚本/命令
- 根据结果决定提示、校验还是阻断
如果你看到这里还是怕以后又混，我给你一个最省脑子的版本：
- CLAUDE.md：长期合作协议
- rules：局部补充规定
- skill：任务操作手册
- hook：Husky 一样的自动检查脚本
- compact：对话太长时的上下文收纳整理
最后通常都会越来越乱。
真正好用的方式反而很朴素：
- 全局原则放全局
- 局部规则放局部
- 方法论交给 skill
- 硬约束交给 hook
- 上下文乱了就 compact
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/276651.html原文链接：https://javaforall.net
