四种测试，没有一种在运行时用 AI

真实的应用会以不止一种方式坏掉。结账流程点不动了。布局错位，发票看着不对。某个接口开始对未登录用户返回 500。一个表单丢了 label，屏幕阅读器用不了。四种失败，四种测试：端到端、视觉、API、无障碍。

新一代 AI 测试工具有一点是对的：你不该为这四种各配一个工具。它们里有些走偏的地方在于怎么统一——让模型在测试运行时参与，每跑一次都"自愈"。这是拿一个问题（工具太多）换了个更糟的：现在每次 CI 都要仰仗一个 LLM 的判断，而它不确定、每跑一次都花钱，还可能悄悄把一个真回归判成"没问题"、直接愈合过去。

Hover 也覆盖这四种类型。没有一种跑模型。

四种类型，每种都确定性

• E2E——录制的用户流程。agent 在你真实的应用里把结账走一遍，Hover 把这些确切点击结晶成一份纯 @playwright/test spec。回放就是那段录制，不是重新解读。
• API——请求契约。状态码、返回结构、未登录调用者必须收到的 401。抓自你应用本就发出的流量，锁成断言。
• 视觉——用 Playwright 的 toHaveScreenshot 建截图基线，对着已提交的图做像素比对。变了就是变了；没有模型来判定新像素"够接近了"。
• 无障碍——axe-core 扫描。规则引擎按 WCAG 检查：ARIA、对比度、键盘可达。碰到 serious 和 critical 级违规就失败，并点名到具体元素。

其中两种是 Hover 新增的；四种如今并排住在 __vibe_tests__/{e2e,visual,api,a11y}/，业务地图给每种类型打上标记——你能按业务线看清它被哪几类测试守着。

为什么"运行期无 AI"才是全部重点

一个每跑一次就愈合你测试的 AI，也就是一个能替你把回归藏起来的 AI。登录按钮挪了位置、模型"适应"了，挺好。可要是登录按钮是被人改坏了才挪的，模型照样适应——于是你的测试在一个坏掉的应用上照样变绿，你只能等用户来告诉你。

像素比对没法被说服。axe 没法被劝退一个对比度问题。一次录好的点击，要么落在控件上、要么没有。这正是你想从测试身上要到的性质：它在所守护的东西坏掉时失败，且只在那时失败。AI 在写这些测试时极其有用——探索你的应用、决定什么值得锁住；但它不该变成测试本身。

怎么用

从你已经在用的编码 agent 里：crystallize_visual_spec 给那些外观要紧的页面，crystallize_a11y_spec 给那些必须保持可访问的页面，和你本就在录的 E2E、API spec 并排。它们都落成纯 Playwright 进你的仓库、在你的 CI 里跑——a11y 的工作流会替你把 @axe-core/playwright 装好。

四种类型，一套你拥有的套件。代码和裁决之间，没有模型。

npm i -g @hover-dev/mcp@latest。更多见 gethover.dev。