代码改完了，然后呢？应用到底构建成功没有，改完的页面长什么样，用户指的是哪个控件，点下去有没有进对页面——这些事，绝大多数编程智能体都管不着。

9 月 11 日，阿里 Qoder 推出 Mobile Use 插件（Beta），试图补上这段缺口。

智能体卡在”提交之前”

Qoder 官方对现状的描述很直接：今天的编程智能体已经能够修改安卓、鸿蒙与 iOS 的代码，但工作往往止步于代码提交之前的那一步。

修改能否编译通过、界面是否如预期渲染、交互路径是否正确，在传统流程里需要开发者自己打开模拟器、连上真机逐项确认。智能体写完了代码，验证环节却重新回到了人工。

Mobile Use 的定位就是把这个环节也交给智能体。据官方介绍，安卓、鸿蒙与 iOS 三端均可将代码修改接入应用运行，在设备上完成交互，再确认修改是否生效。

不搞”最低能力对齐”

值得注意的是，Qoder 并没有选择用一套最低能力把三个平台强行拉平。

原因并不复杂：三端的工程结构、构建工具、模拟器、测试框架和设备接口本来就完全不同。硬做统一，结果往往是能力被最弱的一端拖住。

Mobile Use 的处理方式是各走各的路——

• 安卓：沿用 Emulator、ADB 与 Instrumentation
• 鸿蒙：连接 DevEco Previewer、HDC 与 ArkXTest
• iOS：使用 Xcode Simulator、Accessibility 与 XCTest

平台差异交给各自的适配器处理，上层再通过统一的 Skill 与命令行工具，把这些能力暴露给智能体调用。

在 Qoder 看来，真正需要对齐的不是底层工具，而是更上一层的开发过程：观察、操作与验证。这也意味着开发者现有的开发环境可以继续沿用，不必另外准备一套专门给智能体使用的测试设备。

“不具备的能力会明说”

官方特别强调了一条承诺：如果某个平台或运行环境不具备某项能力，Mobile Use 会明确说明，而不会用一条不等价的命令冒充成功。

对依赖智能体自动验证的开发者来说，这句话的分量可能比功能清单本身更重。自动验证最怕的不是失败，而是”假成功”——命令跑通了、日志也干净，但实际上验证的根本不是同一件事。

编程智能体的竞争点正在后移

过去两年，编程智能体的比拼集中在”能不能写出能跑的代码”。随着代码生成质量趋于接近，竞争焦点正在向代码提交之后延伸：能不能自己构建、自己跑起来、自己截图比对、自己判断改动是否达成目标。

Qoder 此次把三端验证打通，方向上也属于这一轮延伸。需要说明的是，Mobile Use 目前仍是 Beta 版本，三端适配的完整度、真机连接的稳定性以及在复杂项目上的实际表现，还需要开发者在真实工程里检验。