MCP与Skill实战：AI自己开浏览器改bug的前端指南

过去的两个多月，我的前端日常被两个词搅得有点热闹——Skill 和 MCP。起因是团队里同事发来一个链接，说现在的 AI 助手可以自己打开浏览器、操作页面、还能按公司的代码规范写业务模块。我一开始以为是某个新框架又出了命令行工具，仔细看完才发现，这根本不是框架的事，而是 AI 应用层的两套标准正在成形。

说实话，作为一个还在写业务代码的在职前端，我对新概念一向是“先围观、再上手”的态度。但 Skill 和 MCP 这两个东西，确实在过去几周里改变了我每天的工作方式：从“在浏览器里手动点半天定位 bug”，变成“让 AI 自己打开页面看控制台报错”；从“复制接口文档手写类型”，变成“让工具直接对接拿到结构化的数据”。这篇文章不聊纯理论，就把我真实用过的场景、踩过的坑、以及给前端同事的选型建议一次性说清楚。适合那些已经听说过 MCP 和 Skill、但还不知道怎么放进自己日常开发的读者。

1. 为什么突然都在聊 Skill 和 MCP：从一次“AI 改 bug”说起

1.1 一次“让 AI 自己开浏览器修 bug”的实况

事情是这样的。某个周五下午，设计师跑过来说活动页面的弹层在移动端点不出来。我打开 DevTools 正准备开始“甩锅排查”，突然想起刚配好的 Playwright MCP。我就在对话里让 AI 自己打开本地开发服务器、用手机模拟视口访问那个页面、把控制台报错和元素截图都拉回来。

结果 AI 真的去做了：弹出浏览器、切换设备仿真、点击按钮、抓取报错信息，最后定位到是一个z-index层级问题加一个接口返回的时间戳格式不对，两层问题叠在一起导致弹层被遮住。它甚至把修改建议和验证步骤一起写了出来。整个过程我没动一下鼠标，只是盯着日志看它“操作”页面。

这种体验一旦有过一次，你就回不去了。以前我们调试页面，最耗时间的不是写代码，而是“复现问题—观察状态—猜测原因”这个循环。现在这个循环可以被 AI 代理部分接管，前提是它真的能触达浏览器、能拿到页面运行时数据——这正是 MCP 在做的事情。

1.2 两套标准的底层逻辑：接口与能力包

先说 MCP，全称 Model Context Protocol，模型上下文协议。它是 2024 年底由一个主要 AI 实验室开放出来的标准，目的是解决一个很朴素的问题：大模型再聪明，默认也碰不到你的本地文件、数据库、浏览器和各个线上服务。MCP 就相当于给 AI 应用开了一排统一的“USB 口”，不同的工具和服务只要实现成 MCP 服务器，AI 客户端就能通过同一套协议调用它们。

你可以把 MCP 想象成外卖平台。AI 是用户，MCP 服务器是各个餐厅，协议就是统一的点餐流程。你不需要为每家餐厅单独下载一个 App，平台帮你把菜单、下单、配送标准化了。对应到开发里，就是浏览器自动化、地图查询、数据库操作、文件读写这些能力，都能以统一的“工具调用”方式暴露给 AI。

Skill 则是另一件事，核心是一份SKILL.md文件。它不像 MCP 那样提供“手和眼睛”，而是提供“脑子里的操作规程”——把一个领域里老师傅的经验、步骤、检查清单、代码规范、易错点，打包成一个 AI 可以直接读取的技能包。

现在社区里流传的各种“skill 编码 193、194、247”，我理解就是大家在共享技能清单时给每个 Skill 编的序号，相当于一个技能库的索引入口。这个编号本身不是正式标准，任何人都可以给自己的技能包编号，所以看到编号别急着激动，先看内容质量。

对前端来说，这两者的关系可以简化成一句话：MCP 让 AI 能打开浏览器、查地图、调接口；Skill 让 AI 知道“一个合格前端拿到页面后应该先看什么、按什么顺序排查、用什么规范写代码”。一个解决“能不能碰到”，一个解决“懂不懂怎么做”。

2. MCP 不是魔法：边界先说清楚再谈好用

2.1 浏览器与页面巡检：Playwright MCP 的打开方式

前端最容易上手的 MCP 场景，绝对是浏览器自动化。社区里最出名的就是 Playwright MCP，基于微软的 Playwright 封装，它给 AI 开放了打开网页、点击元素、读取控制台、拦截网络请求、截屏、生成无障碍快照这些能力。

配好之后，AI 就不再是“盲猜”你的页面了，而是真正打开你的本地地址，像一个刚入职的实习生那样，用工具帮你把页面摸排一遍。我最常用的几个指令场景：

• “打开localhost:5173，把首页控制台的警告列出来”
• “切换到 iPhone 14 视口，逐个点击导航菜单，截图看是否有重叠”
• “拦截这个页面的所有网络请求，找出返回 5xx 的接口”
• “跑一遍关键路径，把每一步的页面快照保存下来”

配置方式不复杂。在支持 MCP 的客户端里，以 JSON 配置为例，大致是这样：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

如果你是第一次用，我建议先跑一个很小的页面验证：让 AI 打开任意一个你本地在开发的项目，问它“页面标题是什么、控制台有没有红色报错”。跑通了再上复杂任务。不要一上来就让 AI 操作你还没保存的代码，万一它按错了按钮，哭的是你自己。

值得留意的是，浏览器 MCP 不只 Playwright 一家，Chrome DevTools 也有对应的 MCP 实现，甚至有一些“网页知识”类的 MCP 服务能直接抓取线上页面内容。我自己的体会是：本地调试优先 Playwright，因为它在本地起浏览器、仿真视口、拦截请求这些能力比较完整；线上巡检类的需求，可以再单独评估其他服务。

2.2 地图与接口类 MCP：最值得前端接入的两类

除了浏览器，前端日常里跟“外部数据”打交道最多的就是地图和业务接口。这块也是 MCP 的热门方向。

地图类的典型代表是百度地图 MCP。在纯前端项目里接入地图，最烦的往往是：你要去控制台一个个试地点检索的参数、处理坐标系、调通路线规划。有了 MCP 服务，AI 可以直接调地图能力拿到结果，然后按你的前端组件结构生成可渲染的数据。社区版本的配置大概长这样：

{ "mcpServers": { "baidu-map": { "command": "npx", "args": ["baidu-map-mcp"], "env": { "BAIDU_MAP_API_KEY": "你的密钥" } } } }

接口类则是另一个大热门。很多后端项目是 Java REST 接口，社区里已经有人把这类接口快速包装成 MCP 服务的方案，后端同事跑一个命令就能把 Swagger/OpenAPI 文档转成 MCP 接口。前端的好处是：你不再需要人肉复制接口文档，AI 可以直接通过 MCP 去读接口结构、拿到字段定义，甚至帮你把 TypeScript 类型生成出来。

但这里有个容易被忽略的点：MCP 服务器本质上是把某个数据源或工具的能力开放给了 AI。如果这是一个内部接口的 MCP，你要确认它只在本机跑、没有暴露到外网，密钥不要写进提交到仓库的配置里。我见过有人图省事把密钥直接写进 MCP 配置推上 GitHub，第二天就被机器人扫走了。

2.3 MCP 的使用边界与常见误区

很多前端同事第一次接触 MCP 会有一个幻觉：觉得它让 AI “无所不能”了。其实不是。MCP 解决的是“触达”问题，不解决“判断”问题。AI 能打开浏览器，不等于它知道你的业务逻辑；AI 能查地图，不等于它懂产品的地图交互设计。

我把 MCP 的边界总结成四条，每一条都是用时间换来的教训：

• 工具质量决定结果质量。MCP 服务器如果本身有 bug、返回了不规范的数据，AI 会把错的数据当成“事实”继续往下推理，错误会被放大。
• 权限边界要最小化。不要给 AI 暴露写数据库、删文件、发消息这类危险操作，除非在隔离环境。给它的工具越少，出事面越小。
• 延迟和上下文占用是真实成本。一次 MCP 调用会消耗上下文和时间，一个任务里挂着十几个用不到的 MCP 服务器，只会拖慢响应、烧 token。
• MCP 不提供生意的“为什么”。它能帮你把页面打开十次、截图十张，但为什么这个按钮要放在这里、为什么接口要这样拼参数，还是得靠人。

3. Skill 的正确用法：把一个“懂前端的人”装进 AI

3.1 拆开一个 SKILL.md

如果你去翻官方或者社区的 Skill 示例，会发现它就是一个目录，里面有SKILL.md、可能还有脚本和参考文件。SKILL.md是核心，它决定了 AI 拿到这个技能后会“怎么想”。

一个简化版的前端技能文件大概长这样：

--- name: frontend-performance-audit description: 对指定前端页面执行性能审计，输出优化建议清单。 --- # 前端性能审计 ## 目标 分析页面加载性能，定位 CLS、LCP、FCP 等瓶颈。 ## 步骤 1. 用浏览器 MCP 打开目标页面，记录控制台警告。 2. 收集关键指标，判断是否超出阈值。 3. 逐项输出问题清单，每个问题附修改建议。 4. 建议优先处理影响核心用户体验的项目。 ## 注意事项 - 不要只看 Lighthouse 分数，要结合真实交互路径。 - 图片未懒加载是常见问题，优先检查。 - 长列表用虚拟滚动，避免一次性渲染大量 DOM。

看起来很简单对吧？但就是这个简单的东西，价值巨大。它把“一个前端老手拿到页面后先干什么、后干什么、哪些地方容易漏”固化成了 AI 能执行的操作规程。

3.2 前端高频技能包盘点

我平时关注的热搜词里，有好几个都对应真实需求：skill html页面优化、前端使用worker上传大文件、前端组件库、纯前端线上免费部署。这些其实都可以做成 Skill。

• 页面结构优化技能。输入一个页面，输出语义化标签调整建议、懒加载方案、SEO 基础优化。特别适合接手别人的老项目，快速出整改清单。
• 大文件上传技能。把“基于 Worker 做分片上传、计算哈希、断点续传、并发控制”这套逻辑固化成代码模板，让 AI 按模板生成实现。前端用 Worker 上传大文件是个老话题，但很多人每次都要重新查资料，技能包能帮你把标准答案沉淀下来。
• 组件库生成技能。团队如果有自己的设计规范，可以把组件命名、样式变量、属性命名规则写进 Skill，让 AI 生成的新组件跟老组件看起来像同一个人写的。
• 面试准备技能。热搜里有“前端面试题”，有同事真的把一个“面试官视角的追问清单”做成了 Skill，用来帮自己复习，也让 AI 扮演面试官模拟问答。这个思路我很推荐。
• 部署技能。“纯前端线上免费部署”这个需求，适合做成技能包：把构建命令、静态托管平台的上传步骤、SPA 路由回退配置、HTTPS 证书自动签发这些细节写清楚，让 AI 照着跑流程。

3.3 自己写一个前端 Skill 的思路

社区里各种“skill 编码”满天飞，质量参差不齐。与其到处下载别人的技能包，我更建议前端同事自己写，尤其是那些你反复做的事。

我的方法是七个步骤，已经固定下来了：

1. 挑一个你每周都会重复的任务，比如“接到一个活动页需求后如何开工”。
2. 把任务拆成步骤，一步步写下来，包括每个步骤的输入输出。
3. 加入你的“避坑经验”，比如“注意接口鉴权方式不是 Bearer 而是自定义头”。
4. 给出代码规范和示例，让 AI 有样学样。
5. 把文档压缩成 SKILL.md，控制描述里的 token 占用，步骤要具体不要空话。
6. 在真实项目里测试，让 AI 按技能执行一个真实小任务。
7. 放进团队 Git 仓库，大家共用、持续更新。

写 Skill 的难点不在格式，在于你愿不愿意把自己的经验“翻译”成 AI 能执行的流程。很多前端同事觉得“这算什么技能，我脑子里都有”，但问题是 AI 脑子里没有。你只要把脑子里那套东西写出来一次，后面所有用 AI 写的页面、改的 bug，都会带上你的经验和标准。

4. 前端日常里 Skill + MCP 的组合落地清单

4.1 从 0 到 1 搭一个页面巡检机器人

这是我最推荐的第一个组合场景，难度低、见效快。核心思路：用 Playwright MCP 让 AI 能访问页面，用一个“巡检 Skill”告诉 AI 按什么标准检查。

我搭的巡检 Skill 里写了三类检查项：控制台报错、主要交互路径、关键元素的可见性与尺寸。跑起来之后的流程是：

1. AI 启动本地开发服务器。
2. AI 打开首页，截图并收集控制台日志。
3. AI 按 Skill 里的清单逐项检查，把不通过的项目列表输出。
4. 最后生成一份简单的巡检报告，标注问题严重等级。

这个流程以前要人工花半小时，现在大概三五分钟能出一轮。注意点是在本地跑的时候要先把代码保存好，最好用开发分支，避免 AI 操作时干扰正在写的代码。

4.2 地图 H5 从联调到上线

地图类 H5 是前端里很容易在“接口联调”上卡壳的场景。传统的做法是：前端照着地图开放平台的文档一个个调参数、测返回，遇到坐标系对不上再拿计算器换算。

我用百度地图 MCP 之后，这条链路变成：

1. 让 AI 通过 MCP 发起地点检索，拿到结构化的地点列表。
2. 让 AI 把结果转换成分页组件需要的格式。
3. 坐标系的处理写进一个“地图数据处理 Skill”，AI 直接按技能里的换算规则处理。
4. 前端组件只需要关心渲染，不用反复手动试参数。

这里要注意地图 MCP 服务通常需要有效的 API 密钥，而且地图能力的使用量会影响配额，开发调试时不要用生产密钥，单独开一个测试密钥更稳妥。

4.3 接口对接与类型生成

前端的日常有一大块时间浪费在“对着接口文档写类型”上。现在这块可以被 Skill + MCP 替代大半。社区已经有把 OpenAPI/Swagger 文档转成 MCP 服务的方案，后端把接口包一层，前端就能让 AI 直接读取接口定义。

我的做法是维护一个“接口类型生成 Skill”，里面写着团队的命名规范、接口响应包装结构、错误码约定。配合 MCP 拿到原始接口定义后，AI 能一次性生成统一风格的请求层代码和 TypeScript 类型。生成完我再做一件事：让 AI 用浏览器 MCP 打开本地页面，验证请求真的能发出去、数据能渲染。

这一步的价值不只是省时间，更重要的是统一了团队的请求层写法。以前每个人自己写 request 封装，风格五花八门；现在用 Skill 固化规范，新老项目慢慢就趋同了。

4.4 纯前端线上免费部署

“纯前端线上免费部署”也是热搜常客。对静态站点来说，免费的托管平台选择不少：GitHub Pages、Vercel、Netlify、Cloudflare Pages 这类都可以部署纯前端项目。

我建议把它做成一个部署 Skill，里面写清楚：构建命令、部署前要做的环境变量检查、SPA 路由回退配置、自定义域名和 HTTPS 自动签发。再配上 Git 仓库的自动化流程，推代码后自动构建上线。

需要注意，这类免费托管对带宽和构建时长有限制，放在个人项目、演示项目、小活动页上完全够用；如果是核心业务，还是要走公司的正式部署链路。Skill 的真正作用，是让 AI 不要再问你“部署到哪、用什么命令”，而是直接按技能包里的流程执行。

5. AI 时代的前端安全：防爬虫、防查看源码的执念该放下了

5.1 “防止查看源码”做不到，先接受这个前提

这段时间看到不少同学在问“怎么在前端进行防止爬虫、防止查看页面源码、防止打开”。我只能说，这个方向本身是错的。

前端代码最终要下载到用户浏览器里执行，从交付那一刻起，它就不可能是秘密。所谓“禁用右键”“禁用 F12”，只能防住完全不懂技术的人；对于会打开 DevTools 的同行来说，这些都是摆设。更关键是，现在 AI 工具越来越强，拿到一段混淆压缩的代码，让它格式化、分析逻辑、找接口地址，成本比人肉看代码低得多。

我见过团队花了好几周做“源码加密”，结果爬虫根本不看源码——人家直接抓接口、模拟请求，速度更快。你的前端加密代码不仅没拦住爬虫，还拖慢了页面加载、增加维护成本，纯属负收益。

5.2 把安全重心移回服务端：限流、签名与敏感逻辑下沉

前端安全真正能做的，是“提高抓取成本 + 保护用户”，而不是“阻止一切访问”。我的建议是这几点：

• 核心业务逻辑放服务端。前端只负责展示和交互，判断、计算、权限校验都放到后端。这是最重要的原则。
• 接口加限流和风控。对高频接口做频控，异常用行为做验证码或封禁，比前端加密有用一百倍。
• 敏感操作加签名。接口参数做签名校验、时间戳防重放，前端只传必要参数。
• 做正规的安全加固。配置 CSP 内容安全策略、给 Cookie 加上HttpOnly和Secure标记、设置合理的Referrer-Policy，这些才是前端该干的“安全操作”。

一句话总结：前端做安全，是为了“让攻击者多花点钱”，不是“让攻击者进不来”。你把预期放对，才不会走偏。

5.3 别把前端密钥当秘密

顺带提醒一个大坑：“把密钥写在前端代码里”不等于安全。GitHub 的代码扫描机器人天天在扫这种泄露，很多人的 API Key、地图密钥就是这么被拖走的。

正确做法是：

• 前端只通过后端代理转发敏感接口，密钥只存在服务器端环境变量里。
• 如果用地图等第三方 SDK，线上域名要配置白名单，测试域名不要跟生产域名混用。
• 把密钥提交进仓库之前，先想想：我能不能接受它被公开展示？如果不能，就不要进。

6. 踩坑记录与选型建议

6.1 我踩过的几个坑

第一个坑是 MCP 服务器装太多。一开始我为了“体验完整”，一口气配了七八个 MCP 服务，包括什么文件操作、数据库、浏览器、地图、日志查询。结果 AI 每次做任务前都要遍历一堆工具，响应很慢，有时候还调错了服务。后来我砍到日常只挂两三个，速度立刻恢复。

第二个坑是 Skill 乱下载。社区里那些“skill 编码”看起来像版本号，其实是别人清单里的序号，同一份清单前后编码还可能变。我试过下载一个“页面优化技能”，内容很水，就是几行空泛建议，还不如我自己写。现在我只用两个来源：官方文档示例和团队自建仓库。

第三个坑是没验证 AI 改的代码。有一次 AI 按 Skill 的建议改了组件结构，我看着没问题就提交了，结果真机上样式全错。现在我强制要求“改完必须用浏览器 MCP 打开实际页面验证一遍”，这条写进了我们的工作流。

第四个坑是上下文被撑爆。有的 Skill 写得非常长，把整个团队的代码规范全塞进去，AI 每次对话光读说明书就消耗了大量 token，回答质量反而下降。技能包要像“菜谱”，不要像“百科全书”，只写关键步骤和易错点。

6.2 前端团队落地 Skill/MCP 的选型表

如果要落地到团队，可以参考我现在的选型思路：

选型的原则是：MCP 解决“连接”，Skill 解决“规范”。一个团队最少需要一个浏览器 MCP、一个内部接口 MCP，外加三五个核心 Skill，就能覆盖日常大头。

6.3 我的个人工作流：一次完整闭环

最后分享我现在每天实际在用的闭环流程。接到一个前端需求后，我通常会让 AI 按这个顺序干活：

1. 先让我自己的“需求拆解 Skill”把任务拆成可执行的小块。
2. 用浏览器 MCP 打开相关页面，拿到现状数据。
3. 让 AI 按团队的“编码规范 Skill”写代码。
4. 写完用浏览器 MCP 做一次自测，看控制台、看交互。
5. 通过后再提交，让同事做人的审查。

踩过几次坑之后我才意识到，Skill 和 MCP 不是用来“替代前端”的，它们是把那些重复、机械、靠经验的部分先做了，把人的精力留给真正需要判断的事。我个人最大的体会是：别贪多，先把一个场景跑顺，再慢慢扩。选一个你每周都会做三次以上的重复任务，把它做成 Skill、配上 MCP，你会很快感受到这套组合拳的威力。