2.1 页面数据抓取

这是最直观的用途。用自然语言告诉 Claude Code 你要从哪个页面抓什么数据，它会自动打开页面、分析 DOM、提取信息并以结构化格式返回。

比如你可以说：“帮我打开 XX 后台的运营数据页面，把今天的核心指标（UV、PV、转化率）抓出来。“它不需要你写任何选择器或爬虫脚本。

和传统爬虫的区别：传统爬虫需要你分析页面结构、写选择器、处理反爬机制。Chrome DevTools MCP 走的是”像人一样浏览”的路线，它复用你的真实浏览器会话，所以登录态、Cookie、JavaScript 渲染的内容都能正常获取。

2.2 前端问题诊断

当页面出现异常时，你可以让 Claude Code 直接打开页面，帮你做一轮”AI 版的前端排查”：

• 检查控制台有没有报错
• 看网络请求有没有失败的
• 分析 DOM 结构是否符合预期
• 检查某些关键元素是否渲染出来了

它会把排查结果整理成报告，告诉你”哪里有问题、可能的原因是什么、建议怎么修”。

2.3 UI 还原度检查

设计稿交付之后，前端同学写完了页面，怎么确认还原度？可以让 Claude Code 同时打开设计稿页面和开发页面，对比两者的布局、间距、颜色等视觉差异。虽然不能完全替代人工 review，但能快速发现明显的不一致。

2.4 自动化回归

代码改完之后，你可以让 Claude Code 自动打开页面、执行一系列操作（比如点击按钮、填写表单、提交请求），然后检查结果是否符合预期。这相当于一个”自然语言驱动的 E2E 测试”。

2.5 多站点信息对比

如果你需要对比同一类信息在不同站点上的展示差异（比如竞品分析），可以让 Claude Code 同时打开多个页面，提取关键信息并做横向对比。

2.6 自动学习在线文档

让 AI 帮你系统阅读文档站，把关键知识提炼出来，再带着这些知识修改项目，要比自己一点一点去看要快速并且准确很多。

3.1 传统前端调试的痛点

关于前端调试，对于我自己来说，真正耗时间的其实不是”看报错”本身，而是看完报错之后的分析和修复过程。

举个例子：页面上一个组件渲染异常，Console 里报了一个 Cannot read properties of undefined。传统排查流程是：

1. 看报错堆栈，定位到某一行代码
2. 打断点或加 console.log，看变量的值
3. 发现某个 props 没传对，去查父组件的逻辑
4. 父组件的数据来自一个 API，去查 API 返回格式
5. API 返回格式和文档描述不一致，去翻文档确认
6. 最后发现是自己对某个参数的理解有误

这个流程里，第 5 步和第 6 步才是真正决定修复方向的关键，但它们也是最耗时间的——因为你需要在浏览器、IDE、文档站点之间来回切换。

当然，现在借助于 AI 可能找错误要比上面流程要快速简单很多，但是还是免不了要在不同页面进行切换，并且面对复杂一些的报错问题，可能还是需要自己去翻文档。

3.2 用 Chrome DevTools MCP 做”调试 + 文档”一体化排查

Chrome DevTools MCP 的价值不只是让 AI 能”看页面”，更在于它能让 AI 在同一个上下文里完成”看报错 → 查文档 → 给方案”的完整闭环。

我实际使用中的典型流程大概是类似于这样的：

1
我项目里 src/pages/game/GameDetail.tsx 页面，
2
游戏详情里的属性列表渲染不出来，页面白了一块。
3
请使用 Chrome DevTools 打开 http://localhost:5173/game/123，
4
帮我排查问题。如果涉及到第三方组件库的用法，
5
请同时打开对应的文档页面确认正确用法。

这个工具在这里主要的作用其实就在最后一句话，“如果涉及到第三方组件库的用法，请同时打开对应的文档页面确认正确用法”。

AI 收到这个指令后，会做以下事情：

1. 打开页面，截图查看当前状态 — 确认”白了一块”具体是哪个区域
2. 查看 Console 报错 — 发现有 TypeError: Cannot read properties of undefined (reading 'map')
3. 查看 Network 请求 — 确认 API 返回的数据结构
4. 读取项目代码 — 定位到 GameDetail.tsx 里渲染属性列表的逻辑
5. 打开组件库文档 — 确认 Table 组件的 dataSource 格式要求
6. 交叉比对 — 发现 API 返回的商品列表字段名是 items，但代码里写的是 list

整个过程 AI 就是在一个连贯的思维链里完成的，不需要像人一样在浏览器、IDE、文档之间来回跳转，所以分析速度更快，也更不容易遗漏线索。

3.3 调试过程中 AI 能做到的事

总结一下，在前端调试场景中，Chrome DevTools MCP 让 Claude Code 能做到这些：

• 看得到：打开页面、截图、查看 DOM 结构、读取元素属性、查看 Console 输出、检查 Network 请求。
• 查得到：根据调试过程中发现的问题，自动打开相关的文档页面，确认正确用法。
• 想得到：结合”页面上的实际表现”和”文档里的正确用法”，推断出问题的根本原因。
• 改得到：直接在项目代码里给出修改建议，你确认后就能应用。
• 验得到：代码改完后，自动刷新页面，重新检查功能是否正常、控制台有没有新的报错。

3.4 踩过的坑和经验教训

在使用这个工具的过程中，我也踩过一些坑，总结出来供参考：

文档页面有动态加载，AI 读到的内容不完整

有些文档站点使用了懒加载或者需要交互才能展开内容（比如点击”展开详情”按钮）。这种情况下，AI 第一次打开页面可能只能看到首屏内容。

解决办法：在指令里明确告诉 AI “如果页面有展开/折叠的内容，都要点开看一遍”。或者先手动打开页面，把需要关注的部分展开，再让 AI 来读。

文档版本和项目依赖版本不一致

比如你用的组件库是 v3，但 AI 默认打开的是最新版文档（v5），结果 AI 给出的修改建议全部是基于 v5 的 API，直接用了就会报错。

解决办法：在指令里明确指定文档版本，比如”请阅读 v3 版本的文档”。或者先确认自己项目的依赖版本，再告诉 AI 对应去读哪个版本的文档。

AI 给出的代码修改建议缺乏上下文

AI 读完文档后给出的修改建议，有时候会忽略项目里已有的封装。比如项目里已经对某个 API 做了二次封装，但 AI 不知道，直接用了原生 API 的写法。

解决办法：在指令里补充项目上下文。比如”我的项目在 src/utils/request.ts 里对 axios 做了封装，所有 HTTP 请求都要走这个文件”。上下文给得越充分，AI 的修改建议就越准确。

所以其实，我们自己对于给 AI 的条件和约束也是很重要的。

4.1 让 AI 帮你写文档

不只是”读文档”，也可以让 AI 通过 Chrome DevTools MCP 参考其他项目的文档风格，帮我们写自己项目的文档：

1
请使用 Chrome DevTools 打开 Ant Design 的组件文档
2
（地址：https://ant.design/components/table-cn），
3
学习它的文档结构和写作方式，
4
然后为我项目 src/components/GameTable.tsx 这个组件
5
写一份同样风格的 API 文档。

4.2 让 AI 帮你做竞品分析

如果我们想了解某个竞品的某个功能是怎么实现的，可以让 AI 打开竞品的页面，分析它的 DOM 结构和交互逻辑：

1
请使用 Chrome DevTools 打开 [竞品URL]，
2
分析它的 [功能名称] 是怎么实现的：
3
- 页面结构是什么样的
4
- 交互流程是怎样的
5
- 有哪些细节设计值得参考
6
整理成一份分析报告。

4.3 调试 + 文档驱动的”反向验证”

有时候我们想验证某个第三方库的文档是否准确。可以让 AI 读完文档后，直接在项目里按文档的写法试一下，然后用浏览器看看效果：

1
请使用 Chrome DevTools 阅读 [SDK] 的 [某功能] 文档，
2
然后在我项目里按照文档的示例写一个最小可运行的例子，
3
用浏览器打开看看文档里的写法是否真的能工作。
4
如果效果不对，帮我分析是文档写错了还是我理解错了。