1. 在职前端为什么突然都在聊 Skill 和 MCP
最近半年，我身边做前端的朋友，不管是刚入行一两年的，还是干了七八年的老手，聊天话题里频繁冒出两个词：Skill和MCP。一开始我也没太当回事，以为又是哪家厂商炒出来的新概念，直到我自己在项目里真正用起来，才发现这东西确实改变了我的工作方式。
先说清楚这两个词到底指什么。Skill，你可以理解成给 AI 编程助手安装的“技能包”——它是一段封装好的指令、工具调用逻辑或者领域知识，让 AI 在特定场景下表现得更专业。比如你写一个“前端组件生成 Skill”，AI 就能按照你团队的规范自动产出符合要求的组件代码。MCP全称是 Model Context Protocol，翻译过来叫“模型上下文协议”，它解决的是 AI 模型怎么跟外部工具、数据源、服务打交道的问题。打个比方，Skill 像是给 AI 装的“APP”，MCP 则是这些 APP 跟手机系统之间的“接口标准”。
那为什么在职前端特别需要关注这两个东西？因为日常开发里大量重复劳动——写 CRUD 页面、调接口、改样式、排查构建报错、写单元测试——这些事占掉了我们太多时间。Skill 和 MCP 的组合，能把这些重复环节自动化掉相当一部分。我实测下来，一个配置得当的前端 Skill 集合，能把日常开发效率提升 30% 到 50%，这不是夸张，是实打实省下来的时间。
这篇文章适合谁看？如果你是在职前端，不管你是做管理后台、H5 活动页、还是复杂中后台系统，只要你想把 AI 真正用进日常工作流而不是只拿来聊天，那接下来的内容应该对你有用。我会从整体设计思路讲到具体实操，再到踩过的坑，尽量把每个环节都说透。
2. 整体设计思路：Skill 和 MCP 到底怎么配合
2.1 先搞清楚 Skill 和 MCP 的分工
很多人一开始会把 Skill 和 MCP 搞混，觉得都是让 AI 变强的，有什么区别？我用一个生活化的类比来解释：假设 AI 是一个刚入职的新员工，Skill 就是他的岗位培训手册，告诉他“遇到这种任务应该怎么做、按什么规范做”；MCP 则是他手里的工具箱和通讯录，让他能真正去操作文件、查数据库、调接口、发消息。
具体到前端场景，分工是这样的：
- Skill 负责“知道怎么做”：比如代码规范、组件命名约定、目录结构要求、常用工具函数用法、团队代码审查清单。这些是知识层面的东西，不需要外部工具就能生效。
- MCP 负责“能做什么”：比如读取本地文件、调用 Figma 获取设计稿、查询接口文档、操作 Git、运行构建命令。这些需要跟外部系统交互。
两者配合起来，AI 才能既懂规矩又能干活。只装 Skill 不配 MCP，AI 只能给你建议但动不了手；只配 MCP 不装 Skill，AI 能操作但产出的东西不符合团队规范。
2.2 为什么选择“Skill + MCP”而不是单一方案
我试过几种不同的路子。最早是纯靠提示词，每次对话都把规范贴一遍，效率极低而且容易漏。后来试过写脚本自动化，但脚本维护成本高，换个项目就得重写。最后落到 Skill + MCP 这套组合上，核心原因是可复用、可组合、可迭代。
可复用体现在：一个写好的“Vue 组件生成 Skill”，在 A 项目能用，在 B 项目稍微改改也能用。可组合体现在：你可以把多个 Skill 串起来，比如“读设计稿 → 生成组件 → 写单元测试 → 提交代码”这样一条流水线。可迭代体现在：团队规范变了，改 Skill 文件就行，不用改代码逻辑。
还有一个很实际的原因：MCP 是标准协议。这意味着今天你接的是 Figma，明天想换成别的设计工具，只要那个工具支持 MCP，你的 Skill 基本不用大改。这种解耦设计对长期维护太重要了。
2.3 适合在职前端的落地路径
我不建议一上来就搞一套大而全的系统，那样很容易半途而废。根据我带团队的经验，比较稳妥的落地路径是分三步走：
- 第一步，先搞定高频重复场景：比如组件生成、接口联调、样式调整。选两三个你每天都要做的事，写成 Skill，配上必要的 MCP。
- 第二步，打通工具链：把 Git、构建工具、接口文档、设计稿这些日常打交道的系统通过 MCP 接进来。
- 第三步，形成工作流：把零散的 Skill 串成完整流程，比如从需求到提测的自动化链路。
这个路径的好处是每一步都有即时收益，不会出现“投入很多但看不到效果”的情况。
3. 核心细节解析：前端 Skill 到底怎么写才管用
3.1 Skill 的基本结构长什么样
一个前端 Skill 文件，本质上就是一份结构化的指令文档。我见过不少人把它写成一大段散文，结果 AI 理解起来效果很差。比较靠谱的结构是这样的：
# Skill 名称：Vue3 业务组件生成 ## 适用场景 当需要新建一个中后台业务组件时使用 ## 输入要求 - 组件名称（大驼峰） - 组件用途描述 - 需要调用的接口列表 ## 输出规范 - 使用 <script setup> 语法 - props 必须定义类型和默认值 - 样式使用 scoped - 必须包含 loading 和 error 状态处理 ## 代码模板 （这里放具体的代码骨架） ## 禁止事项 - 不允许使用 any 类型 - 不允许在组件内直接写死接口地址这个结构的关键在于输入输出明确、禁止事项清晰。AI 最怕的就是模糊指令，你告诉它“写个好点的组件”，它只能瞎猜；你告诉它“props 必须有类型和默认值”，它就能准确执行。
3.2 前端 Skill 的几类典型场景
根据我这段时间的实践，前端 Skill 大致可以分成这么几类，每类的写法侧重点不一样：
| Skill 类型 | 典型场景 | 编写重点 |
|---|---|---|
| 代码生成类 | 组件生成、页面生成、工具函数生成 | 模板要完整，规范要具体 |
| 代码审查类 | 提交前检查、代码规范校验 | 检查项要可量化，避免主观判断 |
| 调试排查类 | 构建报错分析、运行时错误定位 | 要包含常见错误模式和对应解法 |
| 文档生成类 | 接口文档、组件文档、注释补全 | 格式要固定，字段要明确 |
| 重构优化类 | 代码拆分、性能优化、类型补全 | 要说明重构目标和约束条件 |
我自己的经验是，代码生成类和调试排查类的投入产出比最高。前者省的是写代码的时间，后者省的是查问题的时间，这两块恰恰是日常最耗精力的。
3.3 写 Skill 时最容易踩的三个坑
第一个坑：指令太笼统。比如写“生成一个表格组件”，AI 不知道你要什么表格、什么数据格式、什么交互。正确的做法是把场景拆细，比如“生成一个支持分页、排序、筛选的中后台表格组件，数据源为 RESTful 接口返回的 list 格式”。
第二个坑：没有反例。只告诉 AI 要做什么，不告诉它不要做什么，产出的代码经常夹带私货。比如你不说“不要用 index 作为 key”，它就可能给你写上。所以每个 Skill 里最好都有“禁止事项”这一节。
第三个坑：版本不更新。团队规范变了、依赖升级了，Skill 文件还停留在半年前。这个问题很隐蔽，因为 AI 还是会照常输出，只是输出的东西慢慢就不符合要求了。我的做法是每个 Skill 文件头部标注最后更新日期，每月定期 review 一次。
提示：Skill 文件不要写得太长，单个文件控制在 500 行以内。太长了 AI 理解起来会丢重点，而且维护起来也痛苦。如果一个场景特别复杂，拆成多个 Skill 组合使用。
4. MCP 接入实操：把工具链接进工作流
4.1 MCP 的基本工作原理
MCP 的核心思路是标准化模型和外部工具的交互方式。在没有 MCP 之前，每个 AI 工具想接一个外部服务，都得自己写一套适配代码，重复造轮子。有了 MCP 之后，只要外部服务实现了 MCP 协议，任何支持 MCP 的 AI 客户端都能直接调用。
从技术角度看，MCP 定义了几种基本的交互原语：资源（Resource）表示可读取的数据，工具（Tool）表示可执行的操作，提示（Prompt）表示预定义的指令模板。前端场景里，我们最常用的是 Tool 和 Resource 这两种。
举个具体例子：你有一个接口文档系统，想让 AI 能直接查询接口定义。传统做法是把文档导出成文本喂给 AI，但文档一更新就失效了。用 MCP 的做法是，接口文档系统暴露一个 MCP Server，AI 通过它实时查询最新接口定义。这样 AI 拿到的永远是最新数据。
4.2 前端常用 MCP 服务清单
根据我这段时间的实践，前端日常能用上的 MCP 服务大概有这些：
| MCP 服务 | 用途 | 接入难度 |
|---|---|---|
| 文件系统 MCP | 读写本地项目文件 | 低 |
| Git MCP | 查看提交历史、分支状态、diff | 低 |
| 设计稿 MCP | 读取 Figma 等设计工具的数据 | 中 |
| 接口文档 MCP | 查询接口定义和示例 | 中 |
| 数据库 MCP | 查询表结构和数据 | 中 |
| 浏览器 MCP | 自动化页面操作和截图 | 中高 |
| 构建工具 MCP | 触发构建、查看构建日志 | 中 |
接入难度低的基本上开箱即用，配置一下路径就行。难度中高的通常需要服务端配合，比如设计稿 MCP 需要设计团队开放权限，数据库 MCP 需要 DBA 配置只读账号。
4.3 一个完整的 MCP 配置示例
以文件系统 MCP 为例，配置大概长这样：
{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/projects/my-app/src" ] }, "git": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-git", "--repository", "/Users/yourname/projects/my-app" ] } } }配置的关键点在于路径要精确。文件系统 MCP 如果直接把整个用户目录暴露出去，一是性能差，二是安全风险高。我的做法是只暴露当前项目的 src 目录和必要的配置文件目录，其他一律不给。
注意：MCP 服务涉及本地文件读写和命令执行，配置时务必遵循最小权限原则。不要图省事把整个磁盘或者敏感目录暴露出去，这是安全底线。
4.4 MCP 和 Skill 怎么串起来用
单独用 MCP 或者单独用 Skill，效果都有限。真正好用是两者串起来的时候。我举一个实际的工作流例子：
场景：根据设计稿生成页面组件
- 通过设计稿 MCP 读取指定画板的图层结构和样式信息
- 触发“页面组件生成 Skill”，把设计稿数据作为输入
- Skill 按照团队规范生成组件代码
- 通过文件系统 MCP 把代码写入项目对应目录
- 通过构建工具 MCP 触发一次构建，验证代码没有语法错误
- 通过 Git MCP 查看变更，确认无误后提交
这一套流程走下来，原本需要半小时到一小时的活，压缩到几分钟。当然前提是设计稿本身规范，图层命名清晰，不然 AI 也读不明白。
5. 实操过程：从零搭一套前端 Skill + MCP 工作流
5.1 环境准备与工具选型
先说工具选型。目前支持 MCP 的客户端有不少，我主要用两个：一个是命令行类的，适合快速验证和脚本化；一个是编辑器插件类的，适合日常开发时随手调用。选哪个取决于你的使用习惯，但核心是要支持自定义 Skill 和 MCP 配置。
环境准备清单：
- Node.js 18 以上（大部分 MCP Server 是 Node 实现的）
- 一个支持 MCP 的 AI 客户端
- 你的项目代码（建议先拿一个非核心项目练手）
- 基础的 JSON 配置能力（MCP 配置都是 JSON）
我建议先在个人项目或者公司内部非关键项目上试，跑通了再往核心项目迁移。这样即使出问题也不会影响业务。
5.2 第一个 Skill：从组件生成开始
我建议第一个 Skill 从组件生成做起，因为这是前端最高频的场景，而且效果最直观。具体步骤：
第一步，梳理团队组件规范。把你们团队写组件的约定整理出来，包括：文件命名、目录结构、props 定义方式、样式方案、状态管理方式、错误处理方式。这一步不能偷懒，规范越清晰，Skill 效果越好。
第二步，写一个最小可用的 Skill 文件。不要一上来就追求大而全，先覆盖最核心的规范。比如先管住命名、props 类型、样式 scoped 这三件事。
第三步，拿真实需求测试。找一个你本来就要写的组件，用 Skill 生成一遍，对比手写的差异。把不满意的地方记下来，回头改 Skill。
第四步，迭代。一般迭代三到五轮，Skill 的产出质量就能达到可用水平。之后就是持续微调。
5.3 接入文件系统和 Git MCP
组件生成 Skill 跑通之后，下一步是让它能真正操作文件。接入文件系统 MCP 之后，AI 就能直接把生成的代码写到项目里，不用你手动复制粘贴。
配置要点前面说过了，这里补充几个实操细节：
- 路径用绝对路径，相对路径在不同客户端下行为不一致，容易出问题。
- 只读和读写分开配置。如果某个目录只需要读，就不要给写权限。
- 配置完之后先测试。让 AI 读一个文件、写一个测试文件，确认权限正常。
Git MCP 的接入类似，主要用途是让 AI 能查看当前分支状态、最近提交、文件 diff。这在排查问题时特别有用，比如你让 AI 分析一个 bug，它能自己去看最近的代码变更，定位到是哪次提交引入的。
5.4 串成完整工作流
单个 Skill 和 MCP 都跑通之后，就可以串工作流了。我目前用得最顺的一条工作流是“需求到提测”：
- 读取需求文档（通过文档 MCP）
- 分析需要改动的文件和组件（通过文件系统 MCP + Git MCP）
- 生成或修改组件代码（通过组件生成 Skill）
- 生成对应的单元测试（通过测试生成 Skill）
- 运行测试和构建（通过构建工具 MCP）
- 生成变更说明（通过文档生成 Skill）
- 提交代码（通过 Git MCP）
这条链路走下来，一个中等复杂度的需求，从理解到提测的时间能压缩一半以上。当然，AI 产出的代码还是需要人工 review，但 review 的工作量比从零写要小得多。
6. 常见问题与排查技巧实录
6.1 Skill 不生效或者效果差怎么办
这是最常见的问题。排查思路按顺序来：
先看 Skill 有没有被正确加载。不同客户端的加载机制不一样，有的需要重启，有的需要手动刷新。先确认 Skill 确实生效了。
再看指令是不是太模糊。把 Skill 里的关键指令拿出来，自己读一遍，问自己“如果我是新员工，看到这句话知道该怎么做吗”。如果答案是否定的，那就是指令不够具体。
然后看有没有冲突。如果你装了多个 Skill，它们之间可能有规则冲突。比如一个 Skill 说用 Options API，另一个说用 Composition API，AI 就懵了。这种情况要明确优先级。
最后看模型能力。有些复杂场景确实超出了当前模型的能力边界，这时候要么拆细任务，要么换更强的模型。
6.2 MCP 连接失败排查表
MCP 连接问题我遇到过不少，整理成一张速查表：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 启动就报错 | 命令路径不对 | 手动执行命令看报错 |
| 连接超时 | 网络或权限问题 | 检查防火墙和目录权限 |
| 工具列表为空 | 服务未正确初始化 | 查看服务日志 |
| 调用返回错误 | 参数格式不对 | 对照文档检查参数 |
| 时好时坏 | 资源竞争或超时 | 增加超时时间，减少并发 |
我踩过最坑的一个问题是路径里有空格。MCP 配置里路径带空格，某些客户端解析会出问题。解决办法是用引号包起来，或者干脆把项目放在没有空格的路径下。
6.3 安全和权限的注意事项
这块必须单独说，因为涉及本地文件和命令执行，一旦出问题后果比较严重。
- 最小权限原则：只暴露必要的目录和操作，不要图省事全开。
- 敏感文件排除：.env、密钥文件、配置文件里的密码，这些目录不要暴露给 MCP。
- 操作可追溯：重要的写操作要有日志，出问题能查。
- 定期审查：MCP 配置和 Skill 文件定期 review，清理不再使用的。
提示：如果团队多人共用一套 MCP 配置，建议把配置纳入版本管理，改动走 review 流程。这样既能保证一致性，又能避免有人误改导致安全问题。
6.4 性能优化的几个实操技巧
用久了会发现，Skill 和 MCP 多了之后，响应速度会变慢。几个优化方向：
精简 Skill 内容。把不常用的规则挪到单独的 Skill 里，按需加载。主 Skill 只保留最高频的规范。
MCP 按需连接。不是所有 MCP 都要常驻，用不到的可以关掉。比如数据库 MCP 只在需要查数据时开。
缓存常用数据。接口文档、组件列表这类不常变的数据，可以缓存起来，减少 MCP 调用次数。
拆分复杂任务。一个大任务拆成几个小任务分别执行，比一次性执行要快，而且出错更容易定位。
7. 我个人的一些实践体会
用这套东西大半年下来，最大的感受是：它改变的不是写代码的速度，而是工作的节奏。以前写一个页面，思路是“打开编辑器 → 写代码 → 调试 → 提交”，现在变成了“描述需求 → review AI 产出 → 调整 → 提交”。省下来的时间，我更多花在了理解业务、设计架构、review 代码这些更有价值的事情上。
另一个体会是，Skill 和 MCP 的质量，取决于你对团队规范的理解深度。如果你自己都说不清楚团队代码规范是什么，那写出来的 Skill 肯定也是模糊的。所以这件事反过来倒逼我把团队的规范梳理了一遍，这本身就是很有价值的产出。
最后分享一个小技巧：从最小的场景开始，快速拿到正反馈。不要一上来就想着搭一套完整系统，先写一个最简单的组件生成 Skill，用起来，感受到效率提升，再逐步扩展。这样更容易坚持下来，也更容易在团队里推广。
