这两年 AI 编程工具迭代得实在太快作为在职前端我最直观的感受是2024 年大家还在争“AI 能不能写代码”到 2025 年团队里讨论的已经变成“怎么让 AI 按我们团队的规范写、怎么让 AI 自己动手验证页面”。Skill 和 MCP 就是绕不开的两个词。这篇文章不打算重复官方文档而是把我自己在真实项目里摸索出来的用法、配置和踩坑整理出来。如果你正在用 AI 辅助前端开发发现生成结果不够稳定、不知道怎么把 AI 接进本地环境和浏览器这篇应该能给你一条可以直接上手的路径。1. 先把概念捋清楚MCP 和 Skill 解决的问题并不一样1.1 MCP 是 AI 和外部世界的“USB-C 接口”MCP 的全称是 Model Context Protocol直译是“模型上下文协议”由 Anthropic 在 2024 年底开源。它要解决的事情其实很朴素AI 模型默认只能“看到”你粘贴给它的文字但真实开发需要它去读文件、跑命令、操作浏览器、查接口文档这些动作如果每换一个工具都要重新适配浪费的时间就太多了。MCP 就是定了一套统一的标准让 AI 客户端通过这套标准和外部工具通信。你可以把 MCP 理解为 AI 世界的 USB-C 接口。以前每家厂商都做自己的专用充电口手机、耳机、充电宝各不通用现在 MCP 把“AI 连接外部工具”这件事统一了。一个实现了 MCP 协议的“工具服务器”MCP server注册几个工具任何支持 MCP 的 AI 客户端都能调用。对前端来说这意味着不用为每个项目单独给 AI 写一套“调用浏览器、读文件”的适配代码配置一次换客户端也能复用。具体到技术形态MCP 分为 Client 和 Server 两部分。AI 客户端比如 Claude Desktop、Cursor、Codex CLI 这类是 MCP Client工具提供方是 MCP Server。两者通过 JSON-RPC 通信传输方式有 stdio本地进程标准输入输出和 HTTP 两种。本地开发最常见的是 stdio你启动一个 node 进程那个进程对外提供“读取项目结构”“打开浏览器”这类能力。我第一次配置 MCP 的时候还在想这到底是什么黑科技搞明白是“本地起一个进程 按协议聊天”之后就觉得它其实很工程化没有听上去那么玄。1.2 Skill 是“给 AI 的操作手册”解决的是怎么把活干对说完 MCP 再说 Skill。很多人把 Skill 和 MCP 混在一起聊我的理解是MCP 解决“AI 有没有工具可用”Skill 解决“AI 拿到工具后按什么规矩干活”。Skill 在 Claude 生态里通常表现为一个目录里面有一个SKILL.md文件文件头部用 YAML frontmatter 写清楚这个技能的名字、描述、适用时机下面就是具体的操作指令和规范。举个例子我团队里有一个“前端组件库使用规范”的 Skill里面会写清楚组件优先从公司组件库引入按钮类交互统一用哪个组件表单校验文案的格式是什么样式变量用 design token 而不是写死颜色。AI 读到这个 Skill 之后生成代码时会主动套用这些规则而不是给你一套“看起来能跑但完全不符合团队风格”的页面。这个差别在真实项目里非常明显前者合并即用后者还得人工返工一遍。所以我现在对团队同事的建议很简单MCP 先选 2 到 3 个确实能提效的接入Skill 则优先把你最常重复的“规范和检查流程”固化成文档。这两者不是竞争关系而是一个提供能力、一个约束行为配合使用效果才稳。2. 在职前端最值得先接的几个 MCP 场景2.1 Playwright MCP让 AI 亲眼看到页面上发生了什么在所有 MCP server 里Playwright MCP 是给我带来体感最强的之一。它的本质是把 Playwright 封装成一组 MCP 工具让 AI 可以打开一个本地页面、滚动页面、点击按钮、输入文字、截图、读取网络请求返回。以前我们让 AI“帮忙看看这个按钮是不是有问题”它只能盯着代码猜接了 Playwright MCP 之后它能自己打开浏览器看真实渲染结果排查效率完全不是一个量级。配置方法其实不复杂。以我常用的客户端为例在 MCP 配置文件里加一段{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcplatest] } } }npx -y的意思是临时下载并直接运行不用手动全局安装。第一次启动会慢一些因为要拉包后续再跑就是本地缓存速度可以接受。配置完重启客户端对话里就能看到playwright相关工具出现说明连接成功。我日常用得最多的工具就几个browser_navigate用来打开地址browser_snapshot用来拿当前页面的可访问性快照适合让 AI 理解页面结构browser_click和browser_type用来操作browser_take_screenshot用来拿视觉证据。实际配合时我一般让 AI“打开 localhost 的页面 → 快照 → 定位问题元素 → 点击/输入 → 截图”它就能自己走完一轮 UI 验证。需要注意一个细节Playwright MCP 默认是无头模式跑也可能在你电脑上直接弹出一个真实浏览器窗口。我喜欢在有头模式下做交互调试因为能看到 AI 一步一步操作但如果是跑回归验证无头模式更快也更稳定。这个可以在配置里通过参数切换具体参数名每个版本会有更新建议以项目 README 为准。2.2 用 MCP 让 AI 自己读项目上下文而不是你手动贴文件很多前端同学用 AI 提效的第一个瓶颈是“上下文不够”。项目十几万个文件AI 只能看到对话框里那几百行代码生成结果当然偏通用。我现在的做法是给 AI 接一个能读取文件系统或项目文档的 MCP server让它按需自己去看项目结构、读 README、查接口定义。Filesystem MCP 是社区里比较成熟的方案它允许 AI 在指定目录范围内读写文件。配置时需要注意目录权限控制不要把整个用户目录都暴露给它这一点后面安全小节会展开。还有一种更贴合团队的方案把接口文档、设计规范、组件说明文档放到项目 docs 目录用 MCP server 提供结构化读取这样 AI 生成的代码能主动对齐后端字段和设计 token。实际使用下来我最大的体会是“读取范围一定要可预期”。如果让 AI 自由扫描整个 monorepo一来 token 消耗会很夸张二来它容易被无关文件带偏。我的做法是在 Skill 里明确告诉 AI“先读 README 和 docs/ 下的文件组件代码看 src/components 下的 index 和类型定义不要扫描 node_modules、dist、.git”。这样 AI 的行为可控生成质量也更稳定。2.3 构建、预览、部署的验证闭环前端开发离不开本地起服务这个环节也能通过 MCP 做得更顺。常见做法是暴露一个“运行 npm run dev”“检查构建日志”的工具让 AI 改完代码之后自己去跑构建、把报错信息读回来修复省去它在代码里瞎猜。纯前端项目部署到静态托管平台也可以用类似思路构建产物通过平台接口上传部署完成后把线上预览地址返回给 AI再让 Playwright MCP 去线上地址做一次冒烟验证。这套链路跑通之后“AI 写代码 → 自动构建 → 自动部署 → 浏览器验证”就闭环了。我见过很多团队已经买了静态托管服务但没人想过把它们包成 MCP server实际上这种包装成本不高收益却很直观它把 AI 从“只改代码”扩展到“能验证自己的改动”。2.4 把大文件上传这类“重活”沉淀成 Skill热搜词里有条“前端使用 worker 上传大文件”这确实是在职前端会被问到的典型场景。如果只是让 AI 现写它大概率能写个分片上传但未必考虑并发控制、失败重试、进度计算这些工程细节。我的做法是把这类高频场景的成熟方案写成 SkillAI 遇到相关需求时直接套用模板再根据具体后端接口做微调。比如一个分片上传的 Skill我会在里面固话几个决策点分片大小怎么定常见做法是按文件大小动态分片比如小于 2GB 的文件每片 5MB 到 10MB具体还要看后端接收限制和网络稳定性没必要追求极小分片。并发数怎么控制一般建议 3 到 5 个并发太多容易把浏览器和服务器都打满也有团队直接用“单线程分片 队列”的做法虽然慢一点但稳定性更好。进度条怎么算要用已上传分片的总字节数除以文件总大小不能用“发送多少请求”来算因为分片大小可能不均。这些经验写成 Skill 之后AI 生成的上传组件会比你临时口头描述靠谱得多而且团队新人也能直接问 AI不用重复踩坑。3. 前端安全AI 辅助开发时最容易忽略的部分3.1 先认清边界前端代码没有“绝对保密”热搜词里有“怎么在前端进行防止爬虫、防止查看页面源码、防止打开”这类问题作为一个做过多年前端的从业者我得先泼一盆冷水只要代码被下发到浏览器里执行它对这个用户就是可见的任何手段都只能提高阅读和复制的成本不可能做到绝对保护。那些声称“禁用右键”“遮罩源码”就能防止别人看代码的方案本质上只是防君子不防小人实际意义非常有限甚至还会伤到正常用户的体验右键菜单被禁、文本选择被禁稍微手误操作一下就烦躁得不行。那搞安全的精力应该花在哪我的优先级很明确保护接口和业务数据 保护源码可读性 防止无差别爬取。页面杀 20 行代码的混淆时间不如认真给接口加一道签名来得实在。3.2 值得做的几件加固实事先说压缩混淆。构建时开启产物压缩是标配进一步用 javascript-obfuscator 这类工具做变量名混淆、控制流平坦化可以显著提高人工阅读成本。但要注意混淆会增加包体积和运行耗时核心业务代码做混淆非核心库没必要全部上。第二敏感信息千万别出现在前端代码里。API 密钥、加密密钥、管理员接口地址这些都不应该打包进静态资源。前端环境变量只是“看不见”不是“拿不到”用 sourcemap 一还原很多东西就露出来了。生产环境尤其不要发布 sourcemap 文件很多泄漏事故都是这么来的。第三接口层要做防护。前端能发请求就能被绕过真正防刷要靠服务端校验接口签名、时间戳、频率限制、验证码、设备指纹这些手段配合使用。前端代码里能做的是在请求拦截器里统一加签名参数、隐藏关键业务入口。爬虫也好、脚本批量访问也好最后碰到的都是这层防线它比页面源码混淆管用得多。第四CSP 和 SRI。给页面配置内容安全策略限制脚本可以从哪些来源加载给静态资源加上 SRI 完整性校验防止 CDN 资源被篡改。这两项配置成本不高对安全性的提升却很直接。顺手再检查一下有没有把内联脚本写得到处都是CSP 严格模式下内联脚本会被直接拦掉这也倒逼代码更规范。3.3 用 Skill 把安全自检做成日常动作我们团队做过一个“前端安全自检”SkillAI 在生成或者审查前端代码时会自动跑一遍检查清单代码里有没有硬编码的密钥和 Token有没有把后端内部地址直接写在页面里有没有开启 sourcemap 上传用的是不是内联事件有没有引入未经过 SRI 的外部脚本接口请求是否都带了统一签名逻辑。这个 Skill 本质上是把安全经验文档化让 AI 每次生成的代码都自动过一遍安全红线比人肉 review 遗漏少很多。特别提醒一句上面这些全部是防御性手段目的是保护自己的项目和服务绝不能反向去研究别人的系统。这条底线必须清楚AI 工具越是强大越要把能力用在正向上。4. 实操记录从零搭一套前端 AI 工作流4.1 环境准备与 MCP 配置下面记录一次完整的实操过程。假设我手上是一个 Vite React TypeScript 的中台系统项目组件库用 antd。我要让 AI 帮我完成一个“带 Worker 分片上传的文件表单页”并让 AI 自己完成页面验证。第一步确认客户端支持 MCP。目前主流 AI 编程工具大多都支持我习惯在配置文件里统一管理。MCP 配置本质是一个 JSON声明 server 名称、启动命令和参数。一个包含 Playwright 和 Filesystem 的配置大概长这样{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcplatest] }, filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /Users/me/projects/my-admin] } } }配置完成之后关键是验证连通性。一般客户端里会有一个工具列表入口能看到接入的新工具是否注册成功。如果没看到先看本地进程是否真的启动了再确认配置 JSON 的路径有没有写错。我第一次配置时就是少了-y参数npx 卡在“是否安装”的交互提示上MCP server 一直没起来工具列表自然是空的。这个坑非常典型后面排查章节我再详细说。4.2 先写一个团队级 SKILL.md在让 AI 开始干活之前我会先确认项目里已经放了一份前端开发 Skill。这个 Skill 的目的不是教 AI 怎么写代码而是约束它按团队标准来。一个最小可用的 SKILL.md 长这样--- name: admin-frontend-standard description: 在中台管理系统生成或修改前端代码时使用确保代码符合团队组件库、样式和工程规范 when-to-use: 用户要求新增页面、修改组件、生成表单、涉及上传下载交互 version: 1.0.0 --- # 中台前端开发规范 1. 组件优先使用项目内封装的 antd ProComponent禁止直接写零散的原生表单项 2. 样式变量必须使用 design token禁止硬编码色值和字号 3. 接口请求统一走 src/api 下封装的方法禁止在组件内直接写 fetch 4. 大文件上传必须使用 Worker 分片方案禁止直接把 File 对象整体 POST 5. 页面展示敏感数据时先做脱敏处理frontmatter 里的description和when-to-use写得越具体AI 在正确场景触发这个 Skill 的概率越高。如果你发现 AI 在不需要的时候去读这份文档多半是描述写得太宽泛反过来如果该触发没触发就要检查触发条件描述和用户表达是否匹配。这个调优过程和我们日常写函数文档有点像入口条件写清楚调用方才知道什么时候该用它。4.3 用 MCP 辅助完成一次真实开发环境就绪后我给 AI 的任务是“请根据项目规范新增一个文件上传页面支持 1GB 以内的文件使用 Worker 分片上传要求显示实时进度、支持失败重试完成后给出浏览器验证记录。”第一步AI 会先调用 filesystem 工具读取项目结构和 README理解现有代码的组织方式再读 src/api 目录下已有的接口封装而不是上来就自己造一套请求方案。这一步是 MCP 最大的价值所在它让 AI 的输出从“通用写法”变成了“项目内一致写法”。第二步AI 读取到 SKILL.md 后会按照里面的大文件上传规范生成代码。核心代码它会主动用 Worker 实现分片逻辑主线程只负责进度展示和交互。这里补充一个团队里验证过的分片参数默认分片大小 5MB文件大于 500MB 时提升到 10MB并发数控制在 4切片失败时先重试当前分片 3 次指数退避后再放弃进度条按“已上传分片字节数总和 / 总大小”计算这个公式在分片大小不均的时候也不会出现超过 100% 的 bug。第三步代码生成后我让它自己启动 dev server并用 Playwright MCP 打开页面验证上传表单。它实际执行的操作是打开本地地址、快照页面、找到上传按钮、选择一个小文件、点击上传、查看网络请求里的分片列表、截图确认进度条正常。这一轮下来确实发现了一个问题分片并发数太高主进程有明显卡顿。我让它调整 Worker 里的并发参数到 3再重新跑一遍验证基本就稳定了。第四步处理接口层的兼容。由于是本地开发后端接口还没完全就绪AI 在验证时发现了 CORS 报错。这时候可以在 Vite 配置里加一条本地转发规则把/api开头的请求转到后端服务地址同时保持前端代码统一走相对路径生产环境再由网关处理。整个过程AI 通过 MCP 不只是“写代码”而是真正经历了“改代码 → 起服务 → 看页面 → 查接口 → 修问题”的开发循环这个体验和单纯让它生成代码是完全不一样的。5. 常见问题排查速查表5.1 工具列表里看不到新增的 MCP 工具先确认 MCP server 进程有没有起来。本地 stdio 模式下配置里的命令一旦被客户端拉起系统进程列表里应该能看到对应的 node 进程。看不到的话大概率是启动命令有问题。排查依次看三点第一命令里是否缺了-y导致停在交互安装提示第二命令路径是否正确Windows 上 npx 可能是npx.cmd第三配置文件语法有没有错JSON 多一个逗号都会被静默忽略。改完配置后记得完全退出客户端再重开有些客户端并不会热加载 MCP 配置。5.2 Skill 不触发或误触发怎么办Skill 不触发最常见的原因是description和when-to-use写得不够贴近用户表达。比如你把前端规范 Skill 的触发条件写成“当用户要求开发时使用”AI 大概率不知道什么时候匹配改成“当用户要求新增页面、修改表单、涉及上传下载、生成 CRUD 界面时使用”这类具体行为描述命中率会高很多。误触发则相反多半是描述里出现了高频但无关的词比如光写“前端”两个字任何前端话题都会命中。调试 Skill 触发没有捷径就是多测试、缩小描述范围、迭代版本号。5.3 Playwright MCP 的经典坑浏览器自动化看起来方便实际坑也不少。最常见的是元素定位失败页面上有弹窗、iframe、懒加载内容或者组件渲染动画还没结束AI 的快照里根本拿不到目标元素。我的经验是让 AI 先生成完整快照再操作不要凭代码里的 DOM 结构瞎猜。下面是我整理过的一份速查表现象常见原因解决思路元素定位失败弹窗覆盖、动画未结束、懒加载未触发先滚动到目标区域再做快照弹窗先关闭再操作iframe 内元素取不到快照默认只包含顶层文档明确切换到对应 iframe 后再定位登录态丢失自动化浏览器没有用户 cookie预置测试账号 cookie或走本地白名单环境页面结构频繁变化前端改版导致选择器失效多用可访问性角色定位少用绝对路径选择器另外一个容易被忽略的点是登录态真实项目页面通常需要登录AI 开的浏览器默认没有你们的登录 cookie要么提前在脚本里种一个测试账号的 cookie要么让后端开放本地白名单环境否则验证到一半就会被登录页拦下。5.4 Token 和上下文管理的经验最后一条是关于 token 管理。MCP 工具返回的内容可以非常大尤其是 Playwright 的快照和文件系统读取一次返回几万 token 很常见。如果每次对话都让 AI 无脑读取整个项目很快就把上下文窗口撑爆后续生成质量会明显下降。我的习惯是三句话控制规模第一Skill 里明确约定读取范围只读 README、类型定义、接口封装和当前改动模块第二让 Playwright 做快照时优先用可访问性快照而不是全文 HTML第三一个会话只聚焦一个功能模块不要指望 AI 在一个超长对话里同时处理多个大型任务。这套做法用下来AI 生成的稳定性和我的 token 成本都能保持在一个可控区间。
