MCP：新时代的API，每个程序员都应该掌握

哈喽，我是老刘

老刘做Flutter开发6年多了，之前还做过Android客户端、网络安全等等不同的开发领域。

按说在这个AI蓬勃发展的时代，老刘这样的老派程序员应该属于被AI替代的对象。

不过在我看来AI虽然确实代替了开发中的一部分机械性的模板化的工作，但是同时也极大的扩展了应用的边界。

所以与其说AI替代了某某工作，不如说在AI的影响下各行各业都发生了深刻的变化。

一、AI扩展应用边界：从固定算法到动态智能​

"帮我安排下周二北京飞东京的行程，早班机别太贵，下午还能逛个秋叶原..."

三年前，如果你对手机说出这段话，它大概率会回复："听不懂，请点击底部菜单操作"。

而今天，某程旅行App直接甩你一张完整行程单：航班比价、浅草寺路线、秋叶原店铺评分------整个过程像在跟人聊天。

为什么过去死活做不好的体验，现在突然实现了？​​ 秘密藏在技术代际的断层里。

1. 老办法到底卡在哪儿？​​

想象你要教小学生解方程：

固定算法​​：必须写死规则"见到'X+Y=Z'就代入公式"，那如果要算X+Y^2怎么办？

对不起，需要提需求，进一步开发。

​​痛点的本质​​：代码只能处理人类预设的问题，​​而真实世界满是模糊需求和突发奇想​​。

2. 大语言模型：给App装上"大脑"​​

来看下面的场景：

"导航到三里屯评分最高川菜馆"

AI可以自动拆分以下动作：定位→搜餐馆→筛评分→算路线

"PDF第3页数据做成柱状图发我微信"

调OCR→提取数据→用Matplotlib画图→微信推送

本质上AI为应用提供了以下的能力：
​​听懂人话​​ ：再刁钻的说法（如"那个啥PPT文件"）都能基于上下文做出正确的判断。
自动规划 ：可以将一个任务拆解为多个具体的步骤去执行。
​​动态组装技能​​：像乐高一样任意拼接工具链，无需程序员手写对接逻辑。

二、MCP：AI时代的"手脚"与标准化接口​

若LLM是应用的大脑，MCP则是连接外部世界的神经与肢体。

曾几何时，AI就像个只会动嘴的学霸：

你问"帮我查三月绩效"，它甩你一串SQL教程

你说"邮件通知财务审批"，它教你Outlook操作指南

Function call诞生

这种情况的改变是源于ChatGPT在2023年6月份的时候提出来的Function call协议。

Function call让LLM有了直接调用外部工具的能力。

假设我们让AI去查询北京今天的天气，它会按照下面的流程工作：

1、​​请求阶段​​

用户提问 + 函数定义列表 → 发送至ChatGPT API。

{
  "functions": [{
    "name": "get_weather",
    "description": "获取城市天气",
    "parameters": {"type": "object", "properties": {"location": {"type": "string"}}}
  }]
}

​​2、模型决策​​

模型判断需调用函数 → 返回函数名及参数字符串，如：

{"name": "get_weather", "arguments": "{"location": "Beijing"}"}

3、​​函数执行​​

AI客户端（例如CherryStudio、Cursor）解析JSON，调用本地或外部API（如天气接口），获取结果。

4、​​结果整合​​

将函数返回数据再次发送给模型 → 生成最终自然语言回复（如"今日晴，25°C"）。

但是Function call并没有明确规定向LLM发送函数列表以及LLM调用某个方法时的具体字段及协议标准。

这就会造成不同LLM接受函数列表以及调用时的字段可能各不相同。

比如我要开发一个天气查询服务，就需要针对不同的LLM开发不同的通知和解析过程。

而作为一个AI客户端，比如Cursor或者CherryStudio，也需要针对不同的LLM以及不同的服务提供者做专门的适配。

为了解决上面这个问题，将Function call的通知和调用接口统一成标准协议自然而然的产生了，那就是MCP。

MCP 协议

MCP通过定义一个统一的协议层解决了上述碎片化问题：

1、​​统一交互协议​​

• 标准化函数描述格式：所有服务提供者遵循同一套MCP Schema定义函数（名称、参数、权限）
• 调用指令规范化：LLM返回的请求强制符合MCP JSON Schema，消除解析歧义
• 示例：MCP函数调用指令格式

{"action": "execute", "tool": "weather", "params": {"location": "Beijing"}}

2、双向解耦设计​​

三、为什么说开发者必须掌握MCP？​​

1. 躲不开的AI洪水：你的行业正在被"智能体"重塑​

当00后实习生用AI三天搞定报销系统，老程序员盯着自己写的10万行代码陷入沉思...

当老板发现AI能自动调数据库、连微信、改OA流程------你写的传统代码正在加速贬值！

2. 传统的开发模式正在被MCP重塑​

以前对接钉钉+用友+微信要写三套接口，但现在只需要对接对应的MCP服务，即可以让LLM去智能调用，也可以让AI生成对接的代码实现固定策略调用。

也就是说对接MCP接口的服务，可以同时满足传统的接口调用方式，也可以支持AI调用的方式。

从这个角度看它可以完全替代现有的接口体系，而不是仅仅用于AI的场景。

3. 生态卡位战：不做MCP Server=被踢出AI餐桌​

这里以高德地图的MCP服务为例，来看看生态位的重要性
先发优势固化用户习惯​​

• 当开发者第一次调用地图服务时，高德MCP Server已是现成选项，接入成本接近于零

  • 可以找到的地图服务MCP的资料、教程和生态基本都是指向高德的。

• AI应用默认接入高德后，沉淀为路径依赖

  • 当系统中一个服务运行良好的时候，除非有特殊原因，否则几乎不可能去做这种底层服务的替换。
    数据飞轮碾压技术差异​​

• 当高德通过海量调用积累实时路况、POI热度等场景数据，反哺AI（比如亲子游线路推荐）

  • 新玩家即便技术更强，也会因缺乏数据闭环沦为"实验室玩具"；

四、开发者的两条黄金赛道

其实智能体和MCP是全新的开发模式，对开发者来说有很多可以探索的方向和玩法。

这里列举两条老刘自己能看到的思路。

​​工具提供方​​：

把你的系统变成MCP Server

比如把财务软件暴露为"智能记账工具"

再比如提供本地主机上的MCP服务，就像老刘现在在使用的excel mcp，和智能体用自然语言说一下就可以将本地excel做对应的处理，效果非常好。
​​智能体设计师​​：

用MCP像搭乐高一样组装AI工作流

比如自动抓GitHub代码+跑测试+发Slack通知

五、从何开始？

前面我们讨论的是MCP在未来开发体系中的地位。

但是对于我们开发者来说要从何开始呢？

老刘自己是做客户端开发的，这两年更是主要写Flutter代码，原生方面都略微有些生疏了。

我觉得对于和老刘类似的程序员来说，就可以先从使用MCP开始。

比如先搭建一个本地的mcp运行环境，然后配置一些mcp服务优化自己的工作流程。

我在自己的电脑上基于Trae + excel mcp + 文件系统mcp，做了不少数据整理、配置文件生成等工作。节约了很多的时间。

当然Dart也能做相关的开发工作：

未来的手机端App，作为一个mcp host去调用mcp服务应该会是一件很常见的事情。

而Flutter作为目前跨平台开发的顶流，将各种端侧的功能封装为mcp server也是非常有可能的。

好了，本文主要是老刘对目前MCP、AI对于开发者的一些影响的思考和判断。

结尾添加了一些作为客户端、Flutter开发者能从哪里开始入手。

如果看到这里的同学对客户端、Flutter开发或者MCP感兴趣，欢迎联系老刘，我们互相学习。

点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。

可以作为Flutter学习的知识地图。
覆盖90%开发场景的《Flutter开发手册》