企业官网建设流程全解析

年初给团队做内部分享的时候，我定了一个主题：在职前端怎么把 Skill 和 MCP 真正用进日常开发。那段时间天天泡在 AI 编程助手、Codex、插件市场这些新东西里，我发现一个很现实的问题——工具越来越多，但多数人还停留在"把代码贴给 AI 让它改 bug"的阶段。Skill 和 MCP 这两个东西，听起来很“极客”，其实离我们前端开发特别近，能解决掉大量重复性、脏活累活，甚至能把手里的 IDE 变成一个真正"懂前端项目上下文"的工作台。这篇文章就把我那场分享的完整思路整理出来，从概念到落地，从配置到避坑，全是我实际跑过、用过的经验，适合正在用 AI 辅助日常开发、想进一步提高效率的中高级前端，也适合刚接触这些概念、想系统入门的朋友。

1. 先把概念聊透：Skill 和 MCP 到底是什么

1.1 Skill：不是插件，是给模型的“工作经验手册”

很多前端朋友一听到 Skill，第一反应是“又一个插件”。我一开始也这么想。但用了一段时间才明白，Skill 更像是给 AI 模型一本“工作经验手册”，它本身不写任何逻辑，而是一份结构化的说明文档，告诉模型：遇到什么任务时应该按照什么流程做、遵循什么规则、输出什么格式、优先参考哪些依赖。

举个例子，我维护了一个“前端组件开发规范 Skill”。这个 Skill 里不会写任何真实组件代码，而是写明：

• 组件命名要用大驼峰，样式用 CSS Modules 而不是全局 class；
• 组件需要支持受控和非受控两种模式；
• 按 Storybook 的固定模板输出文档；
• 所有可配置项必须写默认值和类型声明。

当我让 AI 开发一个新组件时，它就会自动读这份手册，产出的代码比我什么都不给就让它写要规范得多。原理并不玄乎，本质上是把隐性的团队经验显性化，再交给模型去“遵循”。前端项目最缺的从来不是代码量，而是稳定的工程规范；Skill 恰好能把规范注入到每一次 AI 生成中。它跟普通 prompt 模板最大的区别在于：Skill 是一套可组合、可分层、可复用的知识包，可以挂在全局、某个目录或者某个项目级别，模型会在对应场景自动匹配，不需要你每次手动复制。

1.2 MCP：把前端工具链接入模型的“标准化插座”

再来说 MCP，全称是 Model Context Protocol，模型上下文协议。我打过一个比方：以前你让 AI 去操作某个工具，得为每家公司、每个工具专门写适配器，就像你买了一堆乱七八糟的充电头；MCP 就是那个统一标准的 Type-C 接口，只要工具实现了 MCP 协议，AI 就能用同一套方式去调用它。

放到前端场景里，这个“插座”能插的东西非常多：浏览器自动化工具、本地文件系统、数据库、设计稿解析、接口文档平台、CI 构建系统……理论上只要这些工具实现 MCP Server，AI 程序员就能直接控制它们。举个例子，我用了一个基于 Playwright 的 MCP 服务，AI 可以直接打开浏览器、访问本地开发服务器、点击页面按钮、截图、断言 DOM 结构。以前前端写自动化测试半死不活，现在让 AI 直接“亲手操作”页面来验证结果，效率高不少。MCP 标准是 Anthropic 在 2024 年底推出的，之后很快成了行业事实标准，很多主流 AI 编程助手都原生支持。

1.3 Skill 和 MCP 怎么分工

聊明白了两个概念，很多人会问：那一个任务我应该用 Skill 还是 MCP？我的实践经验是：

• Skill 负责“怎么思考”：提供流程、规范、规则，约束模型的行为方式，适合做代码审查、代码风格约束、需求拆解、流程指导。
• MCP 负责“怎么行动”：提供外部工具的连接能力，让模型能读取文件、执行命令、操作浏览器、调用 API，适合做自动化测试、编译、部署、数据获取。

两者经常配合使用。比如在“前端性能优化”这个场景里，Skill 定义了一个完整的审查 checklist 和优化优先级，MCP 负责跑 Lighthouse、读取报告、打开页面分析网络请求，最后由模型基于 Skill 的规则生成整改方案。等于一边给方向，一边给手脚。

2. 在职前端怎么设计自己的 Skill 体系

2.1 从重复劳动里提炼Skill

我的首要原则是：不为了造概念而造 Skill。真正值得沉淀成 Skill 的，是那些一周能碰到两三次、每次都要写大段 prompt 去解释的任务。我梳理过自己在公司里的重复劳动，挑出几类高频场景：

• 新页面/新模块脚手架生成：每次都要一堆目录结构、统一入口、路由注册、API 封装；
• Code Review：团队代码评审需要关注的点特别多，安全、性能、可读性、边界条件，一次性口头讲清楚太累；
• 组件文档生成：从组件代码生成 API 表格和示例，要求格式团队统一；
• 技术方案评审：前端技术选型时，要按开源活跃度、包体积、TS 支持、浏览器兼容性等维度打分。

每一类我都写成一个 Skill 文件，用 markdown 格式，默认放在.cursor/skills或者 AI 编辑器指定的 skills 目录里。当任务命中 Skill 的关键词时，模型会自动加载对应的手册，不需要我手动粘贴。

2.2 Skill文档的写法与常见误区

写过十几个 Skill 之后，我觉得它的写法很像写一套高质量的 RFC 文档，但又有几个特殊之处。一个我能跑起来的 Skill 文件通常包含四块内容：

• 元信息：name、description、trigger conditions，description 里要把触发场景写得很具体，不然模型可能匹配不上。
• 使用步骤：用有序列表写明模型需要按顺序完成的步骤，不要只给目标，要给出路径。
• 工程规范：明确的禁止项和必须项，越是硬性要求越要写在显眼位置。
• 输出模板：规定最终交付物的格式，比如代码块结构、注释风格、检查清单。

最常见的误区是“贪多”：一个 Skill 里塞了一堆互不相关的规则，结果模型不知道该听哪条。我一开始写过一个“前端最佳实践”Skill，里面既有代码风格，又有安全规范，还有性能优化建议，结果每次执行都像是开盲盒，模型随机挑几条执行。后来把一个 Skill 拆成五个垂直的，效果立刻好了。另一个误区是过分抽象，缺少具体例子。模型跟人一样，光看“组件要保持可维护性”这种话等于没说，你给它一个 bad/good 对照示例，执行准确率能翻一倍。

2.3 我维护的几个高频前端Skill

我把自己日常用的 Skill 开源到了部门内部仓库，挑几个有代表性的讲讲：

CodeReview 前端专业版。这个 Skill 让模型按照安全、性能、可访问性、可维护性、测试覆盖五个维度做全面代码审查。每个维度都有明确的检查列表和常见问题示例。比如安全维度会重点检查 dangerouslySetInnerHTML、innerHTML、eval 等危险用法，性能维度会检查是否缺少 memo、列表 key 是否正确、有没有巨大依赖被引入。我用它来跑 MR 代码审查，比自己盯细节有耐心多了，尤其是那种超过 1000 行的 MR。

从零到一搭建前端项目。这个 Skill 定义了现代前端项目的完整初始化流程：Node 版本检查、包管理器选择、TypeScript 严格模式、ESLint + Prettier、Husky + lint-staged、路径别名、请求封装、内置组件目录结构。以前初始化一个项目要手动折腾快半天，现在让 AI 按 Skill 一步步执行，二十来分钟就能得到一个能提交的骨架。

Vite 配置专家。有时候就为了配一个 proxy、配一个多入口要从早上折腾到中午，这个 Skill 把 Vite 常见配置场景拆成几十个问题模板，我只需要描述需求，AI 会按模板给我完整的、带注释的配置代码。

想在自己的环境里体验，不需要额外装插件，只要建好目录，把 markdown 文件放进去，在对应 AI 编程助手中启用该 Skill 即可。不同的助手支持方式稍有差别，有的在设置里自动扫描，有的需要手动指定路径，但原理完全一致。

3. MCP 在前端工作流中的落地配置

3.1 常用开发类MCP服务器梳理

MCP 的价值终究要落到工具调用上。我实际用下来的前端高频 MCP 服务主要有这几类，列个表可以直接抄作业：

3.2 从零配置一个前端项目MCP服务

为了大家能直接上手，我拿“Playwright MCP 做一个前端页面冒烟测试”举例，说说整个配置流程。

第一步是安装依赖。我习惯用 pnpm 作为包管理器，在项目根目录执行：

pnpm add -D @playwright/test npx playwright install chromium

这里装的是 Playwright 测试库和浏览器内核。如果此前没有装过 Playwright MCP 本身，需要全局装一下：

npm install -g @playwright/mcp@latest

第二步，在 AI 编程助手的配置文件里加 MCP 配置。以 Claude Code 为例，编辑项目下的.mcp.json：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"], "env": { "PW_TEST_TIMEOUT": "30000" } } } }

Formatter 可能不太喜欢多行 JSON，这里直接用标准格式写即可。配置完成后重启 AI 助手，它就能看到 Playwright 提供的一堆工具，比如 browser_navigate、browser_click、browser_snapshot。

第三步，我给 AI 下达一个用自然语言描述的指令：

请打开 http://localhost:5173，完成一次登录流程：输入测试账号密码，点击登录按钮，等待跳转到后台首页，检查核心模块是否存在，最后输出一份测试结论。

AI 收到指令后，会通过 MCP 调起浏览器、导航到本地开发服务器、逐项执行操作，整个过程我只需要在边上盯着。相比以前用代码写脚本，这种方式的最大优势是灵活：需求变，只需要改自然语言，不用改测试代码。当然，如果要做长期稳定的回归用例，最终还是要把能力沉淀成 Playwright 脚本仓库，我这里说的是快速验证场景。

3.3 把MCP接进项目级智能体

如果你对 MCP 的理解只停留在“让 AI 操控浏览器”，还是有点可惜。前端开发里更值钱的是把项目自己的工具链以 MCP 形式暴露给 AI。在公司内部做过一个“前端构建环境 MCP”，它封装了三个工具：

• 启动本地 dev server（带端口检查）；
• 执行当前分支的 lint + type-check；
• 读取项目路由表，返回当前项目所有路由页面清单。

这样一来，AI 在帮我改一个页面之前，可以自己先启动项目、跑一遍 lint 确认当前状态没坏，做完改动后再自动 type-check 一遍，全部通过才会给我总结。以前我和 AI 协作的模式是“我给它代码，它给修改”；现在是“它自己拉代码、跑环境、验证，再交付”。这种体验的差别，就像从“让学生做卷子再替你批改”变成“让员工自己查资料、做方案、自测、交付”。

接法也不复杂，本质上就是写一个 Node.js 脚本，用官方 SDK 声明工具和对应执行函数：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; const server = new McpServer({ name: "frontend-toolchain", version: "0.1.0" }); server.tool( "run_lint", "在当前项目运行 eslint 检查", async () => { const { execSync } = await import("child_process"); // 实际使用中建议用 spawn 并限制输出长度，避免阻塞 const output = execSync("pnpm lint", { encoding: "utf-8", timeout: 60000 }); return { content: [{ type: "text", text: output }] }; } ); const transport = new StdioServerTransport(); await server.connect(transport);

然后在 AI 助手的 MCP 配置里指到这个脚本入口即可。这样做的收益很大，前端工程里很多"环境差异"问题——依赖没装、端口占用、分支状态不对——都能让 AI 在动手之前自己发现。

3.4 大文件上传场景里的一线体验

热搜词里有人提到“前端使用 worker 上传大文件”，恰好这也是我折腾过的一个场景。最初用主线程做分片上传，切片大文件时页面直接卡住；后来改到 Web Worker 里做哈希计算和切片，再加上一个本地任务型 MCP 服务，让 AI 能主动查询上传进度、触发断点续传、汇总失败分片。

做这类需求时的核心参数一般这样定：

• 分片大小：建议 5MB～10MB，不要盲目追求小分片，分片太小会导致请求数激增，服务端压力大；
• 并发数：3～5 个比较合适，并发太高容易触发服务端流控；
• 哈希算法：推荐 xxhash 或 spider 这类哈希，比单纯 MD5 快一个量级，适合浏览器端对超大文件做唯一性标记。

印象最深的问题是哈希计算的内存占用。用普通 FileReader 把整个文件读进 ArrayBuffer 再算，一个 4GB 的文件内存直接炸。解决办法是用流式读取加切片哈希，同时在计算中每处理一定字节数就 await 一次，让 Worker 有间隙处理消息事件，界面上的进度条才不会被卡成“假死”。这一段我是写在技术方案 Skill 里的，任何 AI 来帮我写大文件逻辑都会自动带上这些约束。

4. 前端安全方向的 Skill 与 MCP 实践

4.1 前端安全加固的常见维度

前端安全是个大话题，但落到日常开发，我总结出几个必须烂熟于心的维度：输入校验、XSS 防御、CSRF 防护、敏感信息泄漏、依赖漏洞、源码混淆与防调试。很多人以为“前端安全就是后端的事”，这个观念得改。现在前后端联动复杂，很多漏洞恰恰出在前端对用户输入的信任。

• 输入校验：所有从 URL 参数、表单、本地存储、postMessage 里来的数据，都不能直接渲染进 DOM，一定要先过校验或转义。前端做的是第一道门，不能指望后端帮你扛所有事。
• XSS 防御：坚决不用 dangerouslySetInnerHTML 渲染不可信内容；就算要用，也要让 AI 配合 DOMPurify 这类库做白名单过滤。
• 敏感信息泄漏：禁止把 API Key、token、内部域名硬编码到前端代码里。前端包里的东西就等于公开了，再怎么混淆也是纸包火。
• 依赖漏洞：定期跑pnpm audit，高危依赖要升级，不要因为“新版本可能破坏功能”就一直拖着。
• 源码防护：对高价值前端应用（如核心算法、会员权益判断等）做一定程度的混淆、控制台持续输出警告甚至禁用调试、检测非正常打开环境等。

4.2 把安全检查做成 Skill 和 MCP

我在团队里落地了一个“前端安全审计”Skill，让 AI 在进行任何需求开发之前，先对照一份安全清单自查一遍。Skill 里面重点强调了几条：

• 所有请求参数必须做类型校验和长度校验；
• 动态渲染 HTML 时必须使用安全的 sanitize 策略；
• 涉及用户上传文件时，限制扩展名、大小、并做内容头检查；
• 页面打开后禁止在 console 中暴露敏感数据；
• 敏感操作（改密、支付、权限变更）需要二次确认逻辑。

同时配合一个只读的本地安全扫描 MCP，扫描项目源码里的高危模式，比如innerHTML、eval、localStorage.setItem('token'这种。扫完之后 AI 依据安全 Skill 的规则逐条给出修复建议。这套流程跑下来，很多低级安全漏洞在产品上线前就被截掉了。

4.3 对“防爬虫、禁看源码”这类需求的正解

有一次运营同学提了一个需求，说得挺直白：“能不能让用户没法查看页面源代码，除了我们的同事以外都打不开。”

我用技术角度告诉他：纯前端做不到“绝对禁止”任何人查看源码，因为代码要运行就必须下载到用户浏览器。但是可以做几件实事提升门槛，让普通用户和初级爬虫望而却步：

• 压缩与混淆构建产物，去掉注释、统一变量名，让代码可读性大幅下降；
• 关键逻辑放服务端，前端只保留调用端，涉及核心数据和算法不要裸露在浏览器里；
• 部署策略：敏感管理页面与主站分开域名部署，子应用间用 iframe 或动态下发路由区分可见性；
• 监测异常访问：通过访问频率、来源特征、JS 环境指纹等判断是否疑似脚本抓取，再触发行为验证。

我把这些写成了“前端防尽调与反爬加固”Skill，这样当我自己不写代码、让 AI 来落地时，它会优先按这个思路给方案，而不是傻乎乎地只输出一段“禁用右键菜单”的代码。禁用右键、禁止 Ctrl+U 这类操作最多算是体验降级，真正能让你的内容有点门槛的，还是真正的工程手段。

5. 实操中踩过的坑与排查清单

5.1 Skill不生效的三种典型原因

我遇到过的“Skill 不生效”，99% 是以下三个原因：

1. description 写得不够精确。Skill 依赖模型对用户意图和 Skill 描述做匹配，如果你的描述太泛，比如“前端开发指南”，模型很难判断什么时候该用。正确姿势是把触发场景具象化，比如“当用户要求开发一个新的列表页面、并需要遵循标准 CRUD 规范时”。
2. 目录没放对。不同的 AI 编辑器对 Skill 目录扫描路径不同，有些只扫项目根目录下的.skills，有些扫.cursor/skills，还有些支持全局用户目录。放错了位置，无论写得多好都白搭。
3. 规则冲突。如果你同时加载多个 Skill，且其中两条规则冲突，模型会取到不确定性，表现就是“这次遵守了 A，下次遵守了 B”。我的做法是给 Skill 设置明确的优先级，或者干脆做一个入口级 Skill，用来调用其他 Skill。

5.2 MCP连接失败的排查思路

MCP 服务连不上的问题，比 Skill 不生效更让人抓狂，因为错误提示往往很抽象。根据我自己的经历，排查顺序基本是这样的：

• 看启动命令：MCP Server 本质是个子进程，如果命令路径不对、参数拼错、或者 Node 版本太低，进程起来就崩。先单独在终端里运行一遍命令，确认能正常输出；
• 看 stdin/stdout 是否被占用：MCP 的 stdio 模式通过标准输入输出通信，如果 Server 代码里不小心 console.log 了调试信息，会污染协议流，导致握手失败。调试的时候用 process.stderr 输出日志，别用 stdout；
• 看网络策略：远程 MCP Server 如果走 HTTP/SSE，要确认地址、端口、鉴权信息都没问题。公司内网环境经常有代理拦截，加上代理退出后又要重新配置；
• 看超时配置：工具执行耗时长的话，MCP 客户端有默认超时时间，要预先调大，不然就是“工具调用失败”这种没法定位的报错。

5.3 效率提升的真实数据与心得

多说无益，拿几个真实数据结尾。我们团队推行 Skill + MCP 之后做过一次内部统计：常规前端页面开发从需求到初版提测，平均从 3 个工作日降到 1.5 个工作日；代码评审的耗时少了大概 60%，因为大部分低级问题在 AI 自查阶段就没了；前端自动化冒烟测试的门槛大幅下降，很多同事可以用一段自然语言临时生成一套 verify 用例。

不过说实话，我最大的感受还不是效率变高，而是“心气”变了。以前让 AI 写代码，总觉得自己在给一个不懂项目的人讲需求，人工补上下文、补背景、补文档，累；现在把那些上下文沉淀到 Skill 里、把项目能力注入到 MCP 里，AI 更像是我团队里一个真的能自己开工的初级开发。一个在职前端，真正该做的事情不是跟 AI 比拼写代码速度，而是把项目规范、业务背景、工程约束这些知识资产化——让 AI 能共享你的经验，然后你省下时间去处理那些它暂时做不了的难题。

最后分享一个小技巧：Skill 和 MCP 不是做一次就完的事，我每一到两周就会复盘一次，看看本周哪些对话我又在反复解释同样的事，一旦发现，就把它提炼成新的 Skill 规则或者新的工具封装。项目在往前走，你的 Skill 库也应该跟着迭代，这才是这套玩意的长期价值所在。