1. 在职前端为什么突然都在聊 Skill 和 MCP最近半年如果你混迹在前端圈子里会发现一个明显的变化以前大家聊的是你 Vue 还是 React你 Vite 还是 Webpack现在越来越多人在问你写 Skill 了吗你 MCP 接了几个。这个转变不是空穴来风它背后是前端工作方式正在经历的一次真实重构。先把两个词说清楚不然后面全是空中楼阁。Skill简单理解就是给 AI 编码助手比如各种 CLI 编码工具、IDE 里的智能体预先写好的一份能力说明书——它告诉 AI 在特定场景下该怎么做、按什么规范做、输出成什么样。你可以把它当成一份写给 AI 的 SOP写一次之后每次触发都按这个标准来。MCPModel Context Protocol则是一套让 AI 助手能够调用外部工具和数据的协议它解决的是AI 怎么去操作浏览器、怎么去读数据库、怎么去调你的内部接口这类问题。Skill 管的是怎么做才对MCP 管的是能碰到什么。为什么在职前端尤其需要关注这两个东西因为职场前端和自学前端最大的区别在于你有存量代码、有团队规范、有历史包袱、有交付压力。你不可能每次都从零开始让 AI 帮你写你需要的是让 AI 理解你现有的项目结构、遵守你团队的代码风格、复用你已有的组件库。这正是 Skill 和 MCP 的用武之地。我自己的情况是手上维护着三个中后台项目、一个 H5 活动页体系、还有一套内部组件库。以前用 AI 辅助编码最大的痛点是它写的东西能跑但不符合我们的规范改起来比自己写还累。后来我把团队规范、目录约定、组件用法沉淀成 Skill把浏览器自动化、接口调试、代码审查接成 MCP整个效率才真正起来。这篇就把我这段时间的实践完整拆开讲包括怎么设计 Skill、怎么选 MCP、怎么把它们串进日常开发流以及踩过的那些坑。适合谁看如果你是在职前端日常要维护真实项目、要跟团队协作、要保证交付质量那这篇就是写给你的。如果你还在学习阶段也可以看但重点放在理解思路不用急着全套照搬。2. 把团队规范沉淀成 Skill从AI 乱写到AI 按规矩写2.1 Skill 到底解决的是什么问题很多人第一次接触 Skill会误以为它是提示词模板。其实不是。提示词模板是你每次手动粘贴一段话Skill 是常驻的、可触发的、带上下文的能力单元。区别在于提示词是你在迁就 AISkill 是让 AI 来适配你的工作流。举个我真实遇到的场景。我们团队的中后台项目有一套约定所有列表页必须用统一的ProTable封装组件请求走统一的useRequesthook错误提示走全局的message封装不允许直接调axios。以前我让 AI 写一个列表页它十有八九给我写一个裸的fetch加useState能跑但 review 的时候会被打回。后来我写了一个中后台列表页 Skill把这些约定全部写进去再让 AI 生成出来的代码基本一次过。所以 Skill 的核心价值是把隐性的团队知识显性化让 AI 成为团队规范的执行者而不是破坏者。这一点对在职前端特别重要因为你的产出是要进代码库、要被同事 review 的不是自己玩玩的 demo。2.2 一个可复用的 Skill 应该包含哪几块内容我摸索下来一个真正好用的 Skill 通常包含五个部分缺一块效果就打折组成模块作用我项目里的实际写法触发条件告诉 AI 什么时候该用这个 Skill当用户要求新建列表页/表单页时上下文约束项目结构、技术栈、目录约定项目使用 React 18 TS Vite页面放在 src/pages 下规范清单必须遵守的编码规范禁止直接使用 axios统一走 request 封装参考示例一段正确的样板代码贴一个精简版的 ProTable 用法输出格式期望 AI 交付的形态输出完整文件内容并说明新增了哪些依赖这五块里参考示例是最容易被忽略但最关键的。你光说要用 ProTableAI 可能理解偏你贴一段真实可用的代码它就照着来了。我一般会从现有项目里挑一个最规范的页面删掉业务逻辑只留骨架作为示例塞进 Skill。2.3 写 Skill 时最容易踩的三个坑第一个坑是写得太大太全。我一开始想写一个万能前端 Skill把 React、Vue、小程序全塞进去结果 AI 触发的时候反而抓不住重点输出质量下降。后来我拆成React 中后台 SkillH5 活动页 Skill组件库开发 Skill三个独立的每个都聚焦效果立刻好了。Skill 要窄而深不要宽而浅。第二个坑是规范写得太抽象。比如代码要清晰易读这种话AI 根本没法执行。要写成函数不超过 50 行复杂逻辑必须加注释说明输入输出禁止使用 any必要时用 unknown 加类型守卫。能被机器判断的规则才是好规则。第三个坑是忘了维护。项目在演进规范在变Skill 不更新就会误导 AI。我现在养成的习惯是每次团队规范调整同步改 Skill每次 review 发现 AI 反复犯同一个错就把这条补进 Skill。Skill 不是写完就完事的文档是活的。2.4 把 Skill 和组件库打通的实际做法我们内部有一套组件库以前 AI 完全不知道它的存在老是让我用第三方库或者手写。后来我做了一件事把组件库的 API 文档精简成一份组件速查表作为 Skill 的一部分。这份速查表不追求全只列高频组件和它们的核心 props。具体做法是我写了个小脚本从组件库的 TypeScript 类型定义里提取出每个组件的 props 名称、类型、默认值生成一份 Markdown。然后手动补充每个组件什么时候用的说明。这份东西塞进 Skill 后AI 生成页面时会主动用我们的组件而不是乱造轮子。这里有个经验速查表要控制体积。我一开始把整个组件库文档塞进去结果 Skill 文件太大AI 处理起来慢还容易忽略重点。后来只保留 Top 20 高频组件其余的需要时再单独查。给 AI 的信息也要做减法。3. MCP 选型前端日常真正用得上的那几个3.1 别被MCP 全家桶带偏先想清楚你要解决什么MCP 生态现在很热闹各种服务器层出不穷从数据库到云服务到设计工具都有。但我观察到一个现象很多前端一上来就想我要把所有 MCP 都接上结果配了一堆日常真正用的没几个还拖慢了工具启动速度。我的建议是从痛点倒推。你先问自己日常开发里哪些环节最耗时、最重复、最容易出错然后去找对应的 MCP。对前端来说我总结下来高频痛点就三个浏览器里的调试和验证、代码审查、接口联调。对应的 MCP 也就那么几个。3.2 Playwright MCP前端自动化的主力Playwright 本身是前端测试和自动化的老牌工具它的 MCP 版本让 AI 能够直接操作浏览器——打开页面、点击元素、填表单、截图、读取 DOM。这对前端来说价值巨大因为前端的大量工作本质上是在浏览器里验证东西。我日常用 Playwright MCP 干这几件事验证 AI 生成的页面AI 写完一个页面我让它自己用 Playwright 打开、截图、检查关键元素是否存在不用我手动切浏览器。复现 bug给一个 bug 描述让 AI 用 Playwright 走一遍复现路径把每一步的截图和控制台日志抓出来。写测试用例让 AI 根据页面结构生成 Playwright 测试脚本我再微调。配置上Playwright MCP 一般通过命令行启动然后在你的 AI 工具配置里注册。核心参数是浏览器类型chromium/firefox/webkit和无头模式开关。我建议开发调试时用有头模式能亲眼看到 AI 在点什么出问题好排查跑批量任务时用无头快。注意Playwright MCP 操作的是真实浏览器涉及登录态、支付、删除等敏感操作时一定要在测试环境跑别对着生产环境放开。3.3 Code Review MCP把 review 前置到编码阶段代码审查是前端日常绕不开的环节但传统 review 是写完再查发现问题时改起来成本高。Code Review 类 MCP 的思路是把审查能力接进 AI 助手边写边查。我用下来的体会是这类 MCP 最擅长抓三类问题明显的逻辑漏洞、不符合规范的写法、潜在的边界问题。比如它经常能指出这个数组访问没做空判断这个 useEffect 缺少依赖项这个异步操作没有错误处理。这些恰恰是人工 review 时容易漏、但线上容易出事的点。不过要清醒MCP 的 review 不能替代人工 review。它抓的是模式化问题抓不了业务逻辑对不对、架构合不合理。我的用法是让 MCP 先过一遍把低级问题清掉人工 review 时专注在业务和设计上效率高很多。3.4 接口联调类 MCP让 AI 直接摸到真实数据前端联调最烦的是什么后端接口没写好只能对着文档 mock或者接口写好了但字段对不上来回扯皮。接口类 MCP 能让 AI 直接读取接口定义比如 OpenAPI/Swagger 文档甚至直接发请求看真实返回。我现在的流程是后端给了 Swagger 地址我让 AI 通过 MCP 拉取接口定义自动生成 TypeScript 类型和请求函数。字段对不上时AI 能直接对比文档和实际返回告诉我哪里不一致。这比手动对着文档敲类型快太多了。这里有个坑要提醒接口 MCP 拿到的数据可能是敏感的。配置时要注意权限范围别把生产库的读写权限开给 AI。我一般只给测试环境的只读权限。3.5 MCP 配置的通用注意事项不管接哪个 MCP有几个通用原则我踩过坑之后总结出来了一个 MCP 一个职责别指望一个 MCP 干所有事职责单一才好排查问题。启动方式要稳定优先用官方或社区维护良好的版本自己魔改的容易在升级后崩。日志要能看MCP 出问题时日志是唯一线索。配置时确保日志输出到你能找到的地方。权限最小化能给只读就别给读写能给测试环境就别给生产。4. 把 Skill 和 MCP 串成一条日常开发流水线4.1 单点用和串起来用效果差一个量级Skill 和 MCP 单独用各自都能提效。但真正让我觉得回不去了的是把它们串成一条流水线。举个我每天在用的完整场景接到一个新增用户管理列表页的需求。以前的做法是我自己想清楚要哪些字段、用什么组件、接口怎么调然后一段段让 AI 写写完自己跑起来测。现在我的流程是触发中后台列表页 SkillAI 按团队规范生成页面骨架和组件用法。通过接口 MCP 拉取用户接口定义AI 自动生成类型和请求函数。让 AI 用 Playwright MCP 打开页面截图确认渲染正常。触发 Code Review MCP过一遍生成的代码清掉低级问题。我人工检查业务逻辑和交互细节微调后提交。整个过程我从写代码的人变成了定需求和把关的人。这不是偷懒是把精力从重复劳动转移到真正需要判断力的地方。4.2 流水线里各环节的衔接细节串起来用衔接处最容易出问题。我分享几个实际的处理经验。Skill 和 MCP 的触发顺序一般先 Skill 后 MCP。因为 Skill 定的是怎么做MCP 提供的是能碰到什么。先让 AI 知道规范再让它去操作工具输出才可控。反过来先操作再套规范往往要返工。上下文传递AI 在不同环节之间需要共享上下文比如页面结构、接口字段。我一般让 AI 把关键信息组件名、字段名、路由路径显式写出来作为后续环节的输入而不是指望它记得。显式传递比隐式记忆可靠。失败回退MCP 操作失败是常事比如页面加载超时、元素找不到。我的做法是让 AI 失败后先截图、打印控制台再决定是重试还是报告。别让 AI 在失败时瞎猜给它明确的排查指令。4.3 一个真实项目的完整复盘上个月我接了个内部工具的需求大概是一个数据看板加筛选功能。我用上面这套流水线走了一遍记录几个关键节点。需求拆解阶段我没让 AI 直接写代码而是先让它基于 Skill 里的项目结构列出需要新建哪些文件、改动哪些文件。这一步花了几分钟但避免了后面大改。编码阶段列表页和筛选表单由 Skill 生成图表部分因为项目里用的是特定图表库我单独补了一个图表使用 Skill。接口部分通过 MCP 拉取类型自动生成。验证阶段Playwright MCP 打开页面发现筛选后数据没刷新。截图和控制台日志显示是请求参数没带上筛选条件。这个问题如果靠肉眼 review可能要跑起来才发现MCP 直接定位了。审查阶段Code Review MCP 指出两处一个 useEffect 依赖缺失一个日期格式化没处理时区。都是真实会出问题的点。整个需求从接到到提交比我以前纯手写快了大概一半时间而且质量更稳。关键不是快是稳——AI 按规范产出低级错误被前置拦截我只需要专注业务判断。5. 那些没人告诉你但一定会遇到的坑5.1 Skill 写太细反而限制 AI 发挥我一开始写 Skill 有个执念要把所有情况都覆盖到。结果写出来的 Skill 像一本几百页的规范手册AI 触发后反而变得死板遇到规范没覆盖的情况就卡住或者硬套。后来我调整了思路Skill 定底线不定上限。底线是必须遵守的比如用哪个组件、走哪个请求封装上限留给 AI 自己判断比如具体怎么组织逻辑、怎么命名变量。这样既保证了规范又保留了灵活性。5.2 MCP 的稳定性比功能更重要选 MCP 的时候很多人看功能列表觉得功能越多越好。但实际用下来稳定性才是第一位的。一个功能强大但三天两头崩的 MCP不如一个功能单一但稳定的。我踩过的坑某个 MCP 功能很全但每次启动要等十几秒还偶尔连不上。后来换了个功能少但秒启动的日常体验好太多。工具是拿来用的不是拿来炫的。5.3 别让 AI 的产出绕过你的判断这是最重要的一条。Skill 和 MCP 让 AI 产出变快变规范但责任还是你的。AI 生成的代码进了代码库出了问题是你背。所以无论流水线多顺最后那道人工把关不能省。我的习惯是AI 产出的每一段关键逻辑我都要能讲清楚它为什么这么写。讲不清楚的要么去搞懂要么重写。能解释的代码才敢提交。5.4 团队协作时的共享问题Skill 和 MCP 配置如果只在你本地团队其他人用不上价值就打折。我们团队的做法是把 Skill 文件放进代码库跟着项目走MCP 配置写成文档新人照着配。这样规范是团队级的不是个人级的。但要注意Skill 里别塞个人偏好。比如你喜欢用某个冷门工具别写进团队 Skill。团队 Skill 只放大家都认可的约定。6. 给不同阶段前端的落地建议如果你刚开始接触别一上来就搞全套。我的建议是从一个小痛点切入。比如你最近老是要写重复的列表页那就先写一个列表页 Skill用一周看看效果。有效果了再考虑接 MCP。如果你已经在用 AI 辅助编码但觉得产出不够规范那重点放在 Skill 上。把你团队最常被 review 打回的问题整理出来写成 Skill立竿见影。如果你已经在用 Skill 了想再进一步那就挑一个 MCP 接进来。前端我首推 Playwright MCP因为它覆盖的场景最广验证、调试、测试都能用。如果你是小团队或者独立开发者没有严格的团队规范那 Skill 可以写得更轻重点放在让 AI 理解我的项目结构上。MCP 也不用贪多一两个够用就行。最后说个我自己的体会Skill 和 MCP 不是让你少干活是让你把活干在刀刃上。以前大量时间花在写样板、调样式、对字段上现在这些交给 AI 按规范做我把时间花在理解需求、设计交互、把控质量上。这才是在职前端该有的状态——不是被工具替代而是用工具放大自己的判断力。这套东西我还在持续打磨Skill 会随着项目演进更新MCP 也会根据实际需要增减。如果你也在实践欢迎交流你踩过的坑和总结出的用法前端这个圈子分享出来的经验才是真的经验。