手机上的 AI 助手能不能替你点外卖?豆包抛出了一份＂声明协议＂

9 月 14 日，豆包手机助手的消费者版发布，把"手机图形界面自动操作"这项能力以 Beta 形式开放——简单说，就是让它替你在屏幕上点。

同一时间，他们还抛出了一个叫 SAEP（屏幕自动化操作声明协议）的东西，启动为期 30 天的规则公示：第三方应用可以自主声明，是否允许 AI 助手在自己的应用内执行自动化操作；豆包表示，会停止对明确拒绝接入的应用执行操作。

我看完的第一反应是：方向挺对的。让被操作的一方有机会表态，这是这件事能谈下去的前提。但第二反应是——这套协议里的苦活，全在它没写出来的那部分。

我在项目里做过形态非常接近的东西：一套系统去读另一个系统的数据，双方靠一份"是否授权"的声明来约定边界。所以下面这三件事，我基本是被打脸打出来的经验。

一、用户不是"两种状态"，是三种

协议描述里最自然的读法是二选一：允许，或者拒绝。但真实世界里，绝大多数应用会处在第三种状态——没声明。

而且要记住，"没声明"不会是一个短暂的过渡态，它是长期的主流状态。中小应用没有动力第一时间接入，老应用早就没人维护了，新应用还在排期。所以在任何一个时间点上，助手遇到的大部分应用都是"没表态"的。

于是整个协议最关键的一句话，其实是一句没被说出口的话：没声明的时候，默认是允许还是拒绝？

我在这边测过一模一样的机制。当时的结论很简单，也很不舒服：这两种默认值没有一个是纯技术选择，都得业务有人拍板。

• 默认允许：出事一定出在"没表态"的那批身上——它们没拒绝，但也没同意，而风险是它们承担的；
• 默认拒绝：助手在大量应用里直接不可用，用户的第一感受是"这东西不好用"，而不是"它很谨慎"。

测试上的做法只有一个：把"方声明状态"乘上"助手行为"做成一张矩阵，然后重点测"未声明"这一列。三种状态 × 三类动作（读屏、点击、提交），一共九个格子，逐格确认行为是否符合预期，并且逐格留下证据。这张表我做过，九格其实不花时间，真正花时间的是说服产品同事把"未声明"这一列写完——因为它最容易被当成"以后再说"。

二、拒绝之后走哪条路，比拒绝本身重要

一个应用明确拒绝了，助手接下来做什么？这个问题看起来是体验问题，其实是测试问题，而且是最容易漏测的那一类。

我自己给这类"被拒绝之后"的路径定过三条出口，缺一条我就打回：

• 告知
  ——用户必须知道为什么停，而不是看到"操作失败"四个字；
• 可替代
  ——给出人工可继续的路径，比如"这个步骤需要你自己点一下"，最好直接跳到那个界面；
• 可追溯
  ——这个拒绝动作在日志里能查得到，用户之后想问"你刚才为什么没帮我做"时有答案。

为什么这么在意？因为自动化操作有一个特别讨厌的性质：用户看不见过程，所以用户没有自然的机会发现问题。

我在这个号第 36 篇写过智能体手机跨应用任务的七类场景，当时把"静默失败"列在第一类风险里。一个助手默默没做，比一个助手明确报错要糟糕得多——因为用户会以为它做了。等发现的时候，可能已经过了最关键的时点。

在这种"看不见"的产品里，所有失败都必须有出口，而且出口必须是有声音的。

三、声明改了，什么时候生效——缓存是这类机制的隐形杀手

第三个坑更技术一点，但它是这种机制必然要面对的：声明是会变的。一个应用今天选择了允许，下个月法务要求改回拒绝。

那么问题来了：它改了之后，助手多久知道。

只要有缓存，就有一个"两边规则不一致"的窗口期。而在这个窗口期里发生的操作，到底按旧规则算还是新规则算？这是必须提前定义、并且必须被测试的东西。我在这边踩过一个很典型的版本：配置改完，前端缓存五分钟，用户在这五分钟里做的操作全部落在旧规则上，日志里也看不出任何异常。

所以这类机制的测试用例，我固定写这几条：

• 改声明后立刻发起操作，测一次；
• 改完等过一个缓存周期，再测一次；
• 清缓存与不清缓存
  各测一次，两条路径都可能存在；
• 跨天再测一次
  ——很多缓存是跟着会话或者日期边界走的；
• 最关键的：窗口期内发生的那次操作，要去数据里回查它按哪套规则落的。

最后一条最容易被省掉。也正是它，往往能查出真问题。

四、30 天公示期：它得真的能收反馈，才叫灰度

这次公告里我觉得最有诚意的一环，是那 30 天规则公示期。它至少承认了一件事：这套规则不可能一次想全，需要让被影响的人先说一轮。

但公示期要真的成为灰度，我认为得有两个东西同时到位：

一是能收反馈的入口。开发者得有一个具体的地方提意见，而不是面对一篇公告。二是公示期内不按新规则追责的明确承诺。没有第二条，开发者会为了自保先把声明写成"拒绝"，那这次公示收到的就是假的民意。

我在这边做流程变更也是同样的套路：先发通知，留反馈窗口，再切换。中间那段时间我们内部叫"软着陆期"，规则写得很清楚——软着陆期内发生的偏差按旧规则处理。就这一句话，反馈质量立刻不一样了，因为大家不用防着被追责。

而且对自动化操作这种"用户看不见"的功能，反馈入口尤其重要。像我们做审批流，每一节点都有人点，出问题会有人喊；但一个替你点外卖的助手点错了店，用户很可能吃完才发现。没有反馈入口的公示期，等于没有公示期。

五、同一周的折叠屏和手机涨价，其实指向同一件事

这周手机圈很热闹。9 月 18 日 iPhone 18 Pro / Pro Max 正式开售，国行 9999 元起；首款折叠屏 iPhone Duo 国行 15999 元起，京东预约逼近百万，二手已经被炒到数万元；华为的三折叠和小米的折叠新机也在同周发布。折叠屏的"三国杀"正式开打。

作为一个天天跟界面打交道的人，我想指一个大部分人不注意的关联点：折叠屏对"看屏幕、点坐标"的 AI 助手，是一道新的测试题。

这类助手的工作方式是先识别屏幕上的元素，再决定点哪里。而折叠屏恰恰是形态最不稳定的设备：内屏和外屏是两套布局，展开和折叠的中间态还有一个过渡过程，分屏、悬停、应用自适应这些场景又各有各的界面状态。

界面一变，识别和点击的稳定性就是全新的测试面。以前同一套用例在直板机上跑一遍就行，现在要按形态组合再跑一遍。而设备形态组合是最容易爆炸的测试维度之一。

另一边，GSMA 这两天警告说，入门级手机涨价正在加剧"AI 鸿沟"。这条新闻和上面那条是同一件事的两面：端侧 AI 功能最需要证明稳定性的地方，恰好是性能最弱的那些设备；而它们的份额正在被价格压缩。

测试资源永远不够，这是行业常识。所以最后还是要回到那个问题——哪些设备上的失败是不可接受的，哪些是能接受的。这个问题不回答，测试覆盖就是一笔糊涂账；回答了，资源自然就分完了。

说句公道话，把声明机制拿出来公示，比"我们先做了，你们适应一下"要进步得多。国产厂商愿意在一个全新的能力上先立规则、再放开，这个动作本身就值得肯定。

但作为测试，我关心的永远不是规则写得多好，而是边界情况有没有被认真对待——默认值、拒绝之后的路径、改了的生效时延，还有那 30 天里到底能收到多少真话。

这几件事做好了，它才是真替用户省事；做不好，它只是替厂商抢时间。