2025年做前端如果你还没认真折腾过 MCP 和 Skill说实话已经有点落伍了。我最近半年几乎每天跟这两个东西打交道——让 AI 自己打开浏览器跑页面、把团队规范写成技能包丢给 AI 执行、把防爬虫和源码保护的安全检查做成自动化动作。今天的分享就是把这些实践原原本本讲清楚先说清 MCP 和 Skill 到底解决什么问题然后给一份适合在职前端直接抄作业的 MCP 清单再手把手教你写自己的前端 Skill最后聊聊安全、部署、面试和那些踩坑经验。适合所有刚接触 AI 辅助开发、想知道这些工具怎么真正落地到日常工作的前端同行。1. 先搞清楚MCP 和 Skill 到底在解决什么1.1 MCP 是给 AI 装上的万能转接头MCPModel Context Protocol这个名字对新人挺劝退的但你可以把它理解为 AI 和外部工具之间的“USB-C 转接头”。以前你让 AI 帮忙查个接口报错它只能凭空猜测现在通过 MCPAI 可以拿着这个协议直接去读你的接口返回、打开浏览器看页面表现、查一下 Git 提交记录甚至把数据库里某条数据拉出来给你看。本质就是一套统一标准让 AI 的对话能力可以触达真实开发环境中的各种工具和数据源。对前端来说最有价值的 MCP 场景大概是三类浏览器调试类、代码工程类、数据可视化类。浏览器调试类里以 Playwright MCP 为代表AI 可以直接驱动浏览器做点击、截图、读取控制台报错这就相当于你多了一个“长着眼睛和手的同事”。代码工程类包括文件读写、Git 操作、依赖检测等AI 不再局限于聊天框里的文本而是可以真实修改你的代码文件并跑命令。数据可视化类则让 AI 能接上地图、数据库直接帮你生成带真实数据的前端图表或 GIS 地图页面。但 MCP 并不是越多越好我也见过有人一口气配了十多个 MCP 服务器结果 AI 在选择工具时反而犯迷糊。合理的方式是“按需接入”当前面向什么任务就启用对应的 MCP。比如你正在调页面交互那就把浏览器类 MCP 开起来你在做接口联调那就把数据库和接口类的 MCP 配上其他的一律关掉。接入太多不仅启动慢AI 的注意力也会被稀释这个坑我在实践里反复踩过。1.2 Skill 是给 AI 的业务说明书如果说 MCP 解决的是“AI 能碰到哪些工具”那 Skill 解决的就是“AI 拿到这些工具后该怎么干活”。Skill 本质上是一个目录包里面包含一份说明文档通常叫 SKILL.md和配套的脚本、参考资源。这份说明文档用自然语言把任务目标、执行步骤、注意事项、代码规范写得清清楚楚AI 看到这个包之后就会按照里面的流程去办事。我习惯这样类比MCP 相当于给了 AI 一套工具箱Skill 则是这本工具对应的“标准操作规程”。比如说你需要 AI 生成一个符合公司规范的业务组件如果只是口头描述AI 可能直接给你一个千奇百怪的文件但如果你写好了一颗“Business Component Skill”里面明确写了要用 TypeScript、要带单元测试、要遵循团队的目录结构、要支持主题变量那 AI 产出的东西基本就是能直接提交的水平。这就是 Skill 最大的价值——把团队或个人积累的“编码经验”沉淀成 AI 可以直接消费的资产。很多同学分不清 Skill、Plugin 和普通 Prompt 的区别。普通 Prompt 是一次性的提示词聊完就没了Plugin比如某些 IDE 插件通常是一段程序逻辑改起来需要写代码而 Skill 是结构化的文档加资源包可以随仓库分发、可以多版本管理、可以被 AI 在需要时自动加载。前端团队可以像管理 npm 包一样管理自己的 Skills把规范、模板、经验全部固化下来这是它最值得投入的地方。2. 在职前端值得装进开发环境的 MCP 清单2.1 浏览器调试类把“眼见为实”交给 AI在所有前端 MCP 里我第一个推荐的就是 Playwright MCP。Playwright 本身就是微软出品的浏览器自动化框架而 Playwright MCP 把它包装成了 AI 可以调用的工具集。装上之后AI 能打开你指定的 URL执行点击、输入、滚动、截图还能拿到页面的 DOM 结构和 console 日志。对前端来说最爽的场景就是排查那种“只在特定环境复现”的 bug你把复现路径描述给 AIAI 自己打开本地开发服务器、一步步操作、把报错截图回来效率比你手动点半天高得多。配置 Playwright MCP 在 Claude Desktop 或支持 MCP 的客户端里非常简单。以 JSON 配置为例你需要声明一个 mcpServers 对象address 指向 Playwright MCP 的地址即可。一般有两种接入方式本地脚本模式和远程服务模式。本地模式适合日常开发调试远程模式适合团队共享一个测试浏览器环境。我个人建议日常开发就用本地模式因为调试本地代码始终需要拿到 localhost 的权限远程模式反而会绕一圈。除了 Playwright MCP浏览器类还有 Chrome DevTools MCP 这类方案可以直接读取 Network 面板的请求记录、修改 CSS 样式、查看 Performance 数据。我实际体验下来DevTools MCP 在做性能优化时特别有用因为 AI 可以直接读取页面加载的资源大小和耗时分布然后给出具体的优化建议。这类工具的核心优势是让 AI 不再是“盲人摸象”而是能亲眼看到页面在浏览器里的真实表现。2.2 工程类 MCP打通代码和构建链工程类 MCP 的作用是把 AI 从“对话窗口”拉进“你的项目目录”。文件系统 MCP 是最基础也最常用的一类它授权 AI 读取和修改你指定范围内的文件。这里有个安全技巧不要把整个磁盘都开放给文件系统 MCP而是只开放当前项目目录避免 AI 误操作到其他敏感文件。我见过为了省事把根目录授权给 AI 的同事结果 AI 在改文件时差一点动了项目外部的配置相当吓人。Git MCP 也值得拥有。它让 AI 可以查看当前分支、提交记录、甚至直接创建提交和拉取请求。对前端这种频繁联调、频繁发版的场景来说AI 帮你做一次常规提交、组一个清晰的 commit message其实是挺爽的体验。不过要注意AI 的 Git 操作一定要在提交前人工 review尤其是涉及 force push 这种危险动作我建议在 Skill 或提示词里明确禁止。还有一类工程 MCP 是围绕前端 SDK 和框架的辅助工具比如类型检查、ESLint、测试运行器。有些团队会把 ESLint 和单元测试命令封装成 MCP 工具让 AI 改完代码后自己跑一遍 lint 和测试不通过就继续修直到绿了才提给开发者。这样一来AI 的质量下限就被工具约束住了不像以前那样“聊得挺好代码一跑就崩”。2.3 数据和可视化类 MCP直接生成真实页面前端开发不可能永远只做静态页面接数据、做可视化是家常便饭。数据库 MCP 可以让你直接授权 AI 查询本地或远程数据库比如 SQLite MCP、PostgreSQL MCP。实测下来最有用的场景是后端接口还没好但数据库表已经建了这时让 AI 直接按表结构生成一个 mock 接口或临时页面联调效率会大幅提升。当然生产环境数据库千万不要开放权限给 MCP这也是最基本的底线。可视化相关的 MCP 也越来越多地图是最典型的一个。百度地图有对应的 MCP 服务GIS 领域也有空间分析的 Skill 生态。前端做智慧城市、物流轨迹、数据大屏这类项目时如果用 MCP 让 AI 直接去拉地理数据和经纬度坐标再配合前端图表库生成页面能省掉大量重复的数据预处理工作。可以说只要某个开发环节存在“数据源 工具的连接问题”就值得考虑有没有合适的 MCP 可以接入。给个建议在整理自己 MCP 清单时可以按照“调试 / 工程 / 数据”三类去维护每个分类控制在两到三个工具。不是为了显得专业而是为了让 AI 的上下文不至于被杂乱工具淹没。工具越多模型在选择时越容易出错这个现象几乎人人都能遇到。3. 手写一个前端专用 Skill从零到可复用3.1 Skill 的目录结构和最小可用配置写 Skill 不需要什么魔法核心是目录和文档。一个标准的前端 Skill 在项目里通常是这样的结构在 .claude/skills 下面建一个子目录里面放一个 SKILL.md再加上可选的 scripts、references 目录。SKILL.md 的头部是 YAML frontmatter至少要有 name 和 description 两个字段description 尤其重要因为 AI 就是靠它来判断“这个技能什么时候可以用”。我举个实际写入的例子。假设你要做一个 React TypeScript 业务组件生成器SKILL.md 可以写成这样--- name: react-business-component description: 根据用户需求生成符合团队规范的 React TypeScript 业务组件包含样式文件、测试文件和组件文档。在用户要求创建页面组件或业务组件时使用。 allowed-tools: read_file, write_file, run_command --- # React Business Component Generator ## 前置条件 - 项目使用 React 17 和 TypeScript - 组件目录位于 src/components - 样式使用 CSS Modules ## 执行步骤 1. 确认组件名称和用途将其转换为 PascalCase 2. 创建组件目录 src/components/{ComponentName} 3. 生成 index.tsx、index.module.css、__tests__/index.test.tsx 三个文件 4. 组件 props 禁止使用 any必须有明确的类型定义 5. 运行 pnpm test 验证测试通过 ## 注意事项 - 禁止引入未在 package.json 中声明的依赖 - 样式类名必须使用 camelCase这段内容看起来简单但它是实实在在的规范落地。AI 以后只要遇到“帮我写一个表格组件”“生成一个弹窗组件”这类需求就会自动加载这个技能然后按你的规则执行。你不用每次重复强调“用 TypeScript”“带测试”它全记得。这也是我在团队里最推荐的实践把口头上的代码规范写进 SkillAI 就是最严格的那个“代码审查新人”。3.2 实例一业务组件生成 Skill继续以组件生成 Skill 为例展开。你可能会问为什么说这种 Skill 比普通 Prompt 靠谱因为普通 Prompt 只有文本很容易被对话历史稀释而且不同次对话的规范描述可能不一致。Skill 则是固定文件每次调用都是按照同一份规则来执行可复现性非常强。我实际用下来写这类 Skill 的关键在“边界清晰”。比如组件需求中明确说“只生成前端代码”那 Skill 里就要写“不修改后端接口、不生成文档站配置”。如果不写这些边界AI 经常会在你只想要一个按钮组件的时候自动帮你改了一堆无关文件。这是我加进 Skill 的高频条款“如无明确要求不得修改组件目录之外的文件。”另一个细节是“描述”越具体越好别用“提升开发效率”这种空话。AI 判断是否需要触发某个 Skill靠的就是 description 里的语义匹配。比如上面例子的描述里写清楚了“在用户要求创建页面组件或业务组件时使用”AI 就很容易命中。你要是写成“一个好用的组件工具”它大概率都不知道该什么时候用。3.3 实例二前端代码审查 Skill除了生成代码Skill 还可以用来做代码审查。我团队里就有一个“前端审查 Skill”里面列了四类检查维度安全XSS 风险、dangerouslySetInnerHTML 滥用、性能大数组渲染、未使用 memo、可访问性按钮缺 aria 标签、图片缺 alt、规范命名、目录、依赖声明。AI 在每次提交前会自动跑一遍这个检查把问题列成清单。写审查 Skill 的时候有个小技巧把常见问题写成“如果……那么……”的规则越具体越好。比如“如果用户输入被直接拼接到 innerHTML 中标记为高危问题并建议改用 textContent 或可信的 HTML 清理库”。这比写一句“注意安全”有用得多。AI 掌握这类规则后代码审查质量有时候真的不比普通组员低很多低级问题在提交之前就被拦下来了。当然审查 Skill 也有局限它对业务逻辑的理解肯定不如人但它的强项是稳定性和覆盖面。人容易累、容易漏AI 每次都会老老实实地把所有维度检查一遍。从个人角度说我已经养成习惯了代码写完先让 AI 按审查 Skill 跑一遍再自己瞄一眼最后才提交。3.4 实例三大文件分片上传 Skill热词里有人提到“前端使用 worker 上传大文件”这也是一个非常适合做成 Skill 的场景。前端大文件上传最常见的问题是文件太大导致请求超时、内存占用过高以及进度反馈不流畅。常规解法是分片上传加 Web Worker把文件切成若干块在 Worker 线程里做哈希计算和上传任务避免阻塞主线程同时在断网或失败时支持重试。这类 Skill 的文档里应该包含分片大小设定、并发数控制、失败重试策略这些参数。以我的经验单个分片建议控制在 2MB 到 10MB 之间并发数在 3 到 5 之间比较稳定。太大容易超时太小又会让请求数暴涨。哈希算法方面推荐用 SparkMD5 或 Web Crypto API前者兼容性好后者是原生能力性能更好。把完整方案写进 Skill 后以后任何项目要做上传功能AI 都会自动按这套可靠方案生成代码不用你重新踩一遍单车。这种“解决问题型 Skill”最显个人功力因为它包含的是你从实战里得出的参数和经验。代码生成类 Skill 可能谁都能写但带具体调优参数和实践总结的 Skill才是真正值钱的东西。4. 前端安全专场防爬虫、防扒源码、安全配置4.1 “防查看源码”的认知纠偏热词里有一堆与前端安全相关的词比如防止爬虫、防止查看页面源码、防止打开、安全技术操作。这些需求在业务里很常见但第一个要纠正的认知是前端代码永远无法做到绝对保密。无论你怎么混淆、怎么加密只要代码跑到用户浏览器里用户就有办法拿到它。你能做的是提高获取和破解的“成本”让普通用户和轻度爬虫知难而退而不是幻想完全阻挡。“防止查看源码”最常见的操作是禁右键、禁快捷键、禁复制然后加一点代码混淆。这些手段对普通用户有效但对稍有技术能力的人来说形同虚设。如果你真要给代码增加一层阻碍可以引入混淆器比如 JavaScript Obfuscator把变量名、字符串、控制流都做混淆让源码的可读性大幅下降。代价是包体积增加和运行速度变慢需要你自己做权衡。关于“防止打开”这个点我猜你可能指的是“防止别人通过开发者工具调试或直接打开源码看内部逻辑”。常见的做法是检测开发者工具是否打开一旦检测到窗口尺寸异常就跳转或清空页面内容。但这类检测很容易产生误伤而且反调试代码本身也会成为被分析的目标。我的建议是不要把大量精力花在这种本地对抗上不值得。4.2 防爬虫的工程化手段真正值得投入的防爬虫是工程化的、前后端配合的安全体系。前端层面能做的事情包括对关键接口做请求签名比如把时间戳、随机数和业务参数一起签名后端验签、接入风控验证码滑动、点选、行为验证、在数据渲染时加入一些无感知的 hash 校验字段。这些手段会显著增加爬虫脚本的编写成本因为对方必须去逆向你的签名逻辑。接口层面是最关键的。限制单个 IP 的请求频率、对异常 UA 和 Header 做拦截、在返回数据时加入时间戳和 token 校验这些都要后端配合实现。纯前端只能做展示层保护真正的数据安全要靠服务端。我见过很多团队要求前端“加密一下接口”仿佛这样就能防止爬虫其实只要请求发出去接口参数就必然可以被分析。把主要精力放在风控和后端验证上才是正路。还要说一句防爬的度要拿捏好。我们自己做开发时也经常需要访问别人的网站分析样式如果动机正当、频率低、不涉及数据滥用是没有问题的。过度防御不仅消耗用户体验还可能误伤正常用户。合理的防爬策略应该是“针对异常流量精确打击”而不是对所有访客施加层层障碍。4.3 前端安全基线配置不管业务需不需要防爬有几条安全基线是每个前端项目都应该做的。第一是 Content-Security-PolicyCSP响应头它可以从浏览器层面限制脚本、样式、图片的资源来源能在很大程度上缓解 XSS 攻击。配置方式是在服务端返回头或通过 meta 标签声明建议从“只允许同源资源 必要的白名单域名”开始。第二是 cookie 和请求的安全属性。Cookie 尽量设置 HttpOnly、SameSiteSession 标识或 token 不要放在 URL 参数里避免泄露到日志和来源统计中。第三是第三方依赖的安全扫描也就是 npm audit这个很多人只在 CI 报错时才看一眼平时根本不查。其实把 npm audit 集成进提交前检查或流水线里对减少已知漏洞非常有帮助。前端安全技术操作还包括表单输入过滤、输出编码、CSRF token 校验等基础内容。这些话题说多了容易变成“安全教育课”但我要强调的实际经验是前端安全问题的根源通常不在框架而在业务代码里那些“图方便”的写法。比如直接把后端返回的 HTML 塞进页面或者为了让联调方便把 token 写死在 localStorage。把这些习惯改掉你的安全水平就已经超过大多数团队了。5. 实操把 MCP 和 Skill 接进你的前端工作流5.1 环境准备与全局 MCP 配置实操起点很简单确保本机有 Node.js建议 18 以上然后准备一个支持 MCP 的客户端比较常见的是 Claude Desktop、VS Code 里的 Copilot 相关插件以及 Codex 这类 AI 编程工具。不同客户端的配置入口略有差异但核心都是维护一份 mcpServers 配置。下面是一份 JSON 示例包含文件系统、Playwright 和 SQLite 三个 MCP 服务{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, ./frontend-project] }, playwright: { command: npx, args: [-y, playwright/mcplatest] }, sqlite: { command: npx, args: [-y, modelcontextprotocol/server-sqlite, ./data/dev.db] } } }配置好之后建议先做一个连通性测试随便让 AI 列一下当前项目目录结构或者让它打开一个测试页面截图。能跑通就说明环境没问题了。要注意的是很多 npx 首次执行会下载依赖速度较慢不是配置出错稍等即可。如果你所在团队网络环境有特殊限制可能需要提前把对应包下载好这个在实践里经常遇到。5.2 用 Playwright MCP 做一次真实页面调试环境通了之后实际跑一次调试流程你就明白 MCP 的神奇之处。假设你正被一个 bug 折磨某个表单提交后页面白屏控制台报了个 React 渲染错误但你在不同浏览器里表现不一样。我通常这样操作先让 AI 用 Playwright MCP 打开项目的本地页面填入测试数据、点击提交按钮然后读取控制台错误和页面截图。整个过程我只需要描述“打开 http://localhost:3000/form用 testexample.com 登录提交空表单看看会发生什么”。执行过程中AI 会一步步调用浏览器工具你可以在对话里看到它做了什么操作出错时也可以随时打断纠正。这个“可观察性”很重要它让你知道 AI 按你的意图走到了哪一步而不是黑箱里默默干事。拿到错误信息之后AI 再结合你项目里的代码文件就可以定位到具体的组件或函数给你修复建议。整个过程比人工手动复现省下了大量重复点击和排查时间。这里有一条实操心得在让 AI 做浏览器操作之前最好先在提示词里明确“请每一步都在本地开发服务器上执行不要使用生产环境”。因为 AI 一旦连上生产环境并执行表单操作是有可能写入脏数据的。我习惯在 Playwright MCP 的访问范围上做限制只允许访问 localhost 和一些内部测试域名。5.3 部署环节纯前端项目免费上线前端项目上线这件事也完全可以和 AI 工作流串起来。如果你只是做一个纯前端项目没必要上来就买服务器可以先用 CDN 或静态托管平台免费部署。现在主流的方案有 Cloudflare Pages、Vercel、Netlify、GitHub Pages 等。它们的共同特点是支持绑定 Git 仓库每次推代码就自动构建并部署自带 HTTPS 和全球 CDN对个人项目和原型验证来说完全够用。我常用的流程是把项目推到 GitHub 仓库然后在 Cloudflare Pages 或 Vercel 上导入仓库设置好构建命令比如 pnpm build和输出目录比如 dist剩下的事情平台自动完成。如果配合 MCP你可以让 AI 直接读取构建日志、检查部署状态甚至帮你修改重定向规则。走到这一步你会发现从写代码到上线的整条链路AI 都能参与进来你只需要做最终决策。部署时最容易踩的坑有两个一是资源路径用了绝对路径部署到子目录后就白屏二是没有配置 SPA 重定向刷新页面变成 404。前者建议在项目里统一用相对路径或环境变量控制 base 路径后者则需要在托管平台设置 rewrite 规则把非静态文件请求都指向 index.html。把这些经验写进部署 Skill 里AI 以后生成的工程就不会再犯这种低级错误了。6. 前端面试与职业发展AI 工作流带来的新考点6.1 现在面试官开始问什么了前端面试题这几年确实在变化除了传统的八股文和算法越来越多面试官开始关心“你怎么利用 AI 提效”。他们不再问“你知道 MCP 是什么吗”这种背诵题而是更愿意听你说“我在项目里配置了 Playwright MCP用它自动复现了一个低概率 bug”“我写过一个 Skill把团队组件规范沉淀进去AI 生成的代码直接能过 lint”。这种真实实践最能体现一个工程师的工具敏感度和落地能力。如果你的简历里写过“熟悉 AI 辅助开发”那就更要准备好回答这类细节。面试官可能会追问MCP 和传统插件有什么区别你的 Skill 是什么结构怎么保证 AI 改代码后不影响其他功能这些问题没有标准答案但有过真实实践的人很容易讲出让人信服的案例。面试本身就是验证“你是不是真的用过”而不只是知道这些名词。有意思的是有些公司开始把“编写 Skill 能力”作为加分项甚至作为培养目标。因为 Skill 代表的是团队经验的数字化沉淀能力谁能把隐性知识转化为 AI 可以复用的资产谁就在未来的开发模式里占据先手。这个趋势我觉得会在接下来一两年越来越明显建议在职的朋友早点布局。6.2 在职前端怎么系统化学习学习新东西最忌“收藏夹吃灰”。我自己的路径是分三步走的。第一步是“抄作业”照着官方文档搭一个最小的 Playwright MCP 环境体验 AI 控制浏览器改页面样式第二步是“改作业”把网上的 Skill 案例找几个下来结合自己项目改一版这个过程中你会理解 Skill 的边界和描述怎么写更容易触发第三步才是“写作业”从自己团队最痛的点出发把规范或流程写成 Skill实际用起来再不断迭代。还有一个办法是建立一个“个人 Skill 仓库”不仅放技能包也放你收集的 MCP 清单、热词和灵感记录。比如前面提到的 GIS 空间分析 Skill、甚至某些新语言如仓颉相关的 Skill 生态都可以在仓库里留个索引。平时看着没什么用真到某个项目需要时你会发现自己的“军火库”已经比大多数同行丰富。持续积累永远是普通开发者拉开差距的最好方式。7. 常见问题与避坑指南7.1 MCP 连不上、鉴权失败怎么排查我遇到的 MCP 问题有一半以上是“连不上”。排查的第一步是看客户端日志大多数 MCP 客户端都有日志面板或命令行输出能直接告诉你 command 是否启动成功、网络请求是否超时。第二步是确认 npx 包是否能独立运行比如单独在终端执行 npx playwright/mcplatest看它是否正常报出监听地址。第三步是检查 JSON 配置的路径是否正确尤其注意相对路径是相对于客户端工作目录的不是相对于你的项目目录。鉴权失败也很常见特别是接远程 MCP 服务或需要 token 的服务。我的经验是能本地跑的就不要用远程鉴权必须用远程的则把 token 放到环境变量里而不要明文写在配置文件中。另外要留个心眼MCP 服务本身也可能包含恶意的代码安装第三方 MCP 前尽量查看其源代码和下载量宁可少用一个不要乱用。7.2 Skill 不生效多半是描述写得太抽象不少人写了 Skill 之后发现 AI 根本不调用问题八成出在 description 上。AI 选择技能很像人与搜索引擎交互你的 description 就是技能的“关键词页面”。如果你写的是“前端技术总结”那 AI 确实不知道什么时候该用如果你写的是“当用户要求把毫秒时间戳格式化为 YYYY-MM-DD 时使用”它就能精准命中。另一个不生效的原因是 frontmatter 格式错误。YAML 里冒号后面必须要有空格多行描述要正确处理缩进这些细节出错会导致整个文件无法解析。遇到 Skill 没生效先去客户端技能管理面板确认它是否被正常加载。如果加载了但不触发就检查 description 与被调用场景的匹配度然后迭代改写。这个迭代过程其实挺像产品运营要观察、要分析、要改版。7.3 隐私和成本不是所有代码都要喂给 AI最后一个避坑点也是最重要的在享受 MCP 和 Skill 带来的效率提升时要时刻守住数据安全的边界。不要把包含密钥的文件、生产环境数据库连接串、未脱敏的用户数据授权给 AI 工具。我在团队里的原则是本地开发环境的数据可以授权预发环境要看情况生产环境一律禁止。这是一个硬性规定哪怕牺牲一些便利性也值得。成本方面MCP 和 Skill 本身大多是开源免费的但 AI 的调用按 token 计费尤其你让 AI 通过 MCP 读取大量文件、频繁调用浏览器操作时上下文消耗会很快。控制成本的办法是限缩 MCP 可访问的目录范围尽量让 AI 只读取相关文件而不是全仓库扫描另外一个技巧是在大任务开始前先明确“不要读取 node_modules、dist、图片文件”这类目录又大又没用。我个人在实际操作中最大的体会是MCP 和 Skill 不是摆设它们是把“AI 很聪明”变成“AI 很好用”的最后一步。真正拉开差距的永远是你写的 Skill 质量和你对工作流的理解。最后分享一个小技巧写 Skill 时一定要在里面放一两个具体的 example比如“输入是 xx输出是 yy”AI 有了样例参照执行起来会远比只有抽象规则时稳定。希望这份分享对你有用也期待看到你把自己团队的规范写成 Skill成为那个“定义工具的人”。
