MCP 又死了?3亿月下载量打脸唱衰者!前端工程师何去何从?
01 前端工程师真的”死”了吗?
最近技术圈有个”月经话题”:MCP 到底死了多少回了?
不少人吐槽:模型能力每提升一次,前端工程师就要”死”一次。一次又一次,前端岗位确实在减少,或者被”合并”到了全栈工程师当中。
但就在唱衰声最大的时候,一组数据砸了过来——
数据来自 Claude 官方博客,不是野榜。
先说结论:前端岗位在锐减,但凶手不是 MCP。
来看几组硬数据:
2025 年,84% 的开发者已在或计划使用 AI 工具,初级程序员岗位需求同比下降约 30%
智联招聘 2026 年 Q1 报告:普通前端开发岗位需求同比暴跌 52%
美国劳工统计局数据:过去两年,编程类初级岗位减少了 27%
到 2025 年底,部分公司的专职前端岗位已经消失——要么转全栈,要么走人
这不是 MCP 的锅,这是 AI 对整个软件开发行业的结构性冲击。
“死”了的只是那种”只会写页面、调接口、切图”的纯执行型前端。活下来的,正在变成三种人:
全栈工程师:一个人用 AI 助手搞定前后端,独立交付整个功能
架构师 / 协调者:不再一行行码代码,而是设计系统架构、写提示词、指挥多个 AI 智能体协同工作
AI 原生开发者:熟练使用各种 AI 工具,具备”把需求拆解成 AI 可执行任务”的能力
02 让智能体连上外部系统,三条路怎么选?
目前主流有三种方法,咱们一个一个讲清楚。
方法一:直接调 API
起步最简单。一个 API 对应一个场景,Agent 直接调就完事了。
但规模一上来,问题就炸了:每新增一个”Agent × API 服务”的组合,都得从头写一套认证和工具描述。这就是经典的 M×N 集成难题:M 个 Agent × N 个 API 服务 = M×N 套代码。小打小闹可以,上生产就疼。
方法二:命令行工具(CLI)
更快、更轻。直接复用现成工具链,本地环境里非常好使。Agent 天生就会用命令行语言。
但天花板也很明显:移动端、网页端、云端没有 shell,就玩不转了。CLI 的认证通常靠磁盘上的凭证文件,最适合本地开发环境,正经生产场景会受限。
方法三:模型上下文协议(MCP)
把”统一中间层”做成了协议。认证、工具发现、语义表达全部标准化。
建好一台 MCP 服务器,Claude、ChatGPT、Cursor、VS Code 等所有兼容客户端都能直接用,部署在哪儿都行。
三条路不是非此即彼。成熟的集成,往往三者都用。
03 MCP 被骂得最狠的问题:Token 死贵
MCP 虽好,但被骂得最多的就是:太费 token 了,贵得离谱。
ScaleKit 做了一组严格的 benchmark,拿 GitHub 官方 MCP 服务器和 gh CLI 对照跑实验。
问题出在 schema 膨胀上。
GitHub 的 MCP 服务器带了 43 个工具定义,每次对话都得把这些工具的描述塞进上下文。你只是想查个仓库语言,但模型得先读完所有工具的说明书——
|
|
|
|---|---|
|
|
44,026 tokens |
|
|
1,365 tokens |
04 Token 问题的两个解法,已经落地了
好消息是,这些问题正在被解决。
解法一:按需加载工具定义(Tool Search)
以前是一上来就把所有工具定义塞进去——43 个工具、55,000 tokens,活还没干,工作台就被说明书堆满了。
工具搜索把这步推迟了:智能体先描述它想做什么,系统在运行时搜索相关工具,只把匹配的几个拉进来。
工具定义的 token 消耗减少 85% 以上,准确率没有下降。差距从 32 倍缩到约 7 倍——还是比 CLI 贵,但不再是数量级的差距了。
解法二:用代码处理工具结果(程序化工具调用)
工具返回的结果不再直接丢给模型,而是扔进代码执行沙箱里处理。智能体在沙箱里循环、过滤、聚合,只把最终结果返回到上下文——中间的原始数据不经过模型。
在复杂多步骤工作流中,token 使用量可减少约 37%。
两个解法叠加,上下文更瘦、往返更少、响应更快。
05 怎么做出一个好用的 MCP 服务器?
目前目录里已有超过 200 个 MCP 服务器,每天数百万人在用。结合大量实践,总结了几个关键设计原则。
① 做成”远程服务器”,触达面才大
远程服务器是唯一能同时被网页端、移动端、云端智能体调用的形态。想让智能体无论跑在哪儿都能用上你的系统?做远程的,没别的选择。
② 按”用户意图”组织工具,别按 API 端点
很多人第一反应是把 API 一对一翻译成工具——这是个陷阱。少而精、描述清晰的工具,远比一堆细碎的工具好用。
与其给智能体四个工具(获取消息串 + 解析消息 + 创建工单 + 关联附件),不如直接给一个 “从消息串创建工单”,一步到位。
思路:围绕“用户想完成什么”,而不是”API 有哪些方法”。
③ 接口非常多时,改成”代码编排”
如果你的服务有几百个操作——比如 Cloudflare、AWS、Kubernetes——”意图分组”也包不完。这时换个思路:只暴露一两个接受代码的工具。
Cloudflare 的 MCP 服务器就是典型案例:只有两个工具(search 和 execute)。整个工具定义只占大约 1K tokens,却覆盖了约 2,500 个端点。
这个模式叫“代码编排”——把 CLI 的哲学搬进了 MCP 协议里。
④ 在关键时刻,给用户更丰富的交互
MCP Apps 允许工具直接返回可交互界面——图表、表单、仪表盘,直接渲染在聊天里,不用让用户跳出去。会用 MCP Apps 的服务器,采用率和留存率都明显更高。
⑤ 认证用标准方案,别自己造轮子
认证是否标准化,直接决定云端智能体能不能用起来。
最新 MCP 规范支持 CIMD 客户端注册方式,用户首次登录快,后面也不容易突然被要求重新授权。Claude Managed Agents 的 Vaults(保险库) 帮你管令牌:用户登记一次,之后每次会话平台自动注入正确凭据并帮你刷新——不用自己搭密钥存储。
06 MCP + Skills:不是替代,是组合拳
Skills 和 MCP 是互补的两件事:
|
|
|
|---|---|
| MCP |
|
| Skills |
|
方式一:打包成 Plugin 一起分发
Claude 的插件可以把 skills、MCP 服务器、hooks、LSP 服务器、子智能体全打进一个包里,一键安装。
方式二:从 MCP 服务器直接分发 Skills
服务提供方发布 MCP 服务器时,顺手附送一份 skill——客户端拿到的不只是原始能力,还有一本”最佳使用手册”。Canva、Notion、Sentry 今天都在这么干。
07 三条路,各回各家
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
MCP 并没有死。 它当然不是万能方案,但它正在成为云端智能体的标准化接入层。今天建好一台远程 MCP 服务器,就能触达所有兼容客户端、所有部署环境,认证、交互、语义全部由协议兜底。更妙的是:随着规范支持的客户端越来越多,你那台老服务器会自动变强——什么新东西都不用额外写。
写在最后
回到开头的问题:前端工程师真的”死”了吗?
没有。但”只懂前端”的工程师,确实在被淘汰。
AI 不是来抢饭碗的,是来重新定义饭碗的。MCP 也不是来杀死谁的,它是来给智能体铺路的。
如果你想在这个时代活下去、活得更好,方向很清晰:
从”写代码的人”变成“用 AI 写代码的人”
从”只懂前端”变成“懂业务、懂架构、懂 AI 工具链”
从”被 MCP 吓到”变成“会写 MCP 服务器的人”
作者:Tiger / 公众号:TechLifeExplorer
夜雨聆风