claude-code-skill-mcp-hook
第一次打开 Claude Code，界面上摆着 Skills、MCP、Hook、Plugin 四个词，我的第一反应跟大多数人一样——都是插件吧，全装上就完事。

三天后我才知道这个判断有多草率。我把这三天的踩坑过程理了一遍，希望能帮你少走弯路。搞清楚这四个概念各自解决什么问题，是用好 Claude Code 的前提。

第一天：装了一堆 Skills，Claude Code 却纹丝不动

Skills 看起来最直觉。skills.sh 上挂着六十多万个，我光是浏览就花了半小时，一口气装了七八个。结果呢？Claude Code 的行为完全没变。

困惑了好一阵才想明白：Skills 不是插件，是"领域知识包"。说白了就是高级 Prompt，告诉模型"在这个领域里该怎么做"。它不连任何外部服务，也不给 Claude Code 增加新工具。装了一个 React 最佳实践 Skill，得到的是更懂 React 规范的模型，不是一个能替你提 PR 的机器人。

选 Skills 的判断标准只有一条：你是想"让模型更懂某个领域"，还是"让模型能做成某件事"？前者用 Skills，后者接着往下看。

第二天：配 MCP，卡在报错里整整一下午

摸清 Skills 的边界之后，我意识到自己真正想要的，是让 Claude Code 连上 GitHub、Notion、外部数据库。这才轮到 MCP。

MCP（Model Context Protocol）是一套开源标准协议，解决的是"能不能连上"的问题。Claude Code 本身是一个 MCP client，内置了读文件、跑 bash、搜代码这些能力，但没有 MCP，它碰不到你的 GitHub repo、云数据库或者任何第三方 API。工具再强，连不上你的数据也是空转——这是很多人做 AI Coding 时的盲区。

MCP 踩坑实录（Windows 用户重点看）

我在 Windows 11 下配 context7 MCP，连续报错三次，最后归结成四个坑。

第一个坑，npx 命令必须用 cmd /c 包一层。Windows 下 Claude Code 抓不到 npx 的 stdio 通信，得这么写：

// .mcp.json（项目级配置）
{
  "mcpServers": {
    "context7": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@upstash/context7-mcp", "--api-key", "YOUR_KEY_HERE"]
    }
  }
}

macOS 和 Linux 用户不用管这个，直接写 npx 就行。

第二个坑最阴险：API Key 只能靠 --api-key 参数传，context7 MCP 不认 API_KEY 环境变量。关键是它不报错，只是静默失效，排查起来能耗掉你半天。

第三个坑出在命令行。claude mcp add 少了 -- 分隔符就会解析失败：

# 错误写法，解析失败
claude mcp add context7 npx -y @upstash/context7-mcp

# 正确写法
claude mcp add context7 -- npx -y @upstash/context7-mcp

第四个坑是习惯问题：改完配置不重启，永远不生效。改动任何 MCP 配置后，把终端或 VS Code 插件彻底关掉再开一次，然后用 /doctor 验证连接状态。

MCP 的隐性成本：上下文窗口

这里有个容易被忽略的账要算。每连一个 MCP server，它完整的工具 JSON Schema 就会塞进系统提示词。社区里有人测过，光加载一个 Playwright MCP，就吃掉 200k 上下文窗口的 8% 左右。几个 server 叠加，再配上多轮对话，模型的推理质量会一路往下掉。

MCP 不是装得越多越好。只连当前任务真正用得上的 server——这是我用下来最实在的一条原则。我自己长期挂着的，也就两三个。

第三天：Hook 才是最被低估的那个

前两天我一直以为 Hook 是某种 MCP 变体，第三天认真读完文档才发现，它解决的是完全不同的问题。

Hook 挂在 Claude Code 生命周期的节点上——你定义的 shell 命令、HTTP 端点或者一段提示词，在特定事件触发时自动跑起来。一共 13 个事件，按触发频率分三档：

  • 每会话一次：SessionStart、SessionEnd
  • 每轮一次：UserPromptSubmit、Stop、StopFailure
  • 每次工具调用：PreToolUse、PostToolUse 等

我用得最顺手的是两个场景：

// Hook 配置示例，实际格式为 JSON
{
  "hooks": {
    "PostToolUse": {
      "command": "npm run lint --silent",
      "filter": { "tool": "write_file" }
    }
  }
}

一个是 PreToolUse，在模型动手写文件之前先自动备份；另一个是 PostToolUse，每次改完代码自动跑 lint。PreToolUse 还能拦截甚至阻止工具调用，遇到高风险操作需要人工过一眼时特别管用。PermissionDenied 返回 {retry: true} 时，模型会换个思路重试刚被拒的操作。

到这里选型的判断就清楚了：MCP 决定"能连接什么"，Hook 决定"执行时发生什么"。

四者选型速查

我想要… 用什么
模型更懂 React / TypeScript 规范 Skills
连接 GitHub / Notion / 数据库 MCP
每次写文件后自动跑测试 Hook
官方预置的场景化功能 Plugin

这四个不是互相替代的关系，是叠在一起用的不同层级：Skills 注入知识，MCP 扩展连接，Hook 自动化流程，Plugin 封装场景。想清楚这条主线，大部分配置决策就不用纠结了。

常见问题

Claude Code MCP 配置文件放在哪里？

分两级。项目级配置放在项目根目录的 .mcp.json，可以提交进版本库给团队共享；用户级配置在用户设置里，对所有项目生效。本机的私有凭证建议单独放 ~/.claude/settings.local.json。其实我更推荐直接用自然语言让 Claude Code 帮你加 MCP server，比手动编辑配置文件省事得多。

Skills 和 MCP 能一起用吗？

能，而且值得组合。MCP 负责"能连上"，Skills 负责"知道怎么用"，两者互补。连上 GitHub MCP 之后再挂一个 Git 工作流 Skill，模型既能操作 repo，又懂什么才是像样的提交规范。

Claude Code 和 Cursor、Copilot 有什么本质区别？

Cursor 和 Copilot 的内核是自动补全，Claude Code 是 Agent。你给它一段任务描述，它自己读文件、跑命令、跨文件改代码，整个过程不用你一步步确认。MCP、Hook 这类生命周期扩展机制在 Agent 里才有意义，在补全工具里压根不存在。这也是我判断一款 AI 编程工具值不值得深投入的标准之一。

那 Codex、GPT 系列这些呢？

经常有人问我 Claude Code 和基于 GPT 的方案、OpenAI 的 Codex 类工具怎么比。模型能力上都不弱，各有各的强项。但就 Agent 化的编程工作流、MCP 生态和 Hook 这套生命周期控制而言，Claude Code 目前打磨得更完整。真要提效，与其纠结哪个模型跑分高，不如先把手上工具的 MCP 和 Hook 配明白。

国内用户怎么稳定用上 Claude Code？

这确实是第一道坎。Claude Code 依赖 Anthropic 账号、海外信用卡，对网络也有要求，很多人卡在配置阶段就放弃了。我们做 ECC 的初衷就是把这一步抹平——免翻墙、免绑海外卡，直接调用 Claude Code 的完整 API 能力，个人开发者和需要统一管理 Token 消耗的团队都能用。接入之后，你就能把精力全放回开发本身。

写在最后

三天的困惑，根子在于我一开始没分清这四个概念的边界。抓住"Skills 注入知识、MCP 扩展连接、Hook 控制流程"这条主线，绝大多数配置问题就顺了。

从最小可行配置起步：先装一两个真正用得到的 MCP server，写一个 PostToolUse Hook 跑 lint，再按需叠 Skills。别在六十多万个 Skills 里迷路，也别把 MCP server 装满。在 AI 编程这件事上，克制往往比贪多更值钱。

关于 Easy Claude Code

如果你想用上 Claude Code，可以试试我们 ECC（Easy Claude Code）的中转服务：免🪜、低成本、快速稳定，直连官方 Claude Code。企业定制化服务可详询。