机器可读原始数据为什么重要：从截图到可复核数据

截图证明测试发生过，结构化记录才能被复核

测速截图能证明“某一刻有过一次测试”，却很难被别人复核：它不能检索，不能可靠地汇总，转写时容易抄错单位，也难以证明没有经过挑选或修改。机器可读的原始记录把时间、条件、单位、失败与重试都写成明确的字段，别人才能在同样的字段上重新计算、比对和质疑。从数据状态的角度看，截图是 Measured Data 的起点，结构化记录才是它能被反复引用的形态。

本文不公开、也不转写任何截图数值。本站截图从发布到转写数值之间还缺哪些条件，已在 本站公开测速数值前还缺什么 中列出；批次本身的说明归 本站测速批次记录与局限。所属专题见 数据状态与标注规范专题。

截图形态的五个局限

前四项可以靠结构化部分解决，最后一项则需要在测试时就记录，事后无法从图片里恢复。

本站已经结构化的部分

本站没有转写图内数值，但围绕截图的元数据已经以字段形式保存，并在品牌页测速报告面板中展示：

“日期可信度”这一字段很能说明结构化的价值：可信云截图只清晰显示时刻，日期按批次推定。如果只有截图，这个差别只能写在正文里，很容易被转述时丢掉；作为字段保存后，它会跟着记录一起出现在任何引用它的地方。可以在 可信云的测速报告面板 看到这一标注。

源文件哈希的作用则是防篡改：发布在页面上的 WebP 图片由原始 PNG 只做缩放与重新编码生成，没有裁剪或改动图内内容；原始文件的 SHA-256 记录在案，日后若有人质疑某张图被改过，可以拿原始文件重新计算比对。

一份可复核的测速记录应包含的字段

如果要把测速结果做成真正可复核的数据，每一次测试应记为一行，至少包含以下字段：

test_id         唯一编号
batch           批次编号
tested_at       日期时刻（带时区）
tester_network  测试端城市、运营商、本地带宽
tool            工具名称与完整版本
backend         测试后端位置与带宽规格
threads         线程数
node            节点名称
protocol        节点协议
metric          指标名称（如 HTTPS 延迟、平均速度）
unit            单位，按工具原样记录，不换算
value           数值；失败时留空
status          成功 / 超时 / 失败
retries         重试次数
source_file     对应截图或导出文件，及其哈希

其中三个字段最容易被省略，却最影响复核：unit 确保不同来源的数值不会因为单位混淆而被错误比较；status 让失败结果作为一行记录留下，而不是被悄悄删除；retries 让读者知道展示的结果是否经过多次尝试后挑选。

从截图到结构化数据的步骤

1. 登记源文件：记录文件名、尺寸与哈希，之后所有转写都指向这个文件。
2. 双人转写：两人分别转写图内数值，对比差异，不一致处回到原图核对。
3. 单位原样保留：工具显示 MB 就记 MB，换算放在单独的派生列。
4. 异常值保留：零速度、超时、UDP 无法判定都记为一行，标注 status。
5. 补齐上下文：测试端网络、重试规则等图里没有的信息，从测试记录中补入；补不上的标为待核实。
6. 汇总规则先行：先公布用平均值还是中位数、怎样处理异常值，再计算。

结构化之后才可能做的三件事

• 复测比对：同一节点、同一工具在不同日期的记录可以按字段对齐，直接看出变化，而不必把两张截图并排肉眼比较。
• 发现挑选：如果记录里有 status 与 retries，读者能看出展示结果是否只取了成功的一次；截图形态下，这种挑选几乎无法被察觉。
• 独立重算：任何人都可以用公开的记录按自己的规则重新汇总，不必接受发布者给出的唯一结论。

这三件事正是“可复核”的具体含义，也是本站在补齐条件之前不转写、不汇总图内数值的原因：没有完整字段的数值一旦被转写成表格，就会被当作可以比较的数据使用。

风险与边界

结构化不会让单次测试变成长期结论，也不会让不同工具的结果变得可比，它只是让同一份证据更容易被检查。自己测速时，可以直接用上面的字段做记录表，具体测试流程见 自己动手测速，数据核实的整体方法见 数据来源与核实方法。使用任何网络服务时，请遵守所在地法律法规与平台条款。