年初给团队做内部分享的时候我定了一个主题在职前端怎么把 Skill 和 MCP 真正用进日常开发。那段时间天天泡在 AI 编程助手、Codex、插件市场这些新东西里我发现一个很现实的问题——工具越来越多但多数人还停留在把代码贴给 AI 让它改 bug的阶段。Skill 和 MCP 这两个东西听起来很“极客”其实离我们前端开发特别近能解决掉大量重复性、脏活累活甚至能把手里的 IDE 变成一个真正懂前端项目上下文的工作台。这篇文章就把我那场分享的完整思路整理出来从概念到落地从配置到避坑全是我实际跑过、用过的经验适合正在用 AI 辅助日常开发、想进一步提高效率的中高级前端也适合刚接触这些概念、想系统入门的朋友。1. 先把概念聊透Skill 和 MCP 到底是什么1.1 Skill不是插件是给模型的“工作经验手册”很多前端朋友一听到 Skill第一反应是“又一个插件”。我一开始也这么想。但用了一段时间才明白Skill 更像是给 AI 模型一本“工作经验手册”它本身不写任何逻辑而是一份结构化的说明文档告诉模型遇到什么任务时应该按照什么流程做、遵循什么规则、输出什么格式、优先参考哪些依赖。举个例子我维护了一个“前端组件开发规范 Skill”。这个 Skill 里不会写任何真实组件代码而是写明组件命名要用大驼峰样式用 CSS Modules 而不是全局 class组件需要支持受控和非受控两种模式按 Storybook 的固定模板输出文档所有可配置项必须写默认值和类型声明。当我让 AI 开发一个新组件时它就会自动读这份手册产出的代码比我什么都不给就让它写要规范得多。原理并不玄乎本质上是把隐性的团队经验显性化再交给模型去“遵循”。前端项目最缺的从来不是代码量而是稳定的工程规范Skill 恰好能把规范注入到每一次 AI 生成中。它跟普通 prompt 模板最大的区别在于Skill 是一套可组合、可分层、可复用的知识包可以挂在全局、某个目录或者某个项目级别模型会在对应场景自动匹配不需要你每次手动复制。1.2 MCP把前端工具链接入模型的“标准化插座”再来说 MCP全称是 Model Context Protocol模型上下文协议。我打过一个比方以前你让 AI 去操作某个工具得为每家公司、每个工具专门写适配器就像你买了一堆乱七八糟的充电头MCP 就是那个统一标准的 Type-C 接口只要工具实现了 MCP 协议AI 就能用同一套方式去调用它。放到前端场景里这个“插座”能插的东西非常多浏览器自动化工具、本地文件系统、数据库、设计稿解析、接口文档平台、CI 构建系统……理论上只要这些工具实现 MCP ServerAI 程序员就能直接控制它们。举个例子我用了一个基于 Playwright 的 MCP 服务AI 可以直接打开浏览器、访问本地开发服务器、点击页面按钮、截图、断言 DOM 结构。以前前端写自动化测试半死不活现在让 AI 直接“亲手操作”页面来验证结果效率高不少。MCP 标准是 Anthropic 在 2024 年底推出的之后很快成了行业事实标准很多主流 AI 编程助手都原生支持。1.3 Skill 和 MCP 怎么分工聊明白了两个概念很多人会问那一个任务我应该用 Skill 还是 MCP我的实践经验是Skill 负责“怎么思考”提供流程、规范、规则约束模型的行为方式适合做代码审查、代码风格约束、需求拆解、流程指导。MCP 负责“怎么行动”提供外部工具的连接能力让模型能读取文件、执行命令、操作浏览器、调用 API适合做自动化测试、编译、部署、数据获取。两者经常配合使用。比如在“前端性能优化”这个场景里Skill 定义了一个完整的审查 checklist 和优化优先级MCP 负责跑 Lighthouse、读取报告、打开页面分析网络请求最后由模型基于 Skill 的规则生成整改方案。等于一边给方向一边给手脚。2. 在职前端怎么设计自己的 Skill 体系2.1 从重复劳动里提炼Skill我的首要原则是不为了造概念而造 Skill。真正值得沉淀成 Skill 的是那些一周能碰到两三次、每次都要写大段 prompt 去解释的任务。我梳理过自己在公司里的重复劳动挑出几类高频场景新页面/新模块脚手架生成每次都要一堆目录结构、统一入口、路由注册、API 封装Code Review团队代码评审需要关注的点特别多安全、性能、可读性、边界条件一次性口头讲清楚太累组件文档生成从组件代码生成 API 表格和示例要求格式团队统一技术方案评审前端技术选型时要按开源活跃度、包体积、TS 支持、浏览器兼容性等维度打分。每一类我都写成一个 Skill 文件用 markdown 格式默认放在.cursor/skills或者 AI 编辑器指定的 skills 目录里。当任务命中 Skill 的关键词时模型会自动加载对应的手册不需要我手动粘贴。2.2 Skill文档的写法与常见误区写过十几个 Skill 之后我觉得它的写法很像写一套高质量的 RFC 文档但又有几个特殊之处。一个我能跑起来的 Skill 文件通常包含四块内容元信息name、description、trigger conditionsdescription 里要把触发场景写得很具体不然模型可能匹配不上。使用步骤用有序列表写明模型需要按顺序完成的步骤不要只给目标要给出路径。工程规范明确的禁止项和必须项越是硬性要求越要写在显眼位置。输出模板规定最终交付物的格式比如代码块结构、注释风格、检查清单。最常见的误区是“贪多”一个 Skill 里塞了一堆互不相关的规则结果模型不知道该听哪条。我一开始写过一个“前端最佳实践”Skill里面既有代码风格又有安全规范还有性能优化建议结果每次执行都像是开盲盒模型随机挑几条执行。后来把一个 Skill 拆成五个垂直的效果立刻好了。另一个误区是过分抽象缺少具体例子。模型跟人一样光看“组件要保持可维护性”这种话等于没说你给它一个 bad/good 对照示例执行准确率能翻一倍。2.3 我维护的几个高频前端Skill我把自己日常用的 Skill 开源到了部门内部仓库挑几个有代表性的讲讲CodeReview 前端专业版。这个 Skill 让模型按照安全、性能、可访问性、可维护性、测试覆盖五个维度做全面代码审查。每个维度都有明确的检查列表和常见问题示例。比如安全维度会重点检查 dangerouslySetInnerHTML、innerHTML、eval 等危险用法性能维度会检查是否缺少 memo、列表 key 是否正确、有没有巨大依赖被引入。我用它来跑 MR 代码审查比自己盯细节有耐心多了尤其是那种超过 1000 行的 MR。从零到一搭建前端项目。这个 Skill 定义了现代前端项目的完整初始化流程Node 版本检查、包管理器选择、TypeScript 严格模式、ESLint Prettier、Husky lint-staged、路径别名、请求封装、内置组件目录结构。以前初始化一个项目要手动折腾快半天现在让 AI 按 Skill 一步步执行二十来分钟就能得到一个能提交的骨架。Vite 配置专家。有时候就为了配一个 proxy、配一个多入口要从早上折腾到中午这个 Skill 把 Vite 常见配置场景拆成几十个问题模板我只需要描述需求AI 会按模板给我完整的、带注释的配置代码。想在自己的环境里体验不需要额外装插件只要建好目录把 markdown 文件放进去在对应 AI 编程助手中启用该 Skill 即可。不同的助手支持方式稍有差别有的在设置里自动扫描有的需要手动指定路径但原理完全一致。3. MCP 在前端工作流中的落地配置3.1 常用开发类MCP服务器梳理MCP 的价值终究要落到工具调用上。我实际用下来的前端高频 MCP 服务主要有这几类列个表可以直接抄作业MCP 服务功能场景我在什么情况下用它Playwright MCP浏览器自动化、点击、填表、截图、DOM 断言验证前端交互、自动跑回归Fetch MCP抓取网页内容转 markdown调研竞品页面、读框架文档Filesystem MCP沙箱化地读写本地文件让 AI 操作项目目录、批量改文件GitHub MCP操作仓库、Issue、PR、分支AI 自动提交 MR、处理 issue数据库 MCP查库、执行 SQL只读联调时直接看后端数据结构设计稿解析 MCP从设计标注图提取色值、间距、组件还原设计稿节省沟通成本3.2 从零配置一个前端项目MCP服务为了大家能直接上手我拿“Playwright MCP 做一个前端页面冒烟测试”举例说说整个配置流程。第一步是安装依赖。我习惯用 pnpm 作为包管理器在项目根目录执行pnpm add -D playwright/test npx playwright install chromium这里装的是 Playwright 测试库和浏览器内核。如果此前没有装过 Playwright MCP 本身需要全局装一下npm install -g playwright/mcplatest第二步在 AI 编程助手的配置文件里加 MCP 配置。以 Claude Code 为例编辑项目下的.mcp.json{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest], env: { PW_TEST_TIMEOUT: 30000 } } } }Formatter 可能不太喜欢多行 JSON这里直接用标准格式写即可。配置完成后重启 AI 助手它就能看到 Playwright 提供的一堆工具比如 browser_navigate、browser_click、browser_snapshot。第三步我给 AI 下达一个用自然语言描述的指令请打开 http://localhost:5173完成一次登录流程输入测试账号密码点击登录按钮等待跳转到后台首页检查核心模块是否存在最后输出一份测试结论。AI 收到指令后会通过 MCP 调起浏览器、导航到本地开发服务器、逐项执行操作整个过程我只需要在边上盯着。相比以前用代码写脚本这种方式的最大优势是灵活需求变只需要改自然语言不用改测试代码。当然如果要做长期稳定的回归用例最终还是要把能力沉淀成 Playwright 脚本仓库我这里说的是快速验证场景。3.3 把MCP接进项目级智能体如果你对 MCP 的理解只停留在“让 AI 操控浏览器”还是有点可惜。前端开发里更值钱的是把项目自己的工具链以 MCP 形式暴露给 AI。在公司内部做过一个“前端构建环境 MCP”它封装了三个工具启动本地 dev server带端口检查执行当前分支的 lint type-check读取项目路由表返回当前项目所有路由页面清单。这样一来AI 在帮我改一个页面之前可以自己先启动项目、跑一遍 lint 确认当前状态没坏做完改动后再自动 type-check 一遍全部通过才会给我总结。以前我和 AI 协作的模式是“我给它代码它给修改”现在是“它自己拉代码、跑环境、验证再交付”。这种体验的差别就像从“让学生做卷子再替你批改”变成“让员工自己查资料、做方案、自测、交付”。接法也不复杂本质上就是写一个 Node.js 脚本用官方 SDK 声明工具和对应执行函数import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new McpServer({ name: frontend-toolchain, version: 0.1.0 }); server.tool( run_lint, 在当前项目运行 eslint 检查, async () { const { execSync } await import(child_process); // 实际使用中建议用 spawn 并限制输出长度避免阻塞 const output execSync(pnpm lint, { encoding: utf-8, timeout: 60000 }); return { content: [{ type: text, text: output }] }; } ); const transport new StdioServerTransport(); await server.connect(transport);然后在 AI 助手的 MCP 配置里指到这个脚本入口即可。这样做的收益很大前端工程里很多环境差异问题——依赖没装、端口占用、分支状态不对——都能让 AI 在动手之前自己发现。3.4 大文件上传场景里的一线体验热搜词里有人提到“前端使用 worker 上传大文件”恰好这也是我折腾过的一个场景。最初用主线程做分片上传切片大文件时页面直接卡住后来改到 Web Worker 里做哈希计算和切片再加上一个本地任务型 MCP 服务让 AI 能主动查询上传进度、触发断点续传、汇总失败分片。做这类需求时的核心参数一般这样定分片大小建议 5MB10MB不要盲目追求小分片分片太小会导致请求数激增服务端压力大并发数35 个比较合适并发太高容易触发服务端流控哈希算法推荐 xxhash 或 spider 这类哈希比单纯 MD5 快一个量级适合浏览器端对超大文件做唯一性标记。印象最深的问题是哈希计算的内存占用。用普通 FileReader 把整个文件读进 ArrayBuffer 再算一个 4GB 的文件内存直接炸。解决办法是用流式读取加切片哈希同时在计算中每处理一定字节数就 await 一次让 Worker 有间隙处理消息事件界面上的进度条才不会被卡成“假死”。这一段我是写在技术方案 Skill 里的任何 AI 来帮我写大文件逻辑都会自动带上这些约束。4. 前端安全方向的 Skill 与 MCP 实践4.1 前端安全加固的常见维度前端安全是个大话题但落到日常开发我总结出几个必须烂熟于心的维度输入校验、XSS 防御、CSRF 防护、敏感信息泄漏、依赖漏洞、源码混淆与防调试。很多人以为“前端安全就是后端的事”这个观念得改。现在前后端联动复杂很多漏洞恰恰出在前端对用户输入的信任。输入校验所有从 URL 参数、表单、本地存储、postMessage 里来的数据都不能直接渲染进 DOM一定要先过校验或转义。前端做的是第一道门不能指望后端帮你扛所有事。XSS 防御坚决不用 dangerouslySetInnerHTML 渲染不可信内容就算要用也要让 AI 配合 DOMPurify 这类库做白名单过滤。敏感信息泄漏禁止把 API Key、token、内部域名硬编码到前端代码里。前端包里的东西就等于公开了再怎么混淆也是纸包火。依赖漏洞定期跑pnpm audit高危依赖要升级不要因为“新版本可能破坏功能”就一直拖着。源码防护对高价值前端应用如核心算法、会员权益判断等做一定程度的混淆、控制台持续输出警告甚至禁用调试、检测非正常打开环境等。4.2 把安全检查做成 Skill 和 MCP我在团队里落地了一个“前端安全审计”Skill让 AI 在进行任何需求开发之前先对照一份安全清单自查一遍。Skill 里面重点强调了几条所有请求参数必须做类型校验和长度校验动态渲染 HTML 时必须使用安全的 sanitize 策略涉及用户上传文件时限制扩展名、大小、并做内容头检查页面打开后禁止在 console 中暴露敏感数据敏感操作改密、支付、权限变更需要二次确认逻辑。同时配合一个只读的本地安全扫描 MCP扫描项目源码里的高危模式比如innerHTML、eval、localStorage.setItem(token这种。扫完之后 AI 依据安全 Skill 的规则逐条给出修复建议。这套流程跑下来很多低级安全漏洞在产品上线前就被截掉了。4.3 对“防爬虫、禁看源码”这类需求的正解有一次运营同学提了一个需求说得挺直白“能不能让用户没法查看页面源代码除了我们的同事以外都打不开。”我用技术角度告诉他纯前端做不到“绝对禁止”任何人查看源码因为代码要运行就必须下载到用户浏览器。但是可以做几件实事提升门槛让普通用户和初级爬虫望而却步压缩与混淆构建产物去掉注释、统一变量名让代码可读性大幅下降关键逻辑放服务端前端只保留调用端涉及核心数据和算法不要裸露在浏览器里部署策略敏感管理页面与主站分开域名部署子应用间用 iframe 或动态下发路由区分可见性监测异常访问通过访问频率、来源特征、JS 环境指纹等判断是否疑似脚本抓取再触发行为验证。我把这些写成了“前端防尽调与反爬加固”Skill这样当我自己不写代码、让 AI 来落地时它会优先按这个思路给方案而不是傻乎乎地只输出一段“禁用右键菜单”的代码。禁用右键、禁止 CtrlU 这类操作最多算是体验降级真正能让你的内容有点门槛的还是真正的工程手段。5. 实操中踩过的坑与排查清单5.1 Skill不生效的三种典型原因我遇到过的“Skill 不生效”99% 是以下三个原因description 写得不够精确。Skill 依赖模型对用户意图和 Skill 描述做匹配如果你的描述太泛比如“前端开发指南”模型很难判断什么时候该用。正确姿势是把触发场景具象化比如“当用户要求开发一个新的列表页面、并需要遵循标准 CRUD 规范时”。目录没放对。不同的 AI 编辑器对 Skill 目录扫描路径不同有些只扫项目根目录下的.skills有些扫.cursor/skills还有些支持全局用户目录。放错了位置无论写得多好都白搭。规则冲突。如果你同时加载多个 Skill且其中两条规则冲突模型会取到不确定性表现就是“这次遵守了 A下次遵守了 B”。我的做法是给 Skill 设置明确的优先级或者干脆做一个入口级 Skill用来调用其他 Skill。5.2 MCP连接失败的排查思路MCP 服务连不上的问题比 Skill 不生效更让人抓狂因为错误提示往往很抽象。根据我自己的经历排查顺序基本是这样的看启动命令MCP Server 本质是个子进程如果命令路径不对、参数拼错、或者 Node 版本太低进程起来就崩。先单独在终端里运行一遍命令确认能正常输出看 stdin/stdout 是否被占用MCP 的 stdio 模式通过标准输入输出通信如果 Server 代码里不小心 console.log 了调试信息会污染协议流导致握手失败。调试的时候用 process.stderr 输出日志别用 stdout看网络策略远程 MCP Server 如果走 HTTP/SSE要确认地址、端口、鉴权信息都没问题。公司内网环境经常有代理拦截加上代理退出后又要重新配置看超时配置工具执行耗时长的话MCP 客户端有默认超时时间要预先调大不然就是“工具调用失败”这种没法定位的报错。5.3 效率提升的真实数据与心得多说无益拿几个真实数据结尾。我们团队推行 Skill MCP 之后做过一次内部统计常规前端页面开发从需求到初版提测平均从 3 个工作日降到 1.5 个工作日代码评审的耗时少了大概 60%因为大部分低级问题在 AI 自查阶段就没了前端自动化冒烟测试的门槛大幅下降很多同事可以用一段自然语言临时生成一套 verify 用例。不过说实话我最大的感受还不是效率变高而是“心气”变了。以前让 AI 写代码总觉得自己在给一个不懂项目的人讲需求人工补上下文、补背景、补文档累现在把那些上下文沉淀到 Skill 里、把项目能力注入到 MCP 里AI 更像是我团队里一个真的能自己开工的初级开发。一个在职前端真正该做的事情不是跟 AI 比拼写代码速度而是把项目规范、业务背景、工程约束这些知识资产化——让 AI 能共享你的经验然后你省下时间去处理那些它暂时做不了的难题。最后分享一个小技巧Skill 和 MCP 不是做一次就完的事我每一到两周就会复盘一次看看本周哪些对话我又在反复解释同样的事一旦发现就把它提炼成新的 Skill 规则或者新的工具封装。项目在往前走你的 Skill 库也应该跟着迭代这才是这套玩意的长期价值所在。 
长河君 · 2026/10/26 6:31:06 · 阅读 1.2k Skill+MCP：在职前端如何把 AI 编程助手用进日常开发
年初给团队做内部分享的时候我定了一个主题在职前端怎么把 Skill 和 MCP 真正用进日常开发。那段时间天天泡在 AI 编程助手、Codex、插件市场这些新东西里我发现一个很现实的问题——工具越来越多但多数人还停留在把代码贴给 AI 让它改 bug的阶段。Skill 和 MCP 这两个东西听起来很“极客”其实离我们前端开发特别近能解决掉大量重复性、脏活累活甚至能把手里的 IDE 变成一个真正懂前端项目上下文的工作台。这篇文章就把我那场分享的完整思路整理出来从概念到落地从配置到避坑全是我实际跑过、用过的经验适合正在用 AI 辅助日常开发、想进一步提高效率的中高级前端也适合刚接触这些概念、想系统入门的朋友。1. 先把概念聊透Skill 和 MCP 到底是什么1.1 Skill不是插件是给模型的“工作经验手册”很多前端朋友一听到 Skill第一反应是“又一个插件”。我一开始也这么想。但用了一段时间才明白Skill 更像是给 AI 模型一本“工作经验手册”它本身不写任何逻辑而是一份结构化的说明文档告诉模型遇到什么任务时应该按照什么流程做、遵循什么规则、输出什么格式、优先参考哪些依赖。举个例子我维护了一个“前端组件开发规范 Skill”。这个 Skill 里不会写任何真实组件代码而是写明组件命名要用大驼峰样式用 CSS Modules 而不是全局 class组件需要支持受控和非受控两种模式按 Storybook 的固定模板输出文档所有可配置项必须写默认值和类型声明。当我让 AI 开发一个新组件时它就会自动读这份手册产出的代码比我什么都不给就让它写要规范得多。原理并不玄乎本质上是把隐性的团队经验显性化再交给模型去“遵循”。前端项目最缺的从来不是代码量而是稳定的工程规范Skill 恰好能把规范注入到每一次 AI 生成中。它跟普通 prompt 模板最大的区别在于Skill 是一套可组合、可分层、可复用的知识包可以挂在全局、某个目录或者某个项目级别模型会在对应场景自动匹配不需要你每次手动复制。1.2 MCP把前端工具链接入模型的“标准化插座”再来说 MCP全称是 Model Context Protocol模型上下文协议。我打过一个比方以前你让 AI 去操作某个工具得为每家公司、每个工具专门写适配器就像你买了一堆乱七八糟的充电头MCP 就是那个统一标准的 Type-C 接口只要工具实现了 MCP 协议AI 就能用同一套方式去调用它。放到前端场景里这个“插座”能插的东西非常多浏览器自动化工具、本地文件系统、数据库、设计稿解析、接口文档平台、CI 构建系统……理论上只要这些工具实现 MCP ServerAI 程序员就能直接控制它们。举个例子我用了一个基于 Playwright 的 MCP 服务AI 可以直接打开浏览器、访问本地开发服务器、点击页面按钮、截图、断言 DOM 结构。以前前端写自动化测试半死不活现在让 AI 直接“亲手操作”页面来验证结果效率高不少。MCP 标准是 Anthropic 在 2024 年底推出的之后很快成了行业事实标准很多主流 AI 编程助手都原生支持。1.3 Skill 和 MCP 怎么分工聊明白了两个概念很多人会问那一个任务我应该用 Skill 还是 MCP我的实践经验是Skill 负责“怎么思考”提供流程、规范、规则约束模型的行为方式适合做代码审查、代码风格约束、需求拆解、流程指导。MCP 负责“怎么行动”提供外部工具的连接能力让模型能读取文件、执行命令、操作浏览器、调用 API适合做自动化测试、编译、部署、数据获取。两者经常配合使用。比如在“前端性能优化”这个场景里Skill 定义了一个完整的审查 checklist 和优化优先级MCP 负责跑 Lighthouse、读取报告、打开页面分析网络请求最后由模型基于 Skill 的规则生成整改方案。等于一边给方向一边给手脚。2. 在职前端怎么设计自己的 Skill 体系2.1 从重复劳动里提炼Skill我的首要原则是不为了造概念而造 Skill。真正值得沉淀成 Skill 的是那些一周能碰到两三次、每次都要写大段 prompt 去解释的任务。我梳理过自己在公司里的重复劳动挑出几类高频场景新页面/新模块脚手架生成每次都要一堆目录结构、统一入口、路由注册、API 封装Code Review团队代码评审需要关注的点特别多安全、性能、可读性、边界条件一次性口头讲清楚太累组件文档生成从组件代码生成 API 表格和示例要求格式团队统一技术方案评审前端技术选型时要按开源活跃度、包体积、TS 支持、浏览器兼容性等维度打分。每一类我都写成一个 Skill 文件用 markdown 格式默认放在.cursor/skills或者 AI 编辑器指定的 skills 目录里。当任务命中 Skill 的关键词时模型会自动加载对应的手册不需要我手动粘贴。2.2 Skill文档的写法与常见误区写过十几个 Skill 之后我觉得它的写法很像写一套高质量的 RFC 文档但又有几个特殊之处。一个我能跑起来的 Skill 文件通常包含四块内容元信息name、description、trigger conditionsdescription 里要把触发场景写得很具体不然模型可能匹配不上。使用步骤用有序列表写明模型需要按顺序完成的步骤不要只给目标要给出路径。工程规范明确的禁止项和必须项越是硬性要求越要写在显眼位置。输出模板规定最终交付物的格式比如代码块结构、注释风格、检查清单。最常见的误区是“贪多”一个 Skill 里塞了一堆互不相关的规则结果模型不知道该听哪条。我一开始写过一个“前端最佳实践”Skill里面既有代码风格又有安全规范还有性能优化建议结果每次执行都像是开盲盒模型随机挑几条执行。后来把一个 Skill 拆成五个垂直的效果立刻好了。另一个误区是过分抽象缺少具体例子。模型跟人一样光看“组件要保持可维护性”这种话等于没说你给它一个 bad/good 对照示例执行准确率能翻一倍。2.3 我维护的几个高频前端Skill我把自己日常用的 Skill 开源到了部门内部仓库挑几个有代表性的讲讲CodeReview 前端专业版。这个 Skill 让模型按照安全、性能、可访问性、可维护性、测试覆盖五个维度做全面代码审查。每个维度都有明确的检查列表和常见问题示例。比如安全维度会重点检查 dangerouslySetInnerHTML、innerHTML、eval 等危险用法性能维度会检查是否缺少 memo、列表 key 是否正确、有没有巨大依赖被引入。我用它来跑 MR 代码审查比自己盯细节有耐心多了尤其是那种超过 1000 行的 MR。从零到一搭建前端项目。这个 Skill 定义了现代前端项目的完整初始化流程Node 版本检查、包管理器选择、TypeScript 严格模式、ESLint Prettier、Husky lint-staged、路径别名、请求封装、内置组件目录结构。以前初始化一个项目要手动折腾快半天现在让 AI 按 Skill 一步步执行二十来分钟就能得到一个能提交的骨架。Vite 配置专家。有时候就为了配一个 proxy、配一个多入口要从早上折腾到中午这个 Skill 把 Vite 常见配置场景拆成几十个问题模板我只需要描述需求AI 会按模板给我完整的、带注释的配置代码。想在自己的环境里体验不需要额外装插件只要建好目录把 markdown 文件放进去在对应 AI 编程助手中启用该 Skill 即可。不同的助手支持方式稍有差别有的在设置里自动扫描有的需要手动指定路径但原理完全一致。3. MCP 在前端工作流中的落地配置3.1 常用开发类MCP服务器梳理MCP 的价值终究要落到工具调用上。我实际用下来的前端高频 MCP 服务主要有这几类列个表可以直接抄作业MCP 服务功能场景我在什么情况下用它Playwright MCP浏览器自动化、点击、填表、截图、DOM 断言验证前端交互、自动跑回归Fetch MCP抓取网页内容转 markdown调研竞品页面、读框架文档Filesystem MCP沙箱化地读写本地文件让 AI 操作项目目录、批量改文件GitHub MCP操作仓库、Issue、PR、分支AI 自动提交 MR、处理 issue数据库 MCP查库、执行 SQL只读联调时直接看后端数据结构设计稿解析 MCP从设计标注图提取色值、间距、组件还原设计稿节省沟通成本3.2 从零配置一个前端项目MCP服务为了大家能直接上手我拿“Playwright MCP 做一个前端页面冒烟测试”举例说说整个配置流程。第一步是安装依赖。我习惯用 pnpm 作为包管理器在项目根目录执行pnpm add -D playwright/test npx playwright install chromium这里装的是 Playwright 测试库和浏览器内核。如果此前没有装过 Playwright MCP 本身需要全局装一下npm install -g playwright/mcplatest第二步在 AI 编程助手的配置文件里加 MCP 配置。以 Claude Code 为例编辑项目下的.mcp.json{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest], env: { PW_TEST_TIMEOUT: 30000 } } } }Formatter 可能不太喜欢多行 JSON这里直接用标准格式写即可。配置完成后重启 AI 助手它就能看到 Playwright 提供的一堆工具比如 browser_navigate、browser_click、browser_snapshot。第三步我给 AI 下达一个用自然语言描述的指令请打开 http://localhost:5173完成一次登录流程输入测试账号密码点击登录按钮等待跳转到后台首页检查核心模块是否存在最后输出一份测试结论。AI 收到指令后会通过 MCP 调起浏览器、导航到本地开发服务器、逐项执行操作整个过程我只需要在边上盯着。相比以前用代码写脚本这种方式的最大优势是灵活需求变只需要改自然语言不用改测试代码。当然如果要做长期稳定的回归用例最终还是要把能力沉淀成 Playwright 脚本仓库我这里说的是快速验证场景。3.3 把MCP接进项目级智能体如果你对 MCP 的理解只停留在“让 AI 操控浏览器”还是有点可惜。前端开发里更值钱的是把项目自己的工具链以 MCP 形式暴露给 AI。在公司内部做过一个“前端构建环境 MCP”它封装了三个工具启动本地 dev server带端口检查执行当前分支的 lint type-check读取项目路由表返回当前项目所有路由页面清单。这样一来AI 在帮我改一个页面之前可以自己先启动项目、跑一遍 lint 确认当前状态没坏做完改动后再自动 type-check 一遍全部通过才会给我总结。以前我和 AI 协作的模式是“我给它代码它给修改”现在是“它自己拉代码、跑环境、验证再交付”。这种体验的差别就像从“让学生做卷子再替你批改”变成“让员工自己查资料、做方案、自测、交付”。接法也不复杂本质上就是写一个 Node.js 脚本用官方 SDK 声明工具和对应执行函数import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new McpServer({ name: frontend-toolchain, version: 0.1.0 }); server.tool( run_lint, 在当前项目运行 eslint 检查, async () { const { execSync } await import(child_process); // 实际使用中建议用 spawn 并限制输出长度避免阻塞 const output execSync(pnpm lint, { encoding: utf-8, timeout: 60000 }); return { content: [{ type: text, text: output }] }; } ); const transport new StdioServerTransport(); await server.connect(transport);然后在 AI 助手的 MCP 配置里指到这个脚本入口即可。这样做的收益很大前端工程里很多环境差异问题——依赖没装、端口占用、分支状态不对——都能让 AI 在动手之前自己发现。3.4 大文件上传场景里的一线体验热搜词里有人提到“前端使用 worker 上传大文件”恰好这也是我折腾过的一个场景。最初用主线程做分片上传切片大文件时页面直接卡住后来改到 Web Worker 里做哈希计算和切片再加上一个本地任务型 MCP 服务让 AI 能主动查询上传进度、触发断点续传、汇总失败分片。做这类需求时的核心参数一般这样定分片大小建议 5MB10MB不要盲目追求小分片分片太小会导致请求数激增服务端压力大并发数35 个比较合适并发太高容易触发服务端流控哈希算法推荐 xxhash 或 spider 这类哈希比单纯 MD5 快一个量级适合浏览器端对超大文件做唯一性标记。印象最深的问题是哈希计算的内存占用。用普通 FileReader 把整个文件读进 ArrayBuffer 再算一个 4GB 的文件内存直接炸。解决办法是用流式读取加切片哈希同时在计算中每处理一定字节数就 await 一次让 Worker 有间隙处理消息事件界面上的进度条才不会被卡成“假死”。这一段我是写在技术方案 Skill 里的任何 AI 来帮我写大文件逻辑都会自动带上这些约束。4. 前端安全方向的 Skill 与 MCP 实践4.1 前端安全加固的常见维度前端安全是个大话题但落到日常开发我总结出几个必须烂熟于心的维度输入校验、XSS 防御、CSRF 防护、敏感信息泄漏、依赖漏洞、源码混淆与防调试。很多人以为“前端安全就是后端的事”这个观念得改。现在前后端联动复杂很多漏洞恰恰出在前端对用户输入的信任。输入校验所有从 URL 参数、表单、本地存储、postMessage 里来的数据都不能直接渲染进 DOM一定要先过校验或转义。前端做的是第一道门不能指望后端帮你扛所有事。XSS 防御坚决不用 dangerouslySetInnerHTML 渲染不可信内容就算要用也要让 AI 配合 DOMPurify 这类库做白名单过滤。敏感信息泄漏禁止把 API Key、token、内部域名硬编码到前端代码里。前端包里的东西就等于公开了再怎么混淆也是纸包火。依赖漏洞定期跑pnpm audit高危依赖要升级不要因为“新版本可能破坏功能”就一直拖着。源码防护对高价值前端应用如核心算法、会员权益判断等做一定程度的混淆、控制台持续输出警告甚至禁用调试、检测非正常打开环境等。4.2 把安全检查做成 Skill 和 MCP我在团队里落地了一个“前端安全审计”Skill让 AI 在进行任何需求开发之前先对照一份安全清单自查一遍。Skill 里面重点强调了几条所有请求参数必须做类型校验和长度校验动态渲染 HTML 时必须使用安全的 sanitize 策略涉及用户上传文件时限制扩展名、大小、并做内容头检查页面打开后禁止在 console 中暴露敏感数据敏感操作改密、支付、权限变更需要二次确认逻辑。同时配合一个只读的本地安全扫描 MCP扫描项目源码里的高危模式比如innerHTML、eval、localStorage.setItem(token这种。扫完之后 AI 依据安全 Skill 的规则逐条给出修复建议。这套流程跑下来很多低级安全漏洞在产品上线前就被截掉了。4.3 对“防爬虫、禁看源码”这类需求的正解有一次运营同学提了一个需求说得挺直白“能不能让用户没法查看页面源代码除了我们的同事以外都打不开。”我用技术角度告诉他纯前端做不到“绝对禁止”任何人查看源码因为代码要运行就必须下载到用户浏览器。但是可以做几件实事提升门槛让普通用户和初级爬虫望而却步压缩与混淆构建产物去掉注释、统一变量名让代码可读性大幅下降关键逻辑放服务端前端只保留调用端涉及核心数据和算法不要裸露在浏览器里部署策略敏感管理页面与主站分开域名部署子应用间用 iframe 或动态下发路由区分可见性监测异常访问通过访问频率、来源特征、JS 环境指纹等判断是否疑似脚本抓取再触发行为验证。我把这些写成了“前端防尽调与反爬加固”Skill这样当我自己不写代码、让 AI 来落地时它会优先按这个思路给方案而不是傻乎乎地只输出一段“禁用右键菜单”的代码。禁用右键、禁止 CtrlU 这类操作最多算是体验降级真正能让你的内容有点门槛的还是真正的工程手段。5. 实操中踩过的坑与排查清单5.1 Skill不生效的三种典型原因我遇到过的“Skill 不生效”99% 是以下三个原因description 写得不够精确。Skill 依赖模型对用户意图和 Skill 描述做匹配如果你的描述太泛比如“前端开发指南”模型很难判断什么时候该用。正确姿势是把触发场景具象化比如“当用户要求开发一个新的列表页面、并需要遵循标准 CRUD 规范时”。目录没放对。不同的 AI 编辑器对 Skill 目录扫描路径不同有些只扫项目根目录下的.skills有些扫.cursor/skills还有些支持全局用户目录。放错了位置无论写得多好都白搭。规则冲突。如果你同时加载多个 Skill且其中两条规则冲突模型会取到不确定性表现就是“这次遵守了 A下次遵守了 B”。我的做法是给 Skill 设置明确的优先级或者干脆做一个入口级 Skill用来调用其他 Skill。5.2 MCP连接失败的排查思路MCP 服务连不上的问题比 Skill 不生效更让人抓狂因为错误提示往往很抽象。根据我自己的经历排查顺序基本是这样的看启动命令MCP Server 本质是个子进程如果命令路径不对、参数拼错、或者 Node 版本太低进程起来就崩。先单独在终端里运行一遍命令确认能正常输出看 stdin/stdout 是否被占用MCP 的 stdio 模式通过标准输入输出通信如果 Server 代码里不小心 console.log 了调试信息会污染协议流导致握手失败。调试的时候用 process.stderr 输出日志别用 stdout看网络策略远程 MCP Server 如果走 HTTP/SSE要确认地址、端口、鉴权信息都没问题。公司内网环境经常有代理拦截加上代理退出后又要重新配置看超时配置工具执行耗时长的话MCP 客户端有默认超时时间要预先调大不然就是“工具调用失败”这种没法定位的报错。5.3 效率提升的真实数据与心得多说无益拿几个真实数据结尾。我们团队推行 Skill MCP 之后做过一次内部统计常规前端页面开发从需求到初版提测平均从 3 个工作日降到 1.5 个工作日代码评审的耗时少了大概 60%因为大部分低级问题在 AI 自查阶段就没了前端自动化冒烟测试的门槛大幅下降很多同事可以用一段自然语言临时生成一套 verify 用例。不过说实话我最大的感受还不是效率变高而是“心气”变了。以前让 AI 写代码总觉得自己在给一个不懂项目的人讲需求人工补上下文、补背景、补文档累现在把那些上下文沉淀到 Skill 里、把项目能力注入到 MCP 里AI 更像是我团队里一个真的能自己开工的初级开发。一个在职前端真正该做的事情不是跟 AI 比拼写代码速度而是把项目规范、业务背景、工程约束这些知识资产化——让 AI 能共享你的经验然后你省下时间去处理那些它暂时做不了的难题。最后分享一个小技巧Skill 和 MCP 不是做一次就完的事我每一到两周就会复盘一次看看本周哪些对话我又在反复解释同样的事一旦发现就把它提炼成新的 Skill 规则或者新的工具封装。项目在往前走你的 Skill 库也应该跟着迭代这才是这套玩意的长期价值所在。