写在前面 这是一篇实操笔记，记录我搞懂 MCP 和 Skill 的过程，以及踩过的坑。上一篇写了 Claude Code 的基础，这篇写怎么让 Claude Code 变得更强。
从一个痛点说起
我每天都在用 Claude Code 写代码、做自动化、管理飞书文档。用着用着就发现一个问题：AI 很聪明，但它记不住事。
每次开新对话，我得重新告诉它——我的项目用什么技术栈、飞书文档怎么操作、代码风格是什么、哪些目录不能碰。说一次管一次，下次从头说。
你可能也有类似的体验：每天早上上班，你得把公司规矩、项目背景、你的工作习惯重新给助理讲一遍。他听完帮你干了一天活，第二天来了，再讲一遍。
这不叫协作，这叫消耗。
后来我搞明白了两个东西：MCP 和 Skill。它们解决的不是同一个问题，但配合起来，能让 AI 从"你问我答"变成"真正住进你的工作流"。
MCP：给 AI 装工具
MCP 全称 Model Context Protocol，翻译过来叫"模型上下文协议"。不用管这个名字，你只需要知道一件事：
MCP 是让 AI 连上外部工具的标准接口。就像 USB 之于电脑。
USB 出现之前，键盘有键盘的接口，鼠标有鼠标的接口，打印机有打印机的接口，每接一个新设备都要搞清楚用什么线。后来有了 USB，一个标准接口，所有设备往上靠，插上就能用。
MCP 对 AI 来说就是 USB。而且它是开放协议，不是 Claude 专属的——Cursor、Codex、Gemini CLI 这些工具都支持。你在一个工具里学会的 MCP，换个工具照样能用。
三个角色
理解 MCP 的工作方式，你只需要认识三个角色：
| 角色 | 类比 | 干什么 |
|---|---|---|
| Client | 你用的 AI 工具（Claude Code、Cursor） | 提需求的人 |
| Server | 外部工具（GitHub、数据库、浏览器） | 干活的人 |
| Tool | 具体能力（截图、查文档、执行 SQL） | 具体的动作 |
你对 AI 说"帮我看看浏览器报了什么错"，AI 就去找 DevTools Server，调用"读取控制台日志"Tool，拿到结果告诉你。你完全感知不到这个过程。
我实际在用的几个 MCP
Context7 — 让 AI 永远查最新文档
你问 AI 某个框架怎么写，它很自信地给你一段代码，你一跑直接报错。因为框架更新太快，AI 学的那版文档早就过期了。更麻烦的是，AI 不会告诉你"我给的可能是旧写法"，它会很自信。
Context7 的做法很直接：AI 回答你之前，先去官方文档查一遍最新内容，拉进来再回答。写代码的时候 Context7 算是必装 MCP。
Chrome DevTools MCP — 让 AI 看见你的浏览器
做网页开发的时候，页面白屏了、样式乱了、接口报错了，以前只能截图贴给 AI。现在 AI 能直接读你浏览器里的 console 报错、network 请求、页面结构。
Playwright MCP — 让 AI 模拟用户操作
跟 DevTools 不一样，这个是用来"动手"的——自动点击、填表、跑登录流程、做自动化测试。
| 工具 | 一句话定位 |
|---|---|
| Chrome DevTools MCP | 调试器——看浏览器内部发生了什么 |
| Playwright MCP | 测试员——模拟用户怎么操作 |
| agent-browser Skill | 轻量操作员——快速截图、简单点击 |
DevTools 用来看，Playwright 用来做，按需选择，不用全装。
Skill：给 AI 写上岗 SOP
MCP 是装工具，Skill 是教方法。
还是那个助理的比方：MCP 是给助理配了一台电脑、装了软件。但光有工具不够，你还得告诉他"遇到这类任务应该怎么做、按什么标准、遵循什么流程"。
Skill 就是你写给 AI 的长期工作说明书。写一次，AI 永久记住。
一个真实的对比实验
同一个需求——“帮我写一个个人博客首页”。
不用 Skill：AI 给你一个能用但很"AI味"的页面——默认蓝白灰、默认字体、默认布局。功能没问题，但看着就像模板。
用了 frontend-design Skill：字体变了、留白变了、颜色有了明确方向、布局不再是最普通的三段式。像是一个有品味的人做的，不是 AI 随手生成的。
唯一的区别，就是启用了一个 Skill。Skill 没有让 AI 更聪明，只是给了 AI 一套明确的审美标准。
Skill 和 Prompt 有什么区别
你可能会问：Prompt 不也能告诉 AI 怎么做吗？为什么要用 Skill？
区别在于：Prompt 是一次性的，Skill 是长期的。
Prompt 是你每次都要说的那句话，说完这次就没了。Skill 是你写好之后，AI 每次遇到相关任务都会自动参考。你不需要每次重新交代。
想象你是一个餐厅老板：
- Prompt 方式：每天早上跟厨师说"今天做这道菜，用这些食材，按这个步骤做"。他做完，明天你再重新说。
- Skill 方式：给他一本菜谱。他来上班直接看菜谱，按照菜谱做。
Skill 就是那本菜谱。
Skill 和 Rule（规则）有什么区别
Claude Code 里还有一个东西叫"规则"（Rules）。
- 规则是全量加载的——不管 AI 在做什么任务，那条规则都一直占着位置。适合"任何时候都必须遵守"的事，比如"永远用中文回答"。
- Skill 是按需加载的——AI 先扫一眼每个 Skill 的名字和简介，判断当前任务跟哪个相关，才加载详细内容。适合"特定场景下的专业规范"。
| 类型 | 加载方式 | 适合 |
|---|---|---|
| Rule | 始终加载 | 铁律：“永远不要修改生产数据库” |
| Skill | 按需加载 | 专项：“做前端页面时遵循这套设计规范” |
Skill 的核心价值
是稳定性。
你用 AI 写代码最大的痛点是什么？不是 AI 不会写，而是写得不稳定。有时候很好，有时候随便发挥，有时候绕过了你的规范。
根本原因是 AI 在没有明确约束的情况下有太多自由度。每次都在"猜"你想要什么。你把规范写进 Skill，AI 就不用猜了。
但注意：一个 Skill 只做一件事。 很多人第一次写恨不得把所有要求塞进去，结果 Skill 太复杂反而不好使。三个不同类型的规范，就写三个 Skill。
我踩过的坑：两个工具不共用配置
这部分是我在实操中发现的，网上很少有文章讲。
我同时用 Claude Code 和 Codex 两个工具。有一天发现：给 Claude Code 装的 Skill，Codex 完全看不到。给 Codex 配的 MCP，Claude Code 也用不了。
它们是两套完全独立的系统。 配置目录不一样、Skill 存放位置不一样、MCP 配置方式不一样。你以为装了一次两边都有了？并没有。
更坑的是 Codex 的 Skill 识别：我一开始只在 Codex 的配置文件 config.toml 里加了 Skill 路径，结果 Codex 根本没识别。后来在 ~/.codex/skills/ 下建了个软链接，它才终于看到了。
我的解决方案：公共 Skill 目录
既然两边不共享，那我就让它们共享。
建了一个公共目录，所有自定义 Skill 的原件只维护一份。然后两边用软链接去引用：
公共目录/<skill-name>/SKILL.md ← 唯一原件
~/.claude/skills/<skill-name> → 软链接到原件
~/.codex/skills/<skill-name> → 软链接到原件
改一处，两边都生效。不用在两个地方各维护一份。听起来很简单，但我确实花了一个下午才摸清楚。
还有一件事：权限列表会越来越长
Claude Code 每次想执行操作，默认都会弹确认框让你点"允许"。你可以选：
- Allow（仅本次）：这次放行，下次还问
- Always allow：写进配置文件，以后永远不问
我一开始不管什么都点 Always allow，结果一个月下来，配置文件里攒了 93 条权限。其中 60 多条是一次性的 mv、cp、git 命令，执行过一次再也不会用了。
后来清理了一遍，保留了 30 条。规则很简单：
一次性操作点"仅本次"，确定会反复用的才点"Always allow"。
MCP + Skill，不是非此即彼
MCP 和 Skill 不是替代关系，是配合关系。
MCP 给 AI 装工具，Skill 教 AI 用工具的方法。
- 只用 MCP——AI 有工具但没有规范，每次发挥不稳定
- 只用 Skill——AI 有方法但没有工具，有些事做不到
- 两者配合——工具 + 方法，能力 + 规范
写在最后
我现在的 AI 工作流是这样的：
- 每天用 Claude Code 跑 PPT 生产线
- MCP 连接飞书、浏览器、最新文档
- Skill 告诉 AI 怎么写文案、怎么审查代码、怎么设计界面
- 所有自定义 Skill 统一维护在一个目录，两边工具通过软链接使用
- 一次性权限不再攒，保持配置干净
工具不是越多越好。遇到问题再找插头，这是我今年学到最重要的一课。