企业官网建设流程全解析

最近我把大部分前端工具链都换成了围绕 Skill 和 MCP 搭建的工作流——一开始是有点赌博心态，但跑通后确实回不去了。本地起着一个 React 项目，AI 助手能直接打开浏览器跑一遍主流程，把控制台报错抓回来分析；给它一张设计稿，它会按团队组件库的规范生成代码并提交 MR。作为在职前端，我过去对 AI 辅助开发的预期还停留在自动补全和代码生成，直到把 Skill 和 MCP 接到真实开发链路里，才意识到这两样东西更像是给 AI 装上了“手”和“操作手册”，而不是又一个新版代码提示框。

这篇文章把我这段时间的落地实践、踩过的坑、以及为什么我觉得前端才是最适合吃这一波工具红利的领域，系统地整理一遍。内容不涉及 PPT 式概念，都是能在你现有项目里立刻试的东西。

1. 为什么到了2025年，前端开发突然离不开MCP了

1.1 MCP到底是什么：把它想象成AI世界的USB-C

MCP 全称是 Model Context Protocol，也就是模型上下文协议。它不是某个框架，也不是某个库，而是一套开放标准，用来解决“AI 应用如何安全地连接外部工具和数据源”的问题。2024 年底 Anthropic 把它开源之后，微软、谷歌等厂商快速跟进，才在 2025 年变成了前端工具链里绕不开的词汇。

要理解它，最好的类比就是 USB-C。你不需要为每个设备准备不同的充电线，一根线到处插。MCP 做的事情类似：它把 AI 和工具之间的通信方式标准化了。以前每个 AI 应用要对接浏览器自动化，得专门写一套插件；要读写文件，又得再写一套。现在只要工具方提供一个 MCP Server，AI 客户端（比如 Claude Desktop、Cline、Cherry Studio 等）能像插 USB 一样直接连上，通过标准化的接口调用能力。

对前端开发来说，MCP 的价值不是概念上的优雅，而是切切实实缩短了“AI 能做什么”的距离。以前我们说让 AI 帮忙调试页面，它只能读代码猜；现在接上 Playwright MCP，AI 能自己控制浏览器去点击、输入、截图、读控制台日志，把“猜测”变成“观察”。这和传统脚本自动化最大的区别是，工作流由自然语言驱动，AI 会根据观察结果动态调整下一步。

1.2 前端开发者能从中拿走什么

前端可能是最能从 MCP 中获益的职业之一，因为我们工作里充满了“可被标准化”的动作：启动 dev server、打开浏览器、调试 API 响应、检查样式、跑测试、打包部署。这些动作以前要么人工做，要么靠 CI 脚本做，但脚本不够灵活——换一个页面结构就要改选择器；而 MCP 给了 AI 一个实时操作这些工具的能力。

我整理了一下平时用得最多的 MCP Server 场景：

• Playwright/MCP：浏览器自动化，适合断言的回归测试、跨页面状态检查、移动端模拟；
• Git/MCP：让 AI 直接读仓库状态、创建分支、生成 commit message，减少上下文切换；
• 文件系统/MCP：让 AI 读取项目配置、组件目录结构、批量重命名或重构；
• 数据库/MCP：前端偶尔要直接验证数据结构，连接本地数据库做查询，不用开 Navicat；
• 自有业务 MCP：把团队接口文档和组件库包成 MCP 资源，AI 生成的代码天然符合内部规范。

这些例子说明一个趋势：前端工程师不再只能把代码喂给 AI，而是可以把整个研发环境“挂到”AI 旁边。这带来的直接收益是，日常那些重复、机械、需要频繁切换工具的细节（查样式、翻接口文档、对着截图改像素），AI 能直接完成大半。

1.3 一个决定：从观望到真正接入MCP

我最早也犹豫过，觉得 MCP 又是一阵风。但当我真切遇到几个痛点后改变了想法：接手一个 6 年历史的老项目，样式散落五六个文件，想找一个组件的来源只能靠全局搜索；需求排期又紧，AI 补全代码时总有 1% 的概率用错接口，而它自己完全不知道。把 MCP 接进工作流后，AI 能直接读取整个项目的样式文件和接口定义，在生成代码时对照现实，而不是凭空输出。这个体验的差异是本质性的。

对于刚开始接触 MCP 的同事，我的建议是不要一上来就搭复杂架构，先装一个 Playwright MCP，让它开着浏览器陪着你改页面。你会发现，很多以前要写脚本才能确认的东西，现在用自然语言就能完成——这才是 MCP 入门最核心的体感。

2. 从Playwright MCP说起：让AI当你的“前端测试助理”

2.1 安装与启动：把MCP服务器接进你的AI客户端

Playwright MCP 是微软官方维护的 MCP Server，核心是封装了 Playwright 库的浏览器控制能力。它让 AI 客户端可以通过一组标准工具发起浏览器操作，比如browser_navigate（导航到 URL）、browser_click（点击元素）、browser_snapshot（读取当前无障碍树/快照）、browser_console（读取控制台消息）。

安装步骤不复杂，以 CLI 方式启动为例。我习惯把它配到 Claude Code 或 Cline 里，因为这两类工具支持 MCP server 的 stdio 模式：

# 全局安装或使用 npx 均可 npm install -g @playwright/mcp # 本地启动（默认 8931 端口，也可以走 stdio） mcp-server-playwright

如果你用的是 Claude Code，直接在配置里加一句：

"mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp", "--headless"] } }

这里有个容易踩的坑：--headless参数。无头模式下运行速度更快，适合 CI 环境；但本地调试时我强烈建议不要加，因为你想亲眼看到 AI 的操作过程，看它点错哪里、页面报什么错。用有头模式虽然慢一点，但排查问题的效率翻倍。

2.2 自然语言驱动浏览器：一条指令完成状态检查

接入之后，你不再需要写冗长的 Playwright 脚本。对 AI 说：“打开 localhost:3000，完整跑一遍注册流程，把控制台里的报错列出来”，AI 会自己拆解步骤、调用 MCP 工具、滚动页面、填写表单，然后返回结果。

我实际遇到的一个例子是：组件库升级后，Modal 组件在某些宽度下出现错位。传统做法是写测试脚本或手动调整窗口大小试半天。有了 Playwright MCP 后，我让 AI 分别用 375px、768px、1440px 三种视口打开所有包含 Modal 的页面，截图对比，然后把变体差异整理成表格。整个过程不是“给我一段测试代码”，而是 AI 直接驱动浏览器做了真实检验，最后把报错信息和截图贴在对话里。

更关键的是，这个过程允许 AI 中途自我修正。以前写自动化测试，断言一失败脚本就停了；MCP 模式下，AI 看到页面不符合预期，会主动换一种操作路径再试，或者把页面快照拉回来分析样式问题。这种“带眼睛工作”的方式，比传统脚本更接近人类调试的思维。

2.3 踩过的坑：选择器失效、等待超时与并发复用

使用 Playwright MCP 也有不少实际工程细节，简单分享一下：

1. 选择器稳定性比速度重要。AI 驱动浏览器时，优先选择稳定的>--- name: react-form-generator description: 根据 JSON 配置生成 React 表单组件，包含 antd 控件、校验和提交逻辑 --- ## 触发条件 用户要求创建表单、生成 form、或基于 schema 生成录入页 ## 输入参数 - fields: 字段列表，包含 name, label, type, required, rules - layout: 布局方式（horizontal, vertical, inline） - submitApi: 提交接口地址 ## 执行步骤 1. 根据 type 映射到 antd 对应组件（Input, Select, DatePicker...） 2. 生成受控组件，value 和 onChange 绑定到 Form 3. 使用 rules 数组定义校验规则，required 字段必填提示 4. submitApi 为空时不渲染提交按钮，方便嵌入弹窗 5. 代码风格必须遵循团队 ESLint 配置和文件头注释规范 ## 参考示例 给出一个 2 字段的登录表单，并展示完整代码 ## 约束 - 禁止使用 any 类型 - 禁止在非必要场景引入新的第三方库 - 冗余注释不要生成，保持代码整洁

   把这个 skill 文件放进团队共享目录（或按工具要求放在指定 skills 文件夹），AI 在响应表单相关需求时会自动加载这个技能，输出结果显著更可控。

   为什么这么写有效？关键在于边界和规范被显式化。以前 AI 生成表单时哪里都能凑合，现在输入、步骤、约束全部写死，生成结果从“能跑”变成了“符合团队标准”。对在职前端来说，把经验沉淀成 Skill 其实就是把团队 code review 的共识变成了 AI 的默认行为。

   3.3 让Skill和MCP配合工作，而不是二选一

   有些开发者容易搞混：学了 MCP 就不学 Skill，或者反过来。但我在实践中发现，它们在前端自动化里是配合使用的。举个例子：

   • 团队有一个 MCP Server，连接了设计稿平台（Figma）和代码仓库；
   • 有一个“设计稿转页面” Skill，里面规定了解析设计稿后应该先产出哪些文件、用什么图片压缩策略、如何处理栅格间距；
   • AI 先通过 MCP 读取设计稿的图层结构和样式常量，再调用 Skill 里的步骤生成页面代码，最后通过 Git MCP 创建分支并提交。

   没有 MCP，Skill 缺少执行所需的上下文数据；没有 Skill，MCP 只是一堆零散的工具调用，缺乏业务步骤的组织。Skill 负责“按什么顺序做什么”，MCP 负责“具体连接哪个系统取什么数据”。两者结合，才是完整的 AI 辅助开发体验。

   4. 前端安全，专业团队的“最后一层牛皮”：防爬虫与源码防读实践

   4.1 为什么说前端安全是悖论，但还必须做

   几乎所有前端面试和技术讨论里都会遇到一个问题：前端代码是公开的，怎么防止被爬虫爬数据、怎么看源码？我的回答一直是——前端安全不是“不能被看到”，而是“看到和复制的成本足够高，高到对方放弃”。

   前端代码跑在用户浏览器里，拿不到 100% 防护，但只要我们把攻击成本抬升，大多数爬虫和想要偷代码的人就会知难而退。这不是悖论之下的消极妥协，而是这个岗位必须理解的安全边界。真正敏感的业务校验、权限控制永远放在后端；前端安全只负责保护“体验层”和“未被后端兜底的边界”，比如防止页面被轻易 iframe 嵌入、防止站内链接被批量采集、防止按钮被脚本自动提交等。

   4.2 可落地的防护组合：混淆、反调试、动态水印

   我实际用在前端项目里的安全手段，按投入产出比排序如下：

   1. JavaScript 混淆与压缩。这是最基础的一层。Webpack 构建时开mode: "production"，TerserPlugin 会自动做变量名压缩。更进一步的混淆可以用javascript-obfuscator，把字符串、函数名也打乱。这不会让代码读不了，但能让“扫一眼代码就复制”的成本提高一个数量级。

   2. 反调试技巧。针对那些打开 DevTools 的爬虫，可以检测到开发者工具打开时触发无限 debugger 断点或清空控制台。这种做法一直被滥用的是“反爬”，但对于验证码页面、登录页等敏感界面，它是一种常见的用户体验保护。注意别做得太激进，否则会误伤真实调试需求的用户。合理的方式是仅对核心交易流程启用，或延迟触发。

   3. 禁止页面被内嵌。通过设置Content-Security-Policy: frame-ancestors 'none'或旧版X-Frame-Options: DENY，防止自己的页面被第三方 iframe 嵌入，避免点击劫持和山寨镜像站。这一项是我认为性价比最高的安全头配置，而且配置成本几乎为零。

   4. 动态水印。如果业务对数据泄露敏感，比如后端管理后台或报表系统，可以给页面增加带用户名+时间戳的动态水印，既能威慑截图泄露，也方便追溯暴露源。我见过很多团队把水印做成了 PNG 背景图，但更好的是用 Canvas 动态绘制，每次会话生成不同位置和大小的水印，批量截图脚本很难自动清除。

   5. 接口层防御。爬虫往往不只抓静态页面，还会抓你的 API。所以前端层面能在发送请求时带签名或短期 token，而服务端做频率限制和校验来源 Header。前端的作用是提高伪造请求的难度，最终防线还是后端。

   4.3 把安全检查做成Skill：自动扫描隐藏风险点

   安全配置多、容易遗漏，这时候就轮到 Skill 出场了。我给团队写了一个“前端安全体检 Skill”，把上述检查项固化成清单，AI 接上 MCP 后可以自己扫项目文件并输出报告。

   Skill 的核心指令包括：

   • 检查index.html是否包含 CSP 标签，frame-ancestors是否配置；
   • 检查构建配置中是否开启压缩和混淆；
   • 检查路由守卫和按钮权限控制是否覆盖所有页面；
   • 检查前端存储（localStorage）中是否明文保存 token；
   • 检查外部链接是否统一经过安全跳转，避免成为window.opener钓鱼入口。

   有了这个 Skill，新项目提测前只要让 AI 自动跑一遍，就能快速找到大部分低级安全疏漏。它不会替代安全工程师，但能把常见问题的回归成本压到最低。如果你自己不想从零写，也可以去 AI 工具平台的技能市场里找现成的安全类 Skill，切记要把团队自己的规则合并进去再使用。

   5. 大文件上传与流式输出：前端Worker与MCP的实战接力

   5.1 Worker分片上传：不只是“快”，而是可控

   前端上传大文件是一个老生常谈的难题：文件超过几百 MB 时，网络中断重来、内存占用飙升、服务器超时。我之前的做法是直接在主线程读取文件并fetch，后来发现一旦文件到了 2G 以上，页面直接卡死。现在采用 Web Worker + 分片上传的方式，把处理逻辑从主线程剥离出去。

   核心思路非常简单：用File.slice()把文件切成固定大小（比如每个分片 5MB），在 Worker 里循环读取分片，计算哈希（用于秒传和断点续传检测），然后逐个上传。每个分片上传成功后，记录已完成的偏移量，断网或失败时从该偏移量继续，而不是整个文件重来。

   我用的一个精简版本长这样（主线程部分）：

   // 主线程 const worker = new Worker('/upload-worker.js'); // 给Worker传文件引用和切片大小 worker.postMessage({ file: file, chunkSize: 5 * 1024 * 1024, uploadUrl: '/api/upload/chunk' }); worker.onmessage = (e) => { if (e.data.type === 'progress') { updateProgressBar(e.data.percent); } else if (e.data.type === 'done') { notifyUploadFinished(e.data.fileUrl); } else if (e.data.type === 'error') { // 记录失败分片，稍后重试 } };

   Worker 内部实际做分片和上传，但因为代码运行在独立线程，页面滚动和交互完全不受影响。实测下来，上传一个 3GB 的视频文件，页面始终稳定在 60fps，内存占用也比主线程方案低不少。

   另外提醒一句：Worker 里读文件用的是File对象的arrayBuffer()或stream()方法，注意在 Chrome 的跨域环境下，File是从主线程 transfer 过来的，不需要复制，性能很好。断点续传还需要配合后端保存每片的状态，以及一个“合并文件”的接口，这部分属于服务端工作，前端不要省。

   5.2 MCP流式输出到文件：长任务不再让HTTP超时

   热搜词里出现的“使用 MCP 工具流式输出内容到文件”，其实描述的是 MCP 能力里一种长任务处理方式。MCP 的某些工具调用可能耗时很长（比如让 AI 生成一份大型项目分析报告、批量重构代码），这时候不能像普通 HTTP 请求那样等全部结果返回，更不能让代理超时。

   在 MCP 协议中，流式传输（Streamable HTTP 或之前在 stdio 下的消息流）允许服务器按事件逐步返回输出。对前端工程来说，最常用的场景是：AI 通过 MCP 工具将长文本内容直接写入本地或远端文件，而不是把几千行代码一次性塞进对话窗口。

   举个例子，我让 AI 根据整个项目的目录结构生成一份完整的组件迁移文档。传统方式是 AI 生成 Markdown 后，我手动复制到文件里，中途还可能因为对话长度限制导致生成中断。现在给 AI 挂一个“文件写入 MCP”，它会自动按章节把内容分块写进本地文档，每写完一块就反馈进度。这样即使生成过程很长，也不会出现上下文溢出或 HTTP 超时，最终产物直接落盘，可以立刻 review 和提交。

   这种做法背后的原理并不复杂：协议层面支持事件流，工具层面支持增量写文件，AI 层面则学会把大输出拆解成多个批次。前端开发在对接 MCP Server 时，如果自己写服务，记得优先支持text/event-stream格式的事件响应，并给每个事件附加finished标志，否则客户端很难判断长任务何时真正结束。

   5.3 这两项技术放在同一个项目里的样子

   你可能会问：大文件上传和 MCP 流式输出，一个是浏览器性能优化，一个是 AI 工具链协议，怎么搭到一块？我最近做一个内部素材库项目，就把它们组合起来了：

   页面需要让运营上传几十个大型视频素材，同时生成对应的字幕摘要、标签、封面建议。传统的实现是一个一个传、上传完再等 AI 处理，体验极度割裂。我的方案是：

   1. 用 Worker 分片上传素材文件，主线程保持流畅；
   2. 上传完成触发 MCP 工具调用远程的 AI 服务，流式生成字幕摘要和标签；
   3. MCP 工具把 AI 生成的结果边生成边写入文件系统，同时通过事件流推送给前端进度条；
   4. 全部完成后，页面展示摘要文件路径和可直接编辑的标签列表。

   整个过程就像一条装配线：Worker 负责“搬大件”，MCP 负责“边走边写”，前端只需要展示状态。这套组合让我的真实体感是：以前需要来回切工具、轮询接口的活，现在变成了一个可以被 AI 编排的完整工作流。

   6. 从Codex到组件库：我的前端AI工作流是怎么串起来的

   6.1 让AI“懂”你的组件规范：把组件库变成MCP资源

   Codex、Copilot、Claude 都是当前主流的 AI 编码工具，但无论用哪一家，前端开发者都绕不开同一个问题：AI 不了解你团队的组件库。它可能生成一个看着像 Antd 但实际用了另一种语义的按钮，或者引用了根本不存在的 prop 名。

   解决办法是：把团队组件库的 API 文档、使用示例和样式规范变成 MCP 资源，让 AI 在写代码前先读取“组件字典”。我之前在团队做了一个轻量 MCP Server，它只做一件事：读取内部组件库的 TypeScript 定义文件，并把每个组件的 props、事件、slot 转成结构化描述返回给 AI。

   实践效果很明显。以前让 AI 写一个带搜索的表格页，它可能会自己拼一个自造的搜索逻辑，复用性极差；现在它会先去 MCP 里查ProTable的request参数规范，然后用项目定义的query方法提交请求，生成代码的样式和交互与现有页面保持高度一致。说白了，MCP 在这里放大的是“上下文”的价值，让 AI 生成的内容在团队标准之上生长，而不是随机变异。

   6.2 部署与团队协作：纯前端项目也能被AI把玩

   话题再往后走，就不得不提“纯前端线上免费部署”这样的热搜词。我理解很多前端团队都在寻找快速出 demo、低门槛验证 AI 生成代码的方式。当前主流做法是把纯前端项目托管到静态平台（比如 GitHub Pages、Cloudflare Pages、Vercel），配置好自动构建后，AI 每次提交代码都能自动部署到一个临时预览地址。

   这么做和 Skill/MCP 有什么关系？关系在于：当你把部署平台也做成 MCP 工具时，AI 在完成代码变更后可以直接触发一次预览部署，并在对话里返回预览 URL。整个链路变成“AI 改代码 → AI 调用部署 MCP → 你打开预览链接确认效果”。这等于把前端的“最后一公里”也交给了可编排的自动化。

   对于团队协作，我建议把：

   • 组件库目录
   • 接口文档 OpenAPI 地址
   • 设计稿 token（颜色、间距）
   • 构建脚本
   • 部署平台

   这五类资产全部注册在 MCP Server 里，再配一两个偏向团队场景的 Skill（比如“新页面开发流程”Skill，定义读设计稿→生成组件→写测试→跑构建→预览的完整顺序）。新同学加入后，给 AI 一条需求描述，整个流程就串起来了；老同学也不需要反复解释那些“隐含在团队脑中的规范”。

   6.3 我的一些体会：拥抱Skill/MCP后，前端工程师在做什么

   最后说说我个人的感受。这一套东西刚上手时，确实有点复杂，要先理解 MCP 协议、配置服务器、写 Skill 文件、管理权限。但两周内，我个人的开发节奏产生了明显变化：

   • 大量“看一眼再决定”的工作交给 AI 完成（检查样式、比对组件、扫 console）；
   • 写代码前，AI 会先读取项目事实（通过 MCP），而不是闭着眼睛生成；
   • 团队的编码规范从“评审时被骂”变成“生成时被约束”，因为 Skill 把规范前置了。

   因此，前端工程师的核心竞争力，正在从“记住 API 细节”转向“定义 AI 的工作规则”。谁能把团队流程抽象成 Skill、把工具接进 MCP，谁就能让 AI 替自己完成更多的重复劳动。这并不意味着前端失业，而是意味着每个人的产出范围在扩大。我常跟组里的同学讲：你要做那个给 AI 写说明书的人，而不是那个被 AI 替代的人。

   如果你也想试试，建议从三个最小动作开始：装一个 Playwright MCP、把你最常用的组件规范写成一份 Skill、给项目加一个文件写入 MCP。跑通这三个能力，你已经比我三个月前超前了。剩下的，就是在真实项目的每一次踩坑中，把 Skill 和 MCP 打磨成自己的东西。