AI 移动端流程越有用，越需要清楚边界。
问题不是 AI 能不能点击、重试、恢复，而是：什么时候允许它这样做？什么时候必须停下来交给人？
先给一个简单答案
Human-in-the-loop 规则用来定义：哪些移动端步骤 AI 可以自动处理，哪些步骤 AI 可以给建议但要人工批准，哪些步骤必须暂停并交给人。这对云手机自动化很重要，因为移动 App 里经常混着登录、安全、支付、发布和账号风险页面。
为什么边界很重要
移动 App 里的低风险动作和高风险动作经常在同一个流程里出现。
权限弹窗可能可以处理，页面加载慢可能可以重试。但登录验证、账号警告、最终发布确认，就应该交给人。
如果所有失败都用同一种方式处理，自动化会有风险；如果所有失败都交给人，自动化又没效率。Human-in-the-loop 是中间的平衡点。
AI 动作可以分三层
一个好用的模型可以分成三层：
- AI 可以自动恢复。
- AI 可以建议修复，但需要人批准。
- AI 必须停止并上报。
第一层例子：
- 等待并重试慢页面；
- 关闭已知且不敏感的弹窗；
- App 崩溃后重新打开；
- 页面符合预期后继续。
第二层例子：
- UI 变化后调整选择器；
- 修改等待时间；
- 改变流程步骤，但要运营确认。
第三层例子：
- 登录验证；
- 支付或账单；
- 账号风险提醒；
- 平台政策通知；
- 最终发布确认；
- 未知页面。
规则应该怎么写
先用自然语言写规则，再写脚本。
每个流程都应该定义：
- 预期开始页面；
- 预期成功页面；
- 安全恢复情况；
- 必须人工审核的情况；
- 最大重试次数；
- 谁接收异常；
- 必须保存什么证据。
这样 AI 有边界，运营也更敢使用。
为什么独立开关重要
AI 异常接管不应该是全开或全关。
团队可能希望某个任务开启 AI 恢复，另一个任务不开；可能允许 AI 处理权限弹窗，但不允许处理发布确认；也可能先在小分组测试，再逐步放开。
独立开关能让团队更安全地采用 AI 接管。
QCCBot 适合放在哪
QCCBot 支持 AI 辅助云手机流程和可控异常处理。团队可以用 xeasy code AI 生成脚本，用 AI Guardian 监控失败，再通过任务日志复盘 AI 做过什么。
如果你正在设计更安全的 AI 移动端流程，QCCBot 提供云手机、脚本自动化、AI 异常处理和日志能力，让关键步骤仍然在人控制之下。
常见问题
Human-in-the-loop 是不是说明自动化不够强？
不是。真正强的自动化知道什么时候该停。
AI 可以处理登录页面吗？
登录和验证页面应该谨慎处理，通常更适合交给人工审核。
第一条规则应该写什么？
先定义 AI 必须停止的页面，这能先保护流程。