「不用 selector」？脆弱只是换了个地方住

先说结论：这篇 dev.to 教程有真东西。但「不再依赖脆弱的 selector」？一半是解法，另一半是障眼法。脆弱没被消灭——它只是换了个地方住。

去年七月有人发教程，教 Cursor 配一个叫 BrowserAct 的 CLI，去自动化那些动不动就原地换皮的动态页面。开头的诊断我认：前端一更新，硬编码的 selector 失配，UI 肉眼看着没变，底下 DOM 早换了套骨骼。这痛，谁干谁知道。

解法是 inspect-act-reassess 循环。读状态，选动作，执行，等稳定，再读一遍，继续。

browser-act --session demo open
state → click → wait stable → fill → get markdown

这纪律，写 UI 自动化的人都熟。Playwright 的 locator 本来就自动重查，wait 一下，大半问题当场解决。BrowserAct 真正干的事，是把「定位」外包给 LLM——把页面可交互元素压成紧凑表示喂给模型，让它看活页面下决定。

「全程没写任何 CSS selector、ID 或 XPath，流程完整跑通。」演示里这句最有分量！搜索、开详情页、验证信息，全靠模型自己读状态自己下判断。这确实能跑，我认。

但「脆弱被消灭了」？没有。它只是换了个地址。

第一个代价是 token。每步都要重新拉状态，重新喂模型，重新推断。五步流程，状态读取十几轮起步。评论区逮着的也是这俩：成本，延迟。作者回了一条 shadow DOM 的质疑，说操作在浏览器层发生所以没关系——这解释站得住。但成本那条，他自始至终没给数。

第二个代价更阴。文章自己留了最后一步显式验证。理由：加载问题、认证问题、应用状态，都可能让前面的交互表面成功、实际失败。

这句是全文最诚实的一句！

等于亲手承认这套循环不信任自己——才需要兜底验证收尾。不用 selector 听起来很美。重复跑十遍不翻车？另一回事。

还有一句得记下。作者说不是来替代 Playwright 的，确定性场景该用 Playwright 还是用。主动把自己从「颠覆性方案」候选名单里摘了出去。一个博文作者说自己不颠覆，比通稿里连用三个「革命性」可信多了。

锐评评分卡：思路不冤。工具值得拿真实项目照一照。但记住，「不用 selector」不等于更便宜，也不等于更可靠。动态页面拿来练手可以。指望着测试全迁上去省事——趁早打住！