150多款App拒绝豆包,AI手机卡在了应用入口

“

微信发消息、淘宝下单，豆包能替我做到哪一步？

10月14日，豆包手机助手宣布，《屏幕自动化操作声明协议》30天公示期结束，逐步开放第三方应用的屏幕自动化操作。

微信、淘宝、美团、支付宝等150多款App出现在拒绝操作清单中，开发者此后也可继续声明拒绝。

这些应用可以正常安装、手动使用。被限制的是豆包识别屏幕、模拟点击和滑动等代操作方式，通常称为GUI操作。

对准备购买AI手机的人来说，这份名单值得认真看。

购物、发消息、叫外卖，恰好是大家最熟悉、最常做的操作。把这些步骤交给助手，本来也是AI手机很容易让消费者理解的卖点。

淘宝下单、微信发消息、调用支付宝付款，分别受哪些限制，已经成了购机前需要查清楚的问题。

操作范围与合作条件

豆包手机助手官网把“操作手机”列为Beta版功能，介绍中提到模拟点击和工具调用两种方式。

官网也列出了已经接入的服务，例如曹操出行，并注明首批支持北京、杭州。

豆包手机助手官网展示的努比亚NaviX Ultra产品图

来源：豆包手机助手官网

模拟点击容易理解：助手识别界面上的搜索框、商品卡片和按钮，按照用户指令执行。它要读取界面，也可能处理联系人、地址、订单等个人信息。

SAEP让应用开发者声明允许操作的页面和动作。系统会结合用户授权、应用声明等信息，判断本次请求是否执行。

应用明确拒绝以后，豆包会停止相应代操作。

假设用户要求豆包在淘宝里查找某件商品、选择规格并下单，拒绝声明会限制这条GUI执行路径。换成“把订单地址发给微信里的朋友”，又涉及读取联系人和发送消息的权限。

助手接下来能否继续，要看有没有可用的合作接口，或者能否让用户接手。手动接手时，用户可能得重新找到商品，核对型号和数量，再确认收货地址。

如果找商品、选规格、填地址都得自己做，自动下单就很难成为换机理由。

名单覆盖的功能因此比应用数量更重要。十个偶尔使用的工具，与每天打开的通信、购物、支付应用，对购买体验的影响差别很大。

部分拒绝操作应用清单

来源：第一财经转引豆包手机助手信息

这也会影响手机的推广。

演示中展示一次自动下单，用户往往会联想到自己的常用平台。销售页面若省略适用应用、账号条件和人工确认步骤，购买后的落差就会集中出现在这些细节上。

哪家平台支持搜索，哪家支持提交订单，付款时怎样确认，都是功能说明里应该明确的内容。

电商和本地生活平台有自己的商品排序、促销活动与广告展示。

AI介入消费决策，可能改变用户接触这些内容的方式。

假设用户要求助手比较三个平台的酒店，最后只听到两三个推荐结果。

用户少翻几页，部分酒店、促销活动和推广位置就可能失去曝光；助手采用什么价格口径，也会影响推荐顺序。

一间酒店的标价、优惠券、会员价、早餐和取消条件，都可能改变最终选择。

助手若只比较页面上最显眼的价格，可能把条件不同的房间放在一起排序。平台要考虑信息怎样提供，商家也会关心自己的优惠是否被完整呈现。

如果会员优惠没被纳入比价，实际更便宜的酒店也可能被排到后面。

购物请求往往已经带着预算、品类和购买意愿，豆包有机会直接承接这类需求。

如果用户在助手里完成挑选，原平台怎样展示促销、怎样识别订单来源，就会成为双方接入时的实际问题。

可调用的商品来自哪些商家，价格与库存怎样更新，订单归属和售后由谁承接，都得写进合作安排。如果未来涉及服务费用或交易分成，双方也要约定新增收入怎样分配。

与此同时，平台每天还要处理自动化操作带来的风险。

如果助手选错规格后提交订单，客服需要查清用户原本的要求，以及提交前确认过什么。

若任务超时后重复执行，还可能产生重复下单、重复预约。对于通信应用，选错联系人、发送了错误内容，也有直接后果。

这些操作一旦扩大到大量用户，申诉、撤销和售后处理就会增加平台的工作量。平台判断是否开放时，会关心操作记录、身份核验和故障处理办法。

第一财经的报道还提到，部分努比亚NaviX Ultra用户登录《王者荣耀》时，出现环境异常提示或被强制下线。

豆包方面表示，正与腾讯相关方沟通。

对字节来说，接入一个服务，接下来就要处理一组持续变化的功能条件。

假设豆包通过合作接口提供酒店预订，双方首先要明确能查询哪些房源、提交哪些订单，是否覆盖取消、改期与退款。

只开放预订时，用户提出“把明天的入住改到后天”，助手就需要提示可执行范围，并安排后续操作。

同样一项服务，不同供应商也可能采用不同规则。

某家酒店允许免费取消，另一家要求支付违约金，助手执行前就得读取对应条款、核对金额，让用户确认。

这些细节会增加产品开发、接口适配和持续测试的工作。

手机卖出以后，服务方更新接口、调整优惠规则，或者修改权限配置，原有任务都有可能受影响。

用户手动确认购物订单的概念插图

异常处理也得跟上。

如果提交订单后迟迟没有收到结果，助手要先查询是否已经生成订单，再判断能否重试。

若直接重复提交，后续可能需要客服介入取消。用户授权撤回以后，尚未完成的任务怎样停止，也要有明确处理。

若出现重复订单，客服得查清用户确认了几次、助手提交了几次。

字节要安排团队接入服务、跟进规则变化、排查失败任务，以及与合作方处理投诉。

假设一项订票服务需要平台人工核实，客服接手时就得看到助手查过哪班车、提交了哪些信息，以及用户确认过什么。

对话里的指令、系统执行记录和商家的订单记录要能对应起来，排查人员才能定位出错步骤。

手机扩大销售以后，同一种失败还可能集中发生。

供应商某个接口返回异常，受影响的预订任务就可能同时增加。

暂停重试、通知用户、核实订单状态，需要有团队持续处理。手机售出之后，处理重复订单和退款的人工支出会继续发生。

合作范围还可能影响推荐结果。

假设接入的酒店供应商只覆盖一部分房源，助手实际比较的就是这部分供给。用户说“找最便宜的”，需要知道搜索覆盖了哪些平台，以及哪些价格尚未纳入。

如果服务接入长期围绕少数合作平台展开，豆包就要在产品里明确标注可用范围。消费者才能判断，它是否覆盖了自己经常使用的购物、出行和通信服务。

已声明拒绝的应用可以随时调整策略，豆包也要同步更新支持范围。

消费者购买时看到的功能，在后续使用中可能发生变化，更新说明就得标明受影响的平台、操作和处理办法。

消费者在门店问“能自动下单吗”，销售人员最好能直接回答支持哪些平台、哪些商品、哪些地区，演示付款怎样确认，以及任务失败后怎样处理。

购机页面把这些内容列清楚，消费者才容易算出：自己每天找商品、填地址、查订单和发消息的操作，究竟能减少多少。

— END —