vibe-coding-课程-干货集训

09 MCP & Skills：让CC成为真正靠谱的多面手

2026年6月3日Claude Code 用到现在，你大概率撞过两堵看不见的墙。

Claude Code 用到现在，你大概率撞过两堵看不见的墙。

第一堵：它够不着你的世界。 你让它去看看 GitHub 上的 issue、查一下数据库、打开网页核对、对着飞书发个通知——它做不到。它被关在自己的小黑屋里，只能看到你当前塞给它的那点东西。 第二堵：它不懂"你这一行"怎么把事做对。 让它按你公司的规范提交代码、按你的文风写稿、按你这套流程做调研——每次都要从头教一遍，换个窗口它就忘得干干净净。

这一期的两个主角，正好一人拆一堵墙：

MCP 让 Claude 够得着 —— 把它接到外部世界，能连数据、连工具、连你的各种平台。 Skills 让 Claude 做得对 —— 把你的专业方法打包塞给它，让它做得专业、做得像你。

一个往外扩能力的边界，一个往里沉淀做事的方法。下面先讲 MCP，再讲 Skills，最后说说为什么它俩经常被打包在一起。

graph LR GH[GitHub] --- MCP DB[数据库] --- MCP BR[浏览器] --- MCP FS[飞书] --- MCP MCP["MCP · 能力触手
够得着外部世界"] --- CC(("Claude Code")) CC --- SK["Skills · 做事方法
做得对、像你"] SK --- WD[写文档] SK --- FR[财报分析] SK --- GF[团队规范]

一、MCP：给 Claude 接上外部世界

MCP 是什么

打个比方，MCP 就像 Claude 的"能力触手"。像章鱼一样，它能伸出一条条触手，搭到外面各种平台上——你的数据、你的个人信息、你的历史文档、各种线上服务。装一条对应的"触手"，Claude 就多一种够得着那个系统的能力。

往技术上再说一层：MCP 想做的，是 "AI 时代的 USB 接口"。USB 出现之前，每个设备一种插口，乱成一团；USB 把它统一了，插上即用。MCP 想对"AI 连接外部世界"这件事，做同样的统一——一个大家都照着来的标准，Claude 就能即插即用。

说得再准一点，它的野心是当 "AI 时代的 API 协议"。过去二十年，软件和软件之间靠 API 对接；现在 Claude 这样的 agent 要和整个外部世界对接，MCP 想做那个通用标准。

原理一句话就够：

Claude 通过 MCP 这个统一接口，向一个个 MCP server 发请求、取结果；server 负责对接背后真实的系统（GitHub、数据库、飞书……）。原理就这么多，剩下的不用操心。

为什么需要 MCP

默认的 Claude 是个"信息孤岛"。 你问它"我 GitHub 上那个 issue 进展如何"，它只能回"我看不到"。查实时数据、打开网页、连公司内部系统——通通够不着。它再聪明，也被困在一间没有窗户的房间里。 装上对应的 MCP，它当场长出那只手。 接一个 GitHub MCP，它立刻能读 issue、提 PR；接一个数据库 MCP，它能直接查数；接一个飞书 MCP，它能帮你写文档、发消息。房间开了一扇扇门。

MCP 能做什么

把 Claude 接到外面，常见的接法有四类：

连开发工具
接 GitHub，让它读 issue、提 PR、看代码；接浏览器（Playwright），让它自动点页面、跑测试、截图。
连数据
接数据库，用人话直接查；接文件系统，读你本地或云上的资料。
连协作软件
接飞书 / Slack / Notion，让它发消息、写文档、查日历——你日常用的工作台，它也能上手。
连设计与第三方服务
接 Figma 读设计稿，接各种 SaaS 的接口，把它们的能力借给 Claude。

MCP 长什么样

示例：给 Claude Code 加一个 MCP，通常就一行命令。

# 加一个本地运行的 MCP serverclaude mcp add context7 -- npx -y @upstash/context7-mcp# 加一个远程的 MCP server（走授权登录）claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

拆开看几个要素：

名字（如 context7）：你给这个 server 起的代号，方便管理。
本地还是远程：本地的跑在你电脑上（npx ... 这种），远程的是别人云端的服务（--transport http + 网址）。
密钥 / 授权：连私人服务要给钥匙——本地的用 -e KEY=xxx 传，远程的一般走一次浏览器登录授权。

两种类型，怎么选：

类型	跑在哪	适合
本地 server（stdio）	你自己电脑上	操作本地文件、本地工具、个人脚本
远程 server（HTTP）	服务商云端	连 SaaS（Sentry、Notion 这类），多人 / 多设备共用

放在哪（放置规则）：

用户级（全局生效）：写进全局配置 ~/.claude.json，你所有项目都能用。适合放通用的，比如浏览器、搜索这种哪个项目都想用的。
项目级（仅本项目）：写进项目根目录的 .mcp.json，可以提交到 git，团队拉下来就共享同一套连接。适合放这个项目专属的服务。

怎么用 & 怎么管理

加 MCP 有三条路，优先让 Claude 自己帮你配：

让 Claude 配（推荐）：直接说"帮我加一个能读我 GitHub 的 MCP"，它会帮你查命令、写配置。
自己敲一行：claude mcp add ...（上面那种）。
从市场找现成的：很多服务（GitHub、Figma、Vercel……）官方都出了 MCP，照说明装即可。

管理也简单：在 Claude Code 里输入 /mcp，能看到所有已连接的 server、它们提供哪些工具、授权状态，随时开关。

要不要自己做一个 MCP？ 一般不用。除非你想做个工具、让一堆 coding agent 都能调用你的服务——那才值得自建。日常用，装现成的就够。

这些 MCP 现在仍然好用

市面上 MCP 上万个，但真正值得装的不多。下面几个到 2026 年仍是口碑款：

Context7 —— 把某个库的最新版文档实时喂给 Claude，专治它用过时 API。全生态最火。
GitHub —— 读 issue、提 PR、管理仓库，开发者几乎人手一个。
Playwright —— 用人话驱动浏览器："帮我测一下登录流程"，不用自己写脚本。
按需再加 Figma（设计稿转代码）、Vercel / Sentry（看部署、查报错）。优先选官方维护的，更可信。

别贪多。 装超过 5–7 个 server，工具一多反而拖慢、拖乱 Claude。挑 2–3 个你天天用的就好。

想反面：MCP 的毛病，和为什么"命令行"在复兴

这一节别人不爱讲，但你该知道——免得把 MCP 当万能药。

MCP 的几个真问题：

费上下文：有些 MCP 光"工具说明书"就占掉几千上万 token，还没干活，Claude 的脑容量先被吃掉一截。
安全是大雷：2026 年上半年，热门 MCP server 被扒出大量漏洞，有的还爆过严重的远程执行风险。装来源不明的 MCP，等于把钥匙交给陌生人，务必只装可信来源。
质量参差：社区里一句糙话流传很广——"95% 的 MCP server 是垃圾"。

于是"命令行（CLI）"开始复兴。 很多事其实不需要 MCP：给 Claude 一个命令行工具（比如 gh、vercel，甚至飞书的 lark-cli）反而更轻、更省、更可控——Claude 本来就很会用命令行。连 Notion、Playwright 这些都同时出了 CLI 版本。

更有意思的是，Anthropic 官方自己也在给 MCP "减负"，三个建议值得记：

让 Claude 写代码去调 MCP，而不是一个个直接调——能省下近 98% 的 token。
工具按需搜索加载（Tool Search），别一股脑全塞进上下文——Claude Code 现在默认就这么干。
把跑通的能力沉淀成 Skill 复用（正好接到下半篇）。

一句话判断：你自己机器上的日常活，优先用"命令行 + Skill"，更顺；只有当你要连一个云端服务、还想在好几个 AI 客户端里都能用时，才上 MCP。

实操：装一个 Context7，让 Claude 用上最新文档

走一遍你真会遇到的场景。

你想做的事：让 Claude 用某个库的最新写法帮你写代码，但它老给你过时的、跑不通的 API。

第一步 · 装上 Context7

claude mcp add context7 -- npx -y @upstash/context7-mcp

第二步 · 确认连上了：在 Claude Code 里输入 /mcp，看到 context7 在列表里、状态正常。

〔配图2 · 截图：/mcp 面板里 context7 已连接〕

第三步 · 用它：提问时让它查最新文档，比如——

用 Next.js 最新版帮我写一个带缓存的数据请求，参考 context7 的最新文档

第四步 · 看差别：没装之前，它可能给你一段半年前的旧写法；装上之后，它会先拉最新文档、再按当前版本写。一个会跑，一个报错——差别立刻看得到。

到这儿，你已经会装、会用、会管 MCP 了。下次想让 Claude 够着哪个系统，就给它接一条"触手"。

二、Skills：把你的专业方法装进 Claude

先接住上一期的伏笔

上一期讲 Subagent 时我们说过一句："Skill 是一条工作流水线，Subagent 是流水线上的工作单元"。这一期，就把这条"流水线"讲透——它到底怎么写、怎么用。

Skill 是什么

如果说 MCP 是"能力触手"，那 Skill 就是给 Claude 的一本"专业技能包 / 活页 SOP 手册"。

你把"做某一类专业活儿的整套方法"——该怎么做、注意什么、用什么模板——写成一个 Skill。以后 Claude 一碰到这类活，自动翻开这本手册，照着你的标准做。

〔配图3 · 示意图：一摞贴了标签的手册（写课程文档 / 财报分析 / 提交规范），Claude 按任务抽出对应那本〕

为什么需要 Skills

同一类专业活，你每次都在从头教。 怎么按你的风格写文档、怎么做财报分析、怎么按团队规范提交代码——你讲了一遍又一遍。换个对话窗口，Claude 就忘光了，做出来还总差点意思、不像你的水准。 写成一个 Skill，它就"学会"了。 把这套方法沉淀成一个 Skill，Claude 以后遇到这类活自动加载、按你的标准做。而且可复用、能进 git 分享给团队、越用越顺——教一次，受益无数次。

Skills 能做什么

封装专业工作流：写课程文档、做财报分析、跑竞品研究——把多步流程固化下来。
固化你的个人 / 团队规范：提交规范、文风、审美偏好，让它做得"像你"。
打包知识 + 脚本 + 模板：一个 Skill 里能放说明、参考资料、甚至可执行脚本。
团队共享、长期复利：放进 git，全队和未来的你都能用同一套。

Skill 长什么样

示例：一个最简单的 Skill，核心就是一个 SKILL.md 文件。

---name: commit-helperdescription: 按团队规范写 git commit message。当用户要提交代码、写 commit 时使用。---# 写 Commit Message按以下规范写：1. 首行：<类型>: <做了什么>，用中文，不超过 50 字2. 类型只用：feat / fix / docs / refactor3. 描述"为什么改"，不只是"改了什么"

拆开看要素：

name：这个 Skill 的代号。
description：最关键的一栏。Claude 靠它判断"什么时候该翻开这本手册"，所以要把"做什么 + 什么时候用"写清楚（这点和上一期 Subagent 的 description 是一个道理）。
正文：具体的做事指南——怎么做、按什么标准、输出什么格式。
附带文件（可选）：参考资料、模板、脚本，放在同一个文件夹里。

一个省脑容量的机制：Skill 平时只占一行（就 name + description），Claude 真用到了才翻开全文。所以你装一堆 Skill 也不挤占上下文——正好呼应我们讲过的"省 Token"。

类型大致三种：

类型	装什么	例子
知识型	领域知识、规范	公司的财报口径
流程型	多步 SOP	写课程文档的完整流程
工具型	封装脚本	一键生成某种报表

放在哪（放置规则）：

用户级（全局）：~/.claude/skills/<名字>/，你所有项目都能用。适合通用技能。
项目级（仅本项目）：项目根目录/.claude/skills/<名字>/，可提交 git，团队共享。适合这个项目专属的活。

怎么创建 & 管理

让 Claude 帮你建（推荐）：用专门的 skill-creator，一句话描述需求，它帮你把整个 Skill 文件夹搭好。
比如："帮我建个 skill，叫 weekly-report，按我这个格式整理每周工作。"
自己写：手动建文件夹、写 SKILL.md，适合你很清楚要什么的时候。
管理：Skill 就是文件夹，直接改 / 删对应文件即可；团队版跟着 git 走。

实操：造一个属于你的 Skill

你想做的事：每次让 Claude 写 commit message，都得重复念一遍团队规范，烦。

第一步 · 让 Claude 建

用 skill-creator 帮我建一个 skill，叫 commit-helper。作用：按我们团队规范写 git commit message——中文、首行不超过 50 字、说清为什么改。放项目级。

第二步 · 看它生成：Claude 会在 项目根/.claude/skills/commit-helper/ 下建好 SKILL.md。

〔配图4 · 截图：生成好的 commit-helper skill 文件结构〕

第三步 · 用：下次你直接说"帮我写这次改动的 commit"，Claude 自动翻开这本手册、按规范写——不用再念叨规范了。

第四步 · 进化：哪天规范变了，让 Claude 改一句 SKILL.md 就行；提交到 git，全队同步。

教一次，以后每次提交都受益——这就是 Skill 的复利。

三、Plugin：为什么很多插件是「MCP + Skills」的组合

你装插件（plugin）时可能发现过：一个插件里，常常同时打包了 MCP 和 Skills。比如 Vercel 的插件，既带一个 Vercel 的 MCP，又带一整套教 Claude 怎么用好 Vercel 的 Skills。

为什么这么配？因为它俩天生互补：

一句话记住：Skill 是不变的"怎么用"层；它下面的连接，可以是 MCP（连云端服务、跨客户端），也可以是命令行（在你自己终端里）。Plugin 负责把它们打包成一个东西发给你。 MCP 给了连接，但它的"说明书"往往太简略、教不会 Claude 怎么用好；Skill 正好补上"怎么用"。两个一捆 = 连得上 + 用得对 = 一个完整能用的能力。

所以三者的关系可以这么理解：

角色	干什么	类比
MCP	连接外部世界	能力触手 / USB 接口
Skills	教 Claude 把事做对、做得像你	专业技能包
Plugin	把上面这些打包、分发、一键安装	装好的工具箱

MCP 让 Claude 够得着，Skills 让 Claude 做得对，Plugin 把它们装进一个盒子递给你——这就是 Claude Code 能力扩展的完整图景。下次再看到一个插件，你就知道它里面大概装了什么、各自在干嘛。