浏览器测试DevTools
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @user_3c6cb52e/browser-testing-with-devtools-lr-25f3 技能到当前 AI 助手。
技能介绍
你在调什么,其实看不到
静态代码审查能告诉你某段 JS 里有没有语法错误,但它回答不了「用户点这个按钮之后,页面究竟发生了什么」。DOM 有没有按预期更新?控制台里是不是又冒出了 CORS 报错?某个接口的响应结构是不是和文档对不上?性能瓶颈到底卡在 LCP 还是 CLS?这些问题在运行时才暴露,而传统做法是打开 DevTools 手动一条条翻,非常慢。
这个技能的核心思路很简单:把 Chrome DevTools 通过 MCP 暴露成 Agent 可直接调用的工具集,让 AI 拥有和人一样的「看页面」能力。
它做了什么
- DOM 感知:Agent 可以读取实时渲染出的文档树,而不是源码里的模板字符串
- 控制台日志抓取:
console.error、console.warn以及自定义输出能被程序化读取,不再需要人眼扫屏 - 网络请求分析:拦截 XHR / Fetch 请求,检查请求头、响应体、状态码和耗时
- 性能画像:采集 Core Web Vitals 指标,包括 paint timing、layout shift 等
- 修复验证:改完代码之后,让 Agent 重新跑一遍,确认问题在真实浏览器里真的消失了
典型工作流是:Agent 启动浏览器 → 执行操作 → 抓取运行时数据 → 和预期比对 → 给出诊断结论。整个过程不需要人盯着 DevTools。
适用边界
这个技能不是万能的。它不处理后端逻辑、CLI 工具或非浏览器环境,这些场景用它纯属浪费。另外,--autoConnect 模式会连到你正在使用的 Chrome,跳过登录态模拟,所以只有在确实需要真实用户会话时才用。推荐默认走 --isolated 配置,浏览器关闭后临时 profile 会被清除,避免污染日常浏览数据。
一句话:它能验证「运行时到底发生了什么」,但不能替代你对业务逻辑本身的判断。
使用场景
- 前端改了表单提交逻辑,需要让 Agent 在真实浏览器里触发提交,并确认渲染后的数据是否符合预期
- 页面加载缓慢,需要通过 Agent 采集性能指标,定位瓶颈是 LCP 偏高还是布局偏移过大
- 接口返回 401 或响应结构异常,需要 Agent 抓取网络请求,检查请求头和参数是否正确
- UI 样式修复后,需要 Agent 自动点击按钮并抓取控制台日志,确认没有新增报错
适合人员
- 前端工程师:需要排查页面交互故障,直接看到运行时 DOM 变化而不只看源码
- QA 工程师:编写自动化测试,希望 Agent 模拟真实用户操作并抓取控制台日志
- 技术作者:在博客中给出真实性能数据,而非凭猜测描述页面表现
- 全栈开发者:调试跨端联调问题,同时检查网络请求和前端渲染结果