1. 在职前端为什么突然都在聊 Skill 和 MCP
最近半年，我身边不少做前端的朋友，不管是刚入行一两年的，还是干了七八年的老手，聊天时都绕不开两个词：Skill和MCP。一开始我也没太当回事，以为又是哪个新框架或者新工具库的营销概念。直到我自己在项目里真正用起来，才发现这两个东西确实在改变前端的工作方式，尤其是对于在职开发者来说，它们解决的不是“能不能写出来”的问题，而是“能不能写得快、写得稳、写得可复用”的问题。
先说清楚这两个词在我理解里是什么意思。Skill，你可以把它理解成一种“技能封装”——把某类特定任务的输入、处理逻辑、输出格式打包成一个可调用的单元。它不一定是代码层面的函数，更多时候是一种能力描述加执行逻辑的组合。比如“根据设计稿生成组件代码”可以是一个 Skill，“把接口返回的数据转换成图表配置”也可以是一个 Skill。MCP则是 Model Context Protocol 的缩写，简单说就是一套让模型和外部工具、数据源之间建立标准化连接的协议。它让前端开发者可以把本地的、远端的各种能力挂载到模型上，让模型在生成内容时能调用真实的数据和工具，而不是凭空编造。
这两个东西放在一起，对在职前端的价值就很明显了：Skill 负责“把事做对”，MCP 负责“把事做实”。以前我们用 AI 辅助写代码，最头疼的就是它不知道你项目的具体结构、不知道你用的组件库版本、不知道你接口的返回格式。现在通过 MCP 把项目上下文接进去，再通过 Skill 把常用操作固化下来，整个开发流程的顺畅度完全不一样了。
这篇文章主要面向已经有一定前端工作经验、正在或者准备把 AI 能力接入日常开发流程的读者。我会从整体设计思路讲到具体实操，包括我踩过的坑和目前跑得比较稳的方案。如果你还在犹豫要不要花时间研究这些，我的建议是：先挑一个最痛的点试一下，大概率你会回不去。
2. 整体设计思路：Skill 和 MCP 到底怎么配合
2.1 先想清楚哪些事值得做成 Skill
不是所有事情都值得封装成 Skill。我一开始犯的错就是什么都想做成 Skill，结果维护成本比手动做还高。后来我总结了一个判断标准：高频、有固定模式、输入输出格式相对稳定的任务才值得做成 Skill。
举个例子，我在项目里经常需要根据后端返回的 JSON 结构生成 TypeScript 类型定义。这个任务几乎每个迭代都会做，输入就是一段 JSON 或者接口文档，输出就是符合项目规范的 type 文件。这种就非常适合做成 Skill。反过来，像“帮我优化这段业务逻辑”这种任务，每次的上下文和约束都不一样，做成 Skill 反而限制发挥。
具体来说，我目前沉淀下来的 Skill 主要分三类：
- 代码生成类：根据接口文档生成类型定义、根据设计稿生成组件骨架、根据路由配置生成菜单结构。
- 代码转换类：把旧版本的组件写法迁移到新版本、把 Options API 转成 Composition API、把 CSS 转成 Tailwind 类名。
- 检查与修复类：检查提交前的代码规范、自动补全缺失的 i18n 文案、修复常见的类型错误。
这三类任务的共同点是：规则明确、重复度高、人工做容易出错或者枯燥。把它们做成 Skill 之后，我只需要在对话里说一句“用接口文档生成类型”，剩下的交给 Skill 执行，我只需要检查结果。
2.2 MCP 解决的是“上下文缺失”问题
Skill 本身是相对封闭的，它知道怎么做一件事，但不知道你项目里现在是什么情况。MCP 就是来补这块的。通过 MCP，我可以把项目的文件系统、Git 仓库、接口文档、组件库文档甚至浏览器调试工具都挂载到模型上。
我目前用得最多的几个 MCP 连接：
| MCP 类型 | 作用 | 使用频率 |
|---|---|---|
| 文件系统 MCP | 让模型直接读取项目文件，不用手动粘贴 | 极高 |
| Git MCP | 查看提交历史、分支差异、 blame 信息 | 高 |
| 接口文档 MCP | 拉取最新的 Swagger/OpenAPI 定义 | 高 |
| 组件库 MCP | 查询组件 API 和示例代码 | 中 |
| 浏览器 MCP | 获取页面 DOM 结构和样式信息 | 中 |
有了这些 MCP，模型在生成代码时就不是“盲写”了。比如我让它生成一个表单组件，它会先去读项目里现有的表单组件是怎么写的，用的什么校验库，错误提示怎么展示，然后按照同样的模式生成新的。这样出来的代码风格一致，我 review 起来也快很多。
2.3 整体工作流的设计原则
我把 Skill 和 MCP 的组合使用总结成三个原则：
第一，MCP 负责“看”，Skill 负责“做”。MCP 把项目上下文拉进来，Skill 基于这些上下文执行具体操作。不要让 Skill 自己去猜项目结构，也不要让 MCP 承担太多逻辑。
第二，Skill 的粒度要适中。太细了调用麻烦，太粗了不好复用。我的经验是，一个 Skill 对应一个“可独立验收的产出物”。比如“生成类型定义”是一个 Skill，“生成类型定义并写入文件”是另一个 Skill，后者依赖前者。
第三，先手动跑通再封装。我见过不少人一上来就写 Skill，结果连手动流程都没跑顺。我的做法是，先在对话里手动把一件事做三遍，确认流程稳定了，再把它固化成 Skill。这样出来的 Skill 才是真正可用的。
3. 核心细节解析：Skill 的编写要点与 MCP 的接入方式
3.1 Skill 的描述怎么写才有效
Skill 的核心是描述。描述写得好，模型就知道什么时候该调用它、怎么调用。我踩过的坑是描述写得太模糊，比如“处理数据”，模型根本不知道是什么数据、怎么处理。后来我改成“把后端返回的下划线命名 JSON 转换成前端使用的驼峰命名 TypeScript 接口”，调用准确率立刻上来了。
一个有效的 Skill 描述应该包含四个要素：
- 触发条件：什么情况下用这个 Skill。比如“当用户提供 Swagger 文档链接并要求生成类型时”。
- 输入说明：需要什么输入。比如“Swagger 文档的 URL 或者本地文件路径”。
- 处理逻辑：做什么处理。比如“解析 OpenAPI 定义，提取所有 schema，转换成 TypeScript interface”。
- 输出格式：产出什么。比如“一个或多个 .ts 文件，每个文件对应一个模块”。
我通常还会在描述里加一个“示例”，给一个输入输出的例子。这样模型理解起来更准确，尤其是处理复杂格式转换的时候。
3.2 MCP 接入的几种方式和选择建议
MCP 的接入方式主要分本地和远端两种。本地 MCP 通常是一个进程，通过标准输入输出和模型通信；远端 MCP 则是一个 HTTP 服务，模型通过网络调用。
我目前的选择策略是：
- 涉及本地文件和命令的，用本地 MCP。比如文件系统、Git、本地构建工具。这些需要访问本机资源，走远端不安全也不方便。
- 涉及团队共享数据的，用远端 MCP。比如接口文档、组件库文档、设计规范。这些放在团队服务器上，大家共用一份，更新也方便。
- 涉及敏感信息的，坚决不接入。比如数据库连接串、密钥、用户数据。这些即使本地 MCP 也要谨慎，最好用脱敏后的数据或者只读视图。
接入 MCP 的时候有一个细节很容易被忽略：权限控制。本地 MCP 默认可能能访问整个文件系统，但实际上你只需要它访问项目目录。我建议在配置里明确指定允许访问的路径范围，避免模型误操作影响到其他文件。
3.3 一个完整的 Skill 加 MCP 配置示例
下面是我在项目里实际使用的一个配置片段，用来根据接口文档生成类型定义。这里用的是一个通用的配置格式，具体字段名可能因工具而异，但思路是一样的。
{ "mcpServers": { "project-files": { "command": "node", "args": ["./mcp/file-server.js"], "env": { "ALLOWED_PATHS": "./src,./types,./api" } }, "api-docs": { "url": "http://internal-docs.example.com/mcp", "headers": { "Authorization": "Bearer ${DOCS_TOKEN}" } } }, "skills": [ { "name": "generate-types-from-swagger", "description": "根据 Swagger/OpenAPI 文档生成 TypeScript 类型定义。当用户提供接口文档链接或文件路径，并要求生成类型时使用。输入为文档地址，输出为 .ts 文件。", "steps": [ "通过 api-docs MCP 获取 OpenAPI 定义", "解析所有 schema 定义", "按照项目规范转换成 TypeScript interface", "通过 project-files MCP 写入 ./types 目录" ] } ] }这个配置的关键点在于：Skill 的步骤里明确引用了 MCP 的名字，这样模型就知道每一步该用哪个 MCP 来获取信息或执行操作。实际使用的时候，我只需要说“根据最新的用户接口文档生成类型”，模型就会自动走完整个流程。
4. 实操过程：从零搭建一套可用的前端 Skill 工作流
4.1 环境准备与基础配置
开始之前，你需要确认几件事。第一，你用的 AI 编程工具支持 MCP 和自定义 Skill。目前主流的一些工具已经支持了，具体可以查你所用工具的文档。第二，你的项目有相对清晰的目录结构和代码规范，否则 Skill 生成的东西可能不符合你的预期。第三，准备好一个可以回滚的 Git 分支，所有实验性操作都在这个分支上做。
我建议的起步配置是这样的：
- 先只接入文件系统 MCP，允许访问项目根目录。
- 写一个最简单的 Skill，比如“读取指定文件并解释其作用”。
- 跑通之后，再逐步增加 Git MCP、接口文档 MCP。
- 每增加一个 MCP 或 Skill，都单独测试，确认没问题再继续。
这个顺序很重要。我见过有人一次性配了十几个 MCP，结果出了问题根本不知道是哪个环节的错。一步一步来，虽然慢一点，但稳。
4.2 第一个实用 Skill：接口类型自动生成
这是我建议每个人都先做的 Skill，因为它的收益最直接。具体步骤如下：
第一步，准备接口文档。如果你的后端有 Swagger 或者 OpenAPI 文档，直接拿 URL。如果没有，可以让后端导出一份 JSON 文件放到项目里。
第二步，定义输出规范。看一下项目里现有的类型文件是怎么写的。比如是不是每个模块一个文件，interface 命名用不用 I 前缀，枚举怎么表示。把这些规范写进 Skill 的描述里。
第三步，编写 Skill 逻辑。核心逻辑是：获取文档、解析 schema、按模块分组、生成代码、写入文件。这里有一个细节：生成的类型名要和后端保持一致，但字段名要转成驼峰。这个转换规则要明确写在 Skill 里。
第四步，测试与调整。拿一个简单的接口先试，确认生成的类型能通过 TypeScript 编译。然后拿一个复杂的接口试，看看嵌套对象、数组、枚举这些情况处理得对不对。有问题就调整 Skill 的描述或步骤。
我实测下来，一个中等复杂度的项目，接口类型生成这个 Skill 能节省大概 70% 的手动编写时间，而且因为格式统一，review 成本也低了很多。
4.3 第二个实用 Skill：组件代码迁移
前端项目经常遇到组件库升级或者写法迁移的情况。比如从 Options API 迁到 Composition API，或者从旧版组件库迁到新版。这种任务规则明确但工作量巨大，非常适合做成 Skill。
我以 Vue 的 Options API 转 Composition API 为例。Skill 的核心逻辑是：
- 识别 Options API 的结构：data、methods、computed、watch、生命周期钩子。
- 把 data 转成 ref 或 reactive。
- 把 methods 转成普通函数。
- 把 computed 转成 computed 函数。
- 把 watch 转成 watch 或 watchEffect。
- 把生命周期钩子转成对应的组合式函数。
这里有几个坑要注意。第一，this的指向问题。Options API 里到处是this，转成 Composition API 后要全部去掉，改成直接引用变量。第二，mixin的处理。如果组件用了 mixin，迁移时要手动把 mixin 的逻辑展开。第三，模板引用的变化。有些写法在两种 API 下不一样，需要同步调整模板。
我的做法是，先让 Skill 生成转换后的代码，然后人工 review 一遍，重点检查this相关的逻辑和异步操作。确认没问题后再替换原文件。这样虽然多了一步 review，但比纯手动改还是快很多，而且不容易漏掉细节。
4.4 第三个实用 Skill：提交前自动检查
这个 Skill 严格来说不算代码生成，而是质量把关。我把它挂在 Git 的 pre-commit 钩子上，每次提交前自动跑一遍。
检查内容包括：
- 类型检查：跑
tsc --noEmit，确保没有类型错误。 - 规范检查：跑 ESLint，确保代码风格一致。
- 文案检查：扫描新增的中文文案，确认是否都加了 i18n 包裹。
- 接口检查：对比接口文档，确认调用的接口和字段都存在。
这个 Skill 的价值在于，它把很多低级错误挡在了提交之前。以前经常出现的情况是，本地跑得好好的，提交后 CI 挂了，一看是某个类型没对上或者文案漏了 i18n。现在这些问题在提交前就暴露了，省了很多来回。
配置的时候要注意，检查要快。如果跑一次要几分钟，大家就会想办法绕过它。我的经验是，只检查变更的文件，不要全量检查。另外，检查失败的提示要清晰，直接告诉开发者哪个文件哪一行有问题，怎么改。
5. 常见问题与排查技巧实录
5.1 Skill 调用不准确怎么办
这是最常见的问题。模型要么不调用 Skill，要么调用了但传参不对。排查思路如下：
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| 不调用 Skill | 描述太模糊，模型没识别出场景 | 在描述里加具体触发词和示例 |
| 调用但传参错误 | 输入格式说明不清晰 | 明确输入类型和格式，加示例 |
| 调用后结果不对 | 处理逻辑有歧义 | 把步骤拆细，每步写清楚 |
| 频繁误调用 | 触发条件太宽泛 | 收窄触发条件，加排除说明 |
我的经验是，Skill 的描述要像写给一个新同事看的操作手册，不能有歧义。你觉得理所当然的事情，模型可能完全理解不了。多写几句说明，比事后反复调试省时间。
5.2 MCP 连接不稳定或超时
MCP 连接问题通常有几个来源。本地 MCP 可能是进程启动失败或者权限不足；远端 MCP 可能是网络问题或者认证过期。
排查步骤：
- 先单独测试 MCP 是否可用。大多数 MCP 工具都有独立的测试命令，先确认 MCP 本身没问题。
- 检查配置里的路径、URL、Token 是否正确。尤其是环境变量，很容易漏配。
- 看日志。MCP 的日志通常会告诉你连接失败的具体原因，比如“connection refused”或者“401 unauthorized”。
- 如果是远端 MCP，确认服务端是否正常运行，防火墙是否放行。
我遇到过一次远端 MCP 一直超时，查了半天发现是服务端的证书过期了。这种问题不看日志根本猜不到。
5.3 生成的代码不符合项目规范
这个问题通常是因为 Skill 里没有把项目规范写清楚。解决方法是把规范显式地写进 Skill 描述里，或者通过 MCP 读取项目的配置文件（比如.eslintrc、tsconfig.json、.prettierrc），让模型自己遵守。
我现在的做法是，在 Skill 的步骤里加一步“读取项目根目录的配置文件”，这样模型在生成代码前就知道项目的规范是什么。另外，我还会在 Skill 里加一个“自检”步骤，让模型生成后自己对照规范检查一遍。
5.4 性能与成本控制
Skill 和 MCP 用多了，token 消耗会明显上升。尤其是文件系统 MCP，如果每次都把整个项目读一遍，成本很高。
我的优化措施：
- 限制 MCP 的访问范围。只允许访问必要的目录，不要整个项目都开放。
- Skill 里指定读取哪些文件。不要让模型自己决定读什么，直接在 Skill 里写清楚需要哪些文件。
- 缓存常用结果。比如接口文档解析后的 schema，可以缓存起来，不用每次都重新拉取。
- 定期清理不再使用的 Skill 和 MCP。有些实验性的配置用完就删，避免每次对话都加载。
实测下来，经过优化的工作流，token 消耗能降低一半以上，响应速度也快很多。
5.5 团队协作中的注意事项
如果你想把 Skill 和 MCP 推广到团队，有几个点要提前考虑。
第一，配置要统一。每个人的 MCP 地址、Skill 版本要一致，否则同样的指令在不同人那里结果不一样。我建议把配置放在项目仓库里，大家共用一份。
第二，要有版本管理。Skill 的修改要像代码一样走 review 和版本记录。不然改坏了都不知道是谁改的。
第三，要留手动兜底方案。不是所有人都愿意用 AI 辅助，也不是所有场景都适合。保留手动操作的可能性，不要强制所有人都用同一套流程。
第四，注意信息安全。接入 MCP 的时候，确保不会把敏感信息暴露给外部服务。尤其是远端 MCP，要确认数据加密和访问控制到位。
6. 我目前的工作流和几点真实体会
我现在的工作流大概是这样的：早上到公司，先拉最新代码，然后让模型通过 Git MCP 看一下昨天的提交和今天的任务列表。接着用接口文档 MCP 拉取最新的接口定义，用类型生成 Skill 更新类型文件。开发过程中，遇到重复性的代码转换或者生成任务，直接调用对应的 Skill。提交前跑一遍检查 Skill，确认没问题再推。
这套流程跑下来，我感觉最大的变化不是写代码变快了，而是心智负担变轻了。以前很多琐碎的事情要记在脑子里，现在都交给 Skill 和 MCP 了，我可以把精力放在真正需要思考的地方，比如业务逻辑的设计、边界情况的处理、性能的优化。
当然也有不爽的时候。比如 Skill 偶尔会抽风，生成一些莫名其妙的东西；比如 MCP 连接断了，要花时间排查。但总体来说，收益远大于成本。
如果你问我建议从哪里开始，我的答案是：从你最烦的那件事开始。每个人烦的事情不一样，有人烦写类型，有人烦改组件，有人烦写测试。找到那件事，手动做三遍，然后把它做成 Skill。不用追求大而全，先解决一个点，尝到甜头之后你自然会想解决下一个。
最后分享一个小技巧：Skill 的描述里可以加一句“如果不确定，先问用户”。这样模型在遇到模糊情况时会主动确认，而不是瞎猜。这个小小的改动，能避免很多返工。
