Selector Forge 实战:用 AI 一键生成可靠的 CSS/XPath 选择器,告别脆弱测试代码
做 UI 自动化测试或网页爬虫的开发者都遇到过这种场景:辛苦写好的 CSS 选择器,一次前端重构后全部失效。div.content > ul.list > li:nth-child(3) > a.btn-primary 看起来很精确,但只要 class 名改一下、结构多一层 wrapper,所有测试瞬间变红色。
这不是你的错——手动编写选择器本身就是一种脆弱的逆向工程。你把 HTML 结构的每一层都写进了选择器,但前后端并不会通知你「我们改了 class 名哦」。
Selector Forge 是一个 MIT 许可的开源浏览器扩展(Chrome 和 Firefox),它用 AI 自动生成经过浏览器真实 DOM 验证的 CSS 和 XPath 选择器。你只需要点一下页面上的元素,剩下的交给它。
安装:一个扩展搞定
Selector Forge 已经上架两家商店,无需配置、无需 API Key:
- Chrome:Chrome Web Store 安装
- Firefox:Firefox Add-ons 安装
安装后,浏览器工具栏会出现 Selector Forge 的图标。点击即可打开选择器面板。
信任边界:AI 提议,浏览器验证
这是 Selector Forge 最核心的设计——AI 只负责出主意,浏览器才是裁判。每次候选选择器生成后,扩展都会在当前页面的真实 DOM 上测试,确认它真正匹配到预期的元素数量。如果某个选择器在 DOM 上匹配到了错误数量的元素,它会被丢弃,循环继续。
这意味着你拿到的每个选择器都是在实时页面上验证过的,不是 AI 凭空生成的假设。
两种选择模式
Selector Forge 提供两种模式,覆盖了绝大部分场景:
| 模式 | 操作 | 结果 |
|---|---|---|
| Single(单个) | 点击页面上的一个元素 | 返回该元素的多个候选选择器(CSS + XPath) |
| List(列表) | 点击同一个重复组中的两个示例元素 | 返回能匹配整个列表组的容器选择器 |
场景 1:Single 模式——五秒钟定位一个按钮
假设你需要帮 Playwright 测试定位「提交订单」按钮。用 Selector Forge:
- 打开目标页面,点击扩展图标
- 选择 Single 模式
- 直接在页面上点击「提交订单」按钮
- 扩展弹出面板展示验证过的候选选择器,每个带复制按钮
你得到的选择器可能长这样:
// XPath 方案 //button[contains(@class, 'submit-btn') and text()='提交订单'] // CSS 方案 button.submit-btn.order-cta
关键区别在于,这些候选已经在当前 DOM 上跑过一遍验证,不是你凭空推断的。如果你要的是最稳定的选项,选 ID 或 data-* 属性的版本最可靠。
场景 2:List 模式——一次性搞定重复元素
更常见的需求是抓取重复列表——商品卡片、搜索结果、表格行。手动写 ul.products > li:nth-child(n) 不仅容易断裂,而且列表项数量一变就要改代码。
用 List 模式:
- 打开目标页面,点击扩展图标
- 选择 List 模式
- 点击第一个元素和第二个元素(比如两个商品卡片)
- 扩展分析它们的共同父容器和结构相似性
- AI 生成候选容器选择器,浏览器验证它是否匹配页面上所有同类元素
- 面板展示验证过的容器选择器,还会预览匹配了哪些元素
拿到容器选择器后,你可以在 Playwright 或 Puppeteer 中这样用:
// Playwright 示例
const containerSel = 'div.product-grid > div[class*="card"]';
const items = await page.locator(containerSel).all();
for (const item of items) {
const title = await item.locator('h2').textContent();
const price = await item.locator('.price').textContent();
console.log({ title, price });
}
因为容器选择器已经在真实页面上验证过能匹配所有预期元素,你在代码中直接用它,出问题的概率远低于手动编写。
从源码构建与开发
如果你需要定制或扩展 Selector Forge 的功能,它的源码基于 TypeScript + WXT 框架,构建流程很标准:
git clone https://github.com/Intuned/selector-forge.git cd selector-forge yarn install # 安装依赖,同时运行 wxt prepare yarn dev # 开发模式,自动监听变更
构建产物在 .output/chrome-mv3/ 目录下。在 chrome://extensions 中打开开发者模式,选择「加载已解压的扩展」指向该目录即可。
项目提供了几类测试保证质量:
yarn test # 单元测试 + 浏览器模式测试(真实 DOM 验证) yarn e2e # 端到端测试(Playwright + 打包后的扩展) yarn ladle # 组件预览模式,在 http://localhost:61010 预览弹出 UI
实际使用技巧
优先选 data-* 属性选择器
如果你的目标页面上有自定义 data 属性(如 data-testid, data-cy, data-id),Selector Forge 会优先把它们纳入候选。这类属性选择器在测试中最稳定,因为它不依赖 class 名或 DOM 层级——只要 HTML 属性不变就能工作。
XPath 更适合复杂定位
CSS 选择器无法基于「文本内容」或「兄弟元素关系」来定位,而 XPath 可以。如果你的场景需要:
// 找到「立即购买」后面的「加入购物车」按钮 //button[contains(text(),'加入购物车')]
Selector Forge 会同时给出 CSS 和 XPath 两种候选方案,你按需选择。
用于断言而非全部替换
即使你已经在用 AI 编码工具生成测试代码,Selector Forge 仍然有独立价值——AI 生成的代码经常包含虚构的选择器(hallucinated selectors)。用 Selector Forge 拿到的选择器是经过 DOM 验证的,可以混合到 AI 生成的测试代码中作为断言定位器,把测试的可靠性提高到另一个层级。
注意事项
- 需要网络连接:选择器生成依赖 Intuned 的后端 API(AI 推理部分)。离线不可用。
- 免费使用上限:基础使用免费,但在 Intuned 上注册后可获取更多配额。当前无付费墙。
- CLI 集成在路上:项目 Roadmap 中规划了 CLI 驱动能力,届时可以直接从终端脚本中调用 Selector Forge 获取选择器。
- 自定义后端:项目长期规划了自托管后端能力——目前依赖 Intuned 服务,后续会开源可替换的后端参考实现。
总结
Selector Forge 解决的不是「怎么写出选择器」的问题,而是「怎么确保写出来的选择器是对的」的问题。将 AI 生成的候选与浏览器 DOM 的实时验证结合,让 E2E 测试和网页爬虫的 selector 部分有了一个可靠的自动化工具。
如果你写过哪怕一次 waitForSelector 测试然后因为 UI 改版而重写,Selector Forge 都值得花 30 秒装上试试。
- GitHub:github.com/Intuned/selector-forge
- Chrome 商店:安装链接
- Firefox 附加组件:安装链接