Midscene.js：用截图和自然语言替代选择器的 UI 自动化测试框架
适用于每个平台的人工智能驱动、视觉驱动的 UI 自动化。有两种测试方法，将 Midscene 添加到您的 Playwright / Vitest 套件中，或者让 AI 代理通过技能进行自主测试。
秒懂
- 它是什么？
- Midscene.js 是一个基于视觉驱动的 UI 自动化测试框架，它只依赖截图和多模态模型，无需维护 CSS 选择器。本文分析其工作原理、接入方式、适用场景与局限。
- 适合谁用？
- Midscene.js 适合那些深受选择器维护之苦、需要覆盖 canvas 或跨域 iframe 等非语义化界面的测试团队。它不适合预算有限、无法为多模态模型调用付费的团队，也不适合对每次交互延迟有严格要求的场景。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
选择器维护是痛点，Midscene 的选择是彻底绕开
传统 UI 自动化依赖 DOM 结构或 accessibility tree。每次前端重构，选择器就可能失效，icon-only 按钮和 canvas 内的元素更是难以定位。Midscene.js 的核心立场是：只从截图出发，用自然语言描述操作目标。这意味着你不需要写 CSS 选择器或 XPath，也不需要给元素补充语义化标记。它面向的是 UI 测试工程师和需要跨平台自动化的团队，尤其是那些被选择器维护拖累、或者需要测试原生应用和 iframe 内内容的场景。
视觉定位的机制：从截图到坐标
Midscene.js 的定位完全基于截图。它调用多模态模型，如 Qwen3.x、GLM-4.6V 或 gemini-3.5-flash，让模型理解截图中的元素位置并返回坐标。你只需要描述“点击登录按钮”，模型会找到按钮在图片中的位置，然后驱动浏览器执行点击。对于数据提取和页面理解，你仍然可以选择性地引入 DOM 信息，但默认路径是纯视觉。这种设计的直接好处是：如果人类能看到，Midscene 就能操作，无论元素是否具有语义标记。但这也意味着每次交互都需要一次模型推理，延迟和成本都高于传统选择器。
两种接入方式：测试套件与自主 Agent
Midscene.js 提供了两种使用模式。第一种是集成到现有的 Playwright 或 Vitest 测试套件中，你可以在测试脚本里创建 Agent，用自然语言编写操作步骤。第二种是通过 Midscene Skills 结合 OpenClaw 实现自主测试，AI Agent 可以独立执行任务，比如自动填写表单并通过所有字段验证。前者适合在 CI 中跑回归测试，后者适合探索性测试或需要快速验证的场景。两种方式共享同一个视觉驱动引擎，但 Skills 模式更强调自主性，你不需要预先编写完整的脚本。
快速上手：从 Chrome 扩展到第一个脚本
官方文档提供了两条起步路径。最简单的做法是安装 Chrome 扩展，配置模型后直接在浏览器里执行自然语言指令。如果你要写脚本，可以安装 Playwright 或 Puppeteer，然后创建一个 Agent，运行完整的浏览器自动化。示例代码在 midscene-example 仓库中。核心 API 包括 aiAct、aiQuery、aiAssert，分别用于执行操作、提取数据和断言。具体配置方法需要查阅官方文档，但基本流程是：初始化 Agent，传入模型配置，然后调用这些方法。注意，你必须自己准备模型 API 的访问凭证，Midscene 不负责托管模型。
跨平台能力与边界
Midscene.js 声称支持任何能截图的界面，包括 Android、iOS、HarmonyOS 和桌面应用。它通过 scrcpy 控制 Android，通过 WebDriverAgent 控制 iOS，底层依赖这些项目的桥接。这种设计让同一套 API 可以覆盖不同平台，但每个平台的接入都需要额外的配置和依赖。一个明显的边界是：截图驱动的视觉模型在复杂或动态页面上可能产生不稳定的定位，尤其是当页面元素频繁变化时。此外，模型对截图的解读存在误差，特别是在小尺寸元素或高密度信息界面上。如果你需要像素级精确的点击，视觉定位可能不如传统坐标来得可靠。
模型依赖与成本考量
Midscene.js 的定位质量完全取决于所选的模型。它支持商业模型如 gemini-3.5-flash，也支持开源模型如 UI-TARS，后者可以自托管。选择开源模型可以避免按调用付费，但你需要自己部署推理服务，这涉及 GPU 资源和运维成本。模型策略的文档建议根据场景选择模型，但具体如何评估需要你自行实验。一个实际问题是：如果模型在某个页面上定位失败，你可能需要调整提示词或切换到更强的模型，这增加了调试的复杂度。对于预算有限的团队，频繁的模型调用可能成为新的成本中心。
维护成本与许可证
Midscene.js 采用 MIT 许可证，这意味着你可以自由使用、修改和分发，甚至用于商业项目，无需开源你的代码。社区提供了多个扩展，如 midscene-pc 用于桌面操作，Midscene-Python 提供 Python SDK，但这些都是第三方维护，质量参差不齐。升级成本方面，项目最近更新频繁，v1.12.2 在 2026 年 8 月 28 日发布，说明 API 可能还在快速演进。你需要关注版本兼容性，特别是当你使用 Playwright 集成时，版本更新可能引入破坏性变更。官方文档和示例项目是主要的维护资源，但社区支持主要依赖 Discord 和 X。
编辑结论
Midscene.js 适合那些深受选择器维护之苦、需要覆盖 canvas 或跨域 iframe 等非语义化界面的测试团队。它不适合预算有限、无法为多模态模型调用付费的团队，也不适合对每次交互延迟有严格要求的场景。在采用前，先验证你选定的模型（如 Qwen3.x、GLM-4.6V 或 gemini-3.5-flash）在你的目标页面上的定位准确率，并确认你的测试环境允许截图数据发送到模型服务。若使用开源模型自托管，需要额外评估本地推理的硬件成本和延迟。最终判断：Midscene.js 的纯视觉路线是真实的范式转变，但它把测试的稳定性从选择器转移到了模型质量上，这是你必须接受的交换。
社区笔记