MAI-UI 要是能替我报销，先得过这三关

看 MAI-UI 的资料，我最先想到的是，AI 如果真的能替人操作手机，一些原来要自己来回点的事情，可能会变轻松。

但很快又想到另一头：它点错了呢？回答错一句话，我还能停下来核对。操作已经发出去，可能是提交了一份表单、修改了订单，或者把消息发给了别人。这时候体验就不能只看它操作得多快，还要看自己是否知道发生了什么，能不能停下，后面怎么处理。

我想拿差旅报销把这件事推一遍。我自己报销时卡的就是三处：发票和行程对不上，得人工核；系统字段多，附件上传麻烦；审批链长，不知道卡在谁那里。这件事看起来重复，里面却全是需要确认的细节。

先分清公开能力和我的设想

MAI-UI 是阿里通义团队的 GUI Agent 项目。2025 年 12 月的 技术报告 讨论了界面定位、移动端任务执行，以及与用户交互、工具调用、端云协作等问题。我比较在意报告对动态环境和现实部署难点的讨论。它没有理由被简化成“看得懂任意 App，从此可以全自动操作”。基准成绩说明某些条件下的表现，不是对用户手机里所有任务的承诺。

从产品角度理解，可以先拆成几件事：看懂当前屏幕上的对象，判断下一步动作，执行点击或输入，再根据新的页面状态继续。定位对了，不代表任务理解一定对；点中了按钮，也不代表业务已经成功。登录失效、页面变化、弹窗、加载中，都可能改变下一步。报告里的 MCP 指 Model Context Protocol，是连接工具与上下文的一种协议，通过工具调用和通过屏幕操作，是两类可以组合的执行方式。

“一句话发起任务”可以是入口，“一句话之后再也不需要人”是另一种要求。假设我说“明天北京去上海，八百元以内，订好以后通知助理”，这句话仍然缺信息：选哪个时间段，是否接受中转，谁是乘机人，哪个联系人是助理。我会期待它先查到候选方案，让人确认，再进入后续流程。这是期望中的产品设计，不是在说 MAI-UI 已经可以替我在所有应用里稳定完成这件事。

点击指标会变，但人没有消失

一部分操作由 Agent 完成以后，原来只统计点击和页面停留的做法，需要重新解释。用户本人进入页面，和代理为了完成任务进入页面，意图可能不同。一次完成任务产生了很多点击，可能是它在反复寻找入口；停留短，有时是效率提高，有时是根本没拿到结果。

我会在原有指标之外补几个问题：发起了多少任务，哪些真正完成，完成如何确认；哪些步骤需要人介入，介入以后能否继续；任务失败时有没有重复操作，是否产生了副作用；用户第二次还愿不愿意授权类似任务。这不代表 DAU、点击率或 A/B 测试都失效了，需要做的是区分使用方式。

一种常见的设想是，助手早上看天气、买衣服、约车、处理账单，人在睡觉，事情就办好了。我会忍不住往里补问题：降温就要买衣服吗，家里是不是已经有？账单金额是否异常，发给同事的消息是否需要本人看过？这不是否定自动化，是在区分提醒、建议、准备和执行。查天气可以自动做，替人消费就不只是多调用一个工具。

拿差旅报销走一遍

传统差旅报销涉及出票记录、发票、公司系统和审批。接口能提供标准数据时，通常值得优先考虑；没有接口或接入不方便时，GUI 操作多提供一种办法。屏幕会改版，字段会移动，权限和登录状态也会变化，GUI Agent 同样需要维护。下面是一个假设方案，用来想清楚任务设计，不是已上线案例。

触发点要能解释。可以由用户主动说“帮我准备这次出差的报销”，也可以在获得明确授权后，根据某类通知提醒。触发后先确定是哪一次行程，记录有几张票、是否改签、要提交给哪个主体。任务身份不清楚，不该急着往下填。

读到的内容要带着来源。Agent 打开对应应用或文档，找到行程、金额和日期。这里要知道显示的是票价、实付金额还是含退改费用的总额，不能把一个醒目的数字直接当报销金额。发票和行程对不上，正是我自己最常卡的地方。看不清、页面没加载完、缺正式凭证，就应该标明缺失。能把识别结果指回原始页面或附件，比只给一组数字更方便人工检查。

跨应用填写，不等于已经完成。进入企业工作台、选择报销类型、填写字段、附上凭证，这些动作可以编排，每一步都可能遇到不同情况。系统里已有同一份申请怎么办？选错了项目代码怎么办？附件上传中断怎么办？提交后没有成功提示，是重试还是先查记录？这些细节决定它会不会重复报销，或者让人以为完成了、实际只停在草稿。

接手时，人要看到什么。最终确认页，我希望看到行程、金额、附件、报销归属和待补信息，不只是一句“已填好，是否提交”。中途失败，最好能保留已完成的部分，明确停在哪里。人改完一个字段后，是从当前状态继续，还是必须整条流程重来，也会影响使用意愿。审批链上卡在谁那里，它能不能告诉我，比替我多点一个按钮更有用。人工确认不是装饰性的最后一个按钮，是有足够信息让人作判断。

产品要怎样适应

让服务更容易被明确调用。平台提供稳定的接口、清楚的字段含义和状态反馈，Agent 不必每次猜屏幕。对自己的产品，我会先检查操作语义：一个“确定”按钮究竟确定什么，提交是否可撤销，价格字段含不含税，失败有没有可识别的原因。人看不懂的地方，模型未必就能猜对。

垂直任务仍然需要理解业务。通用模型能识别页面，不代表知道每个行业怎样判断任务成功。医疗或法律场景可以考虑辅助整理材料，但不能因为 Agent 能操作，就把专业判断和责任也一并交出去。我会先从重复、边界相对清楚、失败后可恢复的任务看起。

我想补的三种能力：把要求描述成能检查的输入和输出，先说清触发条件、动作和预期结果，“出现库存变化时暂停提交并展示新信息”比“优化体验”容易讨论；把状态和恢复一起画出来，退款申请可以是待提交、处理中、完成、被拒绝、待人工处理，超时以后要查原来的申请状态，不是默认重新发起；提前写几种不该继续的情况，价格缺失、按钮被遮挡、页面还在加载、账号已退出，每个用例写清期望它怎样停。转账、购买、发消息、删除内容，要按授权和后果决定确认规则。这些规则不该只写在 Prompt 里，模型答应遵守和产品实际阻止，是两件不同的事。

我更想看的下一段演示

MAI-UI 让我对手机里的自动化有了更多想象，也让我更在意演示之外的部分。下一次展示的如果是页面改了、任务被打断、金额对不上之后，它怎样发现问题、怎样请人确认、怎样继续，我会看得更认真。那决定了自己是否真的敢把一件事交出去。

我仍然需要一个面向人的产品。哪怕大部分点击由模型完成，我也应该能知道当前状态，理解下一步的后果，并且随时接回来。