day7✅-2026/11/12

一、claude code桌面端安装 Playwright MCP

现存问题⚠️

初始化的claude code进行网页信息搜索，并摘取用户需要特定信息时，调用的是两个内置工具/系统工具如下 1️⃣WebSearch：拿到的是搜索结果列表——标题、链接、一段摘要。 2️⃣WebFetch：挑其中一条链接，根据搜索结果给出的摘要/信息+用户最初问的问题，agent模型自主写一份提示词（决定筛什么、用什么格式、要多精确），紧接着claude桌面端进程中（node.exe）发起请求下载HTML。markdown文件和prompt一起发送给模型进行处理

但最后出来的结果只能处理静态网页（html）

• JS 渲染的站，WebFetch 拿到的是空壳。现在大量网站是 React/Vue，HTML 里只有一个空的 《div id="root"》内容全靠浏览器里跑 JS 才出现。WebFetch 不跑 JS。
• 要登录的一律进不去。登录墙后面的内容它够不着。
• 内容会被压缩。它内部用一个小模型处理，长文档可能被摘要，细节会丢；同一 URL 15 分钟内还走缓存。

真实体验是：维基、博客、官方文档、新闻这类静态页——很好用；知乎、微博、小红书、需要登录的论坛、各种 SPA 应用——基本读不到，我只能告诉你"拿不到"。

❓为什么是 Playwright MCP

介绍：微软做的浏览器自动化服务器，让 AI 能开一个真 Chromium 去逛网页 给的是 accessibility tree

accessibility tree（无障碍树）：本来是浏览器给盲人用的读屏软件准备的——盲人看不见屏幕，软件就把这份清单念出来（只写有什么、叫什么、能不能点）

主线五步：

1️⃣浏览器拿到 HTML，先建 DOM：页面里所有标签都在，几万个 div/span 也在。叠上 CSS，算出哪些真的看得见

DOM（文档对象模型）：浏览器把 HTML 那段文字，解析成一棵由节点组成的树，这棵树就是 DOM

2️⃣同时另建一棵无障碍树：按语义规则把 DOM 筛一遍，div 这种没语义的直接被排除在外

留下的每个节点只带三样：role（按钮/链接/标题/输入框）、name（念出来的名字）、state（勾选/展开/禁用）。

🌟三个启动模式

🌟它的代价

慢 —— 每次真渲染，一个页面几秒起 吃内存 —— 一个 Chromium 常驻几百 MB token 不稳定 —— 页面越乱，树越大 对你是半残 —— 截图那条路走不通，纯文本模型读不了图

它解决的是"WebFetch 撞墙"那三类场景，不是替代 WebFetch——简单静态页用 WebFetch 更快更省。

skill和cmp怎么生效

Skills 启动时扫目录➡️你建 .claude/skills/xxx/，它自己就读到了 MCP 配置驱动➡️.claude.json 的 mcpServers 里写一条命令，启动时执行它

所以skill可以放专门的目录进行有序化存放，但mcp不行