北京
长时间AI任务和聊天请求有一个关键区别：任务可能会跑得比屏幕亮起、网络连接、访问令牌甚至应用进程更久。对于移动端来说，真正的成功不是“加载动画还在转”，而是用户离开、再回来，还能找回任务的权威状态，既没有重复工作，也没有失去控制。这篇文章是一份测试协议，不是设备跑分，它定义了一套团队在宣布“移动连续性”之前应当记录的设备、网络切换、证据和不变性检查点。
要做的第一件事是明确任务到底在哪里运行。写下实际执行链路：移动应用调用任务API，API创建持久化任务记录，记录分派给工作进程，工作进程产出制品。如果任务在云端开发环境执行，手机暂停理当不会终止任务；但如果执行在设备本地，那么后台限制、发热、电量和操作系统调度就成了正确性的一部分。测试结果表里别把这两种架构混在一起。
其次，每一个测试结果都需要足够的上下文来复现。要记录设备型号、操作系统及版本、应用构建版本、执行位置（云端、边缘还是设备）、起始网络类型（Wi-Fi、蜂窝或受限网络）、账户角色、任务夹具及版本、任务ID、各项关键时间点（任务开始、切换开始、恢复开始）、电池起止百分比、屏幕状态，以及预期不变性条件和实际观察结果，还要附上证据链接。团队至少要用一台当前iOS设备和一台支持的安卓设备，如果能拿到老旧或内存受限的设备就更贴近真实用户。模拟器对确定性的UI流程有用，但别拿它来证明电池行为、无线电特性、温控限制或进程被杀死的情况。
还需要一道确定性的任务夹具。选一个至少需要5分钟才能跑完的代码仓库和任务，这样生命周期变化才能发生。任务要能产出可检查的补丁和测试结果、能安全重复运行、没有生产凭证、从一个固定版本开始，而且有已知的成功条件。例如，可以用一个可丢弃的计算器API仓库，固定在某个提交SHA，任务是为其添加“除以零”的输入校验，成功的标志是产生一处预期的源码变更和一个新的通过测试，最长时限15分钟。切换网络场景时别改动提示词，否则任务的自身差异就可能被误判为移动端生命周期行为。
接着跑一套连续性矩阵：覆盖App从后台恢复、网络从Wi-Fi切到蜂窝再切回、飞行模式开关、强制杀掉进程、以及离线下取消操作等情况。离线取消这个案例尤其能暴露问题——按钮在本地按下了，并不代表服务器端真的接受了取消请求。
最后，移动端界面上不能只展示一个任务状态，还得让用户知道这个状态有多“新鲜”、来源是谁。客户端需要缓存任务的更新时间、版本号和连接状况。比如显示“正在运行——42秒前更新；重连中”，而不是一个看起来一切正常的动画；取消操作在本地排队时则要标明“连接恢复后将发送取消请求”。做到这些，才能给用户真正的掌控感。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
