先定义基线要回答的问题
基线不是追求一个漂亮的速度数字，而是回答某项任务在正常条件下通常需要多久、会不会中断，以及中断后能否恢复。文字浏览、视频会议和大型文件交付的判断指标并不相同。
记录之前先确定任务。若目标是同步研究资料，应关注持续吞吐、文件完整性和恢复；若目标是远程会议，则上行稳定、抖动和语音连续性更重要。
每台设备都有自己的运行条件
Windows、macOS、Android、iOS和Linux对后台进程、休眠、网络切换与证书存储的处理不同。即使账号、目标地址和网络名称相同，也不能假设结果完全一致。
设备表至少保留系统版本、芯片架构、客户端版本、网络类型和测试时间。换机后先建立新记录，不要把旧设备数字直接当成合格线。
把瞬时速度放回完整任务
测速工具通常在短时间内建立多条连接，它适合观察接入能力，却不一定代表单个文件、单条会话或目标服务的真实表现。
更接近实际的方法，是选择一个可重复任务，记录开始、完成、中断与恢复时间。连续数次结果的范围比单次最高值更能说明日常体验。
晚高峰需要日间对照
晚上变慢可能来自家庭接入、无线竞争、区域线路或目标服务拥塞。没有日间对照时，很难知道变化发生在哪一段。
保持设备、任务和目标不变，分别在日间与晚高峰执行。若只有无线设备受影响，先检查本地环境；若多种网络同时变化，再观察区域或目标服务。
抖动会藏在平均值后面
两次任务的平均延迟可能相近，其中一次却频繁出现短时停顿。语音、远程桌面和交互工具对这种波动尤其敏感。
除了平均值，还要保留中位数、较高分位和异常峰值出现的时间。这样才能区分持续偏慢与偶发卡顿。
完成率比峰值更接近结果
高峰速度说明链路在某一刻可以达到的能力，完成率则回答任务最后有没有成功。大型文件、长时间同步和批量资料更需要后者。
把成功、重试、失败、校验不一致分别计数。若速度很高但任务经常重启，优化重点应放在会话保持、存储权限或恢复机制。
恢复时间决定中断成本
网络切换、设备休眠或目标端暂时不可用都可能中断任务。真正影响工作的是能否从已完成位置继续，以及恢复需要多少人工操作。
测试恢复时不要立即清空任务。先记录断点、重试次数、源文件状态与目标目录，再判断客户端是否正确续传。
用变化范围代替绝对承诺
网络环境会随时间、地点和服务负载变化，任何单一数值都不应被写成永久保证。基线的作用是提供一个可比较范围。
当结果超出平常范围，先重复同一任务，再只改变一个条件。一次同时换设备、网络和目标地址，会让原因无法追踪。
记录格式必须让别人看懂
只有截图而没有设备、时间与任务说明，团队成员很难复查。日志应让没有参与现场的人仍能理解发生了什么。
建议使用固定字段，但正文备注保持自然：写清现象、已确认条件、尚未确认部分和下一次测试。不要提交密码、验证码或私钥。
基线最后要回到实际决策
测量不是为了积累数字，而是决定是否需要换网络、调整客户端、延后大型任务或准备备用路径。
每次复查只形成一个明确判断，并写出适用条件。新的系统版本、设备或工作地点出现后，再建立新基线，而不是覆盖旧记录。
从机器人现场看连接基线
机器人工位很少只有一条数据流。相机、编码器、力觉传感器和控制器同时工作，现场网络还要承担日志回传、固件更新与远程协作。因此，基线不能只记录一次测速，而应该覆盖一个完整工作周期。
比较时可以保留一项实际任务，例如回传一组视觉记录，然后分别在设备空闲、正常生产和高负载时执行。这种设计能看出延迟是持续增加，还是只在其他设备集中上传时短暂出现。
中国机器人产业从样机转向工厂、仓储和服务场景后，工程团队更需要跨地点复现问题。一份可用的基线应让远程成员看懂设备状态、任务目标和异常发生的顺序，而不是只看到一张脱离现场的图表。
当新客户端、新控制器或新路由策略上线时，保留旧基线比覆盖记录更有价值。团队可以将新旧结果放在同一任务下比较，再决定是继续部署、调整参数，还是回到已经验证的版本。