第一款 AI 手机，被半个互联网「拒」了

头图来源： chatgpt 生成

10 月 14 日，豆包手机助手推出的《屏幕自动化操作声明协议》（SAEP，Screen Automation Execution Protocol）正式结束 30 天公示期。随之公布的拒绝名单显示，已有 155 款第三方应用明确关上了 AI 自动化操作的大门。名单当日经两轮更新，首批发布为 153 款，最终补全长尾应用后共计 155 款。

腾讯旗下 66 款、阿里旗下 23 款、美团 11 款、快手 14 款，几乎覆盖国内互联网半壁江山的主流产品悉数在列，就连 Kimi、DeepSeek 等 AI 赛道的同类产品，也选择了关闭权限。

这份长长的拒绝名单，是超级 App 们在 AI Agent 时代，第一次集体对自身的应用边界和流量主权做出表态。

当 AI 开始能替用户点按屏幕、跨应用完成任务，原本稳固了十几年的移动端流量格局和商业逻辑，正在出现新的裂痕。

SAEP：把规则摆上台面

在 SAEP 出台之前，这件事始终处于行业的灰色地带。

手机 AI 助手能不能操作某款应用、能操作到哪一步，基本由 AI 厂商单方面技术适配决定，应用方没有正式的表态渠道，大多通过风控策略默默拦截；用户则始终面对模糊的功能边界，不知道为什么有的应用能用 AI 操作，有的不能。

SAEP 的核心，是把屏幕自动化操作的选择权交还给第三方开发者。

开发者可以自主声明是否允许豆包手机助手在自身应用内执行屏幕识别、模拟点击、内容填写等操作，也可以细化到具体页面、具体功能的权限边界。

按照豆包公布的运行规则，整个权限开放分为两个阶段：

30 天公示期内，所有第三方应用默认不开放 AI 操作，仅主动声明同意的应用才会被支持；

公示期结束后，未明确提交拒绝声明的应用，将按照风险层级逐步开放操作权限；

已明确拒绝的应用，始终不会被 AI 执行自动化操作，开发者后续也可随时调整声明状态。

从技术实现上，豆包手机助手的自动化能力基于系统级权限，可在后台完成屏幕读取与交互操作，区别于普通无障碍工具需占用前台的特性。同时，该权限仅针对 AI 自动化操作，完全不影响应用本身的正常使用，用户依然可以手动打开、使用所有 App。

从隐性冲突到公开规则

事实上，这套规则的出台，之前已埋下伏笔。

2025 年 12 月，字节跳动联合中兴努比亚推出豆包手机助手技术预览版，搭载于工程样机努比亚 M153，面向行业人士开放体验。

这是豆包屏幕自动化能力首次面向公众落地，但很快便暴露出与第三方应用的适配冲突。当时已有用户反馈，微信、淘宝、闲鱼、大麦等多款主流应用出现登录异常、频繁弹出人机验证、闪退等现象；在竞技类游戏场景中，相关自动化能力也触发了应用方的风控判定。

针对这一情况，豆包官方当时即发布功能调整公告，主动限制了 AI 在刷分激励类、金融类应用以及竞技游戏等场景下的自动操作。矛盾被暂时压下，但并没有形成统一的解决标准。

2026 年 9 月 14 日，豆包手机助手消费者版本正式发布，同步推出《屏幕自动化操作声明协议》（SAEP），启动为期 30 天的公示期。两天后，搭载豆包手机助手消费者版的努比亚 NaviX Ultra 正式发售，标志着这项系统级 AI 自动化能力正式面向普通消费者开放。

然而正式落地后不到两周，冲突再次集中出现。

9 月 24 日起，大量用户反馈在 NaviX Ultra 上登录《王者荣耀》时触发「设备环境异常」判定，账号被强制下线甚至短时封禁，理由是「使用第三方辅助工具」。

豆包官方次日发布说明致歉，称经核查助手未对游戏系统进行任何操作，不存在违规模拟行为，团队正与腾讯沟通。后续媒体实测显示，即便未开启 GUI 自动化功能，该机型运行游戏仍会触发风控。

腾讯系拒绝名单｜图片来源：豆包手机助手官方网站

这一事件典型呈现了此前的矛盾状态：冲突真实存在，但双方都在技术和风控层面隐性博弈，没有公开的规则，也没有明确的沟通渠道。SAEP 的推出，则在试图将这种隐性博弈转化为公开的规则协商。

拒绝名单里的阵营分野

此次明确拒绝的 155 款应用，覆盖社交、电商、支付、娱乐、AI 工具等多个核心领域，头部互联网厂商的产品构成了拒绝阵营的主体。

拒绝阵营的主体，是拥有完整自有生态与流量闭环的头部平台。腾讯以 66 款产品成为拒绝数量最多的厂商，覆盖微信、企业微信、QQ 等社交入口，腾讯会议、腾讯文档等办公工具，以及酷狗音乐、王者荣耀等娱乐产品，几乎全线关闭权限。

美团、阿里系拒绝名单｜图片来源：豆包手机助手官方网站

阿里系共有 23 款应用在列，包括菜鸟、高德、天猫、淘宝、闲鱼、支付宝、饿了么等主流产品，基本覆盖了阿里的核心应用矩阵。 此外，美团旗下 11 款、快手旗下 14 款应用也均选择拒绝。

此外，多家 AI 赛道的同类产品同样出现在拒绝名单中，包括 Kimi、DeepSeek 等。 其余第三方应用还包括滴滴、小红书、拼多多、知乎、陌陌、网易云音乐、百度地图、WPS、唯品会，以及三大运营商 App、工商银行、招商银行等均明确拒绝。

另一边，各领域仍有不少头部应用暂未出现在本次拒绝名单中。

字节跳动自研及关联全系应用作为自有生态默认全面支持；电商领域，京东全系产品均未在列。

长视频、汽车、金融等赛道也呈现类似格局：爱奇艺、芒果 TV、哔哩哔哩均暂时未进入拒绝名单；比亚迪、蔚来、小鹏、理想等主流车企的官方控车 App 悉数缺席；除工商银行、招商银行等少数机构外，多数国有大行与头部券商也暂未提交拒绝声明。

整体来看，拒绝与否的边界，大致沿着「是否拥有独立的流量入口与生态闭环」划分。越依赖自有首页流量、越看重用户站内停留时长的平台，拒绝的倾向越强；越依赖外部订单分发、更看重交易达成的平台，越倾向于观望甚至开放。

边界确权才刚刚开始

这场集体选择，不只是商业利益的博弈，也藏着整个行业对安全与责任的共同顾虑。

在此之前，移动端的权力结构是清晰的：操作系统掌握底层能力，App 掌握服务入口，用户通过 App 获取服务。AI 助手的出现，在用户和 App 之间插入了新的一层，原本的平衡被打破。

安全与责任是一个现实考量。

屏幕读取加模拟点击的能力，本身就游走在合规的灰色地带。在支付、登录、内容发布、信息删除这些高风险场景中，如果 AI 代用户完成操作，一旦出现盗刷、误发、账号异常，责任到底该由 AI 厂商、App 平台还是用户承担，目前行业内还没有明确的标准和划分。很多银行、社交应用的风控系统，本身就会将模拟操作判定为外挂或风险行为，拒绝 AI 操作也是出于安全合规的现实考量。

也正因为如此，SAEP 的意义远不止是一份授权清单，而是把原本藏在风控背后的矛盾公开化了。它建立了一套透明的规则，让开发者可以明确表态，让用户可以清晰预期。

长期来看，手机 AI 的生态应该并不会走向「谁权限高谁赢」的野蛮生长。最终可能会形成三层博弈的格局：操作系统决定给 AI 助手开放多少系统级能力，App 开发者决定划出多大的操作边界，用户最终选择用不用、用哪款 AI 工具。

155 款 App 的拒绝只是这个过程的起点。它先把选择权交还给了开发者，接下来的权限细化、责任划分、利益分配，还需要整个行业在博弈中慢慢找到平衡点。

资讯由采集器定时从公开的机器人 / AI 信息源自动聚合。