哈喽，我是老刘
老刘做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开发手册》
