断网之后 Qwen 类能力还剩多少，不取决于名字里有没有「Qwen」，而取决于这条任务链路上哪一段跑在手机本地。常见的三段是：请求发给远端推理服务、端侧跑着量化小模型、应用把上一次结果或本地知识库存了下来。第一段断网即断，第二段能出字但质量会掉，第三段看着能用，其实在复用旧结果。想判断自己的设备属于哪种，靠的是同一批任务在断网前后各跑一遍，逐项对比，而不是看设置里有没有「离线」字样。
先把断网表现分三档：可用、降级、失败。做法是固定设备、固定输入、固定任务顺序，用飞行模式把同一批任务重跑一遍，再和在网结果逐字段对比；接着换一段全新输入并重启应用，排除本地缓存造成的假可用。能稳定复现的写进离线能力清单，只出现一次的标注为不确定项，不要当成端侧能力。
固定测试条件：同一设备、同一批任务
只有固定项够多，断网前后的差异才有解释力。切换网络这一步本身会带来变量，所以除网络状态外，其余条件建议全部锁死，并在记录里逐条写明。
- 设备：机型、系统版本、芯片、剩余存储、电量与是否处于省电或低电量模式。
- 应用：应用版本号、是否登录同一账号、模型或离线包是否已下载完成。
- 场景：把要测的任务列全，例如语音转写、文本问答、长文摘要、翻译、图片文字识别，每个任务算一项。
- 输入文本：为每个任务准备一份固定输入，建议 100 到 200 字的一段中文加一段英文，另备一份全新输入用于后面排除缓存。
- 任务顺序：按固定顺序执行，每项之间是否清空会话要写清楚，保持一致。
- 计时口径：统一记录两个时间，点击到首字出现、点击到生成结束。
可以先按下面这个表头建记录文件，一行为一次执行：
[任务] 文本问答
[网络] 飞行模式 / 仅关Wi-Fi / 在网
[输入] 固定文本编号 T1
[结果档位] 可用 / 降级 / 失败
[返回片段] 前 80 字原文
[提示文案] 如网络异常、请检查连接、离线模式
[耗时] 首字 / 结束
[备注] 截图路径、错误码、是否重启过应用断网后逐项执行，按可用、降级、失败三档记录
三档的判定标准建议提前写死，避免边看边改口径：
- 可用：断网后发起同一任务能返回结果，内容类型与在网时一致，语言、结构、长度量级接近，且没有网络类提示文案。
- 降级：能返回但形态变了，例如明显更短、只给套话、只从本地内容里摘取、长输入被截断、语音只出转写不出理解。
- 失败：报错、超时、长时间停在生成中、提示检查网络，或返回空内容。
每档的记录写法不同。可用档要抄下返回片段的前几十字和耗时，证明确实跑完；降级档除了片段，还要写清降在哪一项，是长度、是事实性还是无法联网检索；失败档要记录完整提示文案和出现时机，最好同时抓一段日志用于定位是请求发出后失败，还是在发起前就被拦住。Android 设备可先用这条命令观察网络相关日志，包名与关键字需按实际替换：
adb logcat -v time | grep -iE 'timeout|dns|network|offline|error'一个容易踩的坑是只关 Wi-Fi。如果设备仍能走蜂窝数据，任务当然「可用」，但那是在线能力。所以建议两种条件各测一次：仅关 Wi-Fi 一次，飞行模式再一次，两次结果不一致时，以飞行模式为准。
对比在网与断网下的输出差异
差异要落到字段上，不然只剩一句「感觉变差了」。建议逐项对比以下字段，并把差异归到四类之一：
- 内容长度：字数、段落数、是否给完整答案还是只给一句话。
- 准确性：数字、日期、专有名词是否被改写，是否出现明显编不出来的内容，是否明确声明无法获取最新信息。
- 提示文案：是否出现离线、网络异常、稍后重试之类的字样。
- 结构格式：在网时输出的列表、表格、代码块，断网后是否还保留。
归类时，长度差异通常指向端侧模型规模或截断策略，准确性差异更值得关注，它可能来自模型变小，也可能来自应用改用了本地规则模板。如果断网后回答与在网回答几乎逐字相同，先别高兴，这种高度一致往往意味着在复用历史结果，进入下一步验证。
判断是否有本地缓存或离线资源在起作用
区分真端侧与缓存复用，核心是让缓存失效。可以按下面顺序做，每一步只改一个条件：
- 换全新输入：用一段应用从未见过的文本，人名、数字、句式都换掉。仍能返回合理结果，端侧能力的可能性才提高。
- 重启应用并新建会话：排除会话级缓存。
- 切换任务类型：在在网时没做过的任务上断网重试，例如在网只聊过天，断网试摘要或图片识别。
- 检查本地资源：看设置里有没有离线包、模型下载项，以及应用数据目录是否明显增大。以 Android 为例，下面命令中的包名和路径需替换，Release 包未必允许直接查看：
常见本地模型文件后缀有 gguf、bin、tflite、onnx 等，是否存在体积较大的这类文件，比界面上的「离线可用」标签更可信。adb shell dumpsys package com.example.app | grep -iE 'version|codePath' adb shell ls -l /sdcard/Android/data/com.example.app/files/ - 清缓存或清数据：这一步会连带删除已下载的模型，需要重新下载，网络条件不允许时不要做，做之前先记下应用数据目录体积。
还有一个辅助信号是耗时。纯端侧推理通常不依赖网络往返，但设备性能差异大，耗时只能作为旁证，不能单独下结论。
整理离线能力清单并标出不确定项
最后把记录压成一份能直接照着用的清单，每个任务一行，字段固定如下：任务、离线档位、依赖来源、验证方式、复现次数、风险、状态。依赖来源写端侧模型、本地缓存还是远端服务，写不准就写待确认。
任务：长文摘要
离线档位：降级
依赖来源：端侧模型（本地存在较大模型文件）
验证方式：飞行模式下换全新输入，重启应用后复测
复现次数：2/3
风险：长输入被截断，事实性下降
状态：已确认不确定项的标注建议统一成一句话，写清没验证到什么程度，例如「待确认：换新输入后无返回，疑似缓存」或「待确认：飞行模式下能用，但未测超过十分钟的连续使用」。这样别人看清单时，能分清哪些是稳定结论，哪些只是当前设备上的一次观察。换设备、换应用版本、换系统省电策略后，已确认项也需要重新跑一遍再沿用。