Post

要不要用 Skills 和 MCP？

Posted Updated
By Toby Qin
19 min read
要不要用 Skills 和 MCP？

2025 年的 AI 圈，概念造词的速度似乎比模型迭代的速度还要快。

Anthropic 最近推出的 Skills 和之前的 MCP 反复引爆了开发者社区。大家都在问：我们要不要重构代码适配 MCP？是不是把 Prompt 改成 Skills 效果就会变好？

这种焦虑大多是多余的。

在决定要不要用之前，我们需要先完成一次祛魅：剥离掉精美的 PPT 和营销话术，把它们还原成计算机工程里的“可实现物”。

只有看清本质，你才能判断它们是在解决真问题，还是在制造新麻烦。

它们到底是什么？

别被新名词吓倒，它们都是你熟悉的老朋友，只是换了身新衣服。

1. Skills 的本质：标准化的 SOP 挂载包（可检索、可组合、可版本化）

Anthropic 宣传 Skills 是可定制的专业能力。

实质上，Skills 更接近：Prompt 工程 + RAG/检索 + 懒加载 + 组织化的“流程包”。

以前，你把如何写 Python 代码的 50 条规则全塞进 System Prompt，导致上下文爆炸，模型注意力被稀释。

现在，Skills 让你把这 50 条规则写成文件放在文件夹里。模型先只看目录，当你问 Python 问题时，它才把规则加载进来。

它解决的核心问题是：如何在有限的上下文窗口里，塞入无限的企业业务流程。

但更关键的是：它把“散装提示词”变成了工程资产。

  • 可版本化：像代码一样做 review、diff、回滚。
  • 可组合：把“代码规范 + 安全审计 + 输出格式”拆成可叠加的模块。
  • 可治理：知道某次输出是加载了哪些规则（至少理论上可以追踪）。
一个更工程化的 Skills 范例

你可以把 Skills 当作一个“只给模型看的 SOP 仓库”。比如一个面向研发团队的 python_pr_review：

1
2
3
4
5
6
7
8

skills/
  python_pr_review/
    manifest.md
    rules.md
    checklist.md
    examples/
      good.md
      bad.md

manifest.md（目录页，类似索引/路由）：

1
2
3
4
5
6
7
8
9
10

# Skill: python_pr_review

When to load:
- user asks for code review / PR review
- user asks for Python best practices

Outputs:
- Summary
- Risk list (security, correctness, performance)
- Actionable suggestions with patch-style snippets

rules.md（规则，尽量“可判定”）：

1
2
3
4
5
6
7
8

## Must
1. Do not suggest insecure `eval()`.
2. Ensure exceptions are not swallowed silently.
3. Prefer `pathlib` over string path.

## Should
1. Add type hints for public functions.
2. Complexity: keep cyclomatic complexity under 10 unless justified.

examples/bad.md（反例比“抽象规则”更有效）：

1
2
3
4
5

def load(x):
    try:
        return eval(x)
    except:
        return None

这个结构的价值不在于“新格式”，而在于：你终于能把隐性经验（review 习惯、输出结构、风险偏好）从人的脑子里搬到一个可维护的仓库里。

2. MCP 的本质：通用的 USB 接口标准（让工具“像硬件外设一样可插拔”）

Anthropic 宣传 MCP 是连接 AI 与数据的通用标准。

实质上，MCP 是一种偏工程化的工具/资源协议：你可以把它理解成“用一套约定好的 RPC 规范去描述 tools、resources、prompts”等能力。

从技术形态上看，它很像 OpenAPI、JSON-RPC、gRPC、插件协议的同类：关键不在于“RPC 用什么格式”，而在于让客户端和服务端解耦。

以前，你要让 Claude 查数据库，你得写一段 Python 代码定义 Tool，然后还要写胶水代码去连数据库。换个模型，比如 GPT-4，你可能得重写一遍 Tool 定义。

现在，MCP 试图定义一种标准：只要数据库端支持 MCP，任何模型都能直接连上去，就像 USB 鼠标插哪台电脑都能用。

它解决的核心问题是：N 个模型与 M 个数据源之间的适配复杂度，从 N 乘 M 降低到 N 加 M。

一个 MCP 范例：把“公司知识库查询”做成可插拔服务

假设你有一个内部知识库（Confluence/Notion/自建 Wiki 都行），你希望：Claude、ChatGPT、Cursor 甚至未来别的 Agent，都能复用同一套“查询能力”。

没有 MCP 时，你可能会在每个客户端里实现：鉴权、分页、重试、限流、query DSL、数据脱敏、审计日志……这就是 N×M 的痛苦。

有 MCP 时，你把这些能力收敛到一个 kb-mcp-server：

  • 客户端只需要“会讲 MCP 这门语言”
  • 服务端负责把你们内部系统的复杂性吞掉
  • 安全、审计、缓存、数据脱敏都在服务端统一做

从团队协作角度，MCP 真正的收益是：把“工具接入”从应用代码里挪到平台层。

你真的需要它们吗？

技术选型不是追星，而是计算 ROI。请对照以下清单进行自我审视。

1. 关于 Skills：你的痛点是记不住还是装不下？

什么时候该用 Skills？

你的 SOP 极其复杂。你有几十页的编码规范、审计流程或品牌文案指南。全塞进去模型会晕，不塞进去模型会乱。Skills 的按需加载是绝佳解药。

团队协作需要统一。你希望团队里 100 个开发者用 Claude 时，都遵循同一套最佳实践。Skills 可以像代码库一样分发配置。

你需要人设切换。同一个 Bot 既要当客服又要当运维。Skills 可以让它动态切换知识库，防止知识串扰。

你需要可复现实验。你已经在做 Prompt A/B test、离线评测，想知道“这次效果提升，是不是因为我改了第 17 条规则”。Skills 把提示词变成可追踪、可评审的资产，更容易做评测闭环。

什么时候别折腾 Skills？

任务很简单。你的 System Prompt 只有几百个 Token。直接写在 Prompt 里效果最好，强行拆成 Skills 增加了检索的不确定性，有可能该加载的时候没加载。

迷信魔法。你以为用了 Skills 模型就会变聪明。不会的。如果你的 Prompt 逻辑本身是混乱的，把它存成 Skills 只会得到一个结构化的混乱。垃圾进，垃圾出定律依然有效。

你没有维护能力。Skills 一旦进入生产，就会变成“制度”：需要 owner、更新节奏、review 机制、过期策略。没有维护流程的 Skills，会比没有 Skills 更糟，因为它会以“权威口吻”输出过时结论。

2. 关于 MCP：你是想造车还是修路？

什么时候该用 MCP？

你有异构的数据孤岛。你需要让 AI 同时访问本地文件、Slack 记录、PostgreSQL 和 GitHub。MCP 提供了一套统一的接入范式，比你手写 4 个不同的 API Client 要优雅。

你相信生态的未来。你赌 Anthropic 能把 MCP 做成行业标准。一旦成功，未来社区会有成千上万现成的 MCP Server，比如 Notion MCP、Jira MCP，你直接拿来用即可。

你想把“工具能力”平台化。多个团队都在做类似接入：权限、审计、脱敏、缓存、配额、限流、观察性。MCP 让你把这些横切能力集中到一层去做，而不是在每个 Agent/客户端里复制粘贴。

什么时候别折腾 MCP？

你只需要调一个 API。你只是想让 AI 查一下天气。写一个简单的 Function Calling 只需要 10 行代码。为了这个去部署一套 MCP Server 是典型的大炮打蚊子。

你担心被绑定。MCP 目前主要是 Anthropic 在推。如果明年 OpenAI 搞了个 OCP，Google 搞了个 GCP，你的代码就白写了。在标准未定之前，简单的 REST API 才是最通用的标准。

你没有“平台化”的预算。MCP 的隐性成本通常不在代码，而在：部署、密钥管理、网络拓扑、访问控制、审计、告警、版本兼容、灰度发布。这些东西对成熟平台是日常，对小团队是负担。

一个更现实的判断标准：你是否真的存在 N×M？
  • 如果只有 1 个模型 + 1 个数据源：直接 Function Calling / REST API。
  • 如果有 2-3 个模型 + 2-3 个核心系统：开始出现重复劳动，MCP 值得试点。
  • 如果你在做“企业级 AI 平台”：MCP 的价值不在“连接能力”，而在“治理能力”。

技术落地的核心：形式只是表面，治理与数据才是灵魂

无论你选择 Skills 还是 MCP，在做技术落地时，请务必清醒地认识到：工具和协议只是外壳，真正决定效果的通常是两件事：

1) 你喂给 AI 的数据质量（正确、完整、及时、可追溯）

2) 你的工程治理能力（评测、权限、审计、可观测、回滚）

1. 上下文管理的死穴依然存在

Skills 依赖匹配算法来决定加载哪个技能。

召回率问题。如果你的 Skill 描述写得不准，AI 在该用这个 Skill 的时候没用，结果就是灾难性的。

Skills 腐烂。代码库更新了，但作为文档存在的 Skills 没更新。AI 会一本正经地按照旧流程执行错误操作。维护 Skills 的成本，比维护代码还要高。

更隐蔽的问题是冲突：多个 Skills 同时加载时，规则可能互相打架。

  • A 说“输出要简短”，B 说“输出要完整”，模型会随机选择“看起来更顺眼”的那条。
  • A 说“允许改动架构”，B 说“只做最小变更”，你得到的是不可控的折中。

解决冲突不是靠“再写一条规则”，而是靠工程手段：

  • 规则优先级（强制/建议/可选）
  • scope（对哪些文件/场景生效）
  • 评测集（把冲突暴露出来）

2. 接口的安全性与延迟

MCP 让连接变得容易，也让风险变得容易。

权限失控。当你把本地文件系统的 MCP 开放给 AI，你实际上是在裸奔。如果 AI 被注入攻击，它可能读取你的敏感文件。

链路延迟。MCP 是基于 JSON-RPC 的，多了一层封装和通信，对于实时性要求极高的场景，这可能是瓶颈。

还要补上一个经常被忽略的点：可审计性。

当 AI 能调用越来越多的工具时，事故不是“会不会发生”，而是“什么时候发生”。你至少需要：

  • 谁在什么时候通过 AI 触发了什么工具调用
  • 传了哪些参数、返回了什么（脱敏后）
  • 是否命中了敏感操作（删库、转账、发公告）

如果你没有这套日志与告警体系，MCP 只会把风险放大。

你应该把 MCP 当作“生产系统接入层”来做

工程上，一个能进生产的 MCP Server，往往需要接近 API Gateway 的能力：

  • 认证鉴权（细粒度到 tool / resource / tenant）
  • 限流与配额（防止被模型循环调用打爆）
  • 缓存（降低成本与延迟）
  • 超时/重试/幂等（否则你会在边缘 case 里崩溃）
  • 变更管理（版本兼容、灰度、回滚）

一个更“落地”的实践路线：先做评测，再做封装

如果你想让读者带走一个能直接用的框架，我建议是这条路线：

  1. 先定义成功标准：什么叫“效果更好”？准确率？节省时间？减少事故？
  2. 建立最小评测集：选 20-50 个真实任务（最好包含失败样本），做离线回放。
  3. 先把 Prompt 写好：不靠 Skills/MCP 也能 work。
  4. 再决定要不要工程化：
    • Prompt 太大、角色太多、版本太乱 → 用 Skills 做资产化
    • 数据源太多、权限审计难、重复接入多 → 用 MCP 做平台化

这样做的好处是：你在“可测量”的基础上引入复杂性，而不是为了新概念引入复杂性。

结论：做架构师，不做收藏家

不要因为 Anthropic 发布了新功能，就觉得手里的工具落后了。

Skills 只是 RAG 的一种工程化封装，用于解决上下文过载。

MCP 只是 API 的一种标准化封装，用于解决集成复杂度。

建议从小处着手。不要上来就搞全公司 MCP 化。先在一个具体的、痛点明显的场景（比如复杂的财务报表生成、PR Review 自动化、客服工单归因），尝试 Skills 或 MCP 的其中一个。

关注内容。花 80% 的时间去打磨你的 Prompt 内容和业务流程，只花 20% 的时间在配置 Skills 和 MCP 的格式上。好的 Prompt 放在 txt 里也是好的，烂的 Prompt 放在 Skills 里还是烂的。

保持独立。尽量保持你的业务逻辑与特定厂商的协议解耦。今天用 MCP，明天也许就要切回 Function Calling。架构的灵活性比单一技术的先进性更重要。

最终，我们要的是解决问题，而不是集齐所有的技术名词。

Tech
ai
This post is licensed under CC BY 4.0 by the author.