自动化的入口变了，验收标准不能跟着变
最近掘金首页的推荐里，AI 编程、Skills / MCP 工作流和自然语言驱动 Android 操作都很活跃。以 Google 开源的 ARTEMIS 为例，它尝试让 Agent 根据自然语言目标观察手机界面、规划操作并执行任务。
这类工具让写 UI 脚本的门槛降低了，但"Agent 点完了"不等于"测试通过了"。真正需要重新设计的，是任务描述和结果验收。
1. 把测试目标写成可检查的条件
"帮我测试登录"太宽泛。Agent 可能走了不同路径，也可能只看到页面变化就认为成功。更好的任务描述应包含：
- 前置状态：使用测试环境和专用账号，App 已安装，当前处于退出登录状态。
- 操作范围：输入指定测试凭据并点击登录；不修改账号资料，不触发真实交易。
- 成功条件：进入首页、登录态标识出现，并且关键接口返回符合预期。
- 失败证据：保留失败步骤、截图和可用日志，明确指出哪条条件未满足。
目标越可观察，Agent 越容易执行，结果也越容易复核。
2. 让 Agent 探索，让断言守住底线
传统 UI 自动化擅长重复执行稳定路径：定位明确、耗时可控、断言清晰。Agent 更适合探索界面、跨页面完成任务、复现不固定的操作路径。两者不是简单替代关系。
一个实用组合是：让 Agent 负责探索或生成操作步骤，再把稳定、重要的场景沉淀为可重复脚本；关键结果继续使用确定性断言，例如页面状态、接口响应或数据变化。对登录、支付、删除等高影响流程，必须在隔离测试环境里验证，并限制可操作范围。
3. 验收整条执行链，而不只看最终一句话
评估 Agent 自动化时，可以持续记录四件事：
- 完成率：同一任务多次执行是否稳定。
- 证据完整度：失败时能否定位到具体步骤，而不只是返回"未成功"。
- 恢复能力：遇到弹窗、加载延迟或页面变化时，能否安全重试或及时停止。
- 成本与时延：模型调用的耗时和费用，是否适合进入日常回归。
如果只看一次演示成功，很容易高估工具能力。把任务重复跑、保留过程证据，再和现有脚本对照，才能判断它适合探索测试、冒烟检查，还是可以进入更严格的流程。
小结
自然语言让移动端自动化更容易上手，但不会自动带来可信结果。目标要具体，动作要有边界，关键结论要能被独立验证。Agent 可以负责"怎么走"，测试体系仍要回答"凭什么算通过"。
参考：