MCP、Skills、Hooks到底有什么区别？Claude Code三大扩展机制怎么选

一句话总览：Claude Code的三大扩展机制不是三选一，而是各管一层：MCP负责“能连到什么外部系统”，Skills负责“怎么把一套复杂流程做漂亮”，Hooks负责“哪些动作必须无条件执行”。判断该用哪个，只看三个问题——要不要连外部服务、要不要每次都强制、是不是一段可复用的流程。本文把三者的定位、配置、Token成本和最容易踩的坑讲清楚，顺手纠正几处网上教程常年抄错的命令和包名。

用Claude Code久了，几乎所有人都会撞上同一个困惑：同样想让AI“自动做点什么”，到底该接个MCP服务器、写个Skill，还是挂个Hook？三个词听着都像“插件”，功能也确实有重叠，于是很多人随手抓一个就用，结果要么Token烧得飞快，要么该执行的步骤总被跳过。

问题的根子在于，这三样东西压根不在一个层面上。把它们的分工想清楚，选择就变得很机械了。这篇就按“一层一层”的思路拆开讲，每个机制配上当前官方的正确配置方式——网上不少教程还在抄两年前的老写法，包名和配置文件位置都变了，照着配只会报错。

MCP、Skills、Hooks分别在解决什么问题？

先给一个整体的心智模型。把Claude Code想象成一个能干的程序员，这三样东西分别给了它不同的东西：

• MCP是“手臂”——让它能够到外部世界。没有MCP，Claude只能在本地文件和命令行里打转；接上MCP，它就能读GitHub issue、查数据库、调Sentry、发Slack。解决的是“能做什么”的问题。
• Skills是“工作手册”——告诉它一类活该怎么干得专业。把你反复交代的那套流程、规范、注意事项写成一个知识包，需要时自动调出来。解决的是“怎么把事做好”的问题。
• Hooks是“车间纪律”——规定哪些动作一定发生、不容商量。它不靠AI判断，到了某个生命周期节点就确定性地执行。解决的是“什么事必须做”的问题。

一个最关键的区别藏在“要不要AI推理”上：MCP和Skills都依赖模型自己判断要不要用、怎么用，所以有不确定性；Hooks是代码级触发，到点必执行，零推理、零随机。理解了这条，后面所有的取舍都顺了。

MCP是什么，什么时候才值得连？

MCP全称Model Context Protocol（模型上下文协议），是一个开放标准，专门用来把AI和外部工具、数据源接起来。一个MCP服务器可以对外暴露三类东西：可执行的操作（Tools）、可读取的数据（Resources），以及预设的提示模板（Prompts）。

什么时候该连？官方给的信号很接地气：当你发现自己反复在“别处复制、粘贴进对话”时——比如把issue内容贴给Claude、把数据库查询结果贴进来、把监控面板的报错抄过去——就该给那个系统接个MCP，让Claude直接读、直接动手，而不是靠你当二传手。

接上之后，体验是质变的。以前你得先去GitHub把issue描述复制下来、贴进对话、再让它写代码；现在你可以直接说“把ENG-4521这个issue描述的功能实现了，并开一个PR”，它自己去读、去写、去提。查数据库也一样——“找出过去90天没下过单的客户邮箱”，它直连你的库跑查询。监控、设计稿、消息通知，凡是接了MCP的系统，都能用一句自然语言把跨系统的活串起来。这种“不用再当人肉中转站”的顺滑感，是MCP真正的价值所在，也是判断一个系统值不值得接的标准：你是不是经常在它和对话框之间来回搬运。

这里要纠正一个网上抄烂了的错误。很多老教程教你把MCP服务器写进.claude/settings.json的mcpServers字段，这是错的。.claude/settings.json管的是权限和钩子，不是MCP。正确的做法是用命令行添加，比如接微软官方的Playwright做浏览器自动化：

# 正确：用 claude mcp add 添加
claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest

# 接远程 HTTP 服务器（如 Sentry）
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

# 查看 / 删除
claude mcp list
claude mcp remove playwright

顺带再纠一个常见的包名错误：浏览器自动化的官方包是@playwright/mcp（微软维护），不是某些教程里写的@anthropic-ai/mcp-playwright那种根本装不上的虚构名字。看到LLM生成的安装指令里出现奇怪的官方域名包名，先去核实再跑，别浪费时间。这类配置坑，保哥在Claude Code MCP配置指南里按local、project、user三种作用域整理过一份能直接抄的清单。

关于MCP的Token成本，也有个重要的“时效更新”。源文那个年代的共识是“MCP工具定义常驻上下文、很烧Token”，所以建议能少接就少接。但2026年起Claude Code默认开启了Tool Search：会话启动时只加载服务器名和说明，具体工具定义按需检索、用到才进上下文。这意味着多接几个服务器对上下文窗口的挤占已经小了很多。当然“按需接、用完撤”仍是好习惯，只是不必再像以前那样为了省Token而束手束脚。

Skills是怎么把“反复粘贴的指令”沉淀下来的？

Skill的本质是一个可复用的指令包，落地形态就是一个SKILL.md文件，放在.claude/skills/目录下（项目级），或者放进你的个人目录跨项目共用。它最精妙的设计叫渐进式披露：平时Claude只看得到这个Skill的名字和一句话描述，大约几十个Token；只有当它判断当前任务跟这个描述对上了，才会把完整内容加载进来。

这套机制解决了一个老大难：你既想把领域知识、操作规范喂给AI，又不想这些内容一直占着上下文。渐进式披露让“知识储备很大”和“常驻成本很低”这两件事同时成立。

一个SKILL.md长什么样？开头是一段YAML头信息，至少有name和description两个字段，剩下正文就是这个技能的完整说明。这里头藏着写Skill的头号心法：description决定它会不会被正确触发。描述写得太宽泛，模型会在不相关的任务里误触发；写得太窄或太抽象，又该用的时候它认不出来。诀窍是把“什么场景下用我”写得既具体又有辨识度——与其写“处理文案”，不如写“当需要按某品牌语气改写产品描述时使用”。正文部分则尽量写成可执行的步骤、清单、反例，而不是一堆空泛的原则，模型照着做才不走样。调试Skill的过程，本质就是反复打磨这段描述，直到它在该出现时出现、不该出现时安静。

Skill大体分两类。一类是知识型，给模型补一块领域知识，比如你们团队的接口设计规范、品牌文案语气，Claude碰到相关任务自动检测、自动取用。另一类是任务型，封装一段完整流程，比如“发布前的检查清单”“数据库迁移的标准步骤”，可以手动触发也可以靠描述自动命中。

判断一件事该不该做成Skill，有个朴素的标准：同一套指令你已经粘贴过三次以上。第三次还在复制粘贴，就说明它该被沉淀成一个Skill了。关于怎么写一个真正好用、不会误触发的Skill，保哥在Claude Skills怎么用里拆过官方的十几个示例技能，可以照着仿。

Hooks凭什么是“必须执行”的那一层？

Hooks和前两者最大的不同：它完全不依赖AI推理。你把一段脚本绑到某个生命周期事件上，事件一触发，脚本就确定性地执行，模型连“要不要做”的判断权都没有。也正因为不进模型上下文，它的Token成本是零。

它适合什么？凡是你心里冒出“必须”“每次”“绝对不能”这种词的需求，都该用Hook，而不是指望模型自觉。最经典的例子是代码格式化和危险命令拦截：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(rm *)",
            "command": ".claude/hooks/block-rm.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "prettier --write $CLAUDE_FILE_PATH" }
        ]
      }
    ]
  }
}

注意这里的两层嵌套：外层matcher先筛“匹配哪些工具/动作”，内层hooks数组才是真正要跑的处理器。很多旧教程把它写成扁平的一层，照抄是不生效的。

钩子脚本怎么“拦截”住一个动作？关键在它的退出方式。以PreToolUse为例，Claude Code会把即将执行的工具和参数通过标准输入喂给你的脚本，脚本判断之后用退出码或一段JSON来表态：放行、还是拦下并把原因回传给模型。也就是说，钩子不只能“做点额外的事”，还能直接否决一次工具调用——这正是它能当安全硬闸的底气。相比之下，Skill里写一百句“千万别删生产库”，模型也只是“尽量记得”；而一个PreToolUse钩子匹配到危险删除命令直接返回拒绝，是物理上不让它发生。这种“能否决”的能力，是Hooks区别于另外两者最硬核的地方，也是为什么所有真正的安全约束最终都该落到钩子上。

还有一处该更新的认知：源文那种“Hooks就PreToolUse、PostToolUse、Stop、SessionStart、SessionEnd五个事件”的说法早就过时了。官方现在的事件多达三十多个，按节奏分成会话级、回合级、工具循环级，还细分出权限请求、子代理启动停止、压缩前后、工作目录变化、MCP交互等等。日常最常用的还是PreToolUse（执行前拦截）和PostToolUse（执行后处理）这两个，但要做精细自动化时，去翻一眼完整事件表往往能找到更贴的钩子。具体每个事件什么时候触发、能拿到什么数据，保哥在Claude Code Hooks指南里逐个讲过。

一张表怎么快速分清三者？

把上面拆开讲的东西收成一张对照表，选型时扫一眼就够：

这张表里，“确定性”那一行是选型时最容易忽略却最要命的。一件事如果“做了更好、不做也行”，交给Skills或MCP让模型相机决策没问题；可一旦它是“漏了就出事”的硬要求，就只有Hooks能给你兜底——因为前两者都建立在“模型这次恰好想到了”的前提上，而Hook不需要这个前提。

同一个需求，三种机制各会怎么实现？

抽象的对比不如一个具体例子。就拿最常见的需求——“写完代码自动格式化”——看三种机制分别会怎么做、结果有什么不同：

• 用MCP：接一个格式化服务的MCP服务器，然后指望Claude在写完文件后“想起来”去调它。问题是调不调由模型决定，赶任务的时候它很可能直接跳过。
• 用Skill：写一个“代码规范”Skill，描述里强调写完要格式化。比MCP稳一点，但仍取决于这个Skill这次有没有被激活、模型有没有照做。
• 用Hook：在PostToolUse上绑Edit|Write，每次落盘后自动跑prettier。这才是正解——它不商量、不遗漏，每次都执行。

看出门道了吗？同一个需求，关键不在“哪个机制能做”，而在“这件事允不允许偶尔被跳过”。格式化属于“绝对不能跳”，所以Hook完胜。反过来，“帮我查一下这个issue的上下文”这种活，本就该模型相机判断，硬塞进Hook反而别扭。选型的第一性原理，永远是先问这件事的“必须程度”。

三者怎么拼成一条生产流水线？

真正成熟的用法，从来不是三选一，而是让它们各司其职、串成一条线。给一个团队部署流程的例子，你能看到三者怎么咬合：

1. Hook守底线（PreToolUse）：任何危险命令先被钩子拦一道，这是不可逾越的安全闸，跟后面流程跑不跑没关系。
2. Skill编排主流程（/deploy）：一个部署Skill把整套步骤串起来——跑测试、打构建、走灰度，规范和顺序都写在里面。
3. MCP干外部活：流程里需要在GitHub建Release Tag、往Slack发通知，这些跨系统的动作由对应的MCP服务器完成。
4. Hook收尾留痕（Stop）：会话结束时再挂一个钩子，把这次部署的审计日志确定性地写下来，满足合规。

这条链里，Hooks在头尾把关“必须发生”的安全和合规，Skills在中间编排“该怎么做”的业务流程，MCP负责把流程里需要的外部能力接进来。三层各管一段，谁也不越界，整个流程既灵活又有硬约束。这就是把三者当成“一套工具箱”而非“三个竞品”的正确姿势。

这套组合的妙处在于职责边界清楚，出了问题好定位。某个做跨境电商工具的团队就吃过亏：他们一开始把“部署前必须跑测试”塞进了部署Skill的描述里，结果赶版本的那几天，模型为了“快点上线”自作主张跳过了测试，线上当晚就出了故障。复盘时才想明白——“必须”二字就是Hook的信号，把它交给一段靠模型自觉执行的Skill，等于把安全垫子抽掉了。后来他们把测试这一关从Skill里拎出来、改挂成PreToolUse钩子，部署Skill只管编排顺序，再没漏过测试。一个需求摆在面前，先分清它是“必须项”还是“流程项”，错配的概率就大大降低了。

这三者和斜杠命令、子代理又是什么关系？

聊到这里，常有人追问：那斜杠命令、子代理（subagent）跟这三样又怎么分？毕竟Claude Code的扩展点不止MCP、Skills、Hooks三个。把它们一起摆进同一张地图，思路会更清爽。

斜杠命令更像是Skill的“快捷入口”。你在.claude/commands/里写一个Markdown文件，就多出一条/命令名，敲一下把里面的提示词整段塞给模型。它和任务型Skill很像，区别在触发方式：斜杠命令永远是你手动敲出来的，而Skill可以靠描述被模型自动命中。简单流程用斜杠命令更直接，复杂到需要附带文件、脚本、知识的，就升级成Skill。

子代理则是另一个维度的东西——它解决的是“上下文隔离”和“并行”。当一个任务很重、会污染主对话的上下文，或者你想同时跑好几条独立的活，就派子代理去干，每个子代理有自己干净的上下文窗口，干完把结论汇报回来。它跟MCP/Skills/Hooks不是替代关系：子代理内部照样能用MCP连外部、靠Skill编排、被Hook约束。

所以更完整的心智模型是这样的：MCP/Skills/Hooks是三种“能力扩展”，斜杠命令是Skill的轻量触发器，子代理是“执行单元的复制与隔离”。它们彼此正交、可以自由组合。真正用熟Claude Code的人，脑子里装的不是“该用哪一个”，而是“这几样怎么搭”。这套组合拳的整体打法，保哥在Claude Code最佳实践里有更系统的梳理。

新手该按什么顺序把三样用起来？

知道分工是一回事，落地时从哪下手又是另一回事。三样一起上手，多数人会被配置劝退。下面给一条亲测有效的渐进路线：

第一步，先把Hooks用起来。它最该优先，原因有三：零Token成本、效果立竿见影、而且确定性最高，最容易建立“掌控感”。挑一两个你最受不了的痛点——比如AI老是忘记格式化、或者你怕它误删文件——各写一个Hook，立刻就能感受到“机制兜底”比“反复叮嘱”靠谱多少。这一步花不了半小时，回报却最直接。

第二步，把高频粘贴的指令沉淀成Skill。用Claude Code一两周后，你一定会发现某几段话反复在打。这时候按“粘贴超过三次就沉淀”的原则，把它们各做成一个Skill。从一个小而具体的Skill起步，比如团队的提交信息规范，跑通了再扩。

第三步，按真实需求接MCP。不要为接而接。等你真的烦透了“把issue内容复制进对话”“把数据库结果贴过来”，再去接对应的MCP服务器。带着具体痛点去接，你会更清楚它解决了什么，也不会陷入“接了一堆却用不上”的尴尬。

这个顺序的底层逻辑是“先确定性、再复用性、最后连接性”：先用零成本的Hooks立住底线，再用低成本的Skills沉淀经验，最后才引入相对最重的MCP去打通外部。倒过来上手，往往一开始就陷进MCP的配置泥潭，反而把最该先用的Hooks给忘了。

配置时最容易踩哪几个坑？

最后把高频翻车点集中提醒一下，每一条都是真金白银换来的：

• MCP堆积：见什么接什么，一口气连十几个服务器。即便有了Tool Search帮你省Token，过多的服务器仍会让权限管理和调试变复杂。保持在2到4个真正高频的核心服务器，比贪多务得实在。
• 拿Skill实现“必须执行”：把“每次提交前必须跑测试”写成Skill，本质是把硬要求托付给概率。该用Hook就别用Skill，这是最常见也最致命的错配。
• 只用一种机制：有人全程只接MCP，有人只写Skill，把另外两层的能力浪费掉。三管齐下才能既灵活又可靠。
• 抄过时的命令和包名：前面反复强调过——MCP用claude mcp add不是写settings.json，Playwright是@playwright/mcp不是别的；Hooks是两层嵌套不是扁平结构。配置类的东西，永远以官方当前文档为准。

一个能直接落地的最小配置建议：2到4个核心MCP服务器、5到10个常用Skill、3到5个关键Hook。核心原则就一句——用最少的上下文成本，换最大的效率和确定性。把这条记牢，三者的取舍基本不会再纠结。

常见问题解答

MCP、Skills、Hooks能不能只学一个就够用？

不建议。它们解决的是三类不同问题：连外部服务、沉淀流程、强制必做项。只用一个会在另外两个维度留下短板。最划算的学法是先吃透Hooks（零成本、立竿见影），再按需补MCP和Skills。

MCP服务器到底配在哪个文件？

不是.claude/settings.json。用claude mcp add命令添加，local和user作用域存在~/.claude.json，project作用域存在项目根的.mcp.json（可提交给团队共享）。settings.json管的是权限和钩子，别混。

为什么我接的Playwright MCP装不上？

大概率是包名抄错了。官方包是微软维护的@playwright/mcp，命令为claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest。网上一些教程里的@anthropic-ai/mcp-playwright之类是不存在的虚构名，自然装不上。

Skills和Hooks都能做自动化，区别在哪？

区别在确定性。Skills靠模型判断要不要用、怎么用，有不确定性；Hooks到生命周期节点强制执行、零推理。凡是“必须每次都做”的事用Hooks，凡是“做了更专业但可相机决策”的流程用Skills。

开了Tool Search，是不是就能随便多接MCP了？

Token压力确实小多了，但仍别贪多。服务器越多，权限面、调试复杂度、潜在的提示注入风险都跟着涨。建议守在2到4个高频核心服务器，按需接、用完撤，依旧是更稳的做法。

Hooks真的就PreToolUse、PostToolUse那几个事件吗？

远不止。官方现在有三十多个生命周期事件，涵盖会话、回合、工具循环、子代理、压缩、权限等多个维度。日常最常用的是PreToolUse和PostToolUse，但做精细自动化时翻一眼完整事件表，常能找到更贴切的挂载点。

权威参考资料