企业官网建设流程全解析

Cherry Studio装好之后，如果你只是拿来聊聊天、写写文案，那它大概只发挥了十分之一的价值。真正让我对它刮目相看的，是用MCP把自动化测试和数据爬取这两件事接进来之后——不写测试脚本、不写爬虫代码，全靠自然语言指挥AI干活，浏览器自己开、数据自己抓、Excel自己生成。这篇就是把我的整套高阶玩法、踩过的坑和可以复现的操作步骤完整写出来，适合已经会基本使用Cherry Studio、想把它变成生产力工具的朋友。

1. Cherry Studio的高阶定位：从对话工具到Agent工作台

1.1 MCP相当于给Cherry Studio装了一双手

多数人用Cherry Studio，停留在"给模型发消息"的阶段。你想要它测一个网页，它只能给你一段代码，你还得拿到终端里去跑；你想要它爬点公开数据，它也只能给你一个脚本框架，里面的选择器和解析逻辑大概率还要自己调。我刚开始就是这个状态：AI负责出主意，我负责动手，效率提升很有限。

MCP（Model Context Protocol，模型上下文协议）把这个问题从根上解决了。它像USB接口标准一样，把外部工具、数据源、软件能力统一接到模型面前。Cherry Studio本质上是MCP Host（宿主），负责管理和调度外部工具；MCP Server是真正干活的进程，比如控制浏览器、发HTTP请求、读写文件。配置好之后，模型收到你的指令，会自己判断该调用哪个工具、传什么参数，再把执行结果拿回来继续对话。

我常用一个比喻：原来的AI像一个只会纸上谈兵的顾问，MCP配好之后，它手里多了一套螺丝刀和电钻，能直接上手干活了。顾问还是那个顾问，但产出形式完全不同。

1.2 我实际跑通的三类高频场景

说实话，MCP能做的事非常多，我不建议一上来就铺开全部能力。在Cherry Studio里，我自己跑得最稳、复现率最高的是这三类：

• 自动化测试：让AI操作真实浏览器，按测试用例点击、输入、断言，回归完出一份问题清单。
• 数据爬取：让AI访问公开网页、提取结构化字段、去重清洗，最后导出CSV或Excel。
• 临时数据处理：让AI读取本地文件、调用脚本、处理完再写回来，相当于一个能碰你电脑的对话终端。

这三类里，前两类最值得学，因为可复制性最强。你不需要是多资深的工程师，只要会描述需求，AI就能借助MCP工具完成大部分执行环节。我团队里的测试同学，基本零写码经验，我把这套配置教给她，她第二天就能自己跑回归了。

1.3 先搞懂工具组合再动手，避免选型反复

核心用到的MCP Server其实不多，我整理了一张选型表，直接照着选就行：

这里的关键认知是：不要贪多。工具加得越多，模型在“选哪个工具”上越容易纠结，上下文Token也会被工具定义占掉一大截。我平时就保持2到3个核心Server，跑测试时只开Playwright，跑抓取时才临时把Fetch加上。工具少而精，模型的工具调用准确率明显更高。

2. 把基础设施搭起来：MCP环境配置走一遍

2.1 需要准备哪些组件

先澄清一个常见误解：MCP不是某个单独安装的软件，而是一套协议规范。所以“搭建”其实是把三个角色凑齐：

• MCP Host：用Cherry Studio即可，较新版本内置了MCP管理面板，不需要额外装宿主。
• MCP Server：按需选择，上面表格里那两个是我最常用的。
• 模型：建议选支持工具调用（Function Call / Tool Use）的模型。Claude系列、GPT系列、Qwen系列等主流模型都支持，实测下来模型越新，工具参数生成越准确，尤其在选择器和等待策略上差距明显。

组件版本方面，我把Cherry Studio升级到最新版才省心，旧版本对MCP的支持不完整，联调时经常出现工具不显示的问题。Node.js建议18以上，因为MCP Server大多通过npx启动，Node版本太低会直接报错。

2.2 两个MCP Server的具体配置方法

打开Cherry Studio的设置，找到“MCP服务器”管理面板，新增服务器时选stdin（stdio）类型，把命令和参数填进去。我用得最多的两个配置如下。

第一个是Playwright MCP，微软官方出的，作用是给AI浏览器控制能力：

• 命令：npx
• 参数：@playwright/mcp@latest

如果想让AI默认打开有界面的浏览器方便观察执行过程，可以在参数里追加--headful；不加参数默认是无头模式，适合后台批量跑。我在调试用例阶段会开有头模式，真正回归时才切回无头。

第二个是Fetch MCP，官方参考实现，作用是发起HTTP请求、抓取网页内容：

• 命令：npx
• 参数：-y @modelcontextprotocol/server-fetch

添加完成后，面板里如果显示“已连接”或者“运行中”，说明Server启动成功。这时候回到对话窗口，注意看工具栏上的“工具”图标，点开能看到playwright_browser、fetch_text等一系列工具，说明工具定义已经注入到模型上下文里。

我第一次配置时犯过一个低级错误：添加完Server之后没有重新开对话，模型一直说“我没有浏览器工具”。Cherry Studio对MCP工具的感知是在会话初始化时完成的，改了配置必须新开会话才生效。

2.3 配置环节的三个隐藏要点

第一，npx首次运行要下载包，网络慢的话可能等很久。建议先手动在终端里执行一次npx @playwright/mcp@latest，让它把包和Chromium浏览器内核都拉下来，确认直接能跑之后，再回Cherry Studio配置。Playwright首次启动会自动下载Chromium，大约一两百MB，这一步很多人卡住，其实是下载慢，不是配置错。

第二，端口冲突问题值得提前说。部分MCP Server走SSE或HTTP模式，会占用本地端口，如果你本机开发服务比较多，很容易启动失败。能用stdio模式解决的尽量用stdio，它不走网络端口，进程之间通过标准输入输出通信，省心很多。

第三，MCP Server不是越多越好。我在做Web自动化时只保留Playwright，做数据抓取时才启用Fetch，用完就停用。工具列表清爽了，AI的判断速度和准确性都会上升。

3. 自动化测试实战：让Cherry Studio替你跑回归用例

3.1 用自然语言让AI操作真实浏览器

自动化测试的第一步，是让AI明白“你要测什么”。你不需要写代码，把测试用例翻译成自然语言指令就行。

比如我要验证一个登录页面的正常流程，我会在Cherry Studio里这样描述：

使用浏览器打开 http://localhost:3000/login，点击用户名输入框并输入 admin，点击密码输入框输入 123456，然后点击登录按钮。登录成功后，等待页面出现“欢迎回来”字样。如果出现，返回测试通过；如果没出现，把当前页面截图保存到本地，并列出页面上的可见错误信息。

这个Prompt看起来普通，但我是刻意拆成四块的：操作起点、逐步动作、断言条件、异常处理。AI通过Playwright MCP执行时，会自动定位元素、点击、输入、等待断言、必要时截图。你不懂XPath、不懂CSS选择器都没关系，AI会自己选。

我在一个小项目上实际跑了20个核心回归用例，真实浏览器环境、模拟用户点击，全部跑完大约不到10分钟。如果手动点，半小时起步，而且人会漏看页面上的状态变化，AI不会。

3.2 让AI读懂测试用例表，而不是每次都口述

用例多了以后，每次在对话框里打字描述不现实。我的做法是维护一个CSV表格，字段包括：用例编号、前置条件、操作步骤、预期结果。然后把表格路径告诉AI：

读取 D:/cases/login_cases.csv，逐条执行里面的用例。执行时先看前置条件，需要准备数据的先执行准备动作，再按操作步骤操作页面。每执行完一条，记录实际结果，输出通过与失败的原因。

配合Filesystem类能力或者Cherry Studio的本地文件读取，AI能自己解析表格、循环执行。这其实就是最朴素的测试数据驱动，只不过由AI充当执行引擎。

这里要特别提醒一句：用例之间有关联性时，一定在指令里说明。比如前一条用例创建了订单，后一条要基于这个订单继续操作，你要告诉AI按顺序执行、不要清空浏览器状态。如果用例相互独立，反而要让AI每条之间清掉cookie和缓存，避免状态污染。

3.3 接口自动化测试也能交给MCP跑

很多人以为MCP自动化测试只针对浏览器，其实接口层面的自动化也可以。Cherry Studio配合Fetch MCP，能让AI直接发起GET、POST请求，按接口用例验证状态码、响应体、业务字段。

我常用的指令模板：

读取 D:/cases/api_cases.csv，用例里有请求方法、URL、请求头和请求体。逐条发送HTTP请求，把响应状态码和响应体里关键字段和expected字段比对。不一致的记录下来，输出成表格。

这里Fetch MCP扮演的是“HTTP客户端”，模型负责参数组装和断言。对于没有复杂签名逻辑的内部接口，实测非常好用。但要注意：涉及加签、加密的接口，MCP Server做不了太复杂的签名逻辑，这种情况我建议还是用现成的自动化框架，或者通过自定义脚本MCP封装。

3.4 测试报告的三种产出形态

跑完测试后，AI手里有原始执行结果，怎么输出很关键。我常用三种形态：

一是问题清单。让AI汇总失败的用例编号、失败步骤、截图路径、可能原因。适合快速丢给开发看，开发不用自己再翻一遍执行日志。

二是结构化报告。让AI把执行结果写回CSV或JSON，包括每条用例的耗时、状态、错误摘要。我一般让它生成一个result.csv，在原有用例表基础上追加“实际结果、执行时间、截图路径”三列，这样我拿到Excel里直接做透视图。

三是自然语言复盘。让AI分析失败原因，区分是环境问题还是功能回归。这个价值很高，因为AI能看到浏览器控制台输出和断言失败信息，归因比人肉翻日志快很多。我开头提到的那个测试同学，现在每天的“回归日报”都是AI自动生成的。

4. 数据爬取实战：从网页结构化到Excel导出

4.1 先想清楚合规边界再谈爬取

聊数据爬取，我必须先把边界说清楚。我做这类事情只处理公开可见的信息，并且坚持三个原则：遵守目标网站的robots.txt协议、控制请求频率不给对方服务器造成压力、不采集涉及个人隐私和账号内部的数据。在这个前提下，MCP帮你做的是把人工复制粘贴的活自动化，不是绕过权限的黑科技。

实际的执行上，我会让AI先去读目标域的robots.txt再决定抓哪些路径。指令很简单：

用fetch_text读取 https://example.com/robots.txt，列出允许抓取的路径和禁止抓取的路径，然后根据这个规则判断我下面要抓的内容是否可以抓取。

这一步很多人不做，但既是合规步骤，也能避免你白爬一通——不少网站会把核心列表藏在禁止路径下。

4.2 静态页面抓取：Fetch MCP就够了

如果目标页面是服务端渲染，内容直接写在HTML里，Fetch MCP完全可以搞定。我的指令模板如下：

用fetch_text抓取 https://example.com/list，提取页面里所有商品名称、价格、链接，以JSON数组格式返回。先不写文件，直接在对话里展示前10条。

注意，Fetch MCP返回的是经过清洗的文本，不是原始HTML。它默认去掉脚本、样式和广告噪声，对信息型页面很好用。但缺点也在这里：如果要抓表格数据、多级分类这种结构，纯文本容易丢失。这时候要么让AI请求原始HTML，要么切换到Playwright。

另外，Fetch MCP的请求头自定义能力有限。遇到需要特定User-Agent或Referer的站点，它不一定能搞定。我的习惯是：先试Fetch，遇到403再切换Playwright，后者是完整浏览器，行为更接近真人访问。

4.3 动态页面与翻页列表：交给Playwright MCP处理

现在主流网站基本都是前端渲染，内容藏在JavaScript发起的接口里，直接HTTP请求拿不到。这时候就是Playwright MCP的主场。

我给个真实案例。之前需要抓一个资讯站的文章列表，前三页。我的对话指令是：

用浏览器打开 https://example.com/news，等待页面出现列表容器。每一条新闻，提取标题、链接、发布时间。翻页方式是点击页面底部的“下一页”按钮。每翻一页等2秒，共翻3页。全部抓完以后，合并去重，保存到 D:/data/news.json。

这段话说出来简单，AI实际执行时会做几件复杂的事：定位列表项、判断翻页按钮状态、等待异步数据加载、处理重复项。这些在传统爬虫里是几百行代码的工作量，在MCP模式下被自然语言替代了。

动态页面最常翻车的是“时机”问题：元素还没渲染完，AI就去提取，拿到的是空数据。所以我在指令里会把等待策略写明确：等待某个稳定元素出现、等待固定秒数、等待网络空闲。把这一步点出来，抓取成功率会大幅提升。

4.4 数据清洗、去重与导出Excel的落地方式

抓完数据，下一步是让数据变成能交付的表格。这里我分三步走。

第一步，清洗。让AI检查字段：价格里的“￥1,299.00”转成1299，日期统一成YYYY-MM-DD，缺失字段标记为null。注意，不要删记录，缺失字段先留着，后面可能还要人工补。

第二步，去重。指定基准字段。我常用链接或ID，因为这两个才是唯一标识。如果让AI按标题去重，两个相似标题但不同链接的记录可能会被误删。

第三步，导出。我最常用的是让AI生成CSV文件，用UTF-8带BOM编码，这样Excel打开中文不乱码。如果你必须交付xlsx，可以配置一个执行Python脚本的MCP Server，或者让AI生成openpyxl脚本并运行。

这里顺便回答很多新用户会问的问题：Cherry Studio本身没有“一键导出Excel”按钮，网上经常有人找这个功能。实际上最靠谱的路径，就是让AI通过MCP工具生成CSV或Excel文件，你再双击打开，效果完全一样，而且字段顺序、编码都可控。

我的导出指令模板：

把上一步清洗去重后的数据写入 D:/data/news.csv，使用UTF-8 with BOM编码，字段顺序为标题、链接、发布时间、来源。写完后读取一遍，展示前5行确认格式正确。

“写完后回读确认”这个习惯是我踩过坑之后养成的，它能立刻暴露编码错误和字段错位，不用等交付给同事才翻车。

5. 实测中容易翻车的五个地方与排查思路

5.1 MCP Server启动失败：先看日志，再看工作目录

换电脑后第一次配置Playwright MCP，面板里一直显示未连接。我的排查思路很固定：先在终端手动执行同一条启动命令，看有没有JavaScript报错；如果终端能起，再检查Cherry Studio的启动目录和环境变量是否和终端一致。很多stdio类型的Server对当前工作目录和Node路径敏感，终端能启动不代表应用进程能启动。版本升级之后遇到类似问题，也可以先清掉npx缓存再试。

5.2 模型“看不见”工具：新开对话再验证

配置成功后最常见的问题，是AI一直回复“我无法打开浏览器”。根本原因有两个：一是模型没有规划到工具调用，二是上下文里根本没注入工具定义。处理方式很直接：新开对话，确认工具列表出现在工具栏；然后在指令里主动提示“你可以使用playwright_browser系列工具来操作浏览器”，把模型的重心引到工具调用上。如果新开对话还不行，再去检查Server状态。

5.3 页面加载超时与等待策略

浏览器自动化里，超时是家常便饭。模型默认的等待时间不一定适合慢页面。我通常在指令里写“等待元素出现，超时时间30秒”，或者“等待网络空闲后再操作”。如果某个页面反复超时，不要无脑重试，先让AI截图看页面当前状态，再判断是元素选择器选错了，还是服务本身响应慢。这一步能把调试时间缩短一大半。

5.4 爬取结果乱码与字段错位

CSV乱码，十有八九是编码问题。让AI用UTF-8 with BOM写文件，能解决绝大多数Excel打开中文乱码的问题。字段错位则是分隔符问题：字段内容里自带逗号或换行时，让AI统一用双引号包裹字段，或者采用不容易冲突的制表符作为分隔符。生成完一定要回读前几行，肉眼确认一下再交付。

5.5 对话历史污染工具行为

最后一个是几乎人人都会踩的坑：同一会话里，前面操作过A站点的页面结构，后面让AI抓B站点，它会下意识沿用前面的定位逻辑和字段名。结果就是抓回来的数据牛头不对马嘴。我的做法是：按任务开新对话，一个会话只干一类事。工具配置保持精简，任务边界清楚，AI的发挥就稳定很多。尤其是在自动化测试和爬取之间切换时，新开一个会话的成本几乎为零，不值得为了省事承担串味风险。

5.6 登录态和验证码场景怎么处理

做爬取或测试时，有时绕不开登录。Playwright MCP本身能在浏览器里完成输入账号密码的操作，但如果目标系统有短信验证码或者扫码登录，AI就处理不了了。我的方案是：提前在浏览器里手动登录，保持会话，再让Playwright MCP以持久化上下文的方式复用这个登录态。虽然多一步手工操作，但确实能绕过验证码这道坎，而且比教AI破解验证码靠谱得多。

最后分享一点我的个人体会

用惯这套组合之后，我对“AI自动化”的理解变了很多。以前觉得自动化是程序员的事，现在发现只要工具链通了，真正决定上限的是“你会不会把需求描述清楚”。Cherry Studio加MCP这套玩法，本质上是把“写代码”变成了“下指令”，而指令里最值钱的部分，是你对业务的理解、对用例的判断、对数据结构的规划。它会帮你省掉大量重复劳动，但不会替代你思考。

如果你手头正好有Cherry Studio，我的建议是从一个小页面、一条测试用例开始，跑通一次完整的MCP链路，再逐步放大。等你看到浏览器自己打开、自己点击、自己生成报告的时候，大概率会回来重新定义“AI能干什么”这个问题。