AI 编程工程化：MCP——给你的 AI 员工打通外部能力

上一篇我们讲了 Subagent————给你的 AI 员工打造专属协作助手。

这篇讲 MCP，我们开始真正让 AI 走出聊天框。

从一件以前让我很烦的事说起

写前端项目，免不了跟 UI 打交道。

以前经常一边打开 Figma 设计稿，一边开着 IDE。对照着设计稿，挨个看——圆角、字号、阴影、间距……等等，这个颜色有没有对应的 Token 变量？再翻一下项目配置。

就这样反复横跳，手动把设计稿翻译成代码。

也不是多复杂的事，就是烦。每次都这样，很烦。

直到后来我装了 Figma MCP。

我让 Claude Code 直接读一个 Figma 链接，生成对应的 Vue 组件。

它自己去读设计稿里的尺寸、层级、颜色、间距，还认出了里面用到的 Design Token，再对照我项目里已有的组件，最后吐出一个组件文件。

我看了一眼，改了两行，直接用了。

那一刻我才真正想明白 MCP 是干什么的。

不是让 AI 更聪明，是让 AI 看到你真实的工作环境。

MCP 是什么，为什么会突然火起来

MCP 是一套接口标准。全称 Model Context Protocol，模型上下文协议。

类比最直接的一个：USB 接口。

USB 出现之前，鼠标、键盘、打印机、U 盘——每种设备都有自己的接口，互相不通。USB 统一了接口标准，从此不管什么设备，插上就能用。

MCP 做的是同样的事，只是用在 AI 和工具之间。

AI 本来只能看代码文件，顶多跑跑 Shell 命令。但通过 MCP，它能连上 Figma 读设计稿，连上 PostgreSQL 跑 SQL，连上 GitHub 管 Issue，连上 Sentry 看错误报告，连上 Jira 读需求单……

每个工具提供一个「MCP Server」，Claude Code 作为「MCP Client」连进去。接口标准统一，装哪个工具就能用哪个工具。

装上哪根 USB，AI 就能操控哪个设备。

它之所以后来突然火起来，也是因为当时整个 AI 工具生态太乱了。每个工具有自己的接入方式，每个 AI 客户端也有自己的实现，互相不通。Anthropic 内部被这个问题折腾了很久，最后在 2024 年 11 月 25 日把 MCP 开源出来，想先把这件事标准化。

发布之初，反响其实很平。真正爆发是在 2025 年初——OpenAI、Google、微软相继宣布支持 MCP，Cursor、Windsurf、VS Code 等主流 IDE 也跟进接入。一个 Anthropic 内部的工程规范，就这样慢慢变成了整个 AI 工具生态的事实标准。

到 2026 年初，MCP Server 的数量已经超过 4000 个，覆盖了开发者日常用到的几乎所有工具。

MCP 好用，但代价也很真实

用一段时间之后，你会碰到几个绕不过去的问题。

问题一：上下文 token 消耗大

这是目前最核心的问题。

每个 MCP Server 连上来，它的工具列表就会被注入到 AI 的上下文里。一个工具的 Schema 描述，少则几百 token，多则几千。装了十几个 Server，上下文里光工具描述就占了一大块。

有人做过测试：43 个工具定义，注入了 55,000+ token，AI 还没开始干活，上下文就先消耗了一大半。极端情况下，200,000 token 的上下文里，143,000 token（72%）被工具定义占掉了。

Anthropic 自己也承认，在一些重度 MCP 使用场景下，约 40% 的 token 消耗来自工具 Schema，而不是真正的工作内容。

实际影响：装的 Server 越多，AI 的「有效工作空间」越小，响应质量可能下降，费用也会上升。

现在的应对方式：按需装，用不上的移掉。Claude Code 已经在做按需加载（lazy loading），不是所有工具一开始就全部注入，但这个机制还在完善中。

问题二：安全风险不容忽视

MCP 的安全问题在 2025 年引发了大量讨论。

最典型的攻击方式叫「工具投毒」（Tool Poisoning）：恶意的 MCP Server 可以在工具描述里藏入隐藏指令，AI 读取工具列表时就被「注入」了，然后在你不知情的情况下执行了预期之外的操作。

另一个风险是配置文件里的 API Key 明文存储，一旦本地环境被攻击，所有连接的服务凭证都可能泄露。

Anthropic 在 2025 年 6 月发布了 MCP 规范更新（v2025-06-18），修复了一批安全漏洞，强化了授权机制。但安全问题本质上是个持续的过程，不是一次更新就能解决的。

实际建议：只装官方或知名来源的 Server，给 MCP 配的 API Key 用最小权限，先从只读 Server 开始。

问题三：生态质量参差不齐

4000+ 个 Server，听起来很繁荣，但其中大量是社区维护的，质量差异很大。有些 Server 几个月没有更新，有些文档残缺，有些接口设计很随意。

装之前先看看 GitHub Star 数、最近的 commit 时间、有没有人在 Issue 里反馈问题。

装上 MCP 之后，能干什么

场景一：从 Figma 设计稿直接生成代码

开头讲的就是这个场景。

配合项目里的 Rule 和 Skill，它还能识别 Design Token、复用已有组件、列出设计稿和现有实现的差异。

「读稿 → 生成符合项目规范的代码」，基本一步完成。

场景二：自然语言查数据库

连上 PostgreSQL MCP，你可以直接问：

「最近 7 天注册但没有完成引导的用户有多少，按注册渠道分组给我看一下。」

AI 把这句话翻译成 SQL，跑完，把结果整理给你。

不用开 SQL 客户端，不用记表结构，不用自己写查询语句。

场景三：让 AI 直接处理 GitHub 上的事

连上 GitHub MCP：

「帮我找 bug 这个 label 下，最近两周新开的 Issue，按优先级排一下，给每个写一句简短的分析。」

「把 PR #142 的 review 意见整理一遍，哪些已经处理了，哪些还没动。」

它直接拉数据、读代码、写分析。不用你来回切窗口。

场景四：查最新的库文档

AI 的训练数据有截止日期。你用的库更新了，它给的答案可能是旧的。

Context7 MCP 解决这个问题——它实时拉取最新文档，每次 AI 回答问题之前先去查一遍当前版本的文档，而不是凭「记忆」作答。

用了最新的 API 但老是出问题？很可能就是 AI 在用旧版本的用法。装上 Context7 MCP，这个问题基本消失。

最值得装的几类 MCP Server

设计协作

Figma MCP（官方）

前端开发者必装。读设计稿、提取 Token、生成组件代码。免费计划每月 6 次调用，付费计划无限制。

安装方式：在 Claude Code 里输 /mcp，选择添加，搜索 Figma，按引导完成 OAuth 授权即可。装完后把 Figma 帧的 URL 直接甩给 Claude，让它读。

代码托管

GitHub MCP（官方）

管 Issue、PR、代码搜索，不用离开 IDE。

1	claude mcp add --transport http github https://api.githubcopilot.com/mcp/

数据库

PostgreSQL MCP

让 AI 直接查询数据库，自然语言转 SQL，结果即时返回。

1 2	claude mcp add --transport stdio pg \ -- npx -y @modelcontextprotocol/server-postgres postgresql://user:pass@localhost/dbname

文档 & 搜索

Context7 MCP

实时获取库的最新文档。用哪个框架就查哪个框架的当前版本，不用担心 AI 用了旧 API。

1	claude mcp add --transport http context7 https://mcp.context7.com/mcp

Brave Search MCP

让 AI 联网搜索，解决训练数据过时的问题。

1
2
3

claude mcp add --transport stdio brave-search \
  --env BRAVE_API_KEY=your_key \
  -- npx -y @modelcontextprotocol/server-brave-search

项目管理

Linear MCP / Jira MCP

读需求单、更新状态、创建任务。「帮我把 ENG-421 里描述的功能实现了，然后把状态改成 In Review」——这句话以前只能说给人听，现在 AI 真的能执行。

监控

Sentry MCP

让 AI 直接查错误报告，结合代码定位问题，而不是你复制粘贴报错再问它。

怎么装

三种安装方式

方式一：远程 HTTP（推荐，最省心）

大多数现代 MCP Server 支持 HTTP，一行命令搞定：

claude mcp add --transport http <名称> <URL>

# 例子：连接 Notion
claude mcp add --transport http notion https://mcp.notion.com/mcp

方式二：本地 stdio（需要本地进程的工具）

部分工具需要在本地跑一个进程，用 npx 或本地脚本启动：

claude mcp add --transport stdio <名称> -- <启动命令>

# 例子：连接 Airtable
claude mcp add --transport stdio --env AIRTABLE_API_KEY=你的Key airtable \
  -- npx -y airtable-mcp-server

方式三：在 Claude Code 内部操作

输入 /mcp 打开管理界面，可以查看已连接的 Server 状态、处理 OAuth 认证。

部分需要登录授权的服务（比如 Figma、GitHub），在这里完成授权就行。

三个作用域：配给谁用

user（全局）：所有项目都能用，对应 --scope user
project（项目共享）：当前项目可用，写入 .mcp.json，能提交 git 给团队共享，对应 --scope project
local（默认）：只对你自己的当前项目生效，不填就是这个

团队都要用的 MCP Server（比如 GitHub、Jira），加 --scope project，提交 git，大家拉代码就生效了。

常用管理命令

1
2
3

claude mcp list          # 看当前配置了哪些 Server
claude mcp get github    # 查某个 Server 的详情
claude mcp remove github # 移除

装之前，先记住这几件事

不是所有 MCP Server 都安全。

这是最重要的一条。Anthropic 官方只验证了部分 Server，第三方的 Server 质量参差不齐。从不知名来源装 MCP Server，和从不知名来源装 npm 包一样有风险。

优先装官方或知名来源的 Server。

Figma、GitHub、Notion 这些主流工具的官方 MCP Server，可以放心装。社区版的也行，但要看看 Star 数、维护频率、代码是否开源。

小心会抓取外部 URL 的 Server。

有些 Server 会从外部网页拉取内容。如果那个网页里藏了恶意指令，AI 可能被「注入」执行预期之外的操作。先从「只读型」Server 开始（搜索、文档、监控），再考虑有写权限的。

API Key 按最小权限配。

给 MCP Server 的 Token，尽量限定只读权限或最小必要权限。不要把生产数据库的 root 密码直接配进去。

Server 多了会影响上下文。

每个 MCP Server 的工具列表都会注入到 AI 的上下文里。装太多，上下文里全是工具描述，反而影响响应质量。按需装，用不上的移掉。

去哪里找靠谱的 MCP Server

Smithery

https://smithery.ai

目前最大的 MCP Server 市场，4000+ 个 Server，支持按分类搜索，有安装量和评分参考，是找 Server 最快的地方。

官方 GitHub 仓库

https://github.com/modelcontextprotocol/servers

Anthropic 官方维护的参考实现，质量有保证，但数量有限，适合找主流工具。

Glama

https://glama.ai

综合市场，带可视化预览，界面做得不错，适合浏览找灵感。

awesome-mcp-servers

https://github.com/punkpeye/awesome-mcp-servers

社区精选列表，按分类整理，质量比较有保证，经常更新。

Claude Code 官方文档

https://code.claude.com/docs/en/mcp

官方推荐的常用 Server 列表，都是主流工具，可以作为入门清单。

为什么大家又开始重视起 CLI

前几个月，很多人聊 AI 编程，几乎都绕不开 MCP。

Playwright、Chrome DevTools、Figma、GitHub……仿佛一个工具如果没有 MCP 版本，就不够 AI Native。

但近期，风向明显变了。越来越多人开始重新讨论 CLI，甚至有人进一步说：不只是 MCP，以后连 GUI 都未必还是软件的主入口。

为什么会这样？

因为大家慢慢开始意识到：MCP 解决的，其实不是“执行”问题，而是“接入”问题。

CLI 更像是把动作直接执行出来：读文件、改代码、跑测试、调用本地命令，路径短，开销小，对 Agent 来说也更直接。

MCP 则是把一种能力按公共协议暴露出来，让不同的 Host 都能发现、理解、调用。它不只是 action，还包括 tools、resources、prompts、session 这些边界。它像 USB，也像 HTTP——重点不是它更酷，而是它让互操作这件事成立。

把这个位置放对之后，很多争论就没那么神秘了。

之前大家会觉得 MCP 特别“像未来”，很大程度上是因为它天然带着一种新基础设施的叙事感。那段时间，很多人不是在判断什么形态最自然，而是在判断什么形态最像下一代软件。

说白了，当时大家更怕错过，而不是更想明白。

可一旦 hype 退一点，再回头看就会发现：很多事情本来就更适合 CLI。

对 Agent 来说，CLI 的优势不是情怀，而是现实：更快，更 local-first，action loop 更短，通常也更省 token。

命令发出去就执行，不需要先发现 Server、读 Schema、理解交互边界，再决定怎么调用。

所以现在大家重新谈 CLI，不是因为 CLI 突然变好了，而是因为我们终于把 MCP 放回了它该在的位置。

MCP 不是未来软件的全部形态，它只是一层公共接入协议。

它真正值钱的时候，其实主要是这几种场景：

你真的需要跨 Host 互操作
你不想给每个客户端单独做一套适配
你希望 auth、schema、discovery、session 这些边界尽量统一
你不只是暴露一个动作，还要一起暴露 tools、resources、prompts

如果没有这些需求，很多时候 CLI + API 就够了。硬上 MCP，反而容易变成过度设计。

所以更准确的理解不是“CLI 会不会取代 MCP”，而是：CLI 和 MCP 根本不在同一层。

CLI 是执行层，适合直接干活。MCP 是协议层，适合把外部能力标准化接进来。

真正成熟的 AI 编程环境，往往两者都会有：能直接跑命令的地方，用 CLI；需要统一接入外部系统的地方，用 MCP。

总结

Rule 定规矩，Command 封流程，Skill 装能力，Hook 做检查，Subagent 拆任务。

MCP 做的是最后一件事：把 AI 和你真实的工作环境接起来。

Figma、数据库、GitHub、Jira……这些你每天打交道的工具，AI 原本看不见。装了 MCP，它才算真的进了你的工作流。

没有 MCP，AI 只是个聪明但瞎眼的助手。装上 MCP，它才真正知道你在什么环境里干活。

所以这篇真正想讲的，不是 MCP 有多酷。

而是你开始把 AI 当同事用的时候，迟早都得面对同一个问题：怎么把它接进真实世界。

下一篇讲 Plugin：怎么把 Rule、Command、Skill、Hook、MCP 打包在一起，一键分发给团队或社区。

欢迎感兴趣的朋友继续保持关注~