illegalCreed

中文

English

中文

English

Appearance

MCP·AI 跑 e2e·场景与阶段 ​

让 AI 用自然语言驱动真实浏览器——快速验证这里它比框架 e2e 更对

速查 ​

  • 是什么：Playwright MCP / Chrome DevTools MCP 让 AI 用自然语言驱动真实浏览器（导航/点击/填表/断言/截图/读 console/抓网络/Lighthouse），skills 封装常用流程
  • 就该用 MCP 的场景：快速冒烟、临时验证（还没写框架 e2e）、探索性「让 AI 自己点点看哪坏」、bug 复现、a11y 快查、给没 e2e 框架的项目兜底
  • 适合阶段：开发中即时 / 自测冒烟 / bug 复现 / 验收 demo
  • 核心观点：这里 MCP 比框架 e2e 更对（说句话就跑，免写 spec）；但可重复性/严格断言不如框架，不是 CI 回归门禁的替代
  • 一句话边界：用 MCP发现问题，用框架 spec 守住问题

MCP 让 AI 跑浏览器，到底是什么 ​

这是 AI 时代真正的新能力，以前根本做不到。Playwright MCP、Chrome DevTools MCP 把浏览器的操作能力暴露给 AI，于是你可以用自然语言指挥 AI 操作真实浏览器：

  • 导航 / 交互：打开页面、点击、填表、选下拉、按键、拖拽。
  • 断言 / 取证：等待元素、读文本、截图、抓页面快照。
  • 诊断 / 排查：读 console 报错、抓网络请求与响应、跑 Lighthouse 看性能/a11y。

配合 Claude Code skills，常用流程（「登录测试账号」「造一条测试数据」）能封装成可复用的步骤。你说一句「打开订单页，筛选今天的订单，看看列表加载有没有报错，截个图」，AI 就去做了——不用写一行 Playwright 代码。

就该用 MCP 的场景 ​

快速冒烟：开发中随手验一下 ​

刚改完一个页面，想立刻看「主流程还通不通」。让 AI 跑一遍登录→进页面→点核心按钮→看有没有报错。比手工点快（它自动做），比写框架 e2e 快（不用写 spec）。改一版验一版，迭代飞快。

临时验证：还没写框架 e2e 时 ​

功能刚出来，e2e spec 还没排上写。这空档期用 MCP 顶上——「帮我验下这个新表单提交后跳转对不对、数据存进去没」。它不进 CI、不算正式回归，但能让你当下就知道有没有大问题，不用干等 e2e 写好。

探索性兜底：让 AI 自己点点看哪坏 ​

注意：纯探索性「找意料之外的问题」仍是 手工 的主场——AI 只会按剧本走。但 MCP 能做一种「半探索」：你给个大方向（「把这个表单各种边界值都试试，看哪个报错」），让 AI 批量跑一堆你想得到的边界组合，省去手工一个个点。想得到的边界让 AI 扫，想不到的留给人。

bug 复现：快速还原现场 ​

线上报了个 bug，复现步骤有点绕。让 AI 按步骤在浏览器里跑一遍，读 console、抓网络请求，快速确认能不能复现、错在哪。复现成功后，再让 AI 把它写成框架 spec 的 fail 用例进回归网（见 bug-fail-first）——MCP 负责快速复现，框架负责永久守护。

a11y 快查：可访问性体检 ​

借 Chrome DevTools MCP 跑 Lighthouse / 读无障碍树，快速查一个页面的对比度、ARIA、焦点顺序、tap target 大小有没有明显问题。当下出体检报告，比写一套 a11y 断言快得多。

没框架时兜底：给裸项目一层网 ​

有些项目压根没搭 e2e 框架（老项目、小工具、demo）。引入 Cypress/Playwright + 写 spec 成本不低。MCP 让这种项目零搭建就能有「AI 跑一遍核心流程」的兜底验证——总比完全没有强。

各阶段怎么用 MCP ​

阶段MCP 做什么产物
开发中即时改一版跑一遍主流程冒烟即时通过/失败 + 截图 + console
自测冒烟提测前让 AI 过一遍核心链路自测报告里的冒烟记录
bug 复现按步骤还原现场，读 console/网络复现路径（再转框架 fail 用例）
验收 demo给需求方演示时让 AI 跑真实流程现场可视化的流程跑通

边界：MCP 发现问题，框架守住问题 ​

这是我对 MCP 最重要的一条态度，必须说清：

MCP 不是 CI 回归门禁的替代

  • 可重复性不够：自然语言驱动有不确定性，同一句指令两次跑路径可能微妙不同，比 git 里固定的 spec 更易 flaky。
  • 断言不够严：MCP 的「看看有没有报错」是松断言；框架 spec 能精确断言「列表第 2 行第 3 列等于某值」「这个接口被调用了恰好 1 次」。
  • 进不了 CI 门禁：CI 需要确定、可重复、能一键重跑成百上千次的回归网。MCP 对话式的跑法不适合当卡红的门禁。

正确分工：MCP 用来发现问题（快、灵活、零搭建），框架 spec 用来守住问题（确定、可重复、进 CI）。发现了值得长期守的问题，就让 AI 把它沉淀成框架用例（见 AI 写框架用例）。

换句话说：MCP 和框架 e2e 不是竞争关系，是接力关系。开发中、复现时用 MCP 快速摸清状况；确认这是个要长期守的回归，转手写成 spec 进回归网。拿 MCP 当门禁，或拿框架 e2e 去做开发中的快速冒烟，都是错配。

下一步 ​