让蜂控 AI 少走弯路：把“帮我看看”改成一条能验收的任务

查应用、看页面、检查设备时，怎样给 AI 说清目标与边界？结合实际使用记录，拆开“已安装、已授权、已登录”，给出可直接改用的提问范例。

“看看哪些手机装了这个应用。”这是一条挺自然的指令。但接着问“哪个登录了”“其他的呢”，任务就开始变得含糊：查哪个应用？查刚才的设备，还是全部设备？只检查，还是顺便安装和登录？

蜂控 AI 可以结合设备接口、应用技能和画面处理任务。想用得顺手，关键不是把提示词写得很长，而是让它知道：这次查什么、查哪些设备、允许做什么、怎样才算查清楚。

本文结合蜂控当前使用记录与 v1.2.105 的功能整理。例子经过泛化，是建议用法，不是成功率测试，也没有复用私人聊天内容。

先把三个“正常”拆开

查应用状态时，最容易混淆的是这三件事：

比如页面有商品推荐，不一定代表已经登录；有些应用允许游客浏览。需要检查登录状态，就应明确要求查看能够反映账号状态的页面。遇到证据不足，返回“无法确认”比猜一个“正常”有用。

下面是可按自己情况修改的示例。目标应用和设备范围需要你补充，不要原样保留占位词：

只检查我指定的这组设备是否安装了目标应用。先列出设备编号与内部 ID 的对应关系，再查询安装情况。不要安装、卸载或修改设置。最后逐台返回：已安装、未安装、查询失败；查询失败请保留错误原因。

需要再查登录状态时，另下一条：

只检查刚才“已安装”的设备。允许打开目标应用查看账号状态，但不要输入账号、发送消息或点击购买。没有明确登录证据就标为“无法确认”，不要把设备已授权当成应用已登录。

两条指令拆开，方便发现究竟是设备没选对、应用没找到，还是页面状态判断不够充分。也避免一个“检查”悄悄变成一串修改操作。

Anthropic 的上下文工程文章强调，给代理的信息应相关、明确，而不是一味堆积历史。放到设备操作里，就是保留当前目标、必要背景和边界，把无关对话放下。阅读原文

蜂控中的显示编号方便人辨认，调用接口使用的设备 ID 则是另一回事。不要只给一句“那几台都处理一下”，尤其是在刚切过筛选条件或聊过其他设备之后。

建议先让 AI 回答：“本次会处理哪些编号，对应哪些内部 ID？”确认无误再执行。首次尝试新任务，可以先挑一台测试设备，再扩展范围。这里限制的是本次任务，不是蜂控连接设备的数量上限。

如果已有适用的应用技能，可以指定它；但技能只是操作知识，不会自动补齐你没有表达的业务范围。还没分清 AI、技能和脚本，可以先看三者怎样配合。

“没成功，再试一下”缺少定位信息。更有效的反馈是：

设备列表已经查到了，停在读取应用页面这一步。请保留已完成的查询，只检查失败设备。先说明准备怎样确认页面，不要重新安装应用。

如果不知道失败在哪，让 AI 整理“最后成功的一步、报错的一步、原始错误、当前是否仍有任务运行”。不要把它的总结句当作唯一证据；重要操作还应对照任务状态或设备当前结果。

尤其是发送、提交、安装一类操作：请求超时不一定等于没执行。先查结果，再决定是否重试。

在任务末尾加一句：

按设备分别报告已完成、未完成、无法确认；说明判断依据。尚未验证的不要写成成功。

这能帮你区分“AI 已经安排”“工具接受了请求”和“设备真的完成了”。对于重复流程，可以进一步让 AI 整理成脚本；需要周期执行时，再配置定时任务。

如果你习惯用自己的 AI 助手，也可以走开发文档与 Local API 接入，不必只在蜂控内置对话里完成这些工作。