做过 UI 自动化的人，都被选择器伤过。
按钮文案改了，测试挂；DOM 多套一层，测试挂；设计师把弹窗位置调了一下，测试挂；移动端 WebView 换了渲染方式，测试还是挂。最后你会发现，所谓“自动化测试”，有一半时间在维护测试自己。
这就是 web-infra-dev/midscene 值得关注的原因。它不是又一个 Playwright 包装器，而是把 UI 自动化的入口从“找到某个 CSS selector”改成“描述我要做什么”。仓库描述很直接：AI-powered, vision-driven UI automation for every platform。本次抓取时，它约 13,337 stars、1,004 forks，在 GitHub TypeScript Trending 中单日新增约 99 stars。
README 里的功能说明也很清楚：你可以用自然语言描述目标和步骤，Midscene 会规划并操作用户界面；脚本可以用 JavaScript SDK 或 YAML 写；Web 场景可以接 Puppeteer、Playwright，或者用 Bridge Mode 控制桌面浏览器；移动端则支持通过 adb 控制 Android，通过 WebDriverAgent 控制 iOS 设备和模拟器。
它的关键不是“完全不要代码”，而是把代码写在更稳定的位置。
传统 UI 自动化关注元素：#submit-button、.modal .confirm、data-testid=save。Midscene 更像关注意图：点击“保存”、确认弹窗、检查页面里是否出现错误提示。对于经常变化的界面，这种表达更贴近人类测试步骤，也更适合作为 Agent 的操作接口。
Midscene 还提供三类 API：Interaction API 用来操作界面；Data Extraction API 用来从界面和 DOM 提取数据；Utility API 包括 aiAssert()、aiLocate()、aiWaitFor() 这类辅助能力。再加上它提供 MCP 服务，可以把 Midscene Agent 的原子动作暴露成 MCP tools，让上层 Agent 用自然语言检查和操作 UI。
这就很适合一个实际工作流：
第一层，仍然保留 Playwright 这类确定性测试，覆盖核心路径。它们快、稳定、适合 CI。
第二层，用 Midscene 写“高变化界面”的冒烟测试，比如后台管理系统、运营配置页、活动页面。这些地方 DOM 变化频繁，但人类验证步骤相对固定。
第三层，把 Midscene MCP 接给 coding agent。当前端改完一个页面，Agent 可以自己打开页面，执行“登录、进入订单页、筛选状态、确认列表出现数据”这类动作，再根据截图和断言结果决定是否继续修。
当然，视觉驱动不等于银弹。它会更依赖模型稳定性，也可能比纯选择器测试慢。对支付、权限、数据删除这类高风险流程，仍然应该用更确定的自动化脚本和人工审查兜底。
但趋势已经很明显：UI 自动化正在从“机器读 DOM”走向“机器理解界面”。选择器不会消失，只是它不该再承担所有认知负担。
如果要在团队里试，建议先选最烦但风险最低的流程：例如后台筛选、表单录入、运营配置预览。这些场景变化多、人工验证频繁、出错后损失可控，非常适合用视觉自动化补位。等稳定后，再考虑把部分脚本接进 CI 或交给上层 Agent 调用。不要一上来就碰支付、删除、权限这种高风险链路。