Stagehand：把 H5 验收流写成可控的 AI 浏览器脚本

如果你刚写过 Playwright 或 Selenium，用过一阵就会遇到同一个问题：页面只是换了一个 DOM 层级，选择器就开始抖；但如果完全交给一个黑盒浏览器 Agent，又很难解释它为什么点了某个按钮。

Stagehand 更适合放在这两者中间。官方文档把它定义为一个用自然语言和代码控制浏览器的自动化框架，核心是把 AI 的灵活性和代码的确定性组合起来。它提供四个原语：act 执行动作，extract 按 schema 抽取结构化数据，observe 在页面上发现可操作项，agent 执行完整工作流。

对 QA 来说，不要把它理解成“AI 自动测试平台”。更务实的用法是：把一条 H5/后台页面的验收路径写成可控脚本，让 AI 处理页面变化和自然语言定位，让 QA 保留断言、测试数据和发布门禁的控制权。

适合的 QA 工作类型：UI 测试、H5/后台验收、跨页面数据核对、页面结构变化后的脚本维护。

AI 直接参与的测试动作：根据自然语言指令执行点击、填写、导航，或抽取页面结构化数据，再由 QA 断言。

真实场景：后台配置页改了，QA 要快速验收

比如运营后台新增了一个“自动续费提醒”的配置开关。QA 要验证：进入配置页、打开开关、保存、刷新、确认状态还在，并且页面上的提示文案和实际状态一致。

原来的做法通常是：

1. 手动点一遍主流程。
2. 录屏或截图留证据。
3. 如果要自动化，再写选择器和等待策略。
4. 页面结构改一次，脚本就修一次。
5. 失败时再追 Network、console、页面状态。

Stagehand 介入后，最小工作流可以变成：QA 写清验收目标，observe 看页面上有哪些可操作项，act 执行点击和填写，extract 抽取保存后的状态，最后由 QA 审查断言是否足够业务化。

最小验证路径

不用先接完整回归平台。选一个低风险页面，控制在 10-30 分钟内验证。

可以先从官方仓库给的启动方式开始：

npx create-browser-app

然后只做一条路径：

打开测试环境配置页，找到“自动续费提醒”开关，打开并保存。保存后抽取页面里的开关状态、提示文案和更新时间，输出给 QA 审查。

第一次验证不要追求“全自动发布门禁”。你只看三件事：

1. observe 给出的可操作项是否符合页面真实结构。
2. act 是否能稳定执行主路径。
3. extract 抽出的结果是否足够 QA 做业务断言。

提效点拆解

第一，少维护脆弱选择器。

官方说明里强调，Stagehand 能用自然语言指令处理页面变化，同时仍保留代码控制。对 QA 来说，这意味着不用每次 DOM 轻微变化都改一堆 selector。

第二，少手工抄页面信息。

后台验收常见任务不是只点按钮，而是核对保存后的状态、金额、文案、时间、列表行。extract 可以把页面内容抽成结构化对象，QA 再判断字段是否对。

第三，少丢失败证据。

脚本里应固定保存输入、操作步骤、抽取结果和截图。失败时不是只说“点不动”，而是能带着页面状态和抽取结果开缺陷。

第四，少把 AI 当黑盒。

Stagehand 的关键不是 agent 一把梭，而是 observe -> act -> extract -> assert。QA 能看到每一步做了什么，才敢把它放进冒烟链路。

QA 必须人工校对什么

第一，断言要业务化。

“按钮可点击”不是验收通过。真正要看的是保存后状态是否持久、刷新后是否一致、接口和页面是否一致。

第二，测试数据要隔离。

配置页、订单页、权益页不能随便在共享环境里乱改。要有测试账号、可回滚数据或沙箱环境。

第三，AI 操作不能越权。

如果页面上有删除、退款、发券这类动作，脚本必须加白名单和确认步骤，不能让自然语言指令直接执行高风险操作。

适合和不适合

适合：H5 主流程验收、后台配置核对、无稳定 API 的页面数据抽取、选择器频繁变化但流程相对固定的页面。

不适合：支付、退款、批量发券这类高风险操作；业务断言不清楚的需求；没有测试数据隔离的共享环境。

总结

Stagehand 对 QA 的价值不是取代 Playwright，而是把“自然语言定位 + 结构化抽取 + 可审查代码”放到同一条验收路径里。

如果你现在的问题是：页面经常变、选择器经常坏、手工验收证据经常散，Stagehand 值得用一条低风险 H5 流程试一下。

官方资料

• Stagehand 官方文档
• Stagehand 官网
• Stagehand GitHub