Skill、Slash Command、MCP 到底怎么选？我画了张 3 轴决策图

先说个真事。

上个月有个做 SaaS 的客户找过来，说他们的 Claude Code 一打开就慢得要命，首次响应要 7 秒多。我让他把 system prompt 的 token 数贴给我——34,218。我当时就懵了。

打开一看，他们把公司内部的 12 个工具全写成了 Skill：JIRA 创建工单、Sentry 查错误、Datadog 拉指标、Slack 发通知……每个 Skill 都是大几千 token，加起来就这么多。问他们为啥这么做，回答是「官方文档里 Skill 最简单」。

这是典型的用错了。折腾了两天，我帮他们把 8 个 Skill 改造成一个 MCP server，system prompt 瞬间降到 4.2K，首次响应 1.1 秒。

所以今天想把这件事说透。

本质差异到底在哪

Skill、自定义 Slash Command、MCP tool 这三兄弟，官方文档经常混着讲，但它们不是一个层级的东西。

Skill 是 prompt 级扩展。本质是你提前写好一段指导性文字，打包成 frontmatter + markdown，放在 .claude/skills/ 下。agent 根据任务描述自动触发，把 Skill 正文拼进 context。它给 LLM 的是知识——你告诉它「遇到这种情况应该这么想、这么做」。

Slash Command 是交互级扩展。本质是你定义一个快捷短语（比如 /review-pr），用户敲这个短语时，Claude Code 把你预设的 prompt 模板展开，塞入 $ARGUMENTS 参数。它给用户的是入口——让高频操作有个固定的触发口。关于 slash command 的写法我之前讲过 slash command 的 5 条设计原则。

MCP tool 是能力级扩展。本质是一个独立进程，通过标准协议暴露一组函数。agent 需要时才调用，调完拿到结构化结果。它给 LLM 的是手脚——让它能真正执行动作、访问数据。

我画成一张表就清楚了：

看到没，「常驻 context」这一列就解释了上面那个客户的问题——Skill 越多，context 越肿。

3 轴决策图

我给这事儿画过 8 个版本的决策图，最后稳定下来的是 3 轴：

第一轴：知识 vs 能力。你要给 LLM 补的是「该怎么想」还是「该怎么做」？前者选 Skill，后者选 MCP。

第二轴：个人 vs 团队。这东西只有你一个人用，还是整个团队甚至跨团队共用？个人用、临时用，Slash command 或者本地 Skill 最省事；团队共用、跨项目复用，MCP server 部署一套大家连就行。

第三轴：静态 vs 动态。触发之后的行为是每次都一样（静态），还是要根据实时数据变化（动态）？静态用 Skill，动态必须 MCP。

这三轴组合起来，大部分场景能一眼判断。比如「全公司统一的 SQL 风格规范」——知识 + 团队 + 静态 → Skill（上传到共享仓库）。「线上事故时查 Datadog」——能力 + 团队 + 动态 → MCP。「本地快速跑单测」——能力 + 个人 + 动态，但用户主动触发 → Slash command 包一个 bash。

9 个实战例子到底该用哪种

把最近半年我接触的场景整理了一下：

1. 代码 review 的通用准则（比如「函数超过 80 行要警告」）→ Skill。就是一段 rule，不需要调用外部。
2. 生成符合公司风格的 SQL（知道 schema、join 习惯、命名规范）→ Skill。静态知识，跟 品牌文案 Skill 思路完全一样。
3. 查 Snowflake 里的实时数据 → MCP。动态能力，必须能连数据库。
4. 事故响应 runbook（「支付挂了按这个步骤排查」）→ Skill 为主 + 内嵌 MCP 调用。知识是 Skill，但里面可能让 agent 去调 MCP 查日志。
5. 生成 PR 描述 → Slash command（/pr-desc）。用户敲命令 + diff 传进去就行。
6. 拉 Jira 工单信息 → MCP。要实时数据。
7. 公司架构图的说明（「我们的服务之间怎么调的」）→ Skill。文档性知识。
8. 跑内部 E2E 测试套件 → Slash command 包 subprocess。用户主动触发。
9. 合规检查（「这段代码有没有写死密钥」）→ Skill（正则 + 说明）+ MCP（调 secrets 扫描服务）。两者配合。

看出规律没？知识类全是 Skill，动态能力全是 MCP，用户高频触发的快捷键全是 Slash。

那个 8 个 Skill 改 MCP 的故事

回到开头那个客户。他们原来的 8 个 Skill 分别是：JIRA 创单、JIRA 查单、Sentry 查错误、Sentry 标已处理、Datadog 拉指标、Datadog 建告警、Slack 发消息、Slack 查消息历史。

每个 Skill 正文平均 3,800 token，8 个加起来 30K+。而且最要命的是——这些 Skill 的正文本质上是在教 LLM 怎么拼 HTTP 请求。比如 Sentry 那个 Skill 里写了「POST 到 /api/0/projects/xxx/issues/，header 要带 Authorization，body 字段是……」整整 4,200 字。

这根本不该是 Skill 干的事。

改成 MCP 之后，LLM 看到的只有 tool schema（每个 tool 不到 200 token），8 个 tool 加起来 1.5K。剩下 2.7K 留给一个薄薄的 Skill，讲「我们团队用这些工具的偏好」（比如默认 query 最近 24 小时、Slack 频道用 #ops-alerts）。这才是 Skill 该干的——放偏好，不放实现。

数字对比：context 从 34,218 降到 4,183，首次响应从 7.2 秒到 1.1 秒，月度 API 成本降了 58.7%。

MCP 的搭建这块我之前写过一篇详细的，也讲了为什么 tool schema 比 Skill 正文省 token。

新手最常见的两种误用

把 Skill 当 MCP 用：在 Skill 里写一堆 curl 命令让 LLM 自己拼接。这会有三个问题——context 浪费、LLM 拼错参数时没法验证、每次都重新读。我见过最夸张的一个 Skill 里直接写了 SQL 语句让 LLM 填变量，结果 LLM 把 SQL 改坏了。

把 MCP 当 Skill 用：做一个 tool 叫 get_coding_style_guide，返回一段 5KB 的 markdown。这等于每次都要跨进程调一次拿一段不变的文本，延迟高、浪费 tool call。不如直接写成 Skill。

判断标准其实很简单：返回值会不会变？会变，MCP；不会变，Skill。

一个混合的进阶案例

最近给一个金融客户做的。他们的需求是：每个 PR 自动做合规审查。

最后的结构：

• 一个 Slash command /compliance-check 作为入口，用户在 PR 里 @Claude 触发。
• 一个 Skill compliance-rules 写清楚团队所有合规红线（这是静态知识）。
• 一个 MCP server 暴露 3 个 tool：scan_secrets、check_license、get_pii_risk_score（都是动态能力）。

Claude Code 看到 slash command 触发后，自动加载 Skill（知识），按需调用 MCP（能力），最后输出审查结果。

这三样东西的职责分得清清楚楚——Skill 管知识、Slash 管入口、MCP 管能力。一旦职责边界明确，整个系统就好维护。反之如果混着用，改一个地方要查三个地方，出问题都不知道是哪层的锅。

小结

我知道文档里写 Skill 最简单，所以很多人一上手就只用 Skill。但一个工程师用到第三个月以上就会发现：能力不该塞进 Skill，知识不该做成 tool。早点分清楚，后面少痛苦很多。