1. 先弄懂 Skill 和 MCP 是什么前端用它到底图什么作为一个在职前端我今年最大的变化不是追上了哪个新框架而是习惯把 Skill 和 MCP 直接塞进日常开发流程里。刚接触这两个词的时候我也很懵Skill 不是游戏里的技能吗MCP 又是个什么协议直到我把它们真正接进组件库开发和接口联调的流程后才意识到这东西对前端的改变比想象中大得多。先花点篇幅把概念说透。MCP 全称 Model Context Protocol模型上下文协议。你可以把它理解成 AI 助手的“USB-C 接口”以前每个 AI 工具要接不同的外设都得单独做适配现在大家统一用同一个协议AI 就能通过一套标准方式去连接浏览器、文件系统、数据库、命令行这些外部工具。放到前端场景里最直观的变化是AI 不再只是嘴上说“你应该打开浏览器看一下”而是真的能通过 MCP 帮你打开浏览器、点击按钮、截图、读取控制台报错然后根据结果继续改代码。这种从“聊天顾问”到“带手带脚的操作员”的转变是整个工作流质变的核心。Skill 则更像是“岗位说明书”。它源于 Claude 等模型推出的 Agent Skills 机制本质是一组结构化的指令、参考文件和可选脚本让模型在特定任务上按你的规矩来干活。MCP 解决的是“AI 能不能操作工具”的问题Skill 解决的是“AI 做出来的东西像不像我们团队要的”的问题。比如你让 AI 写一个 Ant Design 风格的表格组件模型可能写得五花八门但如果你在 Skill 里写清楚“组件必须用 TypeScript、必须 forwardRef、必须处理暗色模式、类名必须用 BEM 规范”AI 输出的代码就会明显靠谱得多。为什么前端开发者尤其适合关注这套东西原因有三个。第一前端日常面对的全是结构化数据JSON、DOM、CSS、接口文档这些东西恰好是 AI 最擅长的输入输出格式第二前端本地环境天生适合跑 MCP 服务Node.js、浏览器、调试工具全都现成不用像其他领域那样搭一堆额外环境第三前端技术栈更新太快今天 Vite 出了新版本明天某个组件库又改了 API纯靠模型训练数据根本跟不上而 Skill 能把团队里沉淀下来的新经验持续灌进去。所以我才说MCP 和 Skill 不是给“AI 极客”准备的花活它们就是前端日常开发里真正能提效的东西。2. 在职前端搭 AI 工作流先分边界再定“手”和“脑”2.1 先明确边界哪些环节适合交给 Skill MCP哪些不适合我见过不少同事一开始就把 AI 往产品需求理解、架构设计这种最难的环节上推结果效果很差回头就说“AI 不行”。实际上 Skill MCP 这套组合最适合干的是那些有明确规则、可验证、重复劳动占比高的环节。我自己总结了一个简单的判断方法如果你能把这个任务写成一张检查清单那它就适合交给 AI如果连你自己都得拍脑袋才能决定那就别难为模型了。拿前端工作举例适合的环节包括组件骨架生成、API 模块封装、表单页搭建、单元测试补全、E2E 测试脚本、lint 和类型错误修复、组件文档查询、构建报错排查。这些任务都有清晰的输入输出边界AI 出了错你也能快速发现并纠正。不适合的环节包括产品需求背后的真实意图分析、设计稿到交互模型的高层取舍、跨模块的服务端架构决策、涉及敏感数据和合规权限的判断。这些活儿需要业务上下文和长期经验AI 目前提供不了那么多“隐性知识”。我踩过的最大的坑是让 AI 直接生成一个覆盖全业务线的复杂权限路由配置。它严格按照我给的规则生成了但一上线就出了漏洞因为有些权限规则写在企业微信审批流里根本没进需求文档。从那以后我养成了一个习惯凡是 AI 要处理的代码必须先在本地跑通 lint、类型检查、单测和构建凡是涉及权限、支付、用户数据的变更不管 AI 多自信都要有人工 review 兜底。2.2 “手”和“脑”的分工MCP 管行动Skill 管知识我实践下来最顺手的配合方式是把 MCP 当成 AI 的“手和传感器”把 Skill 当成 AI 的“工作手册”。举个例子我在给团队维护一个 React 组件库的时候MCP 负责启动 Storybook、打开浏览器、逐组件截图、读取渲染结果Skill 里则写死了组件开发规范文件命名用 kebab-case、样式用 CSS Modules、每个组件必须导出类型定义、Props 默认值必须显式声明。AI 动手操作由 MCP 负责动手前该遵守什么规则由 Skill 负责两者缺一不可。这个分工背后有个很现实的原因MCP 工具本身是“无脑”的它只知道如何执行命令并不知道执行出来的结果是否符合你们团队的价值观。Skill 则恰好补上这一层把团队在无数次 Code Review 里沉淀下来的“隐性经验”显性化。过去这些经验散落在每个人的脑子里、群聊记录里、文档角落里现在可以被打包成一个文件让 AI 每次干活前都先“读一遍”输出自然更贴近团队预期。还有一个容易被忽略的点Skill 里可以放参考代码片段这比让 AI 凭空生成强太多了。比如我把团队里一个“标准查询表单组件”的源码放进了 Skill 作为参考之后 AI 生成任何新的查询表单都会下意识模仿这个参考组件的结构。这个效果靠单纯写提示词是做不到的因为提示词描述得再详细也不如一段真实代码来得直观。2.3 工具链选型Claude Code、Codex、Cursor 怎么选都不纠结很多新手一上来就问我“到底用 Claude Code 还是 Codex 还是 Cursor”我的回答是不要纠结工具品牌先看懂 MCP 配置结构你就能在任意工具之间无缝切换。我现在主力用的是 Claude Code备选是 Codex 和 Cursor因为它们都支持 MCP 接入方式配置思路也大同小异。Claude 这边配置文件一般在claude_desktop_config.json或者项目根目录的.mcp.json里Codex 的 MCP 配置在~/.codex/config.toml或者项目级config文件里Cursor 则是在设置面板里直接管理 MCP 服务器。无论哪种工具MCP 服务器本质都是一个本地进程通过 stdio 或 SSE 跟 AI 对话。你自己写一个 MCP server放到任何支持 MCP 的工具里都能跑这才是这套体系最值钱的地方一次编写到处复用。我建议前端开发者从 Node.js 写 MCP server 开始因为前端本来就熟悉 JS/TS 生态加上modelcontextprotocol/sdk封装得很友好写一个自定义工具也就是几十行代码的事。别一上来就研究 Python 版 SDK除非你有跨语言需求先用最熟悉的语言把链路跑通后面再扩展也不迟。3. 前端高频场景落地Playwright MCP、自建文档服务、Worker 大文件上传3.1 用 Playwright MCP 给组件库做视觉回归Playwright MCP 是目前前端社区里最成熟、最“出圈”的一个 MCP 服务热搜词里一直有它的名字。它本质上是把 Playwright 浏览器的能力封装成了 MCP 工具AI 可以直接通过它打开页面、点击元素、输入文本、截图、读取浏览器控制台信息。我主要拿它做两件事一是组件库的视觉回归二是复杂交互流程的冒烟验证。接入方式很简单在你用的 AI 工具的 MCP 配置文件里加一段{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest] } } }启动后AI 会获得browser_navigate、browser_click、browser_snapshot、browser_take_screenshot这一组工具。我最常用的组合是先让 AI 用browser_navigate打开本地 Storybook 地址比如http://localhost:6006然后逐个访问每个组件的示例页截图保存到指定目录最后再和上一次的 golden 截图做比对。用起来有几个非常容易踩的坑。第一必须先启动 Storybook再让 AI 去打开页面否则浏览器会直接报连接失败MCP 本身不负责帮你启动开发服务器它只负责操作浏览器这个边界要记清楚。第二截图路径尽量用项目内的相对路径别让 AI 往系统临时目录里写不然下一轮对话它就找不到文件了。第三在 Windows 上如果浏览器安装路径带空格MCP 启动会失败解决方法是设置PLAYWRIGHT_BROWSERS_PATH环境变量把浏览器装到无空格目录里。视觉回归这事儿不是说 AI 能帮你自动通过测试而是它能把你从“手动打开每个组件页面、肉眼找差异”的重复劳动里解放出来让你只关注真正有变化的那些点。3.2 自建一个“组件文档查询”MCP Server这是我自己写过的、前端场景里性价比最高的一个 MCP 工具。背景很常见团队组件库文档散落在 Storybook 和内部 Wiki 里AI 写代码时经常想当然地编造组件 API生成一堆根本不存在的 Props每次都要人工纠正。与其反复提醒“你去看文档”不如把组件 API 数据做成一个 MCP Server让 AI 每次需要时都来查一次。我当时的做法是先把组件库的 API 信息整理成一个 JSON 文件结构大致是这样组件名、引入路径、Props 列表每个 Prop 的类型、默认值、说明、事件、插槽。然后在项目里用 TypeScript 写了一个极简的 MCP Serverimport { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { readFileSync } from node:fs; import { z } from zod; const components JSON.parse( readFileSync(./component-api.json, utf-8) ); const server new McpServer({ name: fe-docs, version: 1.0.0, }); server.tool( get_component_api, { componentName: z.string() }, async ({ componentName }) { const item components.find((c) c.name componentName); if (!item) { return { content: [{ type: text, text: 未找到组件 ${componentName} }], }; } const text [ 组件${item.name}, 引入路径${item.importPath}, Props\n${JSON.stringify(item.props, null, 2)}, ].join(\n); return { content: [{ type: text, text }], }; } ); const transport new StdioServerTransport(); await server.connect(transport);这段代码编译后把启动命令配置到 MCP 客户端里就行。之后你让 AI“写一个带搜索和分页的用户列表页”它会先调get_component_api查一下团队ProTable组件的真实 Props再动手写代码。写出来的东西从“看起来像那么回事”变成了“百分之百符合团队组件库约束”这个差异在 Code Review 时感受极为明显。写这类 Server 有一个核心心得工具返回值一定要精简。我第一版直接把整个 README 丢给 AI结果上下文被撑爆AI 反而抓不住重点。后来改成只返回组件名、引入路径和 Props 签名效果立刻好了很多。记住MCP 工具输出是给模型“看”的不是给人看的长篇文档越是浓缩成结构化数据模型越能在后续生成中准确引用。3.3 用 Worker 做大文件上传时让 AI 按约束生成可用代码热搜词里有“前端使用 worker 上传大文件”这个场景很适合展示 Skill 的约束价值。我自己在做一个项目管理工具时遇到过真实需求用户要上传单个 2GB 的视频素材直接整文件上传有两个致命问题一是页面会卡死二是上传中断后要从头再来。标准方案是切片上传加断点续传但计算文件哈希和切片逻辑如果放在主线程照样会让 UI 掉帧所以必须把计算放进 Web Worker。这里的关键点在于AI 默认生成的 Worker 上传代码往往只考虑“切个片、发个请求”完全没考虑团队约定的并发控制、失败重试、进度上报方式。这时候 Skill 的价值就出来了。我写了一个“大文件上传开发规范”的 Skill核心约束是这样--- name: large-file-upload description: 使用 Web Worker 实现大文件切片上传的开发规范包含切片大小、并发控制、重试策略、进度上报要求 --- # 约束清单 - 文件切片大小统一为 5MB不接受运行时自定义 - 文件哈希计算使用 SparkMD5必须在 Worker 线程内执行 - 并发上传数为 3禁止超过 5 - 单切片失败重试 2 次间隔 1 秒超过后标记失败 - 进度上报通过 postMessage 传递格式为 { loaded, total } - 服务端返回已上传切片索引后跳过已上传部分再续传当我把这个 Skill 写进项目后用 AI 生成上传模块它输出的代码就非常“听话”不会再自由发挥。如果你只靠普通对话让 AI 写大文件上传它每次给出的方案都可能不一样有的用 10MB 切片有的全量并发有的居然不用 worker代码风格跟团队规范完全对不上。Skill 就像给 AI 套上了一副缰绳它可以在里面自由奔驰但不能跑出你圈定的路线。3.4 把 Code Review 规范沉淀成 Skill前端 Code Review 是最适合用 Skill 替代机械劳动的环节之一。我以前在团队里 review 前端 MR翻来覆去说的就那几类问题命名不规范、副作用函数放在了不该放的位置、列表 key 用了 index、图片没加宽高导致布局抖动、按钮没考虑 loading 状态、可访问性标签缺失。这些问题每个新人都可能犯每个 review 都要重新解释一遍特别磨人。后来我把这些意见整理成了一个fe-code-reviewSkillAI 在 review MR 时会按照固定检查清单输出结论。Skill 里的检查点大致包括类型安全是否存在any滥用、是否直接修改了 props、事件绑定是否有内存泄漏风险、是否有不必要的重复渲染、样式是否出现魔法数字、国际化文案是否硬编码、错误处理是否覆盖了异常分支。每条检查点都配了一个简短的“判断标准”和“修改建议”AI 可以直接引用。实际操作中我让 AI 先用这个 Skill 过一遍 MR 的全部变更文件输出一份带着文件路径和行号的审查意见然后我再基于这份初稿做人工复核。效果非常明显以前一个中等规模的 MR 我 review 要花四十分钟现在 AI 十分钟出初稿我二十分钟复核加补充整体时间压缩了一半以上。而且 AI 审查有一个好处就是它不会因为提意见的人资历深浅而双标团队里新人也能得到一个相对客观的检查结果。但这里必须强调Skill 生成的意见只是“初筛”不能直接作为最终结论因为 AI 没有业务上下文有时候它建议“删除这段代码”实际上是业务规则要求保留的这需要人来判断。3.5 写一个“前端页面体检”SkillHTML/CSS 性能与可访问性优化热搜词里有“skill html 页面优化”我自己的做法是把这套体检项写成一个 Skill专门用来检查一个网页的渲染性能、资源体积、可访问性和语义化质量。它的典型使用场景是新同事接手一个老项目不知道怎么下手优化直接让 AI 跑一遍体检先拿一份基线报告再根据报告逐项改。我的体检 Skill 里固定了这样一套检查项首屏 HTML 里有没有明显阻塞渲染的同步脚本、图片有没有用现代格式和响应式尺寸、字体有没有换 woff2 子集、横向滚动是不是被某个固定宽度元素撑出来的、关键 CSS 有没有被内联、按钮和链接的可点击区域是不是小于 44px、表单控件有没有关联 label、对比度是否满足 AA 标准。为了让 AI 输出可执行的优化清单我在 Skill 里写明了每个检查项的“判断方式”和“合格线”比如“首屏请求体积大于 500KB 时给出按组件拆包的建议”。我拿这个 Skill 检查过自己公司一个上线两年的营销活动页AI 给出了 17 条优化建议其中有几条是之前完全没注意到的比如某个轮播组件在后台仍然定时执行动画导致页面一直处于非空闲状态。这种问题靠人肉检查很难发现AI 却能很快读出来。当然体检 Skill 的结论更多是“提示优化方向”要不要改、什么时候改还得结合业务节奏来定。4. 踩坑实录与排查技巧MCP 连不上、上下文爆炸、权限边界4.1 MCP 服务连不上的排查顺序MCP 配置虽然简单但“服务连不上”是所有人第一个会遇到的问题。我见过的失败案例里十有八九是路径问题。如果你配置的是stdout/stderr模式的 MCP server启动命令里的路径一旦写错AI 客户端根本起不了进程表现就是工具列表里永远刷不出你要的工具。排查顺序我建议从简单到复杂来先确认启动命令在终端里能直接跑通再看配置文件里的路径是不是绝对路径然后检查 Node 版本是否满足要求最后看有没有代理或防火墙拦截了本地通信。Windows 上还有个特别阴间的坑路径带空格。比如你把项目放在C:\Users\Zhang San\project如果配置里没加引号MCP 进程就启动失败。我的解决办法是给所有本地工具建立一个统一的软链目录比如D:\tools\mcp-servers把需要的外部命令都放进去配置文件里只写干净路径从根上避开空格问题。另一个常见问题是 MCP 服务可以启动但 AI 调用工具时一直超时。这通常是因为你的 MCP server 里做了阻塞操作比如同步读了超大文件、请求了外部 API 又没设超时。记住MCP 工具最好保持“快进快出”复杂的操作能拆就拆。返回结果尽量控制在几百字以内因为 AI 拿到结果后还要继续思考塞给它太多内容反而会导致上下文混乱。4.2 Skill 不生效或者输出不符合预期Skill 不生效最常见的原因是格式写错了。很多模型的 Skill 依赖文件头部的name和description字段来匹配触发条件如果你把 description 写得过于宽泛比如“用于前端开发”模型就不知道什么时候该用如果你写得过于具体它又只在极少数场景下触发。我的经验是 description 里要包含任务动词和约束关键词例如“审查 React 组件代码并输出命名、性能、可访问性检查意见”这样模型在遇到类似请求时会更容易命中。输出不符合预期则基本都是因为 Skill 内容太“玄”。比如我一开始写的 Code Review Skill 只有一句“请严格检查代码质量”结果 AI 给出的意见全是空话。后来改成可枚举的检查点清单每一条都有明确的“如何判断”和“如何修改”效果立刻不一样。Skill 不是写作文它更像一份给“实习生”看的标准化作业指导书步骤越具体产出越可控。4.3 上下文被工具输出刷爆这是一个很隐蔽但非常影响效果的问题。AI 每调用一次 MCP 工具工具返回的内容都会进入对话上下文如果返回内容特别长模型就会在一段很长的内容里抓取信息反而容易忽略关键点。我见过有人让 MCP 返回整个项目的目录树结果 AI 直接懵了连下一步该做什么都判断不出来。解决思路是在服务端做裁减只返回摘要和关键字段或者用“文件路径引用”的方式让 AI 按需再用其他工具去读取具体文件而不是一次性把内容全灌进来。我自己固定了一个原则MCP 工具的文本返回不超过 1500 个字符如果确实需要大量数据就返回一个路径然后让 AI 用文件读取工具按需访问。这样尽可能让上下文保持清爽AI 的推理质量才能稳定。4.4 权限过大的风险边界MCP 给了 AI 执行命令、读写文件、操作浏览器的能力这是福也是祸。我在本地测试机器上可以放开权限但在公司项目中一定严格限制MCP server 只允许在项目目录内读写文件绝不能让它全局执行任意命令生产环境完全不接 MCP涉及敏感 token 的环境变量也不能出现在 MCP 能读取的上下文中。这里要尤其提醒不要为了图省事让 AI 以一个拥有管理权限的终端身份去启动 MCP一旦 AI 被提示注入攻击或者理解了错误指令它能干的事远超你的想象。实操中我还会给 MCP 配置加上白名单思路只注册业务需要的那几个服务用不到的一律不挂载。每个工具都是一次潜在的权限暴露面少挂一个就少一分风险。4.5 前端安全话题的正确姿势热搜词里出现了一些关于“防止爬虫、防止查看页面源码”的讨论作为一个前端从业者我想把专业上的判断说清楚前端做的任何防护都只能提高作恶门槛无法真正阻止别有用心的人。页面源码在浏览器里必然可以被拿到JS 混淆只会增加维护成本并不会带来实际安全收益。真正有效的安全防线永远在服务端认证、限流、数据权限校验、加密传输、敏感信息脱敏这些才是投入产出比最高的事。所以我的建议是与其纠结如何在前端做“防爬虫”之类的无用功不如把精力放在怎么做好服务端安全策略和前端安全编码规范上。比如组件里不能把用户输入直接当成 HTML 渲染、跳转 URL 要校验协议、postMessage 要校验来源、第三方脚本要锁 SRI 校验。这些才是前端开发中真正有价值的安全技术操作我会在团队安全知识库里固定这些规范也建议你这样做。5. 我的实际使用体感与一个收尾小技巧Skill MCP 这套组合用下来我最直观的感受是AI 从一个只会“提出建议”的顾问变成了一个“真的能上手干初级活”的协作同事。组件骨架生成、E2E 冒烟测试、代码审查初筛、性能体检这些原本需要人肉处理的重复劳动现在都有人先干一版我再做复核和修正。这个转变不是说前端岗位被替代了而是把初级执行任务从你的待办清单里划掉让你有精力去处理真正需要经验判断的事。最后分享一个小技巧每季度清理一次 MCP 配置。我见过有人一口气挂了二十多个 MCP serverAI 每次处理任务时都要在众多工具里做选择选择越多越容易选错还会拉长响应时间。保持精简只挂你在未来一个季度确定要用的服务比追求“大而全”靠谱得多。Skill 也一样目录里不要堆几十个分类建好description 写好AI 才能在关键时刻准确命中。工具是越用越顺手但如果不去维护它也会慢慢变成一团没人敢动的复杂系统。