魏金华做 AI 提效这几年，我最怕听到的一句话就是：“vibe coding 不就是让 AI 写代码嘛。”说这话的人，多半是看了一堆短视频 demo，以为打开聊天窗口喊一句“帮我做个网站”，剩下就全交给魔法了。真上过手的人都知道，AI 聊得再嗨，只要碰不到你的数据库、接口、设计稿或本地环境，它就只是个“嘴强王者”。真正把 vibe coding 从玩具变成生产力的，是 MCP。
MCP，全称 Model Context Protocol，模型上下文协议。它给 AI 客户端提供了一种统一接入外部工具的方式。你可以把它理解成 AI 世界的 USB 接口：手机电脑都有 USB 口，你插上硬盘能存文件，插上摄像头能录视频，插上手柄能打游戏。MCP 就是这个“口”，你通过它把数据库、浏览器、设计工具、服务器脚本一个个“插”到 AI 身上。
今天我准备手把手把一个完整的 MCP 服务从零写出来。不是讲概念，而是直接把代码跑起来、把配置填好、把客户端连上去、把坑踩一遍。读完这篇文章，你应该能复刻出一个稳定运行的本地任务管家 MCP，并且搞清楚它背后那些“为什么”。不管你用的是 Claude Desktop、Cursor、Codex 还是 Cherry Studio，这套流程都能迁移。
先说重点：本文所有代码都基于本地环境，不需要额外申请云服务，跟着敲就行。项目不复杂，但足以帮你建立对 MCP 服务开发的完整心智模型。
1. vibe coding 跑不通，大多数问题出在“没有工具”
1.1 “自然语言生成代码”其实只解决了前半段
vibe coding 这个词最初指的是用自然语言描述需求，让 AI 连续生成和修改代码的编码方式。听起来很随意，但一个容易被忽略的事实是：AI 的“爽点”在于它能快速产出草稿，而“痛点”是它永远无法自动验证自己是不是真的把事情做对了。
举个例子。你让 AI 写一个统计报表接口，它能瞬间生成一大堆代码。但当你问它“这个接口连的数据库里有几条订单”时，它就沉默了。为什么？因为它手上没有数据库连接。哪怕你把表结构贴给它，它也只能“猜”着写，而不是“用”着写。这样生成出来的代码，很多只能在理想条件下运行，一碰到真实数据就崩。
所以 vibe coding 的正确定义不是“让 AI 随便写”，而是让 AI 处在有反馈、有工具、有执行路径的闭环里。这个闭环就是：AI 调用外部工具 → 工具执行完成 → 返回结构化结果 → AI 根据结果调整下一步。你越早意识到这一点，越不容易被 demo 带偏。
1.2 MCP 就是给 AI 装上传感器和机械臂
如果你用过浏览器自动化或者命令行工具，你会发现很多 MCP 服务本质上就是“已有的工具，加一层协议包装”。
比如你想让 AI 查数据库，可以给它一个“执行 SQL 并返回结果”的工具；你想让 AI 读取网页，可以给它一个“抓取 URL 并转成 Markdown”的工具；你想让 AI 操作设计稿，可以接一个 Figma 或蓝湖的服务。每一个工具都像一个小插件，AI 自己决定什么时候调用。
MCP 协议规定了三件事：
- 客户端怎么发现服务器提供的工具列表；
- 客户端怎么把你的指令转成标准请求发给工具；
- 工具执行完之后怎么把结果带回来。
只要服务器实现了这套协议，任何支持 MCP 的客户端都能直接用。不需要每个客户端各自发明一套“插件 API”。这也是 2025 年以来，Cursor、Claude、Codex、Cherry Studio、Cline 等十几个主流工具都支持 MCP 的根本原因。
1.3 为什么“自己写一个 MCP 服务”是最高效的学习路径
网上现成的 MCP 服务器非常多，有连接 GitHub 的、有连接数据库的、有连接设计稿的。直接安装当然可以，但如果你完全没写过服务器，一旦遇到“AI 找不到工具”“连接不上”“配置不生效”，你根本不知道是客户端问题、协议问题还是工具本身的问题。
手写一个小服务，你会彻底搞懂这几个关键点：
- MCP 服务端如何暴露“工具”；
- 工具的参数和返回值为什么必须设计得极其严谨；
- stdio 和 HTTP/SSE 两种模式有什么区别；
- 客户端配置文件的路径和格式是怎么工作的。
这些东西只有亲手跑一遍才能形成肌肉记忆。所以我建议所有人都从零手写一次，哪怕最后你的正式项目只是复用别人的 MCP，这段基础也不会白学。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先别急着写代码：这四件事决定后面不返工
2.1 选 stdio 还是 HTTP/SSE：先看客户端在哪台机器
MCP 服务器有两种主流通信方式。第一种是 stdio，客户端启动一个本地子进程，双方通过标准输入输出传递 JSON 消息。第二种是 HTTP/SSE（也包含较新的 Streamable HTTP），服务器作为常驻服务，客户端通过网络请求访问。
怎么选？我的经验很简单：如果 AI 客户端和 MCP 服务跑在同一台电脑上，优先选 stdio。它的好处是部署成本为零，没有端口、没有 CORS、没有认证，更安全，因为你不需要把一个服务暴露到网络上。Claude Desktop、Cursor、Codex 这些本机工具，日常跟本地 MCP 打交道基本都是 stdio。
如果你有多个客户端、多台机器要同时连同一个服务，或者服务部署在服务器上给团队用，那就要考虑 HTTP/SSE 或者 Streamable HTTP。这时候你得多考虑几个问题：鉴权怎么做、日志怎么收、进程怎么守护。建议不要一上来就上分布式架构，先把 stdio 跑通再谈网络化。
2.2 开发语言与 SDK：Python 和 TypeScript 是主流
MCP 官方提供了 Python SDK 和 TypeScript SDK，写作本文时还有 Java、Go、C# 等社区实现。我这里选择 Python，原因是 Python 生态里自带了很多数据处理和系统管理库，写本地工具非常顺手；另外它的类型提示配上 MCP 的 schema 生成非常舒服。
有一个重要的设计点：MCP 工具的参数定义，不是你在代码里写多少就暴露多少。SDK 会通过类型提示和函数签名