1. 在职前端为什么突然都在聊 Skill 和 MCP
最近半年，如果你混迹在前端圈子里，会发现一个明显的变化：以前大家聊的是"你 Vue 还是 React""Vite 还是 Webpack"，现在越来越多的人开始问"你那个 Skill 怎么写的""MCP 接了几个了"。这个转变不是空穴来风，它背后反映的是前端工作方式正在经历一次真实的、可感知的重构。
我自己在一家中型互联网公司做前端，日常工作除了业务开发，还要维护组件库、写构建脚本、对接各种内部工具。大概从去年底开始，我陆续把一些重复性高、上下文切换频繁的工作，改造成了 Skill 和 MCP 的形式来跑。用了几个月下来，有些确实提效明显，有些则是踩了坑之后才发现根本不值得做。这篇文章就是把这几个月的实战经验整理出来，给同样在职、想动手但又不知道从哪切入的前端同行一个参考。
先说清楚这两个概念，因为很多人第一次听到会懵。Skill在这里指的是一种封装好的、可复用的能力单元，它通常包含一段明确的指令、一套上下文规则，以及可选的工具调用逻辑。你可以把它理解成"给 AI 助手写的一份岗位说明书"，告诉它在什么场景下该做什么、按什么规范做。MCP则是 Model Context Protocol 的缩写，它定义了一套标准协议，让 AI 模型能够以统一的方式去连接外部工具、数据源和服务。打个比方，Skill 像是你给新同事写的操作手册，MCP 像是公司统一的门禁系统和 API 网关，两者配合起来，才能让 AI 真正"接入"你的工作流。
为什么前端特别适合搞这套东西？因为前端的工作有几个天然特征：一是重复模式多，比如写 CRUD 页面、配路由、写表单校验，这些有很强的规律性；二是工具链长，从代码检查到构建部署，中间要经过十几个环节；三是上下文碎片化严重，一个需求可能同时涉及组件库文档、接口定义、设计稿、埋点规范。这些特征恰好是 Skill 和 MCP 最擅长处理的场景。
但我要先泼一盆冷水：不是所有前端工作都值得做成 Skill 或 MCP。我见过有同事花了两周时间做了一个"自动生成按钮组件"的 Skill，结果因为设计规范三天两头改，维护成本比手写还高。所以这篇文章不会只讲"怎么做"，更会讲"什么值得做、什么不值得做"，以及在实际落地过程中那些文档里不会写的坑。
2. 从日常痛点倒推：哪些前端场景真正适合 Skill 化
2.1 高频且规则稳定的任务才是好候选
判断一个任务适不适合做成 Skill，我总结了一个简单的三维评估法：频率、规则稳定性、上下文复杂度。频率高说明值得投入，规则稳定说明不容易过时，上下文复杂度适中说明 AI 能处理得了。
拿我自己的实际工作举例。我们团队有一套内部的后台管理系统，几乎每个月都要新增几个列表页。每个列表页的结构高度相似：顶部筛选区、中间表格、底部分页、右侧操作按钮。以前我写一个这样的页面大概要 40 分钟，主要是复制粘贴再改字段。后来我把这个流程做成了一个 Skill，现在输入接口定义和字段说明，5 分钟就能出一个可用的初版。这个场景就是典型的高频、规则稳定、上下文适中。
反过来，像"根据设计稿还原复杂交互动效"这种任务，我就不建议做成 Skill。因为动效的细节太多，每个设计稿的意图都不一样，AI 很难稳定输出符合预期的结果，最后你花在调整上的时间可能比自己写还多。
下面这张表是我对常见前端任务做的评估，供你参考：
| 任务类型 | 频率 | 规则稳定性 | 上下文复杂度 | 是否推荐 Skill 化 |
|---|---|---|---|---|
| CRUD 列表页生成 | 高 | 高 | 中 | 强烈推荐 |
| 表单校验逻辑 | 高 | 高 | 低 | 推荐 |
| 接口类型定义转换 | 高 | 高 | 低 | 推荐 |
| 组件单元测试 | 中 | 中 | 中 | 可以尝试 |
| 复杂动效还原 | 中 | 低 | 高 | 不推荐 |
| 性能问题排查 | 低 | 低 | 高 | 不推荐 |
| 构建配置调优 | 低 | 中 | 高 | 谨慎 |
2.2 上下文切换成本高的环节优先做
除了上面三个维度，还有一个很实际的判断标准：这个任务是否需要频繁在多个工具之间切换。前端开发最烦的就是这个，写代码的时候要查组件文档，查完文档要去看接口定义，看完接口要去对设计稿，对完设计稿还要去确认埋点规范。每一次切换都是一次注意力损耗。
我做过一个统计，在改造之前，我平均每天要在 6 到 8 个不同的工具或页面之间来回切换。改造之后，通过 MCP 把组件库文档、接口平台、设计稿标注这几个数据源接进来，切换次数降到了 3 次左右。这个提升不是靠"AI 帮我写代码"实现的，而是靠"AI 帮我把信息聚合到一起"实现的。
这里有个关键认知：Skill 和 MCP 最大的价值不是替代你写代码，而是减少你的认知负担。很多人一开始就想着让 AI 全自动写代码，结果发现效果不好就放弃了。其实正确的用法是让 AI 帮你做信息聚合、格式转换、初稿生成这些"体力活"，把真正需要判断力的部分留给自己。
2.3 一个反面案例：我做过的最失败的 Skill
说个我自己的翻车经历。刚接触这套东西的时候，我特别兴奋，想着把"代码审查"也做成 Skill。我花了一个周末，整理了我们团队的代码规范、常见问题清单、历史 review 记录，写了一个看起来很完整的 Skill。
结果用了不到一周就废弃了。原因有三个：第一，代码审查需要很强的业务上下文，AI 不知道这段代码背后的业务逻辑，经常给出"正确但无用"的建议；第二，团队的规范本身就在演进，我整理的那份很快就过时了；第三，审查结果需要人工二次确认，反而增加了工作量。
这个教训让我明白：Skill 适合处理"确定性高"的任务，不适合处理"需要业务判断"的任务。代码审查、架构设计、技术选型这类工作，AI 可以辅助，但不适合做成标准化的 Skill。
3. MCP 接入的实操路径：从前端视角怎么选、怎么接
3.1 前端最该优先接入的几类 MCP 服务
MCP 生态现在发展很快，各种服务层出不穷。作为前端，我的建议是不要贪多，优先接入这几类：
第一类是文档类 MCP。把你们团队的组件库文档、内部规范文档接进来，这样 AI 在生成代码时就能参考真实存在的组件和 API，而不是瞎编。我之前遇到过 AI 生成的代码里用了一个我们组件库根本不存在的属性，排查半天才发现是它"幻觉"出来的。接入文档 MCP 之后，这个问题基本消失了。
第二类是接口类 MCP。把接口管理平台接进来，让 AI 能直接读取接口定义、字段说明、示例数据。这个对写类型定义和 mock 数据特别有用。
第三类是设计类 MCP。如果你们用的是支持 MCP 的设计工具，可以把设计稿的标注信息接进来。这样 AI 在还原页面时能拿到准确的间距、颜色、字号，而不是靠猜。
第四类是代码仓库类 MCP。让 AI 能读取你的项目代码，这样它在生成新代码时能参考现有的代码风格和目录结构。
这四类接完之后，基本能覆盖前端日常 80% 的信息查询需求。其他的比如数据库 MCP、部署 MCP，可以按需再补。
3.2 接入过程中的配置细节和常见报错
MCP 的接入方式根据你用的客户端不同会有差异，但核心逻辑是一样的：在配置文件里声明服务地址、认证信息、以及需要暴露的能力。下面是一个典型的配置结构示例：
{ "mcpServers": { "component-docs": { "command": "npx", "args": ["-y", "@your-org/docs-mcp-server"], "env": { "DOCS_API_KEY": "your-key-here", "DOCS_BASE_URL": "https://internal-docs.example.com" } }, "api-schema": { "command": "node", "args": ["./mcp-servers/api-schema/index.js"], "env": { "API_PLATFORM_TOKEN": "your-token" } } } }这里有几个容易踩的坑，我一个个说。
第一个坑是路径问题。如果你用的是相对路径，要注意 MCP 客户端的工作目录可能和你想象的不一样。我一开始用./mcp-servers/xxx一直报找不到文件，后来改成绝对路径才解决。建议直接用绝对路径，省得排查。
第二个坑是环境变量传递。有些 MCP 服务需要认证信息，但如果你把密钥直接写在配置文件里，一旦这个文件被提交到仓库就麻烦了。正确的做法是用环境变量引用，或者用客户端支持的密钥管理功能。
第三个坑是超时设置。默认的超时时间往往偏短，如果 MCP 服务需要查询大量数据，很容易超时。我建议把超时时间设到 30 秒以上，具体看你的服务响应速度。
第四个坑是权限范围。有些 MCP 服务默认会暴露所有能力，但你可能只需要其中一两个。建议在配置时明确指定需要的能力，减少不必要的调用和潜在的安全风险。
3.3 怎么验证 MCP 是否真的接上了
配置完之后，不要急着用，先做一轮验证。我的验证流程是这样的：
第一步，检查服务是否启动。大多数 MCP 客户端会有一个状态面板，能看到每个服务的连接状态。如果显示未连接，先看日志。
第二步，做一次最小调用。比如文档 MCP，就问它一个你确定答案的问题，看返回是否正确。这一步能排除认证问题和数据源问题。
第三步，测试边界情况。比如问一个文档里不存在的内容，看它是老实说"不知道"还是瞎编。这一步很重要，能帮你判断这个 MCP 的可靠性。
第四步，观察响应时间。如果每次调用都要等十几秒，那实际使用体验会很差，需要考虑优化或者换方案。
我见过有人配置完就直接用，结果用了半天发现数据源接错了，白忙活。花十分钟做验证，能省下后面几个小时的排查时间。
4. Skill 编写的心法：从"能跑"到"好用"的距离
4.1 Skill 的结构应该包含哪些部分
一个能用的 Skill 和一个好用的 Skill，差距往往在结构设计上。我经过多次迭代，现在写 Skill 基本遵循这个结构：
角色定义：明确这个 Skill 是干什么的，它的职责边界在哪里。这部分要写得具体，不要写"你是一个前端专家"这种空话，而要写"你负责根据接口定义生成 TypeScript 类型文件，不负责生成业务逻辑代码"。
输入规范：说明这个 Skill 需要什么输入，格式是什么。比如"输入应该是一段 JSON 格式的接口定义，包含 url、method、params、response 四个字段"。
处理规则：这是核心部分，要写清楚处理逻辑。包括命名规范、类型映射规则、边界情况处理等。这部分越具体越好，最好配上正反例。
输出格式：明确输出应该长什么样。如果是代码，要说明文件结构、导入规范、注释要求。
异常处理：说明遇到不符合预期的输入时该怎么办。是报错、是询问、还是用默认值兜底。
我举个例子。我们团队有一个"接口转类型"的 Skill，它的处理规则部分是这样写的：
命名规则： - 接口路径 /user/profile 转换为类型名 UserProfile - 路径中的连字符转为驼峰，如 /user-basic-info 转为 UserBasicInfo - 如果路径以数字结尾，数字保留，如 /v2/user 转为 V2User 类型映射： - string 类型且字段名包含 time/date/at 的，映射为 string（ISO 格式） - number 类型且字段名包含 id 的，映射为 number - 嵌套对象递归处理 - 数组类型标注为 T[] 边界处理： - 字段值为 null 时，类型标注为 T | null - 字段可选时，添加 ? 标记 - 遇到无法识别的类型，标注为 unknown 并添加 TODO 注释这种程度的细节，才能保证输出稳定。如果只写"根据接口定义生成类型"，那每次生成的结果可能都不一样。
4.2 提示词里的"负向约束"比正向描述更重要
这是我在实践中最大的一个心得。刚开始写 Skill 的时候，我总想着"要让它做什么"，写了一大堆正向描述。后来发现，明确"不要做什么"往往更能提升输出质量。
比如我写"生成 React 组件"的 Skill 时，正向描述写了组件结构、props 定义、样式方案。但生成的结果总是五花八门，有时候用函数组件，有时候用类组件，有时候用 CSS Modules，有时候用 styled-components。
后来我加了一段负向约束：
不要做的事： - 不要使用类组件，统一用函数组件 + Hooks - 不要引入 styled-components，统一用 CSS Modules - 不要使用 any 类型，所有 props 必须有明确类型 - 不要生成 console.log 调试代码 - 不要添加未在需求中提到的额外功能加上这段之后，输出的稳定性明显提升。原因很简单：AI 在生成内容时，如果没有明确约束，它会从训练数据里"平均"各种写法，结果就是风格混杂。负向约束相当于给它划定了边界，让它在一个更小的空间里发挥。
4.3 版本管理和迭代节奏
Skill 不是写完就一劳永逸的，它需要持续迭代。我的做法是给每个 Skill 建一个独立的目录，用 Git 管理，每次修改都写清楚改了什么、为什么改。
迭代的触发点通常有三个：一是发现输出不符合预期，需要补充规则；二是业务规范变了，需要同步更新；三是发现了更好的写法，需要优化。
这里有个经验：不要频繁改 Skill。我一开始特别勤快，每次遇到问题就改一版，结果改到最后自己都记不清哪个版本是什么逻辑了。后来我改成每周固定时间 review 一次，把这一周遇到的问题集中处理，这样既保证了迭代，又不会太碎片化。
另外，每次改完 Skill 之后，一定要用之前的测试用例跑一遍，确保没有破坏已有的功能。我吃过这个亏，改了一个规则，结果影响了另一个场景的输出，用了两天才发现。
5. 把 Skill 和 MCP 串起来：一个完整的前端工作流改造案例
5.1 改造前的流程长什么样
我拿我们团队最典型的一个需求来举例：新增一个"订单管理"页面。改造之前，这个流程是这样的：
产品经理给需求文档，里面描述了页面要展示哪些字段、支持哪些操作。然后我要做这几件事：去接口平台找对应的接口定义，去组件库文档查可用的组件和属性，去设计稿看布局和样式，然后开始写代码。写完之后要补类型定义、写表单校验、加埋点、写单元测试。
整个流程下来，一个中等复杂度的页面大概需要 1.5 到 2 天。其中真正写业务逻辑的时间可能只占 40%，剩下 60% 都花在查资料、对格式、补样板代码上。
5.2 改造后的流程和实际提效数据
改造之后，我把流程重新设计了一遍。现在的工作流是这样的：
第一步，我把需求文档和接口定义一起丢给 AI，让它生成页面的骨架代码，包括路由配置、页面结构、类型定义。这一步用到了接口 MCP 和文档 MCP。
第二步，我 review 生成的骨架，调整不符合预期的地方。这一步大概花 20 分钟。
第三步，我让 AI 根据设计稿标注生成样式代码。这一步用到了设计 MCP。
第四步，我补充业务逻辑和交互细节。这部分是 AI 替代不了的，需要我自己写。
第五步，我让 AI 生成单元测试和埋点代码的初稿，我再调整。
整个流程下来，同样的页面现在大概需要 4 到 6 小时，提效大概在 50% 到 60%。但更重要的是，我的工作体验变了。以前是"查资料-写代码-查资料-写代码"的循环，现在是"审阅-调整-补充"的流程，注意力更集中，疲劳感明显降低。
这里我要强调一点：提效数据因人而异，不要被别人的数字绑架。我见过有人宣称提效 300%，那要么是任务特别简单，要么是统计口径有问题。对于真实的前端业务开发，能稳定提效 30% 到 50% 就已经很可观了。
5.3 哪些环节 AI 还是替代不了
用了几个月下来，我越来越清楚 AI 的边界在哪里。以下这些环节，我试过让 AI 做，但效果都不理想：
业务逻辑的边界判断。比如"这个订单在什么状态下允许取消"，这种规则往往散落在产品文档、历史需求、口头约定里，AI 很难准确掌握。
跨系统的协调。比如这个页面要调用三个不同的服务，服务之间的调用顺序、错误处理、降级策略，这些需要人来设计。
性能优化。AI 能给出通用的优化建议，但具体到你的项目，哪个组件渲染慢、哪个接口响应慢，需要实际测量和分析。
代码审查。前面说过了，AI 的审查建议往往"正确但无用"，因为它缺乏业务上下文。
认清这些边界很重要，它能帮你把精力放在真正有价值的地方，而不是盲目地追求"全流程 AI 化"。
6. 踩过的坑和沉淀下来的经验
6.1 数据安全是第一条红线
这一点我必须放在最前面说。把内部文档、接口定义、代码仓库接入 MCP 的时候，一定要确认数据流向。有些 MCP 服务会把数据发送到外部服务器，如果你的数据涉及敏感信息，这就是严重的安全隐患。
我的做法是：所有涉及内部数据的 MCP 服务，必须部署在内网。如果做不到内网部署，那就只接入脱敏后的数据，或者干脆不接。这个没有商量余地。
另外，配置文件里的密钥、token 这些，绝对不要提交到代码仓库。用环境变量或者密钥管理服务，这是基本操作。
6.2 不要追求"全自动"，要追求"半自动"
我一开始的执念是让 AI 全自动完成一个任务，从输入到输出不需要人工干预。结果发现，为了达到这个目标，我要写大量的规则和异常处理，维护成本极高，而且一旦遇到规则外的输入就崩了。
后来我调整了思路：让 AI 完成 70% 到 80% 的工作，剩下的由人来收尾。这样 Skill 的复杂度大幅降低，稳定性反而更好。比如生成页面代码，我不要求它一次生成完美的代码，而是生成一个"结构正确、细节待调"的初稿，我再花十几分钟调整。这个模式比追求全自动实用得多。
6.3 团队协作时的共享和隔离
如果你想把 Skill 和 MCP 分享给团队用，有几个问题要提前想清楚：
哪些是公共的，哪些是个人的。公共的比如组件库文档 MCP、接口 MCP，应该统一配置。个人的比如代码风格偏好、常用片段，可以各自维护。
版本怎么同步。公共 Skill 更新了，怎么通知团队成员？我的做法是建一个共享仓库，用 Git 管理，更新时在群里同步一下。
权限怎么控制。不是所有人都需要访问所有 MCP 服务。比如接口 MCP 可能包含敏感信息，应该做权限控制。
怎么收集反馈。用的人多了，问题也会多。我建了一个简单的反馈表，大家遇到问题就填一下，我每周集中处理。
6.4 一个实用的排查清单
最后分享一个我常用的排查清单，当 Skill 或 MCP 出问题时，按这个顺序检查：
| 排查项 | 检查内容 | 常见问题 |
|---|---|---|
| 服务状态 | MCP 服务是否正常运行 | 进程挂了、端口被占 |
| 认证信息 | token 是否过期、权限是否足够 | 密钥过期、权限不足 |
| 数据源 | 数据源是否可访问、数据是否最新 | 数据源变更、缓存过期 |
| 配置格式 | 配置文件格式是否正确 | JSON 语法错误、字段名拼错 |
| 输入格式 | 输入是否符合 Skill 预期 | 格式不符、缺少必填字段 |
| 输出验证 | 输出是否符合预期 | 规则冲突、边界未覆盖 |
这个清单看起来简单，但能覆盖 90% 以上的常见问题。我建议你把它存下来，遇到问题先过一遍，能省不少排查时间。
用了这几个月，我最大的感受是：Skill 和 MCP 不是什么神奇的东西，它们本质上是把你原本散落在脑子里的经验和流程，用一种结构化的方式固化下来。这个过程本身就有价值，因为它逼着你去思考"我到底是怎么做这件事的""哪些步骤是必要的，哪些是可以省略的"。至于 AI 能帮你省多少时间，那是副产品。真正重要的是，你对工作的理解变得更清晰了。
