跳到主要内容

Skills 与 MCP

TL;DR​

前端团队在 AI 协作里最常见的低效，不是“工具太少”，而是“能力顺序错了”。
设计稿任务没先拿 Figma 上下文，React 重构没先收紧组件边界，浏览器问题没先进真实页面，最后所有上下文都堆进同一段对话里，返工自然会高。

这页真正想回答的不是“有哪些 skill”和“有哪些 MCP”，而是三件更实际的事：

  1. 什么时候该先用方法类 skill 收紧工作方式。
  2. 什么时候必须先用 MCP 拿真实世界上下文。
  3. 当你已经知道主题页在哪时，下一步应该去哪个官方入口，而不是再自己搜一轮。

为什么这页需要重写​

先把三个对象分开，不然前端任务很容易一开始就走歪​

当前主流 agent 产品和工具，其实已经把这三层分得很清楚：

  • 事实：OpenAI 在 Introducing the Codex app 中，把 skills 描述为可打包 instructions、resources 和 scripts 的方式，用来让 agent 按稳定偏好连接工具并执行工作流。
  • 事实：Figma 在官方 Guide to the Figma MCP server 中，把 Figma MCP 定义为把设计上下文、组件、变量和 Code Connect 带进开发环境的方式。
  • 事实：Context7 在官方 Intro 中，把自己的作用写得非常直接：给 AI coding assistant 提供最新、版本化的文档与代码示例，减少过时知识和幻觉 API。
  • 事实：Model Context Protocol 官方 Core architecture 文档说明，MCP 的核心是 host、client、server 的 client-server 架构，让 LLM 应用能够以标准接口接入外部上下文、工具与 prompt。

把这些官方表述放到一起看，前端任务里最稳的三层其实是：

层级它真正负责什么前端语境里的典型问题
Skill固定方法、边界和做事顺序React 重构先收紧组件职责，bug 排查先证明问题
MCP提供真实世界上下文与外部能力设计稿节点、浏览器页面、官方文档、文件资源
Task brief定义本轮目标与验收这次到底要改哪页、交什么证据、哪些不做

真正的问题从来不是“我会不会用很多工具”，而是“我有没有先拿到当前任务最关键的那层能力”。

能力编排板​

前端能力编排板

这张图把“方法、真实上下文、任务包、证据”压成了三个典型前端任务。它的作用不是替代表格，而是帮你先建立默认顺序，再回到具体 skill 和 MCP 组合表。

先区分三类能力​

能力类型更适合解决什么问题前端典型例子
Skill工作方法、约束、最佳实践React 组件边界、TDD、系统化调试、验证闭环
MCP实际世界上下文与外部系统Figma 节点、浏览器页面、官方文档、截图、文件资源
普通任务 brief本次任务目标与验收“重构 pricing 页 Hero 并补移动端抽屉”

最稳的顺序通常是：先用 skill 决定工作方法，再用 MCP 拿真实上下文，最后让任务 brief 约束范围和产出。

前端任务到能力编排矩阵​

任务形状优先 skill必要 MCP / 上下文任务包至少要补什么预期交付物
设计稿落地figma、react-best-practicesFigma 节点、截图、token、浏览器能力路由、断点、设计输入、组件边界页面骨架、断点截图、token 对照
React / Vue 组件治理react-best-practices、typescript-react-patterns、state-management文件读取、必要时 Context7共享层边界、状态职责、验证命令组件分层说明、状态边界、验证结果
浏览器 bug 修复systematic-debugging、verification-before-completion浏览器能力、录屏、日志或控制台复现步骤、受影响断点、验收条件复现说明、修复说明、录屏、命令结果
设计系统或共享层重构writing-plans、executing-plans、verification-before-completion设计 token、目录结构、相关页面截图受影响页面、包边界、阶段验证计划、影响面清单、截图、风险说明
文档与规范补强technical-docs-editor目标文档、相邻文档、索引页主题边界、相关页、build 验证要求体检结论、扩写计划或直接改稿摘要
发布前收口verification-before-completion、requesting-code-review命令输出、浏览器截图、PR 草稿验证命令、截图位置、风险项Verification、Artifacts、Risks、review 结论

这张表的关键不是“技能越多越好”，而是让每一类前端任务都先拿到正确的方法、上下文和交付物。

前端高频任务到 skills 的映射​

任务形状优先 skill为什么
React 组件治理react-best-practices、typescript-react-patterns先收紧组件职责、props、事件和类型边界
状态边界梳理state-management先区分远程状态、本地状态和共享状态
设计稿落地figma、react-best-practices先拿设计输入，再落到真实组件结构
Bug 排查systematic-debugging先证明问题，再写修复
改动较大writing-plans 或计划先行能力先拆步，避免跨目录乱改
文档与培训资产扩写technical-docs-editor先体检结构、决策层和证据位，再决定是否直接改稿
交付收口verification-before-completion、requesting-code-review先补证据，再声称完成

前端最值得优先使用的 MCP​

MCP / 能力什么时候最有价值前端场景
Figma MCP设计稿、节点、变量、截图是真实输入时页面还原、组件提炼、token 对齐
Context7需要最新官方接口或文档时Next.js、React、Playwright、Tailwind 新 API
浏览器 / Playwright 类能力需要真实页面行为和截图时复现 bug、检查断点、录制交互路径
文件与资源读取需要理解 repo 中的 token、配置、素材文件时设计 token、内容配置、静态资源目录

一个常见错误是：前端任务明明依赖 Figma 和浏览器，却只给文本说明。这样模型只能猜视觉、猜交互、猜断点，返工自然会高。

官方入口速查​

issue #3 暴露出的真正问题，其实很典型：
读者已经进到了正确主题页，但页面还没有把“下一步去哪里看官方入口”做成显性动作。

这里先说明一个边界：本仓库里的 skill 多数是本地方法模板，不一定一一对应某个独立产品官网。
所以真正值得点出去的，通常不是 skill 名称本身，而是它依赖的外部协议、平台或官方文档。

更稳的理解方式是：

  • 当你需要“方法”，先留在站内看 skill 和 workflow。
  • 当你需要“真实上下文”或“最新接口”，再点去外部官方入口。
  • 当你只是模糊觉得“我听过这个名字”，不要一开始就开十几个标签页。
能力 / 主题站内入口官方或参考入口什么时候值得点出去
Figma MCP设计 / FigmaFigma MCP Catalog
Figma Dev Mode MCP server 介绍		你需要确认 Figma MCP 支持范围、接入方式或产品定位时
Context7当前页Context7你已经知道要查最新官方文档，但还没进入对应库的检索入口时
PlaywrightPlaywright 自动化测试方案Playwright Docs你已经决定要做浏览器自动化，需要对照 API、配置或 runner 细节时
MCP 协议本身MCP 与协议生态Model Context Protocol: Introduction
Model Context Protocol: Architecture overview		你需要先理解协议层，而不是直接挑某个 server 时

如果你在站内页面已经能明确任务形状，就先用站内页缩小范围；只有当你需要核对产品能力、最新接口或官方接入细节时，再点出去看官方入口。这样更不容易在一开始就掉进“开十几个标签页，但还没开始做事”的低效模式。

默认能力组合​

设计稿任务​

  1. 先启用 figma 或等价设计上下文能力，读取节点、截图、变量和层级。
  2. 再用 React / Vue 相关最佳实践 skill，约束组件边界和目录位置。
  3. 实现完成后，用浏览器或 Playwright 能力补断点截图和交互录屏。
  4. 最后用验证类 skill 收口命令、截图和风险说明。

这条组合链路特别适合页面首版、设计系统提炼和高保真还原任务。

浏览器问题​

  1. 先用浏览器能力复现，而不是先猜源码。
  2. 再启用 systematic-debugging 限制排查顺序。
  3. 修复完成后，用 verification-before-completion 收口录屏、截图和 smoke path。

共享层治理​

  1. 先用 writing-plans 或计划类能力拆步。
  2. 再读取目录结构、共享组件、token 和受影响页面。
  3. 最后用验证类 skill 收口跨目录影响和风险说明。

文档与规范补强​

  1. 先启用 technical-docs-editor，读目标页、索引页和相邻页。
  2. 先判断是“结构问题”还是“局部单薄”。
  3. 如果要大改结构，先出计划；如果结构稳定，再直接补表格、模板资产和案例位。

前端浏览器问题的默认能力组合​

问题建议组合为什么
样式只在移动端坏浏览器能力 + 样式系统文档 + 验证闭环先看真实窄屏，再改 token 或布局
某个交互路径失效浏览器能力 + systematic-debugging + Playwright先复现，再判断是逻辑问题还是选择器问题
断点切换抖动浏览器截图 + repo 结构检查 + 测试与交付要求先确认是页面私有逻辑还是共享组件问题

如果你不先进真实页面，只在代码层推理，前端 bug 很容易被误判。

能力编排失败的 5 个前端信号​

失败信号说明缺了什么修正动作
设计稿任务只有整屏截图缺结构化设计上下文先补 Figma 节点、变量或关键局部截图
组件重构直接开改缺方法约束先补 react-best-practices 或计划能力
浏览器 bug 只给报错片段缺真实页面上下文先补复现步骤、录屏和断点环境
文档补强只拉长正文缺结构体检先用 technical-docs-editor 识别结构层、证据层缺口
发布前只有“应该没问题”缺验证证据先跑命令，再补截图和风险说明

MCP 使用失败的 4 个前端信号​

  1. 设计稿任务没有节点上下文，只有整屏截图。
  2. UI bug 修复没有真实浏览器复现，只有报错片段。
  3. 查最新框架接口时没有查官方文档，直接凭旧印象改。
  4. 需要真实截图或视频的任务，却把“请帮我验证”留在纯文本层。

能力编排时至少要补的证据​

任务类型至少要补什么证据
设计稿落地关键断点截图、设计节点说明、token 或组件边界说明
浏览器 bug复现步骤、录屏、修复后截图、最小 smoke path
共享层重构计划、影响面清单、受影响页面截图、验证结果
文档补强结构变化摘要、相关页联动、build 结果

训练任务​

训练任务目标交付物
任务 1：用 Figma 节点重建一个页面骨架练设计上下文读取节点说明、页面骨架、断点截图
任务 2：为 React 重构任务选 skill 组合练能力编排skill 选择表、边界说明、验证计划
任务 3：用浏览器能力复现并关闭一个前端 bug练真实页面调试复现步骤、修复说明、录屏和命令结果

能力编排案例地图​

这一页最适合配合真实案例一起读，因为“选对 skill 和 MCP”本身不是结果，真正要看的是它们有没有把任务包、上下文和证据收成一条线：

现在的前端任务先看哪篇案例为什么值得搭配本页
本地先读设计和代码，再把长执行段交给后台VS Code Agents 本地到后台交接案例适合看 skill、设计上下文和执行段 handoff 怎么配合
中等规模重构，需要计划、验证和阶段收口OpenAI Codex 重构与验证案例最适合对照“方法 skill + repo 上下文 + 验证证据”这条链路
多个 lane 并行推进，最后由 owner 收口Cline 并行 Worktree 收口案例适合看多入口并行时，能力编排如何避免共享层失控

看这些案例时，建议只追三条线：

  1. 先用了什么方法类 skill，为什么不是直接开改。
  2. 真实上下文是怎么补进来的，比如 Figma、浏览器、目录结构或命令输出。
  3. 最终交付里哪些证据证明这套能力编排是对的。

能力编排的媒体联动表​

如果你准备把这页用作培训材料，最稳的方式不是只讲 skill 名单，而是把“视频演示 -> 案例 -> 交付物”放在同一张表里：

前端能力编排证据板

训练主题先看哪个视频再看哪篇案例至少要观察或交付什么
设计上下文 + 组件实现Claude Code + Figma 工作流VS Code Agents 本地到后台交接案例Figma 上下文、brief、组件边界和断点截图
浏览器复现 + 验证收口Claude Code + Playwright 浏览器自动化Claude Code Bugfix 闭环案例复现步骤、录屏、最小 smoke path、命令结果
长链路重构 + 阶段验证使用 OpenAI Codex 构建精美前端界面OpenAI Codex 重构与验证案例计划、影响面、阶段验证、风险说明

案例与视频路径​

下一步​

Sources​