★ FEATURED ARTICLE 1. 在职前端为什么突然都在聊 Skill 和 MCP最近半年如果你混迹在前端圈子里会发现一个明显的变化以前大家聊的是你 Vue 还是 ReactVite 还是 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 的映射为 stringISO 格式 - 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 能帮你省多少时间那是副产品。真正重要的是你对工作的理解变得更清晰了。
阅读完成 · 觉得有帮助？
