直接回答
离线测试必须覆盖用户实际会完成的整项任务，而不是只执行一次模型调用。先声明之前做过哪些设置：模型或语言资产是否已安装、账号状态是否建立、权限是否授予、缓存是否预热。然后阻断连接，按真实用户步骤完成采集或导入、预处理、推理、显示、保存和可选输出。`ARCH-01` 按推理发生位置定义端侧 AI；`PRIVACY-01` 则提醒本地推理不代表应用没有其他请求。结合这两张事实卡来限定结论：任务中可以有本地推理阶段，但首次设置、账号、更新、遥测或可选功能仍可能依赖网络。 要把“首次安装”和“资产已经就绪”分开。如果模型此前已经下载，报告就应这样写；不能因为下载后的任务断网可运行，就说安装过程也是离线的。另设干净安装测试，与设备已准备好模型文件的状态区分。记录应用构建和模型身份，但不要推出未经证明的设备结论。测试时使用独特输入，避免误把历史输出当成新结果；在安全前提下清理相关缓存，并确认显示结果与本次请求对应。 证据不应只有飞行模式。它是有用的受控条件，但平台无线设置或缓存服务可能影响观察。还应结合受控网络阻断、设置和任务期间的请求捕获、调用代码审阅和依赖清单。Android Studio Network Inspector 可以显示受支持的 HttpsURLConnection 与 OkHttp 流量，其他网络库可能不可见，报告必须写明此限制。对比设置前、任务中和恢复联网后的行为，避免把延迟上传或遥测错当作推理流量。 任务矩阵要把阶段拆开。测试模型不存在、模型已在本地、账号不可用（若适用）、权限拒绝、启动前断网、请求中断网、应用进入后台、进程重建，以及可选语音或导出不可用。记录每种状态是返回本地结果、显示明确阻塞，还是走另一条远端路径。禁止本地失败后静默重试到云端。如果语音识别、语音音色、地图或账号检查由平台提供，要按具体官方文档和目标配置核实，不能仅凭 AI 模型在哪儿运行就推定整条链路行为。 执行前写明验收条件：什么结果算通过、怎样的网络行为算依赖、哪些失败要解释。记录构建标识、完整步骤、断网方式、初始缓存状态、执行路径、输出标识、抓包结果和错误阶段。不要把私人用户输入保存为测试证据，尽量使用合成样例。每种准备公开描述的配置都要单独复测，并把结论限定到对应记录。一次成功只支持被记录的设置与工作流，不能证明所有功能、语言、模型或 Android 设备都可离线。 最后，界面要解释离线边界：哪些素材须提前下载、断网时哪些功能仍在、哪些可选能力可能不可用。若应用会排队等恢复联网后再执行，应如实说明，并披露届时发送什么。离线标记应跟随当前执行路径，而非静态贴在产品身份上。这样才形成能审计的工作流，清楚地区分本地推理和完整离线体验，也不会根据一次模型调用夸大隐私结论。
模型设置完成后测试翻译任务
QA 工程师先下载所需模型，再测试导入新短句、翻译、保存和回放是否能在断网时完成。已有热缓存可能掩盖真实依赖。
决策
记录已准备状态，使用新的合成短句，观察完整任务前后的网络行为，并把可选输出单独测试。
预期结果
报告准确写出哪些阶段在本地完成、哪些不可用，以及测试构建中是否出现推理之外的网络请求。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- ARCH-01：端侧 AI 指推理在用户设备执行
- PRIVACY-01：本地推理不能证明没有其他网络请求
隐私声明需要数据清单和流量证据；“本地模型”标签本身不是证明。
实施流程
- 定义离线声明和测试起点. 记录用户任务、应用构建、模型身份、账号、权限、先前设置和缓存条件。区分“资产安装后任务可离线”和“离线安装”。
- 准备完整任务新样例. 使用唯一合成内容，安全清理相关缓存，并在测试前写出可见结果或验收属性。不能用已有答案证明新任务运行成功。
- 阻断并观察连接. 受控阻断网络，在设置、任务、恢复连接各阶段观察支持的端点。对工具不可见的客户端继续检查源代码和依赖。
- 覆盖失败和可选路径. 测试素材缺失、权限、账号、任务中断、进程重建、远端回退条件、语音输出和导出。确认没有隐藏路由切换或排队传输。
- 让结论只匹配测试记录. 保存构建、具体步骤、网络状态、缓存条件、观测路径、结果和缺口。扩大声明前，在新增配置上重复验证。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 报告把提前下载素材与任务测试分开，使用不能被旧缓存答案混淆的输入。
- 断网条件下每个功能阶段都有结果；不可用或排队等待远端的步骤清晰展示并说明。
- 网络观察记录了检查的库和盲区，公开声明限制在已测构建、任务和配置。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 单次模型调用 | 模型层离线检查 | 只能展示一次本地计算，未覆盖采集、设置、账号、保存或输出。 |
| 设置后完成整项任务 | 准备完成后的端到端测试 | 覆盖素材齐备后的用户流程，并明确写出这个前提。 |
| 断网全新安装 | 离线设置测试 | 验证的是另一种能力；所需素材未安装时失败也可能是正确结果。 |
需要避免的失败模式
- 只在飞行模式里跑一个提示词
- 用缓存结果冒充新推理
- 把配置一次设备的结果推广为机型兼容结论
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
只开飞行模式足以证明应用离线吗？
不足。它只是一个有用条件；缓存、延后任务、抓包覆盖不足和平台服务都要另行检查，并完成整项测试、代码审阅和依赖检查。
模型是之前下载的，应用还可以称为离线吗？
应说明前提：必要资产安装后任务可在断网时运行。这不同于离线安装或首次设置，也不能隐藏下载阶段的网络要求与后续更新。
一台手机测试成功能证明广泛设备支持吗？
不能。结果只对应记录的配置和工作流。没有其他模型、设备、语言对或 Android 版本证据时不应推广，也不能写成普遍兼容承诺。