智叟云集系统：架构设计与自动化采集原理

一、为什么需要品牌 AI 监测

当用户把“某个品牌怎么样”“某类产品有哪些选择”“某个地区有哪些服务商”交给 AI 回答时，企业关心的不再只是网页是否被收录，还包括品牌是否被提及、被如何描述、与哪些竞品一起出现，以及这些描述引用了哪些信息来源。要回答这些问题，首先需要一套能够重复执行、保留证据的采集流程。

智叟云集系统的当前能力重点在采集侧：通过真实云手机上的 AI 应用发起问题，将回答正文、屏幕截图、对话分享链接和信源整理到同一任务中。它为后续品牌提及分析、竞品比较、内容纠错和周期监测提供输入，但并不等同于已经完成上述所有分析功能。

二、系统由哪些层组成

分层的价值是把“业务希望问什么”和“手机上如何完成操作”分开。业务后台只应提交经过校验的问题和目标平台；具体设备地址、界面状态、采集动作由执行器负责。未来某个平台界面发生变化时，优先调整该平台适配层，而不是重写业务系统。

三、采集技术如何协同工作

设备连接层使用 ADB 与云手机通信，负责设备命令、应用启动及相关设备能力。界面自动化层使用 Android 自动化工具读取控件树，根据文字、描述、位置及必要的图像线索定位按钮。执行器按照状态推进操作，而不是仅靠一串固定坐标和固定等待时间。

正文和证据获取采用组合方式：界面操作负责真实提问、复制正文、截图和触发分享；对话分享数据解析用于提取公开可取得的回答或信源结构；DeepSeek 的实验性快速链路通过网络响应观察补充本次回答的信源数据，减少逐条打开来源页面的操作成本。

这不是四个平台官方模型 API 的统一封装。问题仍提交给云手机内的真实应用，采集结果也受应用版本、账号状态、页面布局、联网搜索状态以及平台生成过程影响。实验性网络链路有额外设备条件，需要准备与恢复环境，不能因为局部提速就忽略整个执行过程的成本。

四、一次完整采集如何完成

执行前先判断软件是否已激活、设备是否连通和获得授权、目标应用是否可用。进入应用后，确认对话页面和输入框状态，再提交当前问题。对于没有完成提交确认的任务，应报告启动或界面错误，而不是等待回答超时后笼统地归类为平台慢。

回答生成期间需要区分“已经出现文字”和“已经完成生成”。前者可以用于估计首字等待，后者才允许稳定提取正文和完整证据。正文采集后，截图应覆盖需要留存的回答范围，分享链接应关联当前对话，信源应与当前回答对应。最后完成结果校验、写入文件与临时环境清理。

原始失败也具有诊断价值。例如运行不到一秒就退出，通常应先检查授权、连接和启动参数；回答已生成但缺少信源，应检查分享数据或信源提取阶段；截图空白则需要核查页面是否加载完成、滚动位置以及截图内容，而不能把“图片文件存在”作为验收标准。

五、如何理解返回的数据

统一返回结构应明确区分“平台未提供”“采集未成功”和“字段不适用”。例如某个插件没有公开网址，应保留这一事实，不能为了凑齐列表编造链接；如果信源解析失败，则不应把空列表包装成平台确实没有信源。未来入库时，这些缺失原因同样需要保存。

六、适配、测试与应用场景

当前适配针对已测试的中文界面与特定屏幕布局。应用更新、分辨率变化、系统弹窗、输入法遮挡和登录失效都可能影响流程。新增平台至少需要定义启动状态、输入状态、生成完成状态、分享方式和失败出口，再用真实问题验证证据是否一致。仅替换应用名称不能称为完成平台适配。

部署前应覆盖短回答、长回答、无公开信源、分享延迟、账号过期以及设备断线等场景。验收不只看任务是否返回成功，还要抽查正文与问题对应、截图首尾覆盖、链接归属、信源来源和清理结果。测试结果应记录应用版本与设备条件，便于后续定位回归问题。

在业务上，该采集层可以支持品牌描述核查、竞品回答对照、行业问题巡检和内容团队的信息来源分析。例如运营人员定期提交同一组品牌问题，把各平台输出交给人工审核；也可以在后续分析模块中提取品牌提及和关键描述。自动情感评分、排名统计、趋势告警等属于可扩展方向，不应误写为当前已交付功能。