AI 原生移动测试：它在 2026 年的真实含义

I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have that, I’ll provide a Simplified‑Chinese translation while keeping the source link and all formatting exactly as you requested.

传统移动 UI 测试的问题

• 测试使用硬编码的元素 ID 或 XPath 选择器编写。
• 细微的 UI 变动——重命名资源 ID、将按钮移动到 BottomSheet、微调动画时长——都可能在一夜之间导致数十个测试失效。
• 工程团队需要花费整个冲刺周期来修复本应正常工作的代码对应的测试。
• 测试维护的成本往往超过了测试捕获的 bug 所带来的价值。

过去十年里，主流的解决方案是“更好的选择器”：可访问性 ID、稳定的资源路径、页面对象模式。然而根本问题仍在——一个测试如果写成 “tap the element with id btn_login”，就把测试与不应出现在测试契约中的实现细节耦合在一起。

什么是 “AI‑Native”

真正的 AI‑native 测试工具让 AI 成为 编排者，而不仅仅是一个润色层。具体来说，测试框架向 AI 提供：

1. 当前屏幕（截图 + 以纯文本形式解析的 UI 树）
2. 目标描述（例如，“使用这些凭据登录”）
3. 可用操作列表（点击、输入、滑动 等）

随后 AI 会一步步决定该怎么做——不使用 selector、不使用硬编码 ID、也不使用 XPath。它查看屏幕，看到一个标有 “Login” 的按钮靠近用户名字段，就点击它。如果按钮的背景在下一个版本中改变或移动了 80 px，AI 仍然看到 “Login” 并点击它，使测试保持通过。

Drengr：模式的实现

drengr 是一个单一的 Rust 可执行文件，向任何支持 MCP 的 AI 客户端（如 Claude Desktop、Cursor、Windsurf）公开三个动词：

这就是全部的接口：三个动词，没有 XPath，也没有需要保持运行的 Appium 守护进程。

当 AI 成为编排者时的转变

1. 几乎零测试维护 – 测试提示（例如 “使用 test@example.com / pw123 登录并验证进入仪表盘”）很少变化。UI 调整不再导致测试失效。
2. 更广泛的受众 – 那些负担不起专职 QA 工程师的独立开发者和小团队，现在只需支付 Claude 或 Cursor 订阅费用，就能依赖 AI 原生层。

参见 “Field Notes” 了解 drengr 架构如何与学术研究结果相匹配。

超越测试：新 AI‑代理用例

相同的 drengr_look / drengr_do / drengr_query 原语让用户设备上的 AI 代理能够：

• 当用户说“带我回家”时打开地图并开始导航
• 滚动浏览 Instagram 并报告赞助内容
• 为有运动障碍的用户在银行应用中支付账单
• 执行任何长尾的“你会让人工助理在手机上完成的事情”

移动 QA 是最早的受众，因为痛点在这里最为突出，但 AI‑代理构建者市场要大得多。如果你正在构建任何需要 AI 控制真实移动设备的东西——测试、可访问性、个人助理，或是尚未想象的场景——控制层是你不想从零开始编写的部分。(完整论点：“AI 能浏览网页，为什么不能点触手机？”)

开始使用 Drengr

drengr 是免费的。通过 Claude Code 使用一条命令安装它，然后用第二条命令进行验证：

claude mcp add drengr -- npx -y drengr mcp
drengr doctor

将你的代理指向任何 Android 设备或 iOS 模拟器，观察模型的行为——无需 XPath、无需选择器，也不必在数十个测试文件中维护 find_element(By.ID, "btn_login")。

结论

AI‑native 意味着 AI 驱动 测试，而不仅仅是辅助。通过向 AI 提供屏幕视图、目标描述和一组操作，像 drengr 这样的工具消除了脆弱的选择器，降低了维护成本，并将移动自动化向更广泛的受众开放。这就是 AI‑native 应该表达的含义。