昨晚在 staging 跑了一轮 Cypress E2E，核心流程过了，但 cleanup 阶段找不到一个 overflow 按钮，后续全部 skip，某个 hosting 模块的 Repository 在集群里根本不存在，API 却返回 200。要搞清楚发生了什么，我得看录制的视频，手动 kubectl 查集群，自己拼因果链。
看视频的时候我停了一下，觉得哪里不对。Cypress 录视频这件事，在 2026 年的 AI 工作流里，显得异常古老。
三代框架，三种哲学
前端 E2E 测试框架的历史不长，但迭代很快：
Selenium（2004）是第一代，进程外通过 WebDriver 协议控制浏览器，笨重但开创了整个赛道。Cypress（2014）是第二代，直接跑在浏览器的 JavaScript 线程里，和你的应用共享同一个运行时。这在当年是革命性的 – 你可以直接访问应用的 Redux store，断言变得极其简单。但这个架构决策也埋下了所有后来的限制：不能跨 tab，不能跨域，不能原生支持多浏览器。
Playwright（2020，Microsoft）是第三代。它回到了进程外的架构，但用的是现代的浏览器协议（CDP 和 WebDriver BiDi）。它不和应用抢线程，天然支持多 tab、多浏览器（Chromium、Firefox、WebKit），并行化免费且原生。到 2026 年，Playwright 的周下载量已经超过 3000 万，事实上取代了 Cypress 的行业标准地位。
但这些技术指标 – 速度快 30%、包体积小、并行免费 – 都不是我真正关心的。真正让我觉得 Cypress 过时的，是一个更根本的问题。
视频是给人看的，AI 看不了
Cypress 的 debug 模型建立在一个假设上：测试失败后，有一个人类去看录制的视频，理解发生了什么，然后修代码。这在 2014 年完全合理。
但在 2026 年，我的测试 debug 循环长这样：
AI 写测试代码，跑测试，测试挂了。然后呢？
如果是 Cypress：生成了一段 mp4 视频。AI 看不了这个视频。我得自己打开视频，看到第 23 秒按钮没找到，截个图，或者用文字描述给 AI 听 – “那个 overflow 按钮没出现，可能是 DOM 还没渲染完”。AI 根据我的描述改代码，再跑一次，可能又挂在别的地方，我又得看一遍视频。
每一轮 debug 循环 5-10 分钟，而且我被锁在这个循环里，一步也离不开。
如果是 Playwright：生成的是一个 trace.zip，里面是结构化的 accessibility tree snapshot、network log、console output。AI 直接读这些数据，理解 “button role=‘menu’ 在 snapshot 里不存在，上一步的 network response 返回了 403”，自己改代码，自己重跑。
整个循环 30 秒到 1 分钟，不需要我参与。
这就是根本差距。不是语法好不好写的问题，不是速度快不快的问题。是 debug 产物能不能被 AI 消费的问题。Cypress 的产物是视频（给人的），Playwright 的产物是结构化数据（给 AI 的）。
两个 MCP，两个角色
理解了"AI 需要结构化数据"这个前提，Playwright MCP 和 Chrome DevTools MCP 的分工就清晰了。
Chrome DevTools MCP 是 Google 官方出的，直接暴露 Chrome 的 DevTools Protocol。它能看 Network panel 里每个请求的 header 和 body，能跑 Lighthouse 做性能审计，能抓 heap snapshot 查内存泄漏，能看 Console 里的每条日志。它本质上是一个检查工具 – 帮你看清浏览器内部发生了什么。
Playwright MCP 是 Microsoft 出的，暴露的是 Playwright 的浏览器自动化能力。它能导航、点击、填表、等待元素出现。它本质上是一个操作工具 – 帮你像用户一样使用浏览器。
一个是技师，一个是司机。
更关键的是，Playwright MCP 的每一个操作都直接对应测试代码里的一行：browser_click 就是 page.click()，browser_fill 就是 page.fill()，browser_navigate 就是 page.goto()。这意味着 AI 通过 MCP 交互式探索完一个流程之后，可以直接把操作序列翻译成 .spec.ts 文件。
Chrome DevTools MCP 做不到这一点。它能告诉你页面上有什么，但它的操作语义和测试代码之间没有直接映射关系。
所以最佳实践是两个都装。AI 用 Playwright MCP 操作浏览器、生成测试；测试挂了或者需要深入调查时，切到 Chrome DevTools MCP 查 network、查 console、跑 performance trace。这跟后端开发里用 httptest 写集成测试、用 pprof 做性能分析是一个道理 – 你不会用 pprof 写测试，也不会用 httptest 查内存泄漏。
上层 Agent 框架：有 Claude 就不太需要
2025 年冒出了一批 AI-native 测试框架：Stagehand 提供 act()、extract()、observe() 三个原语让 AI “推理"页面状态；ZeroStep 是 Playwright 的插件，用 await ai(‘click the login button’) 替代 CSS selector；Midscene.js 来自字节跳动，走纯视觉路线，截图给多模态 LLM 分析。
它们的共同点是在 Playwright 之上加了一层 AI 封装，让测试可以用自然语言描述而非精确的 selector。理念很好，但仔细想想，如果你已经有 Claude 这样的多模态模型 – 它能读 accessibility tree，能看截图，能理解页面语义 – 这层封装的价值就大打折扣了。
Claude 通过 Playwright MCP 拿到 a11y tree，天然就具备了"根据语义找元素"的能力。Stagehand 的 observe() 本质上就是 Playwright MCP 的 take_snapshot，extract() 就是在 snapshot 上跑一个 schema extraction。这些事情 Claude 裸做就行，不需要一个中间层。
当然，如果团队里没有 AI agent 的基础设施，这些框架提供了开箱即用的体验，有它们的价值。但对于已经在用 Claude Code + MCP 的工作流来说，直接用 Playwright MCP 更直接、更可控。
效率差距在哪里
写第一版测试代码，Cypress 和 Playwright 几乎没有差距。AI 对两个框架的语法都很熟，生成速度差不多。差距全部集中在 debug 和维护阶段 – 而这恰恰占了 E2E 测试生命周期 80% 的时间。
以我昨天的 Portal E2E 为例（登录、建 Project、建 HostingSource、部署、验证、清理，5 个 spec 文件），首次调通阶段：Cypress 每个 spec 要经过 3-5 轮人工 debug 循环，每轮 5-10 分钟看视频，一个 spec 调通要 30-50 分钟，5 个 spec 总计 3-4 小时人工时间。Playwright 同样 3-5 轮 debug，但 AI 自主完成，每轮 30 秒到 1 分钟，5 个 spec 总计半小时到一小时，而且大部分时间人可以去干别的。
持续维护阶段差距更大。前端改了一个按钮的 class name，3 个 spec 挂了。Cypress 要人看 3 个视频、定位问题、指导 AI 修复、再跑再看，1-2 小时。Playwright + MCP 让 AI 自己打开页面、定位新元素、改 selector、验证、提 PR，10-15 分钟，人只需要审核。
规模化之后，50 个 E2E 测试，Cypress 大约需要两周（人全程参与 debug），Playwright 大约三天（AI 自主 debug，人抽查）。AI 可自主完成的比例，Cypress 约 40%，Playwright 约 85%。
这不是 5 倍 10 倍的差距能概括的。本质上是两种不同的工作模式：Cypress 让人变成了 AI 的眼睛，Playwright 让 AI 自己长了眼睛。
循环能否闭合
所有这些差距归结为一个问题：AI 的 debug 循环能否闭合。
Playwright 的循环是闭合的：写代码、跑测试、读 trace、理解失败、改代码、跑测试 – 全程无人介入，AI 自己转。
Cypress 的循环是断裂的：写代码、跑测试、生成视频 – 到这里断了。AI 看不了视频，得等人看完描述给它，才能继续。每断一次，5-10 分钟人工时间，更关键的是上下文切换的成本。
昨晚的真实案例：cleanup spec 找不到 overflow 按钮导致全部 skip，某个 hosting 模块在集群里不存在但 API 返回 200。用 Cypress 的 debug 模型，我花了一整个 session 才理清因果链。如果是 Playwright + 双 MCP，AI 读 trace 看到 click 失败，通过 DevTools MCP 查 Network 确认 API 实际返回内容，通过 Playwright MCP 重新定位按钮，大概 15 分钟自主完成诊断。
这不是假设。这就是 “debug 产物是视频” 和 “debug 产物是结构化数据” 之间的实际差距。
不是框架过时，是 debug 模型过时
Cypress 的语法没什么问题，它的 chainable API 甚至比 Playwright 的 async/await 更直观。它的 Time Travel 调试（悬停在命令上看 DOM 快照）对人类开发者来说依然是最好的体验。
但"对人类最好"在 2026 年不再是唯一的评判标准。当你的开发循环里 AI 承担了 60-80% 的执行工作，框架的 AI 友好度就变成了和人类友好度同等重要的维度。
Cypress 不是一个差框架，它是一个为纯人类工作流设计的好框架，遇上了一个 AI 参与度越来越高的时代。视频录制、Cypress Cloud 付费并行、500MB 的安装包 – 这些都是为人类优化的产物。在 AI 时代，你需要的是轻量的结构化 trace、免费的原生并行、以及一套 MCP 接口让 AI 能直接操作浏览器。
这些，Playwright 都有。