很多人在开始使用 Claude Code 时，都会碰到一个看似简单、实际很容易选错的问题：
同样都是“定制 Claude 的方式”，到底该用 Skills，还是 CLAUDE.md？什么时候该上 Subagents？Hooks 和 MCP 又是干什么的？
如果这个问题没想清楚，后面很容易走偏。
本来只是想让 Claude 在某个任务上更专业，结果把大量说明都塞进全局配置里；
本来只是想加一个自动检查，却误用了 Skills；
本来需要一个独立执行的上下文，却还在当前会话里硬撑。
最后系统越来越复杂，效果却不一定更好。
这篇文章，我们就把 Claude Code 里最常见的五种定制方式讲清楚：Skills、CLAUDE.md、Subagents、Hooks 和 MCP servers。**它们并不是互相替代的关系，而是各自解决不同的问题。
· 先说结论：这五种能力，解决的是五类不同问题
Claude Code 提供的这些能力，看起来都和“定制”有关，但它们的工作逻辑完全不同。
你可以先这样理解：
- CLAUDE.md： 每次对话都会加载，适合放“始终生效”的项目规则
- Skills： 按需加载，适合放“只在特定任务里需要”的专业知识
- Subagents： 独立上下文执行，适合做委派任务
- Hooks： 事件触发，适合自动执行某些动作
- MCP servers： 提供外部工具和集成能力，属于“连接能力”而不是“提示能力”
这几个功能最容易出问题的地方，就是很多人总想用一个功能解决所有问题。
但实际上，它们各管一摊，组合使用才是正解。
1. CLAUDE.md 和 Skills，最大的区别是“是否始终加载”
这是最常见、也最容易混淆的一组。
CLAUDE.md：适合放每次都必须遵守的规则
CLAUDE.md 的特点很明确：它会在每一次对话中加载。
也就是说，不管你是在写代码、查 bug、做 review，还是改文档，这里面的内容都会一直存在于上下文里。
所以，凡是你希望 Claude 始终遵守 的要求，都更适合放进 CLAUDE.md。
比如：
- 项目统一使用 TypeScript strict mode
- 不允许修改数据库 schema
- 默认使用某个框架或代码风格
- 团队约定的全局开发规范
这类规则有一个共同点：无论做什么任务，它们都成立。
Skills：适合放只在某些任务中才需要的知识
Skills 则完全不同。
它不是每次都加载，而是在 Claude 判断当前请求与某个 Skill 匹配时，按需把这部分说明加入会话。
这就意味着，Skills 更适合承载“特定任务下的专业知识”。
比如：
- PR review 的检查清单
- 某类测试流程的操作规范
- 某个特定模块的排错方法
- 只有在做发布、审查或迁移时才用到的详细步骤
举个很典型的例子：
你在写新功能代码时，并不需要 PR review 的全部规则一直占着上下文；
但当你明确发起代码审查时，Claude 就应该自动调出那套 review 经验。
这就是 Skills 的价值：该出现时出现，不该出现时不打扰。
该怎么选
可以记住一个最简单的判断标准：
凡是“永远都要生效”的，放 CLAUDE.md；
凡是“只有某类任务才需要”的，放 Skills。
如果把所有内容都塞进 CLAUDE.md，会让每次对话都背上额外负担；
如果把全局规则写成 Skills，又可能导致它在该生效的时候没有稳定生效。
所以，二者不是谁替代谁，而是职责不同。
2. Skills 和 Subagents，不是“谁更强”，而是“是否需要隔离执行”
很多人也会把 Skills 和 Subagents 搞混，因为它们看起来都像是在“帮 Claude 更好完成任务”。
但本质上，这两者做的不是一件事。
Skills：给当前会话补充知识
Skill 被激活之后，是把相关说明加入到当前对话上下文 里。
也就是说，Claude 还是在你当前这条主线里继续思考和执行，只不过它现在多了一套更具体的知识或流程。
所以，Skill 的核心作用是：
增强当前任务中的认知和处理方式。
它适合用在：
你希望 Claude 在眼下这个任务里更懂规则、更懂流程、更懂标准。
Subagents：把任务交给独立上下文去做
Subagents 则是另一种模式。
它不是给当前会话“补知识”，而是开辟一个独立的执行上下文， 把某个任务交出去，让它单独完成，然后把结果带回来。
这意味着 Subagents 更像“委派”，而不是“增强”。
它适合的情况包括：
- 你想把一项工作交给独立上下文处理
- 你希望主会话和被委派任务之间保持隔离
- 你需要和当前会话不同的工具访问方式
- 你不想让某个子任务把主上下文弄得太杂乱
该怎么理解这两者的边界
一句话说清楚：
Skills 是把知识带进当前对话；
Subagents 是把任务送去另一个对话。
如果你只是想让 Claude 当前这一轮更懂“怎么做代码评审”，用 Skill 就够了。
但如果你想把“去单独分析这一批日志并整理结论”作为一个子任务委派出去，Subagent 会更合适。
所以，这里不要用“功能更强”来判断，而是看你是否需要一个隔离的执行环境。
3. Skills 和 Hooks，一个是“按请求触发”，一个是“按事件触发”
这也是非常值得分清的一对。
Hooks：事件发生了，它就自动运行
Hooks 的逻辑是事件驱动。
也就是说，不是你主动在问什么，而是某个动作一发生，它就触发。
比如：
- 每次 Claude 保存文件时自动跑 linter
- 某些工具调用前自动做参数校验
- 在执行关键操作前后触发某种自动处理
这些事情的共同特征是：
不是因为你在“讨论”这个问题，而是因为某个动作发生了。
因此，Hooks 非常适合做自动化、校验、固定副作用处理。
Skills：你在问什么，它决定要不要激活
Skills 则是请求驱动。
它关注的是：你当前让 Claude 做的是什么事。
如果你在请求代码审查，它可能激活 review Skill；
如果你在做发布流程，它可能激活 release Skill；
如果你在排查某类故障，它可能激活相应的诊断 Skill。
所以，Skills 影响的是 Claude 如何理解和处理请求，而 Hooks 影响的是某些事件发生时自动执行什么动作。
什么时候用 Hooks，什么时候用 Skills
判断方式也不复杂：
如果你希望“每次某个动作发生，都自动做一件事”，那是 Hooks；
如果你希望“Claude 在处理某类任务时，自动带上对应知识和规则”，那是 Skills。
一个偏自动执行，一个偏任务理解。
一个是流程触发，一个是认知增强。
千万别混用。
· MCP servers 又是什么？它根本不是同一类东西
前面几个功能都容易被看作“提示或执行层的定制”，而 MCP servers 其实是另一类能力。
它的重点不在“告诉 Claude 怎么想”，而在“让 Claude 能接入哪些外部工具和系统”。
也就是说，MCP servers 本质上提供的是：
- 外部工具
- 外部数据源
- 系统集成能力
- 与外部环境交互的接口
所以，MCP 和 Skills 不是替代关系。
Skills 提供的是任务相关知识，MCP 提供的是外部操作能力。
前者解决“怎么做更专业”，后者解决“能调用什么资源”。
把这两者混为一谈，是很多初学者最常见的误区之一。
4. 一套更合理的 Claude Code 配置，通常长什么样
如果把这些能力放回实际开发环境里，一个比较自然的组合往往是这样的：
- CLAUDE.md
放项目级、长期稳定、每次都必须遵守的开发标准
- Skills
放只在特定任务里才需要的专业知识和详细流程
- Hooks
处理保存文件、调用工具等事件触发型自动化动作
- Subagents
承担需要独立上下文的委派任务
- MCP servers
连接外部工具、系统和集成能力
这样的结构有一个明显好处：
每种机制只做自己最擅长的事。
不会让全局配置越来越臃肿；
不会让自动化逻辑混进任务知识；
也不会把本该独立执行的任务全塞进主会话里。
· 真正重要的，不是会不会用，而是别把它们用错
Claude Code 的这些能力，看起来都很强，但真正决定效果的，往往不是你“用了多少功能”，而是你有没有把它们放到正确的位置上。
很多复杂度，其实不是任务本身复杂，而是因为定制方式选错了。
该放在 CLAUDE.md 的，别硬写成 Skill；
该用 Hooks 自动做的，别靠手动提示去提醒；
该交给 Subagent 的，别把主会话上下文搅得越来越乱；
该通过 MCP 接工具的，也别试图让 Skills 去冒充外部集成。
说到底，这些能力不是竞争关系，而是分工关系。
· 结语
如果你只记住一句话，那就是：
CLAUDE.md 管“始终生效”，Skills 管“按需专业化”，Subagents 管“独立执行”，Hooks 管“事件自动化”，MCP 管“外部工具接入”。
它们不是让你五选一，而是帮你把 Claude Code 的定制能力拆成五种明确职责。
真正成熟的使用方式，不是试图把所有问题都塞进一种机制里，而是根据任务特点，把每一层能力安排到最合适的位置上。
当你开始这样理解 Claude Code，你就会发现：
系统不仅更清晰了，配置更容易维护了，Claude 在实际开发里的表现，也会稳定得多。
