近一个月我们前端小组的讨论群几乎被两个词刷屏MCP 和 Skill。一开始我也以为又是一轮“AI 概念炒作”但真正把 Playwright MCP 接进日常开发之后我发现自己处理 bug 的方式完全变了——以前是看代码猜问题现在是让 AI 打开浏览器复现、截图、看控制台报错再直接给出修改 diff。这篇分享不是科普文而是我在职前端实际接入 Skill 和 MCP 之后的选型记录、踩坑清单和使用心得适合正在观望、想知道这俩东西到底能不能落地到日常提效的人。先说清楚一个概念MCP 和 Skill 不是同一层的东西但它们组合在一起基本重构了我过去大半年“AI 辅助写代码”的工作方式。MCP 解决的是“AI 能碰什么”Skill 解决的是“AI 会用什么样的方式碰”。下面我按自己从了解到上手的顺序把这套东西拆开讲。1. MCP 和 Skill到底给前端工作流带来了什么很多前端同事第一次听说 MCP是在 Claude 或者 Codex 的更新公告里。但看了半天文档还是不知道它跟“AI 帮我写代码”有什么关系。我换个说法MCP 是 AI 的“万能插头”它让 AI 不再是个只会在对话框里聊天的模型而是能直接操作你电脑上的浏览器、读取你项目里的文件、执行 npm 脚本、甚至打开设计稿的工具。1.1 先说清 MCP 是什么AI 的“万能插头”MCP 全称 Model Context Protocol可以理解为“模型上下文协议”。在过去如果我想让 AI 读取某个页面截图、操作一下浏览器通常要走两条路要么把截图手动拖进对话里要么写一堆一次性脚本把结果处理后喂给 AI。每个工具都要单独写一套桥接繁琐且不可复用。MCP 做的事情就是把这些“桥接”标准化成一个统一协议。只要工具的提供方实现一个 MCP ServerAI 客户端Claude、Codex、以及其他支持 MCP 的 IDE 插件就能像插 USB 一样直接接上。作为前端我最直观的感受是AI 可以自己启动浏览器、打开本地页面、点击按钮、检查 Console 报错AI 可以读取我指定的敏感文件目录、搜索项目代码、运行测试命令AI 可以连上团队内部的文档服务回答“我们项目的接口路径是什么”这类上下文问题。这个“万能插头”的意义在于前端开发里大量问题本质是“环境问题”——样式为什么不对、接口为什么报错、某个组件在特定分辨率下为什么塌了。这类问题很难靠聊天描述清楚但现在 AI 能自己去看效率完全不一样。1.2 Skill 又是什么从“会问”到“会干活”的转变如果说 MCP 解决的是“AI 的手和眼”那 Skill 解决的就是“AI 的脑子和职业素养”。热词里有人在搜“Skill 编码 193”“skill 编码247”“GitHub nature write skill”说实话这些编号和具体技能包我没有逐个深入研究但它们的本质是一样的Skill 是一整套可复用的能力包包含任务拆解流程、约束规范、参考示例、自查清单而不是简单一句“帮我写个组件”。打个比方普通 prompt 是让一个实习生“把这个页面写出来”Skill 则是给这个实习生一套公司 SOP——先读设计稿、再建目录、按组件库规范写代码、写完跑测试、最后自查边界情况。同样是干活后者产出的质量稳定得多而且这份 SOP 可以被团队沉淀、复用、迭代。1.3 对前端来说这两个东西改变了什么我总结下来有三个最直接的变化排查问题的模式变了。以前是“人看代码—人推测—人改—人验证”现在是“AI 看代码 看运行状态—AI 定位—人 review 后合入”。人的时间从“写代码”挪到了“做决策”。团队规范能真正落地。前端最头疼的就是每个人写的组件风格差很多。把代码规范、目录约定、命名规则封装成 Skill 之后AI 生成的新代码天然符合规范老代码也可以批量往规范上靠。重复劳动被压缩。比如“接接口传参”“写基础 CRUD 页面”“补国际化文案”这些工作在有了 Skill 和 MCP 之后基本进入半自动状态。当然这不代表前端要失业。在我看来这更像是一个“资深工程师放大产能”的机会——你懂的越多就越知道怎么调教这些工具产出的质量也就越高。2. 我把哪些 MCP 服务接进了日常前端开发MCP 生态比我预想中成熟。官方和社区已经有大量现成服务器前端开发里冲刺第一优先级的我觉得就是浏览器自动化这一类而这里最典型的就是 Playwright MCP。热词里那句“playwright mcp自动化0到1”看起来也是在问这个我就从它开始。2.1 浏览器自动化类Playwright MCP 是第一优先级Playwright MCP 简单说就是微软官方把 Playwright 的浏览器自动化能力包成了一个 MCP Server。AI 接上它之后可以直接访问本地或线上页面点击、输入、滚动等模拟用户操作截取当前页面或元素的截图读取 Console 日志、网络请求、页面错误信息。我在 Claude 里接入的方式很简单配置文件里加一段{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest] } } }接好之后我做的第一个实验是让它“复现 bug”我把一段有问题的代码跑在本地开发服务器上让 AI 打开http://localhost:5173然后截图给我看。它真的打开了页面告诉我控制台有个红色报错甚至把报错堆栈读了出来。这一步在以前需要我手动打开浏览器、按 F12、截图、贴给 AI——现在全自动了。踩过的坑也分享一下端口问题MCP 启动的浏览器实例和我们平时打开的浏览器不是同一个所以登录态、代理设置都不共用。涉及需要登录的页面要先让 AI 执行登录流程或者手动把本地调试的 cookie 配进去。权限问题在 CI 或沙箱里跑 Playwright 会遇到无头模式不支持某些 GPU 渲染的情况表现为截图空白或样式差异。我现在的做法是本地调试用有头模式CI 里用无头模式但样式断言留足视觉容差。选择器识别AI 生成的选择器偶尔会踩到动态id最好的做法是叮嘱 AI 优先用>my-frontend-skill/ ├── SKILL.md # 核心流程与规则描述 ├── references/ # 参考资料如团队代码规范、组件库文档 ├── examples/ # 输入输出示例越具体越好 └── checks/ # 自查清单如“提交前必须检查的十个点”SKILL.md是入口它定义“什么是好的完成结果”和“完成过程中必须遵循的步骤”。references是知识库让 AI 在不确定时查证而不必猜。examples是标准答案展示好的输入输出是什么样的。checks是最后一道质检关卡。这与 Copilot 的 custom instruction 最大的区别是颗粒度。custom instruction 更偏向全局偏好Skill 则像是针对某一类具体任务的专用工具两者可以结合使用互相补充。3.2 我写的第一个前端 Skill组件生成规范我写的第一个 Skill 是给团队用的“Vue 组件生成器”。起因是团队新项目里大家写组件的风格极不统一有人用选项式 API、有人用组合式有人把样式写在 scoped 里、有人用了 CSS Modules有人给组件命名带前缀、有人不带。我把团队确认好的规范写进了 Skill核心规则包括目录结构按src/components/模块名/组件名/组织命名组件文件名用 PascalCase样式类名用 BEM 风格样式方案必须使用 scoped CSS 变量禁止!important接口设计所有子组件 props 用defineProps并声明类型与默认值边界处理必须考虑 loading、empty、error 三种状态。写完之后让 AI 照着生成新页面组件一次过审率大大提升。过去 code review 里抓命名、抓缩进、抓样式方案的时间现在基本省了。这也是我建议所有想尝试 Skill 的人从“写组件”开始的原因——它是前端最高频、最容易被规范化的任务反馈周期短、见效快。3.3 第二个实用的 Skill安全防线检查热词里有好几条在搜“前端安全技术操作”“防止爬虫”“防止查看页面源码”我就顺势写了一个“前端安全防线检查”Skill。这里必须说清楚一个客观事实纯前端没有绝对的安全任何代码只要跑到用户浏览器上就能被查看、被调试、被爬取。你能做的只是提高门槛让绝大多数恶意操作的成本变高。真正敏感的逻辑和核心数据必须放在后端校验和控制权保护。所以这个 Skill 不是教“怎么把源码藏起来”而是让 AI 逐项检查这些常见风险点localStorage里是否存了敏感 token尤其是过期时间过长的接口请求是否缺少统一鉴权拦截器是否有绕过校验的入口页面中是否通过前端注释或错误提示泄露了后端接口细节依赖包是否存在已知高危漏洞配合 npm 类 MCP 查询是否有基础的 CSP 安全响应头配置上报给日志系统的数据是否包含用户敏感信息。我把这些写成了检查清单型的 Skill让 AI 对项目做静态扫描。实测下来它能发现一些我们人工 review 容易漏掉的问题比如同事在某个页面注释里贴了一段内网接口的完整地址。这类细节在 code review 时很容易被忽略但 Skill 检查一遍就能捞出来。3.4 Skill 的调教心得从“能用”到“好用”Skill 不是一次写好的而是迭代出来的。我的流程是先用普通 prompt 让 AI 完成一次该任务记录 AI 做得不好、做得偏差或不稳定之处把这些“负面案例”整理成明确规则写进 Skill反复用同一个输入测试直到输出稳定符合预期过一段时间根据实际项目反馈再回头修订。举个例子第一次让 AI 生成组件时它总是忘记处理 loading 状态。我就把“所有异步数据渲染必须包含 loading 判断”单独写成一条配上错误示例和正确示例。下一次它就不犯了。这说明 Skill 真正厉害的不是“一次性提示”而是可以把团队常年积累的 review 经验固化下来。4. 一组真实场景的落地组合查样式、改 bug、出组件、防爬优化聊完了单个工具我来展示几个完整的组合场景。这些场景都是我上个月实际在做的不是纸上谈兵。4.1 场景一页面样式错乱用浏览器 MCP 调试 Skill 快速定位有一天同事说某个弹窗组件在 1366px 宽度下按钮被挤成两行。这种问题靠“看代码猜”很难定位因为浮动、flex 收缩、文字长度任何一个因素都可能导致。我是这样处理的让 AI 通过 Playwright MCP 打开页面调整到 1366px 宽度对弹窗区域截图让 AI 用调试 Skill 检查按钮容器的主要样式对比设计稿中的间距约束给出修复 diff。整个过程大概五分钟AI 定位到是弹窗内容区flex-direction: row没有换行而且按钮的最小宽度写死了一缩就溢出。以前我可能要看十几分钟代码才能找到位置。这个组合对“界面 bug”这一类问题特别有效本质上是因为 AI 能同时看到运行状态和源码这和人眼排查的逻辑是完全一样的。4.2 场景二大文件上传进度条 Worker 分片让 AI 照着内部规范写热词里有条“前端使用worker上传大文件”我们团队恰好在做这个功能。要在页面上传几百 MB 的文件且不卡主线程方案是使用 Web Worker 做分片 进度上报。我把这个非常典型的需求整理成了一个 Skill分片大小固定 5MB断点续传用索引记录Worker 中只做文件切割和 hash 计算不直接操作 DOM主线程通过postMessage接收进度事件上传使用XMLHttpRequest方便监听上传进度所有上传错误要有统一重试策略最多重试三次间隔递增。将 Skill 交给 Codex 后它生成的代码一次通过了类型检查时效性也不错。极少数需要人介入的点是“分片上传接口是团队网关自定义协议”AI 不可能知道需要我把接口文档摘录放到 Skill 的 references 里。这也说明 Skill 的上下文不是越多越好而是要精准、结构化、针对当前项目。4.3 场景三给页面加基本的防爬门槛接前文的安全 Skill我们团队最近给一个公开数据展示页做了防爬优化。需要说明的是我们做这些不是为了“藏源码”而是为了降低站点被批量抓取的压力。具体手段包括去掉页面源码里无意义的、机器可读的链接结构改为接口数据动态渲染对一些高度重复的接口做频率限制和签名校验对图片资源启用防盗链 referer 检查敏感的业务数据打印成 canvas 而不是纯文本节点提高批量提取的成本。这些操作在安全 Skill 里都被标准化了。比如“接口签名校验”Skill 会指导 AI 在请求头加入时间戳和一次性 nonce后端校验通过才返回数据。另外我坚持不在前端做“禁用右键”“禁止选择”这类体验损伤型功能因为它们防不住真正的爬虫只会伤到真实用户。一句话前端防爬是护城河的第一道浅滩真正的防线必须修在后端。Skill 能做的是让这道浅滩尽量规范化不至于因为开发者疏忽而直接裸奔。4.4 场景四发布到纯前端免费托管很多小伙伴做个人项目、作品集希望有一个免费且稳定的静态托管。热词里那条“纯前端线上免费部署”我也经常搜到。这里分享一个我常用的部署 Skill针对的是纯静态站点的场景本地执行npm run build确认构建产物无误用npx serve本地预览构建产物检查资源路径是否正确配置base path避免部署到子目录时资源 404上传到静态托管平台或自己的服务器检查 HTTPS 证书与自定义域名解析是否生效。这个流程看似简单但容易踩的坑不少比如 SPA 应用路由需要配置fallback到index.html比如静态资源缓存策略设得太激进导致部署后用户看到旧版本比如某些托管平台对文件数量有限制上传几千个文件时要用增量部署。我把这些注意事项都写进了 SkillAI 每次部署都会主动检查省得每次都要人肉去翻部署文档。5. 没解决的事和避坑清单工具当然不是万能的。这一个月用下来我也遇到一些问题这里一并列出来供大家参考。5.1 安全边界MCP 权限、密钥、沙箱MCP 给了 AI 操作电脑的能力同时也放大了风险边界。尤其是内部 MCP 服务或本地文件读写类 MCP一旦配置不当AI 可能会读取到不该看到的密钥文件、修改生产环境配置等。我的建议是本地开发机上MCP 服务尽量用最小权限运行不直接挂根目录生产环境相关的 MCP 服务单独放在隔离环境里禁止访问公网数据库和密钥管理日志和密钥文件路径要显式加入“禁止读取”列表即使 AI 主动请求也要拒绝。5.2 模型上下文MCP Skill 不能替代人类决策Skill 写得越细AI 的产出就越规范但这也带来一个副作用如果规范本身有问题AI 会忠实地把问题放大。比如我们在某个阶段把“必须使用组合式 API”写进了 Skill但后来发现某些纯展示组件用选项式更加简洁AI 依然死板地生成组合式代码。这时需要人来更新 Skill而不是怪 AI 不聪明。另外Skill 不会帮你做“这个需求该不该做、这个方案合不合理”的决策。它只能保证在执行层面不偏移。真正的前端判断力——比如交互设计是否合理、性能优化优先级怎么排——还是需要人来把关。5.3 团队协作Skill 版本化和 Codex / Claude 的选择我们团队现在把 Skill 放在 Git 仓库里管理命名空间按“框架-任务类型”分每次改动走 PR 流程review 通过才合入。一开始有同事图省事直接改主分支后来发现不同分支的 Skill 规则不一致AI 生成结果不稳定。改走版本管理之后好很多。至于工具选择我们团队内部有人用 Claude for desktop有人用 Codex还有人在用 IDE 插件。实测下来它们对 MCP 和 Skill 的支持度有差异Claude 的生态比较成熟、指导也多Codex 对代码上下文的理解强、和 GitHub 工作流贴合度高。我的建议是不必死守一个工具把 Skill 和 MCP 配置做成跨平台通用的格式随环境切换也不会被锁死。最后再分享一个小技巧Skill 的checks清单是容易被忽略但性价比最高的部分。我后来给“组件生成 Skill”加了一条“生成后必须检查是否有console.log忘删且类型定义无any”这个简单的清单项直接消灭了 code review 里最常见的低级问题。工具在迭代规范也在迭代保持这套循环持续转起来比任何单次的“完美配置”都更有价值。