这台 Android 手机能完成你的 AI 任务吗？

从一个真实任务开始

设备就绪情况取决于任务。同一部手机可能可以安装应用，却在加载模型、打开相机、处理较长提示词或应用中断后恢复时失败。与其笼统地问手机“兼不兼容”，不如描述一项需要完成的工作，并在准确的目标手机上测试整个流程。

例如：在某一台 Android 手机上打开指定应用构建版本，加载目标本地模型，离线分析一张虚构收据图片，显示可读结果，再关闭并重开应用重复一次。这只是测试定义，不代表 Cove 的任何公开版本或模型已在某款手机上通过测试。

可重复执行的设备就绪检查

选择范围明确、保护隐私且可以重复的任务。每次只改变一个变量，成功和失败都记录下来。一次成功运行不能转化为对其他手机的承诺。

1. 1. 记录设备和软件身份

   写下手机厂商与准确型号、Android 版本和构建号、可用存储空间、应用版本及测试日期。还要记录构建包来自开发安装还是正式分发渠道。Android API 级别可以帮助判断系统版本门槛是否满足，但设备名称本身不能证明硬件运行行为。每次结果都要保留这些信息，避免固件或应用更新后悄悄改变测试对象。

2. 2. 单独验证安装环节

   安装准备评估的准确构建版本，并记录商店筛选、安装包错误、权限提示或首次启动设置。能够安装只代表安装这一项检查通过，并未证明模型可以下载、内存充足，或相机、语音等任务能够运行。不要先更改设备设置绕过安装失败，再把原来的配置记录为成功。

3. 3. 准备准确的模型文件

   确认模型文件和运行时版本，在有网络时完成必要下载；如果发布方提供文件标识或校验值，也要记下。下载大小、安装后占用和运行内存是不同概念：临时文件、更新、运行时缓冲区以及同时使用的其他应用会分别影响设备。日常使用应留出足够空间，但不要编造通用存储额度。如果应用不能确认设置已完成，应记录这种不确定性。

4. 4. 定义受控任务和基线

   选择一项无敏感内容且有预期答案的输入，例如虚构笔记或样例图片。开始前写明语言、图片尺寸或提示词长度、预期输出和明确的通过条件。只有在符合真实使用方式时才关闭其他大型应用，并记录这一操作。用可重复的系统工具观察运行前和运行中的可用内存。手机标注的总 RAM 并不等于该进程真正可用的内存。

5. 5. 完成整条用户流程

   从普通用户会打开的界面开始，等待模型初始化，执行任务，检查结果，并记录耗时和可见错误。把首次冷启动与后续热启动分开。若任务包含多个环节，例如相机权限、拍摄、识别、推理和结果显示，应记录具体停在哪一步。只有在模型文件、应用版本、运行时、输入、输出限制、设备状态和计时方式都一致时，速度比较才有意义。

6. 6. 中断、恢复并重复

   在安全时机关闭应用或切到后台，重新打开并执行同一任务。若需验证离线行为，应在准备完成后断开网络并开始新会话，不能把缓存答案算作新结果。记录应用是否恢复、要求重新下载、丢失进度或解释了恢复办法。重复次数要足以暴露不稳定失败，同时如实注明次数和条件；小样本不能包装成普遍基准。