如何读懂技术主张：来源、测量与不确定性

公告、测量和评论回答不同问题

开发者公告说明发布了什么；测量说明特定设备与输入下发生了什么；评论说明作者如何理解结果。同一篇文章可能包含三者。先把句子分类，才能知道哪些是有证据支持的观察，哪些只是承诺或解释。

本指南中的“快转换”产品及全部耗时都是为教学虚构的案例，我们没有测试真实产品。这里提供的是阅读方法，可用于分析科技新闻或 AI 回答中的具体主张，而不是产品购买建议。

把标题改写为可以验证的句子

“快转换现在速度翻倍”没有说明版本、文件和操作。可以验证的表述是：“在同一设备上，把同一份 10 MB CSV 文件转为 JSON，本例耗时从 800 ms 降到 400 ms。”如果不包括文件读取或结果下载，也要明确说明。否则读者容易把某一步的时间理解为整个流程的时间。

AI 回答中的链接能打开，并不代表引用正确。原文是否确实包含该版本、操作与比较？如果文章又引用另一篇文章，应继续找到最初的测量。找不到原始记录时，状态应写成“原始测量不可得”，而不是“已验证”。

• 主张：具体哪个行为发生变化？
• 范围：什么版本、设备与输入？
• 证据：测量数据和可重复方法在哪里？

“速度翻倍”与“耗时减少 50%”

800 ms 降到 400 ms，减少比例是 (800 − 400) / 800 × 100 = 50%。旧耗时与新耗时之比是 800 / 400 = 2。对于相同任务，耗时减半意味着理想情况下原来的时间可以完成两次操作，但不能据此断言所有场景的整个应用都快了一倍。

再假设文件选择、读取与输出准备始终需要 1,200 ms。总耗时便从 2,000 ms 降到 1,600 ms，改善幅度是 20%。一个环节的显著提升不会自动等比例传递到完整体验。看到百分比时，应先找它的分母，并确认省略了哪些步骤。

不要用最好的一次代替完整结果

虚构的旧耗时为 780、800、810、790、820 ms；新耗时为 390、400、410、395、900 ms。排序后，中位数分别为 800 和 400 ms。但新数据中的 900 ms 慢速运行仍值得记录，不能为了标题好看而删去。五次测试也不足以可靠估计广大用户遇到延迟的概率。

设计真实浏览器实验时，应记录相同文件、软件版本与计时起止点，并单列预热过程。MDN 说明 performance.now() 使用单调时钟测量经过的时间。这有助于避免系统时间调整的影响，却不会消除设备负载、缓存差异或实验设计中的偏差。

保留简短的证据记录

可以先写四行：主张；来源及访问日期；来源真正支持的发现；仍未解决的问题。本例支持的说法是“相同假设任务的转换耗时中位数减半”，而“大文件内存占用和慢速运行如何变化”仍是未知项。没有数据的地方不要补上看似合理的答案。

公告日期不一定等于测量日期，网页更新日期也不一定是事件发生时间。新文章可能在复述旧测试，因此应核对测试对应的软件版本。五个网站互相转载同一结果，也不等于五次独立实验。

分享时同时保留结论和边界

适当的摘要是：“在教学情景中，转换耗时中位数从 800 ms 降为 400 ms；加上假设固定准备时间后，总体改善为 20%。这不是真实产品基准测试。”数字、适用范围与不确定性出现在同一段落，减少断章取义。

向社区提问时附上原始来源、不理解的句子和自己的计算步骤。使用小型合成数据，不要公开私人文件或个人信息。新证据改变结论后，说明具体修改了什么。百分比工具可以辅助算术，但无法判断来源是否诚实、比较是否公平。