2024 年底，一个叫 MCP 的东西发布了。它的目标很大：让 AI 能连接任何外部工具。代码托管、项目管理、文档协作、即时通讯——全打通。媒体给它起了个外号，叫"AI 世界的 USB-C"。
听起来很美好。一个接口统一所有工具，就像 USB-C 统一了充电线一样。
但一年半过去了，真正每天在用的开发者，态度发生了变化。不是因为 MCP 没用，而是它在实际工作中的表现，跟宣传差得太远。
这篇文章聊聊 MCP 到底出了什么问题，以及为什么很多人开始用回一种更老、更简单的方式——命令行。
先说清楚几个概念
在讲问题之前，需要先解释几个词。不懂技术的读者可以跳过这段，后面用到的时候会再解释。
LLM：就是 ChatGPT、Claude、通义千问、豆包这类 AI。你可以把它理解成一个特别聪明的文字处理器，但它有一个致命限制——它的"记忆"是有限的。这个限制叫上下文窗口。
上下文窗口：AI 一次能"看到"的信息总量。想象你面前有一张桌子，桌子的大小是固定的。你能在桌上放多少东西，决定了你能同时处理多少信息。桌子越大，AI 能做的事越多。
Token：衡量桌上空间的单位。一个中文字大约占 1-2 个 token。桌子（上下文窗口）总共能放 20 万个 token，听起来很多，但光是跟 AI 说几句话就要用掉好几千。
CLI：命令行界面。就是你在电脑上打开那个黑底白字的窗口，用打字的方式操作电脑。比如输入 ls 看文件列表，输入 git push 上传代码。开发者天天用，AI 也会用。
MCP：Model Context Protocol。它是 AI 和外部工具之间的"翻译官"。你想让 AI 操作飞书项目，MCP 服务器就在中间帮你们传话。
好，概念说完了。下面讲 MCP 的问题。
问题一：AI 的桌子被菜单占满了
这是最直观的问题。
想象你去一家餐厅吃饭。坐下来之后，服务员在你桌上铺了 10 本菜单——中文菜单、英文菜单、酒水单、甜品单、儿童套餐、素食菜单……你说了"我就点个炒饭"，但那 10 本菜单还是占着桌子。你的菜端上来都没地方放。
MCP 就是那 10 本菜单。
当你给 AI 连上一个 MCP 服务器，这个服务器会告诉 AI："我有 42 个工具可以用哦。"然后它会把这 42 个工具的详细说明书全部铺在 AI 的桌子上——不管你会不会用到它们。
海外工程团队 Quandri 做过一个测试。他们连了 4 个 MCP 服务器（项目管理、文档协作、即时通讯、数据库），一共 77 个工具。光是这些工具的说明书，就占了 AI 桌子的 10.5%。国内主流办公工具的 MCP 规模相近，问题也是类似的。
10.5% 是什么概念？AI 的桌子总共能放 20 万个 token，这些说明书占了 2.1 万个。还没开始干活，桌子就少了十分之一。
其中项目管理工具一个 MCP 就占了 1.28 万个 token——因为它塞了 42 个工具的说明。你可能只用其中两个：查一下任务、保存一下任务。但另外 40 个工具的说明书，一直躺在桌上。
更扎心的是：桌子越小，影响越大。如果你用的是上下文窗口更小的模型，这个比例会被进一步放大。
问题二：翻译官经常掉链子
MCP 的架构是这样的：AI 不直接跟外部工具说话，而是通过一个"翻译官"（MCP 服务器）传话。这个翻译官是一个独立运行的程序。
问题就出在这个翻译官身上。
启动慢。翻译官每次上班都要先换衣服、泡咖啡。MCP 服务器初始化需要时间，第一次用的时候尤其慢。有人测试过，同样是查一个工单，MCP 首次调用比直接调接口慢了一个数量级。
容易挂。翻译官在工作中途突然晕倒了——MCP 服务器进程崩溃。你正在跟 AI 聊得好好的，突然工具就不能用了。
每句话都要翻译。就算翻译官没挂，每次 AI 想用工具，消息都要先发给翻译官，翻译官再转发给工具，工具回复翻译官，翻译官再回复 AI。多了一道手续，每次都慢。测试显示，MCP 每次调用都明显慢于直接调接口。
权限说不清。你不知道翻译官到底能帮你做什么。它有哪些权限？能读什么、改什么？MCP 的权限模型不透明，开发者经常搞不清楚。
问题三：翻译官做的事，打字就能解决
这是最根本的问题：MCP 解决的问题，命令行早就解决了。
举个例子。你想让 AI 查一个飞书项目上工单的状态。有两种方式：
方式 A：用 MCP。AI 先加载项目工具的 42 个工具说明（占掉 1.28 万个 token），然后调用"查工单"工具，MCP 服务器帮你转发请求，拿到结果，再返回给 AI。
方式 B：用命令行。AI 直接输入一条命令：
curl -s -H "Authorization: Bearer 你的密钥" \ -H "Content-Type: application/json" \ -d '{"query":"{ issue(id: \"工单号\") { title state { name } } }"}' \ https://api.feishu.cn/project/graphql方式 B 不需要加载任何工具说明，不需要翻译官，不需要启动额外的程序。一条命令，直接拿到结果。
你可能会问：密钥直接写在命令里，安全吗？当然不。实际使用时，密钥通过环境变量或密钥管理器传入，不会出现在命令里。这不是 MCP 的专利，命令行一样能做到。
token 开销呢？方式 A 占 1.28 万个 token（工具说明）加上 150 个 token（调用和结果）。方式 B 只占 200 个 token（命令加结果）。同样的事，MCP 消耗的资源是命令行的 65 倍。
而且命令行还有一个天然优势：AI 本来就会用。它在训练的时候，已经从无数的技术文档、问答网站里学会了 curl、git、psql 这些工具。你不需要教它，它已经会了。
命令行的调试也方便。出了问题，你自己在终端里输入同样的命令就能复现。MCP 出了问题，你只能在 AI 对话里反复尝试，很难排查。
有人真的从 MCP 换到 CLI 了吗？
有。Quandri 团队分享过一组对比数据。
以下是基于同类场景的测算示意：同一个任务——查项目管理工具上的本周 bug 清单，汇总后发到通讯群——用 MCP 方案时，上下文峰值占用 1.8 万 token，总耗时 23 秒，中间失败重试了 2 次。换成 CLI 加本地脚本之后，token 占用不到 2000，耗时 7 秒，零失败。
他们的工程师说了一句很直接的话："MCP 像一个讲究的餐厅，而 CLI 是外卖窗口——更快，更简单。"
国内大厂怎么选的？
有意思的是，国内三大协作平台走上了完全不同的路。
2026 年 3 月，飞书开源了自己的 CLI 工具，首日 GitHub Star 超过 1000。它提供了超过 200 条命令，覆盖 19 种核心能力，全部走命令行。钉钉更早一步，2025 年底就推出了"MCP 广场"，首批开放 6000 多个能力，把 MCP 做成平台化。企业微信紧随其后，2026 年 3 月底开源 CLI，开放 7 大核心能力。
三条路，三种选择：
| 平台 | 路径 | Token 开销 | 安全机制 |
|---|---|---|---|
| 飞书 | CLI + Skill（开源 MIT） | 低，按需加载 | API 调用，可控 |
| 钉钉 | CLI + MCP 广场（平台化） | 中 | 提供 --dry-run 安全预览 |
| 企业微信 | CLI（开源） | 低 | Bot ID + Secret 认证 |
飞书和企业微信都选了 CLI 优先。钉钉选了 MCP 平台化。这不是谁对谁错的问题，而是说明了一件事：CLI 不是一个过时的选择，它正在成为主流选项之一。
那不用 MCP 用什么？
答案是一个更聪明的组合：命令行 + Skill。
命令行解决"怎么用工具"的问题。Skill 解决"什么时候加载"的问题。
什么是 Skill？继续用餐厅的比喻。MCP 是一进门就把所有菜单摊在桌上。Skill 是你跟服务员说"我要看炒饭"，服务员只把炒饭那一页拿给你。
Skill 不是什么新协议，也不是一个新平台。它就是一个文本文件，里面写清楚"当用户问某类问题时，AI 应该执行哪条命令行"。
比如一个 feishu-project.skill 文件的内容可能是：
如果用户要查工单，执行：curl -X POST https://api.feishu.cn/project/graphql ...
如果用户要创建工单，执行：curl -X POST ...
结果是 JSON 格式，用 jq 解析。
AI 只有在用户真的提到"飞书项目工单"的时候，才会去读这个文件。用完即丢，不占常驻空间。
这种方式的好处：
按需加载。你需要查飞书项目，才加载飞书项目的说明。不需要的时候，桌子干干净净。
省资源。因为只加载需要的部分，上下文占用比 MCP 少得多。
扩展性好。加 100 个 Skill，平时不用就不占空间。MCP 每加一个服务器，桌子就少一块。
人和 AI 用同一套。命令行就是命令行，你在终端里能用，AI 也能用。出了问题，你直接在终端里调试，不用猜 AI 到底做了什么。
有一个例外：数据库
数据库的情况稍微特殊一点。
从功能上说，AI 完全可以直接用命令行操作数据库。它懂 SQL，给它表结构就能写查询。本地开发的时候，用命令行就行。
但如果你连的是生产环境的数据库——线上正在运行的、客户数据都在里面的——情况就不一样了。
命令行有一个危险：AI 输入什么，数据库就执行什么。如果 AI 不小心写了个 DROP TABLE users，那就真的删了。命令行不会拦它。
MCP 服务器可以充当一个"安全员"。它可以在中间拦截危险操作，强制只读模式，记录所有查询。生产环境需要这种保护。
所以数据库的建议是：本地开发用命令行，生产环境用 MCP。
MCP 不是没用，只是大部分场景不需要
MCP 在几种情况下仍然有价值：
没有命令行接口的服务。有些 SaaS 产品只有网页版，没有提供命令行工具。MCP 可能是唯一的连接方式。
不用命令行的人。产品经理、设计师、运营——这些人不碰终端，MCP 对他们来说更友好。
需要实时双向通信的场景。比如 AI 需要持续监听飞书消息的变化，这种超出简单请求-响应的场景，MCP 更合适。
但对于大多数开发者日常在做的事情——查代码、管工单、跑测试、操作数据库——MCP 是过度设计。
现在的行情是，每家 SaaS 公司的官网都写着"支持 MCP"。至于这个 MCP 服务器稳不稳、吃多少资源，没人关心。重要的是在功能清单上打个勾。跟几年前"AI 驱动""区块链赋能"一个路子。用户真连上去之后，面对的是几十个用不到的工具定义、反复的初始化失败、和说崩就崩的服务器。
结论
至少在 2026 年的今天，对绝大多数开发者来说，CLI 加 Skill 是更务实的选择。教 AI 怎么用好现有的工具，比给它接更多的工具更重要。