别再手动复制代码喂给 AI 了，MCP 让它自己会读、会查、会动手。

文中实战用到的华玥组件库 MCP，官网文档在 hy-design-uni.top/guide/mcp，可以对照着配。

先吐槽一句：你现在的 AI 是个"睁眼瞎"

你肯定遇到过这种场景。

你想让 AI 帮你改一个 Vue 组件里的 bug，结果它压根不知道你这个组件长什么样、依赖了哪些 store、用了哪个组件库。你只能把文件内容一大段一大段地粘贴到对话框里，改完再粘回去。

你想让 AI 帮你按设计稿还原页面，可设计稿在 Figma 里，AI 连不上。你只能把设计稿导成图片传过去，然后它对着图片猜颜色、猜间距，猜得八九不离十但你还得反复纠正。

你想让 AI 帮你查个接口的数据结构，可接口文档在公司内网的 YAPI 上，AI 根本访问不了。你只能手动把响应 JSON 复制给它。

说白了，现在的 AI 就像一个特别聪明、但被关在小黑屋里的顾问——你问什么它都能答，但它看不见你的项目、摸不到你的设计稿、调不了你的接口。所有的上下文，都得你手动搬进去。

这个痛点，就是 MCP 要解决的。

---

MCP 到底是个啥？一句话讲清楚

MCP，全称 Model Context Protocol（模型上下文协议），2024 年底由 Anthropic（Claude 背后那家公司）开源的一套标准协议。

别被"协议"两个字吓到。我用大白话翻译一下：

MCP 是一套让 AI 能"伸出手"去摸外部世界的统一接口标准。

打个比方。你家里有一堆电器（数据库、文件系统、Figma、GitHub、浏览器……），以前每个电器都得配一个专属遥控器，AI 想用哪个就得专门学一遍。MCP 干的事，就是给所有电器定一个统一的插座标准——只要电器支持 MCP，AI 插上去就能用，不用再为每个工具单独写适配。

装上 MCP 之后，AI 就从"只能跟你聊天的顾问"，变成了"能自己动手翻代码、查设计稿、调接口的实习生"。

---

一张图看懂 MCP 的结构

MCP 里有三个角色，搞清楚它们，你就懂了一半：

• Host（宿主）：就是你平时用的那个 AI 应用。比如 Claude Desktop、Cursor、VS Code 里的 Cline 插件、命令行的 Claude Code。它是 AI 模型住的地方。
• Client（客户端）：藏在 Host 里面的"通讯员"，负责跟外面那些 MCP Server 打交道，一个 Client 对应一个 Server。
• Server（服务端）：真正干活的小程序。每个 Server 对接一类外部资源——读文件的、连 Figma 的、操作 GitHub 的、查数据库的。Server 把自己的能力按 MCP 标准暴露出来，AI 就能调用。

用一句话串起来：你在 Cursor（Host）里问 AI 一个问题，AI 觉得需要看一下你的项目代码，就让 Client 去找 filesystem 这个 Server，Server 把文件内容读出来喂给 AI，AI 拿到上下文再回答你。

协议底层用的是 JSON-RPC 2.0，传输方式有两种：本地子进程走 stdio，远程服务走 HTTP + SSE。不用记，知道有这么回事就行。

---

前端开发者凭啥要关心 MCP？

你可能会想：这玩意儿听起来是后端和运维的事，跟我写页面的有啥关系？

关系大了。MCP 对前端来说，解决的是一个特别具体的痛点——让 AI 真正理解你的项目上下文，而不是每次都靠你手动喂。

举几个前端天天碰的场景：

• 你说"帮我看看 UserCard.vue 这个组件为啥样式崩了"，AI 自己就能通过 filesystem Server 读到这个文件、读到它依赖的样式变量、读到全局样式表，然后告诉你问题出在哪。
• 你说"按 Figma 这个设计稿还原一个商品列表页"，AI 通过 Figma Server 直接拉到设计稿的 token、图层结构、组件嵌套，生成的代码跟你设计稿严丝合缝，不用你对着图片猜颜色。
• 你说"这个页面在移动端有个奇怪的兼容 bug"，AI 通过 Playwright Server 自己打开浏览器、复现问题、截图、改代码、再验证一遍，全程不用你切来切去。

这些都不是画大饼，现在就有现成的 MCP Server 能做到。

---

MCP 的三种能力，用大白话讲

一个 MCP Server 能给 AI 暴露三种东西，记住了你就能看懂大部分文档：

Tools（工具）——AI 可以"主动调用"的函数。
比如"读文件"“查接口”“提交 commit”。AI 判断需要的时候，会自己去调，拿到结果再继续。这跟以前 function calling 的概念很像，只是标准化了。

Resources（资源）——AI 可以"读取"的数据。
比如一份设计规范文档、一个 JSON 配置、一段接口定义。跟 Tool 的区别是：Resource 是"被动"的，AI 想看的时候去读，但不会触发什么动作。适合放那些参考资料。

Prompts（提示词模板）——预定义好的"对话开场白"。
比如团队里固定的"代码评审 prompt"“提测前自检清单”。存成模板，AI 随时能调出来用，不用你每次手打一长串。

三者类比一下：Tool 是手（会干活），Resource 是眼睛（会看资料），Prompt 是嘴（会按套路说话）。一个完整的 MCP Server 通常三个都给。

---

实战一：让 AI 读懂你整个项目

最基础也最高频的场景：让 AI 能读你本地的项目文件。

这个用官方的 filesystem MCP Server 就行，开箱即用。以 Cursor 为例，配置文件（一般是 .cursor/mcp.json 或全局设置）里加这么一段：

{
 "mcpServers": {
   "filesystem": {
     "command": "npx",
     "args": [
       "-y",
       "@modelcontextprotocol/server-filesystem",
       "/Users/你的名字/projects/my-frontend-app"
     ]
   }
 }
}

保存重启之后，AI 就能读到你这个目录下的所有文件了。

这时候你再问它：“帮我看看 src/views/Home.vue 里的接口调用有没有问题”，它会自己去读文件、读相关的 api 封装、读类型定义，然后给你一个基于真实代码的回答，而不是瞎猜。

一个小提醒：路径要给到具体项目目录，别给整个用户目录，不然 AI 能读到你的所有文件，既慢又不安全。

---

实战二：接 Figma，让 AI 直接读设计稿

这是前端最该试的一个。

Figma 官方有 MCP Server（也有社区的第三方实现）。配置好之后，你把一个 Figma 链接丢给 AI，它就能：

• 读到设计稿里的所有图层、组件结构
• 提取颜色、字号、间距这些 token
• 根据设计稿生成对应的 Vue/React 组件代码，命名和样式都贴合设计稿

配置大概长这样（以 Cursor 为例，key 去 Figma 开发者后台申请）：

{
 "mcpServers": {
   "figma": {
     "command": "npx",
     "args": ["-y", "figma-developer-mcp", "--stdio"],
     "env": {
       "FIGMA_API_KEY": "你的-figma-api-key"
     }
   }
 }
}

配好之后，你的开发流程会变成这样：Figma 里复制设计稿链接 → 丢给 AI → AI 直接生成带 token、带组件结构的页面代码 → 你微调一下就能用。

比以前"截图传图 → 对着图片猜颜色"高效太多了。

---

实战三：让 AI 自己开浏览器调试

前端写完页面，调试是最烦的环节之一。Playwright 有官方 MCP Server，配好之后 AI 能自己操作浏览器：

{
 "mcpServers": {
   "playwright": {
     "command": "npx",
     "args": ["-y", "@playwright/mcp@latest"]
   }
 }
}

配好之后你可以这么用：

• “打开 localhost:5173，点一下导航栏的’订单’，截图给我看看样式对不对”
• “这个页面在 Safari 上按钮错位了，你帮我排查一下”（AI 会自己跑、截图、对比）
• “帮我写一个登录流程的 E2E 用例，写完自己跑一遍验证能不能通过”

AI 会真的去操作浏览器、点击、填表单、截图、读控制台报错。这比你自己手动点来点去快得多，尤其是写自动化测试的时候。

---

实战四：接一个真实在用的组件库 MCP（华玥组件库）

前面几个都是通用 Server。但前端真正头疼的，往往是自家的组件库——你自己写业务的时候，组件有哪些属性、什么平台能用、Hook 怎么调，AI 一概不知，全靠你查文档再喂给它。

这时候如果组件库本身提供了 MCP，事情就顺了。这里拿一个现成的例子：华玥组件库（hy-app），一个面向 uni-app 的多端组件库，官方已经做好了 MCP Server，npm 包是 @hy-app/mcp。它干的事特别实在——让 AI 能自己查组件文档，不用你再去翻。

官方 MCP 文档地址：hy-design-uni.top/guide/mcp

它给 AI 暴露了哪些工具

这个 MCP Server 一共提供了 8 个工具，基本覆盖了"用组件库"会遇到的全部场景：

• search_components：按中英文名称模糊搜索组件，比如你说"帮我找个弹窗组件"，它自己去找
• get_component_api：查组件的 Props / Events / Slots，问 AI 就能拿到准确的属性列表
• get_component_examples：拿组件的使用示例代码
• check_platform_support：查组件在某个平台（H5 / 微信小程序 / 支付宝小程序 / App）能不能用
• get_hook_doc：查 Hook 文档，比如 useToast、useShare
• get_tool_doc：查工具函数文档，比如 http、throttle
• get_guide：拿开发指南，主题定制、国际化这些
• validate_component_usage：校验你写的组件代码对不对，属性有没有用错

看到没？最后一个 validate_component_usage 特别贴心——你写完一段代码，让 AI 自己校验一遍属性有没有用错，等于 AI 帮你做了一遍 code review。

在 Cursor 里接入（最省事的姿势）

推荐用 npx，不用本地安装。在 Cursor 的 MCP 设置里加这么一段：

{
 "mcpServers": {
   "hy-app": {
     "command": "npx",
     "args": ["@hy-app/mcp"]
   }
 }
}

配置文件的位置：Cursor 里按 Cmd/Ctrl + Shift + P，输入 MCP，点 Edit MCP Settings 就能直接编辑。

如果你更喜欢全局或本地装，官方也给了另两种方式，npm install -g @hy-app/mcp 之后用 "command": "hy-app-mcp" 也行，三种姿势随你挑。

配好之后，开发体验直接起飞

举几个真实的对话例子，都是配好之后你能直接对 AI 说的：

• “我想在项目里用 Picker 组件，帮我生成一个基础选择器” —— AI 会调 search_components + get_component_examples，直接给你能跑的代码
• “我的项目跑在微信小程序上，Radio 组件能用吗？” —— AI 调 check_platform_support，准确告诉你能不能用
• “帮我把组件库主题色改成 #FF6600” —— AI 调 get_guide 查主题定制指南，告诉你该改哪里
• “检查这段代码对不对：<hy-button type='error' size='big'>” —— AI 调 validate_component_usage，告诉你 size 这个组件压根没有 big 这个值

最后这个校验能力，是我觉得最值钱的。以前你写完组件代码，属性写错了只有运行时才发现；现在 AI 帮你查一遍，等于多了一双盯着文档的眼睛。

一个小细节：它对 token 做了优化

前面说过 MCP 会烧 token，华玥这个 Server 明显是考虑过这个问题的，几个默认行为很克制：

• 查 API 默认不返回示例代码，要的话单独调 get_component_examples
• 查 API 支持 detail=false 精简模式，只返回 name/type/default/enum，适合快速扫一眼
• 搜索组件最多返回 10 条精简摘要，不会一次性灌一堆
• 组件名支持 hy- 前缀，写 hy-list 和 list 都能匹配到

这些细节说明它是真的给 AI 编辑器场景设计的，不是顺手套个壳。

Trae、Cline 这些客户端的接入方式跟 Cursor 完全一样，配置格式通用，照着官方文档抄就行。

---

自己动手：给团队设计系统写一个 MCP Server

现成的 Server 用着爽，但真正的威力在于——你可以给团队的设计系统写一个专属 MCP Server。

举个例子。你们公司有一套设计 token（主色 #1a73e8、间距用 4 的倍数、圆角 8px……），平时 AI 不知道这些，每次都得你提醒。把它做成一个 MCP Server，AI 就能随时查。

用官方的 TypeScript SDK 写，几十行代码就够：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// 你的设计 token
const designTokens = {
 color: {
   primary: "#1a73e8",
   success: "#16a34a",
   danger: "#dc2626",
   textPrimary: "#1f2937",
   textSecondary: "#6b7280"
 },
 spacing: { xs: 4, sm: 8, md: 16, lg: 24, xl: 32 },
 radius: { sm: 4, md: 8, lg: 12 },
 fontSize: { caption: 12, body: 14, title: 18, h1: 32 }
};

const server = new McpServer({ name: "design-system", version: "1.0.0" });

// 暴露一个工具：查 token
server.tool(
 "get_token",
 { category: z.enum(["color", "spacing", "radius", "fontSize"]) },
 async ({ category }) => ({
   content: [
     {
       type: "text",
       text: JSON.stringify(designTokens[category], null, 2)
     }
   ]
 })
);

// 暴露一个资源：完整的规范文档
server.resource(
 "design-spec",
 "spec://design-system/full",
 async () => ({
   contents: [
     {
       uri: "spec://design-system/full",
       mimeType: "application/json",
       text: JSON.stringify(designTokens, null, 2)
     }
   ]
 })
);

// 跑起来
const transport = new StdioServerTransport();
await server.connect(transport);

把这个文件保存成 design-mcp.ts，package.json 里配一下，然后在你用的 Host（比如 Cursor）里这么接：

{
 "mcpServers": {
   "design-system": {
     "command": "node",
     "args": ["/绝对路径/design-mcp.js"]
   }
 }
}

配好之后，AI 写组件的时候，遇到颜色、间距、圆角，会自动调 get_token 去查你们团队的规范，生成的代码天然符合设计系统，不用你每次喊"用主色"“间距用 8 的倍数”。

这才是 MCP 真正香的地方——把团队沉淀的规范，变成 AI 默认就知道的事。

---

在 Cursor / Claude Code 里怎么接入

说一下不同客户端的接入方式，都差不多：

Cursor：项目根目录建 .cursor/mcp.json，或者用全局设置。重启 Cursor，右下角会显示连上的 Server 数量。

Claude Code（命令行）：用 claude mcp add 命令加。比如：

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ./src

VS Code 里的 Cline / Roo Code：在插件的 MCP 设置面板里填配置，格式跟上面那个 JSON 一样。

不管哪个客户端，核心都是那三件事：指定命令、传参数、设环境变量。会一个就会全部。

---

有没有缺点？说句实在话

MCP 不是银弹，有几个现实问题你得心里有数：

生态还早期。 很多 Server 都是社区维护的，质量参差不齐，有的文档稀烂，有的动不动报错。官方维护的那几个（filesystem、github、playwright）比较稳，第三方的要自己掂量。

配置有点折腾。 第一次接的时候，路径、权限、环境变量、Node 版本，任何一个不对都连不上。报错信息有时候还很含糊。不过配通一次后面就稳定了。

会消耗更多 token。 AI 调用 Server 拿回来的上下文，都算进 token 用量。读一个大文件、拉一份完整设计稿，token 烧得挺快。所以别让 AI 一次性读太多，按需调用。

安全要上心。 MCP Server 能读文件、能调接口、能操作浏览器，权限给大了有风险。尤其是生产环境的数据库、能写文件的 filesystem，配置时把路径和权限卡死，别图省事给全部权限。

把它当成一个"早期但值得提前布局"的工具，心态就对了。

---

几个高频问题

Q：MCP 跟之前的 function calling 是啥关系？

function calling 是单个模型厂商的功能，每家标准不一样。MCP 把这件事标准化了——只要 Server 按 MCP 协议暴露工具，任何支持 MCP 的客户端（Cursor、Claude、Cline……）都能用，不用为每个模型单独适配。可以理解成 function calling 的"统一插座版"。

Q：必须要 Claude 吗？别的模型行不行？

MCP 是开放协议，不绑定 Claude。Cursor 里可以选 GPT、Gemini；Cline、Continue 这些也支持。只要客户端支持 MCP、模型本身有足够强的工具调用能力就行。目前 Claude 系列对 MCP 的支持最成熟。

Q：前端能用来干嘛？给几个具体例子。

• filesystem：读项目代码，让 AI 理解上下文
• 组件库 MCP（比如华玥的 @hy-app/mcp）：让 AI 自己查组件 API、校验属性、看平台兼容性
• Figma：读设计稿，自动还原页面
• Playwright：AI 自己开浏览器调试、跑测试
• GitHub：让 AI 帮你看 PR、写 commit message、查 issue
• 自己写的设计系统 MCP：把团队 token、组件规范喂给 AI

Q：会不会很难？前端能学会写 Server 吗？

会写 Node 脚本就够了。用官方 TypeScript SDK，照着模板改，几十行就能跑起来。前端写 MCP Server 甚至比后端更有优势，因为你最懂前端项目需要暴露哪些能力。

---

最后说两句

这篇写到最后，我想说一个挺实在的感受。

过去一年，前端圈对"AI 辅助开发"的讨论，基本都停留在"用什么 prompt""怎么让 AI 写出更规范的代码"这个层面。但这些都是治标——AI 不懂你的项目，你再怎么调 prompt，它也只能基于你喂的那点上下文瞎猜。

MCP 真正改变了这件事。它让 AI 从"被动等投喂"，变成了"主动去拿上下文"。这才是 AI 辅助开发该有的样子。

不用急着把所有 Server 都接上。先从 filesystem 开始，让 AI 能读你的项目；再接一个现成的组件库 MCP（像华玥那种，配一行 npx @hy-app/mcp 就能用），或者 Figma、Playwright，挑一个你最痛的环节。跑通一个，你就知道这套东西有多上头了。

等你哪天给团队写出了第一个自己的 MCP Server，把设计规范、接口约定、组件文档都接进去（哪怕先像华玥那样，只把组件文档接上），你就理解我为什么说——MCP 是前端 AI 化最值得提前布局的一块拼图。

---

如果这篇文章对你有帮助，点个赞收个藏。下一篇我会聊聊怎么给团队搭一套完整的 MCP 工具链，把设计、接口、文档全接进去。