AI时代前端工程师何去何从？MCP、Agent Skill与GenUI全解析

“AI出来后前端工程师是不是没了”这个话题，我最近被问了不下十次。每次我都没法用一句话回答，因为我自己也是追完 OpenTiny NEXT 整套系列直播、又把 MCP 和 GenUI 链路亲手跑了一遍之后，才真正想明白这个问题该怎么答。这篇内容不是那种“AI帮你写代码”的提示词教程，而是我作为前端开发者的真实学习路径复盘：MCP 协议到底在解决什么、Agent Skill 和 MCP 有什么区别、怎么从零搭一个 MCP Server、Figma MCP 接入时“工具注册不上”怎么排查，以及 GenUI 这套新东西会对前端工作流产生什么实质影响。如果你也在焦虑 AI 会不会把前端岗位干没，或者在面试题里看到 MCP、Agent Skill 一脸懵，这篇文章应该能给你一个比较完整的坐标系。

1. 追完整套“OpenTiny NEXT”直播，我对AI前端的判断变了

先说清楚我为什么要追 OpenTiny NEXT。OpenTiny 本身是国内企业级组件库方向的重要开源项目，有 Vue 和 Angular 两条产品线，还有配套的设计系统。NEXT 系列直播讨论的核心是：下一代组件库怎么适配 AI 时代。坦白讲，在追直播之前，我对 AI 前端的理解停留在“用 AI 写代码”这个层面，每天刷各种提示词技巧，总觉得和真实项目之间隔着一层。但直播里面反复出现的三个词把我拉了回来：MCP、智能体组件、GenUI。

我印象最深的一期是讲设计稿到代码链路的。直播嘉宾现场演示了一个流程：把 Figma 文件通过 MCP 连接给 AI，AI 读取设计稿的图层结构和样式变量，然后按照 OpenTiny 组件库的规范生成 Vue 组件。整个流程跑通的那一刻，我意识到自己之前的关注点完全错了。AI 前端不是“提示词竞赛”，而是协议链路的问题。AI 能不能读懂设计稿、能不能按照你的组件库规范生成代码，取决于你有没有把设计系统和代码库用机器可读的方式暴露给 AI。你可以把最好的提示词发给 AI，但如果它根本拿不到设计稿的结构化数据，一切都是空中楼阁。

直播里嘉宾还分享了一个观点，我当时记了笔记：组件库不仅是给人类开发者用的，还是给 AI Agent 用的。这句话看似简单，背后是一个很大的转变。传统组件库的文档是给人看的，AI 读起来其实很费力。OpenTiny NEXT 在做的事情，是把组件库的语义、属性、使用规则结构化，让 AI 能“读懂”组件。这直接改变了我对前端工程的理解——以后我们写的可能不只是组件，还有组件的“AI 可读层”。

所以追完这套直播，我对 AI 前端的判断已经从“AI 会替代前端”变成了一个更具体的认知：AI 前端会成长为一个独立方向，而 MCP 和 GenUI 是这个方向的两个支点。MCP 是数据与工具的连接协议，负责让 AI 触达设计稿、接口、组件库；GenUI 是界面生成范式，负责让 AI 直接产出可用、可交互的界面。搞清楚这两个东西，比多背十条提示词有用得多。

我当时还特意翻了一下社区里的热门问题，发现“前端 AI 开发”“前端 AI 工具”“MCP 协议”这些词的热度都在涨，但真正能讲清楚 MCP 工作链路的人不多。这其实是个信号：当人人都知道某个技术很重要，但大多数人还没搞明白它怎么运作时，你先跑通一遍，就已经领先了。

2. MCP协议拆解：AI与外部世界的“USB-C接口”

MCP 全称 Model Context Protocol，翻译过来是模型上下文协议。很多人第一次看到这个名字会懵，但它的作用其实特别直白：让 AI 能够调用外部工具和数据源。

2.1 MCP要解决的真实痛点

2024 年到 2025 年，AI 编程工具的爆发带来一个新的问题：每个工具都自带一堆插件机制，但插件是私有的。比如某个编辑器插件能读文件，另一个工具能操作浏览器，它们之间互不通用。AI 智能体如果想同时操作文件系统、Figma、浏览器、数据库，就得为每个工具写一套对接。这种碎片化非常严重。

我当时自己在项目里就遇到过这个问题。给 AI 接了一个能读写本地文件的插件，又接了一个能抓网页的插件，结果两个插件各自为政，AI 完全没法跨工具协作。MCP 的出现就是解决这个问题的：它定义了一套通用标准，把文件系统、数据库、设计工具、浏览器自动化这些能力都包装成“MCP Server”，AI 通过标准化的方式统一调用。

2.2 client-server-host三角色的USB-C类比

MCP 里面有三个角色，刚开始很容易绕晕。我用一个 USB-C 的类比给你讲明白。

想象一下，你的手机是 AI 客户端（Client 和 Host 的结合体），各种各样的 MCP Server 是外设：显示器、硬盘、投影仪。过去每个外设需要专属接口，今天支持 USB-C 的设备和外设，插上就能用。MCP 就是那套 USB-C 标准。Host 是那个插座板，Claude Desktop、Codex、Cursor 这些 AI 客户端都是 Host；每个 Host 内部会创建多个 Client，每个 Client 和某个 Server 建立一对一连接。

本地开发中，最常见的组合是一个 Host 挂多个 Server。比如我在 Codex 里同时挂了 Figma MCP、Playwright MCP、自己写的辅助 Server。AI 在对话里按需调用某个工具，就像你给手机接上显示器看视频，再接上硬盘拷数据，互不干扰，但都走同一个标准。

2.3 协议内部只有三步

MCP 的本质是基于 JSON-RPC 2.0 的通信协议，但剥开细看，核心流程只有三步。

第一步是握手（initialize）。Host 和 Server 启动后先交换能力信息，确认双方支持的协议版本。第二步是列工具（tools/list）。Host 问 Server“你能干什么”，Server 返回一个工具清单，每个工具都有名称、描述、参数 Schema。第三步是调用工具（tools/call）。Host 根据用户需求挑选工具，带上参数发起调用，Server 执行完把结果返回给 Host。

传输层方面，本地开发 99% 用 stdio 模式，也就是标准输入输出。你在客户端配置文件里看到的 command: "npx" 这种写法，就是让客户端通过子进程的方式启动 Server，数据走命令行管道。远程服务则用 Streamable HTTP。理解这个非常关键，因为后面排查“工具注册不上”的问题时，很多坑都出在这三步的某个环节。

2.4 为什么协议比工具更重要

我一开始也觉得，MCP 不就是一套接口吗，随便找几个现成 Server 用不就行了。但真正接完几个 Server 之后我发现，协议的理解深度决定了你排查问题的速度。MCP 生态里已经有大量现成的 Server：Figma、Playwright、GitHub、数据库连接器、联网搜索，有些还是免费的。但每个 Server 都需要配置、调试、排错，你要是不知道它的握手逻辑和工具描述格式，遇到问题只能瞎猜。

在语言上，MCP 官方提供了 TypeScript、Python、Java 等多个 SDK，也就是说，哪怕你们团队是 Java 技术栈，也能在服务端接入 MCP，并不局限于前端生态。我当时用 TypeScript 写了一个自己的小型 Server 之后，再看其他现成 Server 的配置文档，基本上一眼就能看出它们做了什么、为什么这么配。

3. Agent Skill和MCP的区别：工具与操作手册

“Agent Skill 和 MCP 有什么区别”这个问题，在我看直播的弹幕区和社区讨论里几乎天天有人问。如果你把两个概念放在一起看，确实容易混：都是给 AI 用的，都是某种“能力包”。但它们的定位完全不同。

3.1 MCP是操作员的手，Skill是行车路线图

我给一个直观的类比。MCP 解决的是“AI 能调用什么”的问题，它像是给 AI 装了一双手，能抓取数据、操作工具、碰触外部世界。Skill 解决的是“AI 应该怎么做”的问题，它像是一份行车路线图加操作手册，告诉 AI 遇到复杂任务时该按什么流程拆解、该遵循什么规范、有哪些步骤不能省。

举一个例子。假设你让 AI 完成“从 Figma 设计稿生成前端页面”这个任务：

• 只有 MCP 没有 Skill：AI 能读到设计稿数据，也能调用代码生成工具，但它不知道你们团队的代码规范是什么，不知道按钮应该用哪个组件库的哪个组件，生成出来的代码能用但不可控。
• 只有 Skill 没有 MCP：AI 知道整套生成流程和规范，但它没有数据来源，没有工具可调用，方案只能停留在纸面上。
• 两者配合：MCP 负责从 Figma 拉取设计稿、读取组件库信息、调用代码生成工具，Skill 负责把“先分析设计稿、再映射组件、再生成代码、再校验规范”这套流程注入给 AI。最后得到的代码质量完全不一样。

3.2 一张表看清定位差异

3.3 实际项目中怎么配比

我在实际项目里的配置顺序是这样的：先接好数据与工具层的 MCP Server，把 Figma、文件系统、数据查询这些能力打通；然后把团队沉淀的规范写成 Skill，比如“OpenTiny 组件使用规范”“前端代码提交规范”“从设计稿生成页面的标准流程”。这样 AI 既有了干活的工具，又有了一套靠谱的干活方法。

这里顺便说一句，面试和社区里经常有人把这两个概念做成二选一的对比，其实是不对的。它们不是替代关系，而是互补关系。MCP 解决“能用”，Skill 解决“会用”。优秀的 AI 前端工程，一定是又给工具又给方法。

4. 可复制的实战链路：MCP Server + Figma MCP 从零接入

下面这部分是我当时边看直播边动手实操的完整过程，可以照着复制。我不会只给结论，每一步都会解释为什么这么做。

4.1 为什么建议先自己写一个Server

很多教程一上来就让你配置别人封装好的 MCP Server，跑通了什么都懂了。但我的体验是：不自己写一个 Server，你永远不知道 MCP 工具列表是怎么暴露的，也不知道日志去哪看、报错为什么那么难懂。花 15 分钟写一个最小 Server，后面的排查能力会是质的差别。

4.2 用TypeScript写一个最小MCP Server

环境要求很基础：Node.js 18 以上，npm 或 pnpm 任一即可。创建一个项目目录，初始化：

bash复制mkdir frontend-helper
cd frontend-helper
npm init -y
npm install @modelcontextprotocol/sdk zod

然后创建 index.js（为方便演示用 JavaScript，TS 逻辑一样）：

javascript复制import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import fs from "node:fs/promises";

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

server.registerTool(
  "read_design_spec",
  {
    description: "读取前端设计规范或组件清单文件，返回内容给AI分析",
  },
  {
    filePath: z.string().describe("设计规范文件的绝对路径"),
  },
  async ({ filePath }) => {
    const content = await fs.readFile(filePath, "utf-8");
    return {
      content: [{ type: "text", text: content }],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

然后把它编译或直接用 node 运行。如果你使用 npm 的 type 是 module，上面代码可以直接 node index.js 跑起来。注意这个 Server 不会输出任何普通日志，它启动后会一直监听标准输入，等待客户端发来 JSON-RPC 消息。

接下来把它注册到客户端。以 Codex 为例，配置文件通常是 ~/.codex/config.toml 或 JSON 配置，具体以你客户端文档为准。核心思路是告诉客户端：启动这个 Server 的命令是什么。对于本地 node 脚本，推荐直接写绝对路径，避免环境变量丢失：

json复制{
  "mcpServers": {
    "frontend-helper": {
      "command": "node",
      "args": ["/你的绝对路径/frontend-helper/index.js"]
    }
  }
}

配置后重启客户端，新建一个对话，问它“你现在能调用哪些工具”。如果一切顺利，AI 会告诉你它有一个 read_design_spec 工具，可以读取设计规范文件。到这里，你就拥有一个属于自己的 MCP Server 了。

4.3 接入Figma MCP

跑通自己的 Server 之后，接入 Figma MCP 就简单了。核心逻辑一样，只是换成一个现成的 Figma 服务。

先在 Figma 里创建个人访问令牌。进入 Figma 的 Account settings，找到 Personal access tokens，生成一个以 figd_ 开头的令牌。创建时要勾选文件读取权限，我当时漏了这一步导致后面一直没权限。

然后把它注册到客户端：

json复制{
  "mcpServers": {
    "figma": {
      "command": "npx",
      "args": ["-y", "figma-developer-mcp", "--stdio"],
      "env": {
        "FIGMA_API_KEY": "figd_你的令牌"
      }
    }
  }
}

注意 env 是给这个子进程单独注入的环境变量，不是往你自己的 shell 里 export。很多新手会困惑“我明明设置了环境变量，为什么客户端里还是看不见”，多半就是没把 env 正确放到 server 配置下面。

配置完成重启客户端后，AI 就能读取 Figma 设计稿了。我在直播里看到他们演示的“Figma 将设计图转给 AI 写前端代码”，实际就是这么跑的。你给 AI 发一个 Figma 文件链接，它可以读取文件内图层的结构、文本内容、颜色、布局信息，然后按你的要求生成代码。

4.4 一个可复制的提示词模板

这是我当时直接从直播里抄下来改造的模板，分享给你，改成自己的项目名就能用：

code复制请读取这个 Figma 设计稿：{设计稿链接}
提取页面结构、组件层级、关键样式（颜色、字号、间距、圆角）。
然后按照以下要求实现页面：
1. 使用 OpenTiny Vue 组件库，优先使用 t-button、t-table、t-form 等组件；
2. 布局使用 CSS Grid 或 Flexbox，间距与设计稿保持一致；
3. 输出单文件 Vue 组件，并在代码注释里标明每个区块对应的设计稿节点；
4. 不要使用任何未在组件库中定义的组件。

这套模板能用，关键在于它给了 AI 三条约束：技术栈约束（组件库）、布局约束（Grid/Flex）、格式约束（单文件 Vue）。没有约束的 AI 生成代码，就像没有一个明确的验收标准，结果往往不可控。

5. 踩坑实录：“工具注册不上”背后的完整排查链路

我在跑 Figma MCP 的时候，第一次遇到的最典型问题就是“工具注册不上”——AI 客户端里完全看不到 Figma 相关的工具。社区里这个问题也很高频，尤其是“Codex 中总是工具注册不上”这种描述。我把自己踩坑的完整过程写下来，这个排查思路对所有 MCP Server 都适用。

5.1 问题现象

配置完 Figma MCP 后，我重启了客户端，新建对话问 AI：你能调用哪些工具？结果 AI 回答说只知道内置的文件工具，完全看不到 Figma 相关能力。当时第一反应是“配置格式是不是写错了”，于是对着文档检查了半天，格式没问题。

5.2 完整排查链路

第一步：直接手动启动 Server。在终端单独运行：

bash复制npx -y figma-developer-mcp --stdio

这一步非常关键。MCP Server 在 stdio 模式下不会在 stdout 打普通日志，如果启动失败，错误会输出到 stderr。如果命令秒退，或者直接报错，那问题大概率不在客户端配置，而是服务端根本起不来。我当时执行后没有任何报错，一直停留在等待状态，说明服务端本身能启动。

第二步：检查环境变量。我手动执行时没有报错，但客户端里注册不上，于是怀疑是环境变量没传进去。在终端里确认：

bash复制echo $FIGMA_API_KEY

发现这个变量根本没有设置。我在配置文件里确实写了 FIGMA_API_KEY，但它的值是从 Figma 网站复制的 token，并没有真正配置到服务启动的环境里。更隐蔽的是，有些版本会在没有 token 时直接静默退出，导致工具列表为空。

第三步：检查配置文件格式。我在 env 字段里漏了嵌套层级，导致环境变量没有被正确传给子进程。确认配置文件里 env 是否位于对应 server 配置项内部，而不是放在了全局配置下。

第四步：检查网络与拉包速度。npx -y 每次第一次运行都要从 npm registry 拉包。如果你的网络访问 npm 很慢，或者公司内网有限制，npx 可能在拉包阶段超时，从而导致 Server 启动失败。这时候可以先把包全局安装：

bash复制npm install -g figma-developer-mcp

然后把配置里的 command 改成全局命令：

json复制{
  "mcpServers": {
    "figma": {
      "command": "figma-developer-mcp",
      "args": ["--stdio"],
      "env": {
        "FIGMA_API_KEY": "figd_你的令牌"
      }
    }
  }
}

这能帮你把网络因素排除掉。

第五步：看日志。如果上述都检查完还是不行，就去找客户端日志。Codex、Claude Desktop 这类客户端通常会在用户目录下生成日志文件，里面记录着 MCP Server 的启动命令、退出码、stderr 输出。搜一下日志里的 figma 关键字，基本能定位到是启动失败还是握手失败。

5.3 根因总结

最终我遇到的原因是两层叠加：first，环境变量 FIGMA_API_KEY 没有正确导入；second，我用的 npx 拉包速度不稳定，导致 Server 启动超时。换成本地安装 + 手动设置环境变量后，问题就消失了。

还有一个高频坑我想单独提一下：如果你在自己的 MCP Server 代码里写了 console.log 来调试，切记在正式运行时注释掉。因为 stdio 模式下 stdout 只能传输 JSON-RPC 消息，任何多余的日志都会污染数据流，客户端解析会直接失败。看起来像是“工具注册不上”，其实是通信协议被破坏了。

6. GenUI重构前端：智能体组件和工程师的新位置

如果说 MCP 是 AI 前端的“数据与工具层”，那 GenUI 就是“界面生成范式”层。我追完 OpenTiny NEXT 直播，又自己动手把 MCP 链路跑通之后，才真正理解 GenUI 的野心。

6.1 GenUI到底是什么

GenUI 全称 Generative UI，生成式 UI。传统前端开发是“预先定义组件树”：开发者写死页面结构，运行时根据数据渲染。GenUI 的基本思路是：界面不再静态写死，而是由 AI 根据用户意图、上下文和实时数据动态生成。你给 AI 一个目标，它自主决定需要哪些组件、怎么布局、怎么交互。

听起来很科幻，但它不是玩具。你在 AI 客户端里看到的动态操作界面、AI 生成的表单和表格、根据上下文自动变化的操作按钮，这些都是 GenUI 的雏形。

6.2 从传统组件到智能体组件

GenUI 落地的核心载体是智能体组件。传统组件是“受控组件”，接收 props 和事件回调，渲染结果完全由外部输入决定。智能体组件不一样，它有自主能力：能感知上下文、能调用外部工具、能根据数据变化主动调整自己的展示逻辑和交互行为。

举个例子，一个“订单卡片”组件。传统写法是：父组件把订单数据传进来，卡片显示固定字段。智能体组件的版本是：组件自己去查询物流状态，发现异常时主动显示重新下单按钮，用户点一下还能弹起一个自动填好的表单。组件不再是被动展示，而是主动参与了整个交互闭环。

OpenTiny NEXT 在智能体组件方向做了不少事，比如基于 Web Components 实现跨框架的组件能力，让组件在 Vue、React、原生环境里都能工作；同时给组件增加了 AI 可读的语义描述层，使 AI 能理解组件适用范围和属性含义。这套设计让我觉得，它是真在往“AI 原生组件库”方向走，而不是简单给组件库加几个 AI 相关组件。

6.3 前端工程师的定位变化

现在回到最初那个问题：AI 出来后前端工程师是不是没了？

我的判断是：低门槛前端岗位确实在缩减，但 AI 链路相关的前端需求在上涨。以前那种“照着设计稿把页面切出来”的工作，AI 确实能做了，而且做得越来越快。但“定义界面语义”“设计智能体组件”“构建 AI 可读的组件库协议层”“排查 AI 生成代码的质量问题”，这些工作是全新的、且必须懂前端才能做的工作。

我在实际操作中体会最深的一点是：以前你的价值是“会写代码”，现在你的价值是“能定义 AI 如何写代码”。你不只是写组件，还要写组件的 AI 可读描述；你不只是接数据，还要考虑 AI 如何按你的数据 schema 生成界面。这些能力不是一句“会用 AI 工具”能替代的。

6.4 我现在会建议新人做的几件事

如果你看完这篇也想往 AI 前端方向走走，我的建议非常具体：

第一，花一个周末把手动 MCP Server 的流程跑通，自己写一个能读文件的 Server 就算及格。第二，把 Figma MCP 接入到你常用的客户端里，找一个真实设计稿跑一遍“设计稿转代码”。第三，把你最熟悉的项目的编码规范写成一个 Skill 文档，让 AI 在生成代码前参考它。第四，去读一份开源组件库的源码，比如 OpenTiny，看它的组件是如何描述自己、如何暴露给外界的。

这几件事做完，你对“AI 前端到底是什么”的理解肯定比单纯刷十条提示词要深得多。我最近和不少前端候选人聊，发现会追 AI 工具的人很多，但能讲清 MCP 工作链路、能自己写一个 Server、能把组件库语义化暴露给 AI 的人，真的不多。AI 前端不是学一个工具，而是学一套把前端能力暴露给 AI 的方法。把自己最熟悉的一个组件或页面抽象成 MCP Server 或 Skill 的那一刻，你就已经跨到了“做 AI 链路”这一侧。