Claude Code 教程丨Skill 与 MCP：工作流与外部工具

你有没有遇到过这种情况：每次让 Claude 做代码审查，都要重复说一遍"先看改动范围，再检查测试覆盖，最后按风险分级输出"？

说多了，真的挺累的。

Skill 要解决的就是这个问题：把工作方法写下来，让 Claude 记住，以后直接执行。

而 MCP 解决的是另一个问题：让 Claude 能连上 GitHub、Notion、Slack 这些外部系统。

这两个配合起来，才能真正实现"一句话交代，AI 自主完成":

先把背景说清楚

Claude Code 里的 Skill 不是随手起的功能名。官方把它定位为可重用的知识和可调用的工作流。我们平时看到的 SKILL.md、/review-pr、/deploy，都是这一类。

更重要的是，Claude Code 的 skills 遵循 Agent Skills 开放标准。这是 Anthropic 参与制定的开放规范，不只是 Claude Code 能用，其他支持这个标准的 AI 工具也能用。

MCP（Model Context Protocol）则是另一条线。这是 Anthropic 在 2024 年 11 月开源的协议，目标很明确：让模型能接上外部系统——数据库、GitHub、Slack、Notion、浏览器等。

把这几个概念分清楚，后面就不容易混：

• • Skill：用自然语言写的工作流定义
• • Agent Skills：Skill 遵循的开放标准
• • MCP：连接外部工具的开放协议
• • Plugin：把 skills、hooks、agents、MCP servers 打包分发的机制

Skill：用自然语言写工作流

Skill 是一份用自然语言写的操作说明。它告诉 Claude：这类任务先做什么、中间查什么资料、哪些地方要小心、最终以什么格式交付。

最简单的 Skill 示例

文件结构：

.claude/
  skills/
    review-pr/
      SKILL.md

SKILL.md 内容：

---
name: review-pr
description: 审查当前改动，按风险、可读性和测试覆盖整理结论
disable-model-invocation: true
---

按下面顺序完成审查：

1. 先看当前分支的改动范围
2. 再看受影响的核心文件
3. 检查有没有明显的范围问题和回归风险
4. 检查测试是否覆盖到关键改动
5. 最后用"高风险 / 中风险 / 低风险 / 建议"四段格式输出

这份 Skill 没有写业务代码，但已经把完整的审查流程交给了 Claude。

输入 /review-pr，Claude 就会按这个流程执行。

Skill 和脚本的区别

Skill 最适合那些会反复出现，每次顺序都差不多的任务。

代码审查、发布说明整理、日报周报、部署前检查，这类任务的特点是：有稳定步骤，但不是固定脚本能一次写死的。

举个例子——发布说明整理：

脚本能做的：把 git log 拉出来。

Skill 能做的：告诉 Claude 先看这次改动涉及哪些模块，再按"新增 / 修复 / 调整"分组，如果有对用户可见的变化要单独提出来，最后整理成适合发公告的版本说明。

这就是核心区别：

• • 脚本：固定命令序列，死板执行
• • Skill：带判断的流程说明，Claude 能根据上下文调整

脚本是死的，Skill 是活的——因为执行者是能理解的 AI，不是机械的解析器。

最值得先记住的一个设置

Skill 的 frontmatter 字段不少，但真正最值得先记住的是 disable-model-invocation: true。

只要这份 Skill 会发消息、会部署、会提交、会改远端资源，就把它设成手动触发。这样做不是更麻烦，而是把主动权掌握在自己手里。

• • /review-pr 这种审查类 Skill，自动调用问题不大
• • /deploy、/send-slack 这种会产生结果的 Skill，最好手动调用

怎么写出好用的 Skill

很多人第一次写 Skill，容易把它写成"什么都想交代"的大杂烩——项目背景写一段，接口文档贴一段，注意事项写十几条。看起来很完整，用起来反而散。

一份好用的 Skill，通常有三个特点：

1. 1. 主文件短：只写目标、顺序、判断和交付
2. 2. 资料分散：大段内容放到 examples.md、template.md，需要时再加载
3. 3. 关键操作手动触发：会改远端资源的动作，默认加上 disable-model-invocation: true

SKILL.md 负责告诉 Claude "这类事该怎么做"，不负责替项目 wiki 兜底。

不好的写法

• • 把所有背景资料一次性塞进去
• • 每条都像规定，但轻重缓急不分
• • 没有交付格式
• • 没有判断标准

结果：Claude 每次都能做一点，但每次做出来都不太一样。

更好的写法

文件结构清晰：

.claude/
  skills/
    release-note/
      SKILL.md
      examples.md
      template.md

SKILL.md 里只保留几件事：

• • 这份 Skill 是拿来做什么的
• • 先做哪一步，再做哪一步
• • 哪些地方不要乱猜
• • 最终以什么格式交付

发布说明这类任务，真正值钱的不是"会不会跑 git log"，而是能不能分清改动范围、能不能把用户能感知的变化单独提取出来。

Skill 不是把代码搬进自然语言，而是把一套长期重复的做事方式写清楚。

一个实用的 Skill 范例

下面这份发布说明 Skill，比"字段列一排、规则写一堆"的写法更实用：

---
name: release-note
description: 根据本次改动整理发布说明
disable-model-invocation: true
---

目标：
- 根据最近一次发布后的改动，整理一份能直接发给团队或用户的更新说明

顺序：
1. 先确认本次整理的范围
2. 读取 git log 和 git diff
3. 把改动分成新增、修复、调整、注意事项
4. 对用户可见的变化单独提出来
5. 不确定的地方直接标成待确认

交付：
- 先给一段短摘要
- 再给完整版本说明
- 最后给一版适合群里发的短消息

Claude 一眼就知道：目标是什么、先后顺序是什么、哪些地方不能糊弄、最终要以什么格式交付。

详细案例和模板，再去旁边的 examples.md、template.md 里补，不要把所有东西硬塞回主文件。

MCP：连接外部工具

Skill 管的是"怎么做"，MCP 管的是"能不能连上"。

MCP（Model Context Protocol）让 Claude 能访问外部系统：GitHub、Notion、Slack、数据库、浏览器等。

没有 MCP，Claude 只能操作本地文件和终端。配置 MCP 后，它才能：

• • 读取 GitHub issue
• • 查询数据库记录
• • 发送 Slack 消息
• • 操作浏览器

怎么接入 MCP

手动接入最快的方式：claude mcp add

HTTP 方式（如 Notion）：

claude mcp add --transport http notion https://mcp.notion.com/mcp

本地程序方式（如 Playwright）：

claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest

配置后用 /mcp 查看状态。没连上，Claude 自然用不了这些工具。

Skill 和 MCP 怎么配合

举个例子：读 GitHub issue，查 Notion 规范，整理成 Slack 消息。

分工：

• • MCP 提供 GitHub、Notion、Slack 的连接能力
• • Skill 定义"先读 issue → 再查规范 → 最后发消息"的流程

Skill 示例：

---
name: ship-issue
description: 读 issue、查规范、整理成 Slack 消息
disable-model-invocation: true
---

1. 去 GitHub 读取指定 issue 的内容
2. 去 Notion 查询相关团队规范
3. 把需求和规范合并成实现说明
4. 整理成适合发 Slack 的消息草稿

只配 MCP，没有 Skill：Claude 能访问这些系统，但每次执行方式都不同。

只写 Skill，没有 MCP：Claude 知道要做什么，但访问不了外部系统。

两者配合，才能把事完整自动化。

核心分工

一句话记住：

• • Skill：负责把知识、流程和判断交给 Claude
• • MCP：负责把 Claude 接到外部世界

官方总览页把这几层分得很清楚：

• • Skill 是按需加载的知识和工作流
• • MCP 是外部服务和工具连接
• • Plugin 是打包层

Skill 默认只把名称和描述放进上下文，调用时才加载完整内容。MCP 则在会话开始时就把工具定义带进来。

所以 MCP 配得越多，上下文成本越高；Skill 写得越散，调用时越容易乱。

很多团队最后都收敛到同一种用法：

• • 用 MCP 解决"能不能访问外部系统"
• • 用 Skill 解决"访问之后按什么顺序做"

通过 Plugin 安装（可选）

不想手动配置 MCP，可以用 Plugin：

/plugin install github@claude-plugins-official
/plugin install notion@claude-plugins-official

Plugin 把 skills、MCP、hooks 打包在一起，开箱即用。

但建议先学会手动配置，再用 Plugin 省时间。Plugin 是别人写好的，手动配置更灵活。

两条路选一条：

• • claude mcp add：手动配置，适合先验证可行性
• • /plugin install：装现成工具包，适合长期复用

装完后用 /mcp 查看状态。如果没出现，继续检查安装状态、权限和连接情况。

浏览器和截图，先分清是哪一类需求

这一块最容易一上来就装工具，其实没必要。

如果手里已经有一张现成截图，只是想让 Claude 看看报错、看看页面、看看设计差异，通常不必先接 Playwright 或 Chrome。
先把图片贴进对话里，很多时候就够用了。具体形式还是以当前客户端实际支持为准。

真正需要额外接工具，通常是下面两类情况。

需要主动操作网页

如果要打开本地页面、点按钮、看 DOM、做一轮交互，再顺手截一张图回来，这种情况更适合 Playwright MCP。

最常见的安装命令就是：

claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest

这种方式常见的用法，是本地页面调试、交互验证和截图。
装完之后，先去 /mcp 看它是不是已经正常出现，再决定要不要把它接入日常工作流。

需要直接利用浏览器里的登录状态

如果经常要访问已经登录的网站，比如 Notion、Gmail、内部后台、运营平台，使用 Chrome 集成会更方便。

截至 2026 年 3 月 22 日，官方文档写清了几条前提：

• • 需要 Google Chrome
• • 需要 Claude in Chrome 扩展，版本至少 1.0.36
• • 需要 Claude Code，版本至少 2.0.73
• • 需要直接 Anthropic 计划
• • 这项能力不通过 Bedrock、Vertex AI、Foundry 这类第三方提供商提供

启用方式是：

claude --chrome

或者在现有会话里输入：

/chrome

官方文档强调它会复用当前浏览器里的登录状态，所以处理已登录网站通常会方便一些。
如果碰到登录页或 CAPTCHA，还是要人工处理一下。

什么时候只用 Skill，什么时候用 MCP

先用 Skill 就够了：

• • 任务在本地项目（代码审查、发布说明整理）
• • 不需要访问外部系统
• • 重点是"按固定步骤执行"

需要 MCP：

• • 要访问 GitHub、数据库、浏览器等外部系统
• • Claude 目前够不着这些资源

推荐顺序：先用 Skill，等动作重复出现后再补 MCP。这样更顺。

几个容易混的概念

混用的后果：

• • 该写成 Skill 的流程，硬写成脚本 → 一碰判断题就卡住
• • 只是想复用现成能力，却手动接了一堆零散配置

动手试试

今天就写一个最简单的 Skill：

mkdir -p ~/.claude/skills/my-first-skill

创建文件 ~/.claude/skills/my-first-skill/SKILL.md：

---
name: my-first-skill
description: 我的第一个 Skill，列出当前目录下的 Python 文件
---

1. 用 Glob 查找所有 .py 文件
2. 统计文件数量
3. 列出文件名
4. 输出："找到 X 个 Python 文件：" + 文件列表

然后在 Claude Code 里输入 /my-first-skill，看看效果。

从小场景开始，你会发现：把工作方法教给 AI，比每次都亲自做更高效。

小结

对普通人的价值

你可能不会写代码，但你一定有自己的工作方法。

• • 你整理周报有固定的步骤
• • 你审阅文档有自己的标准
• • 你处理某类任务有固定的流程

以前，这些方法只存在于你的脑子里，每次都要亲力亲为。

现在，你可以用自然语言把它们写下来，让 AI 按你的方法执行。

这就是 Skill 的意义：把你的经验变成可复用的资产。

不需要会编程，不需要写脚本，只要把方法说清楚，就能拥有自动化能力。

团队里最会做事的人，把他的方法写成 Skill，所有人都能按这个标准执行。

经验不再只存在于人的脑子里，而可以被保存、被分享、被迭代。