你有没有遇到过这种情况：每次让 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.mdSKILL.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. 主文件短：只写目标、顺序、判断和交付 2. 资料分散：大段内容放到 examples.md、template.md，需要时再加载3. 关键操作手动触发：会改远端资源的动作，默认加上 disable-model-invocation: true
SKILL.md 负责告诉 Claude "这类事该怎么做"，不负责替项目 wiki 兜底。
不好的写法
• 把所有背景资料一次性塞进去 • 每条都像规定，但轻重缓急不分 • 没有交付格式 • 没有判断标准
结果：Claude 每次都能做一点，但每次做出来都不太一样。
更好的写法
文件结构清晰：
.claude/
skills/
release-note/
SKILL.md
examples.md
template.mdSKILL.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-officialPlugin 把 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。这样更顺。
几个容易混的概念
| 脚本 | |
| Hook | |
| Plugin | |
| Skill |
混用的后果：
• 该写成 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，所有人都能按这个标准执行。
经验不再只存在于人的脑子里，而可以被保存、被分享、被迭代。
