AI 会写 App 了,谁来确认它真的能用?

一次移动端 AI 编程工具调研，以及我们准备做什么

设想一次很普通的需求：给登录页增加一个“忘记密码”入口。Coding Agent 修改了界面，补好了跳转，构建通过，最后回复：“已完成，验证通过。”

但作为移动开发者，你可能还要亲自打开模拟器，找到那个页面，点一下按钮：入口有没有被键盘挡住？跳转后能不能返回？大字体下有没有挤掉文案？另一种系统版本上会不会崩溃？代码已经改完，确认改动是否正确的工作还在继续。

当 AI 越来越擅长写代码，移动开发更值得追问的一件事是：谁来确认这个 App 真的能用？

01 从代码到手机，中间还有一条长链路

我们围绕这个问题，梳理了主流 Coding Agent、平台厂商文档、开源移动工具和相关研究。原始调研以 2026 年 10 月 7 日的公开资料为快照；本文对关键数据和平台能力做了补充核对。

这里反复出现一个词：Harness。可以把它理解为 Agent 的工作环境：有哪些工具可用，怎样拿到上下文，如何执行任务，以及如何收到足够可靠的反馈。模型负责推理，Harness 帮它接触代码之外的真实世界。在移动端，这个世界至少包括编译工具链、模拟器或真机、应用状态、界面交互、日志，以及不同设备配置。一次改动通常要经过：

修改代码 → 构建 → 安装与启动 → 观察和操作 → 检查结果 → 带着证据决定是否通过。

任意一环接不上，都可能让反馈失真。构建失败可能来自 SDK 配置，点击无效可能是旧页面或过期坐标，画面正常也可能掩盖数据没有保存的问题。Harness 需要把这些情况区分开，才能让下一次修改有依据。

02 设备入口正在补齐，完整闭环仍要继续建设

移动端的工具生态已经有了不少进展。Apple 在 Xcode 的官方发布说明中，已经描述了 Agent 启动模拟器、安装和运行应用、合成触摸事件与截图验证的能力。[1] Google 的 Android CLI 也覆盖环境配置、虚拟设备管理、应用安装、实时屏幕和 UI 层级读取，并通过 Journeys 提供自然语言驱动的交互检查。[2][3]第三方工具同样在推进这件事：Maestro 提供流程与断言，Mobile MCP 提供设备自动化接口，MobileBuildMCP 连接构建和设备工作流。[4][5][6]所以，我们关心的问题逐渐变成了：这些能力怎样组合成一条可靠、可复查的开发闭环？

能执行一次点击，只能说明输入到达了设备。能取得一张截图，只能说明拿到了某一刻的画面。要判断这次改动是否完成，还需要知道预期结果是什么、检查覆盖了哪些路径，以及判断依据在哪里。

对于不少通用 Coding Agent，移动专项能力仍要依靠平台工具、插件和项目测试拼接起来。这也解释了为什么同样一句“帮我修好”，放到不同工具环境、不同项目和设备上，完成体验会有很大差别。

03 构建成功和任务完成，是两种结果

有一组研究数据，很适合说明这段距离：OpenHarmony Bench 的原论文，在同一个实验配置下报告：DevEco Code 搭配 GLM-5.2，最终构建成功率为 98.04%，任务完成率为 58.39%。 这组结果来自 153 个任务、三次独立全套运行的均值；“任务完成”还要求该任务的全部可执行检查通过。[7]

图 2｜数据据原论文表 4 重绘。平台为 OpenHarmony，配置为 DevEco Code + GLM-5.2；

接近全部能构建，和完成用户要求之间，仍然有明显距离。这是一个特定基准上的观察，不能直接换算成 Android、iOS 或整个行业的成功率；它足以提醒我们，编译结果只能回答一部分问题。

Google 的 Android Bench 2.0 则把长任务放进设备环境中评估：30 个任务，每个任务运行五次，完整通过要求同时满足功能、视觉和约束检查。在 2026 年 10 月 6 日更新的榜单上，最高完整通过率是 32.7%。[8]这个数字同样需要带着口径阅读：它衡量的是该组长任务，模型与 Harness 也是成对评测的，不能单独归因给某个模型或某种工具。它也不适合和早期短任务榜单直接做升降比较。这两项证据共同支持一个工程要求：如果目标是让 App 正确工作，验收就应该到达 App 实际运行的地方。

04 一句“验证通过”，还需要回答三个问题

该验证什么

改了一处状态管理，可能影响不止一个页面；改了权限流程，可能只在某个系统版本上出错。让 Agent 自己选一条顺利的路径走完，覆盖范围未必足够。在原始调研纳入系统的公开文档中，尚未发现明确说明“根据代码改动推导应该验证哪些页面和流程”的通用产品能力。这是一个检索范围内的观察，值得进一步建设和检验。

凭什么判断通过

已有的项目测试、确定性断言、流程回放和视觉基线，都是重要基础。下一步需要把预期表达得更清楚：提交表单后数据应被保存，返回页面后状态应保留，关键按钮在大字体下应可达。能用程序检查的条件，就保留明确的检查结果；需要视觉或模型判断的部分，也应记录依据和不确定性。同一个 Agent 可以负责修改，也可以参与检查。但“我看过了”这句话，还不能替代别人能够复查的证据。

在什么环境下通过

哪一台设备，哪个系统版本，怎样的屏幕尺寸、权限状态和网络条件？同一条流程能否再次执行？失败时能否看到日志、截图和具体步骤？没有这些信息，“通过”很容易变成一次性的印象。把环境和证据记录下来，才能逐步形成有用的回归资产。

05 我们想为这条链路补上什么

我们希望从移动开发的实际工作出发，把三个方向持续做下去。首先，让设备更容易接入开发过程，让运行中的界面和操作反馈随时可见。其次，让一次交互能够留下可复查的信息：做了什么、发生了什么、哪里不符合预期。再往后，把代码改动、风险和验证范围联系起来，帮助开发者判断这次需要重点检查什么。这需要明确的接口和积累起来的证据，也需要与已有工具协作。不同项目已经解决了构建、设备控制、测试执行等问题，我们希望补齐它们之间仍然薄弱的部分，并把可复用的实现开放出来。

让 Agent 拿到更准确的反馈，也让开发者更容易判断什么时候可以信任结果。 这是我们想参与这个方向的原因。

06 先放一个预告：Mobile Preview Plugin

我们已经迈出的第一步，是 Mobile Preview Plugin，简称 MPP。它把 Android 设备和本机 iOS Simulator 的实时画面，接到 DeepSeek Harness 的开发对话旁。开发者可以在同一个工作台里讨论代码、查看应用变化，并直接点击、拖动和使用基础导航按钮。

MPP 使用连续 H.264 视频流，视频与输入独立传输；预览画面在客户端显示，不需要逐帧请求模型。它可以作为插件接入原版 DSH Web 和 Desktop，使用独立 Rust 核心，并以 Apache-2.0 开源。[9]Agent 可以为当前对话打开 Android 或 iOS 平台面板，具体设备由用户选择并连接。MPP 当前提供实时预览与人工操作入口。 前文讨论的自动测试和独立验收，是移动开发工具生态仍需继续完善的环节。开发者预览包已经开放，当前发布包面向 macOS Apple Silicon；iOS 支持限于实验性的本机 Simulator，不包含 iPhone 真机。设备和系统版本的具体验证范围，以项目文档为准。[9]这是系列文章的一个预告。下一篇，我们会单独介绍 MPP 的安装、Android／iOS 使用流程，以及实现中的取舍。

如果你也在用 AI 做移动开发，欢迎聊聊：你现在最费时间的是构建部署、设备操作，还是确认改动没有破坏原有功能？这些具体问题，会决定我们接下来优先补哪一块。

项目与使用指南

• 官网：https://mobile-dev-harness.github.io/mobile-preview-plugin-site/

•  源码：https://github.com/mobile-dev-harness/mobile-preview-plugin

参考资料

• [1] Apple，Xcode 27 Release Notes。https://developer.apple.com/documentation/xcode-release-notes/xcode-27-release-notes

• [2] Google，Overview of Android CLI。https://developer.android.com/tools/agents/android-cli

• [3] Google，Android CLI support for Journeys。

https://developer.android.com/tools/agents/android-cli/journeys

• [4] Maestro 官方文档。https://docs.maestro.dev/

• [5] Mobile MCP 官方仓库。https://github.com/mobile-next/mobile-mcp

• [6] MobileBuildMCP 官方仓库https://github.com/getsentry/MobileBuildMCP

• [7] OpenHarmony Bench，表 4，arXiv 预印本，2026-08-17。https://arxiv.org/html/2608.16022v1

• [8] Google Android Bench 榜单、方法与更新日志。https://developer.android.com/bench，https://developer.android.com/bench/methodology/2，https://developer.android.com/bench/changelog

• [9] MPP v0.1.0-preview.5 发布与验收记录。

https://github.com/mobile-dev-harness/mobile-preview-plugin/blob/f81bf25/docs/RELEASING.md