企业官网建设流程全解析

1. 为什么我要折腾网页渲染 API 接入 MCP

先说结论：我让 Claude 和 Cursor 真正"看见"网页，靠的不是截图，也不是把 HTML 源码一股脑塞进上下文，而是通过 MCP 挂载一个网页渲染 API，把渲染后的结构化内容喂给模型。这套方案跑通之后，我排查前端 bug、抓取动态页面数据、做竞品页面结构分析，效率至少翻了一倍。

如果你现在还在用"复制网页源码粘贴给 AI"这种原始方式，大概率会遇到三个问题：一是现代前端框架渲染出来的 DOM 在源码里根本看不到，二是页面体积一大上下文直接爆掉，三是模型拿到一堆压缩过的 JS 和 CSS 完全抓不住重点。MCP 加网页渲染 API 的组合，恰好把这三个坑一次性填了。

这篇文章适合三类人看：第一类是已经在用 Claude Desktop 或 Cursor，但还没接触过 MCP 的开发者；第二类是听说过 MCP 但不知道怎么和网页渲染结合的人；第三类是想把"让 AI 看网页"这件事做成稳定工作流的人。我会从原理讲到实操，把配置、参数、踩坑经验全部摊开讲，你照着抄作业就能跑起来。

需要提前说明的是，MCP 本身是一个开放协议，它解决的是"模型如何调用外部工具"这件事，而网页渲染 API 解决的是"如何把网页变成模型能理解的内容"这件事。两者结合，才构成了完整的"AI 看网页"能力。下面我按我实际搭建的顺序，一层层拆开讲。

2. MCP 与网页渲染 API 的核心原理拆解

2.1 MCP 到底解决了什么问题

MCP 全称 Model Context Protocol，你可以把它理解成"AI 模型和外部世界之间的标准插座"。在没有 MCP 之前，你想让 Claude 读一个网页，要么手动复制粘贴，要么写一堆胶水代码调用 API 再把结果塞进对话。每次换个工具、换个数据源，都要重新写一遍对接逻辑。

MCP 的价值在于它定义了一套统一的通信规范：模型这边通过 MCP 客户端发起请求，外部工具那边通过 MCP 服务端响应请求，中间用什么语言、什么传输方式，协议都给你规定好了。这就好比以前每个电器都有自己的充电口，现在统一成 Type-C，插上就能用。

具体到"看网页"这个场景，MCP 服务端负责接收"请渲染这个 URL"的指令，调用网页渲染 API 拿到结果，再把结果按协议格式返回给模型。模型不需要知道背后用的是 Playwright 还是 Puppeteer，也不需要关心页面是怎么渲染的，它只负责消费最终内容。

2.2 网页渲染 API 相比直接抓取的优势

很多人会问：我用 requests 直接抓 HTML 不就行了吗，为什么要上渲染 API？这个问题的答案取决于你要抓的页面类型。

静态页面确实用普通 HTTP 请求就够了，但现在的网页大量使用 React、Vue、Svelte 这类框架，页面初始 HTML 里只有一个空的 div 容器，真正的内容要靠 JavaScript 执行完才渲染出来。你用普通请求抓到的，就是那个空壳。

网页渲染 API 的本质是启动一个真实的无头浏览器，把页面完整加载、执行 JS、等 DOM 稳定之后，再把渲染结果返回给你。它和普通抓取的区别，就像"看菜谱"和"等菜做好端上桌"的区别。除此之外，渲染 API 通常还能返回截图、可访问性树、网络请求记录等附加信息，这些对 AI 理解页面结构帮助极大。

2.3 两者结合后的数据流

把整个链路串起来看，数据流是这样的：你在 Claude 或 Cursor 里说"帮我看看这个页面的结构"，模型判断需要调用网页渲染工具，通过 MCP 客户端发出请求，MCP 服务端收到请求后调用渲染 API，渲染 API 启动浏览器加载页面，把渲染后的内容返回给 MCP 服务端，服务端整理成模型能读的格式，最后模型基于这些内容给出分析。

这个链路里有两个关键设计点值得注意。第一是内容裁剪，渲染 API 返回的原始内容往往很大，直接塞给模型会浪费上下文，所以 MCP 服务端通常要做一层提取，比如只保留正文、去掉脚本样式、把 DOM 转成 Markdown。第二是超时控制，网页加载可能很慢，MCP 服务端必须设置合理的超时，避免模型一直干等。

理解了这两点，你后面配置参数的时候就知道每个选项是干嘛的了。

3. 环境准备与工具选型实操

3.1 客户端选择：Claude Desktop 还是 Cursor

Claude Desktop 和 Cursor 都支持 MCP，但适用场景不太一样。Claude Desktop 更适合"对话式探索"，比如你想让 AI 帮你分析一个页面的信息架构，边聊边看很顺手。Cursor 更适合"编码场景"，比如你在写爬虫或者调试前端，让 AI 直接看目标页面然后生成代码，衔接更自然。

我的建议是两个都配。Claude Desktop 用来做分析和调研，Cursor 用来做开发和调试。两者的 MCP 配置方式略有差异，但核心都是编辑一个 JSON 配置文件。

Claude Desktop 的配置文件位置，Windows 一般在用户目录下的 AppData 里，macOS 在 Library 下的 Application Support 里。Cursor 的配置入口在设置里的 MCP 面板，可以直接编辑 JSON。具体路径我不写死，因为版本更新可能会变，你在设置里搜 MCP 就能找到入口。

3.2 渲染服务选型：自建还是用现成

网页渲染 API 这块有两条路。一条是自己用 Playwright 或 Puppeteer 搭一个本地服务，另一条是用现成的云端渲染服务。

自建的好处是可控、免费、数据不出本地，缺点是你要自己维护浏览器环境，偶尔会遇到依赖问题。现成服务的好处是开箱即用，缺点是有额度限制，而且页面内容要发到第三方。

我个人的选择是自建，因为我的使用频率高，而且很多页面涉及内部系统，不适合外发。如果你只是偶尔用用，现成服务更省事。下面我主要讲自建方案，因为它的原理讲清楚了，你用现成服务也能举一反三。

3.3 依赖安装与版本确认

自建渲染服务需要 Node.js 环境，我实测下来 Node 18 以上比较稳。安装 Playwright 的时候有个坑要注意：npm install playwright只装了库，没装浏览器内核，你还需要跑npx playwright install chromium把浏览器下载下来。

node -v npm -v npm install playwright npx playwright install chromium

这几步跑完，你可以写个最简单的脚本验证一下环境是否正常。

const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch(); const page = await browser.newPage(); await page.goto('https://example.com'); const title = await page.title(); console.log('页面标题:', title); await browser.close(); })();

能打印出标题，说明渲染环境没问题。这一步看着简单，但它是后面所有工作的地基，千万别跳过。

提示：如果你在公司网络环境下，浏览器内核下载可能会失败，这时候需要配置镜像源或者手动下载。这个坑我踩过，卡了半小时才发现是网络问题。

4. 搭建网页渲染 MCP 服务端

4.1 服务端整体结构设计

一个能用的网页渲染 MCP 服务端，核心就三块：MCP 协议对接层、网页渲染层、内容处理层。协议对接层负责和客户端通信，渲染层负责调 Playwright 拿页面，处理层负责把原始内容转成模型友好的格式。

我建议用官方的 MCP SDK 来写协议层，因为它把通信细节都封装好了，你只需要关注工具的定义和实现。工具定义就是告诉模型"我提供哪些能力"，比如"渲染网页"这个工具，需要哪些参数，返回什么格式。

import { Server } from '@modelcontextprotocol/sdk/server/index.js'; import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'; const server = new Server( { name: 'web-render', version: '1.0.0' }, { capabilities: { tools: {} } } );

这段是服务端的骨架，定义了服务名称和能力。能力里声明了 tools，表示这个服务提供工具调用。

4.2 定义渲染工具的参数

工具的参数设计直接决定了模型能不能用好它。我设计的参数有这么几个：url 是必填的，表示要渲染的地址；format 控制返回格式，可以是 markdown、text 或者 html；waitFor 控制等待策略，比如等某个选择器出现；timeout 控制超时时间。

const tools = [{ name: 'render_page', description: '渲染指定网页并返回内容，支持 markdown/text/html 三种格式', inputSchema: { type: 'object', properties: { url: { type: 'string', description: '要渲染的网页地址' }, format: { type: 'string', enum: ['markdown', 'text', 'html'], default: 'markdown' }, waitFor: { type: 'string', description: '等待某个 CSS 选择器出现' }, timeout: { type: 'number', default: 30000 } }, required: ['url'] } }];

这里有个经验：description 写得越清楚，模型调用越准确。我一开始 description 写得很简略，结果模型经常漏传 format 参数，后来把每个参数的用途都写明白，调用成功率明显提升。

4.3 渲染逻辑与内容提取

渲染逻辑的核心是启动浏览器、加载页面、等待稳定、提取内容。等待稳定这一步很关键，如果页面还在加载你就提取，拿到的可能是半成品。

async function renderPage({ url, format, waitFor, timeout }) { const browser = await chromium.launch(); const page = await browser.newPage(); await page.goto(url, { waitUntil: 'networkidle', timeout }); if (waitFor) { await page.waitForSelector(waitFor, { timeout }); } let content; if (format === 'html') { content = await page.content(); } else { content = await page.evaluate(() => document.body.innerText); } await browser.close(); return content; }

networkidle表示等网络请求基本停止，这个策略对大多数页面够用。但有些页面有轮询请求，永远到不了 networkidle，这时候就要用 waitFor 指定具体元素。

内容提取这块，我强烈建议做一层清洗。原始 innerText 里会混入大量导航、页脚、广告文字，直接给模型会干扰判断。我的做法是用 Readability 这类库提取正文，再转成 Markdown。

4.4 把服务注册到客户端

服务写完之后，要在客户端配置里注册。Claude Desktop 的配置大概长这样：

{ "mcpServers": { "web-render": { "command": "node", "args": ["/path/to/your/server.js"] } } }

Cursor 的配置类似，只是入口在设置面板里。配置完重启客户端，如果服务正常，你会在工具列表里看到 render_page 这个工具。

注意：路径一定要用绝对路径，相对路径在不同工作目录下会找不到文件。我第一次配置就栽在这上面，排查了半天。

5. 在 Claude 和 Cursor 中实际使用

5.1 Claude Desktop 中的调用体验

配置好之后，在 Claude Desktop 里直接说"帮我渲染一下这个页面并总结主要内容"，把 URL 贴上去，模型就会自动调用工具。第一次看到模型真的去"打开"网页然后给你分析，那个感觉还是挺爽的。

我常用的几个场景：分析竞品页面的信息架构、提取文档站点的目录结构、检查页面有没有明显的可访问性问题。这些任务以前要手动复制粘贴，现在一句话搞定。

有个细节要注意：Claude Desktop 调用工具时会显示一个确认弹窗，你可以选择允许一次或者始终允许。如果你信任这个服务，选始终允许能省不少点击。

5.2 Cursor 中的编码场景应用

Cursor 里的用法更偏开发。比如我在写一个爬虫，不确定目标页面的 DOM 结构，直接让 Cursor 渲染页面然后生成选择器。或者我在调试前端，让 Cursor 看看渲染后的实际 DOM 和我预期的是否一致。

Cursor 的一个优势是它能结合当前打开的文件上下文。比如我正在写一个解析函数，让 Cursor 渲染目标页面，它会自动参考我的代码风格来生成解析逻辑，衔接非常自然。

5.3 参数调优的实战经验

用了一段时间之后，我总结出几个参数调优的经验。timeout 默认 30 秒对大多数页面够用，但有些重页面要调到 60 秒。waitFor 尽量指定具体选择器，比单纯等 networkidle 更可靠。format 方面，分析内容用 markdown，调试结构用 html，纯文本提取用 text。

还有一个技巧：如果页面需要登录才能看到内容，你可以在渲染服务里配置持久化的浏览器上下文，把登录状态保存下来。这样后续渲染就不用每次都登录了。这个功能对分析需要登录的后台系统特别有用。

6. 常见问题与排查技巧实录

6.1 服务启动失败怎么排查

服务启动失败最常见的原因是路径错误和依赖缺失。排查顺序是：先确认 node 能直接跑你的服务脚本，再确认客户端配置里的路径是绝对路径，最后看客户端日志里有没有报错信息。

Claude Desktop 的日志在开发者菜单里能打开，Cursor 的日志在输出面板里。看日志是最快的排查方式，别瞎猜。

6.2 渲染结果为空或不全

渲染结果为空，八成是等待策略不对。页面还没加载完你就提取了，或者内容在 iframe 里你没进去。解决办法是加 waitFor 指定关键元素，或者延长 timeout。

结果不全通常是内容提取逻辑太粗暴。innerText 只能拿到可见文本，如果内容在 shadow DOM 里或者需要滚动才加载，就要特殊处理。我的做法是渲染前先滚动到底部触发懒加载，再回到顶部提取。

6.3 模型不调用工具怎么办

有时候模型明明该调用工具，却直接凭记忆回答。这通常是工具 description 写得不够清楚，模型没意识到需要调用。解决办法是把 description 写得更具体，明确说明"当需要获取网页实时内容时使用此工具"。

另一个原因是客户端没正确加载服务。你可以在对话里直接问模型"你有哪些工具可用"，如果它列不出来，说明服务没注册成功。

6.4 常见问题速查表

6.5 几个我踩过的坑

第一个坑是浏览器内核没装。npm install playwright之后直接跑，报错说找不到浏览器，折腾半天才想起来要npx playwright install。

第二个坑是并发问题。我一开始每次渲染都新开浏览器，页面一多资源就爆了。后来改成复用浏览器实例，只新开页面，资源占用降了一大截。

第三个坑是内存泄漏。浏览器实例用完没关，跑久了内存一直涨。一定要在 finally 里确保 close 被调用，别偷懒。

提示：如果你要长时间运行这个服务，建议加一个定时重启机制，避免浏览器实例累积导致的问题。

7. 进阶玩法与扩展方向

7.1 结合截图做视觉分析

网页渲染 API 除了返回文本，还能返回截图。把截图和文本一起给模型，它能做更丰富的分析，比如判断页面布局是否合理、配色是否协调。这个能力在做 UI 审查的时候特别有用。

实现上就是在渲染逻辑里加一步page.screenshot()，把图片转成 base64 返回。模型收到图片后能直接"看"到页面长什么样。

7.2 批量渲染与任务队列

单个页面渲染好办，批量渲染就要考虑队列和限流。我的做法是加一个简单的任务队列，控制并发数，避免同时开太多浏览器把机器拖垮。并发数我一般设 3 到 5，具体看机器配置。

7.3 和其他 MCP 服务组合

网页渲染只是 MCP 能力的一种。你可以把它和文件系统 MCP、数据库 MCP 组合起来，形成完整的工作流。比如渲染页面拿到数据，写入文件，再存进数据库，整个过程模型自动编排。

这种组合的威力在于，模型不再只是"回答问题"，而是能"执行任务"。这也是 MCP 生态最有想象力的地方。

7.4 性能优化的几个方向

渲染性能优化主要有三个方向：复用浏览器实例、缓存渲染结果、并行处理。复用实例前面说过了，缓存的话可以按 URL 加时间戳做键，短时间内重复请求直接返回缓存。并行处理要注意控制并发，别把资源打满。

我实测下来，加了缓存之后，重复页面的渲染耗时从几秒降到毫秒级，效果非常明显。

8. 我个人的一些使用体会

这套方案我从搭起来到现在用了几个月，最大的感受是它把"AI 看网页"这件事从玩具变成了工具。以前让 AI 分析网页，总要手动准备材料，现在一句话就能触发完整的渲染和分析流程。

如果你刚开始接触，我的建议是先用现成的渲染服务把流程跑通，理解 MCP 的工作方式，再考虑自建。自建虽然可控，但维护成本不低，别一上来就给自己加难度。

另外，工具 description 的打磨值得花时间。模型能不能用好工具，很大程度上取决于你怎么描述它。我前后改了五六版 description，调用准确率才稳定下来。

最后分享一个小技巧：如果你经常分析同一类页面，可以把常用的等待选择器和提取规则做成配置模板，渲染的时候直接引用模板名，省去每次传一堆参数。这个做法我用了之后，日常操作简化了不少。