自愈的 Playwright 测试，CI 里不跑任何模型

你把一个按钮从 "Save" 改成 "Save changes"。下次 CI 一跑，六个 spec 全红了。它们各自在走到要检查的地方之前都点过这个按钮，于是全卡在同一步。没有一个抓到 bug，抓到的只是你这次改名。

两条出路，条条都是白费力气。要么挨个打开文件，手动改 locator。要么删掉 spec 重录一遍——为了修坏掉的那一步，把还好好的十二步一起扔掉。

找出走偏的那一步

Hover 把录好的步骤对着运行中的应用回放，停在第一个再也解析不出来的步骤上。replay_spec 会读取 sidecar——每个 spec 旁边那份记录了 grounded 步骤的档案——在你的实时页面上逐步跑一遍，再点出走偏的那一步：第 4 步，getByRole('button', { name: 'Save' })，什么都没匹配到。哪一行出了问题、应用在底下动过了，你一清二楚。

然后在你自己的 agent 里跑 /mcp__hover__heal <spec>。它会在那一步给页面重拍一张快照，找到如今承载相同含义的控件（也就是被改标成 "Save changes" 的那个按钮），只重新 ground 这一步，其余原封不动。接着重新 crystallize 这份 spec，把一个只改了一处 locator 的 git diff 交到你手上。

为什么不让模型在测试跑的时候临时重新解析 selector

循环里挂着模型，每跑一次 CI 都要收你一笔推理费——连那些根本用不上它的绿色构建也不例外。Hover 愈合后的 spec 就是普通 Playwright，CI 跑它时循环里没有 agent。模型调用只花一次，就在契约变动的那一刻，落在一个你提交前会读的 diff 里。

愈合刻意留红的部分

愈合有一条刻意划下的界。如果某一步失败是因为流程本身坏了——比如 Save 按钮现在不再保存，而是抛出错误——重新 ground 找不到等价的控件，spec 就保持红色。这抹红是你应用里一个货真价实的 bug。愈合循环要是自动把它抹平，也就抹掉了你留着这套测试的理由。

CI 驱动的愈合——由 Hover 从一次红色运行直接开出一个修复 PR——还在路线图上。眼下，你在编辑器里愈合，读 diff，然后提交。

阅读自愈文档 →