1. 在职前端为什么突然都在聊 Skill 和 MCP最近半年我身边做前端的朋友不管是刚入行一两年的还是干了七八年的老手聊天话题里频繁冒出两个词Skill和MCP。一开始我也没太当回事以为又是哪家平台造出来的新概念过两个月就凉了。直到我自己在项目里真正用起来才发现这两个东西解决的是前端日常里非常具体的痛点——不是那种听起来很美好但落不了地的东西而是能实打实省下时间、减少重复劳动的工具。先说清楚它们各自是什么。Skill你可以理解成一套封装好的能力模块它把某个具体任务的处理逻辑、输入输出规范、边界条件都打包在一起调用方不需要关心里面怎么实现的只管用就行。放到前端场景里一个 Skill 可能负责把设计稿转成组件代码也可能负责对页面做无障碍检查还可能负责根据接口返回自动生成类型定义。MCP则是 Model Context Protocol 的缩写它定义了一套标准协议让不同的工具、服务、数据源能够以统一的方式被调用和组合。你可以把它想象成前端世界里的USB 接口标准——以前每个设备一个专用口现在统一了插上就能用。这两个概念放在一起对在职前端的意义就出来了Skill 提供能力MCP 提供连接方式。你不需要在每个项目里重新造轮子也不需要为了对接不同工具写一堆胶水代码。对于每天要在多个项目、多种技术栈之间切换的在职前端来说这套组合能显著降低上下文切换的成本。我写这篇东西不是要给你讲什么高深理论而是把我自己在实际工作中怎么用、踩过哪些坑、哪些场景下确实好用、哪些场景下不如手动做原原本本讲一遍。如果你也是在职前端正在被重复劳动折磨或者想看看别人是怎么把新工具融进日常开发的那接下来的内容应该对你有用。2. Skill 在前端工作流里到底解决什么问题2.1 从每次都要重新写到一次封装反复用前端开发有个特点重复性劳动特别多。表单校验逻辑、请求封装、路由配置、状态管理模板、组件脚手架……这些东西每个项目都要来一遍虽然细节不同但骨架大同小异。以前我们的做法是搞一个项目模板仓库新项目直接 clone 下来改。但模板的问题是它只能覆盖项目初始化阶段项目跑起来之后日常开发中那些零碎的重复任务模板帮不上忙。Skill 的思路不一样。它不要求你一开始就把所有东西都规划好而是针对具体任务做封装。比如我经常遇到的一个场景后端给了一个接口文档我需要在前端写对应的请求函数、类型定义、错误处理。这个任务本身不复杂但很琐碎而且容易出错——字段名写错、类型对不上、错误码漏处理都是常见问题。我后来做了一个 Skill输入是接口文档的 JSON 描述输出是 TypeScript 的请求函数和类型定义。这个 Skill 里面封装了几条规则字段名统一转小驼峰、可选字段加问号、枚举类型生成联合类型、错误码统一走一个错误处理函数。做完之后每次对接新接口我只需要把文档描述丢进去几秒钟就能拿到可用的代码然后人工检查一遍边界情况就行。省下来的时间不是一点半点。注意Skill 不是让你完全不动脑子。它处理的是确定性高、重复度高的部分边界情况和业务逻辑还是得人来判断。把 Skill 当成一个执行力很强但不懂业务的助手这个定位比较准确。2.2 哪些任务适合做成 Skill哪些不适合不是所有任务都值得封装成 Skill。我踩过的坑是一开始兴致勃勃想把所有能自动化的都自动化结果做了几个 Skill 之后发现维护成本比手动做还高。后来我总结了一个简单的判断标准判断维度适合做 Skill不适合做 Skill任务频率每周至少做一次几个月才做一次输入输出格式相对固定每次都不一样规则复杂度规则明确、可枚举依赖大量隐含经验出错成本出错后容易发现和修复出错后影响面大维护成本规则稳定、很少变动规则频繁调整举个例子根据设计稿生成组件代码这个任务如果设计稿格式统一、组件规范明确那就适合做 Skill。但如果设计稿风格多变、组件规范还在频繁调整那做 Skill 就是给自己找麻烦——你花在维护 Skill 上的时间可能比手动写代码还多。另一个我实际用下来的经验是先手动做三遍再考虑封装。如果你手动做某个任务已经做了三遍以上而且每次步骤基本一致那就可以考虑做成 Skill 了。如果只做了一两遍就急着封装很可能封装出来的东西不通用后面还得改。2.3 一个真实案例把接口联调做成 Skill 之后我拿一个具体项目来说。去年下半年我参与了一个后台管理系统的开发前端大概有四十多个接口要对接。按照以前的节奏我需要逐个看文档、写请求函数、写类型、写错误处理然后联调的时候再一个个调。整个过程大概要花两三天而且中间容易出各种低级错误。这次我换了个做法先花半天时间做了一个接口联调 Skill。这个 Skill 做的事情包括读取接口文档的 JSON 描述文件按照项目规范生成请求函数统一走封装的 request 实例生成 TypeScript 类型定义字段名转小驼峰、可选字段处理、枚举转联合类型生成基础的错误处理逻辑根据错误码走不同的提示在指定的目录下创建对应的文件做完之后四十多个接口的代码生成只花了几分钟然后我人工检查了一遍改了几个边界情况。联调的时候因为类型定义是自动生成的字段名对不上的问题基本没有了错误处理也是统一的调试起来快了很多。整个接口对接的时间从两三天压缩到了半天左右。当然这个 Skill 不是万能的。有些接口的返回结构特别复杂嵌套了好几层自动生成的类型可读性不太好这种我就手动调整一下。还有些接口有特殊的业务逻辑比如需要根据用户权限决定是否调用这种 Skill 处理不了还是得手动写。但整体来说百分之七八十的重复劳动被省掉了这就够了。3. MCP 是怎么把前端工具链串起来的3.1 MCP 的核心思路统一接口而不是统一工具很多人第一次听到 MCP会以为它是某个具体的工具或者框架。其实不是。MCP 是一套协议它规定的是工具之间怎么对话而不是用什么工具。这个区别很重要。打个比方以前你要让前端项目里的代码检查工具、测试工具、构建工具、部署工具互相配合你得为每两个工具之间写对接代码。工具 A 的输出格式和工具 B 的输入格式不一样你就得写一个转换层。工具多了之后转换层的数量是平方级增长的维护起来非常痛苦。MCP 的做法是每个工具只需要实现一次 MCP 接口之后就可以和任何其他实现了 MCP 接口的工具对话。转换层的数量从平方级降到了线性级。对于前端这种工具链特别长的领域来说这个改进的意义很大。我实际用下来的感受是MCP 最大的价值不是让你少写多少代码而是让你的工具链变得可组合。以前你想把某个新工具加进现有流程得考虑它和现有工具怎么对接现在只要它支持 MCP接进来就能用不用改现有流程。3.2 前端日常里哪些环节可以用 MCP 串起来前端的工作流大概可以分成几个阶段需求理解、设计稿处理、编码、调试、测试、构建、部署。每个阶段都有对应的工具这些工具之间以前是割裂的现在可以通过 MCP 串起来。我举几个我实际用过的场景场景一设计稿到代码的链路。设计稿工具通过 MCP 把设计信息暴露出来代码生成 Skill 通过 MCP 读取这些信息生成组件代码然后代码检查工具通过 MCP 读取生成的代码做规范检查。整条链路是自动的我只需要在最后确认一下。场景二接口文档到请求代码的链路。接口文档工具通过 MCP 暴露接口描述请求代码生成 Skill 读取描述生成代码类型检查工具验证生成的类型是否正确。这条链路我前面提过确实省时间。场景三构建产物到部署的链路。构建工具通过 MCP 暴露构建产物信息部署工具读取这些信息决定怎么部署监控工具读取部署信息开始监控。这条链路我用的还不太多因为部署环节通常有专门的运维流程但小项目里自己串一下还是挺方便的。提示MCP 的落地程度取决于你用的工具是否支持。目前支持 MCP 的工具还在增加中如果你用的工具暂时不支持也不用急着换可以先手动串联等支持了再切过去。3.3 自己搭一个最小可用的 MCP 链路要花多少功夫如果你从来没接触过 MCP可能会觉得这东西很复杂。我一开始也这么觉得后来实际搭了一个最小链路之后发现核心工作量在于理解协议本身而不是写代码。我搭的第一个 MCP 链路是接口文档到请求代码这条。具体步骤大概是找一个支持 MCP 的接口文档工具或者自己写一个简单的 MCP 服务把接口文档的 JSON 暴露出来写一个 MCP 客户端连接到这个服务读取接口描述把读取到的描述传给前面提到的接口联调 SkillSkill 生成代码写入文件整个链路的核心代码大概一两百行花了一个下午调通。调通之后后面每次对接新接口只需要跑一下这个链路就行。从投入产出比来看如果你手头有多个项目要对接接口这个投入是值得的。当然如果你只是想试试水可以先从更简单的场景入手。比如把代码格式化和代码检查这两个环节用 MCP 串起来看看效果。这个场景简单容易调通调通之后你对 MCP 的工作方式就有感觉了。4. 把 Skill 和 MCP 组合起来用的实际效果4.1 组合使用的典型模式MCP 负责连接Skill 负责执行单独用 Skill 或者单独用 MCP效果都有限。真正好用的时候是两者组合起来。我总结了一个比较典型的模式MCP 负责把数据源和工具连接起来Skill 负责对数据做具体处理。举个例子。假设我要做一个根据用户反馈自动生成 bug 修复建议的流程。这个流程里涉及几个环节从反馈系统读取用户反馈数据源从代码仓库读取相关代码数据源分析反馈和代码生成修复建议处理逻辑把建议写回反馈系统输出在这个流程里读取反馈、读取代码、写回反馈这三个环节可以通过 MCP 来连接而分析反馈和代码生成建议这个环节可以做成一个 Skill。MCP 负责让数据流动起来Skill 负责对数据做智能处理。两者各司其职组合起来就是一个完整的自动化流程。我实际用这个模式做过一个自动生成周报的小工具。MCP 负责从代码仓库、任务管理系统、文档系统拉数据Skill 负责把数据整理成周报格式。以前写周报要花半小时现在跑一下工具几分钟就出来了我只需要改改措辞就行。4.2 实测下来哪些组合确实省时间哪些是花架子用了几个月之后我对哪些组合真正有用、哪些只是看起来美好有了比较清楚的认识。下面这张表是我自己的实测总结组合场景实际效果推荐程度接口文档 请求代码生成省时明显错误率降低强烈推荐设计稿 组件代码生成省时明显但需要设计稿规范推荐代码检查 自动修复省时一般修复质量参差谨慎使用构建 部署 监控小项目好用大项目流程复杂视情况而定任务管理 周报生成省时明显格式需调整推荐代码仓库 文档生成省时一般文档质量不稳定谨慎使用从这张表可以看出来输入输出格式越固定、规则越明确的任务组合使用的效果越好。反过来如果任务本身依赖大量隐含经验或者输出质量很难自动评估那组合使用的效果就一般。我踩过的一个坑是代码检查 自动修复这个组合。一开始觉得很好检查出问题自动修复多省事。实际用下来发现自动修复有时候会把代码改得面目全非虽然检查通过了但可读性变差了。后来我改成检查出问题给出修复建议人工确认后再修复效果好多了。4.3 组合使用时的性能与稳定性注意事项Skill 和 MCP 组合使用的时候有几个性能上的点需要注意第一链路越长出错概率越高。一个链路如果涉及五六个环节每个环节都有失败的可能整体成功率就会下降。我的经验是核心链路控制在三个环节以内超过三个环节的考虑拆成多条短链路。第二数据传输量要控制。MCP 在环节之间传数据如果数据量太大传输本身就会成为瓶颈。比如你把整个代码仓库的内容通过 MCP 传给一个 Skill 处理那传输时间可能比处理时间还长。正确的做法是只传必要的数据比如只传相关文件的内容而不是整个仓库。第三要有失败重试和降级机制。链路里的某个环节失败了不能整个流程就卡住。我的做法是给每个环节加超时和重试重试几次还失败就降级——比如跳过这个环节或者用备用方案。这样即使某个环节出问题整体流程还能继续跑。第四日志要打全。链路长了之后出问题的时候排查起来很麻烦。我的做法是在每个环节的输入输出都打日志这样出问题的时候能快速定位是哪个环节的问题。日志不用打太详细关键信息就行不然日志本身也会成为负担。5. 在职前端上手这套东西的实操路径5.1 从哪个场景切入最不容易劝退如果你之前没接触过 Skill 和 MCP我建议不要一上来就搞复杂的组合链路那样很容易被劝退。比较友好的切入路径是第一步先做一个最简单的 Skill。选一个你每周都要做、步骤固定的任务把它做成 Skill。比如根据接口文档生成请求函数就是一个很好的起点。这个任务输入输出明确规则也不复杂做起来不难做完之后能立刻感受到省时间的效果。第二步把 Skill 用起来。做完之后不要放着要在实际项目里用。用的过程中你会发现一些问题比如某些边界情况没考虑到、某些规则需要调整。根据实际使用反馈来改进 Skill这样 Skill 才会越用越好用。第三步引入 MCP。当你有了几个 Skill 之后可以考虑用 MCP 把它们串起来。比如把读取接口文档和生成请求代码这两个环节用 MCP 串起来形成一个自动化的链路。这一步的难度比第一步高但因为有了前面的基础理解起来会容易很多。第四步扩展链路。当你能熟练搭建一条链路之后可以尝试把更多环节加进来形成更完整的自动化流程。但记住前面说的核心链路控制在三个环节以内太长了容易出问题。5.2 需要提前准备哪些基础能力上手这套东西不需要你是算法专家但有几项基础能力是需要的基本的脚本编写能力。不管是写 Skill 还是写 MCP 服务都需要写代码。Python 或者 JavaScript 都行看你平时用哪个多。对 JSON 格式的熟悉。Skill 和 MCP 之间的数据交换基本都是 JSON 格式熟悉 JSON 的结构和操作是必须的。基本的调试能力。链路出问题的时候你得能定位是哪个环节的问题。会看日志、会用调试工具这些基础能力要有。对前端工作流的理解。这个其实是最重要的。你得清楚前端工作流里哪些环节是可以自动化的、哪些环节的输入输出是什么格式。这个理解越深做出来的 Skill 和 MCP 链路就越实用。如果你这几项能力都具备那上手这套东西不会太难。如果某些能力还欠缺可以边做边补不用等全部准备好了再开始。5.3 我踩过的三个坑和对应的解法坑一Skill 做得太通用结果哪个场景都用不好。我一开始想做一个万能代码生成 Skill输入是自然语言描述输出是代码。做出来之后发现因为输入太自由Skill 很难处理生成质量很不稳定。后来我改成针对具体场景做专用 Skill比如根据接口文档生成请求代码、根据设计稿生成组件代码每个 Skill 的输入输出都很明确效果就好多了。解法Skill 要专用不要通用。一个 Skill 解决一个具体问题输入输出格式固定这样才稳定可靠。坑二MCP 链路太长一个环节出问题整个流程就卡住。我搭过一个涉及七八个环节的链路结果因为其中一个环节不稳定整个链路经常跑不通。排查起来也很麻烦因为环节太多定位问题要花很长时间。解法核心链路控制在三个环节以内长链路拆成多条短链路。每条短链路独立运行互不影响。这样即使某条链路出问题也不会影响其他链路。坑三过度依赖自动化忽略了人工检查。有一段时间我太依赖自动生成的代码结果有一次自动生成的代码里有个隐蔽的 bug我没检查就提交了后来测试的时候才发现。虽然 bug 不严重但这件事提醒我自动化不能完全替代人工检查。解法自动化处理确定性高的部分人工检查边界情况和业务逻辑。把自动化当成助手而不是替代品。关键代码提交前一定要人工过一遍。6. 这套东西对在职前端的长期价值6.1 从写代码的人到设计流程的人用了几个月 Skill 和 MCP 之后我最大的感受是我的工作重心在慢慢变化。以前我的时间大部分花在写代码上现在花在写代码上的时间少了花在设计流程上的时间多了。所谓设计流程就是思考这个任务应该怎么拆解、哪些环节可以自动化、环节之间怎么连接、出问题了怎么处理。这些思考以前也有但以前只是想想现在有了 Skill 和 MCP 这些工具想法可以落地成实际的流程。这个变化对在职前端来说意义挺大的。前端这个岗位写代码的能力当然重要但设计流程、解决问题的能力越来越重要。因为写代码这件事本身正在被越来越多的工具辅助甚至替代。你能设计出好的流程让工具帮你干活你的价值就体现在这里。6.2 对团队协作方式的影响Skill 和 MCP 不只影响个人工作也影响团队协作。我观察到的几个变化第一知识沉淀的方式变了。以前团队里的最佳实践通常写在文档里但文档的问题是没人看、看了也不一定照着做。现在可以把最佳实践做成 Skill大家直接用不用看文档。这样最佳实践就真正落地了。第二协作的粒度变了。以前团队协作的粒度是代码你写一个模块我写一个模块然后合起来。现在协作的粒度可以是Skill和MCP 链路你做一个 Skill我做一个 Skill然后用 MCP 串起来。这种协作方式更灵活也更容易复用。第三对成员能力的要求变了。以前团队招人主要看写代码的能力。现在除了写代码还要看能不能设计 Skill、能不能搭建 MCP 链路。这些能力在团队里的价值越来越高。6.3 接下来可以往哪些方向继续深入如果你已经上手了基础用法想继续深入有几个方向可以考虑方向一做更复杂的 Skill。从简单的代码生成 Skill扩展到更复杂的场景比如根据用户反馈自动定位问题代码、根据性能数据自动生成优化建议。这些 Skill 的输入输出更复杂处理逻辑也更有挑战性。方向二搭建更完整的 MCP 链路。从两三个环节的短链路扩展到覆盖整个开发流程的长链路。但记住前面说的长链路要拆成短链路来管理不要做成一条巨长的链路。方向三把 Skill 和 MCP 用到非编码场景。比如用 Skill 做代码审查、做技术方案评估、做项目排期。这些场景以前主要靠人工现在可以尝试用 Skill 辅助。方向四参与开源社区。现在有不少开源的 Skill 和 MCP 实现你可以参与进去贡献自己的 Skill或者改进现有的实现。这样既能提升自己的能力也能帮到别人。我个人在实际操作中的体会是这套东西的价值不在于它有多先进而在于它能不能真正融进你的日常工作。如果只是学了一堆概念但日常工作中不用那学了也白学。反过来哪怕你只做了一个简单的 Skill但每天都在用那这个 Skill 的价值就体现出来了。所以我的建议是不要贪多先从一个小场景入手做出来用起来然后再慢慢扩展。