MCP过气了？聊聊它和Skill到底怎么选

最近在技术圈溜达，发现一个挺有意思的讨论趋势——MCP（Model Context Protocol）是不是已经在淘汰边缘了？

有小伙伴发问：既然现在Skill方案越来越火，加上CLI工具的配合，是不是Skill就能完全把MCP给取代了？之前我也属于拿来主义，给什么用什么，但今天特意补了一下课，发现这里面还真有不少门道。

今天就来拆解一下，为什么大家会有这种“MCP要凉”的感觉，以及在实际开发中，这两者到底该怎么选。

1. 为什么大家觉得MCP要被取代？

这种感觉主要来自于上手门槛和实施成本。

做MCP通常需要搭建一套标准化的服务端环境，配置传输协议，还得适配不同模型的上下文。对于很多只想快速搞定一个小功能的开发者来说，这简直是杀鸡用牛刀。

反观Skill，特别是结合CLI（命令行）的玩法，显得特别“轻量”。

你只要写个简单的脚本或者工具，通过Skill的接口一调，模型就能直接执行。这种**“脚本即插件”**的直观感觉，确实让人觉得MCP那种繁琐的协议层有点多余。

2. 本质定位不同：协议 vs 能力

虽然看起来都能干活，但两者的底层逻辑其实不一样。

MCP：偏向标准化的“翻译官”

MCP的核心在于Context Protocol。它的目的是解决模型与外部工具之间“语言不通”的问题。它定义了一套标准，让AI能理解如何去获取数据、如何去操作工具。

• 优点：标准化程度高，生态互通性好。如果你希望你的工具能被各种不同的AI前端通用地调用，MCP是正解。
• 缺点：协议繁琐，为了通用性牺牲了一定的开发效率。

Skill：偏向具体的“手艺人”

Skill更像是一种封装后的能力包。它不关心底下的协议怎么走，只关心把特定的功能打磨好，直接喂给模型用。

• 优点：开发极快，特定场景下效率极高，特别是配合本地CLI工具时，几乎是零成本接入。
• 缺点：缺乏统一标准，换个环境可能就不灵了，复用性不如MCP。

3. 实操对比：真的可以互相替代吗？

回到最原始的问题：能不能用 Skill + CLI 代替 MCP？

在单点应用和个人工作流中，答案是：完全可以。

比如你想让AI帮你查一下本地文件，或者跑一段Python脚本。用Skill包一层，直接调用命令行，比搭一个MCP服务器要快得多，也轻盈得多。这种情况下，MCP确实显得有点“重”了。

但在复杂生态和多平台协作中，MCP依然不可替代。

如果你正在开发一个需要被广泛集成的工具，或者你的工具需要处理复杂的上下文切换和权限控制，MCP的结构化优势就出来了。它能帮你处理好很多脏活累活（如数据格式转换、连接管理），而Skill在这方面往往需要开发者自己去造轮子。

4. 避坑指南：到底该怎么选？

别被概念绕晕了，直接看需求：

• 选 MCP，如果：

  • 你在做通用型工具，希望别人能轻松集成。
  • 场景复杂，涉及多个系统间的数据流转和权限控制。
  • 团队协作，需要统一的技术标准来维护。

• 选 Skill + CLI，如果：

  • 你只是在解决自己的个性化需求，或者写个自动化小脚本。
  • 追求极致的开发速度和部署轻量化。
  • 不需要考虑跨平台的通用性，只求在当前环境下跑通就行。

5. 总结

MCP并没有被淘汰，它只是从“万金油”回归到了它该在的位置——基础设施建设。

而 Skill + CLI 的崛起，代表了另一种敏捷开发的思路。两者并不是你死我活的关系，更像是重型坦克和轻型突击车的区别。

以后别再纠结谁取代谁了，手里有什么活，就选什么工具。能解决问题的，就是好技术。