我在 2 小时内修复了 110 个失败的 E2E 测试，且未编写一行测试代码
Source: Dev.to
110 个失败的 Playwright 测试。登录流程、多步骤表单向导、搜索过滤器、文件上传、复杂的用户工作流。有些失败是因为缺少 UI 步骤，有些是上一次运行留下的脏状态，还有些是过时的选择器。我在 2 小时内全部修复，且没有编写任何测试代码。
我构建了一个 playwright‑autopilot 插件来实现这一点。
调试工作流的实际运行方式
当你通过插件运行测试时，一个轻量级的捕获钩子会注入到 Playwright 的工作进程中。它会对 BrowserContext._initialize 进行猴子补丁，添加一个仪器监听器——无需修改 Playwright 的源代码，能够兼容任何已有的安装。
从此以后，所有浏览器操作都会被记录：
- DOM 快照 – 在每一次点击、填写、选择和导航前后，捕获页面的完整 ARIA 树。当测试失败时，你可以看到失败瞬间以及前一步的页面状态。
- 网络请求 – 包括 URL、方法、状态码、时序、请求体、响应体。你可以按状态码（例如 400+）、URL 模式或方法进行过滤。
- 控制台输出 – 错误、警告和日志会与产生它们的具体操作关联。输出范围限定在相关步骤，而不是一大堆文本。
- 截图 – 在失败点自动截取。
AI 并不会一次性倾倒所有这些数据。它基于 MCP（模型上下文协议），按需拉取数据：先是操作时间线，然后是失败的步骤，接着是 DOM 快照、网络响应和控制台日志。由于有 32 种工具只返回必要信息，设计上保持了 token 的高效利用。
它以用户流程思考，而非选择器
在触及代码之前，代理会映射预期的用户旅程（例如，“用户登录，填写多步骤表单，上传文件，提交”）。它会走一遍真实用户会执行的步骤，并将其与测试实际执行的内容进行比较。
当某个步骤缺失——下拉框未被选择，必填字段未填写，单选按钮未点击——代理会在你的代码库中找到已有的页面对象方法并添加调用。没有新的抽象，差异最小。
它遵循您的架构
- 兼容页面对象模型（Page Object Model）、业务/服务层，或您团队使用的任何模式。
- 使用
getByRole()、getByTestId()、以 Web 为先的断言。 - 避免使用
page.evaluate()hack、waitForTimeout，或在 Playwright 操作周围使用try/catch。
如果应用本身出现故障（例如 500 错误、未处理的异常），插件会直接报告这些问题，而不是尝试规避它们。
它学习并记忆
在测试通过后，插件会自动保存已验证的用户流程——即构成理想路径的完整交互序列。下次该测试出现错误时，代理已经了解预期的旅程，能够直接跳到识别变化的步骤。
只需在整个测试套件上运行一次 e2e_build_flows，即可捕获每个测试的旅程；随着时间推移，代理的速度会越来越快。
一个真实的例子
一次结账测试因 “定位器解析到隐藏元素” 而失败。常规的调试步骤：
- 打开 trace viewer。
- 找到失败的步骤。
- 查看 DOM。
- 发现从未选择国家下拉框，导致运输部分未渲染。
对于有经验的开发者，这可能需要约 20 分钟。
插件在一次运行中找到了相同的根本原因。它在失败步骤获取了 DOM 快照，在 ARIA 树中看到未选中的下拉框，搜索页面对象中的 selectCountry()，在服务层加入该调用，重新运行测试，测试通过。一次修复，约 12 秒的 AI 处理时间。
开始使用
# Add the marketplace entry
/plugin marketplace add kaizen-yutani/playwright-autopilot
# Install the plugin
/plugin install kaizen-yutani/playwright-autopilot
# Then prompt the AI
Fix all failing e2e tests尝试一下：https://github.com/kaizen-yutani/playwright-autopilot – 给仓库加星，在你最脆弱的测试上运行它，并告诉我们哪里出问题。